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 <[email protected]> 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 >> [email protected] >
