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

Reply via email to