Before going further with ExtJS make sure licensing is clear. Cuz ExtJS is GPL/Commercial.
2013/1/25 Frank Wienberg <fr...@jangaroo.net> > 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- >
