Quoting Alex Harui <aha...@adobe.com>:
In my simple mind, Falcon generates the AST then at some point in time the
futures task for that compilation unit is asked for output. Current Falcon
code calls the BURM which eventually calls an emitter, I'm assuming FalconJX
does an AST tree walk instead of calling the BURM. There is no reduction,
just emitting. CSS for JS is probably just going emit text from the tree.
Yes this is correct basically.
Each compilation unit implements its own handleASBRequest() that gets
called during a generator request. This request ONLY happens AFTER the
handle AST and Scope requests have been processed.
Its very complicated below that principle because of the future tasks
and outgoing dependency requests that trigger other files to be
parsed, scopes built etc.
THe framework is elegant. The only thing I wish I could tear out and
abstract is how they have SWF baked into ITarget and Target.
This really makes it hard to do what we are doing without all this "baggage".
As I said, parsing is multithreaded right now in FalconJx, I can
easily get the source code generation multithreaded to now that I have
learned how the framework wheels move together.
I'm just not at the point to worry to much about it at the moment
because in a couple of my test projects, the compiler is wicked fast,
I also have an implementation that uses the Workspace and only loads
config once, which is using the framework like and IDE does...
Mike
On 3/15/13 1:44 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
BTW,
I have not seen one thing that you are asking for that doesn't contain
an AST and node framework in the Falcon package.
If it was me, I would create all the emitters exactly the same way be
parsing the file, handling the AST, traversing it while outputting to
the target, then writing it in its file format.
Its simple and I guess the FalconJx framework is mainly due to me
dealing with inheritance and dependency madness with Flex components
for years. I said all my future projects will use composition, this
one does big time.
Mike
Quoting Michael Schmalle <apa...@teotigraphix.com>:
Quoting Alex Harui <aha...@adobe.com>:
On 3/15/13 1:14 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
The problem is, SWF is so
interconnected in the generator packages that you might have a problem
getting a polarity with using the BURM.
Don't know what "polarity" meant, but hopefully it doesn't really matter.
Bad word, I meant polarity in emitters as what the BURM generators
offer right now with FalconJS, properties, css, as, mxml.
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.
Good point about the generators being tied to SWF constructs. But I am
assuming you that, in order to service different file types we will have
several emitters? One for AS, one for MXML/AS? I think I will create one
for CSS and someone will create one for FXG->SVG? And since these two
probably won't generate JS "classes", I think they won't be tied
to the SWF
constructs in the generator and thus will copy over "easily".
Right, if I was getting paid for this stuff, I could have most of it
done in a month or two, so using the pattern I have created with
FalconJx all your emitters with file handlers are possible.
To realize what you need Alex, the knife is already built, its just
adding the blades.
Mike
--
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
--
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
