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.
In terms of what a framework based on Commons Chain might be like, I've made some notes here:
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/WHITEBOARD.html
But the cool thing about Chain is that it plays well with others. You can start using a Chain solution in your Actions at any time. The Action path could be a command name keyed to the business logic. Likewise, the ActionForward name could be another command keyed to the presentation side of the business logic. (What raw materials will be needed by the controls client specified for the target page.)
But, there's also another aspect to the view controller use case -- better support for i18n. The message bundles are a great start, but many applications need to branch to different paths for different locales, or even different clients. So, aside from preparing the request, we could also use a View Action to munge the path (in a new instance of ForwardConfig). Of course, the nuts-and-bolts of this process could be encapsulated in a Chain.
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.
I agree that you could collapse the "business" Action and the "presentation" Action into a single Chain. But, as much as I like Chain, I don't know if I want to present it as the final solution to this problem. Even with Chain, I might want to separate the concern of calling the "business" command from the concern of calling the "presentation" command.
I might even want to put them in different catalogs. One set of Actions could be calling a standard set of DAO commands. Another might be calling a set of commands geared for the presentation layer. One might be in a JAR handed down from another team. The second might be in my WEB-INF directory. Of course, you could combine these into the same runtime catalog, but then you have to micro-manage the namespaces and all that. TANSTAFL.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
