On Tue, Mar 1, 2016 at 6:11 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 3/1/16, 2:32 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >> > >> > > >> >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? > > Well, when you look in MXMLClassDirectiveProcessor you will see lots of > code forks for when -mxml-children-as-data is true. I suppose at some > point someone could do more refactoring to clean it up. It just hasn't > been a priority. One side of the fork generates the MXMLC code, the other > generates the data structures I've described in this thread. > >
Yup, carrying on from my last post I already had an intuition that class needs to be refactored and abstracted for the very same reason you stated. I can imagine what it would look like if you ripped all the Flex SDK out and placed it into a FlexClassDirective and used a strategy to call it. It seems to me that this would be somewhat of a backend like we have with JS and AS in the FlaconJX framework. What is really kewl is I think I will actually be a ble to do this and maybe break it a part to be able to add those flags that would direct the compiler which way to actually generate the hooks. In my ignorant view right now I would say the goal is to make the MXML compiler have a backend for the framework API hooks, this would be correct in my head, the right way to direct. I'm only guessing right now but some of my guesses have worked out pretty well. :) Mike > -Alex > >
