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.
Right now, Tiles checks to see if the path is the name of a definition, and if not, it passes it through as a normal URI. In a sense, this is a mini Chain of Responsibility.
When the Chain Request Processor is in place, we'd be able to have both a Tiles handler and a Stxx handler in the chain. Tiles could check to see if the path was a definition, and if it wasn't, it passes it along (to the Stxx handler).
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?
Here's where adding a Java class to the ActionForward could be useful. The ActionForward could examine the context and decide what to do, which could even be render the response directly. We've made that the Action's job before, but I'm leaning toward enhancing the ActionForward so that it can take greater responsibility for rendering the Response. Right now, I think a lot of are writing two sets of Actions. One to handle the business case and another to handle the presentation case.
When we discusses this before, we came down to wait and see if a Command would work here, which I agree is a good idea.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
