On 8/30/07, akast <[EMAIL PROTECTED]> wrote: > > As I'm learning Wicket, it strikes me as redundant that your component > hierarchy must essentially be expressed twice: once in the Java code, then > again in your HTML file. > > Why doesn't the Java code instead just define an unstructured "pool" of > components, and then rely on the structure indicated by the HTML file to > then dynamically assemble them appropriately, instead of making you the > programmer call all these add(Component) methods in the right order? As it > is the Java structure always has to match the HTML structure anyway or > you'll get a runtime exception, so why not just rely solely on the HTML > hierarchy and let the Java components be unstructured until runtime?
One simple good reason to not do that: it would be chaos. Right now, the mapping is really simple/ non-ambiguous. And whatever nesting you choose, it will be supported. If we'd relax on that, it would mean more magic from Wicket, more exceptional situations, more ways to achieve the same thing. I believe that even if we could (partially) pull it off, it would be hurt the framework more than it would help. I think what you want can be compared to what Tapestry supports. Undeniably, that is convenient sometimes, and can save writing plumbing code, but the other side of this is serious loss of flexibility, and some things will actually get harder/ less straightforward. Wicket is non-declarative and component structure can (and will in many cases such as with repeaters) change, and it is the Java code that drives what will end up in the user's browser, not the markup. Eelco
