While driving back and forth for the holidays, I spent some time thinking about Struts and the new chain framework. Here are a few thoughts I had:
* ChainAction should be obsoleted before a 1.3.0 release in favor of direct handling in the default chain. As was mentioned on the user list, we could easily add "command" and "catalog" properties to ActionConfig and then add another link in the processing chain which operated if those values were present, simply by looking up and executing the specified command. As with the current action and forward handling commands, it would simply do nothing if it saw an ActionConfig which didn't have those values defined. This is something I can do this week.
I just committed this last night, although I haven't yet removed ChainAction. Any objections? Technically, DispatchChainAction is not obsoleted by this. Neither of these classes as they are now take into account the named catalog functionality in commons-chain 1.0. (They can only dispatch to commands in the "default" catalog.) If either or both of them are preserved, that should be taken into account.
As I implemented it, "ExecuteCommand" only operates if the request is valid. This seems to make sense if you plan to use it in place of an action (although it can also be used to do preprocessing before a Forward, Include, or Action are processed -- and maybe in that case, the validity check isn't correct?)
This also made me think that perhaps we should instead make a sub-chain which is executed in the case of a valid form submission, and remove those per-command validity checks. Comments on this are welcomed while I wait for some more time to work on it.
I would rather have implemented this using an ActionContext class, but I was interested in getting it into people's hands. I am even more convinced that it's a good idea, but I think it will take more time to assemble.
* It would also be pretty easy to tack on command/catalog parameters to a ForwardConfig object and set up a similar preprocessing mechanism. It might also be nice to have a way to specify a form (and scope) so that an "output form" could be put into the context for database prepopulation. (ForwardConfig *could* extend ActionConfig and get all these things, but formally, that's probably not really right.)
This is slightly more cumbersome because the ForwardConfig never gets out into the wild, so we'd have to copy these properties to an ActionForward before it is returned by "mapping.findForward(...)". It crossed my mind that perhaps that should be the step when the form config is resolved into an object, and the ActionForward would have a form property instead of formName and formScope properties, but then I thought maybe we should just leave that up to the command we're envisioning which would create a ViewContext object.
I'd like to get some other ideas and opinions before I implement any of this.
Still waiting... ;-)
* Now that we're moving around all these catalog/command pairs, I'm starting to wonder if we wouldn't like to have a standard representation of the pair in a single string.
This has since happened, but since there hasn't been a chain release, the initial implementation doesn't use it. We can easily change it later.
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]
