[
https://issues.apache.org/jira/browse/WICKET-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100427#comment-14100427
]
Martin Grigorov commented on WICKET-5675:
-----------------------------------------
The NPE in wicket-examples has been fixed. Sorry about that!
Please add a test case for "TransparentWebMarkupContainer inside
TransparentWebMarkupContainer would not work" use case and others if you have
in mind.
Thanks!
> Stop ComponentResolvers from blindly ascending the component hierarchy
> ----------------------------------------------------------------------
>
> Key: WICKET-5675
> URL: https://issues.apache.org/jira/browse/WICKET-5675
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 6.16.0
> Reporter: Jesse Long
> Priority: Minor
> Attachments: WICKET-5675.patch
>
>
> ComponentResolvers#resolve() first tries
> ComponentResolvers#resolveByComponentHierarchy().
> This tries the immediate container going all the way up the hierarchy
> attempting to resolve the component is the container is also a
> IComponentResolver.
> I'm worried that the wrong problem is being fixed in the wrong place here.
> Basically, I understand the need for this code as:
> TransparentWebMarkupContainer inside TransparentWebMarkupContainer would not
> work, because TransparentWebMarkupContainer just calls get(String) on its
> parent. If its parent is also transparent, the get(String) is not going to
> return the component, instead, resolve() should be called.
> Therefore, we must try the first one, and if that fails, continue up the tree
> in case the parent is also a TransparentWebMarkupContainer.
> This smells like the ComponentResolvers class fixing
> TransparentWebMarkupContainer bugs.
> Rather, we could just make TransparentWebMarkupContainer first try
> get(String) on the parent, if that fails, check if the parent is a
> IComponentResolver and if so, call resolve() on it.
> When using a TransparentWebMarkupContainer, it is reasonable to expect the
> component to be resolved from the component bound to the grandparent of the
> component tag in the markup hierarchy, but with the current plan, the
> component could be resolved from the great great great grandparent.
> Current behavior probably also leads to some confusing error messages when a
> component cannot be resolved, where a component deep in the hierarchy could
> "steal" a component which has not yet been rendered from an ancestor, and the
> error message would be about how the ancestor is missing a component or it
> was already rendered etc. User would have a hard time figuring out that the
> problem is actually deeper inside the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
