because we are going in circles here.... even with onpopulate you still have to make sure you call super last!
-igor On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > ok, > i don't like to have onBeforeRender final because we have the whole i > called > the super check for that. > But i do like the onPopulate because that makes much more clear that the > repeaters do there there work > because why should that happen in onBeforeRender? The api does speak for > them self then > > So i will remove the final of the onBeforeRender() > but make all onPopulate implementations final because that just for the > implementors > The only exception being RepeatingView because thats just an empty > implementation thats is supposed to be overwritten again.. > > by the way, these discussion do drain you, but your are happily > contributing > to threads like "Wicket Libraries" :) > > On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > i will leave it up to you guys as to what you want to do and how. > honestly > > discussions like this drain my attention span. > > > > the only reason i introduced onpopulate is so that i could make > > onbeforerender final. > > > > -igor > > > > > > On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > thats why i said the concreet repeaters that implement onPopulate > should > > > make them final > > > also what do you mean with funny errors, > > > you only get funny errors when you override both or 1 and start > calling > > > the > > > other. > > > calling super on different times in your onBeforeRender doesn't create > > > anything funny > > > except one thing. Before the onBeforeRender you have the old items > after > > > it > > > the new onces. > > > > > > johan > > > > > > > > > On 9/6/07, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > i think onPopulate() is there for just about 2 or 3 weeks and before > > the > > > > docs > > > > stated that calling super() would be vital. > > > > > > > > so, i really don't see a benefit in having a onpopulate() _and_ a > > > > non-final > > > > onbeforerender(). actually, if i override both, i could get funny > > errors > > > > changing a call to super.onbeforerender() at the end of an > overridden > > > > onbeforerender() to the beginning - since code in onpopulate() would > > be > > > > called > > > > on different initialization stages. > > > > > > > > having no onpopulate() would move the responsability back into the > > > > onbeforerender() again. > > > > > > > > i would prefer to get lost of onpopulate() in favor of > > onbeforerender(). > > > > > > > > my 2c > > > > > > > > regards, --- jan. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > >
