I too followed the thread, some good ideas here - keep them "open" in
this forum and we can all use them :)
As we're back onto this, I've got a few questions below about
responsibilities and behaviour. It'd be good to get opinions of those
"at the coal face" who have written large jsp projects.
<snip>
> 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).
It sounds indeed like the "Adapter" pattern out of the Gang of 4 Design
patterns book. So "Actions" are presumably very light weight classes,
and stateless?
However:
Clarification here for the architecture. Do you
- implement business processing inside the action classes, or do you
- use the action merely to turn an html request into a sensible, sanity
checked and validated Java method call, and then handle the business
logic using a different pattern, like the "command" pattern.
The latter approach could be more flexible if there is a need to have
many different interfaces onto the same business process logic. I.e. you
have stateful business objects, like "Customer", "Order" etc (and why do
we _always_ use Customer and Order as the examples... ;), then you have
either behaviour on the object, or series of "Processes" that can happen
to these objects, like "PrintOrders" (sort of single Use Case
granularity). Then the core business object code, _and_ the process
control logic can be accessed via JSP (and an "Action" adapter class),
or by a windows or unix standalone application, by a batch script etc.
The "Action" adapter classes then contain no business control logic at
all.
How much can this separation happen. And if this approach were followed,
what of validation, or authentication? In which layer would you put the
authentication logic? On the Action? or on the "Command" classes? or
anywehere and everywhere ;) ?
>
> * The controller servlet then forwards (RequestDispatcher.forward())
> to the appropriate JSP page to display the results.
.. and presumably you get the appropriate page from the Action class
itself?
I wonder if it's possible to do it slightly differently, and allow the
Action class to do the forward itself. It is after all in the best
position to "know" whether it needs to throw to an error page, or a
login page, or display results etc. Also, if the Action is allowed to do
the forward itself, then you could potentially chain actions together
(Chain of Responsibility pattern). So an "Authenticate" Action can be
written. The first time someone hits the authenticate action, it can
immediately forward to a login page, then back to the protected action.
Subsequent times, the Authenticate action happens transparently, and
allows the protect action to run. This "chain" could be extended to
include things like site logging, or user tracking etc. What I can't
decide is if this behaviour belongs in the "Actions" or whether at a
more business focused level (or everywhere).
So should actions be chainable?
More thoughts on chaining? and action granularity?
>
> 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).
like it :)
<snip>
===========================================================================
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
