This point made me think of something... What about the idea of adding the concept of an <action-bean> in struts-config?
At 12:11 PM -0800 2/14/05, Don Brown wrote:
The question is whether there will be a one-to-one mapping between action-beans and action-mappings. If 90%+ of the time there will be, this will needlessly complicate the config. I suppose, however, if action mappings used wildcards heavily, this could come in handy, course then I'd argue for wildcards in the action-beans to help group them. :)
I guess I figured on<action-bean> being an alternative to <action> in that it would have a "path" property. Maybe that's a bad idea, but it would be easy enough to throw another chain command in there which looked up the path against another store of expertise.
Then again, it would presumably mean adding yet another property to ActionContext (getActionBean()?) That might be a bad path to head down.
OK, Frank, sorry; you're not on to anything. ;^) Just kidding -- good to think outside the box in all events.
My inclination at this point is to treat the most complicated questions we're bumping up against as fertile ground for subprojects and contrib-type code until we really see what people want and what works. I don't think it is necessary to wrestle them all to the ground at once. Reviewing the latest roadmap, even some of the things I've already done or am planning on doing are a rew minor revs out. It's probably time to recalibrate the roadmap to our current interests and ideas.
I've copied some of
http://struts.apache.org/roadmap.html below; I left out the parts on which I didn't have direct comments.
Experimental Members
ActionCommand - A Chain Command-like interface with one method...
ActionContext - A Chain Context that implements the logical Action class API.
ViewContext - A Chain Context that implements the logical "Velocity Tools" API.
At this time, I am convinced that explicitly passing ActionContext through Struts' chain is sufficiently better than having all the commands have to share info about where to find key context attributes and having them frequently cast to WebContext or ServletWebContext that I would take this out of "experimental" state.
I also don't see how ViewContext would be terribly experimental, unless we immediately rewrote the taglib classes to use it. Even so, I'm not sure I believe it requires a long incubation period.
After reading the section on ActionCommand, I could be persuaded to abandon my suggestion about changing Action in favor of presenting the ActionCommand interface, and "overloading" the <action> type attribute so that it might specify either an Action or an ActionCommand, or possibly adding a new attribute. Ted wrote it so that this level of "smarts" would be deferred until "Struts 1.5"
The Commons Chain WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext.
I'm not sure this is an issue any more. After trying to mix and match commands, I think it's worth stipulating that the ComposableRequestProcessor will always start the chain with an ActionContext.
1.4 considerations
Consider adding catalog element. Depending on how the work goes with the experimental ActionCommand interface, we might identifiy a need to add a catalog element to the Struts configuration, to support using a Chain of ActionCommands.
This has already been done or doesn't matter, depending on how you look at it. There's direct support for looking up any command using the command/catalog attributes; on the other hand, if you want to specify an ActionCommand as the "type" for an ActionConfig, it seems like there's no clean way to support a catalog or any kind of lookup, nor a need, since the former solution exists.
1.5 considerations
Based on our own work with the "experimental" members inroduced in 1.3.x, we might consider some other changes.
Consider a "smart" action type. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even support placing an ActionCommand interface on ActionForm, so people could skip having a sepate Action or ActionCommand class. The ActionForm could do it all.
As noted above, this seems like a necessity before 1.5 if you're going to actually use ActionCommand; I'm not quite sure how one would effectively designate ActionForm as a command; if one wants to have something "do it all," I don't think that thing should be called "ActionForm."
Of course, this document has always just been a scratchpad of sorts, but perhaps now that a few of us are back to actively thinking about implementing future changes, we should revisit it and come up with one which reflects our intentions?
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
