struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: Private Actions Mappings?
Date Thu, 07 Sep 2006 14:52:21 GMT
On 9/6/06, Michael Jouravlev <> wrote:
> On 9/6/06, Martin Cooper <> wrote:
> > 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.
> The SS-18 ballistic missile was created to deliver a dozen of nuclear
> warheads to another continent. Now it is used to launch satellites
> into orbit. I don't see a problem in using something in a way it was
> not intended to be used.
> > 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.
> These are all good arguments against composing a page out of
> action-based components. Still I don't see a *really* serious problem
> here. Yes, parameters will be combined. Yes, request dispatcher will
> do the same work several times for one request, so what? Filters,
> well, I haven't thought about them... Still, I don't want to dismiss
> the composition idea just because of "gnarly bits" of implementation
> ;)

For six years or so, I've watched people repeatedly shoot themselves in the
foot becuse they think they want to chain actions and they _don't know_ the
consequences or their - uh - actions. The serious problem is that many -
perhaps most - developers have no idea what is going on under the covers,
and they _will_ get into problems with chaining actions, and will have no
idea _why_ they are getting into problems. There's no way I want to see us
encouraging the use of an anti-pattern that is an anti-pattern for very good
reasons. Just because it _can_ be done doesn't mean it _should_ be done. We
are here to help users to build their applications as simply as possible.
Using techniques that have traps and pitfalls that are easily stumbled upon
is not a good way to do that.

Martin Cooper

> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message