On 09 Mar 2011, at 21:42, Igor Vaynberg wrote: > oninitialize() is an atomic callback that notifies components when the > page becomes available. the page is special because since a page is > always available to itself it doesnt need such a callback. how is that > for a rationalization... :)
Only, you're special-casing initialize() in Pages so that onInitialize() gets called as soon as the page is available, only to then disallow developers from using onInitialize() by making it final. Kind of defeats the whole point, doesn't it. And I can't see initialize() doing anything else that the developer might notice. So really, just don't do it. >> >> In fact, if you take away this special casing for Page, this issue probably >> wouldn't exist at all and we could go back to letting the >> constructor-favored users use constructors and the others use onInitialize. > > that may very well be true. but weve come a long way from the > beginning of this thread which was: forbid add() in constructors. We have come a long way, but if onInitialize didn't behave this way for pages, that would be an ideal solution to the issue that wouldn't force onInitialize or the constructor (or a lame onConfigure hack). > interesting because in the beginning of this thread you wanted to > blindly castrate constructors :) I explained the issue and proposed solutions. One of them involved not creating component hierarchies from the constructors. I wouldn't call that castrating: You still get to use them for what they're supposed to do: initialize your instance's state. > i have proposed a way to deal with > the issue. you can create your own one-time callback in the page from > inside onconfigure(). So to round up, the proposed solutions are: 1. Forbid add() in constructor. 2. Forbid onInitialize() in pages (and fake one with onConfigure code that really has nothing to do with configuring but is onInitialize code in a block that requires a test of an instance field that takes up a whole boolean field in your page state, and do that for each of your pages). 3. Don't initialize() on add() in pages. > * -1 to forbid add() from constructors > * +0 to delay oninitialize() cascade until right before the first call > to onconfigure() So that's [1] and [3] out the window, does that mean you vote +1 for [2]? Because as I mentioned before, you can't in all honesty argue the case of leaving the door open for add() in constructors if the developer want to do that and slam the door shut for add() in onInitialize() if the developer wants to do that. Perhaps we can add a [4]: 4. Allow both and ignore the fact that mixing them will break things in pages. Heck, if we can allow doing potentially bad things in constructors because the bad is rare anyway, why not, right? My vote, in order of preference, would be [1], [3], [4], [2]. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
