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
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()
*/
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
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
Please do, so that we don't forget.
-Matej
On 9/6/07, Alex Objelean [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
Thank you again, Matej! :)
Will it be fixed, or should I create a task in
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
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
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
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
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
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
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 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
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
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
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
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
18 matches
Mail list logo
