sure no problem, just point them out :)
On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > well, whenever those emails comein...why doesnt onbeforerender is getting > called...you can answer them :) > > -igor > > > On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > who? that overrides onBeforeRender? > > why should those call super last? > > that depends on what they want. > > > > On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
