8 Replies Latest reply on May 14, 2007 11:08 AM by mani doraisamy

    Incremental UI updates in AJAX with rich client state

    mani doraisamy Newbie

      "AJAX applications with rich client state needs only the incremental changes that happened during the request (and not between save/commit). Otherwise we will end up sending the entire (or relevant subset) object tree to the UI everytime. This is inefficient and also requires the AJAX applications to render the whole UI (making it merely a client side html renderer)."

      http://www.theserverside.com/news/thread.tss?thread_id=45173

      I face this problem when i use Hibernate with GWT. Is this solved in SEAM with ICEfaces/Ajax4JSF ?

      mani

        • 1. Re: Incremental UI updates in AJAX with rich client state
          Christian Bauer Master

          Sure, that's what ajax4jsf is for:

          <h:form>
          <a:region>
           <h:inputText value="#{bar.field}"/>
           <a:commandLink action="#{bar.do}" reRender="foo"/>
          </a:region>
          </h:form>
          
          <s:div id="foo">
           Foo
          </s:div>
          


          • 2. Re: Incremental UI updates in AJAX with rich client state
            mani doraisamy Newbie

            If i understand correctly, the solution is to tie the source of the event and potential areas of change using the reRender attribute. This should work for most of the cases. This is true for GWT as well, since you could link the UI event with the widget to be refreshed.

            Probably i could have a very specific case. The potential areas of change in my case is not completely static (not known when i define the UI). Only at runtime, after executing the controller action would i know the areas of change. (depending on data entered in a widget, the logic determines what parameters should be modified). So currently if i have to define it statically it would be the union of all the potential areas of change (which becomes almost the entire object graph itself.)

            I hope i am not asking too much. But wouldnt it be great to automatically detect the changes (atleast for the managed objects in JPA/hibernate) and render those sections of UI alone, without even mentioning reRender ?

            mani

            • 3. Re: Incremental UI updates in AJAX with rich client state
              tedgoddard Newbie

               


              I hope i am not asking too much. But wouldnt it be great to automatically detect the changes (atleast for the managed objects in JPA/hibernate) and render those sections of UI alone, without even mentioning reRender ?


              This is certainly not asking too much, as this is exactly what ICEfaces does.
              Rather than requiring the developer to apply update zones to the page, ICEfaces renders into a DOM on the server, determines the changes to that DOM, and sends just the changes down to the browser.



              • 4. Re: Incremental UI updates in AJAX with rich client state
                Christian Bauer Master

                How do you deal with partial form submits, like in my example? I have a form with three regions and three submit buttons. I want to reRender completely independent areas after an event.

                • 5. Re: Incremental UI updates in AJAX with rich client state
                  mani doraisamy Newbie

                  Too good to be true!

                  How does ICEFaces know what changed without any support from the object graph ?
                  Does it manage the previous request's DOM to be able to indentify the changes ?
                  Does it render the object graph into DOM and then does the comparision ?
                  Is it a comparision by doing a full scan of DOM tree?
                  If i have returned a value from a query (or intensive processing) in an bean getter will it get executed irrespective of the change ? (which itself is not a problem but to understand the behaviour, so that i can model app correctly)

                  Any reference/document that explains how ICEFaces does incremental UI updates should be of great help in pushing this case forward in my company. Thanks.

                  mani

                  • 6. Re: Incremental UI updates in AJAX with rich client state
                    tedgoddard Newbie

                     

                    "christian.bauer@jboss.com" wrote:
                    How do you deal with partial form submits, like in my example? I have a form with three regions and three submit buttons. I want to reRender completely independent areas after an event.


                    Why is it important to know that a specific region is rendered? There could be output components anywhere on the page affected by the input. When the user presses the different buttons, different application logic should invoked by the action methods, but standard JSF would render the entire page. All the outputs on the page should be able to derive themselves correctly from the complete model, it's just that the model is updated differently by the different buttons. This preserves the declarative aspect of page design.

                    It's true that rendering a specific subtree on a page could be a useful optimization, but it should only be an optimization, not the primary way to add Ajax functionality.


                    • 7. Re: Incremental UI updates in AJAX with rich client state
                      tedgoddard Newbie

                       

                      "mdoraisamy" wrote:
                      Too good to be true!

                      How does ICEFaces know what changed without any support from the object graph ?
                      Does it manage the previous request's DOM to be able to indentify the changes ?
                      Does it render the object graph into DOM and then does the comparision ?
                      Is it a comparision by doing a full scan of DOM tree?


                      Of course, we reserve the right to make internal optimizations in ICEfaces or even radically change the implementation -- such things can be done because we only need to preserve the contract to the developer that standard JSF pages will behave as expected, but they will be updated smoothly and efficiently via Ajax. Currently, though, ICEfaces uses a technique called Direct-to-DOM rendering: The component tree is rendered into a DOM on the server (the output of the components is not parsed, the responseWriter is used like an inverse-SAX for efficiency) and a previous DOM is compared with the current DOM to determine an incremental update. The DOMs are scanned fully, but subtrees are not traversed when differences are found (we will be enhancing this algorithm in the future, but I won't go into that detail here).

                      "mdoraisamy" wrote:

                      If i have returned a value from a query (or intensive processing) in an bean getter will it get executed irrespective of the change ? (which itself is not a problem but to understand the behaviour, so that i can model app correctly)


                      If the getter is for a property referenced by a component rendered on the page, it will be called (this is a JSF behavior, not an ICEfaces behavior). When an application has expensive getters, we typically recommend some form of caching, either in the beans themselves or in the persistence layer.

                      "mdoraisamy" wrote:

                      Any reference/document that explains how ICEFaces does incremental UI updates should be of great help in pushing this case forward in my company. Thanks.


                      The ICEfaces architecture is described in the Developer's guide, but the implementation details have varied over time. It's probably best just to ask us questions on the areas that interest you.


                      • 8. Re: Incremental UI updates in AJAX with rich client state
                        mani doraisamy Newbie

                        The idea itself is compelling enough. It is only fair to assume that the implementation will get better over time. This also seems to be better than GWT in security and (eliminating) DTO. I will post questions, if any on the ICEFaces forum. Thanks Ted.

                        mani