I think this predates that change, but I'll check the 'publish' flag logic <br><br><div class="gmail_quote">On Tue, Nov 24, 2009 at 6:43 PM, P T Withington <span dir="ltr"><<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That's a bug then. Perhaps this has the same root as the regression you just fixed?<br>
<br>
Nothing should go in lz unless it is really defining a tag.<br>
<div><div></div><div class="h5"><br>
On 2009-11-24, at 18:23, Henry Minsky wrote:<br>
<br>
> Hmm, now that you mention it, I notice we've been adding the interstitial<br>
> class names that come from compiling class mixins to the lz namespace<br>
> object:<br>
><br>
> lz["colored_square$view"] = $lzc$class_colored_square$view;<br>
> lz["black_line$colored_square$view"] =<br>
> $lzc$class_black_line$colored_square$view;<br>
><br>
><br>
> I don't think we need them in there, do we? The compiler seems to be<br>
> emitting<br>
> calls to instantiate the objects directly using the classname when it calls<br>
> LzInstantiateView e.g.,<br>
><br>
> "class": $lzc$class_black_line$colored_square$view<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>> wrote:<br>
><br>
>> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> Current documentation has this to say about node's createChildren(carr)<br>
>> argument<br>
>>><br>
>>> "an array of children where the structure of each child [c] takes the<br>
>> form:<br>
>>> <a href="http://c.name" target="_blank">c.name</a> = a string containing the name of the child -- usually its<br>
>> constructor<br>
>>> c.args = a dictionary of attributes and values to be passed to the<br>
>> constructor of that child<br>
>>> c.children = an array of children for the new child"<br>
>><br>
>> You are venturing into things that most people don't, since they just use<br>
>> the XML language for their applications.<br>
>><br>
>> I think the documentation on makeChild is more accurate. createChildren is<br>
>> really just a hook to allow a subclass to change where and when it actually<br>
>> makes its children. makeChild is the interface that actually interprets the<br>
>> children specification. (Don't blame me for the confusing names, I did not<br>
>> make them up!)<br>
>><br>
>> <a href="http://c.name" target="_blank">c.name</a> is still valid, it is used to make a child be of the class that<br>
>> implements a particular tag (so you say 'view' to get a <view>, etc. You<br>
>> can use this to make any node that has a tag).<br>
>><br>
>> c.class is an optimization, used by the compiler to:<br>
>><br>
>> 1) Avoid having to look up the name<br>
>> 2) Instantiate 'instance classes'<br>
>><br>
>>> None of this seems to be true.<br>
>>> Instead the children seems to have the structure:<br>
>>> c.attrs = a dictionary of attributes and values to be passed to the<br>
>> constructor of that child<br>
>>> c.class = pointer to the class to be instantiated<br>
>>><br>
>>> When you further inspect the class there is one useful attribute:<br>
>>> tagname. That seems to have the same function as <a href="http://c.name" target="_blank">c.name</a> in the above<br>
>> mentioned documentation.<br>
>>><br>
>>> Further it seems that in the current trunk if you instantiate a class<br>
>> with a constrained attribute like this<br>
>>><br>
>>> <view height="${foo.height}"/><br>
>>><br>
>>> It's tagname becomes<br>
>>> "anonymous tagname"<br>
>><br>
>> Right. This is a so-called "instance class". In order to have a<br>
>> constraint, an instance needs some supporting methods. (You would see the<br>
>> same thing if you gave your instance an explicit <method>.) In order to<br>
>> have methods, the compiler has to build a class, and then make just one<br>
>> instance of that class. It doesn't define a tag for that class, because it<br>
>> will only ever be made by the compiler (or by replication, which works<br>
>> automatically). The tagname in this case, is just for debugging. If you<br>
>> were to look at the non-debug version, you would see the tagname is not<br>
>> emitted. And of course, the class is _not_ entered into `lz` (as are all<br>
>> real class definitions, e.g., lz['view'] => the class that implements<br>
>> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for<br>
>> 'anonymous' or 'instance' classes.)<br>
>><br>
>>> Code:<br>
>>><br>
>>> <canvas debug="true"><br>
>>> <view ><br>
>>> <method name="createChildren" args="children"><![CDATA[<br>
>>> for(var i=0; i<children.length; i++) {<br>
>>> Debug.write(children[i]['class'].tagname);<br>
>>> }<br>
>>> ]]></method><br>
>>> <view height="${canvas.height}"/><br>
>>> <view/><br>
>>> </view><br>
>>> </canvas><br>
>>><br>
>>> Produces the output in debug window:<br>
>>> anonymous view<br>
>>> view<br>
>>><br>
>>> Is this how it is supposed to be?<br>
>><br>
>> That's how it is supposed to be. :)<br>
>><br>
>>> Or is this an accident caused by the instance specific mixin development?<br>
>><br>
>> Although, we did just add this feature to make it easier to debug instance<br>
>> mixin's. Before, we never emitted a tagname for "instance classes". But we<br>
>> decided it would help debugging to give them a tagname that told what tag<br>
>> they were derived from.<br>
>><br>
>><br>
>><br>
><br>
><br>
> --<br>
> Henry Minsky<br>
> Software Architect<br>
> <a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br><br><br>