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:58:33 GMT
So you really don't want a JSF + PPR approach, but are looking for
more of a GWT + AJAX approach it sounds like.

If you are going 100% custom on this baby, I would suggest really
making it flexible, and entering new areas.

One alternative is to leverage the Trinidad API for AJAX calls, and
bypass the renderers or hack into the JSF lifecycle yourself.

You could make a custom component that keeps track of its children and
do all client-side rendering/positioning:
1) render a <div id="trafficPanel" style="display: none" />
2) In that renderer only render new panels and send down JS to remove
existing ones.
3) On the client listen to the DOM add replace notify events
4) In custom JS, move code from in your custom panel to wherever you want.

How PPR works (I think, I may make some wrong statements):
1) add partial target adds a client ID onto a stack
2) all components are rendered, but only those that have a client ID
on the stack or a child component of one on the stack has its output
included in the response
3) on the client, for every existing element that is found with the
same client ID, replace it with the new version and fire the DOM
replace notify event.

Hope that helps to get you thinking,
Andrew



On Fri, Apr 11, 2008 at 10:41 AM, Renzo Tomaselli
<renzo.tomaselli@tecnotp.it> wrote:
>
>  As depicted in a parallel message - my target is oriented to mimic common
> wizards (Eclipse, MSVC, etc.).
>  The basic display unit is the panel, which can contain anything. It can be
> popup, docked, tiled, etc.
>  To put it simple, think of a set of popup panels managed by a single bean:
> it keeps a list of such panels and user actions on the page end up in adding
> new panels, dropping esisting panels and replacing contents.
>  Panels can be dragged around, minimized, resized, etc. In terms of
> Facelets, a panel is not much more than a placeholder:
>
>  <ui:component>
>      <f:subview id="#{panel.name}">
>            <ui:include ....
>
>  Full page refreshing renders the entire lists, preserving positions and
> sizes.
>  But I don't want to redraw the entire page whenever a panel is
> added/removed. If the user chooses to add a new panel - this must appear as
> centered at the top of zindex stack, without affecting what's already on the
> page.
>  Thus I have do to it through PPR and a response must carry the new panel
> contents, nothing else. Since this is constrained to modify (at top level)
> an existing component - that's ok - I provide a fixed component to act as a
> carrier for new panels. It's a simple flow - the browser asks for a new
> panel and the server returns it. But then that panel must be moved somewhere
> else in order to allow for carrying future new panels, otherwise overwriting
> is granted and we end up with the simple display of the very last panel. I
> can't see how this operation could be done without js (fairly trivial, btw).
>  Btw the same requirements would be achieved by simulating a page with
> frames using PPR.
>
>  -- Renzo
>
>
>
>  Andrew Robinson wrote:
>  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