Students may work in pairs for this project if they wish. Individual projects need only implement the user web pages, and may use a simpler user-pages servlet as explained below. 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. Students who received 0 on pa1b may only do individual projects.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 (this is provided). Don't break the old client-server apps or the unit tests!
A start on the project is supplied in project music3-setup. Note that the database has changed slightly to accommodate use of one database for "sales" (users and invoices) and another for the "catalog" (products, downloads, etc.). No foreign key can bridge the gap between the databases, so the user associated with a download no longer has a foreign key, and similarly, neither has the product associated with a lineitem. Instead of ids with foreign keys, the username is used in a download, and the product code is used in a lineitem.
Try to keep the two database apps separate, but this is only a desired feature, not a requirement. However, be sure to use the provided database setup and service/DAO code.
Because of the changes to the database setup, you need to reload the music database before running music3-setup. You should be immediately able to run the client-server SystemTest and also the "ant webSysTest", i.e., SystemTest run from the provided SysTestServlet. Before running webSysTest, be sure to do the edits in tomcat's conf/context.xml as described in UsingDBfromWebApp., as well as deploying the app with "ant deploy-xxxdb".
The service API has been split into CatalogServiceAPI and SalesServiceAPI, one for each database. You can treat them together as one unit or try to keep the code accessing the two databases apart. They are implemented so that the catalog service only uses its DAOs (users, invoices, lineitems), and the sales service only its DAOs (product, track, download). The sales service code calls the catalog service API to get information on a certain product, rather than the product DAO.
Note that it is not
difficult to provide the capability of listening to the samples listed
in table track. You may write a single page that displays tracks for any
CD using track table data, something like the Sound page, pg. 652. It's
OK to list only the tracks in the track table. Alternatively, use the
sound/*/sound.html files of music3-setup. Note the download app ch07download
(zip) is available and plays the samples,
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.
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. Specifically, use pizza3's DispatcherServlet as a model for one DispatcherServlet for non-admin actions, or preferably, two DispatcherServlets called CatalogDispatcherServlet and SalesDispatcherServlet for the two parts of the system. If necessary, CatalogDispatcherServlet can use the sales service API, and vice versa, but it is possible to handle the needed actions by forwarding from one servlet to the other, for example after registering the user in the sales servlet, forward to the catalog servlet to allow the user to listen to tracks. Note that if you use two dispatcher servlets, the URLs need to be different enough that they can be differentiated by the url-mapping for each servlet. For example use foo.html for one dispatcher and foo.do for the other. Since this is tricky, start by using one DispatcherServlet like pizza3's, and if you have time, try splitting it up into two.
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 includes than that, and these are optional. You can use snippets of JSP from the musicStoreJPA in your own JSPs.
If you are doing an individual project and find the DispatcherServlet approach too complicated, you can use the provided AdminServlet as a model instead of DispatcherServlet.
You may use session beans called UserBean (say) and AdminBean to follow the user/admin through their pages, or use multiple variables attached to the HTTPSession. In the JSP code, use JSTL/EL for all dynamic HTML, i.e., no scriptlets. Don't use JSP to get user input from request parameters: use the servlets as in pizza3.
are using Java, JPA, HTML, JSP, EL, JSTL, and servlets, and optionally,
that require additional jar files, such as Spring.
Sunday, Dec. 10: 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 getting started on pa2:
1. Get pizza3 working, for reference.
2. Start from music3-setup. Install 2 copies, one as music3-setup and another as music3 for development.
3. Try running the provided project as described above, including inside tomcat. If working with a partner, try meeting in the UNIX lab. You can exchange files or whole projects by email. Don't change the protection on your cs636 directory.
4. Study DispatcherServlet from pizza3 and think about how to modify it. Decide on one action, say displaying the StudentWelcome page, and put code in the dispatcher for that.
5. Write a JSP page for StudentWelcome, first without dynamic HTML (i.e. plain HTML, but named something.jsp), and see it displayed using the URL you coded into the dispatcher.
Use the packages as in the supplied music1 project, and corresponding to pizza3:
cs636/pa2/src: top of sources tree Note this! (Please not /pa2/music3/src or whatever)
cs636.music.config: provided, but edits might be needed
cs636.music.presentation: any sources common to web and client-server presentation, including SystemTest: provided but can be changed.
cs636.music.presentation.clientserver: AdminApp, UserApp (provided)
SysTestServlet, AdminServlet, DispatcherServlet or two dispatcher servlets, *Controller.java, optionally *Bean
or for individual projects only, StudentServlet modeled after AdminServlet
cs636.music.domain: same as provided
cs636.music.service: same as provided
cs636.music.service.data: same as provided
cs636.music.dao: same as provided
WEB-INF/web.xml provided but may need edits (is set up for two dispatcher servlets)
WEB-INF/jsp/*.jsp user pages
WEB-INF/admin/*.jsp admin pages (if admin web UI is implemented)
here, or fancy CSS, that is, more complicated than pizza3's CSS. Use
database/build.xml, createdb.sql, etc.: same as provided. 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", etc. targets all work 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-xxxdb" 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 deploy-hsqldb; ant webTest1; ant webTest2; ant webSysTest; ant deploy-mysqldb; ...; ant deploy-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 our standard environment variable settings, 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.