2 Replies Latest reply on Nov 15, 2012 5:07 PM by neikius

    rich:tabPanel included ajax components trouble

    neikius
    neikius Nov 12, 2012 12:18 PM

      Hello again!

       

      I have not been able to reproduce this issue yet, but I know a few facts, maybe someone can help. Otherwise I will supply more as I find it out.

       

      So I have a tabpanel:

       

      <rich:tabPanel switchType="ajax">
 <rich:tab>
 <ui:include src="Index3.xhtml"></ui:include> 
 </rich:tab>
 <rich:tab>
 <ui:include src="Index2.xhtml"></ui:include>
 </rich:tab>
 </rich:tabPanel>

       

      In the included files there are quite lengthy forms. I will update this as I find what exactly causes this.

       

      Problem is not reproducible using basic elements and I am suspecting there is a strange interaction of different ajax elements in both tabs. What happens? Autocomplete posts normally and recieves some response BUT cannot parse it and it never gets filled. I checked the response and it seems as if some additional data gets posted.

       

      Javascript breakpointing fun reveals this:

      Autocomplete.js.xhtml in callAjax function returns with ajaxError. Error is "During update: j_idt66:j_idt477:j_idt490 not found"

       

      Funny part is that such a component does not even exist in the currently open tab (searched the DOM for that ID or anything similar, no luck). I am guessing something gets piggybacked from another tab and it disrupts autocomplete handler hard enough that it doesn't pick up the data. Funny part is that the reply DOES contain the requested data! It just is not the first thing returned but is a bit further into the response. So instead of this (normal AC):

       

       

      <?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="j_idt66:j_idt266Items"><![CDATA[<div id="j_idt66:j_idt266Items">

       

      It looks like this:

       

       

      <?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="j_idt66:j_idt98"><![CDATA[<span class="rf-msg " id="j_idt66:j_idt98"></span>]]></update><update id="j_idt66:j_idt103"><![CDATA[<span class="rf-msg " id="j_idt66:j_idt103"></span>]]></update><update id="j_idt66:j_idt266:j_idt266AutocompleteItems"><![CDATA[<table id="j_idt66:j_idt266:j_idt266AutocompleteItems"

       

       

      So now, after writing this, puting each tab in a nested form comes to mind. Not sure though. Also not sure why AC doesn't parse the response anyway since it does actually contain data. That id comes later in the response (rf_msg field it seems) but is not present in the DOM. I must find out what exactly that ID is and where does it come from, but it will be hard since I cannot see it anywhere in view.

        • 1. Re: rich:tabPanel included ajax components trouble
          neikius
          neikius Nov 13, 2012 3:51 AM (in response to neikius)

          Reproduced the bug, problem is rich:message currently not rendered but present in view.

           

          Index3.xhtml:

           

          <rich:panel>
 <rich:autocomplete autocompleteMethod="#{bean.autocompleteMethod}" mode="ajax"></rich:autocomplete>
 </rich:panel>

           

          Index2.xhtml:

           

          <rich:panel>
 <rich:autocomplete autocompleteMethod="#{bean.autocompleteMethod}" mode="ajax"></rich:autocomplete> 
 <rich:message />
 </rich:panel>
            • Actions
          • 2. Re: rich:tabPanel included ajax components trouble
            neikius
            neikius Nov 15, 2012 5:07 PM (in response to neikius)

            Well as was obvious the problem are rich:message components. They are set to ajaxRendered="true" by default and updates keep comming in every ajax request, even though the components themselves are not rendered (as in other tabs)!

             

            This is imho a bug.

             

            The easiest solution was to just to set ajaxRendered conditionally based on the current tab, we still want the mesages ajaxified but not in non-rendered tabs.

             

            Another possible solution would be to just ignore exception thrown from jsf.js.xhtml when encountering a non-existant component in ajax update.

             

            Or another solution to change autocomplete so it doesn't destroy the update data if an error is sent.

             

            Not sure exactly but the implementation is weird on so many levels I was not sure if I dare fix it just like that. A lot could come crashing down I guess?

              • Actions