A couple of points before I move this to Scaffold ... "Craig R. McClanahan" wrote: > Chaining is unlikely to be significantly more efficient than request > dispatcher forwarding. Also, beyond that, I do have a couple of > design/architecture concerns:
Chaining is a misnomer. Here, we are actually *including* another action. Control does not pass to the other action, but returns to the caller. It is the current situation that encourages chaining, and loss of centralized control of the request/response event. > * Not using a RequestDispatcher.forward() means you don't get > the container semantics of erasing any previously generated > output (and complaining if you've already committed the response). > Unless you simulate this -- which you could do with wrappers in > Servlet 2.3 -- an action invoked this way sees different behavior > than one invoked via an RD. Since this is one action including another, we are already past the container semantics. It is the developer's responsibility to ensure that an insecure action does not include a secure action, the same as it would be for any servlet resource. > * In the early days of servlets (prior to the 2.0 spec) there was a > feature of some containers called "servlet chaining", which differs > in details from this but was the same idea in spirit -- seducing > the developer into combining components in ways that were not the > original intent. People that used this technique tended to create > spaghetti code that was very difficult to maintain. I'd rather > avoid that. The suggested approach is an alternative to chaining, which is what we now encourage. By allowing one action to include another, we are bringing conventional servlet semantics to the actions. Since the actions are in effect proxy servlets, this simply provides the functionality actions need to do their job, without resorting to a chaining paradigm. > * Because using a request dispatcher flows back through the controller, > we have the opportunity to "value add" new standard logic (such as > role-based access) before the forward is completed -- but chaining > would bypass this. The value-add is most often a value-diminish, since the current controller is not designed to recognize action chaining. Instead, it is designed to overwrite any changes developers might have made to an ActionForm that they are trying to pass to another action. This causes the developer to either extend the ActionForm to support an immutable mode, or to construct a query string to override the original. Constructing a query string in the action encroaches on the seperation of concern created by the Struts configuration. Actions do not otherwise need to be concerned with the semantics of query strings, since this information can be encapsulated in the ActionForm, unless they need to chain to another action. We are currently forcing workarounds rather than recognizing that including actions is a common development pattern. From the framework's perspective, the ActionForm is an API object for passing parameters to the perform method, and so the framework should support passing that API object from one action to another, using a well understood mechanism. The proposed methods may not be the optimal approach to including actions, but neglecting to provide the functionality encourages chaining, which has been dimissed as an inappropriate pattern. If these methods are vetoed, I would suggest that another concrete strategy be proposed, so that developers have a common way to approach this typical design pattern. > I vote for maintaining the original design intent, and requiring actions > who want to invoke others to simply return an ActionForward that points at > another action, instead of a UI component. I submit that including actions is a feature that the original design implies but does not implement. The proposed methods supply functionality that could have been present from the beginning, but was overlooked. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
