Test your knowledge on this important example, ch05email:
How does the user input get to the servlet?
How does the servlet pass on information to thanks.jsp (i.e, to its servlet)?
How does thanks.jsp get the information out of the request attribute so it can use it for its response HTML, so the user can see it?
The forwarding operation is a little mysterious because it utilizes a URL but does not involve handling an external request coming into the server. Instead it is used to “chain” work inside the server. The code to do the forward in EmailListServlet is:
This shows the request and response objects being handed over to be reused with the target servlet. No other data objects are handed over, but we know lots of info can be attached to the request.
The url in this case is “/thanks.jsp”. This is neither a relative URL or an absolute one. The / here represents the root directory of the webapp, …/ch05email in this case, so this is forwarding to /ch05email/thanks.jsp. Again we see that we don’t need to know the webapp name to code the webapp, because this is relative to the root directory of the webapp, wherever that is.
We must always use a URL like this for forward (see Javadoc), that is, it must start with a /. Forwards can only go to somewhere in our current webapp, not out into the Internet or even to another webapp on this server.
Added note: Another URL starting with / is shown on pg. 101. It means something different here as the target of an href in HTML: it means the root of the whole webserver filesystem, i.e., the webapps directory of tomcat.Only the request and response objects are handed over in a forward. All the other variables are not accessible to the forwarded-to servlet/JSP, unlike in PHP. The trick is to attach attributes to request to let them ride across to the target.
In webapp ch05email, we saw that the servlet accessed the DB (stub actually), attached data to the request object (request attributes), and forwarded to a JSP, which used EL to access the request attributes and generate HTML
We’re following the MVC pattern, see pic on pg. 33:
Note that this picture describes one request-response cycle:HTTP request to server, followed by one HTTP response (often HTML) back to the client, all in one TCP stream connection that provides a two-way data pipe between the client and server. Here our controller is in Java, views in JSP, generating HTML to be sent back to the user.
Model: our DAO layer, same as in client-server
Controller: The servlet code: interprets parameters, i.e., user input, accesses DB, makes decisions, prepares request and/or session variables for view code to access. Layers: controller can be layered into presentation code on top of service layer, where the presentation calls service layer to do app actions.
View: JSP with EL to access variables, JSTL to do loops, etc. No business decisions—pure presentation code, without any service API calls.What about the layers? Where do they fit in above?
Start reading Chap 6 on intro EL, Chap 7 on Session Variables.
MVC in PHP: controller, views and model are in PHP, can cause confusion.
New topic: MVC webapps with session variables.
So far, we have been using "request variables" like the "user" attribute in ch05email. A request attribute can be called a request variable.
Request variables are great for communicating between the servlet and the JSP it forwards to, since they use the same request object.
But as soon as the request-response cycle finishes, those request variables and values evaporate.
In many cases, we need to remember information in the server for longer, from one request cycle to another. That's when we use session variables, or of course the database. The session variables hang off the "session" object just like the request variables hang off the request object. The session object hangs off the request object, so everything is accessible from the request object.
Look at Chapter7 slides (6pp)
First ex: The Cart app, starting pg. 204. Here the Cart is as in
music1, with a collection of Lineitems. The CartServlet does all the
actions on the cart, which is installed as a session variable. That means
the cart lives from one request to another of the same user--it follows
the "user conversation".
The UI just collects the user input and invokes the servlet. Since the servlet is executed multiple times on different request cycles, a request variable would not be long enough-lived. With the cart available as a session variable, it’s easy to use it over and over on different request cycles.
See the Cart page flow in slide 8 of the Chapter 7 slides. See 5 big black dots representing the servlet being executed on various requests. As in many controllers, the controller is directed by the incoming action= value, here “shop” or “checkout” or null (unusual, defaults to “cart”).
Another name for action might be “command”. Basically, the controller is reacting to various UI actions/commands, as a presentation layer should.
Layers. The presentation layer gets the work done by calling the service layer in our design, but here in Murach the service layer and presentation layer are not separated. It still qualifies as MVC, just not fully layered like the pic on pg. 17.
Second ex: the Download app, starting p.226. User object, a session variable, is created on first visit to servlet, along with a session variable for the productCode. The productCode is used on the second execution of the servlet to select the right final view. Without session tracking, the second visit would not know what product was selected by the user on the first page. See the page flow handout for this app. Note that this is useful for project 2.
Tomcat does the session tracking for us, first trying cookies and if that fails, URL rewriting. On the first request by a user, a new session object is created. On later requests, tomcat locates the right session object and attaches it to the pageContext object. So all we have to do to add data (via attributes) to the session object to provide it to later requests by the same user.