Relying on the request dispatcher ties you to the Servlet API. Furthermore, extensions are inadequate as more than one "handler", to use Joe's terminology, might be interested in a particular extension. If the URL idea is collectively shot down, I vote for Joe's idea of adding an attribute the the forward element. In either case, 100% backwards compatibility should be maintained.
Although now that we talk about it, I'm hesitant to put this in the forward config -- I'm afraid it would lead to people writing actions that were too conscious of the view handling. I imagine something like this, which I would not want to see:
<action type="MyAction"....> <forward name="httpSuccess" path="success.jsp" /> <forward name="httpFailure" path="failure.jsp" /> <forward name="soapSuccess" path="success.xsl" handler="stxx" /> <forward name="soapFailure" path="failure.xsl" handler="stxx" /> </action>
Of course people can always do things the wrong ways...
Is this better?
<action type="MyAction"....> <forward name="success" path="success.jsp" /> <forward name="failure" path="failure.jsp" /> <forward name="success" handler="stxx" path="success.xsl" /> <forward name="failure" handler="stxx" path="failure.xsl" /> </action>
That is, multiple forwards with the same name, distinguished by their handlers? I don't like that much either, since it puts a lot of responsibility on mapping.findForward()
So then it seems that a Tiles-ish solution might be better, where the path is another symbolic name, each kind of handler could potentially be configured with a way to dereference that symbolic name.
What's the use case? Using one action to respond to HTTP, Portlet and SOAP, assuming that the control is the same but the view is different? Or is it using different view handlers in the same request domain -- that is some times you want to use JSP to respond to an HTTP request, and sometimes STXX or Velocity?
If it's the first, you could expect the part of the request processor before the action is invoked to be able to leave a mark as to its ID, so that the corresponding view handler could take over after the action finishes. If it's the second, I'm having a hard time thinking of a clean way to organize that.
I should be careful here, because I haven't had need for either of those cases myself. But in all my thinking about this, I wish it didn't have to be implemented using the current monolithic RequestProcessor -- do you guys still think we're on a "1.4 time frame" for switching to a chain-based version? (as noted in the "roadmap").
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]
