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
