Page#onInitialize (and prepareForRender) is now broken as it is final (see
Wicket-3218)
---------------------------------------------------------------------------------------
Key: WICKET-3392
URL: https://issues.apache.org/jira/browse/WICKET-3392
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5-RC1
Reporter: Szádeczky-Kardoss Szabolcs
Priority: Critical
I think the 3218 issue is really a misunderstanding of the onInitialize
concept, as it was a really needed feature. This was the reason I switched to
1.5-M3, and then BANG! in RC1 this is broken. Let me explain how to use it in
the right way, and then my use case for which this is much needed.
USAGE
As you have pointed out, onInitialize gets called at the first time when a
component gets added to the Page, or - if this doesn't happen in the
constructor then - in the render phase (internalPrepareForRender method) at
latest. Well, if you add any component to the page in the constructor then
onInitialize is really not of much use, actually in this case it's better not
to use it all. However if you start making pages as I do, then it becomes a joy
to work with.
The solution is simple: Don't add any component to the Page in the constructor,
use onInitialize for that purpose. If you advocate this as a best practice then
the use cases stated below will be much easier to make than without the
onInitialize (and using only constructor).
The constructor is anyway best suited only for setting up models, performing
(some or all of the) service calls and other things needed to ensure that the
given Page is the one to show to the user, without going into costly component
additions to the Page.
USE CASES
- In my current project we have a common base page from which all other pages
subclasses and so we share a common layout, some common panels and common
functionality in all pages. However once in a while it might be needed to hide
or replace one of the common panels in only one page but leave it as common in
all of the others. If you only could do this in the constructor then that will
be a really pain. The reason in short is that irrespective of whether you use
overriden "panel adder methods" or any other solution you are still in object
construction phase and that puts quite a few restrictions on variable
initialization order. I know, I did it, and there are only hacking workarounds
for this. On the other hand, onInitialize is a super elegant way to use
overriden methods or any cool OO technique since you are not constrained any
more by the "Construction phase".
- An other use case is that the user is doing stuff on any page, it can be
anything. Irrespective of what he/she is doing, something is happening in the
background, perhaps by an other user's action. The next time the first user is
refreshing this page or going to another page, I want the user to be notified,
in a common way, in a common code. This can be also achieved without
onInitialize with more or less hacking (especially when we want the user
notified when staying on the same page), but with onInitialize this is a much
cleaner. The reason is that prepareForRender (which by the way also got final,
why?) precedes onInitialize and so it is possible to do this check there.
FINAL/NON-FINAL :) THOUGHTS
Sorry for getting so long, my only point is that onInitialize (and
prepareForRender) not being final was one of the great achievements of 1.5
(backported into 1.4, or was it the other way around?). There were really use
cases for this, especially the avoidance of the Java Object Construction Phase
limitations (and the possibility of not having ugly big constructors :)). Sure
this can be misused or used wrongly as a lot of other things in Wicket, but
this is not a reason to limit the good usage of this. You can put it in the
javadoc, that only use onInitialize when you don't do add operations in the
constructor. Actually I would also ask what's the point of onInitialize
anywhere else than for Pages? At least I could live without it anywhere else,
but not for Pages.
I hope you will change both methods back to non-final. If not, then I will have
to revert to 1.4 and possibly never use 1.5 since the above issues are
showstoppers for me. This would be a sad thing from such a great framework.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
