> I think the documentation on makeChild is more accurate.
Unfortunately makeChild is marked as private and thus is not part of the
documentation.
> createChildren is really just a hook to allow a subclass to change
where and when it actually makes its children.
I have done a splitpane that automatically creates a divider for each
pane. Fairly normal and straightforward use case. So I think
createChildren is a very powerful place for overrides and strongly
suggest it is kept as part of the official api.
> c.name is still valid, it is used to make a child be of the class
that implements a particular tag
I don't think so.
Code: (slightly modified from previous mail):
-----
<canvas debug="true">
<view >
<method name="createChildren" args="children"><![CDATA[
for(var i=0; i<children.length; i++) {
Debug.inspect(children[i]);
}
]]></method>
<view height="${canvas.height}"/>
<view/>
</view>
</canvas>
Output:
-------
«Object#0» {
attrs: {…, height: $always{canvas.height}}
class: <anonymous view>
}
«Object#4» {
attrs: {…}
class: <view>
}
> c.class is an optimization, used by the compiler to:
> 1) Avoid having to look up the name
> 2) Instantiate 'instance classes'
Is there any other way for me (or the compiler) to recognize
tags/classes from each other? Because if not then the word
"optimization" is incorrect.
> The tagname in this case, is just for debugging. If you were to look
> at the non-debug version, you would see the tagname is not emitted.
What do you mean with "non-debug" version?
It is clear to me that if there is no debug window then I will not see
the debug messages :-)
> That's how it is supposed to be.
So can I now rely on the tagname of my Pane tag to be either "Pane" or
"anonymous Pane" ?
> Before, we never emitted a tagname for "instance classes".
So was the
- child['class'].tagname
previously in my example case "undefined" or "Pane" (It must have been
"Pane" because otherwise my SplitPane would not have worked previously.)
- rami
