[Laszlo-dev] createChildren

[P T Withington]

That's a bug then.  Perhaps this has the same root as the regression you just fixed?

Nothing should go in lz unless it is really defining a tag.

On 2009-11-24, at 18:23, Henry Minsky wrote:

> Hmm, now that you mention it,  I notice we've been adding the interstitial
> class names that come from compiling class mixins to the lz namespace
> object:
> 
> lz["colored_square$view"] = $lzc$class_colored_square$view;
> lz["black_line$colored_square$view"] =
> $lzc$class_black_line$colored_square$view;
> 
> 
> I don't think we need them in there, do we? The compiler seems to be
> emitting
> calls to instantiate the objects directly using the classname when it calls
> LzInstantiateView e.g.,
> 
> "class": $lzc$class_black_line$colored_square$view
> 
> 
> 
> 
> 
> 
> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <ptw at pobox.com> wrote:
> 
>> 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.
>> 
>> 
>> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com