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 Bob Lee
Date Mon, 24 Apr 2006 21:25:16 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 Bob Lee:

      * [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:
+     * [crazybob] I'm not sold on this. 1) The result pulls values from the value stack,
not the request attributes. 2) I ran into a case recently where I ''thought'' I wanted to
return a real object at first: I wanted the action to dynamically select a redirect URL. I
ended up doing this: {{{
+   <result name="..." type="redirect">${url}</result>
+ }}} 3) Enabling users to return either a real object or a string is going to impact the
interceptor API, too. :( 4) Wait a second... you can do what you want right now! Create a
new result type which looks up a `Result` object on the value stack and delegates to it. Then
map a global result to the new type. For example, you could return `CUSTOM`, and the the result
type would execute the `Result` returned from `getCustomResult()` on your action. ;) 
  == 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