Baseline Version of the Pet Store

This section is an overview of the baseline version of the pet store case study, its components , the associated Ant files, and the JUnit tests (details of working with Ant files and JUnit tests are covered in Chapters 4 through 13). All other iterations of the case study in this book are based on this baseline version, so it is important that you see it laid out in one place.

In the next sections we describe the classes used, the public interface, the implementation for the baseline version, the Web interface, and the Ant buildfile structure used to build the case study. Later, we highlight an Ant buildfile that is used to create sample data for our testing. Finally, we cover some of the JUnit tests that are executed by the test. Note that a complete listing of the baseline case study appears at the end of this appendix; we dont cover the full application line by line because the focus is on the buildfiles , not the Java code.

Model Classes (Public Interface)

The online store system for the baseline consists of a navigation system. The CategorySystem class is the faade class that is mapped into the session of the Web application. Through the CategorySystem, the Web applications can access the model data (Category, Product, and Category instances) for listing views and detail views (see the following code listing and illustration). The model is the public interface to the catalog system.

 package xptoolkit.petstore.model; public class CategorySystem {     private Category currentCategory;     private Subcategory currentSubcategory;     private Product currentProduct;     public CategorySystem() throws Exception {         currentCategory = Category.getCategory();         currentCategory.setId(777);     }     public Category getCurrentCategory() {         return currentCategory;     }     public Subcategory getCurrentSubcategory() {         return currentSubcategory;     }     public Product getCurrentProduct() {         return currentProduct;     }     public Subcategory getSubcategory(int id) throws Exception {         currentSubcategory = currentCategory.getSubcategory(id);         return currentSubcategory;     }     public Product getProduct(int id) throws Exception {         currentProduct = currentSubcategory.getProduct(id);         return currentProduct;     } } 

dbmodel Classes (Implementation)

The catalog system model only defines the public interface into our catalog system. The actual implementation is in the dbmodel package. The baseline version of the case study uses old-school JDBC with no connection pooling. In a later implementation we use EJB to provide the connection and prepared statement pooling for this application. Fortunately, we will not have to change many of our tests and JSPs, because the public interface to the system will still be the model. The implementation is hidden behind the public interface to the system. See the following figure for the dbmodel class diagram. You can find the complete dbmodel code at the end of this appendix.

Database Schema

The dbmodel classes read data from a database. Again, our example endeavors to be simple, and the database schema certainly reflects this approach (see the following figure and listing). The SQL Data definition language (DDL) for the schema in the following figure is very simple.

 CREATE TABLE CATEGORY (                 ID int PRIMARY KEY,                 DESCRIPTION varchar (100) NOT NULL ,                 NAME varchar (25)  NOT NULL              )             CREATE TABLE SUBCATEGORY (                 ID int PRIMARY KEY,                 FK_CATEGORY_ID int REFERENCES CATEGORY(ID),                 DESCRIPTION varchar (50) NOT NULL ,                 NAME varchar (25)  NOT NULL              )             CREATE TABLE PRODUCT (                 ID int IDENTITY (1, 1) PRIMARY KEY,                 DESCRIPTION varchar (50) NOT NULL ,                 NAME varchar (20)  NOT NULL ,                 FK_SUBCATEGORY_ID int REFERENCES SUBCATEGORY(ID),                 QTY int DEFAULT (5),                 PRICE DECIMAL(10,2) NOT NULL, 

Web Interface

The main Web page for the case study has a side navigation that contains the subcategories . The product listing for the subcategory is in the middle of the page:

The category name and description appear in the center of the page, along with the subcategory name and description. When you click on a product, a product detail page opens:

The Web interface has seven JSP pages, as follows :

• index.jsp

• category.jsp

• subcategory.jsp

• product.jsp

• category_sys.jsp

• header.jsp

• footer.jsp

The names of the JSP pages are somewhat indicative of their functionality. The product.jsp page displays product details. The subcategory.jsp page shows the subcategory details as well as the product listing for that subcategory (see the following figure for a visual representation of the JSP page structure). The code for all the JSPs appears in the listings at the end of this chapter.

The JSPs use the CategorySystem to display the object model of the application. Each page includes header.jsp, which in turn includes category_sys.jsp, which uses jsp:useBean to map in a CategorySystem instance as follows:

 <%@page import="xptoolkit.petstore.model.*" %> <jsp:useBean id="categorySystem" class="CategorySystem" scope="session"/> 

All the JSPs use the categorySystem to create and get objects. For example, here is a partial listing of the Product.jsp page:

 ...      Category category = categorySystem.getCurrentCategory();     Subcategory subcategory = categorySystem.getCurrentSubcategory();     String productId = request.getParameter("id");     Product product = subcategory .getProduct( Integer.parseInt(productId) );     ...     <b><%= product.getName() %></b>         <br>     <%= product.getDescription() %> 

The baseline version of the application just reads data out of the database. Later versions of the application will edit, add, and delete products using an extended categorySystem.

Build System

This section jumps the gun a bit. We explain how the build system is structured, but we have not yet covered Ant and JUnit. The idea is to give you a glimpse of things to come. Please read this section with the realization that the material covered in this section is explained in detail later.

The case study baseline uses five buildfiles:

• main

• model

• webapplication

• test

• setupDB

The main buildfile is located in the root directory of the baseline version (see figure below). The main buildfile orchestrates the execution and deployment of the other buildfiles.

The model buildfile builds and packages the model and dbmodel classes. The end result of the model buildfile is a JAR file (petmodel.jar) that is stored in the lib directory of the output:

The webapplication buildfile compiles and builds the Web application. The end result of the webapplication buildfile is a WAR file (pet.war) that can be deployed to any J2EE compliant servlet/JSP engine such as WebLogic, Resin, Tomcat, or Orion.

The test buildfile packages and builds the test classes (JUnit) and runs the tests. The test results are stored in XML files in the reports directory. Then, the test buildfile transforms the XML into an HTML report (see the next two figures, which show the test results in a browser).

The setupDB buildfile sets up the database schema and populates the database with sample data that is used for testing. This will be covered in detail in the next section.

The main buildfile has seven targets (see figure below). Targets are like actions that are executed. Well explain the concept of a target in depth in Chapter 5, Building Java Applications with Ant. Well explore the nuances of target names in Chapters 5, 6, and others. By the end of those chapters, you will be able to determine what a buildfile does just by looking at the target names.

The main buildfile orchestrates the execution of other targets in the other buildfiles. For example, the main buildfile target test does the following:

 <target name="test" depends="clean,build"              description="build the model and application modules.">         <ant dir="./Test" target="cleanTest">             <property name="outdir" value="${outdir}" />              <property name="setProps" value="true" />         </ant>     </target> 

This code invokes the cleanTest target on the test buildfile. It also causes the clean and build file targets to be executed for main, which in turn call the clean and build targets on the model and webapplication buildfiles. For example, here is the clean target of main that calls the clean target of model and webapplication as follows:

 <target name="clean" depends="init"              description="clean up the output directories.">         <ant dir="./Model" target="clean">             <property name="outdir" value="${outdir}" />              <property name="setProps" value="true" />         </ant>         <ant dir="./WebApplication" target="clean">             <property name="outdir" value="${outdir}" />              <property name="setProps" value="true" />             <property name="ejb" value="true" />         </ant>         <delete dir="${outdir}" />     </target>