I've looked to pageFlowScope a while ago and found it a somewhat more
cumbersome than Tomahawk's saveState. I might not have interpreted it very
well though. I'll give it another look.
Once more, thank you for your attention.
On 4/20/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
One final thought -- try replacing the Trinidad form with a standard
form and see if the problem goes away. Not sure how difficult it'll
be to do that, but it'll let you know where to look. Also, Trinidad
has something like t:saveState. pageFlowState? pageScopeFlow? Maybe
you could use that instead -- I don't really know how compatible they
are.
On 4/20/07, Mike Kienenberger <[EMAIL PROTECTED]> 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 <[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.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
