On 1/10/13 6:05 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> - work with Alex to get FlexJS to work with FalconJx so we can test
> the whole intended 'goog' workflow, include 'my' Publisher script
Excellent news! In between TLP and release stuff I have been slowly
plugging away at getting FalconJS to output goog code for both AS and MXML.
I've done a bunch of changes to the frameworks files to make it easier to
deal with the MXML output. I'm at the point of finally trying to get it all
to run. Some things like data-binding {} syntax is still not supported but
you can add a "bead" to bind something simple.
I stayed with FalconJS for two reasons: 1) I didn't know how long Erik and
Mike would take and 2) I felt like I needed to understand FalconJS better so
we can truly understand the trade-offs between FalconJX and FalconJS. So
far, I'm becoming more convinced that the AST tree walker in FalconJX will
suit our needs "better". For example:
-FalconJS has some really complex constructor handling code. That's because
initialized instance properties in AS are "moved" to the constructor.
However, in JS that isn't required as we can initialize them on the
prototype (unless there is some subtle rule about how arrays get
initialized) so no need to jump through all of these hoops in FalconJX.
-FalconJS has what I would call top-down tree walking for MXML parsing. But
then if you hit AS code in an event handler or script block you have to send
that stuff through the BURM.
-The BURM is still an impenetrable fortress for me. So far I haven't had to
change it and have sort of figured out how to debug into it, but if
GoogleClosure is going to do the same sort of optimizations for us, it isn't
clear we really need it. The only area we might need something like it is
for future optimizations of data-binding output code. Current data-binding
code is very general and highly inefficient. We want to someday output
different patterns of data-binding code in different situations (like in an
item renderer or when bound to a data model). This will require
understanding more about what the code is trying to do. But Falcon already
has the basic pieces for this so maybe we can leverage it as needed.
So, anyway, I hope to check in this week or weekend and then will eagerly
look forward to FalconJX growing up to replace it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
