What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area.
This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping.
The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a "prepare" method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. The prepare method would return a String that the Controller would use for the path.
This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special "chrome" the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it.
If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it.
Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework.
I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.)
The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between "success", "failure", or "glockenspiel", we're talking about dispatching.
But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists.
Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any "chrome" a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details.
What would start to happen here, I think, is that people will put into the new class the code that now encourages them to "chain" some Actions. By providing a separation of concern between "choosing the Resource" and "preparing the context for the Resource", it becomes easier for people to Do The Right Thing.
The "gotcha" is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here.
-Ted.
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
