struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "RoughSpots" by DonBrown
Date Mon, 24 Apr 2006 20:31:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.

The following page has been changed by DonBrown:

      * [frankz] +1.  This is one area where I personally think Struts had it right and we've
seen frameworks getting it "wrong" subsequently.  !ActionForward I believe is the right concept,
even if the realization might not be optimal.  I think the difference between return "ok";
and return new ActionResult("ok"); is pretty minimal, but the later opens up a lot of possibilities
being a true object that can have behaviors and properties and such.
      * [crazybob] There's no reason we can't support both `String` and `Result` return types
for action methods. I think we should encourage `String` though. Can you provide some example
use cases for when `String` isn't enough?
      * [frankz] A few that come to mind... the ability to choose between redirect and forward
based on decisions made in code (you could argue that you can have two <result>'s defined,
one with type redirect and one with type forward, but then that starts to clutter the config
file I think)... the ability to add parameters to a forwarded result (i.e., if you wanted
to forward to another action, how can you add parameters just by returning a String?  Well,
unless the processor expects and can deal with a query string appended I support)... the ability
to add an anchor name to the response... the opportunity to include additional objects in
the response (i.e., what if you had some sort of ViewSupport object that the presentation
can make use of... it might be more intuitive to add it to a Result than to directly add it
as a request attribute, and that also makes for better abstraction from the servlet API).
 I'm sure there's more, and I'm sure there are ways to accomplish most
  of these things without returning an object, but I think the clarity of the resultant code
is greater by returning a Result object, and it opens up possibilities I can't think of (i.e.,
functionality encapsulated in that object independant of tbe interceptor stack).
+     * [mrdon] For further reading:
  == Nice to haves ==
    1. Inheritance is not a good way to reuse code between actions. One work around is to
use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`.
It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For
example, instead of extending a class that implements `ValidationAware`, SAF could extend
an action class at runtime and implement the `ValidationAware` methods by delegating them
to another object (a mixin): {{{

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

View raw message