Accessing the Customer Class from JSP

I l @ ve RuBoard

Accessing the Customer Class from JSP

Having created your underlying class, you can proceed to hook it up to some JSP pages to actually do something. For the moment, these sections walk you through some bare-bones pages that create and retrieve customers.

To begin, set up a customer-creation page. Before you do, you need to think out your JSP document strategy. You already know that some elements, such as the mini-cart and navigational bars, will appear on most pages. One strategic approach that you can take is to use a single JSP file to control access to all of the site functionality and then have the code dispatch to different subpages inside the main page to display different content depending on the session state. This way, if a user bookmarks the page, he always comes to the entry page (because there will be no session state when the user starts).

For certain types of sites this is an advantage. For example, a site that has a lot of stateful transactions (that is, multistage transactions) might not want a user to bookmark some arbitrary intermediate Web page during the transaction processing.

The disadvantage to this approach is that you can't bookmark a page for a specific product, for example. Sometimes it's actually good to expose state through the URL query string, specifically so that it can be saved or sent to a friend. Also, the all-in-one page approach can lead to a fairly awkward and bloated piece of JSP if you're not careful. Because all the control for the application rests in a single file, it can end up being full of conditional pieces of logic and can become difficult to understand. One alternative is to use an MVC package such as Struts (see Chapter 16, "The Struts Application Framework"), but this approach has its own complexities and perils .

For that reason, and for clarity of demonstration, you'll use a few different JSP files to handle the site functionality.

Beginners to JSP (or to CGI, for that matter) are always taught to do form presentation and handling in two steps: first to display the form and then to handle the submission. The problem with this approach is that when you start dealing with validation and error handling, you find that the second step might need to redisplay the form with error messages, so you end up duplicating the form twice.

The method generally preferred by experienced developers is to create a single page that submits to itself, as you will do throughout this application. One thing to keep in mind with this technique is that you need some kind of state variable that allows you to track whether this is the first display or a subsequent display of the form. You don't want the code to try to validate the submitted data before you have actually filled out the form because it will flag them all as errors: They'll be blank.

The other trick is that if you're populating the form fields with the values provided from the last form submission, these values will be null on the first pass because there are no values to set them to and because the Customer object defaults them to null. To avoid displaying the string null in the form the first time through, you need to set the values to the empty string explicitly.

Listing 8.7 is a simple first pass on a customer-creation page.

Listing 8.7 NewCustomer.jsp
 <%@ page import="com.bfg.customer.Customer" %> <jsp:useBean id="newcust" class="com.bfg.customer.Customer" scope="request"/> <jsp:setProperty name="newcust" property="*"/> <% if (request.getParameter("SUBMITTED") != null) {     try {       newcust.createCustomer();       response.sendRedirect("NewSuccess.jsp");     } catch (com.bfg.exceptions.DuplicateEmailAddressException e) {     } } if (newcust.getEmail() == null) {     newcust.setEmail(""); } if (newcust.getPassword() == null) {     newcust.setPassword(""); } %> <HEAD><TITLE>Create New Customer Account</TITLE></HEAD><BODY> <FORM METHOD=POST ACTION="NewCustomer.jsp"> <INPUT TYPE="HIDDEN" NAME="SUBMITTED" VALUE="T"> e-Mail Address: <INPUT NAME="email" TYPE="TEXT" SIZE=50        VALUE="<%= newcust.getEmail() %>"><BR> Password: <INPUT NAME="password" TYPE="TEXT" SIZE=50        VALUE="<%= newcust.getPassword() %>"><BR> <INPUT TYPE=SUBMIT> </FORM> </BODY> 

The code uses the hidden field SUBMITTED to track whether this is the first time through or whether you're processing a previously displayed form. If it's the first time through, the JSP blanks out the two form field variables ; otherwise , it tries to create a new user and then redirect to the success page. Because a redirect needs to come before any text is sent to the page, you must put all of this control logic above the first HTML in the document.

If the new user creation results in a duplicate entry, the JSP catches the DuplicateEmailAddressException , which results in the redirect being skipped .

I l @ ve RuBoard


MySQL and JSP Web Applications. Data-Driven Programming Using Tomcat and MySQL
MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL
ISBN: 0672323095
EAN: 2147483647
Year: 2002
Pages: 203
Authors: James Turner

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net