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?
Rgds Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
