On 9/6/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 9/6/06, Martin Cooper <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
