Hi,

no offense meant, but the rhetoric in this thread is getting more and more ridiculous. "Chicken"? "Component hierarchy hell"? Seriously? At most maybe "component hierarchy slight annoyance."

I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements.

The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write <wicket:instantiate class="foo"/>? It's just another hierarchy element, isn't it?

I frankly don't see any way to have this "auto-hierarchy" stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing.

The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change.

So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain!

Carl-Eric www.wicketbuch.de

On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi <mart...@koodaripalvelut.com> wrote: