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 lik
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 <[EMAIL PROTECTED]> wrote:
I'd say result selector
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
Would it be XW-440?
* http://jira.opensymphony.com/browse/XW-440
-T.
On 11/21/06, Don Brown <[EMAIL PROTECTED]> 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
OK, do you remember how the WW-1393 feature works, or where we test it?
-Ted.
On 11/21/06, Don Brown <[EMAIL PROTECTED]> 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-
On 10/30/06, tm jee <[EMAIL PROTECTED]> wrote:
Is it possible to have something like
o.a.s.d.RoleMatcher
o.a.s.d.AgentMatchero.a.s.d.ServletDispatcherResult
so that we don't need to introduce another class attribute to the param tag.
Thoughts? :-)
Yes, that's what I meant to write
Hi guys,
Is it possible to have something like
o.a.s.d.RoleMatcher
o.a.s.d.AgentMatchero.a.s.d.ServletDispatcherResult
so that we don't need to introduce another class attribute to the param tag.
Thoughts? :-)
"David H. DeWolf" <[EMAIL PROTECTED]> wrote: YES! I like that. This
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 ;)
And AFAIR standart results/distpatchers already use
OGNL on supplied destinations, so this kind of
functionality could be
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 <[EMAIL PROTECTED]> wrote:
Then, each result selector is given a chance to select a single String.
If a result has
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 woul
On 10/26/06, Don Brown <[EMAIL PROTECTED]> 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
On 10/30/06, Konstantin Priblouda <[EMAIL PROTECTED]> 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 t
On 10/30/06, Alexandru Popescu <[EMAIL PROTECTED]> 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
--- Ted Husted <[EMAIL PROTECTED]> 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 m
On 10/30/06, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/28/06, Don Brown <[EMAIL PROTECTED]> 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 t
On 10/30/06, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/28/06, Don Brown <[EMAIL PROTECTED]> 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 t
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/28/06, Don Brown <[EMAIL PROTECTED]> 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 ab
On 10/28/06, Don Brown <[EMAIL PROTECTED]> 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 HT
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. Wheth
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 a
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
element going in every action, except when a
is defined for a package? How do you handle
multiple selectors? A selector chain? You'd still have these
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:
Seems to me like this type of configuration is very similar to the
in
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:
Seems to me like this type of configuration is very similar to the
interceptor configurat
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:
class="o.a.s.dispat
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:
class="o.a.s.dispatcher.ContentTypeResu
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
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.UserAgentResultS
On 10/26/06, Don Brown <[EMAIL PROTECTED]> 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 somet
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 res
On 10/26/06, Don Brown <[EMAIL PROTECTED]> 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 retur
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
v
31 matches
Mail list logo
