You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Duncan Mills <du...@oracle.com> on 2004/10/13 17:06:07 UTC
Struts & JSF - CommandButton Actions
I've been experimenting with the Struts + Faces integration library and
have hit one puzzling behavior using a <h:commandButton>.executing an
"action" in a form-bean
If I have a page with a StrutsFaces form <s:form action="whatever"> and
that's associated with a Form Bean "foo" (session scope)
So I can have a text field bound to an element of the foo actionForm
<h:inputText id="name" value="#{foo.name}"/>
This works as expected.
If I then have a commandButton thus:
<h:commandButton id="setDefault" action="#{foo.setDefault}" value="Set
Default value" immediate="true"/>
where setDefault() is changing the value of the name attribute in the
foo bean
The method setDefault() in the foo ActionForm class executes in response
to the button, but the page does not refresh with the new value of
foo.name. In debug the getter in the Form Bean is never called .
If I do the same thing in a vanilla faces page with a "conventional"
backing bean defined in my faces-config the value of name would refresh .
So is there some restriction here or difference in lifecycle with
respect to Form-Bean, or should we not be overloading ActionForms with
commandButton actions?
--
Regards
Duncan Mills
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts & JSF - CommandButton Actions
Posted by Craig McClanahan <cr...@gmail.com>.
Sorry -- I think your confusion is my fault. You should use
immediate="true" on a Cancel button, to bypass the Process Validations
and Update Model Values phases. You should use immediate="false" on a
Submit button that is intended to actually perform the requested
transaction (i.e. save the data to the database, or whatever).
In the Struts-Faces integration library, only commands of the latter
type (immediate="false") are passed on to the corresponding Struts
action.
Craig
On Wed, 13 Oct 2004 22:23:00 +0100, Duncan Mills
<du...@oracle.com> wrote:
> I guess I'm confused because in a vanilla JSF page, if a command button
> calls an Action which updates the backing bean, then the Components
> referencing that updated attribute will be refreshed with the new
> value, even if the mode is immediate (using the current version of the RI).
> In this case I used immediate so that I wouldn't fire the Struts Action
> associated with the <s:form> I just wanted to update the "Backing Bean"
> (which in this case is the Form bean), re-render the page and see the
> updated value. So I'm still a little puzzled by the difference in
> behavior when immediate="true" is used in both cases?
>
> Regards
>
> Duncan Mills
>
>
>
>
> Craig McClanahan wrote:
>
> >On Wed, 13 Oct 2004 16:06:07 +0100, Duncan Mills
> ><du...@oracle.com> wrote:
> >
> >
> >>I've been experimenting with the Struts + Faces integration library and
> >>have hit one puzzling behavior using a <h:commandButton>.executing an
> >>"action" in a form-bean
> >>
> >>If I have a page with a StrutsFaces form <s:form action="whatever"> and
> >>that's associated with a Form Bean "foo" (session scope)
> >>So I can have a text field bound to an element of the foo actionForm
> >><h:inputText id="name" value="#{foo.name}"/>
> >>This works as expected.
> >>If I then have a commandButton thus:
> >><h:commandButton id="setDefault" action="#{foo.setDefault}" value="Set
> >>Default value" immediate="true"/>
> >>where setDefault() is changing the value of the name attribute in the
> >>foo bean
> >>
> >>The method setDefault() in the foo ActionForm class executes in response
> >>to the button, but the page does not refresh with the new value of
> >>foo.name. In debug the getter in the Form Bean is never called .
> >>
> >>If I do the same thing in a vanilla faces page with a "conventional"
> >>backing bean defined in my faces-config the value of name would refresh .
> >>
> >>So is there some restriction here or difference in lifecycle with
> >>respect to Form-Bean, or should we not be overloading ActionForms with
> >>commandButton actions?
> >>
> >>
> >>
> >
> >The key to understanding this is the fact that you declared
> >immediate="true" on your command button. That tells JSF this is just
> >a user interface action (for example, you'd use it on the "next page"
> >or "previous page" buttons for a scrolling table), instead of a form
> >submit action. Remove immediate="true" and the library will treat
> >this like a form submit, which will fire the corresponding Struts
> >action.
> >
> >
> >
> >>--
> >>
> >>Regards
> >>
> >>Duncan Mills
> >>
> >>
> >>
> >
> >Craig
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts & JSF - CommandButton Actions
Posted by Duncan Mills <du...@oracle.com>.
I guess I'm confused because in a vanilla JSF page, if a command button
calls an Action which updates the backing bean, then the Components
referencing that updated attribute will be refreshed with the new
value, even if the mode is immediate (using the current version of the RI).
In this case I used immediate so that I wouldn't fire the Struts Action
associated with the <s:form> I just wanted to update the "Backing Bean"
(which in this case is the Form bean), re-render the page and see the
updated value. So I'm still a little puzzled by the difference in
behavior when immediate="true" is used in both cases?
Regards
Duncan Mills
Craig McClanahan wrote:
>On Wed, 13 Oct 2004 16:06:07 +0100, Duncan Mills
><du...@oracle.com> wrote:
>
>
>>I've been experimenting with the Struts + Faces integration library and
>>have hit one puzzling behavior using a <h:commandButton>.executing an
>>"action" in a form-bean
>>
>>If I have a page with a StrutsFaces form <s:form action="whatever"> and
>>that's associated with a Form Bean "foo" (session scope)
>>So I can have a text field bound to an element of the foo actionForm
>><h:inputText id="name" value="#{foo.name}"/>
>>This works as expected.
>>If I then have a commandButton thus:
>><h:commandButton id="setDefault" action="#{foo.setDefault}" value="Set
>>Default value" immediate="true"/>
>>where setDefault() is changing the value of the name attribute in the
>>foo bean
>>
>>The method setDefault() in the foo ActionForm class executes in response
>>to the button, but the page does not refresh with the new value of
>>foo.name. In debug the getter in the Form Bean is never called .
>>
>>If I do the same thing in a vanilla faces page with a "conventional"
>>backing bean defined in my faces-config the value of name would refresh .
>>
>>So is there some restriction here or difference in lifecycle with
>>respect to Form-Bean, or should we not be overloading ActionForms with
>>commandButton actions?
>>
>>
>>
>
>The key to understanding this is the fact that you declared
>immediate="true" on your command button. That tells JSF this is just
>a user interface action (for example, you'd use it on the "next page"
>or "previous page" buttons for a scrolling table), instead of a form
>submit action. Remove immediate="true" and the library will treat
>this like a form submit, which will fire the corresponding Struts
>action.
>
>
>
>>--
>>
>>Regards
>>
>>Duncan Mills
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts & JSF - CommandButton Actions
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 13 Oct 2004 16:06:07 +0100, Duncan Mills
<du...@oracle.com> wrote:
> I've been experimenting with the Struts + Faces integration library and
> have hit one puzzling behavior using a <h:commandButton>.executing an
> "action" in a form-bean
>
> If I have a page with a StrutsFaces form <s:form action="whatever"> and
> that's associated with a Form Bean "foo" (session scope)
> So I can have a text field bound to an element of the foo actionForm
> <h:inputText id="name" value="#{foo.name}"/>
> This works as expected.
> If I then have a commandButton thus:
> <h:commandButton id="setDefault" action="#{foo.setDefault}" value="Set
> Default value" immediate="true"/>
> where setDefault() is changing the value of the name attribute in the
> foo bean
>
> The method setDefault() in the foo ActionForm class executes in response
> to the button, but the page does not refresh with the new value of
> foo.name. In debug the getter in the Form Bean is never called .
>
> If I do the same thing in a vanilla faces page with a "conventional"
> backing bean defined in my faces-config the value of name would refresh .
>
> So is there some restriction here or difference in lifecycle with
> respect to Form-Bean, or should we not be overloading ActionForms with
> commandButton actions?
>
The key to understanding this is the fact that you declared
immediate="true" on your command button. That tells JSF this is just
a user interface action (for example, you'd use it on the "next page"
or "previous page" buttons for a scrolling table), instead of a form
submit action. Remove immediate="true" and the library will treat
this like a form submit, which will fire the corresponding Struts
action.
> --
>
> Regards
>
> Duncan Mills
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org