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-
