Wicket
  1. Wicket
  2. WICKET-4589

Closing </wicket:container> tag is incorrectly setup as autocomponent

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.7, 6.0.0-beta2
    • Fix Version/s: 6.2.0
    • Component/s: wicket
    • Labels:
      None

      Description

      The closing instance of the <wicket:container> tag returns true when isAutoComponentTag() is called whereas the opening instance correctly returns false.

      The problem lies probably in the WicketTagIdentifier class which simply checks if there is a wicket:id attribute value and makes all tags (opening or closing) autocomponent tags if there is no wicket:id.

      Obviously any closing tag doesnt have a wicket:id assigned.

        Activity

        Hide
        Martin Grigorov added a comment -

        Does this cause troubles ?
        Because WicketTagIdentifier has a comment saying:

        // Make it a Wicket component. Otherwise it would be RawMarkup

        Without making it a (auto)component later the MarkupStream cannot find the closing tag.

        @Juergen: do you see a problem here ?

        Show
        Martin Grigorov added a comment - Does this cause troubles ? Because WicketTagIdentifier has a comment saying: // Make it a Wicket component. Otherwise it would be RawMarkup Without making it a (auto)component later the MarkupStream cannot find the closing tag. @Juergen: do you see a problem here ?
        Hide
        Christian Oldiges added a comment -

        Just to make it clear again:

        <wicket:container> is NOT marked as auto-component tag.
        </wicket:container> is marked as auto-component tag.

        ---------------------------------------------------------------------------------------------

        For the normal framework user it doesnt cause any direct troubles, but its still not correct and could lead to whatever problems down the road, such as our example:

        We have identified this problem while developing a CMS system which is template driven and analyses the markup to auto-create sub-components in onInitialize / onConfigure.

        Any auto component tag instances are simply ignored because they are handled by wicket themselves. We are only interested in ComponentTag(s) with wicket:id's such as <wicket:container>.
        Since the opening tag is not marked as auto-component it is correctly handled. The closing </wicket:container> tag however is marked as auto-component and thus ignored which in the end corrupts the component hierarchy, because the closing tag for the opening tag is not processed.

        A workaround to explicitly check for the closing wicket:container tag is straightforward but feels like a hack (which it is).

        Show
        Christian Oldiges added a comment - Just to make it clear again: <wicket:container> is NOT marked as auto-component tag. </wicket:container> is marked as auto-component tag. --------------------------------------------------------------------------------------------- For the normal framework user it doesnt cause any direct troubles, but its still not correct and could lead to whatever problems down the road, such as our example: We have identified this problem while developing a CMS system which is template driven and analyses the markup to auto-create sub-components in onInitialize / onConfigure. Any auto component tag instances are simply ignored because they are handled by wicket themselves. We are only interested in ComponentTag(s) with wicket:id's such as <wicket:container>. Since the opening tag is not marked as auto-component it is correctly handled. The closing </wicket:container> tag however is marked as auto-component and thus ignored which in the end corrupts the component hierarchy, because the closing tag for the opening tag is not processed. A workaround to explicitly check for the closing wicket:container tag is straightforward but feels like a hack (which it is).

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Christian Oldiges
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development