Perry Hoekstra wrote:
> So to reiterate what I think/understand what you said is that your
> dispatcher servlet performs the following functions
>
> - Allow for security authentication if necessary
Yes. In fact, my general purpose controller servlet can be subclassed to add
this or other functionality that is specific to a particular application.
>
> - Allow for branching to various JSP pages on a given action request passed
> in through a request parameter.
There's really two stages of branching going on:
* Which action procedure should I execute? For me, this is based on the
request URI, but you could do it based on a parameter if you wanted to.
This decision is made by the controller servlet, based on a mapping defined
in servlet initialization parameters.
* Which JSP page should I display next? This decision is made in the action
procedure, based on the calculated results. Often there is more than one
possible destination (if there were validation errors, go back to the entry
page; otherwise go to the results page).
>
> - Perform server-side form validation of data entered on a form. This takes
> the form of validating data through a custom JavaBean that contains business
> rules rather that basic form validation through the use of JavaScript
Normally, I use the action procedure to set the properties of a custom JavaBean
(pretty much representing all of the input fields of a particular "form", even
if it extends over multiple pages). Then, for validation, I call a method of
the bean itself that returns a textual error message (if something was wrong),
or null if everything was OK.
This does not by any means exclude client side validation with JavaScript, which
is built in to the original entry forms as well. However, client side
validation cannot check everything, and I check it over again anyway because I'm
not necessarily the author of the JSP pages -- and it is my (as author of the
server side logic) responsibility to reject invalid data.
>
> - This server side validation uses 'Action' classes as an adapter between an
> HTTP request and the Java class that implements the business rules
>
Yes, in the general "design patterns" sense. My bean classes have no knowledge
that they are being used in a servlet/JSP environment (that is, they have no
imports for javax.servlet.* or javax.servlet.http.*). The beans can in fact be
custom JavaBeans, or remote references to EJB entity and session beans.
>
> Did I miss anything?
>
Only one implementation detail -- each of my action procedures is a separate
Java class. The first time I request a particular action, a new instance of the
corresponding action class is instantiated, and it is cached for use on future
requests (saves one object creation per request). As a consequence, the logic
inside my action classes must be multi-thread safe the same way that doGet() and
doPost() have to be, because it's possible for more than one request to be using
the same action class instance at the same time. Basically, this means avoiding
the use of class instance variables or statics within an action class (plus
appropriate synchronization on code that modifies things if necessary).
>
> Perry Hoekstra
Craig
===========================================================================
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
