Well, thinking is my second name
:-)
Actually - all I described has been implemented (it's more like a
framework than an application, although it's targeted to publish a
customer DMS/CMS) - I'm tuning the panel addition story.
And yes - JSF + PPR + Facelets all work well for my purposes (I don't
know about GWT).
After all I have to provide panels with some contents, and that's JSF
(e.g. Trinidad) in all its glory.
My feeling is that - in order to keep web apps competiting vs.
traditional apps - PPR has to be used everywhere to achieve fast
responses.
My wizard choice (e.g. one page, many components) is questionable and
likely domain-driven.
I recognize that using js chunks here and there to work around issues
is somewhat dirty - but not much more than custom component and
renderers.
-- Renzo
Andrew Robinson wrote:
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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> 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
> >
> >
>
>
|
