+1 for Johan's changes to make the surface area of the change smaller. I didn't find onInitialize and onConfigure in our code base as well.
The benefits are evident. So that is +0 from me to keep them in. Pushing them to only 1.5 ensures we get enough folks trying 1.5 though :) Martijn On Fri, Jul 23, 2010 at 10:38 AM, 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 >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
