[Laszlo-dev] createChildren

[P T Withington]

There's a 'publish' flag in ClassModel that should be respected.  It should be false for anything that does not come from an LZX <class> or from a built-in, and that should prevent any entry from going into `lz`.

On 2009-11-24, at 18:43, P T Withington 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
>