CS636 Notes for Class 17

Midterm Exam on Wednesday:  it’s open book, open notes, can bring posted solutions and your own hw.

Midterm Review

Two threads, soon to converge:

--web background

--client-server DB apps 

Book Coverage:


Chap 1 Intro. Layers shown, pg. 17.
Chap 4 HTML, to pg. 105, skip 106-113, study forms to pg. 121

Chap 11 MySQL pp. 347-351, 364-374, but we use caseless database identifiers, as is standard

Chap 12 JDBC pp 378-387 (we use DECIMAL(10,2) and BigDecimal for money)

Chap 18 HTTP, pg 543-553

On pg. 545: second line would usually be GET /email/join-email_list.html HTTP/1.1

Chap 22 Music Store Website: the pictures of pages defines our project UI and thus its needed functionality. Read pp. 644-651,662-669

pg. 663: add Track, Product 1:* Track.  We have a track_id FK in Download.

pg. 664: note this is MySQL-specific. See createdb.sql from music1_setup for portable version.

Homework—see solutions if needed!

hw1: HTML, URLs, OO basics, review SQL, Java Collections, JDBC

hw2: XML basics, command line Java, Java packages, ant, HTML forms, tictactoe example

hw3: page flow for pizza, Java exceptions, music1 setup, music1 SQL, Register.java for music1

Projects: pizza1, music1. I’ll bring two copies of full sources for pizza1 and parts for music1 (posted solution).

The practice midterm is available, and solutions for it.

Pa1b graded project scripts will be emailed soon.  Solution already posted.

music1 analysis, with needed terminology:

UserApp is the official presentation layer program, along with the less-important AdminApp

SystemTest is an overall test program, not a "unit test", and is also presentation code.

These presentation programs call into MusicSystemConfig to get the crucial refs to the service API: vars named studentService and adminService of type StudentService and AdminService. These are singletons.

AdminApp has two fields named user and cart holding UserData and Cart objects, holding user-private data. The Cart has new LineItem objects, also user-private. The LineItem has a Product and its tracks attached to it, but these are immutable, so their longer life in presentation is OK.

There is also a Product variable that lives across calls to the service layer while processProduct is executing. This represents the user choice of which product to listen to, etc. The Product and its Tracks are immutable objects, so their longer life in presentation is OK. 

If Products were mutable, then we shouldn't hold the whole object in presentation, but rather just its PK value, so we can look it up as needed (by calling the service layer, of course).

AdminApp calls the service layer to do its needed actions, and these calls usually call down to the DAO.

Service Layer: StudentService and AdminService

These singletons have fields holding refs to DAO objects, and no other fields, by the "stateless service layer" rule. Only the presentation layer may have fields with domain data, and that should be user private or immutable, (or if mutable, reloaded from the PK if sent back to service--this does not happen in the music project but does in the pizza project).

These classes provide the service API, i.e., the methods to call for actions needed by the app. The service API is the most important API of the system. It defines what the whole app can do.

The refs to DAO objects are provided to the service object via constructor argments. MusicSystemConfig constructs the DAO objects first, then passes their refs to the service object constructors.

DAO Layer

This layer does all the needed JDBC to drive the database, offloading this work from the core code of the service layer.  The API it offers to service layer code is main a CRUD API. The finders of the API return domain objects (and possibly also ints, etc.) to the service layer, so that the service layer can be written in OO Java.  The other calls of the API change rows in the database based on the needs of the service layer.

The DAO singletons are created by MusicSystemConfig and passed to the service layer singletons (in their constructors) for the use of it to call the DAO. Like the service objects, they have no fields for domain objects.  The only field is the Connection, established in the DbDAO constructor.

Note: unit testing, JPA not on midterm

Summary of ideas and rules on layers: layers, domain objects, business layer methods

Any topics to review in detail?

If time...

Introduction to JSP Java Server Pages server side programming.

JSP : old vs. new

Scriptlets : <% . . . %> in JSP

Old vs.                                New JSP

JSP1.2                                JSP2.0+

<% . . . %> in JSP              With JSTL, EL  <c:forEach>, ${user.firstName}

Still in common use            

Old JSP involves serious use of scriptlets for decision making and other processing, i.e., lots of Java code interspersed in the HTML.

New JSP avoids most scriptlets by offering a convenient way to access the data in Java objects using EL, do loops, etc. using JSTL

Example of EL in action: thanks.jsp listed on pg. 47

${user.firstName}   calls getFirstName() in “user” object, itself a request attribute

It could be a plain String  ${message} can access the “message” request attribute, with a String value “Error!...” 

EL is intro’d in Chap. 2 and Chap. 6 and covered in detail in Chapter 8.

Pure HTML also qualifies as JSP: Can rename .html file to .jsp still see it.

First small JSP example, using scriptlet (old way, but still in use widely)

Date.jsp    (in webapps/basicjsp)
       Today's date is <%= new java.util.Date() %>

It gets JSP-compiled to date_jsp.java in a semi-secret tomcat directory

work/Catalina/localhost/basicjsp/org/apache/jsp  relative to $(CATALINA_HOME)

For my tomcat, can see at

/home/eoneil/cs636/tomcat-8.0/ work/Catalina/localhost/basicjsp/org/apache/jsp/date_jsp.java 

In date_jsp.java, we see:

out.write(“ \n”);
out.write (“

\n Todays date is “);
out.print(new java.util.Date());
out.write( . . .);

So we see how Java outputs the needed HTML specified by the JSP.