We can walk the AST if we have the source code. However, if an MXML class gets compiled into a SWC, I don't think there's a way to figure out which properties are being set in MXML from the definitions alone. When I was investigating some things, I tried the AST walk until I realized that it only worked in my app project, and not with the classes that I was using from framework SWCs.
I might actually end up looking at adding an option to convert public vars into getters/setters first. Should be easier than some of the alternatives, which I can dig into more later. I like your idea of a swappable MXMLDataInterpreter. Something for me to consider. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Thu, Mar 26, 2020 at 11:58 AM Alex Harui <aha...@adobe.com.invalid> wrote: > > > On 3/26/20, 11:14 AM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> wrote: > > Snip... > > I'm currently looking into a way to include a function with the MXML > descriptor that can be used to set the property, even if it has been > renamed. An evolution of what I proposed a couple of months ago. > However, I > plan to keep both the string name and the value inside the descriptor > so > that it does not affect your debugging approach. > > A single property in the MXML descriptor looks like this now: > > [ > "someProperty", > true, > 123.4 > ] > > It might look something like this after my change: > > [ > "someProperty", > function(value) { this.someProperty = value; }, > true, > 123.4 > ] > > If the function exists, it will be called like this (where host is the > component/object being created): > > var func = descriptor[i]; > func.call(host, value); > > This will ensure that someProperty can be renamed, and all of the > original > data is preserved for debugging. > > I should be able to make the compiler smart enough to only include the > function where necessary (public vars) and omit it when not necessary > (public setters) to save on file size and make it PAYG. I would, of > course, > also add a compiler option to include no functions in the descriptor > (in > other words, keep the existing behavior). > > Please consider the PAYG aspects of this approach. Without thinking about > it too much, it will at minimum make the MXMLDataInterpreter have to think > harder whether you use that capability or not. > > It might be that we need to make sure there is an easy way to replace > which MXMLDataIntepreter gets used so that more sophisticated logic can be > plugged in if the app developer asks for it. And if we can do that, then > it might just be easier to have a test to see if the property exists before > setting it and if it doesn't check some sort of rename map. > > Or, can we know which classes are having properties set via MXML and swap > out public vars for getter/setters? > > HTH, > -Alex > >
