You can set:
<context-param>
<param-name>
org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
</param-name>
<param-value>false</param-value>
</context-param>
to bypass the issue. Performance will be a little slower.
-- Adam
On 7/11/07, Graeme Steyn <[EMAIL PROTECTED]> wrote:
Hi,
I have recently made a correction to my Facelets pages to make sure that
the PPR works correctly. I included the <trh:body> tag thanks to a
response from Matthias to someone else's posting (without the tag it
simply does a full refresh). The impact was immediate and all of my
headers and footers started to duplicate.
The duplication of components when using Facelets is not limited to PPR.
I have attached a sample project showing the problem, with corresponding
JSP pages that do not have the problem (one of which produces a
NullPointerException)(have also uploaded the attachment to
https://issues.apache.org/jira/browse/TRINIDAD-95 as it appears closely
related). The project uses a maven pom to build.
Basically, any template text that is not wrapped in a Trinidad component
will be duplicated if the page is render after a full request cycle (no
validation errors, etc.) For example, in the snippet below, the <h3>
element will be duplicated, but not the <h2> element which lies outside
of any tr: tag.
<body>
<h:form id="form1">
<h2>Heading in form (using <tr:form>)</h2>
<tr:panelGroupLayout id="layout">
<f:facet name="separator">
<tr:separator />
</f:facet>
<h3>Heading within tr:panelGroupLayout</h3>
<tr:inputText
label="Test Input"
required="true" />
<tr:panelButtonBar id="pageNav">
<tr:commandButton id="command"
action="submit"
text="Submit"
shortDesc="Submit" />
</tr:panelButtonBar>
</tr:panelGroupLayout>
</h:form>
</body>
Unfortunately, I have not got as far as debugging to find where the
problem is. To correct it, the <h3> element can be wrapped in a
tr:outputText or tr:outputDocument tag. This is however not ideal as
all of the original headers and footers etc. have been done by web
developers using normal xhtml and css. To rework this into standard
Trinidad components will take time. It also removes some of the
flexibility of using Facelets. It would be easier to switch back to JSP
using static and dynamic includes, tag files and simple tags.
Does anyone have an opinions if it is worth sticking with Facelets when
using Trinidad or is it just simpler to switch back to JSP 2.1?
Regards,
Graeme.
-----Original Message-----
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 11 July 2007 12:18 AM
To: MyFaces Discussion
Subject: Re: [Trinidad] PPR duplicating transient components
not you,
I only noticed the words "transient" and "JSF12"
https://issues.apache.org/jira/browse/TRINIDAD-95
:-)
On 7/10/07, noah <[EMAIL PROTECTED]> wrote:
> ? I didn't create one for this issue. Should I?
>
> On 7/10/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > jira allows doing an upload, I noticed you created already an issue
in there.
> >
> > -M
> >
> > On 7/10/07, noah <[EMAIL PROTECTED]> wrote:
> > > OK. Mail daemon hates zip files. Here's a tarball of a demo
project.
> > >
> > > On 7/10/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > > A testcase would be great! I suspect a Facelets bug here,
> > > > though it's kind of a corner case.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 7/9/07, noah <[EMAIL PROTECTED]> wrote:
> > > > > On 7/6/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > > > > On 7/6/07, noah <[EMAIL PROTECTED]> wrote:
> > > > > > > On 7/6/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > >From: noah <[EMAIL PROTECTED]>
> > > > > > > > >
> > > > > > > > > On 7/6/07, Gary VanMatre wrote:
> > > > > > > > > >
> > > > > > > > > > >From: noah
> > > > > > > > > > >
> > > > > > > > > > > Thought I'd post this before creating a JIRA
> > > > > > > > > > > issue, in case I've overlooked something. I just
> > > > > > > > > > > now produced this with 1.2.1 but I think I've seen
it in 1.0.x before.
> > > > > > > > > > >
> > > > > > > > > > > In the following page, clicking the link correctly
> > > > > > > > > > > updates 'Foo=' to 'Foo=1' but it renders the
> > > > > > > > > > > paragraph twice. Clicking again updates
> > > > > > > > > > > -both- paragraphs to 'Foo=2' and adds a third.
> > > > > > > > > > > Click again for a 4th, and Foo=3, and so on.
> > > > > > > > > > >
> > > > > > > > > > > Using an h:outputText instead of inline EL keeps
> > > > > > > > > > > the text from being repeated, but additional
paragraph elements are added with each click.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >> ><tr:document xmlns="http://www.w3.org/1999/xhtml";
> > > > > > > > >> > xmlns:ui="http://java.sun.com/jsf/facelets";
> > > > > > > > >> > xmlns:f="http://java.sun.com/jsf/core";
> > > > > > > > >> > xmlns:h="http://java.sun.com/jsf/html";
> > > > > > > > >> > xmlns:tr="http://myfaces.apache.org/trinidad";>
> > > > > > > > >> > <tr:form>
> > > > > > > > >> > <tr:panelHeader partialTriggers="foo">
> > > > > > > > >> > <p>Foo=#{pageFlowScope.foo}</p>
> > > > > > > > > ;> > </tr:panelHeader>
> > > > > > > > >> > & nbsp;& nbsp; <tr:commandLink id="foo"
partialSubmit="true" text="Do
> > > > > > > > >> it!">
> > > > > > > > >> > <f:setPropertyActionListener
value="#{pageFlowScope.foo + 1}"
> > > > > > > > >> >target="#{pageFlowScope.foo}" />
> > > > > > > > >> > </tr:commandLink>
> > > > > > > > >> > </tr:form>
> > > > > > > > >> ></tr:document>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > What happens if you use the output text with the
transient attribute?
> > > > > > > > >
> > > > > > > > > No change, same behavior as transient="false". The
> > > > > > > > > paragraph tags still get repeated of course. I suppose
I shouldn't say 'transient'
> > > > > > > > > but all HTML, inline text, and EL.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Are you using client or server side state saving?
> > > > > > >
> > > > > > > Client.
> > > > > > >
> > > > > > > >
> > > > > > > > I'm not familiar with the specifics of Facelets but I
> > > > > > > > believe that it is creating its own jspid to simulate a
> > > > > > > > "JspIdConsumer" and adds it to the component's
> > > > > > > > attributes. This is how Clay currently works after a
> > > > > > > > few tips from Jacob. When the component tree is
> > > > > > > > restored, the components that are marked transient fall
> > > > > > > > out. Transient components have to be recreated and
inserted into the component tree. The "jspid" marker is used to map
existing components to the meta-data used to build the tree.
> > > > > > > >
> > > > > > > > It sounds like the markup nodes are not being set as
> > > > > > > > transient by facelets or maybe something in the state
> > > > > > > > saving is not discarding the transient components.
> > > > > > > >
> > > > > > > > Can you tell if the outputText components that contain
the markup "<p>..."
> > > > > > > > are "transient=true"?
> > > > > > >
> > > > > > > I don't know how to do that. I don't think Facelets uses
> > > > > > > actual h:outputText components though.
> > > > > > >
> > > > > > > > What happens if you switch state saving modes?
> > > > > > >
> > > > > > > No copies.
> > > > > > >
> > > > > > > But, the rest of my application blows up for some reason
> > > > > > > :)
> > > > > >
> > > > > > So, which mode has the problem with copies getting created?
> > > > > > If it's client-side state saving, what happens if you set
> > > > > > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
> > > > > > to false in web.xml?
> > > > >
> > > > > Client has the copies. If CACHE_VIEW_ROOT is false, it also
> > > > > keeps it from happening, even with client-side state saving.
> > > > >
> > > > > >
> > > > > > And, does:
> > > > > >
> > > > > > <h:outputText transient="true" escape="false"
> > > > > > value="<p>#{pageFlowScope.foo}</p>"/>
> > > > > >
> > > > > > ... dodge the issue?
> > > > > >
> > > > >
> > > > > Yes it does. Although doing that kind of half defeats the
> > > > > point of using Facelets :)
> > > > >
> > > > > > -- Adam
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > mail: matzew-at-apache-dot-org
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
