E-bookshop’s Structure

Now, create a new dynamic web project. Its name is “ebookshop”, and in the next dialog window, type “ebookshopWEB-INFclasses” as default output folder. When the next dialog comes up, associate the same name of configuration “context root” to “context directory”, that is, “ebookshop”.

Note that in this passage the creation of web.xml is checked. The automatic creation of the deployment descriptor is deprecated because the descriptor is no longer necessary for the latest applications (Servlet 3.X). The issue is related to the ability of working with “legacy” applications developed with Servlet 2.X.

Now, we create a new Servlet! You can just go to the File menu ➤ New ➤ Servlet.

Then, you can define the package ebookshop.Servlet (it is possible to insert different folders). Call the Servlet ShoppingServlet (conventionally Class and Servlet names are capitalized) as shown in Figure 3-3.

Finally, it is important to check the methods init and destroy in a Servlet.

A little tip: if you want to indent file, select everything with Ctrl+A and then type Ctrl+I.

Now, you can copy the Servlet code or overwrite the file in the folder. I leave to you the choice.

Now, create a Java Class. To create a new class, right-click the ebookshop project and select “New ➤ Class” and give the name MyLog and package myclasses, as shown in Figure 3-4.

At last, refresh the project (position the cursor on the ebookshop project folder shown in the Project Explorer ➤, right-click, and select Refresh).

To get the application to work, you first need to compile it: it is simple with Eclipse, more than from the command line with javac! Build is automatic, but you can also use the clean option to refresh the project build (from main menu select project ➤, clean and select the ebookshop project).

After deploying the project (Run on Server), you can now open a browser and type http://localhost:8080/ebookshop/; you should see the application’s home page. If you want to export the project, use the WAR file; that is the best way to deploy your applications to more than one server: copy them into webapps, and Tomcat will do the rest for you. What could be easier than that?

Figure 3-5 shows the E-bookshop’s home page, which you see when you type http://localhost:8080/ebookshop in your browser’s address field.

You can select a book by clicking the drop-down list, as shown in Figure 3-5, type in the number of copies you need, and then click the Add to Cart button. Every time you do so, the content of your shopping cart appears at the bottom of the window, as shown in Figure 3-6.

You can remove an item from the shopping cart or go to the checkout. If you add additional copies of a book to the cart, the quantity in the cart increases accordingly.

If you click the Checkout button , you’ll see the page shown in Figure 3-7.

If you click the Buy more! link, you’ll go back to the home page with an empty shopping cart, ready for more shopping.

The E-bookshop Home Page

First, index.jsp (as shown in Scriptlet 1) checks whether the list of books to be sold is available, and if it isn’t, it passes the control to the servlet, which then must initialize the book list. In a real online bookshop, the book list would be very long and kept in a database. Note that JSP doesn’t need to know where the list is kept. This is the first hint at the fact that application logic and presentation are separate. You’ll see later how the servlet fills in the book list and returns control to index.jsp. For now, let’s proceed with the analysis of the home page.

If Scriptlet 1 discovers that the book list exists, it copies it into the select control one by one (as shown in Scriptlet 2). Notice how JSP simply creates each option by writing to the out stream. When the buyer clicks the Add to Cart button after selecting a title and possibly changing the number of copies, the home page posts a request to the eshop servlet with the hidden parameter do_this set to add. Once more, the servlet takes care of updating or creating the shopping cart by instantiating the class Book for each new book added to the cart. This is application logic, not presentation of information.

Scriptlet 3 checks whether a shopping cart exists. index.jsp, being completely data-driven, doesn’t remember what has happened before, so it runs every time from the beginning. Therefore, it checks for the presence of a shopping cart even when the buyer sees the book list for the very first time.

Scriptlet 4 displays the items in the shopping cart, each one with its own form. If the buyer decides to delete an entry, index.jsp sends a request to the servlet with the hidden parameter do_this set to remove.

The sole purpose of the last two scriptlets is to close the curly brackets of ifs and fors. However, notice that the form to ask the servlet to do the checkout is only displayed to the buyer when the shopping cart isn’t empty. This is possible because Tomcat, when converting a JSP page into a Java servlet, processes all scriptlets together, without expecting each one of them individually to contain a complete block of code. HTML elements can then be enclosed within a Java block statement spanning two scriptlets.

If the buyer clicks the Checkout button, index.jsp will send a request to the servlet with the hidden parameter do_this set to checkout.

Finally, notice the use of the expression elements <%=i%>, <%=aBook.getTitle()%>, <%=aBook.getPrice()%>, and <%=aBook.getQuantity()%>. The first expression, <%=i%>, is the position of the book within the shopping cart. The other three are the execution of methods of an object of type Book, which the servlet instantiated for each new book added to the cart.

You’ve probably noticed that the address shown in the browser is http://localhost:8080/ebookshop/eshop. This is actually the address of the Java servlet that controls the application.

The E-bookshop Servlet

As you can see, the init() method only executes the standard servlet initialization, and the doGet() method simply executes doPost(), where all the work is done. If you were to remove the doGet() method, you would effectively forbid the direct call of the servlet. That is, if you typed http://localhost:8080/ebookshop/eshop in your browser, you would receive an error message that says the requested resource isn’t available. As it is, you can type the URL with or without trailing eshop.

The highlighted line shows that I suppressed a warning. Normally, a warning tells you that something might be wrong. Therefore, it is not good to have spurious warnings, because they might distract you from noticing warnings you should fix. The use of @suppressWarnings is in general bad practice and encourages you to use a sloppy programming style. In this particular case, the compiler complained about the typecasting of a generic Object to a Vector, but I knew that the attribute ebookshop.cart was of type Vector<book>.

More on E-bookshop

Checkout.jsp displays the shopping cart and the totals precalculated by the servlet, and it invalidates the session so that a new empty shopping cart will be created if the application is restarted from the same browser window.

Note that you could have included the checkout logic in index.jsp and made its execution dependent on the presence of the two totals. However, I wanted to show you a more structured application. It’s also better design to keep different functions in different JSP modules. In fact, I could have also kept the shopping cart in a separate JSP file. In real life, I would have certainly done so. In addition, I would have saved the styles in a Cascading Style Sheets (CSS) file rather than repeating them in all JSP sources. Finally, there is close to no error checking and reporting. You could easily crash this application. In a real case, you would add an error page as explained in the previous chapter.

Neat, isn’t it?

You now have in your hands the full code of a nontrivial Java/JSP application, but you still need to know how to make these four modules work together.