2 Replies Latest reply on Nov 1, 2011 11:56 AM by healeyb

    Issue re-rendering a <ui:include />

    kumarprabhatn

      Hi there. I am using RichFaces 4.0 Final. I really miss <a4j:include />. Anyway, as an alternative I am using

        

      <ui:include src="#{bean.selectedPage}" />
      

       

      On click on of a <a4j:commandButton />, I am changing the selectedPage in actionListener. The new page is a facelet with a <rich:dataTable />. The styles are not rendered for dataTable and I get RichFaces.ui.dataTable is null or not an object error in javascript. However, if I initialize the selectedPage to same facelet or I hardcode it like <ui:include src="/page.xhtml" /> it works, Only when I change it, it gives issues. <a4j:log /> reveals no errors. What is the workaround ? Actually, I found the alternative to <a4j:include /> here. However I have many such pages and all of them are pretty heavy. So including all of the pages may affect performance. Please help me out here.

        • 1. Re: Issue re-rendering a <ui:include />
          haukegulich

          Hi,

           

          same problem here. Any solutions?

           

          Regards,

          Hauke

          • 2. Re: Issue re-rendering a <ui:include />
            healeyb

            I got this working a while ago, there are some key points to bear in mind:

             

            (EDIT: I thought that I'd seen a recent post where someone had got this going by wrapping the

            ui:include in a a4j:outputPanel ajaxRendered="true", I've never tried this so best to do a search,

            it was in the last 2-3 weeks).

             

            1. It will not work with partial state saving. You either need to disable partial state saving entirely, or

               you can disable it on a per view basis like this:

             

              <context-param>

                    <param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>

                    <param-value>/secure/myPage.xhtml</param-value>

              </context-param>-->

             

            Of course partial state saving was heralded as a big performance improvement, so you take your

            life in your hands if this is the route you decide to take.

             

            2. You need to be using Mojarra 2.1 or above. There were fixes in this release that allowed 'dynamic

                 ui:include' to work (with full state saving, that is). I do not know what the status is with MyFaces.

             

            3. I only ever tested this with h:commandButton/Link, using a nested f:ajax tag. I don't know if it would

                work with a4j:command*.

             

            4. I encountered a problem with RF 4.1.0.M2 on a view with partial state saving disabled. The dataScroller

                component would not work, the first datatable page would render but when you clicked on page 2,

                 nothing happened. When reverting to partial state saving it worked ok.

             

            Is there an alternative? I think so. For example I have a bean property selectedSport containing values such

            as "tennis", "football", and I want to include like this: <ui:include src="#{myBean.selectedSport}.xhtml"/>.

            Without any concerns about partial state saving etc. you could use something like this:

             

            <h:panelGroup rendered="#{myBean.selectedSport == 'football'}">

              <ui:include src="football.xhtml"/>

            </h:panelGroup>

             

            <h:panelGroup rendered="#{myBean.selectedSport == 'tennis'}">

            <ui:include src="tennis.xhtml"/>

            </h:panelGroup>

             

            Whether or not this is a win for you depends on the use case. For example in the above example let's say

            that each sport-name.xhtml contains a dialog box with on average 50 lines of xhtml. If you just include each

            dialog unconditionally that's 5000 lines of xhtml to be converted into html and downloaded onto the client.

            The panelGroup rendered= solution adds 300 lines of extra xhtml (100 sports x 3 lines of code) but only

            renders to the client what is needed according to the value of selectedSport.

             

            It's not perfect but given what we have to work with right now I think this is the best solution, it is for me

            anyway.

             

            Regards,

            Brendan.