You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/10/26 20:17:23 UTC
[Proposal] Struts 2 Result Selectors
A result selector is a mechanism to select a result with a given result
code through some external means. This is a great feature stxx [1] has,
which I miss in Struts 2.
There are two main problems that this helps to solve:
1. You want do return different results based on the user's browser
version. For example, IE/Firefox users should get an advanced page with
a lot of Javascript and CSS, while older Netscape 4 browsers will get a
more simple page.
2. You want to return different results based on the type of request:
JSON, XML, or partial HTML. For example, if the request is for JSON
data, a result that serializes the data into JSON would be required.
For a partial HTML page, perhaps a different JSP would be used.
In both cases, you want to separate the selection of the result from the
Action. Currently, the action would have to determine, say, if the
browser is IE and return "success-ie". A better solution would be to
let the Action focus on what it does, returning "success", then let a
Result Selector determine which "success" result to process. For
example, the config might look like this:
<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>
Or in the second case:
<action name="ViewFoo" class="mypackage.ViewFooAction">
<result name="success" when="html">foo.jsp</result>
<result name="success" when="html-partial">foo-partial.jsp</result>
<result name="success" when="json" type="json" />
<result name="success" when="xml" type="xml" />
</action>
The value here is, again, your Action stays blissfully unaware of how it
will be rendered.
I haven't worked out all the details for how this would be implemented,
only that it would probably need to be put into XWork 2, and should
allow a chain of result selectors so that the two cases could be combined.
Still, I thought it would be worth getting some feedback. Does this
make sense? Do you think it is worth the new optional "when"
attribute? Is there any other cases this would help solve?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Konstantin Priblouda <kp...@yahoo.com>.
OK Ted, Result selector is real way to do.
It would not introduce any new configuration
( xwork config parser can be used ) and it can be made
flexible and extendable as <i do not know what> ;)
And AFAIR standart results/distpatchers already use
OGNL on supplied destinations, so this kind of
functionality could be achieved even without creating
additional result types.
--- Ted Husted <hu...@apache.org> wrote:
> Yes, but they map to a single path. A business
> result, like "success",
> "failure", and "exception", might map to a cluster
> of paths, depending
> on concerns like security role, locale, browser
> type, ajax mode, and
> so forth.
As said before, OGNL is possible, and if action takes
care about role (thouh there are better ways to do
this), it could as well take care ot result name
selection.
> We can use "presentation logic" in the server page
> or template, but if
> there are multiple concerns, the template becomes
> messy, and it starts
> to look like a hack.
If you start mixing concerns, you end up with an ugly
hack. Either in your action, or in tempklate -
it's just a matter of personal preference where you
like to have your mess ;)
> If we are willing to resolve all these concerns in
> the Action, the
> problem goes away. But, I think we agree that some
> of these concerns
> are outside the scope of the Action.
>
>
> > > But, what if there are flavors of success or
> > > failure?.
> >
> > ... they are kind of different results.
>
> Yes, and the difference is based on concerns that
> might be outside the
> scope of a business-orientated Action, so the Action
> has no clean way
> to select the correct result.
>
>
> > >As Don points
> > > out, we might want to present different pages
> based
> > > on the browser.
> >
> > What action got to do with it?
>
> The Action class itself should have nothing to do
> with it. But, the
> action element, which, in effect, encapsulates the
> paths, should be
> able to select from a cluster of paths, based on
> concerns outside the
> scope of the Action class.
>
>
> >
> > > Or, we might want to present different pages
> based
> > > on locale?
> > ... not an action business. result shall take care
> of
> > this ( like rewrite rules in httpd - call it
> > LocalAwareResult which pulls locale and , say,
> adds
> > proper suffix )
> > > Or based on security role?
> > ... again result could take this over. or even
> > template itself.>
> > > Do we want to cram all this into a single result
> > > code?
> >
> > yep. with proper results and maybe kind of
> > interceptors
>
> OK, the Result takes it over. But where do we
> encapsulate the paths,
> if not in the action element?
>
>
> > > return findResult("success");
> >
> >
> > Congratulation. You are describing ( somehow )
> > situation of struts-1 - action has to be aware of
> > servlet environment and take decisions based on
> it.
> > And how are you going to sumulate this in tests?
>
> Yes, this is a straw argument to illustrate the need
> to keep this code
> in the scope of a Result. But, if we do this in the
> scope of a Result,
> then we need a way to encapsulate the paths utilized
> by the Result.
Maybe it is rhetorically imperfect, but this situation
lead me away from using Struts 1 and switch to webwork
> > > But, in practice, this has proven to be a very
> > > common use case.
> > > There's the browser-agent case, the ajax-case,
> the
> > > localization-case,
> > > the security-roles case, to name a few. We often
> > > want to select a
> > > specialized result for the same general outcome
> > > ("success", "failure",
> > > "error", "exception", "login") .
> >
> > Why do it in action?
>
> Exactly. Better to do it in a type of Result that
> can be configured to
> accept a cluster of paths, like an Action, but
> focused on a different
> concern or set of concerns.
+1.
regards,
----[ Konstantin Pribluda http://www.pribluda.de ]----------------
Still using XDoclet 1.x? XDoclet 2 is released and of production quality.
check it out: http://xdoclet.codehaus.org
____________________________________________________________________________________
Get your email and see which of your friends are online - Right on the New Yahoo.com
(http://www.yahoo.com/preview)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/30/06, Konstantin Priblouda <kp...@yahoo.com> wrote:
> ... and struts2 action being xwork action does just
> this - no more or less. it performed business logic
> and determined outcome as string result name.
Agreed. The Action class should focus on business logic, and return a
result code that would map to a top-level box on a flow chart, marked
with labels like "success", "failure", and "exception".
> > Then, the Action returns a code that indicates
> > logical outcome. In
> > practice, the result code maps to a result that
> > encapsulates a path.
>
> it maps to some kind of result - it just happens that
> there are results now (mostly) which encapsulate a
> path.
Yes, but they map to a single path. A business result, like "success",
"failure", and "exception", might map to a cluster of paths, depending
on concerns like security role, locale, browser type, ajax mode, and
so forth.
We can use "presentation logic" in the server page or template, but if
there are multiple concerns, the template becomes messy, and it starts
to look like a hack.
If we are willing to resolve all these concerns in the Action, the
problem goes away. But, I think we agree that some of these concerns
are outside the scope of the Action.
> > But, what if there are flavors of success or
> > failure?.
>
> ... they are kind of different results.
Yes, and the difference is based on concerns that might be outside the
scope of a business-orientated Action, so the Action has no clean way
to select the correct result.
> >As Don points
> > out, we might want to present different pages based
> > on the browser.
>
> What action got to do with it?
The Action class itself should have nothing to do with it. But, the
action element, which, in effect, encapsulates the paths, should be
able to select from a cluster of paths, based on concerns outside the
scope of the Action class.
>
> > Or, we might want to present different pages based
> > on locale?
> ... not an action business. result shall take care of
> this ( like rewrite rules in httpd - call it
> LocalAwareResult which pulls locale and , say, adds
> proper suffix )
> > Or based on security role?
> ... again result could take this over. or even
> template itself.>
> > Do we want to cram all this into a single result
> > code?
>
> yep. with proper results and maybe kind of
> interceptors
OK, the Result takes it over. But where do we encapsulate the paths,
if not in the action element?
> > return findResult("success");
>
>
> Congratulation. You are describing ( somehow )
> situation of struts-1 - action has to be aware of
> servlet environment and take decisions based on it.
> And how are you going to sumulate this in tests?
Yes, this is a straw argument to illustrate the need to keep this code
in the scope of a Result. But, if we do this in the scope of a Result,
then we need a way to encapsulate the paths utilized by the Result.
> > But, in practice, this has proven to be a very
> > common use case.
> > There's the browser-agent case, the ajax-case, the
> > localization-case,
> > the security-roles case, to name a few. We often
> > want to select a
> > specialized result for the same general outcome
> > ("success", "failure",
> > "error", "exception", "login") .
>
> Why do it in action?
Exactly. Better to do it in a type of Result that can be configured to
accept a cluster of paths, like an Action, but focused on a different
concern or set of concerns.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> Yes, ideally the Action should be able to focus on
> the top-level
> outcome of the business logic. Did the request
> success or fail? Was
> there a recoverable error? A fatal exception?
... and struts2 action being xwork action does just
this - no more or less. it performed business logic
and determined outcome as string result name.
> Then, the Action returns a code that indicates
> logical outcome. In
> practice, the result code maps to a result that
> encapsulates a path.
it maps to some kind of result - it just happens that
there are results now (mostly) which encapsulate a
path.
> But, what if there are flavors of success or
> failure?.
... they are kind of different results.
>As Don points
> out, we might want to present different pages based
> on the browser.
What action got to do with it?
> Or, we might want to present different pages based
> on locale?
... not an action business. result shall take care of
this ( like rewrite rules in httpd - call it
LocalAwareResult which pulls locale and , say, adds
proper suffix )
> Or based on security role?
... again result could take this over. or even
template itself.
> Do we want to cram all this into a single result
> code?
yep. with proper results and maybe kind of
interceptors
> Of course, we _could_. One alternative would be to
> have codes like
>
> <action name="ViewFoo" class="mypackage.ViewFoo">
>
> <result
> name=""success.modern-browser">ViewFoo.jsp</result>
> <result
>
name="success.netscape4">ViewFoo-netscape4.jsp</result>
>
> <result
>
name="failure.modern-browser">ViewFoo-failure.jsp</result>
> <result
>
name="failure.netscape4">ViewFoo-netscape4-failure.jsp</result>
>
> <action>
>
> And, the selection logic would be delegated to a
> helper method that
> generated the token
>
> return findResult("success");
Congratulation. You are describing ( somehow )
situation of struts-1 - action has to be aware of
servlet environment and take decisions based on it.
And how are you going to sumulate this in tests?
> But, in practice, this has proven to be a very
> common use case.
> There's the browser-agent case, the ajax-case, the
> localization-case,
> the security-roles case, to name a few. We often
> want to select a
> specialized result for the same general outcome
> ("success", "failure",
> "error", "exception", "login") .
Why do it in action?
regards,
----[ Konstantin Pribluda http://www.pribluda.de ]----------------
Still using XDoclet 1.x? XDoclet 2 is released and of production quality.
check it out: http://xdoclet.codehaus.org
____________________________________________________________________________________
Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates
(http://voice.yahoo.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/30/06, Konstantin Priblouda <kp...@yahoo.com> wrote:
>
>
> --- Ted Husted <hu...@apache.org> wrote:
>
> > On 10/28/06, Don Brown <mr...@twdata.org> wrote:
> > > 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.
>
> In current situation action is not aware of result
> type. It just returns string result code.
Yes, ideally the Action should be able to focus on the top-level
outcome of the business logic. Did the request success or fail? Was
there a recoverable error? A fatal exception?
Then, the Action returns a code that indicates logical outcome. In
practice, the result code maps to a result that encapsulates a path.
But, what if there are flavors of success or failure?. As Don points
out, we might want to present different pages based on the browser.
Or, we might want to present different pages based on locale? Or based
on security role?
Do we want to cram all this into a single result code?
Of course, we _could_. One alternative would be to have codes like
<action name="ViewFoo" class="mypackage.ViewFoo">
<result name=""success.modern-browser">ViewFoo.jsp</result>
<result name="success.netscape4">ViewFoo-netscape4.jsp</result>
<result name="failure.modern-browser">ViewFoo-failure.jsp</result>
<result name="failure.netscape4">ViewFoo-netscape4-failure.jsp</result>
<action>
And, the selection logic would be delegated to a helper method that
generated the token
return findResult("success");
But, in practice, this has proven to be a very common use case.
There's the browser-agent case, the ajax-case, the localization-case,
the security-roles case, to name a few. We often want to select a
specialized result for the same general outcome ("success", "failure",
"error", "exception", "login") .
If we bury this logic in the Action, as I expect many of us do now,
then it's harder to share the code. But, if we elevate the use case to
a first-class feature, then we can share result selectors that solve
common use cases.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/30/06, Alexandru Popescu <th...@gmail.com> wrote:
> I quite agree with Konstantin. Adding more and more configuration
> stuff is not very good imo. In fact right now I am thinking/working
> about a light version of WW/Struts2 where the configuration is
> completely reduced (the biggest problem I have is with interceptors,
> for which I cannot figure out a way to deduce them from context :-( ).
+1 as to work on a light version. Feel free to commit whatever you
have to sandbox. :)
Though the existence of a light version shouldn't block work on the
"enterprise" version.
Simplifying configuration is a critical goal. One of the most
confusing parts of using frameworks like ours is the forrest of
configuration points. XML-here. Properties-there. :) This-name.
That-name. In my ladies' chamber :)
More than anything else, I believe we need a single source of
configuration that can be expressed as a single stream or in multiple
streams, as needed. But, whether single or multiple, it's the same
configuration strategy throughout. One configuration to rule them all.
Once we have one configuration, finding alternatives to XML would be a
simplier task, and it would be easier to be sure that the alternative
can do it all.
But, we should be careful that simplifying configuration does not
become an excuse for catering to the lowest common denominator. We
should continue to address the truly tough use cases facing enterprise
developers today. Elegant solutions to complex problems.
Both Struts 1 and Struts 2 give developers an excellent head-start. We
address many key use cases "out of the box", but there are still many
more to go.
Do we really have a truly excellent solution to presenting different
pages based on security role, or locale, or browser, ajax mode, or a
combination of all of these? If so, let's apply our strategy to the
Showcase, and show everyone how it is done.
Likewise, do we really have a truly excellent out-of-the-box solution
to create wizards, like the JIRA mass-edit wizard? Or, for loading
localized messages from a database (as Struts 1 can)? Or, for
providing fully customized versions of a single application to any
number of hosted clients? Or, for creating dynamic, validated input
forms based on a database result set? We've only just begun to scratch
the surface of what we need on-hand to create and maintain truly rich
enterprise-grade applications.
Don has expressed a complex problem, so what's the elegant solution?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Alexandru Popescu <th...@gmail.com>.
On 10/30/06, Konstantin Priblouda <kp...@yahoo.com> wrote:
>
>
> --- Ted Husted <hu...@apache.org> wrote:
>
> > On 10/28/06, Don Brown <mr...@twdata.org> wrote:
> > > 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.
>
> In current situation action is not aware of result
> type. It just returns string result code.
>
> > Then how about a "Result Controller" that can select
> > among possible
> > results, the same way that an Action can. The Action
> > can focus on the
> > business logic, and the Result Control can focus on
> > the view logic,
> > but they could others look and feel the same.
>
>
> > A single result controller could handle all the
> > selection logic for
> > the result code returned by the action.
> >
> > <result-selector name="agent"
> > class="o.a.s.d.UserAgentResultSelector"/>
> >
> > <action name="ViewFoo"
> > class="mypackage.ViewFooAction">
> >
> > <selector type="agent">
> > <result
> > name=""modern-browser">ViewFoo.jsp</result>
> > <result
> > name="netscape4">ViewFoo-netscape4.jsp</result>
> > </selector>
> >
> > <selector name="failure" type="agent">
> > <result
> > name=""modern-browser">ViewFoo-failure.jsp</result>
> > <result
> >
> name="netscape4">ViewFoo-netscape4-failure.jsp</result>
> > </selector>
>
> I do not think this use case is worth introducing
> new configuration stuff. You may as well use
> custom result type and pass parameters to it within
> vanilla xwork config.
>
I quite agree with Konstantin. Adding more and more configuration
stuff is not very good imo. In fact right now I am thinking/working
about a light version of WW/Struts2 where the configuration is
completely reduced (the biggest problem I have is with interceptors,
for which I cannot figure out a way to deduce them from context :-( ).
./alex
--
.w( the_mindstorm )p.
> regards,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> Still using XDoclet 1.x? XDoclet 2 is released and of production quality.
> check it out: http://xdoclet.codehaus.org
>
>
>
> __________________________________________________________________________________________
> Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster.
> (http://advision.webevents.yahoo.com/mailbeta)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> On 10/28/06, Don Brown <mr...@twdata.org> wrote:
> > 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.
In current situation action is not aware of result
type. It just returns string result code.
> Then how about a "Result Controller" that can select
> among possible
> results, the same way that an Action can. The Action
> can focus on the
> business logic, and the Result Control can focus on
> the view logic,
> but they could others look and feel the same.
> A single result controller could handle all the
> selection logic for
> the result code returned by the action.
>
> <result-selector name="agent"
> class="o.a.s.d.UserAgentResultSelector"/>
>
> <action name="ViewFoo"
> class="mypackage.ViewFooAction">
>
> <selector type="agent">
> <result
> name=""modern-browser">ViewFoo.jsp</result>
> <result
> name="netscape4">ViewFoo-netscape4.jsp</result>
> </selector>
>
> <selector name="failure" type="agent">
> <result
> name=""modern-browser">ViewFoo-failure.jsp</result>
> <result
>
name="netscape4">ViewFoo-netscape4-failure.jsp</result>
> </selector>
I do not think this use case is worth introducing
new configuration stuff. You may as well use
custom result type and pass parameters to it within
vanilla xwork config.
regards,
----[ Konstantin Pribluda http://www.pribluda.de ]----------------
Still using XDoclet 1.x? XDoclet 2 is released and of production quality.
check it out: http://xdoclet.codehaus.org
__________________________________________________________________________________________
Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster.
(http://advision.webevents.yahoo.com/mailbeta)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/28/06, Don Brown <mr...@twdata.org> wrote:
> 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.
Then how about a "Result Controller" that can select among possible
results, the same way that an Action can. The Action can focus on the
business logic, and the Result Control can focus on the view logic,
but they could others look and feel the same.
A single result controller could handle all the selection logic for
the result code returned by the action.
<result-selector name="agent" class="o.a.s.d.UserAgentResultSelector"/>
<action name="ViewFoo" class="mypackage.ViewFooAction">
<selector type="agent">
<result name=""modern-browser">ViewFoo.jsp</result>
<result name="netscape4">ViewFoo-netscape4.jsp</result>
</selector>
<selector name="failure" type="agent">
<result name=""modern-browser">ViewFoo-failure.jsp</result>
<result name="netscape4">ViewFoo-netscape4-failure.jsp</result>
</selector>
Of course, if a majority of the results were "agent", we could make
that type the default selector.
The result selector might just be a specialized kind of Action, with
the same capabilities, but simply assigned a speciallized role.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
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: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by "David H. DeWolf" <dd...@apache.org>.
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: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
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: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by "David H. DeWolf" <dd...@apache.org>.
Don Brown wrote:
> David H. DeWolf wrote:
>> That said, didn't I read somewhere that we're moving towards getting
>> rid of struts.properties? Wouldn't it be easier and more consistent
>> to just add the following to struts.xml:
>>
>> <result-selector class="o.a.s.dispatcher.ContentTypeResultSelector"/>
>>
>> Seems to me like this type of configuration is very similar to the
>> interceptor configuration and should be designed similarly.
> Actually, I'd prefer we went the other direction, get rid of the need
> for struts.xml, but maybe that's just me. The question is if they need
> to be configured on a package/action basis. If they can be done
> globally, then struts.properties is the better place. Otherwise,
> struts.xml would be a better fit.
>
Fair point, perhaps not. I'll have to think about that one.
> 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: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
David H. DeWolf wrote:
> That said, didn't I read somewhere that we're moving towards getting
> rid of struts.properties? Wouldn't it be easier and more consistent
> to just add the following to struts.xml:
>
> <result-selector class="o.a.s.dispatcher.ContentTypeResultSelector"/>
>
> Seems to me like this type of configuration is very similar to the
> interceptor configuration and should be designed similarly.
Actually, I'd prefer we went the other direction, get rid of the need
for struts.xml, but maybe that's just me. The question is if they need
to be configured on a package/action basis. If they can be done
globally, then struts.properties is the better place. Otherwise,
struts.xml would be a better fit.
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?
Don
>
>
> David
>
>
>>
>> Don
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by "David H. DeWolf" <dd...@apache.org>.
Don Brown wrote:
> David H. DeWolf wrote:
>> The first thing I noticed in this example is that there appears to be
>> a missing configuration section. Is it safe to assume that in order
>> to achieve extensibility you're thinking that selectors would be
>> configured something like:
>>
>> <result-selector name="html,html-partial,json,xml"
>> class="o.a.s.dispatcher.ContentTypeResultSelector/>
>>
> Well, I was wondering if you wouldn't even need this... Perhaps the
> possible token list would just be documented in the javadocs of the
> selector and in the user guide. You could specify the chain of
> selectors in struts.properties, and then, it would only be a
> comma-delimited list of class names.
Gotcha, to some extent :)
By using the chain, all selectors have the opportunity to participate
and thus (since they are passed the entire list of matching results)
don't need to have the condition explicitly configured. Makes great
sense, thanks for the clarification.
That said, didn't I read somewhere that we're moving towards getting rid
of struts.properties? Wouldn't it be easier and more consistent to just
add the following to struts.xml:
<result-selector class="o.a.s.dispatcher.ContentTypeResultSelector"/>
Seems to me like this type of configuration is very similar to the
interceptor configuration and should be designed similarly.
David
>
> Don
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
David H. DeWolf wrote:
> The first thing I noticed in this example is that there appears to be
> a missing configuration section. Is it safe to assume that in order
> to achieve extensibility you're thinking that selectors would be
> configured something like:
>
> <result-selector name="html,html-partial,json,xml"
> class="o.a.s.dispatcher.ContentTypeResultSelector/>
>
Well, I was wondering if you wouldn't even need this... Perhaps the
possible token list would just be documented in the javadocs of the
selector and in the user guide. You could specify the chain of
selectors in struts.properties, and then, it would only be a
comma-delimited list of class names.
Don
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by "David H. DeWolf" <dd...@apache.org>.
Don Brown wrote:
> In both cases, you want to separate the selection of the result from the
> Action. Currently, the action would have to determine, say, if the
> browser is IE and return "success-ie". A better solution would be to
> let the Action focus on what it does, returning "success", then let a
> Result Selector determine which "success" result to process. For
> example, the config might look like this:
> <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>
>
> Or in the second case:
> <action name="ViewFoo" class="mypackage.ViewFooAction">
> <result name="success" when="html">foo.jsp</result>
> <result name="success" when="html-partial">foo-partial.jsp</result>
> <result name="success" when="json" type="json" />
> <result name="success" when="xml" type="xml" />
> </action>
>
I definitely like the idea.
The first thing I noticed in this example is that there appears to be a
missing configuration section. Is it safe to assume that in order to
achieve extensibility you're thinking that selectors would be configured
something like:
<result-selector name="html,html-partial,json,xml"
class="o.a.s.dispatcher.ContentTypeResultSelector/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/30/06, tm jee <tm...@yahoo.co.uk> wrote:
> Is it possible to have something like
>
> <result-type name="selector" class="o.a..d.SelectorResult" >
> <param name="matchers">o.a.s.d.RoleMatcher</param>
> <param name="matchers">o.a.s.d.AgentMatcher</param
> <param name="wraps">o.a.s.d.ServletDispatcherResult</param>
> </result-type>
> so that we don't need to introduce another class attribute to the param tag. Thoughts? :-)
Yes, that's what I meant to write. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by tm jee <tm...@yahoo.co.uk>.
Hi guys,
Is it possible to have something like
<result-type name="selector" class="o.a..d.SelectorResult" >
<param name="matchers">o.a.s.d.RoleMatcher</param>
<param name="matchers">o.a.s.d.AgentMatcher</param
<param name="wraps">o.a.s.d.ServletDispatcherResult</param>
</result-type>
so that we don't need to introduce another class attribute to the param tag. Thoughts? :-)
"David H. DeWolf" <dd...@apache.org> wrote: YES! I like that. This seems to reduce the extra complexity from the
config but still provides the flexibility we're looking for.
David
Ted Husted wrote:
> On 10/26/06, Don Brown wrote:
>> Then, each result selector is given a chance to select a single String.
>> If a result has when="modern-browser,partial-html",
>> the each selector will be given a chance to return its "when" token, and
>> xwork will match them together as AND.
>
> Or, with wildcards ...
>
>
>
>
>
>
> /{1}{result-code}{role}{agent}.jsp
>
> /{1}-error.jsp
>
>
>
> Each "matcher" could add a named token into the context, like
> "-manager". The selector result could then resolve the wildcard path
> and delegate to another Result, like the default ServletDispatcher
> Result. The matchers might not inject a token, if it was the default
> or didn't apply for some reason.
>
> So, an application using this strategy might have pages named like.
>
> * ViewFoo.jsp
> * ViewFoo-netscape4.jsp
> * ViewFoo-manager.jsp
> * ViewFoo-manager-netscape4.jsp
> * ViewFoo-failure.jsp
>
> Of course, this strategy presupposes using something like SiteMesh or
> Tiles to provide the standard layout, so that each "page" can just
> focus on it's own content.
>
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [Proposal] Struts 2 Result Selectors
Posted by "David H. DeWolf" <dd...@apache.org>.
YES! I like that. This seems to reduce the extra complexity from the
config but still provides the flexibility we're looking for.
David
Ted Husted wrote:
> On 10/26/06, Don Brown <mr...@twdata.org> wrote:
>> Then, each result selector is given a chance to select a single String.
>> If a result has when="modern-browser,partial-html",
>> the each selector will be given a chance to return its "when" token, and
>> xwork will match them together as AND.
>
> Or, with wildcards ...
>
> <result-type name="selector" class="o.a..d.SelectorResult" >
> <param name="matchers" class="o.a.s.d.RoleMatcher">
> <param name="matchers" class="o.a.s.d.AgentMatcher">
> <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
> </result-type>
>
> <action name="*" class="mypackage.{1}">
>
> <result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
>
> <result name="error">/{1}-error.jsp</result>
>
> </action>
>
> Each "matcher" could add a named token into the context, like
> "-manager". The selector result could then resolve the wildcard path
> and delegate to another Result, like the default ServletDispatcher
> Result. The matchers might not inject a token, if it was the default
> or didn't apply for some reason.
>
> So, an application using this strategy might have pages named like.
>
> * ViewFoo.jsp
> * ViewFoo-netscape4.jsp
> * ViewFoo-manager.jsp
> * ViewFoo-manager-netscape4.jsp
> * ViewFoo-failure.jsp
>
> Of course, this strategy presupposes using something like SiteMesh or
> Tiles to provide the standard layout, so that each "page" can just
> focus on it's own content.
>
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
Just return a Result object, instead of a String. So...
public Result save() {
// do some stuff
return new ServletActionRedirectResult("someAction");
}
Only really valuable, IMO, for returning redirects to other actions, but
it could be taken advantage of in alternative Action implements like a
Struts 2 port of Struts Flow.
Don
Ted Husted wrote:
> OK, do you remember how the WW-1393 feature works, or where we test it?
>
> -Ted.
>
> On 11/21/06, Don Brown <mr...@twdata.org> wrote:
>> Nope, that's something different. Perhaps I didn't open up a ticket on
>> that, and just referred the commit to the struts one.
>>
>> Don
>>
>> Ted Husted wrote:
>> > Would it be XW-440?
>> >
>> > * http://jira.opensymphony.com/browse/XW-440
>> >
>> > -T.
>> >
>> > On 11/21/06, Don Brown <mr...@twdata.org> wrote:
>> >> I'd say result selectors and WW-1393 are different. WW-1393 has been
>> >> implemented, but result selectors have not, AFAIK. I don't
>> remember the
>> >> XWork ticket, off-hand, but the change involved
>> DefaultActionInvocation
>> >> I believe.
>> >>
>> >> Don
>> >>
>> >> Ted Husted wrote:
>> >> > Is "Result Selectors" what was covered by WW-1393?
>> >> >
>> >> > * http://issues.apache.org/struts/browse/WW-1393
>> >> >
>> >> > Or, was that a different feature?
>> >> >
>> >> > Our WW-1393 says it was handled on the XWork end, but doesn't
>> cite a
>> >> > ticket. I don't know what we actually did.
>> >> >
>> >> > Did we
>> >> >
>> >> > * Implement result selectors?
>> >> >
>> >> > * Implement " Returning Result directly"?
>> >> >
>> >> > Or, are they the same thing?
>> >> >
>> >> > -Ted.
>> >> >
>> >> > On 10/30/06, Don Brown <mr...@twdata.org> wrote:
>> >> >> I really, really, like this idea, especially since it doesn't
>> >> introduce
>> >> >> any new syntax or complications for the 90% of users that don't
>> need
>> >> >> this. The more we can keep Struts/XWork to simple, internal
>> >> components,
>> >> >> the easier it will be to worth with both as a user and as a
>> >> developer.
>> >> >>
>> >> >> This would make a nice plugin with default result types for common
>> >> >> situations.
>> >> >>
>> >> >> Don
>> >> >>
>> >> >> Ted Husted wrote:
>> >> >> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
>> >> >> >> Then, each result selector is given a chance to select a single
>> >> >> String.
>> >> >> >> If a result has when="modern-browser,partial-html",
>> >> >> >> the each selector will be given a chance to return its "when"
>> >> >> token, and
>> >> >> >> xwork will match them together as AND.
>> >> >> >
>> >> >> > Or, with wildcards ...
>> >> >> >
>> >> >> > <result-type name="selector" class="o.a..d.SelectorResult" >
>> >> >> > <param name="matchers" class="o.a.s.d.RoleMatcher">
>> >> >> > <param name="matchers" class="o.a.s.d.AgentMatcher">
>> >> >> > <param name="wraps"
>> class="o.a.s.d.ServletDispatcherResult>
>> >> >> > </result-type>
>> >> >> >
>> >> >> > <action name="*" class="mypackage.{1}">
>> >> >> >
>> >> >> > <result
>> >> type="selector">/{1}{result-code}{role}{agent}.jsp</result>
>> >> >> >
>> >> >> > <result name="error">/{1}-error.jsp</result>
>> >> >> >
>> >> >> > </action>
>> >> >> >
>> >> >> > Each "matcher" could add a named token into the context, like
>> >> >> > "-manager". The selector result could then resolve the wildcard
>> >> path
>> >> >> > and delegate to another Result, like the default
>> ServletDispatcher
>> >> >> > Result. The matchers might not inject a token, if it was the
>> >> default
>> >> >> > or didn't apply for some reason.
>> >> >> >
>> >> >> > So, an application using this strategy might have pages named
>> like.
>> >> >> >
>> >> >> > * ViewFoo.jsp
>> >> >> > * ViewFoo-netscape4.jsp
>> >> >> > * ViewFoo-manager.jsp
>> >> >> > * ViewFoo-manager-netscape4.jsp
>> >> >> > * ViewFoo-failure.jsp
>> >> >> >
>> >> >> > Of course, this strategy presupposes using something like
>> >> SiteMesh or
>> >> >> > Tiles to provide the standard layout, so that each "page" can
>> just
>> >> >> > focus on it's own content.
>> >> >> >
>> >> >> > -T.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
OK, do you remember how the WW-1393 feature works, or where we test it?
-Ted.
On 11/21/06, Don Brown <mr...@twdata.org> wrote:
> Nope, that's something different. Perhaps I didn't open up a ticket on
> that, and just referred the commit to the struts one.
>
> Don
>
> Ted Husted wrote:
> > Would it be XW-440?
> >
> > * http://jira.opensymphony.com/browse/XW-440
> >
> > -T.
> >
> > On 11/21/06, Don Brown <mr...@twdata.org> wrote:
> >> I'd say result selectors and WW-1393 are different. WW-1393 has been
> >> implemented, but result selectors have not, AFAIK. I don't remember the
> >> XWork ticket, off-hand, but the change involved DefaultActionInvocation
> >> I believe.
> >>
> >> Don
> >>
> >> Ted Husted wrote:
> >> > Is "Result Selectors" what was covered by WW-1393?
> >> >
> >> > * http://issues.apache.org/struts/browse/WW-1393
> >> >
> >> > Or, was that a different feature?
> >> >
> >> > Our WW-1393 says it was handled on the XWork end, but doesn't cite a
> >> > ticket. I don't know what we actually did.
> >> >
> >> > Did we
> >> >
> >> > * Implement result selectors?
> >> >
> >> > * Implement " Returning Result directly"?
> >> >
> >> > Or, are they the same thing?
> >> >
> >> > -Ted.
> >> >
> >> > On 10/30/06, Don Brown <mr...@twdata.org> wrote:
> >> >> I really, really, like this idea, especially since it doesn't
> >> introduce
> >> >> any new syntax or complications for the 90% of users that don't need
> >> >> this. The more we can keep Struts/XWork to simple, internal
> >> components,
> >> >> the easier it will be to worth with both as a user and as a
> >> developer.
> >> >>
> >> >> This would make a nice plugin with default result types for common
> >> >> situations.
> >> >>
> >> >> Don
> >> >>
> >> >> Ted Husted wrote:
> >> >> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> >> >> >> Then, each result selector is given a chance to select a single
> >> >> String.
> >> >> >> If a result has when="modern-browser,partial-html",
> >> >> >> the each selector will be given a chance to return its "when"
> >> >> token, and
> >> >> >> xwork will match them together as AND.
> >> >> >
> >> >> > Or, with wildcards ...
> >> >> >
> >> >> > <result-type name="selector" class="o.a..d.SelectorResult" >
> >> >> > <param name="matchers" class="o.a.s.d.RoleMatcher">
> >> >> > <param name="matchers" class="o.a.s.d.AgentMatcher">
> >> >> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
> >> >> > </result-type>
> >> >> >
> >> >> > <action name="*" class="mypackage.{1}">
> >> >> >
> >> >> > <result
> >> type="selector">/{1}{result-code}{role}{agent}.jsp</result>
> >> >> >
> >> >> > <result name="error">/{1}-error.jsp</result>
> >> >> >
> >> >> > </action>
> >> >> >
> >> >> > Each "matcher" could add a named token into the context, like
> >> >> > "-manager". The selector result could then resolve the wildcard
> >> path
> >> >> > and delegate to another Result, like the default ServletDispatcher
> >> >> > Result. The matchers might not inject a token, if it was the
> >> default
> >> >> > or didn't apply for some reason.
> >> >> >
> >> >> > So, an application using this strategy might have pages named like.
> >> >> >
> >> >> > * ViewFoo.jsp
> >> >> > * ViewFoo-netscape4.jsp
> >> >> > * ViewFoo-manager.jsp
> >> >> > * ViewFoo-manager-netscape4.jsp
> >> >> > * ViewFoo-failure.jsp
> >> >> >
> >> >> > Of course, this strategy presupposes using something like
> >> SiteMesh or
> >> >> > Tiles to provide the standard layout, so that each "page" can just
> >> >> > focus on it's own content.
> >> >> >
> >> >> > -T.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
Nope, that's something different. Perhaps I didn't open up a ticket on
that, and just referred the commit to the struts one.
Don
Ted Husted wrote:
> Would it be XW-440?
>
> * http://jira.opensymphony.com/browse/XW-440
>
> -T.
>
> On 11/21/06, Don Brown <mr...@twdata.org> wrote:
>> I'd say result selectors and WW-1393 are different. WW-1393 has been
>> implemented, but result selectors have not, AFAIK. I don't remember the
>> XWork ticket, off-hand, but the change involved DefaultActionInvocation
>> I believe.
>>
>> Don
>>
>> Ted Husted wrote:
>> > Is "Result Selectors" what was covered by WW-1393?
>> >
>> > * http://issues.apache.org/struts/browse/WW-1393
>> >
>> > Or, was that a different feature?
>> >
>> > Our WW-1393 says it was handled on the XWork end, but doesn't cite a
>> > ticket. I don't know what we actually did.
>> >
>> > Did we
>> >
>> > * Implement result selectors?
>> >
>> > * Implement " Returning Result directly"?
>> >
>> > Or, are they the same thing?
>> >
>> > -Ted.
>> >
>> > On 10/30/06, Don Brown <mr...@twdata.org> wrote:
>> >> I really, really, like this idea, especially since it doesn't
>> introduce
>> >> any new syntax or complications for the 90% of users that don't need
>> >> this. The more we can keep Struts/XWork to simple, internal
>> components,
>> >> the easier it will be to worth with both as a user and as a
>> developer.
>> >>
>> >> This would make a nice plugin with default result types for common
>> >> situations.
>> >>
>> >> Don
>> >>
>> >> Ted Husted wrote:
>> >> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
>> >> >> Then, each result selector is given a chance to select a single
>> >> String.
>> >> >> If a result has when="modern-browser,partial-html",
>> >> >> the each selector will be given a chance to return its "when"
>> >> token, and
>> >> >> xwork will match them together as AND.
>> >> >
>> >> > Or, with wildcards ...
>> >> >
>> >> > <result-type name="selector" class="o.a..d.SelectorResult" >
>> >> > <param name="matchers" class="o.a.s.d.RoleMatcher">
>> >> > <param name="matchers" class="o.a.s.d.AgentMatcher">
>> >> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
>> >> > </result-type>
>> >> >
>> >> > <action name="*" class="mypackage.{1}">
>> >> >
>> >> > <result
>> type="selector">/{1}{result-code}{role}{agent}.jsp</result>
>> >> >
>> >> > <result name="error">/{1}-error.jsp</result>
>> >> >
>> >> > </action>
>> >> >
>> >> > Each "matcher" could add a named token into the context, like
>> >> > "-manager". The selector result could then resolve the wildcard
>> path
>> >> > and delegate to another Result, like the default ServletDispatcher
>> >> > Result. The matchers might not inject a token, if it was the
>> default
>> >> > or didn't apply for some reason.
>> >> >
>> >> > So, an application using this strategy might have pages named like.
>> >> >
>> >> > * ViewFoo.jsp
>> >> > * ViewFoo-netscape4.jsp
>> >> > * ViewFoo-manager.jsp
>> >> > * ViewFoo-manager-netscape4.jsp
>> >> > * ViewFoo-failure.jsp
>> >> >
>> >> > Of course, this strategy presupposes using something like
>> SiteMesh or
>> >> > Tiles to provide the standard layout, so that each "page" can just
>> >> > focus on it's own content.
>> >> >
>> >> > -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
Would it be XW-440?
* http://jira.opensymphony.com/browse/XW-440
-T.
On 11/21/06, Don Brown <mr...@twdata.org> wrote:
> I'd say result selectors and WW-1393 are different. WW-1393 has been
> implemented, but result selectors have not, AFAIK. I don't remember the
> XWork ticket, off-hand, but the change involved DefaultActionInvocation
> I believe.
>
> Don
>
> Ted Husted wrote:
> > Is "Result Selectors" what was covered by WW-1393?
> >
> > * http://issues.apache.org/struts/browse/WW-1393
> >
> > Or, was that a different feature?
> >
> > Our WW-1393 says it was handled on the XWork end, but doesn't cite a
> > ticket. I don't know what we actually did.
> >
> > Did we
> >
> > * Implement result selectors?
> >
> > * Implement " Returning Result directly"?
> >
> > Or, are they the same thing?
> >
> > -Ted.
> >
> > On 10/30/06, Don Brown <mr...@twdata.org> wrote:
> >> I really, really, like this idea, especially since it doesn't introduce
> >> any new syntax or complications for the 90% of users that don't need
> >> this. The more we can keep Struts/XWork to simple, internal components,
> >> the easier it will be to worth with both as a user and as a developer.
> >>
> >> This would make a nice plugin with default result types for common
> >> situations.
> >>
> >> Don
> >>
> >> Ted Husted wrote:
> >> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> >> >> Then, each result selector is given a chance to select a single
> >> String.
> >> >> If a result has when="modern-browser,partial-html",
> >> >> the each selector will be given a chance to return its "when"
> >> token, and
> >> >> xwork will match them together as AND.
> >> >
> >> > Or, with wildcards ...
> >> >
> >> > <result-type name="selector" class="o.a..d.SelectorResult" >
> >> > <param name="matchers" class="o.a.s.d.RoleMatcher">
> >> > <param name="matchers" class="o.a.s.d.AgentMatcher">
> >> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
> >> > </result-type>
> >> >
> >> > <action name="*" class="mypackage.{1}">
> >> >
> >> > <result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
> >> >
> >> > <result name="error">/{1}-error.jsp</result>
> >> >
> >> > </action>
> >> >
> >> > Each "matcher" could add a named token into the context, like
> >> > "-manager". The selector result could then resolve the wildcard path
> >> > and delegate to another Result, like the default ServletDispatcher
> >> > Result. The matchers might not inject a token, if it was the default
> >> > or didn't apply for some reason.
> >> >
> >> > So, an application using this strategy might have pages named like.
> >> >
> >> > * ViewFoo.jsp
> >> > * ViewFoo-netscape4.jsp
> >> > * ViewFoo-manager.jsp
> >> > * ViewFoo-manager-netscape4.jsp
> >> > * ViewFoo-failure.jsp
> >> >
> >> > Of course, this strategy presupposes using something like SiteMesh or
> >> > Tiles to provide the standard layout, so that each "page" can just
> >> > focus on it's own content.
> >> >
> >> > -T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
I'd say result selectors and WW-1393 are different. WW-1393 has been
implemented, but result selectors have not, AFAIK. I don't remember the
XWork ticket, off-hand, but the change involved DefaultActionInvocation
I believe.
Don
Ted Husted wrote:
> Is "Result Selectors" what was covered by WW-1393?
>
> * http://issues.apache.org/struts/browse/WW-1393
>
> Or, was that a different feature?
>
> Our WW-1393 says it was handled on the XWork end, but doesn't cite a
> ticket. I don't know what we actually did.
>
> Did we
>
> * Implement result selectors?
>
> * Implement " Returning Result directly"?
>
> Or, are they the same thing?
>
> -Ted.
>
> On 10/30/06, Don Brown <mr...@twdata.org> wrote:
>> I really, really, like this idea, especially since it doesn't introduce
>> any new syntax or complications for the 90% of users that don't need
>> this. The more we can keep Struts/XWork to simple, internal components,
>> the easier it will be to worth with both as a user and as a developer.
>>
>> This would make a nice plugin with default result types for common
>> situations.
>>
>> Don
>>
>> Ted Husted wrote:
>> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
>> >> Then, each result selector is given a chance to select a single
>> String.
>> >> If a result has when="modern-browser,partial-html",
>> >> the each selector will be given a chance to return its "when"
>> token, and
>> >> xwork will match them together as AND.
>> >
>> > Or, with wildcards ...
>> >
>> > <result-type name="selector" class="o.a..d.SelectorResult" >
>> > <param name="matchers" class="o.a.s.d.RoleMatcher">
>> > <param name="matchers" class="o.a.s.d.AgentMatcher">
>> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
>> > </result-type>
>> >
>> > <action name="*" class="mypackage.{1}">
>> >
>> > <result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
>> >
>> > <result name="error">/{1}-error.jsp</result>
>> >
>> > </action>
>> >
>> > Each "matcher" could add a named token into the context, like
>> > "-manager". The selector result could then resolve the wildcard path
>> > and delegate to another Result, like the default ServletDispatcher
>> > Result. The matchers might not inject a token, if it was the default
>> > or didn't apply for some reason.
>> >
>> > So, an application using this strategy might have pages named like.
>> >
>> > * ViewFoo.jsp
>> > * ViewFoo-netscape4.jsp
>> > * ViewFoo-manager.jsp
>> > * ViewFoo-manager-netscape4.jsp
>> > * ViewFoo-failure.jsp
>> >
>> > Of course, this strategy presupposes using something like SiteMesh or
>> > Tiles to provide the standard layout, so that each "page" can just
>> > focus on it's own content.
>> >
>> > -T.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
Is "Result Selectors" what was covered by WW-1393?
* http://issues.apache.org/struts/browse/WW-1393
Or, was that a different feature?
Our WW-1393 says it was handled on the XWork end, but doesn't cite a
ticket. I don't know what we actually did.
Did we
* Implement result selectors?
* Implement " Returning Result directly"?
Or, are they the same thing?
-Ted.
On 10/30/06, Don Brown <mr...@twdata.org> wrote:
> I really, really, like this idea, especially since it doesn't introduce
> any new syntax or complications for the 90% of users that don't need
> this. The more we can keep Struts/XWork to simple, internal components,
> the easier it will be to worth with both as a user and as a developer.
>
> This would make a nice plugin with default result types for common
> situations.
>
> Don
>
> Ted Husted wrote:
> > On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> >> Then, each result selector is given a chance to select a single String.
> >> If a result has when="modern-browser,partial-html",
> >> the each selector will be given a chance to return its "when" token, and
> >> xwork will match them together as AND.
> >
> > Or, with wildcards ...
> >
> > <result-type name="selector" class="o.a..d.SelectorResult" >
> > <param name="matchers" class="o.a.s.d.RoleMatcher">
> > <param name="matchers" class="o.a.s.d.AgentMatcher">
> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
> > </result-type>
> >
> > <action name="*" class="mypackage.{1}">
> >
> > <result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
> >
> > <result name="error">/{1}-error.jsp</result>
> >
> > </action>
> >
> > Each "matcher" could add a named token into the context, like
> > "-manager". The selector result could then resolve the wildcard path
> > and delegate to another Result, like the default ServletDispatcher
> > Result. The matchers might not inject a token, if it was the default
> > or didn't apply for some reason.
> >
> > So, an application using this strategy might have pages named like.
> >
> > * ViewFoo.jsp
> > * ViewFoo-netscape4.jsp
> > * ViewFoo-manager.jsp
> > * ViewFoo-manager-netscape4.jsp
> > * ViewFoo-failure.jsp
> >
> > Of course, this strategy presupposes using something like SiteMesh or
> > Tiles to provide the standard layout, so that each "page" can just
> > focus on it's own content.
> >
> > -T.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
I really, really, like this idea, especially since it doesn't introduce
any new syntax or complications for the 90% of users that don't need
this. The more we can keep Struts/XWork to simple, internal components,
the easier it will be to worth with both as a user and as a developer.
This would make a nice plugin with default result types for common
situations.
Don
Ted Husted wrote:
> On 10/26/06, Don Brown <mr...@twdata.org> wrote:
>> Then, each result selector is given a chance to select a single String.
>> If a result has when="modern-browser,partial-html",
>> the each selector will be given a chance to return its "when" token, and
>> xwork will match them together as AND.
>
> Or, with wildcards ...
>
> <result-type name="selector" class="o.a..d.SelectorResult" >
> <param name="matchers" class="o.a.s.d.RoleMatcher">
> <param name="matchers" class="o.a.s.d.AgentMatcher">
> <param name="wraps" class="o.a.s.d.ServletDispatcherResult>
> </result-type>
>
> <action name="*" class="mypackage.{1}">
>
> <result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
>
> <result name="error">/{1}-error.jsp</result>
>
> </action>
>
> Each "matcher" could add a named token into the context, like
> "-manager". The selector result could then resolve the wildcard path
> and delegate to another Result, like the default ServletDispatcher
> Result. The matchers might not inject a token, if it was the default
> or didn't apply for some reason.
>
> So, an application using this strategy might have pages named like.
>
> * ViewFoo.jsp
> * ViewFoo-netscape4.jsp
> * ViewFoo-manager.jsp
> * ViewFoo-manager-netscape4.jsp
> * ViewFoo-failure.jsp
>
> Of course, this strategy presupposes using something like SiteMesh or
> Tiles to provide the standard layout, so that each "page" can just
> focus on it's own content.
>
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Ted Husted <hu...@apache.org>.
On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> Then, each result selector is given a chance to select a single String.
> If a result has when="modern-browser,partial-html",
> the each selector will be given a chance to return its "when" token, and
> xwork will match them together as AND.
Or, with wildcards ...
<result-type name="selector" class="o.a..d.SelectorResult" >
<param name="matchers" class="o.a.s.d.RoleMatcher">
<param name="matchers" class="o.a.s.d.AgentMatcher">
<param name="wraps" class="o.a.s.d.ServletDispatcherResult>
</result-type>
<action name="*" class="mypackage.{1}">
<result type="selector">/{1}{result-code}{role}{agent}.jsp</result>
<result name="error">/{1}-error.jsp</result>
</action>
Each "matcher" could add a named token into the context, like
"-manager". The selector result could then resolve the wildcard path
and delegate to another Result, like the default ServletDispatcher
Result. The matchers might not inject a token, if it was the default
or didn't apply for some reason.
So, an application using this strategy might have pages named like.
* ViewFoo.jsp
* ViewFoo-netscape4.jsp
* ViewFoo-manager.jsp
* ViewFoo-manager-netscape4.jsp
* ViewFoo-failure.jsp
Of course, this strategy presupposes using something like SiteMesh or
Tiles to provide the standard layout, so that each "page" can just
focus on it's own content.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
Alexandru Popescu wrote:
>> As for the implementation of selectors, I'm thinking of something like:
>>
>> public interface ResultSelector {
>> public ResultConfig chooseResult(String resultCode, List
>> matchingResultConfigs, ActionInvocation inv);
>> }
>>
>> then you could have:
>> * o.a.s.dispatcher.UserAgentResultSelector
>> * o.a.s.dispatcher.ContentTypeResultSelector
>> * o.a.s.dispatcher.RequestAttributeResultSelector
>>
>> and so on. Perhaps these would be executed in a chain, such that the
>> user agent selector would get the first shot, but if not found, return
>> null, so the content type selector is called next, and so on.
>>
>
> This may be a good start, but how will this deal with the case when
> the result depends on 2 (or more conditions)?
>
Well, it wouldn't in that version. What if we turned it around so that
the selector looked like this:
public interface ResultSelector {
public String determineWhen(ActionInvocation inv);
}
Then, each result selector is given a chance to select a single String.
If a result has when="modern-browser,partial-html",
the each selector will be given a chance to return its "when" token, and
xwork will match them together as AND.
Don
> ./alex
> --
> .w( the_mindstorm )p.
>
>> Don
>>
>> Alexandru Popescu wrote:
>> > At the first glance the idea looks interesting, but I am wondering if
>> > this is not just a matter of having a custom result type; because I
>> > cannot image a way to cover any possible "when" case.
>> >
>> > ./alex
>> > --
>> > .w( the_mindstorm )p.
>> >
>> >> Don
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Alexandru Popescu <th...@gmail.com>.
On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> Hmm... I suppose you could create a selector result, which would
> delegate handling to other results, but how would those results be
> configured?
>
true... this would not be extendible
> As for the implementation of selectors, I'm thinking of something like:
>
> public interface ResultSelector {
> public ResultConfig chooseResult(String resultCode, List
> matchingResultConfigs, ActionInvocation inv);
> }
>
> then you could have:
> * o.a.s.dispatcher.UserAgentResultSelector
> * o.a.s.dispatcher.ContentTypeResultSelector
> * o.a.s.dispatcher.RequestAttributeResultSelector
>
> and so on. Perhaps these would be executed in a chain, such that the
> user agent selector would get the first shot, but if not found, return
> null, so the content type selector is called next, and so on.
>
This may be a good start, but how will this deal with the case when
the result depends on 2 (or more conditions)?
./alex
--
.w( the_mindstorm )p.
> Don
>
> Alexandru Popescu wrote:
> > At the first glance the idea looks interesting, but I am wondering if
> > this is not just a matter of having a custom result type; because I
> > cannot image a way to cover any possible "when" case.
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >> Don
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Don Brown <mr...@twdata.org>.
Hmm... I suppose you could create a selector result, which would
delegate handling to other results, but how would those results be
configured?
As for the implementation of selectors, I'm thinking of something like:
public interface ResultSelector {
public ResultConfig chooseResult(String resultCode, List
matchingResultConfigs, ActionInvocation inv);
}
then you could have:
* o.a.s.dispatcher.UserAgentResultSelector
* o.a.s.dispatcher.ContentTypeResultSelector
* o.a.s.dispatcher.RequestAttributeResultSelector
and so on. Perhaps these would be executed in a chain, such that the
user agent selector would get the first shot, but if not found, return
null, so the content type selector is called next, and so on.
Don
Alexandru Popescu wrote:
> At the first glance the idea looks interesting, but I am wondering if
> this is not just a matter of having a custom result type; because I
> cannot image a way to cover any possible "when" case.
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts 2 Result Selectors
Posted by Alexandru Popescu <th...@gmail.com>.
On 10/26/06, Don Brown <mr...@twdata.org> wrote:
> A result selector is a mechanism to select a result with a given result
> code through some external means. This is a great feature stxx [1] has,
> which I miss in Struts 2.
>
> There are two main problems that this helps to solve:
> 1. You want do return different results based on the user's browser
> version. For example, IE/Firefox users should get an advanced page with
> a lot of Javascript and CSS, while older Netscape 4 browsers will get a
> more simple page.
> 2. You want to return different results based on the type of request:
> JSON, XML, or partial HTML. For example, if the request is for JSON
> data, a result that serializes the data into JSON would be required.
> For a partial HTML page, perhaps a different JSP would be used.
>
> In both cases, you want to separate the selection of the result from the
> Action. Currently, the action would have to determine, say, if the
> browser is IE and return "success-ie". A better solution would be to
> let the Action focus on what it does, returning "success", then let a
> Result Selector determine which "success" result to process. For
> example, the config might look like this:
> <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>
>
> Or in the second case:
> <action name="ViewFoo" class="mypackage.ViewFooAction">
> <result name="success" when="html">foo.jsp</result>
> <result name="success" when="html-partial">foo-partial.jsp</result>
> <result name="success" when="json" type="json" />
> <result name="success" when="xml" type="xml" />
> </action>
>
> The value here is, again, your Action stays blissfully unaware of how it
> will be rendered.
>
> I haven't worked out all the details for how this would be implemented,
> only that it would probably need to be put into XWork 2, and should
> allow a chain of result selectors so that the two cases could be combined.
>
> Still, I thought it would be worth getting some feedback. Does this
> make sense? Do you think it is worth the new optional "when"
> attribute? Is there any other cases this would help solve?
>
At the first glance the idea looks interesting, but I am wondering if
this is not just a matter of having a custom result type; because I
cannot image a way to cover any possible "when" case.
./alex
--
.w( the_mindstorm )p.
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org