Wicket
  1. Wicket
  2. WICKET-4361

Markup Inheritance & getVariation(): markup loading (and merging) order depends on whether the super constructor adds components or not.

    Details

      Description

      I have a web page 'ChildPage' that inherits (java/markup) from a 'SuperPage' ('ChildPage' --> 'SuperPage'). 'ChildPage' now needs to override getVariation() to return a variation string, for example "test". The variation string is preferably set in the ChildPages constructor, maybe by a PageParameter.

      I would expect the following markup: ChildPage_test.html merged with SuperPage.html. This is the case, when SuperPage has no component added in its constructor. But when SuperPage has a component added in constructor, then I get ChildPage.html merged with SuperPage.html.

      quickstart "myproject_1.5.4" (wicket 1.5.4) shows:
      ChildPage1 inherits from SuperPage1 (no component added)
      ChildPage2 inherits from SuperPage2 (label added)

      • Click on "load ChildPage1_test.html " -> markup ok: ChildPage1_test.html merged with SuperPage1.html
      • Click on "load ChildPage2_test.html " -> markup not ok: ChildPage2.html merged with SuperPage2.html : expected ChildPage2_test.html merged with SuperPage2.html

      same with "myproject2_1.4.19" (wicket 1.4.19) works fine!

      At the moment I moved the logic into getVariation() with: return getPageParameters.get("variation").toString();
      This works and that's why I'm unsure if it is a bug at all.

      Here is some debugging output from MarkupCache:
      1 : hildPage1 inherits from SuperPage1 (no component added)

      child constructor ------> Class=ChildPage1 variationString=test
      DEBUG - MarkupCache - Load markup: cacheKey=com.mycompany.ChildPage1_test_en_US.html
      DEBUG - MarkupCache - Loading markup from file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage1_test.html
      DEBUG - AbstractMarkupParser - The markup file does not have a XML declaration prolog with 'encoding' attribute:file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage1_test.html. It is more save to use it. E.g. <?xml version="1.0" encoding="UTF-8" ?>
      DEBUG - WebAppClassLoader - loaded class com.mycompany.ChildPage1 from sun.misc.Launcher$AppClassLoader@11b86e7
      DEBUG - MarkupCache - Load markup: cacheKey=com.mycompany.SuperPage1_test_en_US.html
      DEBUG - MarkupCache - Loading markup from file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/SuperPage1.html
      DEBUG - AbstractMarkupParser - The markup file does not have a XML declaration prolog with 'encoding' attribute:file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/SuperPage1.html. It is more save to use it. E.g. <?xml version="1.0" encoding="UTF-8" ?>
      DEBUG - MergedMarkup - Merge markup: derived markup: ChildPage1_test.html; base markup: SuperPage1.html
      DEBUG - WebAppClassLoader - loaded class com.mycompany.SuperPage1 from sun.misc.Launcher$AppClassLoader@11b86e7
      DEBUG - MergedMarkup - Merge markup: file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage1_test.html

      2: ChildPage2 inherits from SuperPage2 (label added)

      DEBUG - MarkupCache - Load markup: cacheKey=com.mycompany.ChildPage2_en_US.html
      DEBUG - MarkupCache - Loading markup from file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage2.html
      DEBUG - AbstractMarkupParser - The markup file does not have a XML declaration prolog with 'encoding' attribute:file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage2.html. It is more save to use it. E.g. <?xml version="1.0" encoding="UTF-8" ?>
      DEBUG - WebAppClassLoader - loaded class com.mycompany.ChildPage2 from sun.misc.Launcher$AppClassLoader@11b86e7
      DEBUG - MarkupCache - Load markup: cacheKey=com.mycompany.SuperPage2_en_US.html
      DEBUG - MarkupCache - Loading markup from file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/SuperPage2.html
      DEBUG - AbstractMarkupParser - The markup file does not have a XML declaration prolog with 'encoding' attribute:file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/SuperPage2.html. It is more save to use it. E.g. <?xml version="1.0" encoding="UTF-8" ?>
      DEBUG - MergedMarkup - Merge markup: derived markup: ChildPage2.html; base markup: SuperPage2.html
      DEBUG - WebAppClassLoader - loaded class com.mycompany.SuperPage2 from sun.misc.Launcher$AppClassLoader@11b86e7
      DEBUG - MergedMarkup - Merge markup: file:/C:/testumgebung/eclipseWorkspace/myproject/target/classes/com/mycompany/ChildPage2.html
      ...
      child constructor ------> Class=ChildPage2 variationString=test

      1. myproject_1.5.4.zip
        37 kB
        Jerome Bodis
      2. myproject2_1.4.19.zip
        20 kB
        Jerome Bodis

        Activity

        Hide
        Martin Grigorov added a comment -

        The problem is in MarkupContainer#add() which calls #getMarkup() to see whether to call #internalOnMarkupAttached().
        #getMarkup() is called in the base page constructor stack and it leads to caching the loaded page markup in MarkupCache and later Wicket reuses this cached markup and never asks for the one with the variation (from the child page).

        A solution for this particular case is to implement ChildPage#getVariation() like this:
        return getPageParameters().get("variation").toString();

        But I have no idea how to properly fix the real problem.

        Show
        Martin Grigorov added a comment - The problem is in MarkupContainer#add() which calls #getMarkup() to see whether to call #internalOnMarkupAttached(). #getMarkup() is called in the base page constructor stack and it leads to caching the loaded page markup in MarkupCache and later Wicket reuses this cached markup and never asks for the one with the variation (from the child page). A solution for this particular case is to implement ChildPage#getVariation() like this: return getPageParameters().get("variation").toString(); But I have no idea how to properly fix the real problem.
        Hide
        Martin Grigorov added a comment -

        Moved the calls of #internalOnMarkupAttached() in Component#onInitialize().
        This way #onMarkupAttached() is called a bit later than now but it fixes the problem with early the load of the markup and also saves some CPU cycles by not iterating all children of the added component

        Show
        Martin Grigorov added a comment - Moved the calls of #internalOnMarkupAttached() in Component#onInitialize(). This way #onMarkupAttached() is called a bit later than now but it fixes the problem with early the load of the markup and also saves some CPU cycles by not iterating all children of the added component

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Jerome Bodis
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development