myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <>
Subject Re: [Trinidad] how PPR response is applied to DOM
Date Fri, 11 Apr 2008 15:11:00 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Andrew, I agree with the comment that I must move away the placeholder
content immediately after DOM replacement, otherwise next PPR will
overwrite it and I will end up having a single component visible.<br>
Say I have a panel container where I want to be able adding a new panel
without refreshing the existing ones.<br>
On my Facelets component I define a hidden placeholder acting as a new
panel carrier (a bound component), plus a panel list driven by a
c:forEach loop.<br>
Normally (full page refresh) the carrier is empty while the list hosts
all existing panels.<br>
In case of any PPR for addition - I use addPartialTarget to specify the
carrier which then achieves the new panel.<br>
Then I move it to the visible list (form children) by means of js,
leaving the carrier empty and ready to receive a new future panel.<br>
The resulting composition is like this:<br>
&nbsp;&nbsp;&nbsp; &lt;tr:panelGroupLayout id="pprCarrier" styleClass="invisible"
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;c:if test="#{bean.newPanel
!= null}"&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;cx:popupHolder panel="#{bean.newPanel}"/&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/c:if&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/tr:panelGroupLayout&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;c:forEach var="panel" items="#{bean.panels}"&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;cx:popupHolder/&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/c:forEach&gt;<br>
-- Renzo<br>
Andrew Robinson wrote:
  <pre wrap="">Huh?

Why would this work once? By PPRing a parent component of a child that
can be rendered or not, the child can be added or subtracted
willy-nilly. In fact you can add or remove children components as
needed (best during the invoke application phase). The idea is that
the parent component (the tr:panelGroupLayout in my example) gets
replaced for every time it is triggered. So I am not sure why you
think why you need a "new one".

So if panelGroupLayout renderers:

&lt;span id="namingContainer:mypanelgrouplayout"&gt;

during the ppr it get replaced with:

&lt;span id="namingContainer:mypanelgrouplayout"&gt;
blah 2

The outer HTML is replaced, so adding attributes is okay too. Say you
added a styleClass attribute value on PPR postback, it now renders as:

&lt;span id="namingContainer:mypanelgrouplayout" class="myClass"&gt;
blah 2

The component is always the same on the server, a new one is not created.

Did I miss something?


On Fri, Apr 11, 2008 at 2:58 AM, Renzo Tomaselli
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
  <blockquote type="cite">
    <pre wrap=""> Thanks both of you.
 I still have one doubt, though: using a placeholder as a page component
provides both a DOM id to replace and a component to provide contents for
 However this game works just once: as soon as the placeholder is filled in
with true contents from PPR, it's lost forever. While I can certainly create
a new placeholder by js for a future PPR addition, there wouldn't be any
associated component on the server side. In other words - an adding PPR
response will fill the old placeholder without providing a new one. How can
I force such a new component creation for the next cycle ?
 I'm afraid I miss the overall picture involving PPR restore-view and PPR
rendering to solve this puzzle.

 -- Renzo

 Andrew Robinson wrote:
 Should have been partialTriggers.

This is just to illustrate the usage. Simon's reply is correct.

On Thu, Apr 10, 2008 at 11:42 AM, Andrew Robinson
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>

 Panel group layout is pretty simple, and will do what you need.


 &lt;tr:panelGroupLayout partialTargets="exampleButton"&gt;
 &lt;tr:commandLink rendered="#{buttonWasClicked}" text="visible now!"/&gt;

 &lt;tr:commandButton id="exampleButton" text="Show it" partialSubmit="true"&gt;
 &lt;f:setPropertyActionListener target="#{buttonWasClicked}" value="#{true}"

 On Thu, Apr 10, 2008 at 10:23 AM, Simon Lessard
 <a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
 &gt; Hi Renzo, yes a simple invisible div or even span with the right id is
 &gt; enough. PPR need that only to know where to place the refreshed item with
 &gt; the specified id.
 &gt; ~ Simon
 &gt; On Thu, Apr 10, 2008 at 12:17 PM, Renzo Tomaselli
 &gt; <a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
 &gt; &gt; Hi, I wonder if anybody can enlight me about this topic.
 &gt; &gt; Assume having to add something new to a page through PPR: this requires
 &gt; updating some enclosing container, since PPR is all about updating (e.g.
 &gt; replacing) DOM parts, not adding new stuff. For example, adding a new
 &gt; to a container already owning some of them.
 &gt; &gt; Such a container might be lenghty to refresh - so an alternative
 &gt; might be achieved from having a placeholder to mark the future part to be
 &gt; added by means of addPartialTarget.
 &gt; &gt; The question is whether all is needed is a proper id to match the
 &gt; component to redraw. If yes, a simple empty and hidden div is enough.
 &gt; &gt; Any comment is appreciated,
 &gt; &gt;
 &gt; &gt; -- Renzo
 &gt; &gt;
 &gt; &gt;

  <pre wrap=""><!---->


View raw message