wicket-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WICKET-5569) Unable to find markup for children of deeply nested IComponentResolvers during Ajax response
Date Wed, 15 Oct 2014 07:47:34 GMT

    [ 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
[ 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

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
> 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
> 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

View raw message