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-