[
https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987080#action_12987080
]
Igor Vaynberg commented on WICKET-3218:
---------------------------------------
the problem with leaving onInitialize() open in pages is that its way too easy
to make the mistake and add something in the constructor and have really wonky
unpredictable initialization order results like you mentioned. almost all our
users are used to adding things in the constructor and unfortunately we have to
protect our users from themselves.
prepareForRender() is final because it should not be used, there is
onBeforeRender() which should be used as a callback.
as far as oninitialize() in non-pages, this is extremely useful. sounds like
your app is built mostly with pages. a lot of the apps i work on have very
dynamic UIs and are built almost exclusively with panels and panel swapping. in
these cases panels act as pages.
your usecases can be achieved like this:
1) in onconfigure() do a simple check: if (get("panel1") instanceof baepanel) {
replace(new specializedpanel("panel1"));}
2) you can do the same thing in onConfigure() or onBeforeRender()
> Component#onInitialize is broken for Pages
> ------------------------------------------
>
> Key: WICKET-3218
> URL: https://issues.apache.org/jira/browse/WICKET-3218
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.14
> Reporter: Carl-Eric Menzel
> Assignee: Igor Vaynberg
> Fix For: 1.5-RC1
>
> Attachments:
> 0001-delay-oninitialize-until-just-before-onconfigure.patch
>
>
> As first mentioned at
> http://mail-archives.apache.org/mod_mbox/wicket-dev/201012.mbox/%[email protected]%3E
> , I think the current (Wicket 1.4.14) implementation of
> Component#onInitialize is broken for Pages. Pages get initialized as soon as
> the first component is added, which is correct. But this usually happens
> within the constructor of the page, which means that the page object isn't
> fully initialized yet. The entire point of having onInitialize, however, is
> to be able to do further work once all constructors have run. See
> https://github.com/duesenklipper/wicket-oninitialize for a quickstart that
> demonstrates the problem.
> Pedro Santos suggested in the above thread to just switch the entire object
> construction to onInitialize. I don't think this is a good idea, because
> 1) it is completely counter-intuitive
> 2) it is not always realistic to have an entire class hierarchy not using the
> constructor just because a subclass somewhere might want to use onInitialize
> 3) it is inconsistent with onInitialize behavior for all other (non-Page)
> components. Here I can easily mix work in the constructor with onInitialize.
> I propose the following patch:
> - override onInitialize in Page and make it final, so Pages can't use this
> any more. This should not cause any unnecessary breaking, since currently
> it's not working for pages anyway.
> - introduce Page#onPageInitialize to provide a safe alternative to
> onInitialize
> - make a special case for Page in Component's beforeRender to fire
> Page#onPageInitialize if necessary
> Yes, this is a bit of special casing for Page, but there's quite a lot of
> that needed for Page anyway. I think the impact of this should be minimal.
> My page includes documentation and a new testcase that verifies the new
> behavior. I modified the old ComponentInitializationTest to reflect the fact
> that Page doesn't get onInitialize any more.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
