You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2013/01/20 22:50:12 UTC
[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
RE: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <go...@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 <go...@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
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FalconJx] MXML implementation notes
Posted by Gordon Smith <go...@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 <go...@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
RE: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <go...@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
RE: [FalconJx] MXML implementation notes
Posted by Gordon Smith <go...@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
Re: [FalconJx] MXML implementation notes
Posted by Alex Harui <ah...@adobe.com>.
On 1/21/13 6:46 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Ok here is the deal.
>
> As of now Alex is using a descriptor type emittion. Creating "init"
> objects that initialize a DOM instance.
>
I wrote up the descriptor format. Of course, there could be errors and
cases I haven't considered.
It is also linked from the ASJS prototype page where it talks about
MyInitialView.
https://cwiki.apache.org/confluence/display/FLEX/MXML+Data+Spec
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJx] MXML implementation notes
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Does this make sense?
It does, and thanks again for your patience.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ok here is the deal.
As of now Alex is using a descriptor type emittion. Creating "init"
objects that initialize a DOM instance.
So the ASJS emitter would load up a values object that when the
component is created, is populated by those descriptors.
Your method is different. Put it this way, I am not writing anything
concrete with either right now. Last night I discovered there are a
couple different ways to do this and I really need to be careful to
not couple the walker with a certain implementation like I was just
about to do with Alex's ASJS descriptors.
I need a higher level and that is what I am working on. Basically with
what I am writing, in your emitter, you will be able to visit and
"InstanceNode" and create code like you have above. The instance node
in MXML is the Button tag you wrote as an example.
By doing this, I can also write an emitter that when it visits an
InstanceNode for ALex, will create a descriptor of the properties he
needs and save that into the descriptors array.
Does this make sense?
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
> Just to ease my confused mind:
>
>> Of course, I am writing things along the same lines as the AS visitors BUT
>> there is a semantic difference that we are not exactly translating MXML AST
>> to js, so I need a bit more time figuring out the abstractions.
>
> "not EXACTLY translating", what does that mean? To what else but js
> will we be translating MXML? Won't I be able to emit this:
>
> <s:Button id="myButton" x="25" y="100" label="Click me" />
>
> to:
>
> var myButton = new Button();
> myButton.x = 25;
> myButton.y = 100;
> myButton.label = "Click me";
>
> (overly simplified example, but you get my drift)
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] MXML implementation notes
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
Just to ease my confused mind:
> Of course, I am writing things along the same lines as the AS visitors BUT
> there is a semantic difference that we are not exactly translating MXML AST
> to js, so I need a bit more time figuring out the abstractions.
"not EXACTLY translating", what does that mean? To what else but js
will we be translating MXML? Won't I be able to emit this:
<s:Button id="myButton" x="25" y="100" label="Click me" />
to:
var myButton = new Button();
myButton.x = 25;
myButton.y = 100;
myButton.label = "Click me";
(overly simplified example, but you get my drift)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> On Mon, Jan 21, 2013 at 1:48 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> he
>
>
> I'm not at all sure I understand the details of what you're
> discussing, so I'll just ask this one rookie question:
>
> will I be able to create something like a MXMLGoogEmitter.java to
> output the information in the MXML in a way that will let me interpret
> it the 'goog' way?
HAHA! Erik, this is Mike you are talking to, now wouldn't it be pretty
mean of me to only let one way exist for MXML production? ;-)
Of course, I am writing things along the same lines as the AS visitors
BUT there is a semantic difference that we are not exactly translating
MXML AST to js, so I need a bit more time figuring out the abstractions.
But it will be completely decoupled to where the backend will decide
the MXML emitter.
Mike
> Thanks,
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] MXML implementation notes
Posted by Erik de Bruin <er...@ixsoftware.nl>.
On Mon, Jan 21, 2013 at 1:48 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> he
I'm not at all sure I understand the details of what you're
discussing, so I'll just ask this one rookie question:
will I be able to create something like a MXMLGoogEmitter.java to
output the information in the MXML in a way that will let me interpret
it the 'goog' way?
Thanks,
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] MXML implementation notes
Posted by Alex Harui <ah...@adobe.com>.
On 1/21/13 9:02 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>> 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,
>
> What do you mean generate code on the fly, you mean ABC bytecode
> during runtime in the player?
Yes. Technically I know it is "possible", and believe me, I have thought
about leveraging it at times.
>
> 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.
>
>
> I'm keeping .js in mind for mxml as well so I guess this is just mute
> point right now.
I believe js performance will also benefit from re-use of code vs lots of
run-once methods.
>
>
>> I'll put together a "spec" on the wiki about the data format. You might be
>> able to guess it from the MXMLDataInterpreter class.
>>
>
>
> Yeah I noticed that class last night, it would be nice to read
> something you write though.
Okeydokey.
>
> Mike
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
> 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,
What do you mean generate code on the fly, you mean ABC bytecode
during runtime in the player?
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.
I'm keeping .js in mind for mxml as well so I guess this is just mute
point right now.
> 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.
Yeah, for now I am not thinking about this stuff, I am getting the
walker and visitor pattern API setup so there can be different
implementations just like there is in AS.
Although it is about 2-3 times harder in MXML because I have to be
able to generate AS inside the MXML, I'm getting something working and
the concept seems solid to me.
> I'll put together a "spec" on the wiki about the data format. You might be
> able to guess it from the MXMLDataInterpreter class.
>
Yeah I noticed that class last night, it would be nice to read
something you write though.
Mike
>
> On 1/21/13 4:48 AM, "Michael Schmalle" <ap...@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 <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 1/20/13 1:50 PM, "Michael Schmalle" <ap...@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
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] MXML implementation notes
Posted by Alex Harui <ah...@adobe.com>.
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" <ap...@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 <ah...@adobe.com>:
>
>>
>>
>>
>> On 1/20/13 1:50 PM, "Michael Schmalle" <ap...@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
Re: [FalconJx] MXML implementation notes
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <ah...@adobe.com>:
>
>
>
> On 1/20/13 1:50 PM, "Michael Schmalle" <ap...@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
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] MXML implementation notes
Posted by Alex Harui <ah...@adobe.com>.
On 1/20/13 1:50 PM, "Michael Schmalle" <ap...@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