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] > > > > >
