[
https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032521#comment-13032521
]
Ondra Žižka commented on WICKET-3335:
-------------------------------------
A note to
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3028177.html
:
Perhaps hierarchy ambiguities could be solved by introducing a concept of
"component tree path", e.g. instead of
add("form1").add("input");
add("form2").add("input")
we could have (while keeping backwards compatibility):
add("form1")
add("form1.input")
add("form2")
add("form2.input")
(Which might be what Juergen meant by "extending component resolution process".)
Pro: More flat code
Con: Less semantical code, performance drawback(?)
I'm not really sure what would I prefer. But it would fit with PropertyModel.
> Component Queuing (extract hierarchy information from markup)
> -------------------------------------------------------------
>
> Key: WICKET-3335
> URL: https://issues.apache.org/jira/browse/WICKET-3335
> Project: Wicket
> Issue Type: New Feature
> Components: wicket-core
> Reporter: Giannis Koutsoubos
> Attachments: 0001-component-queuing.patch
>
>
> Doubly defined hierarhices are redundant.
> Server-side hierarchy can be automatically deduced from markup hierarchy.
> Use queue method in MarkupContainer to add components and extract hierarchy
> information from markup.
> Discussed here:
> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html
> Implementation of queue method on branch 1.4.x :
> https://github.com/koutsoub/wicket/tree/component-queuing
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
