[
https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987194#action_12987194
]
Szádeczky-Kardoss Szabolcs commented on WICKET-3218:
----------------------------------------------------
Thanks for the quick reply. The point is yours with my second use case, that's
fine with onConfigure. However I have still a problem with onInitialize. If it
remains final as in RC1, then for Pages there's no other way to do
initialization than in the constructor, right? All other Components can have
this nice feature, but not Pages. Why? If you really want to protect users,
then a much nicer solution would have been NOT to initialize Pages when
components get added, but only before the render phase. I understand that most
situations could be solved with a panel replace maybe in onConfigure, but IMHO
this is kind of a hack compared to a nice OO solution that actually are very
widespread in Wicket elsewhere. And what makes Wicket lightyears ahead of JSP,
JSF and Co.
If you still insist on the current solution, would it be not possible to add an
extra initialize method for Pages that gets called guaranteed only once, and
guaranteed not while the constructor is running (probably before the render
phase like now)? For me this would be essential, and I can hopefully show
another use case of mine for this purpose:
On some pages there might be an important form working with session-bound data
that we want to protect even when the user navigates away via some link other
than submit or cancel. Imagine a shopping cart page where the user can set the
quantities but if he abruptly clicks on a featured product in the sidebar I
want to store all the quantity changes he has made in the cart. A very
efficient solution can be done with AjaxFormSubmitBehavior, that I add to each
link on each panel on such Pages. However each Panel must be made aware of this
important form at creation or initialization time. Since my panels get added in
my common base Page, without onInitialize the only nice way to pass this form
to it is through the super constructor call, however the form is definitely not
available in the first line of the constructor where super(...) is. Of course
workarounds can be made, as I have made one myself that included an extra
Page-managed initialized attribute and some extra glues, but onInitialize was
really a super nice solution to this problem. I am open to other suggestions,
but probably not leaving Pages as orphans that don't have a chance for nice
initialization outside of a Java Constructor would make Wicket more concistent.
> 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/%3c1291238699.1749.1408166...@webmail.messagingengine.com%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.
