On 9/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Hi Paul et al, Paul Benedict wrote: > Everyone, thank you for the response. > > Martin Cooper wrote: >> This sounds to me like a rather blatant mis-use of actions. In the first >> place, as Michael points out, action chaining has always been an >> anti-pattern in Struts. > > As Michael later pointed out (and I should have explicitly said), this > is not about action chaining. I do not pass data from one action to the > next. These actions are self-sufficient in their data retrieval and > render multiple portions of a page. It just happens Michael does the > same thing and so that's how he guessed at my implicit point. Because S1 > so conveniently supplies an "include" attribute on the action mapping, > it's just so easy to invoke multiple actions to render a composite page. I think the point Martin was making though is that an Action should be the endpoint of a request (he said as much actually). Endpoint implies singularity, at least for a given control path. In the case of composition, it would be more "proper" (although I always hesitate to use that word) to have a single Action that calls some helpers to render the complete view.
Exactly. The action is (intended to be) the class that handles the entire request, whether that involves parcelling out the work to other classes or not. An action was designed to be the end point of the request, not one of a set that handles the request in collaboration with each other. I've often done, and advocated, instantiating an Action within another
and calling execute() manually. It's nothing but a helper class really in that case.
This is the part that I've never understood. If it's intended to be a helper class, then why, oh why, do you insist on using an Action for this? If it's a helper class, *make* it a helper class, not an action! And if the reason is that you also use it as an action, then my response to that is that you have the wrong structure - the common code should be in a helper class that both actions use, instead of having one action invoking the other. I've also debated whether this should be called chaining
or not (I don't think so, but some may).
I would not call it action chaining, at least in the traditional sense, for a very, very important reason. By invoking the second action yourself, you are not going through the request dispatcher. It is the nested invocation of the request dispatcher that causes all of the issues with (traditional) action chaining. It's the request dispatcher that may or may not execute filters, depending on the container and J2EE version you are running. It is the request dispatcher that will combine request parameters from the original request with those of the include or forward, possibly occluding what you want to see. Those are where the gnarly bits lie. Of course, I still wouldn't invoke one action from another, but even if I did, I wouldn't call it action chaining. ;-) -- Martin Cooper I think this may be closer to
what your looking for, no? I say that because I can't imagine that if you are compositing a page, that any but the one Action that got called to composite the view is interested in the full request cycle, indeed, I would think you would expressly want to avoid that overhead... seems like that one should call the others as helpers, no? If that's the case, I think moving that code that might otherwise be a private Action out to a helper makes more sense than trying to have private Actions. To put it more succinctly: if that code can never directly be called by the client, then I'm not sure I see why it needs to be an Action at all. > Paul Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
