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
<[EMAIL PROTECTED]> 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
> ><[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
