DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37479>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37479 ------- Additional Comments From [EMAIL PROTECTED] 2005-11-25 20:27 ------- (In reply to comment #0) > Many times I need to redirect to another Struts actions. Recently I've come > across the problem of needing to rename my action paths but this became a real > nightmare to keep the action names as well as my redirect (forward) paths in > synchronization. > I'm uncomfortable with this proposal for the reasons Martin is (see also comments on the dev mailing list thread about this issue), but also for some others. * You are introducing a syntax that creates two unique identifiers for an action ... id and path. That seems like an unnecessary redundancy. * You are overloading the "path" element inside the forward element to mean multiple things, and requiring a namespace escape to disambiguate things. Besides being more complicated to understand, this will break tools that understand the current semantics of Struts configuration files so badly that 1.3 users would need to wait longer than otherwise necessary to get support for 1.3. * The most important reason I dislike this change, however, is an architectural desgn issue that few in the Struts community seem to appreciate ... an ActionForward should represent a *logical outcome* of an Action, not a *menu choice*. Let me explain further. Consider the little search box (with a "Go" button) that we like to put on pages of our applications, to allow users to do text based searching on things. Now, consider that you are authoring the Struts action that actually performs the search. The author of this code should require *no* knowledge of where in the application they wil be sent after the search is completed -- his/her only job is to say "what happened" when the search took place. Logically, there are three interesting outcomes we might want to describe: * No results at all were found -- outcome "none". * Exactly one result was found -- outcome "single". * More than one result was found -- outcome "multiple". I would argue that the search Action should return these three results as three separate logical outcomes. It is up to the application architect to decide to send all three outcomes to the "here's the list of responses" table page. It's also up to the application architect (perhaps later, in response to user feedback) to say "let's do this instead": * If there's no results, go to a page that says "sorry, no results were found, please try your search again." * If there's exactly one response, go to the details page to display the corresponding data. * If there's more than one response, go to the list page (as per the previous behavior). Note that *nothing* in the forwards defined for the search action, or the code inside it, is affected by this decision. Indeed, the outcomes returned by an action are *much* more stable than the places that you (as the application architect) mght want to send the user next. The only time you have to change them is when you add new interesting outcomes that need to be accomodated in the navigation architecture of your app. I agree with you that the names of forwards and the paths they go to can be fragile at times ... but I submit that this is primarily the result of how we are using them. Adding yet another identifier doesn't help, because now you've got *two* fragile identifiers for the same concept. If you think in terms of logical outcomes, though, you'll find this problem to be much less serious. Simply have each Action document the logical outcomes it returns, with meaningful nouns to describe them, and let the architect stitch together the navigation as the struts-config.xml file is composed. (Even if it is *you* playing both roles -- developer and archtect -- you will find that this change of viewpoint really helps the long term maintainability of your application's navigation architecture.) PS: If you ever hear me talk or write about JSF navgation, you'll hear exactly the same thing ... the strings returned by action methods should be *outcomes*, not *destinations*. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
