Just a thought: Surely there must be a way to support both styles of 'construction' (I use that term loosely) within the one framework.
Perhaps a runtime switch in the properties could dictate the 'construction' mode. You could leave the default as 'traditional wicket' mode but in 'two phase' construction mode a clear two phase constructor/init strategy is used whereby init is called only after parent object construction is complete so that all virtual method calls will be made from within the init method and so guatrateed to be operating on a 'fully constructed object' instead of the current situation where it can be operating on a partically constructed parent object - nasty! (I admit it is more dangerous in languages like C++ but it can still cause significant problems in Java). In this "two phase" mode exceptions could be thrown if an attempt is made to do something which is dangerous or would go against the strategy. That means everybody used to other frameworks where a separate 'init' phase takes place after parent object construction is complete will be happy because they can switch to 'two phase' mode but at the same time all existing wicket code will continue to work unchanged. >-----Original Message----- >From: Maarten Billemont [mailto:lhun...@gmail.com] >Sent: Thursday, 10 March 2011 8:28 AM >To: Igor Vaynberg >Cc: users@wicket.apache.org >Subject: Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for >Pages > >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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
