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 14:44:23 GMT
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