All good points. But do end points have to be singular? I do not believe
I have invented any sort of unique design. I have employed actions in
actually a very similar fashion to how a portlet server would work.
Additionally, I don't know exactly which project in Apache has done
this, but I know of a Struts/JSR-168 Portlet bridge. I think that's
pretty cool. It's the same concept: executing multiple actions and
aggregating output.
Paul
Frank W. Zammetti 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.
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. I've also debated whether this should be called chaining
or not (I don't think so, but some may). 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
