struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: view controller
Date Wed, 01 Dec 2004 14:37:01 GMT
>Yes but only half. Regarding the first point, since struts is 
>actually able to accept and deal with a second action mapping in 
>that mapping's "input" (or "forward") param, then somehow struts 
>must be designed for it. It can't possibly have been a happy 
>coincidence, surely? I don't know about tests.

Not really; it's just a side effect.  Struts is merely calling 
requestDispatcher.forward(...)    If Struts were designed for it, you 
wouldn't be including the ".do" in the value of input, in the same 
way in which you don't have to include it in the "action" attribute 
of an html:form tag.

To say that Struts isn't "tested" for it may be overplaying the kind 
of testing we have, but it is true that in general, action chaining 
is considered "unsupported."  As you'll see below, deeper changes 
underway in Struts should obsolete the need to chain using multiple 
calls to requestDispatcher.forward(...) (with repeated runs through 
the entire request processing cycle).  The whole request processing 
cycle is going to be much more open and flexible.

>I appreciate your direction though. Do you envisage being in a 
>position to completely disable chaining in struts? Let me describe 
>the situation I had at my last project where it was useful (and 
>justified IMHO):
>The screens were complex and were not under my control. Each screen 
>contained up to 3 completely seperate bits of functionality, e.g. 
>hotel bank account number, hotel billing address and hotel billing 
>options. These were handled by different session facade calls.
>I had already experienced alot of scope creep and I knew that these 
>would change, and in fact I was pushing to get control of the screen 
>designs, in which case I would simply have put the 3 different bits 
>on different screens - so when coding the mappings, I made 3 
>mappings and chained them together, so I could seperate out the 
>Action classes and hopefully actually seperate out the page too in 
>the future.
>I didn't get the opportunity to seperate out the pages, but I was 
>still happy that I could chain the mappings and have seperate Action 

I think that this is a good use case for the commons-chain library, 
and probably for the "ChainAction" that Craig recently wrote.  The 
ChainAction is meant as a way for users to delegate Action processing 
to a commons-chain command (which itself may be a chain of commands) 
in a way that would have allowed you to rearrange the "plumbing" just 
by editing config files.  Using these things right now is still a 
little cutting-edge, as there is still a lot of documentation to 
write, and probably some better support for multiple 
chain-configuration files...  we're hoping to push these things into 
the Struts core CVS as soon as commons-chain makes its 1.0 release 
(any day now).

Strictly speaking, this is all kind of tangential to a view 
controller, and in fact, if you were using ChainAction, you could 
slot in commands that each had any balance of responsibilities 
between "action processing" and "view preparation" that you liked. 
We might find ourselves looking for some good ways to standardize 
things like instantiation or location of the form bean which might 
need to be prepopulated for the destination view, which is one of the 
reasons I like the idea of formalizing view preparation.


Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message