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 ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
