struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: view controller
Date Thu, 02 Dec 2004 10:26:00 GMT
On 12/01/2004 02:37 PM Joe Germuska wrote:
>> 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 
>> classes.
> 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

OK, I understand now. :)

I'm intrigued to know how you would declare the view controllers and 
register them against URLs. It would be in struts-config.xml presumably. 
Would you be able to register them against a tile def? Would the view 
controller have the same method signature as the action execute()?

Have you actually got anything in the nightly build yet?


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

View raw message