Well, my original purpose is to find a way to best handle the case where
we want to generate multiple types of output without the Action being
aware of it. Foremost in my mind is the ability to have an action be
called and expect HTML, partial HTML, or JSON without affecting the
Action. Whether it is easy for the end user to add their own result
selectors or not is secondary. In fact, there would be much fewer times
that you would want to implement your own, so I'm fine putting it in
struts.properties along with the other factories.
Don
David H. DeWolf wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
