Hi Pedro,
thanks for your reply.
I find the current behavior of onInitialize in Pages *very* surprising
and unexpected. It doesn't say anywhere in the documentation that using
onInitialize prohibits use of constructors.
Also, this only seems to affect pages. In all other components it seems
to work fine, which makes this behavior rather inconsistent.
Also, this quickstart is of course somewhat simplified. My real-world
issue is that I am extending from a chain of superclasses that all do
something in their constructors. It's not realistic to switch the
entire hierarchy from constructors to onInitialize.
Also again ;-), right now onInitialize for Pages is broken. For all
other components, onInitialize is called *after* all constructors have
run. Only for Pages this is done in the middle of the constructor.
I think either Page should have a final onInitialize implementation to
really prohibit onInitialize being used at all, or there should be a
special case for Page causing onInitialize to be called just before
onBeforeRender. This would be consistent with Java object construction
and also consistent with the contract of onInitialize, which simply
says "it is called sometime before onBeforeRender()".
Would that be an acceptable solution? Want me to provide a patch?
Thanks
Carl-Eric
www.wicketbuch.de
On Wed, 1 Dec 2010 20:31:35 -0200
Pedro Santos <pedros...@gmail.com> wrote:
> Hi Carl, you are mixing two different initializations strategies,
> that is why you are finding it weird. If you are using an overwritten
> onInitialize to initialize your component, do all your initialization
> there, even add your component's children.
>
> For example, your quickstart works fine as:
> @Override
> protected void onInitialize() {
> super.onInitialize();
> add(new Label("message",
> "If you see this message wicket is properly
> configured and running"));
> if (!constructorDone) {
> throw new IllegalStateException();
> }
> }
>
> On Wed, Dec 1, 2010 at 7:24 PM, <cmen...@wicketbuch.de> wrote:
>
> > Hi,
> >
> > we just ran into an interesting problem. We are using inheritance a
> > lot in our pages, but at one point we need something in the super
> > page that depends on the constructor of the sub page. Just like
> > with regular components, I thought I'd just use onInitialize() for
> > that.
> >
> > Unfortunately, that didn't work:
> >
> > at
> > com....MySubPage.onInitialize(...)
> > at org.apache.wicket.Component.fireInitialize(Component.java:4050)
> > at
> > org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:413)
> > at org.apache.wicket.Page.componentAdded(Page.java:1589) at
> > org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:979)
> > at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:142)
> > at com....MySuperPage.<init>(...)
> >
> > See the quickstart at
> > https://github.com/duesenklipper/wicket-oninitialize
> >
> > or just do this in the HomePage of any Wicket app:
> >
> > private final boolean constructorDone;
> > public HomePage(final PageParameters parameters) {
> > add(new Label("message", "blah"));
> >
> > this.constructorDone = true;
> > }
> >
> > @Override
> > protected void onInitialize() {
> > super.onInitialize();
> > if (!constructorDone) {
> > throw new IllegalStateException();
> > }
> > }
> >
> > As soon as I add() the first component to the page in the super
> > constructor, the page's initialize() is called, which fires
> > onInitialize. At this time, my onInitialize can't do anything, since
> > not even the super constructor has been run completely!
> >
> > Should this really happen this way? I.e., should the Page be
> > initialized at this point, or should the page's onInitialize call be
> > deferred later? Or is onInitialize not the right spot to do this
> > for a page - what would the right way be then?
> >
> > Thanks
> > Carl-Eric
> > www.wicketbuch.de
> >
>
>
>
