Comments inline
> On Tue, 29 Apr 2003 arh14@cornell.edu wrote:
>
>> Date: Tue, 29 Apr 2003 13:34:31 -0400 (EDT)
>> From: arh14@cornell.edu
>>
>>[SNIP]
>> All that is required is
>> a type of
>> "ActionForward" which does not forward back through the servlet
>> engine, but instead back through another configured Action...I haven't
>> looked at the code (although I've seen pseudo-code description), but
>> this has to be at most a few lines of code.
>>
>> while (actionforward.isLocal()) {
>> actionforward = actionforward.getLocalAction().execute(mapping,
>> form,
>> request, response); }
>> }
>>
>
> This approach doesn't support the "I'm finished now, so stop delegating
> to any more local actions" mechanism of the Chain of Responsibility
> pattern.
Once an Action returns a non-local ActionForward it will.
> This approach ignores any ActionForward returned by any action other
> than the last one, which violates the assumptions that any Struts
> developer building actions is going to make.
This mystifies me. Struts currently already does not support "any
ActionForward returned by any action other than the last one" because it
only supports ONE Action at a time, which is the last one. The sample
loop above executes every Action in sequence until a non-local
ActionForward is encountered.
> This approach locks your business logic into Struts APIs (and therefore
> the servlet API as well), making it basically impossible to use that
> logic anywhere else.
Of course nobody is *forcing* anybody to use this approach. If you need
to implement a chain of responsibility that acts on the servlet request
and response, your classes are going to look very much like the Action
API, and you will end up having to reimplement much of Struts (i.e. your
own controller, your own configuration syntax for defining "actions",
etc.).
> Bottom line -- IMHO, this approach improperly mixes view-tier controller
> functionality (what Struts is for) and business logic controller
> functionality (which is a perfectly reasonable place to use Chain of
> Responsibility, but it should be based on generic APIs for that purpose
> -- not on org.apache.struts.action.Action).
Page transitions are not the only way to affect the view. I can affect the
view for example by submitting a request against the same page with
different parameters, in which case I am right back exactly in the
scenario of struts, delegating control to Actions. If you have actions
that can be reused by many pages it will be much cleaner to implement
those actions once, than to create N x M action mappings.
Aaron
>
>> Aaron
>
> Craig
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org For
> additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
|