Hey Frank, thanks a lot for your elaborate answer (as usual). Basically everything I had in mind you pretty much described. So I'm pretty stoked that this could be implemented rather quickly. Between your and Erik's approach I already prefered yours to be honest (Erik, this is no stab under water in your direction, its just my opinion, hehe). My main problem with using Closure is that it introduces a second parsing and manipulation pass while, IMHO, all of the necessary work can be done inside Falcon since all necessary information is contained within the AST. Therefore implementing the whole shebang inside Falcon will be faster. Plus it removes a dependency, which is always good, again IMHO. The fact that your requireJS approach is also asynchronous is a big boon as well. It means an application could be loaded incrementally much easier, and from what I understand incredibly granular. Its awesome to read that you already have a system in place to generate an AS3 shim for the extJS components, that'll definitely save some typing :)
Anyways, I have some thoughts about the actual implementation of all of this, but I'm gonna write those down tomorrow. For now I think I want to head to bed :) cheers everyone, Roland On 25 January 2013 23:25, Frank Wienberg <fr...@jangaroo.net> wrote: > Hi Roland, > > thank you for bringing up this point, I think it is crucial for the success > of Apache Flex / JS! > I Erik's latest thread, we just discussed the different approaches to come > up with a JS-enabled component library for Flex. > I mentioned that we already have an ActionScript-API for Ext JS from the > Jangaroo project. > Using the original Ext JavaScript code for deployment and the "Ext AS" API > for IDE support and compilation, you can create Ext JS applications in AS3 > and MXML. > Jangaroo actually uses a [Native] annotation, but does not yet support > referencing the script to load or alias the JavaScript identifier. > Both Erik and I propose using a JavaScript module approach (Erik chose > Google's Closure library / goog.require(), I use AMD / RequireJS). The cool > thing about generating JavaScript code that uses a require() API is that is > plays well with "native" JavaScript code. You can require() JS code from AS > code and vice versa. I still think that RequireJS is the better choice, as > Closure implements *synchronous* require() which does not work dynamically > in the browser, and the Closure Library comes with many many more features, > while RequireJS just focuses on (loading and linking) modules. > In any case, a JavaScript module is defined by two things > * which script to load > * what to return as the "value" of the module > The module loader takes care of every script being loaded exactly once, > store the value, and return the (same) value on every subsequent require() > call. > So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the way to > go, complemented by a way to specify what the module value is. For example, > [Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the > module loader, "load and evaluate the script /js/jquery-1.4.js once, and > every time return the value of the global variable 'jquery'". So then, the > compiler would be able to generate require() calls to the right script and > retrieve the right member afterwards. For RequireJS, there is a shim! > plugin<https://github.com/brettz9/shim/#readme>that does something > similar. It is easy to write a custom plugin that would > allow writing something like > > define(["global!jquery@js/jquery-1.4"], function(JQuery) { > // use "class" JQuery... > } > > Using this approach, we can define an API for a JavaScript file that > defines several classes, which is quite typical. > > To generate the Ext AS API, I wrote a Java tool > (ExtAsApiGenerator< > https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java > >, > part of jangaroo-tools on github) that imports the JSON format exported by > Sencha's JSDoc documentation tool > jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and > generates AS3 API wrappers. So updates of the original API can easily be > taken up, and other JavaScript APIs that use or are compatible with jsduck > can be translated to AS3 APIs. Also, if you need a slightly different AS3 > API (e.g. different annotations), the tool is easy to adapt to your needs > (after all, it is open source). > > All in all, I think there is great potential in combining Flex and > JavaScript, and we need to provide good tool support to make it easy! > > Cheers, > -Frank- > -- regards, Roland -- Roland Zwaga Senior Consultant | Stack & Heap BVBA +32 (0)486 16 12 62 | rol...@stackandheap.com | http://www.stackandheap.com http://zwaga.blogspot.com http://www.springactionscript.org http://www.as3commons.org
