I don't believe the goal of onInitiallize is to move all component creation from the constructor to onInitialize, since if you are adding the component to the parent in the onInitialize method then you are back to the problem of not being able to call getPage() in your components.
I say keep constructing components in constructors as well as adding them to their parents, and ONLY use onInitialize for initialization logic. The sort of stuff you'd put in onBeforeRender that would only run once. I'm not weighing in on changing Page's onInitialize from final, but I fear if users begin constructing and adding their components in the onInitialize call, then it removes the guarantee from that method that getPage() calls will always function correctly. -Clint On Wed, Feb 2, 2011 at 4:11 AM, Hans Lesmeister 2 < hans.lesmeis...@lessy-software.de> wrote: > > Hi, > > After onInitialize was introduced in 1.4.12 we have done a lot of > refactoring in a lot of pages to get component-creation out of the > constructors and into onInitialize. Especially calling overridable factory > methods from a constructor is gone now which we and PMD really appreciate. > > > Carl-Eric Menzel-7 wrote: > > > > I think this could be sufficiently > > guarded by putting a good explanation on onInitialize's javadoc. > > Besides, by this logic, Component is also incompletely initialized > > until the moment it gets added to the page. > > > > Ack > > +1 for Carl-Eric's patch > > Cheers > Hans > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3253718.html > Sent from the Forum for Wicket Core developers mailing list archive at > Nabble.com. >
