When a Container translates the JSP into a servlet, the beginning of the service method is a pile of implicit object declarations and assignments.
With implicit objects, you can write a JSP knowing that your code is going to be part of a servlet. In other words, you can take advantage of your servletness, even though you’re not directly writing a servlet class yourself.
Think back to Chapter 4, Chapter 5, and Chapter 6. What were some of the important objects you used? How did your servlet get servlet init parameters? How did your servlet get context init parameters? How did your servlet get a session? How did your servlet get the parameters submitted by the client in a form?
These are just a few of the reasons your JSP might need to use some of what’s available to a servlet. All of the implicit objects map to something from the Servlet/JSP API. The request implicit object, for example, is a reference to the HttpServletRequest object passed to the service method by the Container.
BE the Container
Exercise
Each of the listings is from a JSP. Your job is to figure out what will happen when the Container tries to turn the JSP into a servlet. Will the Container be able to translate your JSP into legal, compilable servlet code? If not, why not? If so, what happens when a client accesses the JSP?
<html><body> Test scriptlets... <% int y=5+x; %> <% int x=2; %> </body></html>
<%@ page import="java.util.*" %> <html><body> Test scriptlets... <% ArrayList list = new ArrayList(); list.add(new String("foo")); %> <%= list.get(0) %> </body></html><html><body> Test scriptlets... <%! int x = 42; %> <% int x = 22; %> <%= x %> </body></html>
Design Goal
Create a JSP that will produce this:
The HTML form
Note
Important tips and clues
The request attribute is of type java.util.ArrayList.
The implicit variable for the HttpServletRequest object is named request, and you can use it within scriptlets or expressions, but not within directives or declarations. Whatever you can do with a request object in a servlet, you do inside your JSP.
A JSP’s servlet method can process request parameters, because remember, your code is going to be inside a servlet’s service method. You don’t have to worry about which of the HTTP methods (GET or POST) was used in the request.
We’ve put a few lines in for you. The code you put in this JSP MUST work with the code that’s already here. When you’re done, it should be compilable and produce the result on the opposite page (you must ASSUME that there’s already a working servlet that first gets the request, sets the request attribute “names”, and forwards the request to this JSP).
BE the Container Answers
#2 is straightforward and works. #1 is a fundamental Java language issue (using a local variable before it’s declared), and #3 also demonstrates a fundamental Java language issue—what happens when you have an instance and local variable with the same name. So you see... if you translate the JSP code into servlet Java code, you’ll have no trouble figuring out the result. Once your JSP stuff is inside a servlet, it’s just Java.
