You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by st...@gmail.com on 2007/04/09 19:50:12 UTC
S2 Request Lifecycle
I have an interesting situation occurring but let me first ask how the
request lifecycle differs between returning INPUT or SUCCESS from an action
method. Consider this action mapping:
<action name="course_*" method="{1}" class="course">
<result name="input">/pages/course.jsp</result>
<result>/pages/course.jsp</result>
</action>
--
Scott
stanlick@gmail.com
Re: S2 Request Lifecycle
Posted by Ted Husted <hu...@apache.org>.
If validation fails, then the original input values are pushed onto
the stack, so that the tags can present the input values. If the
Action or Model properties were different, then the original input
properties would still be presented by the tags, because the original
input properties were the last one's pushed on to the stack. If for
some reason, a different value needed to be displayed for the original
invalid input, the solution would be to push the wanted values onto
the stack, so that they are the first ones found.,
On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> Then is something reloading the properties back into the bean if the action
> method returns INPUT?
>
> On 4/9/07, Ted Husted <hu...@apache.org> wrote:
> >
> > It shouldn't. The interceptor only autowires become the action invocation.
> > http://svn.opensymphony.com/fisheye/browse/xwork/trunk/src/java/com/opensymphony/xwork2/spring/interceptor/ActionAutowiringInterceptor.java?r=1063
> >
> > -T.
> >
> > On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > > Sorry Ted!
> > >
> > > I should have been more clear with my question. Does S2 leverage Spring
> > in
> > > such a way as so fetch a new Action bean when the Action method returns
> > > SUCCESS? It appears a new bean is being injected into my Action when a
> > > method returns SUCCESS.
> > >
> > > Scott
> > >
> > > On 4/9/07, Ted Husted <hu...@apache.org> wrote:
> > > >
> > > > By default, "input" is one of the magic methods that bypass
> > > > validation. In the case of a request for the input method, validation
> > > > is not applied, and input is returned. In the case of request for the
> > > > default execute/success method, input would be returned if validation
> > > > fails, and success returned if validation succeeds. Of course, if an
> > > > exception is thrown, then the exception handling would apply instead.
> > > >
> > > > HTH, Ted
> > > > <http://www.husted.com/ted/blog/>
> > > >
> > > > On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > > > > I have an interesting situation occurring but let me first ask how
> > the
> > > > > request lifecycle differs between returning INPUT or SUCCESS from an
> > > > action
> > > > > method. Consider this action mapping:
> > > > >
> > > > > <action name="course_*" method="{1}" class="course">
> > > > > <result name="input">/pages/course.jsp</result>
> > > > > <result>/pages/course.jsp</result>
> > > > > </action>
> > > > > --
> > > > > Scott
> > > > > stanlick@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 Request Lifecycle
Posted by st...@gmail.com.
Then is something reloading the properties back into the bean if the action
method returns INPUT?
On 4/9/07, Ted Husted <hu...@apache.org> wrote:
>
> It shouldn't. The interceptor only autowires become the action invocation.
>
>
> http://svn.opensymphony.com/fisheye/browse/xwork/trunk/src/java/com/opensymphony/xwork2/spring/interceptor/ActionAutowiringInterceptor.java?r=1063
>
> -T.
>
> On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > Sorry Ted!
> >
> > I should have been more clear with my question. Does S2 leverage Spring
> in
> > such a way as so fetch a new Action bean when the Action method returns
> > SUCCESS? It appears a new bean is being injected into my Action when a
> > method returns SUCCESS.
> >
> > Scott
> >
> > On 4/9/07, Ted Husted <hu...@apache.org> wrote:
> > >
> > > By default, "input" is one of the magic methods that bypass
> > > validation. In the case of a request for the input method, validation
> > > is not applied, and input is returned. In the case of request for the
> > > default execute/success method, input would be returned if validation
> > > fails, and success returned if validation succeeds. Of course, if an
> > > exception is thrown, then the exception handling would apply instead.
> > >
> > > HTH, Ted
> > > <http://www.husted.com/ted/blog/>
> > >
> > > On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > > > I have an interesting situation occurring but let me first ask how
> the
> > > > request lifecycle differs between returning INPUT or SUCCESS from an
> > > action
> > > > method. Consider this action mapping:
> > > >
> > > > <action name="course_*" method="{1}" class="course">
> > > > <result name="input">/pages/course.jsp</result>
> > > > <result>/pages/course.jsp</result>
> > > > </action>
> > > > --
> > > > Scott
> > > > stanlick@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: S2 Request Lifecycle
Posted by Ted Husted <hu...@apache.org>.
It shouldn't. The interceptor only autowires become the action invocation.
http://svn.opensymphony.com/fisheye/browse/xwork/trunk/src/java/com/opensymphony/xwork2/spring/interceptor/ActionAutowiringInterceptor.java?r=1063
-T.
On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> Sorry Ted!
>
> I should have been more clear with my question. Does S2 leverage Spring in
> such a way as so fetch a new Action bean when the Action method returns
> SUCCESS? It appears a new bean is being injected into my Action when a
> method returns SUCCESS.
>
> Scott
>
> On 4/9/07, Ted Husted <hu...@apache.org> wrote:
> >
> > By default, "input" is one of the magic methods that bypass
> > validation. In the case of a request for the input method, validation
> > is not applied, and input is returned. In the case of request for the
> > default execute/success method, input would be returned if validation
> > fails, and success returned if validation succeeds. Of course, if an
> > exception is thrown, then the exception handling would apply instead.
> >
> > HTH, Ted
> > <http://www.husted.com/ted/blog/>
> >
> > On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > > I have an interesting situation occurring but let me first ask how the
> > > request lifecycle differs between returning INPUT or SUCCESS from an
> > action
> > > method. Consider this action mapping:
> > >
> > > <action name="course_*" method="{1}" class="course">
> > > <result name="input">/pages/course.jsp</result>
> > > <result>/pages/course.jsp</result>
> > > </action>
> > > --
> > > Scott
> > > stanlick@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 Request Lifecycle
Posted by st...@gmail.com.
Sorry Ted!
I should have been more clear with my question. Does S2 leverage Spring in
such a way as so fetch a new Action bean when the Action method returns
SUCCESS? It appears a new bean is being injected into my Action when a
method returns SUCCESS.
Scott
On 4/9/07, Ted Husted <hu...@apache.org> wrote:
>
> By default, "input" is one of the magic methods that bypass
> validation. In the case of a request for the input method, validation
> is not applied, and input is returned. In the case of request for the
> default execute/success method, input would be returned if validation
> fails, and success returned if validation succeeds. Of course, if an
> exception is thrown, then the exception handling would apply instead.
>
> HTH, Ted
> <http://www.husted.com/ted/blog/>
>
> On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> > I have an interesting situation occurring but let me first ask how the
> > request lifecycle differs between returning INPUT or SUCCESS from an
> action
> > method. Consider this action mapping:
> >
> > <action name="course_*" method="{1}" class="course">
> > <result name="input">/pages/course.jsp</result>
> > <result>/pages/course.jsp</result>
> > </action>
> > --
> > Scott
> > stanlick@gmail.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: S2 Request Lifecycle
Posted by Ted Husted <hu...@apache.org>.
By default, "input" is one of the magic methods that bypass
validation. In the case of a request for the input method, validation
is not applied, and input is returned. In the case of request for the
default execute/success method, input would be returned if validation
fails, and success returned if validation succeeds. Of course, if an
exception is thrown, then the exception handling would apply instead.
HTH, Ted
<http://www.husted.com/ted/blog/>
On 4/9/07, stanlick@gmail.com <st...@gmail.com> wrote:
> I have an interesting situation occurring but let me first ask how the
> request lifecycle differs between returning INPUT or SUCCESS from an action
> method. Consider this action mapping:
>
> <action name="course_*" method="{1}" class="course">
> <result name="input">/pages/course.jsp</result>
> <result>/pages/course.jsp</result>
> </action>
> --
> Scott
> stanlick@gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org