CS636 Class 19: hw4 is available, due Nov. 28, and tomcat zip, instructions

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

Now we’ll also use session vars.

We’re following the MVC pattern, see pic on pg. 33:

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 8 on EL, Chap. 9 on JSTL.

MVC in PHP: controller, views and model are in PHP, can cause confusion.

Now consider example 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 finishes, those 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. They hang off the "session" object just like the request variables hang off 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.

Next challenge: Moving pizza2/music2 to the web container inside tomcat