4 Replies Latest reply on Aug 22, 2008 5:32 AM by careprad

    the serious design defect of richfaces

    careprad

      We encounter a serious problem in the project that based on richfaces.
      for example:


      <h:panelGrid id="boxGrid" binding="#{bean.boxGrid}">

      </h:panelGrid>

      <a4j:commandButton ajaxSingle="true" id="testButton" value="TEST"
      binding="#{bean.testButton}"></a4j:commandButton>

      <h:panelGrid style="display:none">
      <a4j:poll id="poll"
      actionListener="#{pollRequestBean.poll}"
      binding="#{pollRequestBean.pollButton}" interval="2000"
      />
      </h:panelGrid>

      as you see,we want to modify the panelGrid(id="boxGrid") when user click the button(id="testButton"),then when rerender,some changes will show in the content
      of the panelgrid.And,the poll is also what we needed(the reason is affirmative). But this has a big problem--synchronization!
      in such case:a user click a button,richfaces fire the event to it's listener(alias as 'la'),and the listener(la) began to update the boxGrid(the back-binding of the

      panelGrid),in the same time,the poll also come to request,what happen--the new comming request will update the richfaces' component tree,the boxGrid(the back-binding)
      also update,but the listener(la) did not know this,it still hold the old model,this cause the change to the model has no mean to the ui.
      We have try many method to solve this problem,but all is in vain.you may think push,the push alos will update the component tree when the event is fired.
      I think this a serious problem to richfaces.

        • 1. Re: the serious design defect of richfaces
          nbelaevski

          Hello,

          We're now thinking about enhancing of queues in 3.3.0: https://jira.jboss.org/jira/browse/RF-3131.
          Please vote for this feature if you like it here: http://wiki.jboss.org/wiki/RichFacesFuture

          • 2. Re: the serious design defect of richfaces
            careprad

            thank for you reply,but I think I can't wait for the new version,I found such comment in the source file:
            // Submit or put in queue request. It not full queues - framework perform waiting only one request to same queue, new events simple replace last.
            // If request for same queue already performed, replace with current parameters.
            A4J.AJAX.Submit = function( containerId, form, evt , options ) ,maybe what you say is enhanceing this queue,isn't it?

            • 3. Re: the serious design defect of richfaces

              There is no quick fix solution for this problem. Otherwise, we did not live with it for all two and a half years.
              Yes, the length of the queue is 2. Most people who use RF even have no idea that this is a problem somehow. I remember a couple time, probably, people met it. However, only you announce it as serious defect.

              • 4. Re: the serious design defect of richfaces
                careprad

                Richfaces is good frmaework,it do most thing very well,that is why we choose it.
                But to us,this is really a serious problem,if we can't resolve this problem,the whole ui project should be refactored--change to another ajax-jsf framework or change the server-side framework,but the second one is impossible,the web is just one of many UIs of our server-side framework.
                I think I have found a solution now,to modify the submitRequest function of the a4j engine,put all the request to a client queue,and a timer poll this queue.Hope I it work!
                thank for your reply.