[Laszlo-dev] createChildren

[P T Withington]

Hum.  Well, I would have expected interstitials to create themselves as anonymous classes.  Maybe I missed that.

On 2009-11-24, at 19:27, Henry Minsky wrote:

> I think this predates that change, but I'll check the 'publish' flag logic
> 
> On Tue, Nov 24, 2009 at 6:43 PM, P T Withington <ptw at pobox.com> wrote:
> 
>> 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
>> 
>> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com