flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject RE: [FalconJx] MXML implementation notes
Date Mon, 21 Jan 2013 18:46:45 GMT
Right, hear you loud and clear.

That is why am I taking the same strategy the  
MXMLClassDirectiveProccessor does and use the MXML AST over the  
MXMLData since I do understand how that tree is created and need the  
semantics already applied.

With the ActionScript emitter I just wrote, combining it with the  
traversing and emitting is turning out to be a joy right now. I will  
have something committed in a while that ties both APIs together where  
the MXML uses the current walker and emitter for ActionScript so it  
can produce js in Script blocks etc. if that is what the intended  
output needs.

Anyway, thanks for your explanation again! I am always willing to read  
insights from you, as it helps me along my path.


Quoting Gordon Smith <gosmith@adobe.com>:

> Don't worry about offending me... I'm reasonably thick-skinned. If  
> there's a better way to do something, I want to know about it.
> MXMLData provides a pure-syntax model of MXML. By contrast, an MXML  
> AST encodes the semantic meaning of the MXML, in a way that makes it  
> straightforward to codegen.
> In AS, an expression, statement, or declaration has pretty much the  
> same meaning at any level of a program. But in MXML, the meaning of  
> a tag or attribute in the middle of an MXML file can only be  
> determined by a top-down walk, resolving tags like <s:Button> to  
> their corresponding class in order to determine the properties,  
> styles, and events of that class. So the tree-building phase is in  
> fact also a semantic analysis phase (with many MXML problems  
> currently not getting reported).
> An example of the ambiguities in MXML is
> <Foo>
>     <bar>whatever</bar>
> </Foo>
> In MXML, this could  mean a wide variety of things, depending on  
> where this snippet appears and how tags resolve, such as
> 1. Create a Foo instance and set its 'bar' property to "whatever".
> 2. Create a Foo instance and set its 'bar' style to "whatever".
> 3. Create a Foo instance and set its default property to an instance  
> of <bar>, where the default property of 'bar' has the value  
> "whatever".
> 4. Set the Foo property of the enclosing instance to an instance of  
> 'bar', where the default property of 'bar' has the value "whatever".
> These ambiguities are tamed a little by conventions such as starting  
> classes with a capital letter and properties/styles/ events with a  
> lower-case letter, but these are only conventions, and are sometimes  
> ignored such as with <p> representing an instance of  
> ParameterElement in TLF.
> - Gordon
> -----Original Message-----
> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> Sent: Monday, January 21, 2013 10:19 AM
> To: dev@flex.apache.org
> Subject: RE: [FalconJx] MXML implementation notes
> Gordon, every time you reply to something I say, it seems like I'm  
> offending you. I really am not. :)
> What I meant to say was ActionScript AST flows naturally out to  
> String source code, where as MXML requires pre and post processing  
> of the AST to make total sense of what you "might" produce.
> The AST itself is not "ugly", its the processing of it and making  
> sens of it the way you need it. I'm too poetic sometimes and I  
> apologize for that.
> I spent the last day studying the MXMLClassDirectiveProccessor and  
> fully understand how to traverse the MXML AST.
> So sorry for the misunderstanding, I didn't mean the AST is an ugly duckling.
> Mike
> Quoting Gordon Smith <gosmith@adobe.com>:
>>> MXML is an ugly duckling compared to surfing the AS AST
>> What issues are you referring to?
>> - Gordon
>> -----Original Message-----
>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>> Sent: Sunday, January 20, 2013 1:50 PM
>> To: dev@flex.apache.org
>> Subject: [FalconJx] MXML implementation notes
>> 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".
>>    - you are renaming with the "dummy" post fix, why?
>>    - 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 MyInitialView is sketchy, is uiDescriptors being created by you
>> or is that property created by the MXMLClassDirective?
>> - 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.
>> 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.
>> 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.
>> Mike
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com

Michael Schmalle - Teoti Graphix, LLC

View raw message