onInitialize in the page construction/initialization lifecycle

[Chris Colman <ch...@stepaheadsoftware.com>]

I just realized that onInitialize() isn't the 'initialize' of
traditional frameworks that I thought it was: The style of
initialization that occurs in the lifecycle after instance construction
has completed and the call to the constructors has returned.
 
onInitialize appears to be called while still executing the base class
constructor code which makes things awkward. It is called before the
code in derived (extended) class constructors, after the initial
super(parameters); has been executed which means any set up code that I
have put in the constructors has not yet been executed when
onInitialize() is called - which makes the use cases for onInitialize()
much more rare than I first thought.
 
Given than the purpose of using onInitialize(), according to my
thinking, was to be able to perform some 'post instance construction'
initialization I was quite surprised to find that the relevant
attributes were still uninitialized. 
 
Is there a real 'onInitialize' style override I can use to add
components to a page after the page has been fully constructed and hence
all of its attributes are configured properly?
 
I'm using 1.4.x. Is the lifecycle and execution of onInitialize() any
different in 1.5.x?
 

RE: onInitialize in the page construction/initialization lifecycle

[Chris Colman <ch...@stepaheadsoftware.com>]

>this is true only for page#oninitialize() which is called at the time
>the first add(component) is called. it remains like this for backwards
>compatbility with the first introduction of #oninitialize(). 

Ahuh!

> In 1.5 this has been changed so that oninitialize() is called after
> the page is constructed.

Cool! I think you just convinced me to migrate to 1.5.x ASAP!
(That was the little shove I needed!)

>
>-igor
>
>
>On Thu, Aug 11, 2011 at 5:00 PM, Chris Colman
><ch...@stepaheadsoftware.com> wrote:
>> I just realized that onInitialize() isn't the 'initialize' of
>> traditional frameworks that I thought it was: The style of
>> initialization that occurs in the lifecycle after instance
construction
>> has completed and the call to the constructors has returned.
>>
>> onInitialize appears to be called while still executing the base
class
>> constructor code which makes things awkward. It is called before the
>> code in derived (extended) class constructors, after the initial
>> super(parameters); has been executed which means any set up code that
I
>> have put in the constructors has not yet been executed when
>> onInitialize() is called - which makes the use cases for
onInitialize()
>> much more rare than I first thought.
>>
>> Given than the purpose of using onInitialize(), according to my
>> thinking, was to be able to perform some 'post instance construction'
>> initialization I was quite surprised to find that the relevant
>> attributes were still uninitialized.
>>
>> Is there a real 'onInitialize' style override I can use to add
>> components to a page after the page has been fully constructed and
hence
>> all of its attributes are configured properly?
>>
>> I'm using 1.4.x. Is the lifecycle and execution of onInitialize() any
>> different in 1.5.x?
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: onInitialize in the page construction/initialization lifecycle

[Igor Vaynberg <ig...@gmail.com>]

this is true only for page#oninitialize() which is called at the time
the first add(component) is called. it remains like this for backwards
compatbility with the first introduction of #oninitialize(). in 1.5
this has been changed so that oninitialize() is called after the page
is constructed.

-igor


On Thu, Aug 11, 2011 at 5:00 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> I just realized that onInitialize() isn't the 'initialize' of
> traditional frameworks that I thought it was: The style of
> initialization that occurs in the lifecycle after instance construction
> has completed and the call to the constructors has returned.
>
> onInitialize appears to be called while still executing the base class
> constructor code which makes things awkward. It is called before the
> code in derived (extended) class constructors, after the initial
> super(parameters); has been executed which means any set up code that I
> have put in the constructors has not yet been executed when
> onInitialize() is called - which makes the use cases for onInitialize()
> much more rare than I first thought.
>
> Given than the purpose of using onInitialize(), according to my
> thinking, was to be able to perform some 'post instance construction'
> initialization I was quite surprised to find that the relevant
> attributes were still uninitialized.
>
> Is there a real 'onInitialize' style override I can use to add
> components to a page after the page has been fully constructed and hence
> all of its attributes are configured properly?
>
> I'm using 1.4.x. Is the lifecycle and execution of onInitialize() any
> different in 1.5.x?
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org