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 > >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. > >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. -Alex
