You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@myfaces.apache.org by Francisco Passos <fr...@gmail.com> on 2007/04/20 17:38:34 UTC

t:saveState

What might cause t:saveState to not maintain the bean state from one request
to the next?

Re: t:saveState

Posted by Francisco Passos <fr...@gmail.com>.

I've just tried it with <h:form> and it doesn't work as well. Thank you for
your help!

I will attempt to find the answer in adffaces-user.

On 4/20/07, Mike Kienenberger <mk...@gmail.com> wrote:
>
> No, it's not due to facelets or having the form in the template.   I
> am using facelets and also have the form in the template.
>
> The only difference is that you're using a <tr:form> and I'm using an
> <h:form>.  That brings us back to the second possiblity --
> Trinidad-specific issues.
>
> I seem to recall that <tr:form> isn't a subclass of UIForm, but beyond
> that, I don't have anything else to add.   Might be time for you to
> ask on the adffaces-user mailing list.
>
>         <h:form id="masterForm">
> [...]
>                 <ui:insert name="body"/>
> [...]
>         </h:form>
>
> ========
>
>   <ui:define name="body">
> [..]
>         <t:saveState ...
>
>
> On 4/20/07, Francisco Passos <fr...@gmail.com> wrote:
> > Thank you, that makes sense.
> >
> > But what could be causing the source to omit the form name and just keep
> the
> > id specified in the xhtml tag? Do you have an idea how that can be
> avoided?
> >
> > Could it be due to using facelets and the form being on the template
> page?
> >
> >
> > On 4/20/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > > Well, let me give you an example since we have very similar setups:
> > >
> > > If my content composition contains this:
> > >
> > >         <t:saveState id="accountDetailPageAccount1"
> > > value="#{accountDetailPage.currentAccount }"/>
> > >         <h:inputText id="accountDetailPageAccount2"
> > > value="#{accountDetailPage.currentAccount}"/>
> > >
> > > Then when I view source on the html, I see:
> > >
> > > <input type="text" value="0"
> > > name="masterForm:accountDetailPageAccount2"
> > > id="masterForm:accountDetailPageAccount2">
> > >
> > > So the real client id of my t:saveState for this page would be
> > > "masterForm:accountDetailPageAccount1"
> > >
> > > If I was preserving this t:saveState value on another page, I'd expect
> > > viewsource of a similar test setup to show
> > > "masterForm:accountDetailPageAccount2" as well
> > >
> > > On 4/20/07, Francisco Passos < francisco.passos@gmail.com> wrote:
> > > > Well, but it is in a form... since both pages are facelet
> compositions
> > from
> > > > the attached template and everything is placed inside a form.
> > > >
> > > > What does this mean?
> > > >
> > > >
> > > > On 4/20/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > > > > Yes, as long as it's not in a naming container (form, dataTable,
> > > > > subview, subform, etc), then the id you specify will be the id
> > > > > specified in your tags.
> > > > >
> > > > >
> > > > > On 4/20/07, Francisco Passos < francisco.passos@gmail.com> wrote:
> > > > > > Upon checking the first possibility, the generated HTML for a
> > > > h:outputText
> > > > > > with the same id was the same in both pages:
> > > > > >
> > > > > > <!--Start: javax.faces.Output ["pesquisaFichaBean"]--><span
> > > > > > id="pesquisaFichaBean"></span>
> > > > > >
> > > > > > Can pesquisaFichaBean be considered a fully-qualified client id
> path
> > ?
> > > > > >
> > > > > > If that is ok, that leaves Trinidad as the problem causer. Is
> there
> > any
> > > > > > Trinidad expert in here who can enlighten us?
> > > > > >
> > > > > >
> > > > > > On 4/20/07, Mike Kienenberger < mkienenb@gmail.com> wrote:
> > > > > > > Two possiblities.
> > > > > > >
> > > > > > > 1) Your pages are actually not generating the same ids for the
> > > > > > > t:saveState components.   You could check this by creating
> another
> > > > > > > component next to them (like h:outputText) with a similiar id,
> and
> > > > > > > verifying the fully-qualified client id path is the same for
> your
> > test
> > > > > > > component (since you can do a view source to check it).
> > > > > > >
> > > > > > > 2) Trinidad -- don't have enough experience with it to know if
> > there's
> > > > > > > something specific to Trinidad that affects how the saveState
> > behavior
> > > > > > > might change, ie, navigation or state saving.  Seems unlikely,
> > though.
> > > > > > >
> > > > > > > On 4/20/07, Francisco Passos < francisco.passos@gmail.com >
> wrote:
> > > > > > > > I've checked the code and no JSF tags are present.
> > > > > > > >
> > > > > > > > I'm trying to navigate from page pesquisarFicha.jsf to page
> > > > > > > > consultarFichaImport.xhtml using the
> > > > > > > >
> > > > > > > > <tr:commandButton text="Consultar"...>
> > > > > > > >
> > > > > > > > In the first page I fill the inputField mapped to
> > > > > > > > #{pesquisaFichaBean.operador} with some value. When I reach
> the
> > > > second
> > > > > > page,
> > > > > > > > it is not.
> > > > > > > >
> > > > > > > > I have the following navigation rule in my faces-config.xml:
> > > > > > > >
> > > > > > > >  <navigation-rule>
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > <from-view-id>/pages/ficha/pesquisarFicha.xhtml</from-view-id>
> > > > > > > >   <navigation-case>
> > > > > > > >
> > > > <from-outcome>consultarFichaImport</from-outcome>
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > <to-view-id>/pages/ficha/consultarFichaImport.xhtml</to-view-id>
> > > > > > > >   </navigation-case>
> > > > > > > >  </navigation-rule>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/20/07, Mike Kienenberger <mkienenb@gmail.com > wrote:
> > > > > > > > > Sure.  Post the code.
> > > > > > > > >
> > > > > > > > > The subtle facelets issue can be easily checked -- do a
> view
> > > > source
> > > > > > > > > and make sure that you're not seeing unprocessed JSF tags
> in
> > the
> > > > > > > > > output.
> > > > > > > > >
> > > > > > > > > On 4/20/07, Francisco Passos < francisco.passos@gmail.com>
> > wrote:
> > > > > > > > > > That's odd.
> > > > > > > > > >
> > > > > > > > > > I'm using the same id for the same bean, which is
> > Serializable
> > > > (I
> > > > > > > > changed
> > > > > > > > > > the non-serializable bindings - like CoreSelectOneRadio
> and
> > such
> > > > -
> > > > > > to
> > > > > > > > > > transient, in order to keep serializability). I'm not
> using
> > > > > > <redirect/>
> > > > > > > > as
> > > > > > > > > > well and although I am defining the t namespace in every
> > page,
> > > > it
> > > > > > still
> > > > > > > > > > doesn't keep the state.
> > > > > > > > > >
> > > > > > > > > > Any further ideas? I can post the code if you'd like.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Francisco Passos
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 4/20/07, Mike Kienenberger < mkienenb@gmail.com >
> wrote:
> > > > > > > > > > > - Using a different id for the same bean on two
> different
> > > > pages.
> > > > > > > > > > > - Not correctly implementing Serializable or
> Stateholder.
> > > > > > > > > > > - Navigating to a new page (or the same page without
> using
> > > > null)
> > > > > > and
> > > > > > > > > > > using <redirect/> in your navigation rule.
> > > > > > > > > > > - Using facelets and not defining the t namespace.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>