Hi Jari,
Well, I can't tell you I have written very big JSP projects, but I have
a couple of them working now (I can give the URL's but they are in
Catalan, not even Spanish, so...) and the last of them might get you
some answers. Comments are intermixed for clarity's sake.
Jari Worsley wrote:
>
> 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>
<double-snip>
> 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?
In my case, they are. They just implement 2-3 methods and they are
stateles because the real logic is somewhere else.
> 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.
That is the case, I use EJB to handle the Business logic and my
Operations (That's how I call my commands) just grab the parameters of
the call from the ServletRequest and introduce the results as attributes
prior to forwarding the request to the JSP.
> 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.
Correct. That's where EJB Session Beans <re supposed to play a important
Role.
> 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 ;) ?
I have introduced the authentication in the controller servlet, even
though I would like it to be done at the container, I allow the security
architecture to be specified in an independent class or by the action
itself.
> > * 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?
Yes, I actually allow the Action to specify three different pages, one
for the normal operation, one for parameter checking errors, and another
one for operation execution errors. That's also easily configurable.
> I wonder if it's possible to do it slightly differently, and allow the
> Action class to do the forward itself.
I actually allow different sets of "Actions" to be written. One type is
the "JSP Action" where results are forwarded to JSP pages specified by
the configuration(XML). Another one could be the "WebMacro Action"
where, instead of JSP pages, WebMacro templates are used for the UI.
Another one is the "Servlet Action" where there's no forwarding and the
Action acts as a servlet. The last is useful where there is no UI:
downloading of files...
But I wouldn't, and I don't, let the responsibility of doing the
forwarding to the Action, because this way I can use the same Action
with different JSP pages, just changing a parameter in my configuration.
> 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.
I let them do it through Exceptions, and I'm about to include an
optional feature so they can dinamycally choose the JSP, but for
internacionalization reasons.
> 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).
I decided to integrate the security in the controller servlet, of course
creating different objects and delegating, but that was my choice ;).
> So should actions be chainable?
> More thoughts on chaining? and action granularity?
For me Actions should be simple and reusable, so one task one actions.
If you have to do more than one task with an action, then encapsulate
this tasks, using EJB for example. Again, that's my choice because
that's what I think I can understand and handle better. Chaining actions
and actions that include actions can turn your desing into something
that a machine can perform, but gets so obscure it's difficult to
understand for people, so debugging can turn into a nightmare. I can't
help it, I like simplicity ;).
> > 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>
I also allow different suffixes to be used in the same application, so I
can use *.app for the "open area" and *.admin for the "restricted area".
This way is easier to check whether you are in one area or another, and
configure the authentication scheme accordingly.
I hope this helps,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
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
