Wicket
  1. Wicket
  2. WICKET-5082

Ajax update renders parent/child JS in different order than initial Page render

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.6.0
    • Fix Version/s: 6.7.0
    • Component/s: None
    • Labels:
      None

      Description

      See attached quickstart. On initial page load, the child Javascripts are rendered and executed first, followed by the parent's JS - in this case a Datatables.net JS. Everything works fine.

      However, if you click on a link in the DefaultDataTable, we trigger a DDT refresh via Ajax, and then you can see that the parent's JS is executed first, before the child JS - this causes a problem since the parent JS modifies the visible rows in the table and Wicket can no longer find some of the child rows.

      I expected the order of JS contributions to be the same for initial page render and any Ajax updates.

      1. quickstart.tar.gz
        95 kB
        Nick Pratt
      2. Change_order_of_Ajax_child_visitation.patch
        4 kB
        Nick Pratt
      3. wicket-5082.patch
        4 kB
        Sven Meier

        Activity

        Hide
        Nick Pratt added a comment -

        So normal page rendering uses a ChildFirstHeaderRenderStrategy (since 1.5), but the Ajax header writing doesnt seem to follow that strategy and writes parent first then children (AbstractAjaxResponse.writeHeaderContribution() )is there a reason we couldnt render both normal and ajax updates with the same order?

        Show
        Nick Pratt added a comment - So normal page rendering uses a ChildFirstHeaderRenderStrategy (since 1.5), but the Ajax header writing doesnt seem to follow that strategy and writes parent first then children (AbstractAjaxResponse.writeHeaderContribution() )is there a reason we couldnt render both normal and ajax updates with the same order?
        Hide
        Nick Pratt added a comment - - edited

        I dug around, and here's what's happening:
        In normal rendering, all the items go in to the on dom ready, all appended to the same list in the Response. In an Ajax response, the Wicket added JS for the click handlers get stored in the response.appendJavaScripts, and then, even though the parent was visited last (I replaced the AbstractAjaxResponse.writeHeaderContributor with the same code from ChildFirstHeaderRenderStrategy), the parent's JS was going in to the domReadyJavaScripts - which ultimately are added to the page before the child JS (stored in appendJavaScripts).

        While I have a workaround (an explicit check to see if we are in an AjaxRequest, and then adding to the appendJavaScripts in that case, and the modification of the wicket-core AbstractAjaxResponse to do a ChildFirst traverse), it seems a bit of a hack - I think the order of rendering and JS appends should be the same in both the non-Ajax and Ajax cases.

        See attached patch file for changes needed in AbstractAjaxResponse in order to allow the workaround to work - without this change, I dont see a workaround.

        Show
        Nick Pratt added a comment - - edited I dug around, and here's what's happening: In normal rendering, all the items go in to the on dom ready, all appended to the same list in the Response. In an Ajax response, the Wicket added JS for the click handlers get stored in the response.appendJavaScripts, and then, even though the parent was visited last (I replaced the AbstractAjaxResponse.writeHeaderContributor with the same code from ChildFirstHeaderRenderStrategy), the parent's JS was going in to the domReadyJavaScripts - which ultimately are added to the page before the child JS (stored in appendJavaScripts). While I have a workaround (an explicit check to see if we are in an AjaxRequest, and then adding to the appendJavaScripts in that case, and the modification of the wicket-core AbstractAjaxResponse to do a ChildFirst traverse), it seems a bit of a hack - I think the order of rendering and JS appends should be the same in both the non-Ajax and Ajax cases. See attached patch file for changes needed in AbstractAjaxResponse in order to allow the workaround to work - without this change, I dont see a workaround.
        Hide
        Sven Meier added a comment -

        Could you try wicket-5082.patch :

        • it reuses the current IHeaderRenderStrategy to get the same ordering as on non-ajax request
        • It changes AjaxEventBehavior to always render an OnDomReadyHeaderItem, the destinction betwenn Ajax and non-Ajax is superfluous actually.

        Note that there are unit test failing with this change though.

        Show
        Sven Meier added a comment - Could you try wicket-5082.patch : it reuses the current IHeaderRenderStrategy to get the same ordering as on non-ajax request It changes AjaxEventBehavior to always render an OnDomReadyHeaderItem, the destinction betwenn Ajax and non-Ajax is superfluous actually. Note that there are unit test failing with this change though.
        Hide
        Nick Pratt added a comment -

        Thanks Sven - your patch is simpler and works in my test cases and my application. I noticed the two new tests failing - domReadyOrder and domReadyOrder2, although I dont know if the expected values are meaningful beyond just being a base for a string comparison.

        Show
        Nick Pratt added a comment - Thanks Sven - your patch is simpler and works in my test cases and my application. I noticed the two new tests failing - domReadyOrder and domReadyOrder2, although I dont know if the expected values are meaningful beyond just being a base for a string comparison.
        Hide
        Sven Meier added a comment -

        The JavaScript ordering should now be consistent.

        Show
        Sven Meier added a comment - The JavaScript ordering should now be consistent.

          People

          • Assignee:
            Sven Meier
            Reporter:
            Nick Pratt
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development