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?
No, nothing yet. The first order of business is getting the chain in there, and action on that is waiting for the full release of Chain 1.0. I'm thinking about the issues and looking for challenges while we wait.
As for anything specific to a view controller -- well, I'm not sure how it would be configured, and I consider that important. In a project here, we have a class we call "UIToolKit" which has a collection of "renderers", and then we have a "PagePrep" chain command which operates between "ExecuteAction" and "TilesPreProcess". (This allows the controllers to be registered against tiles paths, although now that I think of it, it is probably only operating for the "master" or top-level tile.
The renderer config looks something like this:
<render
path =".configure.SelectTopicsOrModel"
type ="....ConfigureRenderer"
method ="selectTopicsOrModel"
form ="configure_SelectTopicsOrModel"
scope ="request"
/>where "path" is compared to the return value of "getPath()" called on the ActionForward which was returned by the Action class. "type" is a class, and "method" is a method on the class; for our local use, it is understood that the method will take a single "RenderContext" argument. "form" and "scope" are optional, but if defined, they will be used to put a form into the RenderContext so that prepopulation can occur. The RenderContext also has references to the request, response and other application classes which may be necessary to do the prepopulation or other view preparation.
I'm not specifically proposing this for Struts at all, but only offering it so that people can critique and consider some of the issues we've covered here in a "prototypical" implementation of this idea.
The RenderContext would probably be replaced by a class called "ViewContext" which has been discussed recently on the dev mailing list, and fairly thoroughly elaborated on by Ted Husted.
Moving forward, the main question is whether it's even worth creating a new area of struts configuration for this, or whether it would be more suitable simply to advise people to configure chain commands which do the same thing. Ted's idea is that "ViewContext" would be a subclass of Chain context, so the structure of any view controller class would be pretty similar to a Chain command: "public void execute(Context)"
What might make more sense would be to create an abstract Chain command which knows how to look up a form and put it in the view context, and then users could extend it and implement their view preparation. We didn't do that here because we were still very new to Chain, and we weren't yet comfortable with the chain configuration syntax. But as this is taking shape, and as I'm writing this, I think I'm leaning towards just doing it with Chain, especially for starters. The Chain model was recently extended to make it easier to manage a map of named command catalogs, so that you wouldn't have to cram everything into a single mega-config file.
And, of course, something we've been noticing is that using chain, Actions themselves could be directly replaced with chain commands, once people become comfortable with chain configuration. But one step at a time! The initial chain implementation is totally backwards compatible with old Struts config files.
Joe
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
--
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]
