no not for the onces that make a Repeater.
Because then we aren't being able to tell that the populate should really be
done before the call to super.onBeforeRender
So having an onPopulate is fine. Repeaters should use that method to
populate them selfs and we then also take care of the order
but if somebody extends again that repeater he should be able to overwrite
onBeforeRender()
i think classes that implement the onPopulate should make that method
final... Because that shouldn't be overridable (we don't have the check
there that super is called)
So just removing final of onBeforeRender (for developers who extend the real
repeater again)
and having an onPopulate for concreet classes that extend AbstractRepeater
directly. (and those should make onPopulate final)
johan
On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> if it was not final then there would be little point for keeping
> onpopulate,
> it would just be confusing
>
> -igor
>
>
> On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > and?
> > why can't AbstractRepeater.onBeforeRender() be not final?
> > If i overwrite to do what ever i want (but i do need to call
> > onBeforeRender
> > at some point else we generate an error)
> > then it comes in AbstractRepeater.onBeforeRender()
> > that first does the onPopulate so the items are created and then calls
> the
> > super..
> > That i can never change even if onBeforeRender is not final..
> >
> > johan
> >
> >
> > On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > >
> > > since component.onbeforerender() is what cascades the onbeforerender()
> > > call
> > > to the children, when it comes to repeaters it is absolutely vital
> that
> > > super.onbeforerender() be called last, that way it will cascade to any
> > new
> > > items added in repeater's onbeforerender().
> > >
> > > -igor
> > >
> > > On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > please tell me, tell me!
> > > >
> > > > johan
> > > >
> > > >
> > > > On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > because the final is there for a very important reason?
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > I take the discussion is about removing onPopulate now?
> > > > > > why not keep onPopulate and remove the final?
> > > > > >
> > > > > >
> > > > > > On 9/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > the reason for it being final is that the super.onbeforerender
> ()
> > > > call
> > > > > > HAS
> > > > > > > to
> > > > > > > be done last, otherwise new items do not get onbeforerender
> > called
> > > > on
> > > > > > > them.
> > > > > > >
> > > > > > > so if we remove final will you remember to always call it
> last?
> > i
> > > > > think
> > > > > > > the
> > > > > > > chances are that are pretty small, thus its final.
> > > > > > >
> > > > > > > -igor
> > > > > > >
> > > > > > >
> > > > > > > On 9/6/07, Alex Objelean <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > I've grabbed the latest SNAPSHOT from the repository and
> have
> > > > > noticed
> > > > > > > that
> > > > > > > > AbstractRepeater#onBeforeRender is final. I wonder what is
> the
> > > > > reason
> > > > > > > for
> > > > > > > > this? (I need to do something in it's subclass)
> > > > > > > > /**
> > > > > > > > * @see org.apache.wicket.Component#onBeforeRender()
> > > > > > > > */
> > > > > > > > protected final void onBeforeRender()
> > > > > > > > {
> > > > > > > > if (isVisibleInHierarchy())
> > > > > > > > {
> > > > > > > > onPopulate();
> > > > > > > > }
> > > > > > > > super.onBeforeRender();
> > > > > > > > }
> > > > > > > >
> > > > > > > > Alex
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
> > > > > > > > Sent from the Wicket - User mailing list archive at
> Nabble.com
> > .
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
