There is no major surgery anywhere.
If you study the framework like I have, there is really only one way
to assemble a compiler in Falcon.
What I haven't done is allow for this other processing (css,
properties). Honestly this has not even fit into a use case for me and
I never thought about needing it for the project.
Falcon is not a compiler, its a framework of components that can be
put together to make a compiler front end. The problem is, SWF is so
interconnected in the generator packages that you might have a problem
getting a polarity with using the BURM.
On that note; This would take more study to fully understand, but at
the moment I don't have time to investigate. I guess you will have to
weigh the options or get a "feel" for the Falcon framework when your
not under as much of a timeline/deadline?
That being said, the FalconJx framework was meant to be created in
component sections, so if your end goal is to create things with it
fully, I would suggest things being ported to its emitter, or it will
for ever have a crutch on SWF.
Mike
Quoting Alex Harui <aha...@adobe.com>:
On 3/15/13 12:56 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
don't believe that any of the work I am doing is wasted. FalconJS is not
the competition, it is just a stop-gap place for me to experiment until
FalconJX catches up.
Ok, I wrote too long a statement (as ususal). The TL;DR version is: if
you continue to work on FalconJS, I won't be able to keep up on the
FalconJx side.
My point is that there is nothing to keep up with. All the work I'm doing
is not in the MXML emitter work you are doing and should just copy over,
unless you and Mike have done major surgery to the rest of Falcon.
--
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
