Joe
At 6:47 -0700 8/11/03, David Graham wrote:
--- Ted Husted <[EMAIL PROTECTED]> wrote:David Graham wrote: > 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.
This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API.
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.
I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data.
Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core.
David
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]
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
