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 FrankZammetti: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you want to return anything that requires more than the symbol, you have to do some less than intuitive things to make the Action and the Result cooperate. I'd prefer to see a concrete Result get returned from Action methods, which would allows developers to do more powerful things more easily. There are a bunch of ways to make it backward compatible too. You could return 'new SymbolicResult("success")' and have the SymbolicResult do the lookup stuff (You could even redefine the String constants to be SymbolicResults). You could alternatively use a static class to do Results.find(SUCCESS). Or you could even allow method to continue to return String or Result, and if String wrap it in a SymbolicResult. * [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). == Nice to haves == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]