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
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
