CSCI399
Autumn Session, 2009

Assignment 5: JSP and JPA

• Aims
• Objectives
• Tasks
• Submission

Aim

This assignment aims to introduce Java Server Page technology, JSTL tag library, and the new Java Persistence Architecture model for persistent data.

(This is actually a rather easy assignment - but then it's the end of term and you are probably behind on work for all your other subjects!)

The objectives are for you to:

• build a web application comprising control servlets, entity classes, and JSP presentation pages;
• learn the basics of JSP technology
• explore simple use of JPA.

RentADump revisited

Overview

For this assignment, you are required to rebuild your "RentADump" site. This time you use "Java Server Page" technology to generate (some of) the final response pages, and "Java Persistence Architecture" technology to automate data persistence.

Markup pages and "tags" - the reason for JSP

Servlets represent a good technology for the control aspect of the server side; the code needed to work with beans and other helper classes is usually quite straightforward. In very simple cases, it is possible for a servlet to use JDBC to directly access persistent storage though generally it is better to move such code into helper classes.

But servlets are a bad way of generating the final HTML response pages. All those out.println statements with fragments of HTML markup, content text, and odd variable values are disgustingly opaque as well as being long winded. You cannot get much idea of the appearance of a response page by reading the servlet code.

HTML pages are best created (by persons of an artistic and creative bent) in some form of GUI editor. Such editors allow a user to place content (text and image data); the editor program generates the HTML markup tags needed to create the chosen display format. (Some of the HTML markup generation schemes are crude. They use tables to lay out pages, with empty filler fields around table elements with the text fragments or images. Such schemes result in very large HTML pages with an awful lot of markup - the handling of such large pages can impact on the performance of the server and its network connections.)

Many "web designers" have at least a little experience with Javascript client side scripting and can add scripted elements (such as Lea Smart's calendar control) to their pages. Javascript doesn't present too many challenges to a GUI editor. The main scripting code can be kept in a separate file with simply a <link ... > element in the header section of the page being edited. It doesn't really matter if the actual Javascript code is pasted into the header section (because the GUI editor doesn't need to display this section and can simply keep it as a text supplement). GUI page builders may even provide dialog systems that help "web designers" who need to add "on-event" attributes to form elements.

Dynamically generated content is a bit more difficult! One approach - exemplified by PHP and Microsoft's older "Activer Server Page" (ASP) technology - relies on "server side scripting". The source of the HTML page must contain embedded code (VBScript or PHP code) in amongst the static HTML markup and static content text. The page is processed in the server before it is sent to the client. The server strips out the script code, runs this code, collects the output that resulted when the code was run, and inserts this output into the revised page. The problem for the GUIs is that one ends up with large chunks of arbitrary program code littering the HTML and static text that they handle. It isn't always easy for the GUI page editors to handle such code text, and it certainly isn't easy for a "web designer" to compose such code.

Still the style of HTML markup, content, and a little embedded code is easier for a "web designer" to deal with than the HTML embedded in out.println statements that one gets with servlets.

The earliest version of Java Server Pages followed this "little bits of code embedded in HTML" style. A JSP page contained HTML markup and static content web, probably created with a GUI editor of some form, that contained "scriptlets" - fragments of actual Java code embedded into the markup. The entire JSP page was pre-processed to produce a servlet that would incorporate the Java code and handle the other data through generated output statements.

As you experienced with PHP, the idea of little bits of code in amongst the HTML is largely a fiction. As soon as the processing gets complex, one finds that the source pages have little bits of HTML in amongst large chunks of code. The GUI editors, and the "web designer" users, were again troubled.

Second generation systems evolved to try to reduce the amount of code in the pages. These 2nd generation systems include Microsoft's ASP.NET and JSP with "tags" - first from various communities (e.g. Apache's struts tags) then later with a standard tag set (JSTL).

ASP.NET and JSP/JSTL are similar. "Code" is inserted as XML style tags that are easily handled by the GUI page editors. These tags take attributes. The translation system recognizes the tags and expands them out to elaborate code - function calls, class instantiation and use, ... - that is used entirely internally. The attributes in the tags are parameters for function calls, constructors etc.

The JSTL includes a variety of tags. One can run SQL queries from some tags! Mostly the JSTL tags are used to instantiate helper classes, invoke operations on these, and do tasks like iterate though a collection of items that must be added to HTML tables.

In principle, you can do everything with JSP tags. In practice, JSPs are best kept simply for display - insert data generated earlier into a HTML page. The real work is done by a control servlet and instances of helper classes.

JPA

The E5 exercises should have provided a convincing illustration of the power and convenience of the JPA technology. JPA shortens and simplifies the code needed for data persistence.

Webapp A5

1. Create a new web application. (Some parts of your Assignment 4 web application can be copied and "refactor-pasted" into this new web application.)
2. Add a persistence unit that maps to your Oracle schema to the new project along with the "Toplink Essentials" and JSTL libraries (and the file upload libraries that you used earlier).
3. Generate Entity classes from your existing database tables for properties and photo data.
   Fix up the generated entity classes as necessary (references to sequences etc - you might also wish to change BigInteger and BigDecimal types to int, image data will have been defined as Serializable, you will need to change this to byte[]).
4. Rewrite all your existing servlets.
   Utilize JPA EntityManagers and instance of your entity classes for persistent data. Use JTA user transaction resources to control transactional updates of the persistent store (the insert operations).
   Remove existing report generation code; replacing it with code that forwards necessary data to a JSP for display.
   Actually, you can leave the code that generates simple error pages and the response pages that acknowledge successful entry of a new property record or an additional photo record. The sections that you need to remove are those in the "Find property" servlet that generates a listing of possible properties, and in the "View details servlet" where you display full details and photos of a chosen property.
   You replace those sections of HTML-generating code with code that adds data to the HTTPRequest object and forwards the request to a JSP.
5. The new webapp is to use the same access control scheme as was implemented for assignment 4.
6. Compose two JSP pages, all using the JSTL tag library. Put some effort into making these pages graphically rich and effective - "prettiness" is an important aspect of your web site.
   These pages are:
   • The JSP page that presents matching properties. This should receive its data as a collection of "property" data objects attached to the request that is forwarded by a servlet. It is to use JSTL core iterative constructs to compose a tabular display. (I made use of the fn:length function from the JSTL functions library as well; this was just to print a heading like "We have 9 properties that match your requirements". There is a copy of the reference documentation on JSP/JSTL in /share/cs-pub/399/A5).
   • The JSP that presents details of the property. This will need to be passed the selected property as an extra attribute attached to the HTTPRequest object. You can sort out details of photos either in the servlet (and pass additional attributes that are collections of the photo numbers for interior and exterior views) or in the JSP. Avoid scriptlet coding in the JSP, try to do everything with tags from the JSTL libraries and "Expression Language" (pseudo-Javascript) code for accessing data.

The due date for submission will be announced in lectures; provisionally set for June 5th.

As with previous assignments, you will submit a report on your work for assessment. This should be a word processed document converted to PDF format.

Each servlet, JSP, and entity should be presented in a separate section. A source listing of the wizard generated web.xml file should be included.

There should be screen shots illustrating your forms and responses.

For this assignment you submit your work using the command:

turnin -c csci399 -a 5 A5.pdf

Since the assignment is due in the last week of session, it is not permitted to allow extensions.

Marking

1. 1 mark overall quality and appearance of report.
2. 2 marks quality and appearance of web site! This is a JSP site - they are supposed to be pretty, put some effort into making your site look good.
3. 3 marks for all parts working as adequately documented through submitted evidence
4. 4 marks for Java code of the servlets that now make use of EntityManager and entity classes, and for the JSTL markup in your JSP pages (you will need include the JSP pages - highlight the JSTL sections and, optionally, cut out any lengthy "boilerplate" content and markup).