-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 01, 2000 8:29 PM
To: Perry Hoekstra
Cc: [EMAIL PROTECTED]
Subject: Re: JSP Architectural Question
Perry Hoekstra wrote:
> I read the thread entitled JSP/Servlet Architecture that was held back in
> October and was particullary intrigued by Craig McClanahan reponses. In
> that thread, a servlet acted as a facade to the backend resource. I did
not
> find any threads discussing the merits of using servlets/Java beans acting
> as the facade class.
>
Depending on which thread you were looking at, the approach I actually
utilize
might not have been clear. I don't use servlets directly as a facade for
the
backend resource -- instead, I use them as the controller in an MVC
architecture.
The general organization of request processing in my apps goes like this:
* Input form is created by a JSP page (normally using beans
found in the user session to remember previous input values).
* When the user presses submit, the form is posted to a servlet
with a URL that lets the servlet figure out what processing is
required (see below for more on this).
* Servlet receives the request, figures out which action class to use,
and calls that action class. The action class is usually very short --
its main purpose is to serve as an adapter between the HTTP request
view of the input parameters and the bean properties (and method
calls) that implement the business logic.
* The action procedure stores the results of its processing as either
request beans or session beans (depending on how long the results
need to be alive).
* The controller servlet then forwards (RequestDispatcher.forward())
to the appropriate JSP page to display the results.
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).
The net of all this is that I'm just using a servlet as a dispatcher --
everything
else is done in beans, which are equally accessible to servlets and JSP
pages that
belong to the same application.
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
- Allow for branching to various JSP pages on a given action request passed
in through a request parameter.
- 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
- This server side validation uses 'Action' classes as an adapter between an
HTTP request and the Java class that implements the business rules
Did I miss anything?
Perry Hoekstra
===========================================================================
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
