[
https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966514#action_12966514
]
Carl-Eric Menzel commented on WICKET-3218:
------------------------------------------
Ok, you are right about that. I missed that. After your comment on the dev list
that the whole initialization thing could be moved back to before configure(),
I started on a different patch. The main concern for me is still that I need to
be able to have an initialize step that is guaranteed to run after the
constructors.
> 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
>
> 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.
