C H A P T E R  10

eshop*

In several chapters of this book, I’ve used examples taken from three different versions of an online bookshop application: eshop (see Chapter 3), eshopx (introduced in Chapter 6), and eshopf (the subject of Chapter 8). In this chapter, I’ll complete the description of those applications so that you can use them as models for your own.

All three versions have the same functionality and generate almost identical HTML pages. Their differences are in their implementation. The main difference between the first two versions, eshop and eshopx, is that the JSP code in eshop is in standard JSP syntax, while the code in eshopx is in XML syntax. The third version of the application, eshopf, is quite different from the first two, because I implemented it with JSF. This required me to replace the original servlet with the JSF servlet. Although I used eshopx as a base for developing eshopf, I obviously had to rewrite the user interface almost from scratch.

For your convenience, I have included the code of all three applications in the software package for this chapter. The three folders are identical to those you have already encountered in Chapters 3, 6, and 8.

The eshop Application

In Chapter 3, where I introduced eshop, I described the objects this application deals with (product categories, books, shopping cart, and orders) and the operations the user can perform on those objects. I then described the MVC architecture of eshop. In particular, I listed the methods of the DataManager class (Table 3-1), described the initialization of the servlet (Listing 3-9 and Table 3-2), summarized how the servlet handles incoming requests, and listed the JSP pages (Table 3-3). I also took you through a typical user session.

In Chapter 6, I described the SQL scripts shop_create.sql (Listing 6-1), shop_populate.sql (Listing 6-3) and shop_orders.sql (Listing 6-7), which create the shop database containing categories, books, and orders. I also showed you the code of Category.java (Listing 6-6). Then, I devoted the whole “DB Access in eshop” section to describing how the data manager updates the database via the peer methods (Figure 6-5 and Listings 6-10 to 6-13).

In this chapter, I’ll start by listing all the subfolders and files in the eshop application folder (see Listing 10-1, where the folder names are in bold).

To complete the description of the ShopServlet class, I need to show you how it selects the appropriate JSP page on the basis of the request, thereby fulfilling its role as a controller. Listing 10-2 shows the code of the doPost method (as I mentioned already in Chapter 3, doGet simply executes doPost).

As you can see, doPost obtains the request parameter named action and then uses it to form the correct URL of the JSP page. It then uses the request dispatcher obtained from the servlet context to forward control to the page. If no action parameter exists or if it doesn’t match any of the expected strings, the servlet will execute the default page (/jsp/index.jsp).

To cover the eshop functionality in detail, I’ll show you what happens in a typical user session, as I already did in Chapter 3. This time, though, instead of showing it from the point of view of the user, I’ll look at the behavior of the application on the server. The architecture of eshop is consistent with the general MVC architecture shown in Figure 3-2.

What Happens When the Application Starts

The user starts the application by typing http://localhost:8080/eshop/shop/ in his or her browser. The doGet method of ShopServlet is executed, and that simply executes doPost. The doPost method, as I just explained, doesn't find a request parameter named action, so it forwards the request to index.jsp.

The index.jsp page, like all other pages of eshop, displays a header with a link to the shopping cart and a menu on the left-hand side with search and selection controls (see Figure 10-1). It does so by including two separate modules, as follows:

Figure 10-1. E-shop’s home page

The central area of the page only displays the text welcome to e-Shop.

The TopMenu.jsp module is trivial. Essentially, it consists of the following element:

where the two variables are obtained from the application scope

The action parameter set to showCart causes ShopServlet to forward the request to /jsp/ShoppingCart.jsp.

The LeftMenu.jsp module has to do more. It displays a search field and a list of selectable book categories. The code to accept a search request is as follows:

Notice the presence of the hidden parameter named action with the value "search", which causes ShopServlet to forward the request to /jsp/SearchOutcome.jsp when the user clicks on the Search button to perform a book search.

Here’s the code that lists the book categories:

The DataManager method getCategories only executes another method of the data model

that interrogates the database to obtain identifiers and names of the available categories (see Listing 10-3).

I’ve highlighted the lines that do all the work: first, the database query is performed, and then the result is saved in a hash table in which the key is the category ID and the value is the category name.

LeftMenu.jsp uses the content of the hash table to generate one link for each category with the statement:

as shown in the following example for action novels:

Notice that the action parameter is set to selectCatalog. This is done for all categories and causes ShopServlet to forward the request to /jsp/SelectCatalog.jsp when the user clicks on a category name.

As you can see from the code of CategoryPeer.java, I took great care to ensure that the database connection is closed before the method returns. Also notice that I logged a message to the standard output (mapped by Tomcat to the file stdout_yyyymmdd.log) if the database access fails. In a real-world application, you should throw an exception with an error message that you can then display to the user.

Handling Requests for Book Selection and Book Search

As you saw in the previous section, when the user selects a book category or performs a search, the pages displayed are SelectCatalog.jsp and SearchOutcome.jsp, respectively. Both pages display a list of books and are similar to each other. Actually, they are so alike that I merged them into a single page in the JSF version of the application, eshopf, as you’ll see later in this chapter. Figure 10-2 shows the list you will see when you search for the letter F (or f, as the searches are case insensitive), while Figure 10-3 shows the list of books in the category Action Novels.

Figure 10-2. Titles and author names containing an F

Figure 10-3. Action Novels

In SelectCatalog.jsp, the requested category is specified by the id parameter. To obtain the category name, you execute the DataManager method getCategoryName

and this loads the category record from the database via the corresponding peer method.

In SearchOutcome.jsp, the search string is in the keyword parameter.

To obtain the list of books, SelectCatalog.jsp executes the following statement in a scriptlet:

while SearchOutcome.jsp executes the statement:

For each book in the list, both pages generate a link such as the following one:

With the action parameter set to bookDetails, ShopServlet forwards the request to BookDetails.jsp.

Displaying the Book Details

By now, the mechanism should be pretty clear: each JSP page passes its key request parameter to a DataManager method that encapsulates the business logic. This is how the view and the model of the MVC architecture are kept separate, making it possible for the web-page designers and the software developers to work independently. One creates visually appealing and clear pages, and the other handles the databases. The signatures of the data model methods are the only interface needed between page designers and software developers.

BookDetails.jsp passes the bookId request parameter to the DataManager method getBookDetails:

and the BookPeer method getBookById gets the corresponding book record from the database.

To buy the book (see Figure 10-4), the user then clicks on a link that looks like this in HTML:

With the action parameter set to addItem, ShopServlet forwards the request to ShoppingCart.jsp.

Figure 10-4. Buying a book

Managing the Shopping Cart

The application displays the shopping cart (see Figure 10.5) not only when the user clicks on the Add to Cart link while viewing the book details but also when the user clicks on the shopping cart link in the header of any page. The difference is that in the first case, the action parameter passed to ShoppingCart.jsp has the value addItem, while in the second case the value is showCart.

Figure 10-5. The shopping cart

The shopping cart itself is an object of type Hashtable<String, String> stored as a session attribute. Note that the scope of the attribute must be session, because the shopping cart must be available across multiple HTTP requests. The hashtable key is the book ID, while the value is an object of type CartItem. The CartItem class has no methods except the getters and setters for the author, title, price, bookID, and quantity properties.

It’s appropriate to save the book price in the shopping cart, because the user should pay the price shown in the book details when he or she clicks on Add to Cart, even if the book price stored in the database is then changed before the order is completed.

For each shopping cart item, ShoppingCart.jsp displays the quantity of books in an input field and adds the Update and Delete buttons enclosed in separate forms. This makes it possible for the user to modify the number of copies ordered or to remove an item altogether. Here’s an example of an update form:

and here’s an example a delete form:

When the user clicks on one of the buttons, ShopServlet forwards the request back to ShoppingCart.jsp.

Before displaying the content of the cart, ShoppingCart.jsp needs to do some work that depends on the value of the action parameter (see Table 10-1).

To handle addItem, ShoppingCart.jsp obtains the book details from the data manager via the getBookDetails method and creates a new CartItem object, which it then adds to the cart. To handle updateItem, ShoppingCart.jsp uses the setQuantity method to update the quantity in the cart item identified by bookId. To handle deleteItem, ShoppingCart.jsp simply removes the cart item identified by bookId from the cart.

After listing the cart content, ShoppingCart.jsp displays this link:

With the action parameter set to checkOut, ShopServlet forwards the request to Checkout.jsp.

Accepting an Order

Checkout.jsp asks the user to provide his or her personal and financial data (see Figure 10-6).

Figure 10-6. Checking out

When the user clicks on the Confirm Order button, the hidden action parameter is set to orderConfirmation, which causes ShopServlet to forward the request to OrderConfirmation.jsp. In real life, you should implement validation on as many fields as possible.

To perform validation of the user’s inputs, you have to decide what fields to validate, whether the validation should take place on the client or on the server (or on both), whether to check the fields one by one or all together, and what technique to use.

There are some fields that you cannot really validate (e.g., the contact name). Others might not be critical enough to warrant the effort you would need to spend in order to implement validation. For example, to check the delivery address provided via a simple form like that of Figure 10-6, you could parse the field, extract the country, if present, the ZIP/post code, and check whether they are consistent. To minimize the risk of input errors, it would make more sense to break down the address into several fields and give a multiple choice of countries and, depending on the chosen country, on ZIP codes. This would involve quite a bit of work, and the lists would have to be kept up to date, for example, by downloading them from an online service. All in all, you might decide to forego such complex checks. That said, it is not uncommon for web sites to check that the format of the ZIP code is consistent with the country.

In general, how far you go with validation is something you need to decide on a case-by-case basis.

Concerning the question of whether to validate on the server or on the client, my advice is to always validate on the server. This is mainly because a user could manage to work around validation done on the client with unknown consequences. The fact that validation on the client provides immediate feedback to the user might encourage you to do both types of validation. On the other hand, in order to do so, you effectively duplicate the same checks in JavaScript on the client and in your application on the server.

Ajax, which you learned in Chapter 7, relies on checks done on the server; but because it relies on transferring a minimum amount of data in both directions, Ajax also provides a quick turnaround.

With the check-out form of Figure 10-6, I would make sure the user has typed something in all fields and that the values of the credit-card number and expiry date are plausible. The best time to do checks on an individual field is when the value of the corresponding HTML element changes: that is, when the user modifies the value of a field and then clicks outside it.

As a warm-up exercise, let’s see how you can easily check that the user has typed something into all fields of the form when he or she clicks on Confirm Order. For this check, you can use a straight JavaScript function, like that shown in Listing 10-4.

As you can see, it is pretty straightforward: you check in a loop all fields of the form named frm and display an alert with the name of the first element you find to be empty. You will find nonemptyForm.js in the folder eshop project of the software package for this chapter. To use it, you need to copy it to the folder eshopjsp and change the file eshopjspCheckout.jsp in two places.

The first change is necessary to load the JavaScript file. All you need to do is insert the line

immediately before the form element.

The second change links the validation function to the form’s submit button. You do it by adding the two attributes id and onsubmit to the form element, as in:

Figure 10-7 shows what happens when you leave a field empty and hit the Confirm Order button.

Figure 10-7. Empty-form check with JavaScript

To validate all fields individually, you need to associate a checking function to each input field in Checkout.jsp you want to validate. Let’s do it entirely on the client side first. Listing 10-5 shows the modified Checkout.jsp, with the added or updated lines in bold. You will find the file immediately inside the eshop project folder. Later, we will move validation to the server using Ajax.

What could be simpler than that? Let’s look together at validForm.js (Listing 10-6).

The function validateForm is an extension of the function with the same name defined in nonemptyForm.js (Listing 10-4). The only difference is that before ensuring all fields contain something, it checks whether the two flags numberOk and expiryOk are true. If not, it reports an error and returns false, so that the form is not submitted.

The two flags are set respectively in the two functions valNumber and valExpiry. The function valNumber accepts as valid credit-card numbers all strings that contain either 15 or 16 numeric digits plus any number of spaces. valExpiry only accepts as valid expiry dates strings in the format MM/YY plus, again, any number of spaces.

To try out the validation, replace the version of Checkout.jsp originally in the eshopjsp folder with the modified one, and copy validForm.js to the same eshopjsp folder. Figure 10-8 shows an example of an invalid expiry date.

Figure 10-8. Individual field validation with JavaScript

Before we move the validation of credit-card number and expiry date to the server, we need to take a few things into consideration.

The first ‘A’ of Ajax stands for “Asynchronous.” Although you can actually use it in synchronous mode, if you do so, your page might hang while waiting for the server to respond. However, if you use it asynchronously, it is possible the user could attempt to submit the form before the validation responses from the server arrive. This should be avoided because what’s the point of asking for validation if you don’t wait for the reply? It would result in the server receiving non-validated (and therefore possibly invalid) field values.

The simplest way to wait for Ajax to complete its dialogs with the server is to block the submit button until all validations have been completed and let the user know why he or she cannot submit the page. You could also keep the submit button disabled (i.e., grayed out) until Ajax has done its job. You could also add disabled check boxes beside the fields being validated, which your JavaScript code ticks when the corresponding validation has been done successfully. I favor the minimalist approach: unless you are forced to address the user, you keep quiet. This makes for cleaner pages and simpler coding. In most cases, by the time the user clicks on the submit button, Ajax will have done its job, and the user will remain unaware of what has been going on behind the scene.

If you look at validForm.js (Listing 10-6), you will see that we can use for this purpose the two variables numberOk and expiryOk. All we need to do is set them to a special value while the client is waiting for the server to respond. Then we can extend the check of the two flags in validateForm, so that if necessary we can ask the user to wait.

To avoid confusion, I made a copy of validForm.js, which I then renamed validFormAjax.js. To use it, after copying it to eshopjsp, you will only need to change in Checkout.jsp the script element to load validFormAjax.js instead of validForm.js. During my tests, I also changed the title of Checkout.jsp, from “Check Out (with client validation)” to “Check Out (with server validation),” but it is not necessary for you to do so. To have validation with Ajax working, you will also need to copy to the eshopjsp folder the two files ccNumber.jsp and ccExpiry.jsp, which perform the validation on the server. More about that later.

Listing 10-7 shows validFormAjax.js.

As you can see, the two functions valNumber and valExpiry no longer contain any check of the input fields. Instead, they have become very similar to the function ajaxFun contained in the file ajax.js of Chapter 7 (Listing 7-16).

If you look at the handling of the credit-card number, you will see that numberOk is now initialized to an empty string and set to "waiting" immediately inside the valNumber function. valNumber uses Ajax to execute the JSP page ccNumber.jsp, which accepts the value entered by the user as the input parameter named v. The response received from the server is stored directly into numberOk.

As you will see in a moment, the validating page ccNumber.jsp returns an empty response when the validation is successful, or an error message describing the error.

valExpiry is almost identical to valNumber, and validateForm is pretty self-explanatory.

The two validating JSP pages are shown in Listings 10-8 and 10-9. They contain the Java implementation of the checks that used to be in the JavaScript functions valNumber and valExpiry when they didn’t use Ajax.

Figure 10-9 shows an example of eshop with the validation done on the server.

Figure 10-9. Waiting for the server to respond

To see the “waiting” alert, “touch” ccExpiry.jsp (e.g., insert a space anywhere, remove it, and save the file) and then, after typing something in the expiry-date field, click on Confirm Order before doing anything else. The little time needed by Tomcat to recompile the JSP page will be enough to make validFormAjax.js display the alert.

Providing the Payment Details

In this skeleton implementation of eshop, OrderConfirmation.jsp only saves the order in the database. In a real-world situation, it should perform a series of checks, including verifying with a bank that the credit card is valid and not blocked.

All the work to store the order in the database is done in the DataManager method insertOrder, which I’ve already discussed in Chapter 6.

The eshopx Application

After completing eshop, I showed you how to create the eshopx application by replacing the JSP pages with JSP documents (i.e., modules in XML syntax). This required us to move scriptlet code to JSP custom tags.

Listing 10-10 shows the annotated list of files and folders that constitute eshopx.

As you can see, I only changed the view part of the application (i.e., the JSP modules), while I didn’t need to touch the controller and the model (i.e., the servlet, the beans, the peer classes, and the data manager). This confirms the advantage of implementing an MVC architecture.

As I already mentioned, the views of eshop and eshopx differ in the implementation but are functionally identical.

Style Sheet

I replaced the shop.css file used in eshop with shop.jspx. Listing 10-11 shows the differences between the two files.

As you can see, I only wrapped shop.css inside a jsp:text element and changed three lines. If you look at the original lines, it should become clear why I did it:

The string "/eshop/images" of shop.css has become "${imgUrl}" in shop.jspx, and if you look at the beginning of shop.jspx, you’ll notice that the variable imgUrl is set as follows:

The advantage of doing it with the EL expression is that c:url takes care of adding the application folder (i.e., /eshop) before the relative URL /images. This makes it possible to deploy the application in any folder. You should try to avoid hard-coding paths.

Obviously, you need to change the way in which the style sheet is loaded in the JSP modules. In eshop, with shop.css, you needed to include the following line in the <head> element:

In eshopx, with shop.jspx, you need to write the line

and then include the following line in the <head>:

By doing so, you remove the hard-coded /eshop path from all JSP modules, which is a good thing to do.

web.xml

When moving from eshop to eshopx, I needed to modify in web.xml the definitions of two parameters: base and imageURL. The definition of base changed from /eshop/shop to /shop, because in eshop, I used base as follows:

while in eshopx, I first define the page attribute myURL as

and then use the attribute to make the link, as follows:

As I said when talking about the style sheet, c:url accepts in the value attribute URLs relative to the application folder and then completes them to make them relative to the server root. Within eshop, you had to include the application folder in base, because you didn’t form the URL with c:url.

The definition of imageURL changed from /eshop/images/ to /images/ because I used imageURL in eshop as follows:

while in eshopx, I first define the page attribute imgURL:

and then use the attribute in the img element:

Thanks to these two changes, I could remove all hard-coded references to the application directory in eshopx.

But these small changes in the handling of the images cause a problem in the welcome page of the application.

Perhaps you will recall that in Chapter 4, when talking about c:url, I mentioned that Tomcat attaches a jsessionid string to a URL before sending it to the client in the response.

Tomcat does it when it opens a new session, to handle clients that don’t accept cookies. When Tomcat receives subsequent requests from the same client and they contain the session cookie, it stops appending the session ID string to the URLs, because it knows that it is unnecessary.

Now, the welcome page (index.jspx) includes TopMenu.jspx, which contains the two lines

to display the image of the shopping cart.

When you view http://localhost:8080/eshopx/shop the first time, Tomcat creates a session and then systematically attaches the jsessionid string to all URLs. This means that the value of the src attribute of the img tag becomes something like this:

As a result, when the client browser requests the image of the cart, Tomcat cannot find it, and the shopping cart cannot be displayed. At best, with some browsers, you get a “broken image” icon. All subsequent pages, including a reloaded welcome page, unless you disable the cookies in your browser, are OK.

Fortunately, Servlet 3.0 lets you switch off the appending of the session ID. All you need to do is add in the body of web-app the following element:

It tells Tomcat to use the cookie (and nothing else) to track the session. By default, the session-config element contains both the COOKIE and the URL tracking modes.

With this change, everything works fine, although it makes the acceptance of cookies compulsory for the users.

At the time of writing, Eclipse doesn’t recognize the tracking-mode element and reports an error, as shown in Figures 10-10 and 10-11. This doesn’t affect the normal working of the application.

Figure 10-10. Eclipse reports an error in web.xml

Figure 10-11. Eclipse’s description of the web.xml error

JSP Documents

To explain how I converted the JSP pages of eshop (with extension jsp) to the corresponding JSP documents of eshopx (with extension jspx), I’ll go through one example in detail.

Listing 10-12 shows OrderConfirmation.jsp. I choose it because it is one of the simplest modules.

When converting to the XML syntax, you first need to replace the first 11 lines of the JSP page with those shown in Listing 10-13.

In XML format, you no longer need to declare the Java classes, but you need to declare the namespaces of JSP, the JSTL core, and the custom library. The page directive becomes a jsp:directive.page element. Also, notice that the style sheet is loaded as I explained in a previous section.

Lines 12–18 of OrderConfirmation.jsp remain practically the same, the only difference being that now the two modules have the extension jspx. The last three lines (37–39) also remain the same. You only have to append the end tag of jsp:root.

The major changes take place in lines 19–36. They are replaced by the code shown in Listing 10-14.

Line 31 of OrderConfirmation.jspx is the XML equivalent of lines 20–25 plus line 32 of OrderConfirmation.jsp. Notice that in eshop, the order ID is returned by the insertOrder method and stored in the scripting variable orderID, while in eshopx, the order ID is stored into the EL variable orderID directly by the custom tag eshop:insertOrder.

The if/else of lines 24 and 33 in the JSP code is replaced in the JSPX code by the elements c:choose/c:when/c:otherwise of lines 32–33 and 39. As I said on other occasions, you cannot use c:if because a c:else doesn’t exist.

To complete the picture, let’s look at Listing 10-15, which shows the doEndTag method of InsertOrderTag.java.

Not surprisingly, here you find (highlighted in bold) the code originally in lines 20–25 of OrderConfirmation.jsp that executes the dataManager method insertOrder and terminates the user session if the insertion succeeds.

On the basis of this example, you should now be able to figure out how to convert the other modules. In the next section, you’ll find additional information concerning the eshop custom tag library.

Custom Tags and TLD

EL expressions can include bean properties. This means that they can invoke “getter” methods. What they cannot do is invoke methods that require input parameters. You can work around that difficulty by setting an attribute with c:set and picking it up in a bean method.

For example, in SelectCatalog.jspx, the request parameter id specifies a book category, and you need to know the category name. This operation requires a database search, which you can implement with the following custom tag:

It accepts the ID as an input and sets the variable cat to the category name. The doEndTag method of CategoryNameTag.java is simple:

The getCategoryName method of the data manager (invoked exclusively by the doEntTag method of CategoryNameTag.java) is even simpler:

Instead of defining the custom tag, you could add the categoryID property to the data manager

and remove its input parameter from the getCategoryName method.

Then, in SelectCatalog.jspx, you could replace the eshop:categoryName element with jsp:setProperty to set the categoryID in the data manager and c:setVar to invoke the getCategoryName method:

The result would be the same. I didn’t do it in that way because it makes the code less “transparent,” but it is ultimately a matter of taste. I just want to make the point that you can replace the input parameters of bean methods by setting bean properties with jsp:setProperty. Then, you only need to name the getter methods appropriately (e.g., getWhatever), and you’ll be able to execute them with an expression such as ${myBean.whatever}.

In any case, I introduced a total of ten tags, as listed in Table 10-2.

Listing 10-16 shows an example of a TLD tag element.

The eshopf Application

Although I used eshopx as a basis for the JSF version of the application, its architecture is quite different from that of the first two versions. This is partly due to the fact that I had to replace ShopServlet with the standard FacesServlet class. In the process, I also removed the custom tags I had introduced in eshopx. In this section, I’ll refer to the eshopf application as described in Chapter 8 after the addition of a custom converter, a custom validator, and a custom component with a separate renderer.

Listing 10-17 shows the annotated list of files and folders that constitute eshopf. The folders marked “= eshopx” have the same content as the corresponding folders of eshopx (not of the original eshop); the modules marked “rewritten” are completely different from the previous versions; and those marked “~ eshop” are those obtained by updating the corresponding modules in eshop.

In fact, I described almost everything in Chapter 8. In this chapter, I’ll systematically go through the changes I made to eshopx to transform it into eshopf.

web.xml and context.xml

In eshopx, I defined ShopServlet.java to implement the controller part of the MVC architecture. In eshopf, this function is performed by the standard FacesServlet. As a result, I had to rewrite most of web.xml. In particular, I replaced the servlet element used in the web.xml version of eshopx

with this:

I also changed the body of servlet-mapping from this:

to this:

In eshopx, to access the database containing books, book categories, and orders, I defined the initialization parameters jdbcDriver, dbURL, dbUserName, and dbPassword. They were used in ShopServlet to set up an object of type DataManager, which implemented the model part of the MVC architecture and interfaced to the database. The replacement of ShopServlet with FacesServlet forced me to implement a different mechanism in eshopf for passing the database parameters to the data manager.

I defined the database as a resource external to the application by creating the context.xml file in the META-INF folder with the following content:

I then registered the resource in the web.xml file as follows:

Note that with this mechanism, you effectively pool the connections to the database, thereby achieving a more efficient use of resources. I leave up to you to retrofit eshopx with this mechanism. To complete the conversion from eshopx to eshopf, I also removed the definition of the initialization parameters base and imageURL from web.xml, because they were no longer needed, and I added the element to direct Tomcat to perform the basic authentication needed to access the database resource. Listing 8-8 shows the full web.xml file of eshopf.

Style Sheet

CSS lets you define new styles by adding attributes to already defined styles. This “cascading” mechanism is a form of inheritance, and therefore it requires an underlying hierarchical structure. CSS uses the structure provided by HTML documents instead of creating its own. This is fine as long as you write the HTML code yourself or generate it with JSP. When you use JSF, though, the control you have on the generated HTML is reduced. As a result, you have to pay greater attention when designing the style sheets.

When converting eshopx to eshopf, I encountered this issue in several places and had to modify the style-sheet file accordingly.

For example, in eshopxcsseshop.jspx, I first defined .box (lines 130–133)

and then extended it to define .box p (lines 134–139)

I know, I didn’t need to repeat margin:0px, but these things happen when you cut and paste!

In any case, LeftMenu.jspx uses the two styles as follows:

In eshopf, I replaced the HTML p element with a h:outputText component, which generates an HTML span element, not a p. Therefore, if I had left the style sheet unchanged, the .box p style wouldn’t have had any effect, and the search box would have been rendered as shown in Figure 10-12.

Figure 10-12. Wrong style in the search box

Not nice.

To resolve the issue, I defined in eshopfcsseshopf.jspx the new style .box_p as follows (lines 153–159):

By writing in eshopfjspLeftMenu.jspx the code

I could generate the following HTML output:

Figure 10-13. Correctly styled search box

In case you are wondering, the effect of display:block is to insert a new line before and after and take up the full width available. You will find that I applied it a few times in the style sheet for eshopf to ensure that the generated page looked as similar as possible to the corresponding page of eshopx (and eshop).

As a last remark about styles, I would like to point out that I could have “salvaged” the inheritance from h:panelGroup to h:outputText by renaming the .box p style of eshopx.jspx to .box .p, and then writing the h:outputText component as follows:

This would have worked because the span element it generates is enclosed inside the span element generated by h:panelGroup. I would have still needed to add the display:block style, however. There are often several ways to achieve the same result, and sometimes it is just a matter of what comes to mind first.

This issue concerning style sheets is a disadvantage of using JSF, but it becomes less and less important as you become familiar with the HTML code that JSF generates. Furthermore, you’ll normally start developing directly with JSF. When converting eshopx into eshopf, I was dealing with an existing user interface that I wanted to alter as little as possible.

JSP Documents

I had to modify all JSP documents. This shouldn’t be a surprise, considering that the JSP documents generate the HTML pages that the user sees in his or her web browser. In Chapter 8, I described all the JSF components you need for eshopf. Therefore, it wouldn’t make much sense to do it again here. In this section, I’ll only tell you how JSF allows you to merge two separate JSP documents of eshopx (SelectCatalog.jspx and SearchOutcome.jspx) into a single document of eshopf (ListBooks.jspx).

The two modules were already very similar in eshopx. Without considering page titles, text headers, and error messages, the differences boiled down to less than a handful of lines. In SearchOutcome.jspx, I was using the custom tag eshop:searchResults, while in SelectCatalog.jspx, I was first obtaining the category name with eshop:categoryName and then the list of books with eshop:booksInCategory.

After converting the two modules to use JSF, the list of books in both cases was obtained from a property of shopManager: when the user performed a search via the search field of LeftMenu.jspx, the method that filled in the list of books in shopManager was searchBooks, and when the user selected a category, the method was selectCategory.

The only difference left between the two modules was in a couple of messages. To make the merging possible, I added the categoryName property to shopManager and reset it to null within the searchBooks method. In this way, I could use the name of the category as a flag, because it would be null after a search and non-null after a category selection.

Perhaps I could have also merged the JSP documents in eshopx, but it would have required some “awkward” coding, while it works out quite naturally with JSF.

Java Modules

One major change I made was to replace the custom tags defined in eshopx with the eshop.beans.ShopManager class. I did this to take advantage of JSF.

For example, to update the number of copies of a book in eshopx, you use the custom tag UpdateBook. Listing 10-18 shows the code to implement the tag.

In eshopf, the following JSF component of ShoppingCart.jspx takes care of updating the number of copies:

As a result, when you trigger an update by pressing the corresponding button

there’s nothing left for the updateItem method of the shop manager to do:

Another example is the RoundToCent tag, which rounds amounts in dollars to two decimal places in eshopx. This is necessary because sometimes the result of multiplying the price of a book by the ordered quantity results in a sequence of '9's after the decimal point. Here is an example of its usage taken from ShoppingCart.jspx:

In eshopf, I introduced the subtotal attribute to the CartItem bean and added the functionality to recalculate it and round it to two decimals after every shopping cart update. This is the only update I made to the four eshop.beans modules.

Of the eshop.model modules, I only needed to modify CategoryPeer.java and DataManager.java. In CategoryPeer.java, I changed the getAllCategories method to return a list of categories instead of an object of type java.util.Hashtable. I then changed the getCategories methods in DataManager.java and ShopManager.java accordingly. This allowed me to display the list of categories in LeftMenu.jspx with the following JSF element without having to do any type conversion:

In DataManager, besides the change to the getCategories method that I’ve already discussed and the removal of the getCatIDs method that was no longer needed, I only updated the algorithm used in the getConnection method to open a database connection. This was necessary because I had replaced the database initialization parameters of eshopx with a JNDI resource.

In eshopx, DataManager opened a database connection by invoking the static getConnection method of the java.sql.DriverManager class:

The dbURL, dbUserName, and dbPassword attributes were set by ShopServlet using the servlet initialization parameters. In eshopf, the code to obtain a database connection is as follows:

Finally, I added Java modules to implement a custom JSF component, a converter, a renderer, and a validator. Please refer to the corresponding sections of Chapter 8 for their description.

Summary

In this chapter, I completed the description of the various versions of the online bookshop example and explained what I had to do in order to convert standard JSP syntax to XML syntax and then to use JSF.

This chapter completes the main body of the book. After the first introductory chapter, I took you through five chapters about JSP, application architectures, JSP actions, XML, and databases, followed by two chapters about JSF and one about Tomcat.

Next, two appendixes will help you in two areas that, although not part of the core technologies explained in this book, are essential to develop web applications. Appendix A will talk about HTML and its associated technologies, like JavaScript and CSS, while Appendix B will provide a quick reference of SQL. The third appendix will list all the abbreviations you have encountered in the book.

What more is there to say?

I hope that you’ll find this book useful. Perhaps, in a few areas I could have gone a bit deeper or provided additional examples, but a lot of ground had to be covered in a limited space.

I wish you all the best. Happy programming!