flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <teotigraphix...@gmail.com>
Subject Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Date Tue, 01 Mar 2016 23:17:52 GMT
On Tue, Mar 1, 2016 at 6:11 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
> On 3/1/16, 2:32 PM, "Michael Schmalle" <teotigraphixllc@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message