[cc-ing Lou, fodder for the documentation mill]
The documented API is:
init(): is called after all the nodes children have been created
oninit: is sent after the `init()` method is called.
inited: is true after the `init()` method is called.
As with any property, `inited` has an implicitly associated event `oninited`,
this event could be used instead of `oninit`, but it is a new API in 4.x and
not backward-compatible. There is a _very_ subtle timing difference between
the calling of `init` the sending of `oninit` and the setting of the `inited`
flag, but user programs should not depend on those happening in any particular
order.
These APIs have the following purposes:
1) If you need to further initialize a node's properties, and that
initialization depends on the node's children being initialized, and you must
initialize the properties in a well-defined order, you can override the
`init()` method (but you must remember to call the super.init() method). This
is the most general mechanism, and it gives you the most control over the node
initialization process.
2) If you need a simple initialization that depends on the node's children
being initialized, you can add a handler for the `oninit` event. Since this is
a handler, you can't predict what order it will be called in, but you don't
need to worry about calling any super methods.
3) If you have a constraint or other computation that depends on the node's
children being initialized, you can use the `inited` flag to decide when it is
appropriate to make that computation, e.g.:
opacity="${this.inited?100/subviews.length:0}"
I realize the test case you have written is artificial to prove a point, but I
want to emphasize that you should not rely on `oninit` and `inited` having a
particular ordering. They are really implying the same thing, just in
different fashion for different purposes. It might have been better if
`oninit` did not exist, but it is a legacy API we are required to support.
On 2010-10-21, at 03:46, Max Carlson wrote:
> Hi Ray,
>
> Don't use isinited - it's an internal API and subject to change. It looks
> like inited is set to true _after_ init() and oninit are sent. Try listening
> for the oninited event, e.g.:
>
>> <handler name="oninited" args="v">
>> Debug.debug("isinited",this.isinited);
>> Debug.debug("inited",this.inited);
>> </handler>
>
>
> On Oct 20, 2010, at 9:20 PM, [email protected] wrote:
>
>> Hi, Max
>> Sometimes, I use isInited to decide whether or not the object has
>> finished initialization. But this is an internal attribute. So, I want to
>> switch to inited that is a opening attribute defined in node. But when I use
>> inited, inited is false, however, at the same time,isInited is true.
>> So, I write a tiny test case as below:
>>
>> <canvas width="100%" height="100" bgcolor="green" debug="true">
>> <view name="test">
>> <handler name="oninit" args="v">
>> Debug.debug("isinited",this.isinited);
>> Debug.debug("inited",this.inited);
>> </handler>
>> </view>
>> </canvas>
>>
>> The result is isinited is true, inited is false.
>>
>> Now, I am confused about these two attributes. Is this a bug? or what is the
>> correct usage?
>>
>> Can you give me some guidance?
>>
>>
>> Thanks
>>
>> -Ray
>
