Folks,
I know I'm jumping in late here, so please forgive me if I'm rehashing too
much old material, stepping on toes, etc. I've spent the last day or so
spelunking much of the ActionServlet and related code with an eye toward
extensibility. My motivation is adapting/extending Struts, preferably
without changes to its core source code (via non-committed changes), to
support Velocity as the view-rendering mechanism. I don't want to get into a
p***ing contest about JSPs vs. Velocity, etc. I'll also add that I took a
quick look at the ServiceManager stuff as well. Lastly, I did look at the
enhancement comments for the 1.0.1 release.
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.
- 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.
- 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.
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.
- 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.
- 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.
Thanks for bearing with me. :)
Donnie
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
