On 08 Mar 2011, at 16:39, Pedro Santos wrote: > > I vote for solution 3: postpone the onInitialize call, possible to the first > Component#configure execution. Then the problem of initialization code being > executed for not fully constructed components go away.
I actually also thought of that, which is why I asked for the reason as to why initialize() is invoked as a result of components being added to a page. If it ends up not being necessary (delay the onInitialize to when it's called for any other component) then perhaps that's a fair middle ground. People can still use constructors if they like (though really, the only single *advantage* I can think of for this is that it means you don't have to go back and fix your existing codebase), and others are free to use onInitialize. Doing your work post-construct is a very common thing in Java. That's the whole point of there being a javax.annotation.PostConstruct, for example. Anyone that claims doing this is bad or counter-intuitive probably hasn't seen enough Java code yet. We're stuck with a legacy of how we used to do things in Wicket. And yes, that is a burden we should consider. But at some point, in favor of a clean API and consistency, you need to be able to give up legacy. Perhaps 1.5 is that time, perhaps it should be 1.6, but kid yourself not: it will be all that much harder the longer we wait. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
