On Tue, 8 Mar 2011 17:43:29 +0100 Maarten Billemont <[email protected]> wrote:
> 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. Fun fact: There is already a patch for that... > 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. I would like to use onInitialize for things that *need* to be done outside of the constructor. However, there are much better arguments than existing codebase for still allowing constructors. First, constructors are natural places to do stuff like that. Yes, they have limitations, and yes, PostConstruct exists for a reason, but that doesn't render constructors obsolete. Second, if you need to use any kind of parameters for stuff you do in onInitialize, you *must* store them in instance variables, even if you need them just once and could have long let them be garbage collected. Going purely post-construct would be a very bad idea for this reason. Carl-Eric www.wicketbuch.de --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
