You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alex Objelean <al...@isdc.ro> on 2007/09/06 13:34:22 UTC
Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
sure no problem, just point them out :)
On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> well, whenever those emails comein...why doesnt onbeforerender is getting
> called...you can answer them :)
>
> -igor
>
>
> On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > who? that overrides onBeforeRender?
> > why should those call super last?
> > that depends on what they want.
> >
> > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
well, whenever those emails comein...why doesnt onbeforerender is getting
called...you can answer them :)
-igor
On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
>
> who? that overrides onBeforeRender?
> why should those call super last?
> that depends on what they want.
>
> On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
who? that overrides onBeforeRender?
why should those call super last?
that depends on what they want.
On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> 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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT
(6 sept 2007)?
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
> > > >
> > > > please tell me, tell me!
> > > >
> > > > johan
> > > >
> > > >
> > > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > >
> > > > > because the final is there for a very important reason?
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > > >
> > > > > > I take the discussion is about removing onPopulate now?
> > > > > > why not keep onPopulate and remove the final?
> > > > > >
> > > > > >
> > > > > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > > > > > > For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
> > >
> > > please tell me, tell me!
> > >
> > > johan
> > >
> > >
> > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > >
> > > > because the final is there for a very important reason?
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > >
> > > > > I take the discussion is about removing onPopulate now?
> > > > > why not keep onPopulate and remove the final?
> > > > >
> > > > >
> > > > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
> >
> > please tell me, tell me!
> >
> > johan
> >
> >
> > On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > because the final is there for a very important reason?
> > >
> > > -igor
> > >
> > >
> > > On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > I take the discussion is about removing onPopulate now?
> > > > why not keep onPopulate and remove the final?
> > > >
> > > >
> > > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> wrote:
>
> please tell me, tell me!
>
> johan
>
>
> On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > because the final is there for a very important reason?
> >
> > -igor
> >
> >
> > On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > I take the discussion is about removing onPopulate now?
> > > why not keep onPopulate and remove the final?
> > >
> > >
> > > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
please tell me, tell me!
johan
On 9/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> because the final is there for a very important reason?
>
> -igor
>
>
> On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > I take the discussion is about removing onPopulate now?
> > why not keep onPopulate and remove the final?
> >
> >
> > On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
because the final is there for a very important reason?
-igor
On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
>
> I take the discussion is about removing onPopulate now?
> why not keep onPopulate and remove the final?
>
>
> On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Johan Compagner <jc...@gmail.com>.
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Alex Objelean <al...@isdc.ro>.
Indeed, onbeforerendercalled is an ugly name for a method (maybe choose other
name? :) ... just kidding.
My point is: as long as I want to override the onBeforeRender, I am aware of
the fact that I must call super to make it working properly, otherwise I
will get a nasty exception or unexpected behavior.
That is why I think that a solution could be a method which can be
overridden, without being worried to call its super, OR inform the user from
javadoc to pay attention when overriding it. Anyway, you as the core
developer will take the final (hope not the final onbeforerender :D)
solution.
my 2c :)
Alex.
igor.vaynberg wrote:
>
> a javadoc warning wont stop emails coming to this list :)
>
> onbeforerendercalled() is also an ugly way, uglier then onpopulate() which
> is at least more semantically named.
>
> the root problem is that java does not contain a compiler directive that
> would check for this, there is some support for this in JSR305, but who
> knows when that will come to fruition. until then the only sure way to do
> this is to make the method final :|
>
> -igor
>
>
> On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> The way I do it, is this:
>>
>> protected void onBeforeRender() {
>> //my init code
>> super.onBeforeRender();
>> }
>>
>> I think it can be documented in the javadoc, that it is mandatory to call
>> super at the end.
>> User can also have a problem if just override the onBeforeRender without
>> calling the super.
>>
>> I think, there is a lack of another life-cycle method which would not
>> force
>> user to call super. Something like the below:
>>
>> protected void onBeforeRender() {
>> onBeforeRenderCalled()
>> super.onBeforeRender();
>> }
>>
>> where
>> onBeforeRenderCalled()
>> is an empty method which would allow user to add his init logic.
>>
>> Alex.
>>
>>
>>
>>
>> igor.vaynberg 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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#a12524545
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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#a12536500
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
a javadoc warning wont stop emails coming to this list :)
onbeforerendercalled() is also an ugly way, uglier then onpopulate() which
is at least more semantically named.
the root problem is that java does not contain a compiler directive that
would check for this, there is some support for this in JSR305, but who
knows when that will come to fruition. until then the only sure way to do
this is to make the method final :|
-igor
On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> The way I do it, is this:
>
> protected void onBeforeRender() {
> //my init code
> super.onBeforeRender();
> }
>
> I think it can be documented in the javadoc, that it is mandatory to call
> super at the end.
> User can also have a problem if just override the onBeforeRender without
> calling the super.
>
> I think, there is a lack of another life-cycle method which would not
> force
> user to call super. Something like the below:
>
> protected void onBeforeRender() {
> onBeforeRenderCalled()
> super.onBeforeRender();
> }
>
> where
> onBeforeRenderCalled()
> is an empty method which would allow user to add his init logic.
>
> Alex.
>
>
>
>
> igor.vaynberg 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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#a12524545
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Alex Objelean <al...@isdc.ro>.
The way I do it, is this:
protected void onBeforeRender() {
//my init code
super.onBeforeRender();
}
I think it can be documented in the javadoc, that it is mandatory to call
super at the end.
User can also have a problem if just override the onBeforeRender without
calling the super.
I think, there is a lack of another life-cycle method which would not force
user to call super. Something like the below:
protected void onBeforeRender() {
onBeforeRenderCalled()
super.onBeforeRender();
}
where
onBeforeRenderCalled()
is an empty method which would allow user to add his init logic.
Alex.
igor.vaynberg 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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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#a12524545
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Alex Objelean <al...@isdc.ro>.
Done. Here is the issue link:
https://issues.apache.org/jira/browse/WICKET-935 WICKET-935
Matej Knopp-2 wrote:
>
> Please do, so that we don't forget.
>
> -Matej
>
> On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> Thank you again, Matej! :)
>> Will it be fixed, or should I create a task in JIRA?
>>
>> Alex
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > Some time ago onBeforeRender was called always, even if the component
>> > was not visible. This had caused problems with repeaters, therefore
>> > this restriction - to make sure onPopulate is called only when
>> > component is visible. But IMHO that's no longer necessary.
>> >
>> > -Matej
>> >
>> > On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> I would prefer to use onBeforeRender, instead of onPopulate, since it
>> is
>> >> the
>> >> I do in other components. Why would I use different life-cycle
>> methods,
>> >> depending on the component I'm using?
>> >>
>> >> Alex
>> >>
>> >>
>> >> Matej Knopp-2 wrote:
>> >> >
>> >> > IMHO that's a bit wrong.
>> >> > You can subclass onPopulate instead, but i think we can remove the
>> >> > code, because after recent changes onBeforeRender() is only called
>> >> > when component is visible in hierarchy.
>> >> >
>> >> > -Matej
>> >> >
>> >> > On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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#a12520766
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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#a12521043
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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#a12521149
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Matej Knopp <ma...@gmail.com>.
Please do, so that we don't forget.
-Matej
On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>
> Thank you again, Matej! :)
> Will it be fixed, or should I create a task in JIRA?
>
> Alex
>
>
> Matej Knopp-2 wrote:
> >
> > Some time ago onBeforeRender was called always, even if the component
> > was not visible. This had caused problems with repeaters, therefore
> > this restriction - to make sure onPopulate is called only when
> > component is visible. But IMHO that's no longer necessary.
> >
> > -Matej
> >
> > On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> I would prefer to use onBeforeRender, instead of onPopulate, since it is
> >> the
> >> I do in other components. Why would I use different life-cycle methods,
> >> depending on the component I'm using?
> >>
> >> Alex
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > IMHO that's a bit wrong.
> >> > You can subclass onPopulate instead, but i think we can remove the
> >> > code, because after recent changes onBeforeRender() is only called
> >> > when component is visible in hierarchy.
> >> >
> >> > -Matej
> >> >
> >> > On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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#a12520766
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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#a12521043
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Alex Objelean <al...@isdc.ro>.
Thank you again, Matej! :)
Will it be fixed, or should I create a task in JIRA?
Alex
Matej Knopp-2 wrote:
>
> Some time ago onBeforeRender was called always, even if the component
> was not visible. This had caused problems with repeaters, therefore
> this restriction - to make sure onPopulate is called only when
> component is visible. But IMHO that's no longer necessary.
>
> -Matej
>
> On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> I would prefer to use onBeforeRender, instead of onPopulate, since it is
>> the
>> I do in other components. Why would I use different life-cycle methods,
>> depending on the component I'm using?
>>
>> Alex
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > IMHO that's a bit wrong.
>> > You can subclass onPopulate instead, but i think we can remove the
>> > code, because after recent changes onBeforeRender() is only called
>> > when component is visible in hierarchy.
>> >
>> > -Matej
>> >
>> > On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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#a12520766
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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#a12521043
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Matej Knopp <ma...@gmail.com>.
Some time ago onBeforeRender was called always, even if the component
was not visible. This had caused problems with repeaters, therefore
this restriction - to make sure onPopulate is called only when
component is visible. But IMHO that's no longer necessary.
-Matej
On 9/6/07, Alex Objelean <al...@isdc.ro> wrote:
>
> I would prefer to use onBeforeRender, instead of onPopulate, since it is the
> I do in other components. Why would I use different life-cycle methods,
> depending on the component I'm using?
>
> Alex
>
>
> Matej Knopp-2 wrote:
> >
> > IMHO that's a bit wrong.
> > You can subclass onPopulate instead, but i think we can remove the
> > code, because after recent changes onBeforeRender() is only called
> > when component is visible in hierarchy.
> >
> > -Matej
> >
> > On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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#a12520766
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final
wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Alex Objelean <al...@isdc.ro>.
I would prefer to use onBeforeRender, instead of onPopulate, since it is the
I do in other components. Why would I use different life-cycle methods,
depending on the component I'm using?
Alex
Matej Knopp-2 wrote:
>
> IMHO that's a bit wrong.
> You can subclass onPopulate instead, but i think we can remove the
> code, because after recent changes onBeforeRender() is only called
> when component is visible in hierarchy.
>
> -Matej
>
> On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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#a12520766
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Posted by Matej Knopp <ma...@gmail.com>.
IMHO that's a bit wrong.
You can subclass onPopulate instead, but i think we can remove the
code, because after recent changes onBeforeRender() is only called
when component is visible in hierarchy.
-Matej
On 9/6/07, Alex Objelean <al...@isdc.ro> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org