[Moving to laszlo-dev] Ooh, yeah. Big bug here.
The way LZX mixins work is that we massage the schema definition. We have to do this to get the expected semantics (e.g., the mixin might declare subviews, etc, that would be expected to show up in each class that it gets mixed in to. So, I think there are two things that need to happen to make mixins in an lzo work: 1) On output: we need to make the interface include subviews (and perhaps other things? Are there other LZX features that are like views?) 2) On input: we need to re-attach the JS implementations to the interface in the class model. The work-around is to not put your mixins in the .lzo, for now... On 2010-07-27, at 16:31, Henry Minsky wrote: > There's a bug [...] with use of mixins in an > lzo. > > The have a very simple example, > > <canvas> > <include href="library.lzx"/> > <button with="TestMixin" text="test"/> > </canvas> > > > library.lzx: > > <library> > <mixin name="TestMixin"> > <attribute name="textkey" type="string" value=""/> > <setter name="textkey" args="textkey"> > this.textkey = textkey; > </setter> > </mixin> > </library> > > > What happens is when you make an lzo out of the library.lzx, compile the > main app, it builds > the composite class, $lzc$class_TestMixin$button, with empty function > declarations for > anything that was declared in the mixin. > > It seems almost like the compiler is using the interface definition that's > in the lzo, e.g., > > <interface name='TestMixin' extends='view'> > <attribute name='textkey' value='' type='string' /> > <method name='$lzc$set_textkey' /> > </interface> > > and thus getting empty method declarations? > > I guess I need to trace what is being passed into the script compiler > backend next to see what > the javascript looks like..
