Joe Germuska wrote:Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure.
Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions.
Personally, I like returning the ForwardConfig instead of a String since it's extensible. You can always call a method to get whichever String you want, the logical name or the system path.
Well, the string would just look up a ForwardConfig or ViewController one level out, and I figured you'd still have extensibility and configurability there.
My thinking (admittedly still in progress even now) is that I don't really love the implementation of "processForwardConfig" because it seems to focus on a limited area of how views are rendered. Shouldn't the responsibility for seeing that a response is rendered be encapsulated in the ForwardConfig or a a more active class like ViewController, instead of having the RequestProcessor assume that forwarding is the way to dispatch to a view?
I'll acknowledge that this is fairly theoretical, and practically speaking, probably 99% of actions prefer to use RequestDispatcher.forward to pass off to the view. And arguably even when we now write to the response output stream and return a null ForwardConfig, that might be best implemented in another Servlet in the WebApp, to keep Struts more a pure Controller.
One small itch about just going ahead and using Action as a ViewController -- should the framework make a more explicit mechanism for communication between the controller action and the view action? Certainly, they can just agree to use "well-known" request attributes, but is that good enough?
But once you take these two related cases together, I do believe an Action extension point for the ForwardConfig would be useful and justified. We've been taking about making the forward smarter for years. Now that we have a more flexible request processor, perhaps it's time to make it smarter in the usual way, by giving it an Action class.
OK... so let's go along this line. What ActionMapping gets passed to the view Action? The same that was passed to the control Action? What if I want per-forward configuration details in the struts-config.xml? Do we need to extend ForwardConfig to have all the same configuration properties that ActionConfig has? There are some overlaps, so that could be tricky.
I do like the possibility that the ActionForm passed in to the view action could be the one which will be presented on the view page, instead of the one which was populated from request parameters -- this solves the very common problem of people needing to pre-fill a form.
There's still the question of who instantiates and manages the view action instances; I guess it would be ActionMapping?
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
