Re: Further Chain Engineering

[Joe Germuska <Jo...@Germuska.com>]

At 8:51 AM -0600 12/29/04, Joe Germuska wrote:
>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            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org