[
https://issues.apache.org/jira/browse/WICKET-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668883#comment-16668883
]
Igor Vaynberg commented on WICKET-6604:
---------------------------------------
forgot, its there now.
> Ajax repaint is not correctly handled when component being repainted has an
> enclosure associated with it and is not a child of the enclosure
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-6604
> URL: https://issues.apache.org/jira/browse/WICKET-6604
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 7.10.0, 8.1.0
> Reporter: Igor Vaynberg
> Assignee: Igor Vaynberg
> Priority: Minor
> Labels: ajax
> Fix For: 7.11.0, 8.2.0
>
>
> When a component is repainted with ajax we first check if that component is a
> controlling component of the enclosure and if it is we repaint the enclosure
> instead of the component. However, we make the assumption that the
> controlling component of the enclosure is always contained within the
> enclosure, which may not always be true with inline enclosures.
> For example:
> {code:java}
> <label wicket:child="name" wicket:for="name">Name</label>
> <input type="text" wicket:id="name"/>{code}
> In this case the inline enclosure will only encompass the label. So if we
> repaint the textfield by adding it to the ajax request handler we will get a
> strange result where any header contributions associated with the name
> component will get rendered, but the markup for the name component will not -
> because we make the assumption that since it is controlling an enclosure it
> is also inside it so there is no point in repainting it directly.
>
> One may argue that controlling components have to be inside the enclosure and
> we should throw an error if they are not, but I prefer this more flexible
> approach which allows the controller to be outside.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
