Gotcha! I see what you mean and how they differ.
My off-the-cuff thought was that:
1) no, I envisioned result-selector elements at the global and/or
package level.
2) multiple selectors would be invoked until the first match is made
(not sure this is ideal).
Perhaps it's best to back up and look at the actual requirement (I was
originally guessing at your thoughts as opposed to suggesting an
approach). I should have just asked the question, as I obviously didn't
really think through my stab in the dark:
- End users should have the ability to implement and deploy new
selectors in a manner which is consistent with the way they implement
and deploy interceptors and actions.
David
Don Brown wrote:
What I mean is, with interceptors, you define them, but it is only when
you add them to an action are they actually used. Do you envision a
<result-selector> element going in every action, except when a
<default-result-selector> is defined for a package? How do you handle
multiple selectors? A selector chain? You'd still have these problems
with interceptors. How do you define the chain of selectors with
annotations at a global level?
Don
David H. DeWolf wrote:
If we used the <result-selector> element, how would you define
multiple ones? Just repeating the element wouldn't match the style of
other configuration elements. How would this look as one or more
annotations?
Really? Seems similar to me. I'm not suggesting that the
result-selector would replace the when attribute, instead, I'm
suggesting that we mimic:
<interceptor name="foo" class="o.a.s.i.FooInterceptor"/>
<interceptor name="bar" class="o.a.s.i.BarInterceptor"/>
<interceptor-stack name="myStack">
<interceptor-ref name="foo"/>
<interceptor-ref name="bar"/>
</interceptor-stack>
with:
<result-selector class="o.a.s.d.UserAgentResultSelector"/>
<action name="ViewFoo" class="mypackage.ViewFooAction">
<result name="success" when="modern-browser">foo.jsp</result>
<result name="success" when="netscape4">foo-ns4.jsp</result>
</action>
This basically allows for custom selectors to be registered. Like you
say, if they do not need to be scoped at the package/action level,
then you could definitely achieve the same thing with
struts.properties (pending the discussion of:
https://issues.apache.org/struts/browse/WW-1421).
It's really not a big deal, as long as I do have the ability to
register new implementations. My preference would be for that
configuration to be in the same location as where I specify all the
other custom components I've developed - either as attributes or in
struts.xml.
As far as attributes go, they render the configuration irrelevant. Am
I missing something?
@Selector
would simply replace the result-selector configuration.
@Result(name="success", when="modern-browser")
would replace the <result name="success" when="modern-browser">.
David
Don
David
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
