Definitely +1 from me for keeping these methods in 1.4.x, with the additional scope-narrowing changes from Johan. Good ideas! These new methods will make some things much easier for us. I'm not sure how quickly we could move to 1.5 once it comes out.
On a related note, is there any documentation on what is changing between 1.4.x and 1.5, both on the surface and internally? Thanks Carl-Eric -- Carl-Eric Menzel http://www.wicketbuch.de/ On Fri, 23 Jul 2010 10:38:47 +0200 Johan Compagner <[email protected]> wrote: > we (servoy) dont care much about those changes, they can be left in > (we dont use it and they also dont give us a problem (after my fix ;) > ) > > > the only problem is by the way onInitialize and onConfigure() > > Because initialize and also doInitialize() are package scope so they > are not a problem as far as i know... for example doinitialize() is > final but a subclass of component in another package can just create > such a method just fine... > > configure() you made public final.. i think we just should do the > same, make it package scope final... > then that method shouldnt also be a big problem. > > The it is just the 2 overridable protected methods onInitialize and > onConfigure > > johan > > > On Thu, Jul 22, 2010 at 19:33, Igor Vaynberg > <[email protected]> wrote: > > i just thought of something, i added oninitialize and onconfigure > > features to 1.4.x as well as trunk, but they can create an > > incompatibility for 1.4.x users if they have declared a method on > > their components with the same name. > > > > impacted method names are component#configure(), onConfigure(), > > initialize(), onInitialize(). > > > > should we remove these features from 1.4.x to remove the chance of > > an incompatibility? > > > > -igor > >
