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.
Mike
Quoting Gordon Smith <gosm...@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:apa...@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 <gosm...@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:apa...@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
http://www.teotigraphix.com
http://blog.teotigraphix.com
