At 10:26 AM +0000 12/2/04, Adam Hardy wrote: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.
If your view controller is actually just a command on the chain for an action mapping, how would you register it against the action mapping's 'input' attribute in order to get pre-presentation stuff to happen for the validate-failures?
Just from a quick look at the dev list, it seems you want to put the view class as the last command on the chain. I think I must be missing something.
I tell you what, don't bother about it for the moment as I have unfortunately no time and it looks like I should be taking this over to the dev list to carry on the discussion. If I do get time soon I'll subscribe to that list.
Thanks Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
