This means that if my panelPopup specifies the id of its contained
component as a partialTrigger target, all I need is to generalize the
contents to provide a single id to the container. Then *any* action
occurring inside that contained component would lead to a container PPR
?
Unfortunately, a container component like a panelPopup does not know
its contents (which is dynamically included), but this is an
architectural issue I can work around somehow, using the panel bean as
a bridge to let the containee communicating its id to the container,
and having this retrieving partialTrigger value through a bean property.
Oh well, it's worth to try.
-- Renzo
Andrew Robinson wrote:
Why can't you just put a component in the top level of the included
page that has partialTriggers for your event generating components?
There is no need to re-render the entire page. The PPR works on client
IDs, so it doesn't matter if the component is in the DIV tag of a
popup (the popup is nothing special when it comes to HTML, it just has
some CSS positioning on it).
On 9/25/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
Danny, assume a panelPopup holds a Facelets ui:included component. Thus in
general it can be anything. All actions originated by panel contents can
either to close the panel or to change its contents. In the latter case,
refreshing should not affect the overall page.
My actual modal panel xhtml component is:
<ui:component>
<c:if test="#{bean.visible}">
<t:saveState id="component" value="#{bean.component}"/>
<t:saveState id="componentBeanName"
value="#{bean.componentBeanName}"/>
<tr:panelPopup id="modal" alignment="center" modal="true">
<f:facet name="trigger">
<tr:commandButton id="modalTrigger" text="d"
inlineStyle="visibility: hidden" />
</f:facet>
<cx:include src=""
bean="#{bean.componentBean}" container="#{container}"/>
</tr:panelPopup>
</c:if>
</ui:component>
This component is included in the app. page but in turn it can contain any
other panel (see cx:include, just some sugar to replace ui:include).
This inclusion is runtime-defined by #{bean.component}. When such component
changes (think about a multi-panel wizard hosting next/previous widgets),
there is no reason to refresh the entire page, unless the popup panel itself
has to disappear (!visible). The popup panel is activated by an "onload"
script which clicks modalTrigger, since till now this component misses any
other activation way.
Btw, such PPR would be a nice effect on the overall page as well: in my
app. there is only one single page, where a number of facelets components
act as containers, even in nesting mode. In all cases where a single panel
(e.g. xhtml component) is replaced, there is no reason to redraw all others.
Concerning dialogs - so far I thought they lead to rendering pages, an
effect I wanted to avoid. But maybe "lightweight" leads to something
different, I miss a clear picture about when using either popup panels or
dialogs.
-- Renzo
Danny Robinson wrote:
Renzo,
Do you have a small test-case you can post, you certainly should be able to
use PPR inside a model panelPopup. Although it may be a better option to
use lightweight dialogs for what you're suggesting.
Danny
On 9/25/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
Hi, I'm using tr:panelPopup in modal mode only. It works well, but since
it can host alternative panels (e.g. components in the Facelets sense),
the entire page is refreshed whenever a panel is replaced by another
one. Not a nice effect.
Panel navigation occurs from user actions (next/previous) inside the
panel itself.
AFAIK PPR is there just to avoid this effect, e.g. I should be able
somehow to force panel contents refresh only.
But I don't know how to do it.
Suggestions are welcome.
-- Renzo
--
Chordiant Software Inc.
www.chordiant.com
|
