> > 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.
Not sure if this comment belongs in the context of here, but I'll throw it out. We use Tiles and Tiles Controllers heavily, and one thing I dislike about forwarding to a TileDefinition is that I cannot then easily figure out which Action I'm forwarding to ( The path names a definition which is the same for each view in my case). I'm currently appending information via an extension to the ActionForward, this extra info is then used in my controller to prepare the appropriate data for that view. If there was some more transparent way to do this that would be good. I currently have one controller per definition, which may encompass several related views. > 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. -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
