There are probably a lot of other MXML-isms like the classfactory handling.
But my hope is to get rid of as many as we can. Most if not all of this
code gen can be handled better by code in the framework interpreting data.
Really, if was practical to generate code on the fly in AS, I wouldn't
convert MXML at all, I would just suck it in as XML and parse it at runtime.
It would make for much smaller SWFs and take advantage of the JIT by making
the parsing loop hotter. Right now, Flex MXML generates lots of run-once
methods.
Binding is tricky only because I want to encode it as well. We don't want
to generate the current anonymous function wrappers for simple binding
expressions.
I'll put together a "spec" on the wiki about the data format. You might be
able to guess it from the MXMLDataInterpreter class.
On 1/21/13 4:48 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
> Alex,
>
> Responding inline would be to much of a mess.
>
> Basically half of my post was about the data spec. So you asking if I
> am looking for the data spec, my answer would be yes.
>
> I'm just trying to write a list of things I need to generate.
>
> To reiterate, I understand we are generating data structures, descriptors.
>
> We have to generate
>
> - wrappers for event handlers
> - conceptually seems pretty straightforward
> - deal with inner classes
> - What do you mean inner classes, the Component tag?
> - script blocks
> - these are IASNodes that are directly on the tree, this should not
> be hard, the way the current block emitter is setup with visit methods
> can push this stuff out right in the TypeScope
> - CSS
> - No idea right now, needs more thought
> - binding syntax
> - Since I have good ActionScript emitting, I can't see how the {}
> syntax in an attribute would be hard to generate. I may be
> underthinking but I really think that is doable soon.
>
>
> I will post any more direct questions I may have when I encounter them.
>
>
> Mike
>
>
>
>
>
> Quoting Alex Harui <aha...@adobe.com>:
>
>>
>>
>>
>> On 1/20/13 1:50 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> Alex this one is aimed at you. I have been studying what you have done
>>> for the whole day today and managed by copying about 1000 various
>>> lines of code to my prototype MXML emitter got your Fragment lists to
>>> be populated by my traversal.
>>>
>>> Now the question is, can you in about 5-6 paragraphs give me a nice
>>> detailed approach of yours with what is "needed".
>>>
>>> For example, I see;
>>>
>>> - The main application mxml file, this looks as though it's getting
>>> translated pretty "vanilla".
>> Not sure what you mean by that. For sure, I might have missed generating
>> some pattern the goog way. But it seemed like most of the "goog"-ness is in
>> the class and method signatures not in the function body, but I might have
>> missed something there.
>>> - you are renaming with the "dummy" post fix, why?
>> I am? I didn't think so. Also remember, lots of this code is not mine so
>> it might be doing something I'm not aware of.
>>> - in the constructor you are just using the InstanceNode values (I
>>> know this is all being done behind the scenes, I get how the
>>> directives work now and are processed recursively)
>> The constructor stuff could need work. I didn't do too much in the way the
>> constructor is "reduced" and mostly changed the way it gets emitted.
>>>
>>> - The MyInitialView is sketchy, is uiDescriptors being created by you
>>> or is that property created by the MXMLClassDirective?
>> MXMLClassDirective is the old-school code-gen. I have altered code paths in
>> many of the methods by adding the mxml.children-as-data flag. That causes
>> MXMLClassDirective to spit out the MXMLDescriptors and MXMLProperties arrays
>> that contain a description of the MXML tags. We are not going to use the
>> old code-gen: we will require this flag be set. But the AS code can consume
>> this kind of output, and I have a similar interpreter for the old SDK code.
>> JSMXMLClassDirective then just tries to transcode this stuff into JS.
>>> - Same with he event handlers, I see that is being take care of by the
>>> process method.
>>>
>>> I really think if you can give me as much information of what "you are
>>> doing and need", I could have FalconJx producing the MXML sooner than
>>> later. As I said I already have it spinning, just need to know exactly
>>> what you need at the moment.
>> I'm not 100% sure what you are looking for, the philosophy I have is that
>> MXML should generate as little "code" as possible. It should just generate
>> data where it can, so the AS/JS framework can generate the right widgets at
>> runtime. One thing you can't do is AS is generate new methods on the fly,
>> so the only code I think we have to generate is event handlers and complex
>> databinding expressions. Everthing else becomes data. Are you looking for
>> a spec on the data format?
>>>
>>> Also, this is where the framework will work out nice since when I need
>>> to emit ActionScript for the MXML, I will pass it the current emitter
>>> and send it through the ASBlockWalker.
>> This was a rough spot for me in the FalconJS code. You can be traversing
>> nicely through MXML nodes then hit AS nodes which in the FalconJS code start
>> calling the reducer and setting up the SWF constructs. Hopefully that
>> transition will be smoother for you.
>>>
>>> I will also be honest and say, MXML is an ugly duckling compared to
>>> surfing the AS AST, so when I say I can get your code working sooner
>>> than later, I really mean I can get exactly what you have, to prove we
>>> have all the right tools to put effort into the FalconJx version
>>> because it will produce everything we need.
>>>
>> I'm not sure what you mean by that, the tree walk seems pretty
>> straightforward to me, but yeah, what you emit is trickier. I think I've
>> made it harder by trying to build out that data structure, but we need data
>> and not code in order to allow it to be interpreted differently in AS vs JS.
>> Other than that, I think it is standard pain for MXML. We have to generate
>> wrappers for event handlers, deal with inner classes, script blocks, CSS,
>> binding syntax.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
