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.
Agreed. With chain in place, it is shockingly easy to develop a new action framework, and I'd rather wait and put in a successful, tested extension than put experimental code. Lets go with ActionContext and hopefully ViewContext, and call it 1.3.
In the meantime, I'll revive the Struts Action Invocation Framework (SAIF - http://struts.sf.net/saif) to test out my POJO action idea.
Lets bump up 1.5 features to 1.4 and plan for 1.4 as the release that includes the new action/form framework. I'd also like to target 1.4 as the release that doesn't depend on the Servlet API at all. I'm getting involved in portlet applications at work and am interested in using Struts without cumbersome servlet wrapping hacks.
Don
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
