Damian Fauth wrote:
> "Craig R. McClanahan" wrote:
> >
> > The general organization of request processing in my apps goes like this:
>
> [..]
>
> > What I normally do is use a single servlet per web application, and then map it to
> > a filename extension (I like ".go" because it implies motion). Now, if I submit a
> > form to URL "/saveCustomer.go", my controller servlet is called. It can parse
> > "saveCustomer" out of the request URI and use it as the key to a lookup table
> > containing the Java class of the corresponding implementation class (all
> > configured in initialization properties -- no hard coding). The first time I call
> > a particular action procedure, I instantiate a new instance of that action class.
> > After that, I resuse the same one over again (which must be thread-safe, for
> > obvious reasons).
>
> Using this approach, how do you determine which page to display next?
> Using your example above, would you then use
> getRequestDispatcher("/saveCustomer.jsp").forward(request,response)?
>
I have used two different techniques. In my early crack at this, the name of the
normal display page (see below for error handling) was hard coded in the action
procedure. In other words, the action procedure for saving a customer "knows" (because
I designed the UI that way) that the next page is a customer list, so it forwards to
"/customerList.jsp".
More recently, I've adopted a trick that was used in the J2EE example application from
Sun. In your configuration parameters for the controller servlet, give each possible
destination screen a logical name (such as "Display Customer List"), mapped to an
actual JSP name ("/customerList.jsp" for the above case). Now, I can rearrange my JSP
URLs without having to recompile the action classes. All I need to do is change my
initialization parameters for the logical-to-physical mapping.
In all cases, I do use RequestDispatcher.forward() at the end of my action procedure --
the action procedure knows it's being invoked in a servlet-based environment (because
it was passed a reference to the controller servlet itself, plus the HttpServletRequest
and HttpServletResponse), so it can do anything you can do in the doGet() or doPost()
method. As you'll see below, none of the logic utilized by the action procedure knows
that it is being called from a servlet, so that code can be reused in other apps as
well.
>
> How do you handle business-logic type errors that require the user to
> correct their form input? Presumably these would be detected in your
> Action class - can put some sort of ErrorBean into the request and
> forward() back to the referring page?
>
Here is where the elegance of this architecture really shows up. Let's go back and add
a couple more details:
* In my Edit Customer display screen (with the submit that goes
to "/customerSave.go"), the data values for all the fields are
defaulted from a CustomerBean that was added to my session
by some previous processing, such as the logic that selected the
customer I wanted to edit.
* When I am filling out the form, the visual appearance is that it
shows all the info about the current customer.
* I submit to the control servlet, which goes to the action
procedure for saving a customer. It does the following:
* Updates the CustomerBean properties to reflect
the stuff I just entered.
* Validate the properties of CustomerBean to make
sure everything passes all the business rules about
what makes a correct customer.
* If there was an error, a new request bean is added
(containing the text of the error mesage to display)
and control forwards to the Edit Customer display
screen again. This page now displays the most recent
values I have entered -- plus an error message that
is only displayed if a particular request bean (the one
containing the error message) is present.
* If there was no error, it invokes the database logic
to save the updated customer, and then forwards
to the normal next page, as described above.
A couple of benefits of doing things this way:
* From the user interface point of view, the system always
remembers the most recent input values, just like a typical
GUI application does. No retyping is required.
* From the action procedure point of view, it is dealing only
with the internal (object oriented) representation of a
customer, via the CustomerBean class. It has no idea how
the data is actually stored.
* Likewise, the functional logic to save an updated customer
also deals with CustomerBean -- it has no clue that the
input came from a servlet/JSP based application versus some
other mechanism.
* I deal with the branching in the user interface (error case
versus normal case) in the controller's action procedure.
No need to have convoluted logic in a JSP page itself to
decide which "state" the application is in.
>
> Damian
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
