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 <[EMAIL PROTECTED]> 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 <[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]
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
