Thanks Craig. I disagree but that's okay; I find identifying other actions by
names makes perfect
sense and is the logical outcome of development. The idea was spawned by the
ease of Spring which
I can reference anything else by a name. Anyhow, if you have time, I think your
answer should be
appeneded to the bug request so that we can perpetually keep your explanation.
Paul
--- Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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*.
>
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
