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: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ * [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: http://forums.opensymphony.com/thread.jspa?threadID=23621&tstart=45 + * [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
