On 9/25/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> If I am right, a trinidad component can trigger if one of its children
> have an event, so the following should work:
No, this example below means "repaint the panelBox 'popupContents'
if the component itself has an event". This is basically an example
of the "how do I PPR contents that I don't control" issue you pointed
out.
> <tr:panelPopup>
>
> <tr:panelBox id="popupContents" background="transparent"
> partialTrigger="popupContents">
>
> // your include here
>
> </tr:panelBox>
>
> </tr:panelPopup>
>
> You can use any trinidad component that produces a client ID in the
> HTML page, not necessarily panelBox. I am not aware of an equivalent
> to "h:panelGroup" in Trinidad that can be used as a simple SPAN/DIV,
> but if you find one, that would be best.
tr:panelGroupLayout.
-- Adam
> I didn't test this, but it should work from what I know.
>
> -Andrew
>
> On 9/25/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
> >
> > 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" onclick="return false;"/>
> > </f:facet>
> > <cx:include src="#{bean.component}"
> > 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
> >
> >
> >
> >
>
