On 11/25/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > >>Given that chaining actions is a bad practice, for reasons that I've > stated many times before, > I'm not really interested in providing support to encourage people to use > that pattern. > > Me neither. I've written many times on the boards why I don't like the > chaining pattern either. > The good news is, that's not what this enhancement is! This proposal is > about naming your actions > so that you can refer to them in other forwards. So if you have an action > named "foo" you can > forward directly to "foo" without having to re-write the action path > again. I hope this clears up > your confusion -- it's not chaining, it's resolution. > > >> Also, there is an XML-related reason that we don't use the 'id' > attribute in the Struts config > files, although it is defined. Unfortunately, it's too early and I haven't > had coffee yet, so that > reason escapes me right now. > > W3C has a proposal to make the ID attribute a reserved attribute for all > tags, to uniquely > identify them in a document. This fits perfectly into this schema, since > you would logically would > never have duplicate action names. > > I would have liked to chosen a different attribute (like name), but > unforunately the <action> and > <forward> tags do not synch. The [EMAIL PROTECTED] refers to the bean you want > to use, and the > [EMAIL PROTECTED] refers to its, well, name. Once I noticed this, it looked > confusing; so I settled on > "id" as an acceptable attribute name.
I'm uncomfortable with this proposal for the reasons Martin is, 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.) -- Paul Craig 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*.
