Re: [Trinidad] panelPopup: how to avoid full page refreshing

[Renzo Tomaselli]

This seems not working, I just tried with (added partialTriggers to existing code, not a popupPanel):             <tr:panelBorderLayout id="navigator" styleClass="navigator" partialTriggers="navigator"> under Firebug. This component contains others, with navigation links. Any click forces a full page refresh (e.g. no XHR on Firebug). On the other hand - are you sure that a component can directly trigger itself ? Or in other words - that I don't need to specify exactly the id list of potential event sources (buttons, etc.), even if nested ? -- Renzo Andrew Robinson wrote: If I am right, a trinidad component can trigger if one of its children have an event, so the following should work: <tr:panelPopup> <tr:panelBox id="popupContents" background="" 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. 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" /> </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