[
https://issues.apache.org/jira/browse/WICKET-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172112#comment-14172112
]
ASF subversion and git services commented on WICKET-5569:
---------------------------------------------------------
Commit a4ae23c635b6e8f71d9e616fbc22f60c74e176d0 in wicket's branch
refs/heads/wicket-6.x from [~jesselong]
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=a4ae23c ]
Avoid visiting some children more than once when searching for markup of a
child.
When the ComponentTag of a child Component is nested inside a sibling
Component's ComponentTag,
AssociatedMarkupSourcingStrategy.searchMarkupInTransparentResolvers() is
called to attempt find the markup from inside component resolving markup
containers.
WICKET-5569 introduced behavior to use the visitor pattern to traverse
the Component tree and find these component resolving markup containers
however nested they may be.
Since the highest (page-most) component resolving markup container
component tree will probably cause a call to
searchMarkupInTransparentResolvers() if the markup is not found, there
is no need to descend any deeper than the first component resolving
markup container in that method.
> Unable to find markup for children of deeply nested IComponentResolvers
> during Ajax response
> --------------------------------------------------------------------------------------------
>
> Key: WICKET-5569
> URL: https://issues.apache.org/jira/browse/WICKET-5569
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.14.0
> Reporter: Jesse Long
> Assignee: Martin Grigorov
> Priority: Minor
> Fix For: 6.16.0, 7.0.0-M2
>
> Attachments: WICKET-5569-1.patch
>
>
> Component hierarchy: Page -> WebMarkupContainer -> IComponentResolver (that
> uses Page to resolve) and Page -> Panel.
> Markup hierarchy: Page -> WebMarkupContainer -> IComponentResolver -> Panel.
> When rendering whole page, it works, because it is markup driven. Wicket
> encounters ComponentTag for Panel and resolves the Panel using
> IComponentResolver, which retrieves the Panel from the Page.
> When you add the Panel to an AjaxRequestTarget, the render is component
> driven. In order to render the Panel, we must retrieve the markup for the
> Panel from its parent MarkupContainer, which happens to be the Page.
> Markup.java around line 230 skips to closing tags of ComponentTag, so when
> Page gets to the opening tag of the WebMarkupContainer, it skips to the
> closing tag of the WebMarkupContainer, and so passes over the ComponentTag
> for Panel without noticing it. There is actually another check, in
> DefaultMarkupSourcingStrategy, that tries to fetch from all the "transparent"
> components in the markup container, but this is not good enough, because in
> our example, the IComponentResolver is not actually a direct child of the
> Panel's parent, to it is never used to try find the markup.
> One solution might be to traverse the tree, and attempt to find the markup
> from all IComponentResolving MarkupContainers, but we should be careful. I'm
> a bit concerned at how various parts of Wicket just assume that an
> IComponentResolver is transparent and resolves from its direct parent only.
> If we do go down the route of traversing the tree to find
> IComponentResolvers, then try find the markup from each of them, we really
> should add a check in
> AbstractMarkupSourcingStrategy#searchMarkupInTransparentResolvers() to check
> that the Component that the IComponentResolver resolves for the markup id is
> the same component for which we are looking for markup.
> This is a difficult one. I am working around it for the mean time, just
> recording the difficulty here. Will try make a patch when I can.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
