Which is why it is rather inadvisable. This way it is not a drop-in release, which we usually promise (unless a security issue or blocker forces us to forego binary compatibility)
However, I do think that the benefit of having these methods available now are significant. Martijn On Fri, Jul 23, 2010 at 12:21 PM, Martin Grigorov <[email protected]> wrote: > I'm also +1 to keep them in 1.4. > Addition of new code is not exactly backward incompatible change. The names > of the methods are common so the chance of clash is bigger but still there > is such > chance with any other addition. > > On Fri, Jul 23, 2010 at 10:50 AM, Martijn Dashorst < > [email protected]> wrote: > >> +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 >> > -- 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
