Jesse Long created WICKET-5675:
----------------------------------
Summary: 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
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)
