CS636 Programming Assignment 2 (pa2)

Music3, a DB-backed MVC WebApp

Students may work in pairs for this project if they wish. Individual projects need only implement the user web pages. The admin actions can still be handled with the client-server AdminApp. Partnerships should implement the admin pages but will only lose 5 points if they are not implemented.

Note that a student laptop can be connected (by Ethernet cable) to the Internet in the UNIX lab with full access to our network. You do need to register your Ethernet address first by email to operator.  Email operator.cs.umb.edu from your departmental or UMB account providing your laptop’s Ethernet address. That will put your machine in the operator’s table of good guys, and you will be able to plug into (via Ethernet cable) the departmental network.

Each team will design and implement a multiple-JSP-page UI for the music project, following the general UI flow specified in Murach originally, and simplified as shown in the Music UI page flow diagram. Tie the two UIs together (as in pizza3) by having a home page for the whole system with the simple choice of User or Admin services. Don't break the old client-server apps or the unit tests!

Now it is easy to provide the capability of listening to the samples listed in table track. The Sound page, pg. 652, will list only the tracks with samples if you write a single page for any CD using track table data, but that's OK. Alternatively, use the sound/*/sound.html files (available in music2, copied from music1-setup). Note the download app ch20download (zip) is available and plays the sample, showing how to get the browser to play the mp3s.

You may use the catalog/*/index.jsp files from Murach’s distribution to display products to the user, or make up a simple one (same source for all products) that uses information in the product table.

Although the normal place for a user to start accessing a website is at the site-welcome or user-welcome pages, support starting from other pages.  In real life, people often reach your site via search engines and may never see your welcome page.  Just detect that there is no user/admin session and forward the user to the appropriate welcome page, as is done in pizza*.

Music3: MVC Servlet/JSP for UI Solution, like pizza3
We will use JSP for display, but locate all the decision-making and calls to the service layer in Java, following the MVC (model-view-controller) pattern. In each request, the controller is in Java as part of a "dispatcher" servlet, and usually forwards to the view, in JSP. In some cases the controller forwards back to the dispatcher servlet. The JSPs to do pure display of previously determined data. This display can be conditional on the data fed to it. The JSPs should have no scriptlets.

The MVC setup shown in pizza3 is modeled on Spring MVC, but does not actually use the Spring framework. Use the pizza3 pattern for music3. For more information on Spring MVC, see the JavaWorld Tutorial.

The servlet code in Murach’s musicStoreJPA project (online (zip)) should be a big help in writing the controllers, for example, the CatalogController servlet of pg. 653 can become our CatalogController with a few edits. However, note the lack of a service layer and use of static methods for the DAOs, so proceed with care. Don't use all those JSP include files in musicStoreJPA. As in pizza3, you can use header.jsp, footer.jsp and sidebar.jsp if you want, but no more, and these are optional. You can use snippets of JSP from the musicStoreJPA in your own JSPs.

You may use session beans called UserBean and AdminBean to follow the user/admin through their pages, or use multiple variables attached to the HTTPSession. In the JSP code, use JSTL 2.0/EL for all UI.  

Technologies: we are using Java, JPA, HTML, JSP, EL, JSTL, and servlets. Projects should not use Javascript, or any software systems that require additional jar files, such as Spring.
Sunday, Dec. 11: Final version of pa2, in the cs636/pa2 directory of one member of the team.   Please submit in one team member’s directory, except for a README.txt in the other pointing to the real thing. Late days of either partner can be used.

Suggested steps for pa2:
0. Register your laptop by email to operator, and try out connecting it in the UNIX lab.  
1. Get pizza3 working, for reference. Deploying pizza3 is part of hw6.
2. Start from music2.  I'd install 2 copies, one as music2 and another as music3 for development.
3. Try meeting in the UNIX lab. You can exchange files or whole projects by email, or temporarily write files under your login directory in a public directory. Don't change the protection on your hw directory.
4. Based on your file comparison of hw6, edit music3 to be a web app without any JSP files. Get the servlet version of SystemTest working first.
5. Start writing JSP pages, first without beans, then add beans/session variables and access to the rest of the project.

Pa2 delivery
Use the packages as in the supplied music2 project, and corresponding to pizza3:
cs636/pa2/src: top of sources tree Note this! (Please not /pa2/music3/src or whatever)
cs636.music.config: needed edits to set up for web (see pizza3)
cs636.music.presentation: any sources common to web and client-server presentation, including  SystemTest
cs636.music.presentation.clientserver:  AdminApp, UserApp  
   SysTestServlet, AdminServlet, DispatcherServlet, optionally Controller.java, *Controller.java, optionally *Bean 
cs636.music.domain: same as before 
cs636.music.service: same as before
cs636.music.dao: same as before, except for providing per-thread EntityManager.

WebContent: following pizza3’s setup:
WEB-INF/jsp/*.jsp   user pages
WEB-INF/admin/*.jsp admin pages (if admin web UI is implemented)

Note: use no Javascript here, or fancy CSS, that is, more complicated than pizza3's CSS. Use HTML5.

database/build.xml: from music2, except change the project name to music3. Note that (as in the past) this uses environment variables to specify username and password for database drop and load. But the web execution gets the database username and password from tomcat's context.xml. These must agree!

project build.xml:  "ant build", "ant clean" cleans up, “ant config-*-*” targets all work as in pizza3. "ant sysTest" runs the client-server system test, as in pizza3,  "ant webTest1" should retrieve the site home page using wget or curl. "ant webTest2" should (in effect) choose product 1 in the catalog page and save the response, which may be the student welcome page because no user is logged in yet . "ant webSysTest" should run the SystemTest from the special servlet. "ant deploy" of course should deploy the project to tomcat, following the CATALINA_HOME environment variable.

cs  cs636/pa2/README.txt:  If a partnership, who your partner is and where to find the project to grade (here or in partner's pa2). Quick documentation of system. How much is implemented (user web pages only for example.) One line (or so) on each class that you have added to the project.  Subdivide the report into sections by package, in the order of packages listed just above. 

The main grading execution test will look like this, using topcat.cs.umb.edu:  ant clean; reload for all 3 DBs, ant build; ant config-web-hsqldb; ant deploy; ant webTest1; ant webTest2; ant webSysTest; ant config-web-mysqldb; ...; ant config-web-oradb; ... We may try out the JSPs too as well as read them, or use the browser automation tool “Selenium”. Be sure that all these commands will work for any valid environment variable settings, not just your own, since this grading execution will not be using your environment variable settings. The sources (java and jsp) will be read for good programming practices and decent header comments (Javadoc optional) on classes and public methods.