Yeah when I was speaking about a backend I didn't mean as verbose as the js backends. I just meant when compiling for say Feathers, why have code even close to anything Flex SDK. There is a line between MXML AST and Flex styles, effects, design layer... ehe...
The problem as you have stated is there are multiple threads running and I can't just go in a rip stuff apart. I don't see why the if blocks of the children as data can't be separated. To me that would make things much more clear for future dev. Now I remember how this all works, the BURM is calling the directives which then are calling their builders. The BURM is actually traversing the AST of AS3. I can't remember without looking but what is parsing the MXML? Is that JFlex? Mike On Tue, Mar 1, 2016 at 6:31 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 3/1/16, 3:17 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > > > >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. > > Well, better abstraction is probably always good. I don't know if the > framework abstraction can be completely encapsulated in a "backend". I > think there is some resolving going on during the building of the AST that > required knowing what namespaces and classes are being used for data > binding. So right now there are several things dictated in the > -config.xml. IMO, it would be just as fine if all of the output > differences were defined in the -config.xml file so that there was just > one backend for mxml-children-as-data. The name of the flag has meaning: > I think the goal is to not have the compiler generate code for MXML, but > rather generate data that the framework can turn into code. > > Then you could compile your app with a flex-config.xml and switch to a > feathers-config.xml and it wouldn't change too much of the internal logic. > > There is a potential runtime advantage to MXML as data as well. With > MXMLC, all of the generated code is run once (and in Flash/AIR > JIT-compiled once as well) which is wasteful. With MXML as data, there is > no generated code to run and JIT compile once, the code that "interprets" > the data gets run many times which is a better use of JIT compilation and > supposedly the runtime optimizations in the browser. > > > > >I'm only guessing right now but some of my guesses have worked out pretty > >well. :) > > Yes they have, and I'm very interested in what you will come up with in > this regard. > > Thanks, > -Alex > >
