Lets start at the possible Use Cases. I see a web application wanting to have some actions be displayed as PDF's, others with a simple JSP page, still others with Tiles. I don't see the same action needing multiple forwards for each of the presentation types. If you are going to simultaneously expose an action via two different environments, say HTTP and SOAP, you will probably, in the SOAP case, have specific deployment configuration specific to SOAP and probably won't even be using struts-config.xml. If you are, I'd image you'd have one for HTTP and the other for SOAP, each with their respective view technologies.
Currently, with stxx and I believe with tiles, you, as you said, put in a symbolic name that gets processed by the request processor. In stxx's case, it might look like: <forward name="success" path="success.dox" /> where the "dox" extension lets the stxx request processor know to send it to stxx, where it will probably be converted to "success.xsl" at some point. Yes, one solution could be to simply allow presentation engines to "register" extensions they want to handle and let them convert the string into a useful path of some sort. The advantage of the symbolic name is you can possibly encode more information to pass to the presentation tech, like "simple/success.dox", which in the case of stxx, might be telling stxx to use the "simple" pipeline to process success.xsl. The disadvantage is it is kinda a hack and not particularly elegant. By explicitly specifying the presentation tech in either a separate attribute or the scheme of a URI, it is more clear. Taking into account the ability to pass "parameters" to the presentation engine either by encoding the info in a symbolic name or as part of a URI, perhaps another attribute wouldn't be adequate. In my stxx app, I make liberal use of encoding info in the symbolic name, using wildcards to extract that info within stxx pipelines. I originally suggested URI's to more standardize how info was encoded, but perhaps the symbolic name way would be more acceptable to some. Don On Fri, 19 Dec 2003, Joe Germuska wrote: > At 12:14 PM -1000 12/19/03, Don Brown wrote: > >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
