@Roland For the SDK it s surely not a problem since it s all Apache. But anyone using the Apache Flex SDK to write an ExtJS application will need a commercial license from Sencha or will have to open source the code.
This is worth mentioning. (I wrote an SDK around EXTJS, so i know for sure) 2013/1/25 Roland Zwaga <rol...@stackandheap.com> > Hi Alain, > > I'm not sure if the license really comes into play here, all we're doing is > integrate with an API, > we don't fork or use their code in any way. > We might have to look into the implications for crating an AS3 shim for > their API's though, > so you do make a valid point. > > Roland > > On 25 January 2013 23:41, Alain Ekambi <jazzmatad...@gmail.com> wrote: > > > 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- > > > > > > > > > -- > 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 >
