myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <renzo.tomase...@tecnotp.it>
Subject Re: [Trinidad] how PPR response is applied to DOM
Date Fri, 11 Apr 2008 16:41:18 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
As depicted in a parallel message - my target is oriented to mimic
common wizards (Eclipse, MSVC, etc.).<br>
The basic display unit is the panel, which can contain anything. It can
be popup, docked, tiled, etc.<br>
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.<br>
Panels can be dragged around, minimized, resized, etc. In terms of
Facelets, a panel is not much more than a placeholder:<br>
<br>
&lt;ui:component&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;f:subview id="#{panel.name}"&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &lt;ui:include
....<br>
<br>
Full page refreshing renders the entire lists, preserving positions and
sizes.<br>
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.<br>
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).<br>
Btw the same requirements would be achieved by simulating a page with
frames using PPR.<br>
<br>
-- Renzo<br>
<br>
Andrew Robinson wrote:
<blockquote
 cite="mid:bc36a6210804110904o762fb07cn15baefca9075523f@mail.gmail.com"
 type="cite">
  <pre wrap="">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 &amp; 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 &amp; 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
<a class="moz-txt-link-rfc2396E" href="mailto:renzo.tomaselli@tecnotp.it">&lt;renzo.tomaselli@tecnotp.it&gt;</a>
wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap=""> 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
<a class="moz-txt-link-rfc2396E" href="mailto:renzo.tomaselli@tecnotp.it">&lt;renzo.tomaselli@tecnotp.it&gt;</a>
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:

 &lt;tr:panelGroupLayout id="pprCarrier" styleClass="invisible"
binding="#{bean.carrier}"&gt;
 &lt;c:if test="#{bean.newPanel != null}"&gt;
 &lt;cx:popupHolder panel="#{bean.newPanel}"/&gt;
 &lt;/c:if&gt;
 &lt;/tr:panelGroupLayout&gt;
 &lt;c:forEach var="panel" items="#{bean.panels}"&gt;
 &lt;cx:popupHolder/&gt;
 &lt;/c:forEach&gt;

 -- 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:

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

during the ppr it get replaced with:

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

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
&lt;/span&gt;

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
<a class="moz-txt-link-rfc2396E" href="mailto:renzo.tomaselli@tecnotp.it">&lt;renzo.tomaselli@tecnotp.it&gt;</a>
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
<a class="moz-txt-link-rfc2396E" href="mailto:andrew.rw.robinson@gmail.com">&lt;andrew.rw.robinson@gmail.com&gt;</a>
wrote:


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

 Example:

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

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



 On Thu, Apr 10, 2008 at 10:23 AM, Simon Lessard
 <a class="moz-txt-link-rfc2396E" href="mailto:simon.lessard.3@gmail.com">&lt;simon.lessard.3@gmail.com&gt;</a>
wrote:
 &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;
 &gt; ~ Simon
 &gt;
 &gt;
 &gt;
 &gt; On Thu, Apr 10, 2008 at 12:17 PM, Renzo Tomaselli
 &gt; <a class="moz-txt-link-rfc2396E" href="mailto:renzo.tomaselli@tecnotp.it">&lt;renzo.tomaselli@tecnotp.it&gt;</a>
wrote:
 &gt;
 &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
panel
 &gt; to a container already owning some of them.
 &gt; &gt; Such a container might be lenghty to refresh - so an alternative
solution
 &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
selected
 &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;
 &gt;
 &gt;













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

  </pre>
</blockquote>
</body>
</html>

Mime
View raw message