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 16:04:44 GMT
Could you give me a simple use case for what you want to do, as I
don't see what you are missing yet.

I have given some serious thought in the past about asking for
tr:iterator and tr:table (which I think I did email about) giving the
ability to dynamically add & remove children. It would not be hard to
implement at all if some JS code could get access to the PPR DOM and
then programmatically add & remove the code. For iterating components,
you simply need to know what client IDs to remove and which to add and
how to add them (insert before existing, or append to the end).

-Andrew

On Fri, Apr 11, 2008 at 9:51 AM, Renzo Tomaselli
<renzo.tomaselli@tecnotp.it> wrote:
>
>  Andrew, this issue appeared many times on this (and other lists). The only
> JSTL tags I use with Facelets are c:forEach and c:if. The former for
> compile-time looping, the latter for compile-time conditional inclusion.
>  I did it this way - as opposite to the render-time (stamping) solution
> since I don't know what those panel will contain.
>  Also looping through c:forEach offers the advantage of producing
> discriminated id values - which is not possible at render-time.
>
>  For the second point - I really miss the way I could render a new panel
> without overwriting the one returned by previous PPR, provided that I must
> keep a fixed component to specify in addPartialTarget and its contents
> cannot be a list of panels, to avoid rendering overhead.
>  Thus a PPR operation to add a panel must carry only that new panel in the
> response. I don't see how moving could be performed by arranging PPR
> contents, but of course I'm open to any suggestion.
>
>  -- Renzo
>
>
>
>
>  Andrew Robinson wrote:
>  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