On Tue, Mar 1, 2016 at 5:27 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 3/1/16, 2:08 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >Hmm, interesting. There are a couple things here I misinterpreted from my > >journey through the code a couple years ago. > > > >It's great to hear that there are no dependencies, I think one major thing > >Josh had to do was mangle how Event was handled since MXMLC required > >flash.events.Event for bindings. > > > >So basically it's synthesizing implementation calls that the sub framework > >must implement to use it's children API IE in Feathers it would be > >addChild() of the Starling framework. > > > >From what you have written, it seems like this might now be as hard as I > >originally thought. I guess i need to open Eclipse and look at the code. > > Rats, you were supposed to get the impression that it would be easy. But > you might be right that it is hard. I don't know the Starling/Feathers > code. The main file to look at is MXMLClassDirectiveProcessor > > HAHA I made a typo, where I wrote "now" I meant "not". :)
> > > >So generateMXMLAttributes() is setting instance properties on StarlingApp? > > All it does is hand in the properties, styles and events on the top-level > tag. What the implementation does is up to the framework. > Ok, I am not sounding eloquent today, I guess that is what I meant, it passes properties that must be set on the instance by the implementing framework. > > > > >What does -mxml-children-as-data actually do? Does it output something? > > It tells the compiler to generate these data structures and API calls > instead of generating the Flex SDK code that MXMLC does. > > Ok, so the MXML compiler "does" have ties to the Flex SDK API but not directly in the directives correct? I know, I know I should just look at the code again. :) Mike > -Alex > >
