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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]>
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 < [EMAIL PROTECTED] > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
>
