On the other hand if you only have to do component nesting
programmatically in case of functional reasons (like security) your code
will probably much cleaner and you'll realize issues like using the
wrong parent faster.
Instead of:
myComponent.add(child1)
child1.add(child2)
child2.add(child3)
child2.add(child4)
myComponent.setVisible(false / true)
You do:
myComponent.add(child1)
myComponent.add(child2)
myComponent.add(child3) // correct direct parent determined by markup
myComponent.add(child4) // correct direct parent determined by markup
myComponent.setVisible(false / true)
On 09.11.2010 18:17, James Carman wrote:
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi
<martin.maku...@koodaripalvelut.com> wrote:
(You) as a coder will be responsible for opening that can ;] For good
and for bad. Not wicket. Nor members of this discussion.
How many times have you done this:
add(new TextField(...))
when you meant to do:
someSubComponent.add(new TextField(..))
With add, you'll get an exception if the ids/hierarchy don't match up.
Now, what if you're queueing instead? Suppose the user does:
queue(new TextField(...))
which will work perfectly fine, but they meant to do (to enforce "security"):
someSubComponent.queue(new TextField(...))
Now, since security is not enforced the "designer" has the freedom to
move stuff around and royally hose things up.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
