Would this new ActionForward be created each time like it is now?
ActionForwards (or FowardConfigs) are instantiated when the Struts Config is digested and stored in a Map. FindForward then returns the instance directly from the Map. So they are already singleton instances (or at least shared instances), like ActionMappings.
public ActionForward findForward(String name) {
ForwardConfig config = findForwardConfig(name);
if (config == null) {
config = getModuleConfig().findForwardConfig(name);
}
return ((ActionForward) config);}
public ForwardConfig findForwardConfig(String name) {
return ((ForwardConfig) forwards.get(name));
}
protected HashMap forwards = new HashMap();
Or would it become a dynamic singleton?
The core idea is to expand ForwardConfig so that it can host a "type" (or "handler") property, like the ActionMappings. If the type were specified, it would point to a "View" class. The View class would have an extension method that would return a String. If the View class were specified, the Controller would call that to obtain the path instead. So, if specified, the View class gives ForwardConfig another "bite at the apple" before passing back the String to use for the path.
A View class instance would be shared by all the ForwardConfigs, as an Action class instance is shared by all the ActionConfigs.
The problem is not necessarily
interacting with the business tier, but making any such interaction
to a minimum. The probably means delegation, or caching, or something
else to add decoration. Ideally the Struts Action such grab all the
business logic for you and then store this information for you.
Ideally, yes, but then the Action needs to know every presentation requirement of the View, which implies it has a deep knowledge of the View's implementation. One View may need a select list, another View may not, but they may both serve the same Action in different page flows.
Alternatively, the Action needs to serve the highest-common denominator of all the decoration required by all the Views.
If we define a Context that can be passed around Struts, and perhaps the business layer too, it would be easier for people to implement facades and services that Actions and Views can share. (Though, it's not so hard now.)
> If an action forward requires special business requirements then > I can see both advantages and disadvantages. > > The advantages is that such a new ActionForward could add > special attributes to the response that are not concerned > with the Action logic. > > The disadvantages is that it is open to abuse. Bad programming > could introduce another layer of dispatching in the ActionForward > code. You would get mini-MVC nested inside another MVC, which > looks like Hierarchical MVC
This is why the extension method returns a String and not another ActionForward. The intent here is to render the path, not to dispatch to another component.
One viewpoint would be that the Action is not (or should not be) dispatching to a path. It's dispatching to a logical view. It's already the ForwardConfig's job to provide the path. Whether it is a static path or a dynamic path doesn't affect the status quo.
And speaking of the status quo, we already have Composite View tools like Tiles, which essential create a virtual path, and may have page controller actions of their own.
Meanwhile, people are doing things like creating dynamic ActionForwards in Actions (mainly to paste on request parameters) simply because they have no place else to do it. IMHO, the Action should have as little to do with web semantics as possible. An extension point on the ForwardConfig gives people a place to dynamically control the path and safely add web semantics without polluting the Action.
Also, as it stands, we have the Action rending a dynamic Response, if needed. IMHO, this is another place where lack of a View extension point pollutes the Action. To work around this, you can create an Action who's only job is to create a Response and then chain to it. But a better solution would be to have a View class render such a Response and leave the Action class out of it.
So, the best practice would be that the Action class should never touch the Response or the ActionForward path, that would be up to the View class.
-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]
