I wrote one of those. I wrote SVG -> AS3 graphics. And extending that class, I wrote FXG -> AS3 graphics.
It wasn't a complete implementation of the SVG or FXG standards. It didn't handle text, and complex gradients weren't perfect. The FXG class was based on Adobe's first FXG definition. But it worked pretty well. This was one of the features of the applications I offered to donate. Actually, if you go back to build r53 of extendedMadness. SVG was in there. I took it out, because I didn't think too may people would be interested - and to reduce the bloat. (I didn't want my Framework getting like Flex - did I), http://code.google.com/p/mad-components/source/detail?r=53# See example here: http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53 FXG isn't too different from SVG. ... I've mentioned this before, but I'd like to relinquish control a little over maintaining MadComponents, ExtendedMadness, and MC3D. I've offered before to donate them to this Apache group. Bear in mind that people aren't using Flex to build mobile apps. They're using MadComponents (General Purpose / Enterprise) or Feathers (Game UI). In fact, I've had clients engage my freelance services because they tried to build a mobile app using bloated Flex - and regretted it. http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/ Is there any interest in this group in MadComponents? On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle <apa...@teotigraphix.com>wrote: > > 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 > >
