Remember this ol' thread? http://thread.gmane.org/gmane.comp.jakarta.struts.devel/15486
Just thought I'd check in and see what folks were thinking about the view controller thing. Seems like there are a few enthusiastic folks on struts-dev now who weren't around for the last round of this discussion, or who have started speaking up more.
The way I see it, the problem may be as much "how to configure" as "how to implement." Struts-config files are already kind of complicated. There's also a question about how much more to pile on the poor RequestProcessor when the Chain ComposableRequestProcessor seems pretty close to prime-time.
However, assuming we'd want to put this in the original RequestProcessor rather than wait for struts-chain to reach full maturity, here's some off-the-cuff ideas for you to shoot down....
Create a new interface, "Renderer," strongly modeled off of Action. It would have one method:
public ForwardConfig execute(ForwardConfig config, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception;
ForwardConfig could have a "form" or "formName" property (since 'name' is already taken), and using that, the "output" form would be looked up more or less the way forms are now, taking advantage of some recent refactorings so that you no longer require an ActionMapping to get a form. This would give the Renderer something it could pre-populate using whatever logic and system information it needed, should it care to.
The renderer could return the same ForwardConfig which was passed to it, or it could create a new one: for example, the new one might rewrite the path to include localization information (as described in the post mentioned above.)
I'd want to provide a base "DispatchRenderer" implementation which works like MappingDispatchAction, so i'd probably want to add a 'parameter' property to ForwardConfig. I don't expect everyone to use it, but I really prefer having less classes with more behavior.
It seems like it might be slightly disruptive to add properties to ForwardConfig since people may have already extended it for their own purposes. How do people rate that risk?
Does the Renderer need the ability to look up global forwards?
Is now a good time to coin a "StrutsContext" class that encapsulates the various arguments to "execute"? I've always kind of wanted this for Action too. I've frequently thought it would be a nice thing. This seems to get a little blurry when looking forward to a more chain-oriented Struts, where there's already a Context object floating through, but it seems worth discussing if we're making a new interface.
Like I said, this is just something to shoot down... so fire away!
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
