flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alain Ekambi <jazzmatad...@gmail.com>
Subject Re: [ASJS] Integration with existing JS libraries and components
Date Fri, 25 Jan 2013 22:41:06 GMT
Before going further with ExtJS make sure licensing is clear.
Cuz ExtJS is GPL/Commercial.

2013/1/25 Frank Wienberg <frank@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-

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message