[Laszlo-dev] createChildren

[P T Withington]

On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:

> Hi,
> 
> Current documentation has this to say about node's createChildren(carr) argument
> 
> "an array of children where the structure of each child [c] takes the form:
> c.name = a string containing the name of the child -- usually its constructor
> c.args = a dictionary of attributes and values to be passed to the constructor of that child
> c.children = an array of children for the new child"

You are venturing into things that most people don't, since they just use the XML language for their applications.

I think the documentation on makeChild is more accurate.  createChildren is really just a hook to allow a subclass to change where and when it actually makes its children.  makeChild is the interface that actually interprets the children specification.  (Don't blame me for the confusing names, I did not make them up!)

c.name is still valid, it is used to make a child be of the class that implements a particular tag (so you say 'view' to get a <view>, etc.  You can use this to make any node that has a tag).

c.class is an optimization, used by the compiler to:

1) Avoid having to look up the name
2) Instantiate 'instance classes'

> None of this seems to be true.
> Instead the children seems to have the structure:
> c.attrs = a dictionary of attributes and values to be passed to the constructor of that child
> c.class = pointer to the class to be instantiated
> 
> When you further inspect the class there is one useful attribute:
> tagname. That seems to have the same function as c.name in the above mentioned documentation.
> 
> Further it seems that in the current trunk if you instantiate a class with a constrained attribute like this
> 
> <view height="${foo.height}"/>
> 
> It's tagname becomes
> "anonymous tagname"

Right.  This is a so-called "instance class".  In order to have a constraint, an instance needs some supporting methods.  (You would see the same thing if you gave your instance an explicit <method>.)  In order to have methods, the compiler has to build a class, and then make just one instance of that class.  It doesn't define a tag for that class, because it will only ever be made by the compiler (or by replication, which works automatically).  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.  And of course, the class is _not_ entered into `lz` (as are all real class definitions, e.g., lz['view'] => the class that implements <view>, so lz[<any tag name>].tagname == <any tag name>, but not for 'anonymous' or 'instance' classes.)

> Code:
> 
> <canvas debug="true">
>    <view >
>        <method name="createChildren" args="children"><![CDATA[
>            for(var i=0; i<children.length; i++) {
>                Debug.write(children[i]['class'].tagname);
>            }
>        ]]></method>
>        <view height="${canvas.height}"/>
>        <view/>
>    </view>
> </canvas>
> 
> Produces the output in debug window:
> anonymous view
> view
> 
> Is this how it is supposed to be?

That's how it is supposed to be.  :)

> Or is this an accident caused by the instance specific mixin development?

Although, we did just add this feature to make it easier to debug instance mixin's.  Before, we never emitted a tagname for "instance classes".  But we decided it would help debugging to give them a tagname that told what tag they were derived from.