[jira] Resolved: (WICKET-3392) Page#onInitialize (and prepareForRender) is now broken as it is final (see Wicket-3218)

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ 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.