[
https://issues.apache.org/jira/browse/WICKET-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-3392.
-----------------------------------
Resolution: Duplicate
Assignee: Igor Vaynberg
i have answered your comments in 3128
> 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
> Assignee: Igor Vaynberg
> Priority: Critical
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> 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.
