I think we'd all be happy to see better support for Velocity, and other
templating mechanisms. Geir did some work along these lines last spring.
Donnie Hale wrote:
> Here are some observations, etc.
> - An implicit (or explicit) Struts premise, JSPs, results in a
> predisposition to assume RequestDispatcher.forward is OK for every
> app/view-rendering solution. For example, processValidate expects to be able
> to forward if validation fails.
JSP's are not a design goal, but simply the domain that interested the
orignal workers. Forwarding and redirecting is how HTTP generally works,
so that became the default approach.
> - The points in ActionServlet.process at which functionality can be
> overridden are fragile, as you either have to call "super" or duplicate code
> to get the current functionality plus add in your own.
Agreed. Oleg's been working on a service manger to help offset this.
> - It seems odd to have code in ActionServlet.process specifically tied to
> Forwarding/Redirecting ActionForwards. It would seem to be more "OO" to have
> a virtual method on ActionMapping and/or ActionForward to achieve this in
> the event that other types of ActionForwards need created.
An ActionForward sub-class can be specified in the ActionServlet config,
along with the default ActionMapping class, form bean class, and
multipart handler.
> I guess what I'd like to see is a decoupling of ActionServlet from the
> "template method pattern" it attempts to follow (i.e. formalize the pattern
> by specifying an interface). At the same time, I'd like to see the action /
> action form / mapping decoupled from any assumptions about view rendering.
> So we can keep all the great stuff for pre-populating beans, declarative
> actions and mappings, etc.; but parameterize the mechanisms for initiating
> the rendering of the view.
Cedric has done some interesting work in the tiles library, where the
view is rendered from a runtime configuration rather than a physical
file. Perhaps a variation of this approach would also work for a non-JSP
templating mechanism.
> - A side effect of assuming forwarding is that lots of stuff gets put in the
> various contexts (servlet, session, request). Just by looking at the key
> names in Action.java, you can't tell which of those contexts to find them
> in. I've thought that perhaps having a single object for each of those
> contexts, accessible by name from those contexts, might be more flexible and
> maintainable. For example:
>
> class StrutsServletContext { ... }
> getServletContext().setAttribute("org.apache...SERVLET_CONTEXT", // instance
> of StrutsServletContext);
>
> The StrutsServletContext class would have accessors for the message
> resources, data sources, etc. Use the same pattern for request and session
> contexts. I'm not sure, but I think that might ease moving to the multiple
> controller support that's been discussed recently.
The number of settings used by an ActionServlet has grown a bit, and it
does seem like time to collect these into a coherent binder object, like
a StrutsContext. This could then be passed to the view via the request,
and any access via the application context deprecated.
> - I see that Digester has moved into Commons. Has any consideration been
> given to moving MessageResources, etc. there? It seems like it's the kind of
> self-contained, decoupled, reusable functionality that could go there.
I think most of the tag extensions are destined for Taglibs, depending
on how JSPTL shakes out, which would include the bean tags and the
MessageResource support. They already have an i18n tag modelled that
works in the same way.
I'd love to more the generic connection pool to the Commons, if someone
wanted to maintain it. Or maybe we could adopt Excalibur's instead.
Binding the datasource to the servlet context is problematic in a
layered architecture, and IMHO, sending developers the wrong message.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
