myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <andrew.rw.robin...@gmail.com>
Subject Re: [Trinidad] how PPR response is applied to DOM
Date Fri, 11 Apr 2008 15:20:21 GMT
First of all, I strongly recommend that you do not use JSTL tags,
especially with PPR, I cannot stress this enough.

As for moving JS DOM, I also would not recommend it. Why do you wish
to do this client side instead of moving things around during the PPR?

Are you simply trying to author an add PPR operation instead of a replace one?

-Andrew

On Fri, Apr 11, 2008 at 9:11 AM, Renzo Tomaselli
<renzo.tomaselli@tecnotp.it> wrote:
>
>  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.
>  Say I have a panel container where I want to be able adding a new panel
> without refreshing the existing ones.
>  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.
>  Normally (full page refresh) the carrier is empty while the list hosts all
> existing panels.
>  In case of any PPR for addition - I use addPartialTarget to specify the
> carrier which then achieves the new panel.
>  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.
>  The resulting composition is like this:
>
>      <tr:panelGroupLayout id="pprCarrier" styleClass="invisible"
> binding="#{bean.carrier}">
>          <c:if test="#{bean.newPanel != null}">
>              <cx:popupHolder panel="#{bean.newPanel}"/>
>          </c:if>
>      </tr:panelGroupLayout>
>      <c:forEach var="panel" items="#{bean.panels}">
>          <cx:popupHolder/>
>      </c:forEach>
>
>  -- Renzo
>
>
>
>
>  Andrew Robinson wrote:
>  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:
>
> <span id="namingContainer:mypanelgrouplayout">
> blah
> </span>
>
> during the ppr it get replaced with:
>
> <span id="namingContainer:mypanelgrouplayout">
> blah 2
> </span>
>
> 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:
>
> <span id="namingContainer:mypanelgrouplayout" class="myClass">
> blah 2
> </span>
>
> The component is always the same on the server, a new one is not created.
>
> Did I miss something?
>
> -Andrew
>
>
>
> On Fri, Apr 11, 2008 at 2:58 AM, Renzo Tomaselli
> <renzo.tomaselli@tecnotp.it> wrote:
>
>
>  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
> replacement.
>  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
> <andrew.rw.robinson@gmail.com> wrote:
>
>
>  Panel group layout is pretty simple, and will do what you need.
>
>  Example:
>
>  <tr:panelGroupLayout partialTargets="exampleButton">
>  <tr:commandLink rendered="#{buttonWasClicked}" text="visible now!"/>
>  </tr:panelGroupLayout>
>
>  <tr:commandButton id="exampleButton" text="Show it" partialSubmit="true">
>  <f:setPropertyActionListener target="#{buttonWasClicked}" value="#{true}"
> />
>  </tr:commandButton>
>
>
>
>  On Thu, Apr 10, 2008 at 10:23 AM, Simon Lessard
>  <simon.lessard.3@gmail.com> wrote:
>  > Hi Renzo, yes a simple invisible div or even span with the right id is
>  > enough. PPR need that only to know where to place the refreshed item with
>  > the specified id.
>  >
>  > ~ Simon
>  >
>  >
>  >
>  > On Thu, Apr 10, 2008 at 12:17 PM, Renzo Tomaselli
>  > <renzo.tomaselli@tecnotp.it> wrote:
>  >
>  > > Hi, I wonder if anybody can enlight me about this topic.
>  > > Assume having to add something new to a page through PPR: this requires
>  > updating some enclosing container, since PPR is all about updating (e.g.
>  > replacing) DOM parts, not adding new stuff. For example, adding a new
> panel
>  > to a container already owning some of them.
>  > > Such a container might be lenghty to refresh - so an alternative
> solution
>  > might be achieved from having a placeholder to mark the future part to be
>  > added by means of addPartialTarget.
>  > > The question is whether all is needed is a proper id to match the
> selected
>  > component to redraw. If yes, a simple empty and hidden div is enough.
>  > > Any comment is appreciated,
>  > >
>  > > -- Renzo
>  > >
>  > >
>  >
>  >
>
>
>
>
>
>
>
>
>

Mime
View raw message