Re: [ASJS] Integration with existing JS libraries and components
Hi, We're talking AS - JS cross compilation. So changing one file would be changing one AS file. To turn that AS file into a JS file needs a compilation step. The generation of 'deps.js' is part of the compilation step. So, in the scenario we're discussing, the regeneration is of no consequence. Also, more importantly, 'deps.js' is only needed for the 'intermediate' output, not in the release output. I think if we're going to be comparing anything, we should be comparing 'production/release' code, not 'convinience/intermediate' code, right? No, I *do* talk about the intermediate code, as I see it as the *primary* compilation result, and the production/release code as a derived artifact. The former is the code developers see during debugging their application. Nobody cares about how the production code looks like as long as it works, it concise and performant. That's where we differ in our approach, apparently: I think of the JS code as a replacement for the bytecode that feeds the Flash VM. Nobody but compiler/framework devs debug bytecode. And in my view, nobody but compiler/framework devs should (need to) debug Flex JS. The framework should just work for application devs. Their development (debugging) is in AS (Flash Builder), JS is just an output format, like bytecode if they choose to deploy in the Flash Player. This makes the release js (calling that a derived artifact is a bit dismissive, as it is the primary product of my effort). While it was fun, I think we have been at this for long enough. I have said all I possibly can on the subject and nothing you've said convinced me that -- other than being different and not what you would choose -- my approach is fundamentally wrong. I think I have backed up my position with a solid proof on concept. I will be spending my time improving and expanding that proof of concept and, in time, ask the community if my (and hopefully other's!) contributions are worthy to be included in the Flex SDK. Or, if someone does manage to convince me that another approach is better (e.g. FlexJS, or a tangible AMD implementation), I'll put my efforts into helping get that out of the door. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Alain, In my view all development, including debugging, is done in AS. The JS output, like bytecode, should just work. EdB On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi jazzmatad...@gmail.com wrote: One thing I was thinking about. How would debugging work ? Let's say I set a break point in my as3 code how will debugging the js output look like Greets Alain On Jan 28, 2013 8:37 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, entire library + application. My example was that you change a single file, but change it in a way that you add a dependency. Without re-generating deps.js, base.js could not know in advance that the newly We're talking AS - JS cross compilation. So changing one file would be changing one AS file. To turn that AS file into a JS file needs a compilation step. The generation of 'deps.js' is part of the compilation step. So, in the scenario we're discussing, the regeneration is of no consequence. Also, more importantly, 'deps.js' is only needed for the 'intermediate' output, not in the release output. I think if we're going to be comparing anything, we should be comparing 'production/release' code, not 'convinience/intermediate' code, right? and compile it with Jangaroo 3 and also deploy the output. What do you think? I enabled View Source on the Flash output, so you can grab the AS source and put it through Jangaroo if you please. You can also pick up Alex's FlexJS source and do the same with that.Might be interesting to see what comes out and compare the various approaches when using a different compiler. Yes, I'll try to do that, but except from the deps.js file discussed above I expect the difference to be rather small. So, if 'deps.js' is not needed -- like it's not needed in the 'release' output of my proof of concept -- there really isn't any practical difference between our approaches? However, I still think it is better to consolidate than to offer too much to chose from (where it brings no benefit). And I'd still like to hear your I'd love to consolidate, and I'm reading your Wiki pages with interest on how to tackle some of the language inconsistencies between AS and JS. I just wish that we could work together on code, instead of going round and round on theory and relative merits of two different but equal approaches. opinion on my warning that the input language for GCC is a dialect of JavaScript (restrictions, extensions), not standard JavaScript. If by GCC you are referring to the compiler, [1] should answer your question. The Google Tools (which include, but are not limited to, the compiler) like to have their JavaScript in a 'pseudo-classical' pattern, but that doesn't mean they won't gladly handle other patterns, like AMD. The JSDoc annotations are only there to help the GCC do an even better job, but are not required for the code to function as coded. What about the input language for GCC do you regard as a dialect of vanilla JS? EdB 1: https://developers.google.com/closure/compiler/faq#restrictions -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Hi Alain, for Jangaroo, I answered this question here: http://markmail.org/message/bwjwc7sxfbertu7f For Flex / FalconJx, it seems nobody was extremely fond of the idea to have to keep all the white-space and take care of generating JS code in the exact line of the source AS code. So we have to find another solution for the problem. One could be to use JavaScript source mapshttp://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ to provide a link from the generated code back to the original code. Chrome's developer tools can already read source maps and display the original source code in the debugger. When you set a breakpoint there, the debugger knows where to break in the JS code and stops accordingly. It's like magic! Firefox and IE are going to implement this feature, too, but it is not there yet. I implemented experimental support for source maps in Jangaroo, you can see a screenshot of how it would feel here: http://twitter.yfrog.com/z/odaebmp Google Closure Compiler and Uglify2 can both generate source maps, but only from the generated JavaScript to the minified JavaScript. We would have to take care to create a source map from AS source code to our generated code. Closure provides a Java API, which I successfully used for the Jangaroo source maps prototype. We could even chain both source maps into a direct mapping from AS code to minified JavaScript. Note that minified JavaScript will still be harder to debug, as local variables and other identifiers have been renamed, functions may have been inlined and so on. Greetings -Frank- On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi jazzmatad...@gmail.comwrote: One thing I was thinking about. How would debugging work ? Let's say I set a break point in my as3 code how will debugging the js output look like Greets Alain On Jan 28, 2013 8:37 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, entire library + application. My example was that you change a single file, but change it in a way that you add a dependency. Without re-generating deps.js, base.js could not know in advance that the newly We're talking AS - JS cross compilation. So changing one file would be changing one AS file. To turn that AS file into a JS file needs a compilation step. The generation of 'deps.js' is part of the compilation step. So, in the scenario we're discussing, the regeneration is of no consequence. Also, more importantly, 'deps.js' is only needed for the 'intermediate' output, not in the release output. I think if we're going to be comparing anything, we should be comparing 'production/release' code, not 'convinience/intermediate' code, right? and compile it with Jangaroo 3 and also deploy the output. What do you think? I enabled View Source on the Flash output, so you can grab the AS source and put it through Jangaroo if you please. You can also pick up Alex's FlexJS source and do the same with that.Might be interesting to see what comes out and compare the various approaches when using a different compiler. Yes, I'll try to do that, but except from the deps.js file discussed above I expect the difference to be rather small. So, if 'deps.js' is not needed -- like it's not needed in the 'release' output of my proof of concept -- there really isn't any practical difference between our approaches? However, I still think it is better to consolidate than to offer too much to chose from (where it brings no benefit). And I'd still like to hear your I'd love to consolidate, and I'm reading your Wiki pages with interest on how to tackle some of the language inconsistencies between AS and JS. I just wish that we could work together on code, instead of going round and round on theory and relative merits of two different but equal approaches. opinion on my warning that the input language for GCC is a dialect of JavaScript (restrictions, extensions), not standard JavaScript. If by GCC you are referring to the compiler, [1] should answer your question. The Google Tools (which include, but are not limited to, the compiler) like to have their JavaScript in a 'pseudo-classical' pattern, but that doesn't mean they won't gladly handle other patterns, like AMD. The JSDoc annotations are only there to help the GCC do an even better job, but are not required for the code to function as coded. What about the input language for GCC do you regard as a dialect of vanilla JS? EdB 1: https://developers.google.com/closure/compiler/faq#restrictions -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
On Mon, Jan 28, 2013 at 10:04 AM, Erik de Bruin e...@ixsoftware.nl wrote: Alain, In my view all development, including debugging, is done in AS. The JS output, like bytecode, should just work. EdB This won't work for us (Jangaroo/Ext AS users). In our development workflow, JS/HTML5 is the one and only target platform. And I think this is the future for Flex. If Flex will not support the full development lifecycle for HTML5 projects, it is of no interest for us and I guess for many others, and I'd even dare say it is doomed. -Frank-
Re: [ASJS] Integration with existing JS libraries and components
This won't work for us (Jangaroo/Ext AS users). In our development workflow, JS/HTML5 is the one and only target platform. And I think this is the future for Flex. If Flex will not support the full development lifecycle for HTML5 projects, it is of no interest for us and I guess for many others, and I'd even dare say it is doomed. I'm not talking about what Flex in general supports or does not support. That's up to the community and depends entirely on the contributions you, me and others make to the project. All I said is that in my view (the only one I have ;-)), JS is 'just' another output format for projects built with the Flex SDK. The Flash Player and AIR aren't going anywhere soon, dismissing them as a delivery platforms for the Flex SDK is nonsense. FYI: the main inspiration for my point of view about generated JS came from here: http://blogs.adobe.com/bparadie/tag/actionscript/ And please: what might doom Flex is people talking about what will doom Flex. All that does is feed the trolls that make a living of writing negative stories about tech subjects. Like with the stock markets, often all it takes is one rumor going viral... EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
On Fri, Jan 25, 2013 at 11:56 PM, Alain Ekambi jazzmatad...@gmail.comwrote: @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) Yes, Alain, I can second that. So it is not the perfect choice for every project, but since Flex targets enterprise software, I think it is still a valid choice. -Frank-
Re: [ASJS] Integration with existing JS libraries and components
Please take a look at the proof of concept (both the intermediate and release code) before making these kinds of statements. I'd like to, but you admitted yourself that it has quite an initial overhead to set up. Could you perhaps set up an online demo where one can observe a running system? Or a download of the compiled application? At least that's what I did for the AMD approach: Excellent idea. Here is the full Flash version (+ view source) and both the 'intermediate' and 'release' output of the proof of concept: http://people.apache.org/~erikdebruin/vanillasdk/ A bit of view source will show you why I've been saying what I've been saying. The 'getting started' page for the Closure Tools, as its name implies, only covers the basics. There is, however, a bit more to the story, as you can see ;-) I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Is Example.js a generated cross compile? Mike Quoting Erik de Bruin e...@ixsoftware.nl: Please take a look at the proof of concept (both the intermediate and release code) before making these kinds of statements. I'd like to, but you admitted yourself that it has quite an initial overhead to set up. Could you perhaps set up an online demo where one can observe a running system? Or a download of the compiled application? At least that's what I did for the AMD approach: Excellent idea. Here is the full Flash version (+ view source) and both the 'intermediate' and 'release' output of the proof of concept: http://people.apache.org/~erikdebruin/vanillasdk/ A bit of view source will show you why I've been saying what I've been saying. The 'getting started' page for the Closure Tools, as its name implies, only covers the basics. There is, however, a bit more to the story, as you can see ;-) I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [ASJS] Integration with existing JS libraries and components
On Sun, Jan 27, 2013 at 1:03 PM, Erik de Bruin e...@ixsoftware.nl wrote: Please take a look at the proof of concept (both the intermediate and release code) before making these kinds of statements. I'd like to, but you admitted yourself that it has quite an initial overhead to set up. Could you perhaps set up an online demo where one can observe a running system? Or a download of the compiled application? At least that's what I did for the AMD approach: Excellent idea. Here is the full Flash version (+ view source) and both the 'intermediate' and 'release' output of the proof of concept: http://people.apache.org/~erikdebruin/vanillasdk/ A bit of view source will show you why I've been saying what I've been saying. The 'getting started' page for the Closure Tools, as its name implies, only covers the basics. There is, however, a bit more to the story, as you can see ;-) Thank you Erik, for providing a running version so quickly. That really helps! I think I can now pinpoint the difference to RequireJS: It is in the existence of deps.js. deps.js says it's generated, and seems to be the extracted dependencies of all the other JS files, right? Aha, so this is how the necessary scripts get loaded in advance. And this is where you need the build tool: To extract the dependencies and generate this additional file deps.js. RequireJS has a similar mechanism, called shims. You can shim any JavaScript library that was not made for AMD by specifying dependencies in an additional configuration file. See http://requirejs.org/docs/api.html#config-shim But for modules written in the AMD style, a deps file is not necessary. What I criticize is that dependencies have to be specified twice. Granted, the second occurrence is generated by a tool, but that means you have to use the tool. It just makes things more complicated and more dependent. Why should this be necessary, when there is another solution that works without this redundancy and build step? Especially in development mode, when I change a single AS source file, it would be great if it would suffice to re-generate only the corresponding JS file. But when you add a dependency to your AS code, deps.js would have to re-generated, too, and as it looks quite monolithic, this operation might be expensive. With the AMD approach, you can re-generate exactly one file and reload in the browser, and everything will work. I know that for some Flex folks, development turn-around to the browser is not such an important issue, as they see the JS output more like an alternative deployment format, so they'll test in Flash or AIR and only deploy and QA in HTML5. I see a different scenario, where Flex is used to develop primarily for HTML5, which makes fast development turn-around to the browser a necessity. One more thing, something I didn't find out is how deps.js gets loaded. It has to be triggered by base.js somehow. Can you please explain? I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? Greetings -Frank-
Re: [ASJS] Integration with existing JS libraries and components
Quoting Frank Wienberg fr...@jangaroo.net: I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? Greetings -Frank- I am pretty sure he means, When Mike implements this in FalconJx, we con compare ;-) BTW, just getting over the flu. This is on my list, believe me, so we can stop wasting time with these huge emails back and forth and just compare and performance test. :) MXML is going to wait, I did a bit bit, put some hooks in but there is more pressing things I want to spend my time on, this is one and the other is what Roland just announced for discussion with the compiler. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [ASJS] Integration with existing JS libraries and components
On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle apa...@teotigraphix.comwrote: Quoting Frank Wienberg fr...@jangaroo.net: I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? Greetings -Frank- I am pretty sure he means, When Mike implements this in FalconJx, we con compare ;-) Sorry if I missed a joke, but I was saying the opposite, why not compare now? Why does it have to be implemented in FalconJx when we discuss/compare the output format, not the compile process? MXML is going to wait, I did a bit bit, put some hooks in but there is more pressing things I want to spend my time on, this is one and the other is what Roland just announced for discussion with the compiler. So do we really only compare the approaches by the resulting performance? That would be sad. There are many other factors: * Code size * Modularity (= do you have to re-compile class B if class A changed?) * Development turn-around effort * Complexity of solution * ... These should all be regarded before a final decision for one or the other. Greetings -Frank-
Re: [ASJS] Integration with existing JS libraries and components
Frank, Definitely a cultural difference here with my writing below. Basically, the point was, you CAN compare right now but, I think Erik was or just missed that fact you CAN compare right now. As far as your comments about how things should be compared, my point was, start comparing! :) Enough of the emails, like you said, you have the two outputs, go to town. Again, I guess I should have just kept my mouth shut here as I have previously stated, I will never have an opinion about this stuff, since I will never know enough to give an opinion. :) Frank, a lot of what I said below was from a more sarcastic, lets just get the ball rolling point of view. Mike Quoting Frank Wienberg fr...@jangaroo.net: On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle apa...@teotigraphix.comwrote: Quoting Frank Wienberg fr...@jangaroo.net: I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? Greetings -Frank- I am pretty sure he means, When Mike implements this in FalconJx, we con compare ;-) Sorry if I missed a joke, but I was saying the opposite, why not compare now? Why does it have to be implemented in FalconJx when we discuss/compare the output format, not the compile process? MXML is going to wait, I did a bit bit, put some hooks in but there is more pressing things I want to spend my time on, this is one and the other is what Roland just announced for discussion with the compiler. So do we really only compare the approaches by the resulting performance? That would be sad. There are many other factors: * Code size * Modularity (= do you have to re-compile class B if class A changed?) * Development turn-around effort * Complexity of solution * ... These should all be regarded before a final decision for one or the other. Greetings -Frank- -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [ASJS] Integration with existing JS libraries and components
That being said, I think both Erik and I got the ball rolling. It is not as if we are just talking theory here. We both have a working demo everybody can look at, and have both posted our arguments. Maybe we should just start a new thread to get this to a decision. But I don't want to force a decision right now; if you (Mike) are still willing to implement the AMD approach in FalconJx, we can just continue in parallel and see where it leads to. I have continued on the Wiki page, renamed it and started with the compilation unit concept, which is probably the other big difference between Erik's approach and mine: https://cwiki.apache.org/confluence/display/FLEX/Simulating+AS3+language+features+in+JavaScript+using+AMD+and+ES5 The still empty headlines are all for minor topics which we can tackle later. So from my side, you could start as soon as the flu's gone and MXML is done... ;-) Greetings -Frank-
Re: [ASJS] Integration with existing JS libraries and components
Yes, the one in 'intermediate' is. The one in 'release' is the 'intermediate' version, but run through the Closure Compiler. EdB On Sun, Jan 27, 2013 at 1:48 PM, Michael Schmalle apa...@teotigraphix.com wrote: Is Example.js a generated cross compile? Mike Quoting Erik de Bruin e...@ixsoftware.nl: Please take a look at the proof of concept (both the intermediate and release code) before making these kinds of statements. I'd like to, but you admitted yourself that it has quite an initial overhead to set up. Could you perhaps set up an online demo where one can observe a running system? Or a download of the compiled application? At least that's what I did for the AMD approach: Excellent idea. Here is the full Flash version (+ view source) and both the 'intermediate' and 'release' output of the proof of concept: http://people.apache.org/~erikdebruin/vanillasdk/ A bit of view source will show you why I've been saying what I've been saying. The 'getting started' page for the Closure Tools, as its name implies, only covers the basics. There is, however, a bit more to the story, as you can see ;-) I'm looking forward to seeing the Falcon implementation of your AMD/RequireJS ideas and it's output, so we can compare the various suggested approaches on their technical merits as well as their theoretical underpinnings. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
I think I can now pinpoint the difference to RequireJS: It is in the existence of deps.js. deps.js says it's generated, and seems to be the extracted dependencies of all the other JS files, right? Aha, so this is how the necessary scripts get loaded in advance. And this is where you need the build tool: To extract the dependencies and generate this additional file deps.js. No, the deps.js is just a list of ALL the require statements in the entire library + application (indeed generate during the publish process. However, ONLY the files listed that are ACTUALLY USED are loaded dynamically by the code in 'base.js'. If you look in either Chrome or FF you can see which script files are actually loaded and compare that list agains the 'deps.js' list. You'll see that the only file hard-coded into the HTML is 'base.js', which is the equivalent of 'require.js' in your approach. All the other script files are loaded dynamically, in order, based on the dependencies as given in their contents, much like with Require.js. With the AMD approach, you can re-generate exactly one file and reload in the browser, and everything will work. Same with the 'goog' way. One more thing, something I didn't find out is how deps.js gets loaded. It has to be triggered by base.js somehow. Can you please explain? It's a kind of magic :-) As I explain above, 'base.js' uses it, together with the 'provide' and 'require' statements to figure out which other project files to load. Let me press that point, since it seems to be pivotal to the discussion: ONLY the files that are ACTUALLY needed to run the application are loaded into the browser. NOT all the files in 'deps.js' and certainly not all the files in the Closure Library. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? I enabled View Source on the Flash output, so you can grab the AS source and put it through Jangaroo if you please. You can also pick up Alex's FlexJS source and do the same with that.Might be interesting to see what comes out and compare the various approaches when using a different compiler. I think you're not going to convince me to throw away all the work I did so far (and I strongly believe is at least as valid for our purpose as what you are suggesting) and start the whole process again based on your approach, only to do away with one step in the build process of the intermediate output (the 'deps.js' you object to plays no role in generating the 'release' code). I'll continue development of my proof of concept and I hope to find other contributors willing to help out. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Well the PMC would not veto commits. It would veto the notion o including something in the SDK that wasn't agreed upon via consensus. Just to be clear. :) -omar On Sunday, January 27, 2013, Erik de Bruin wrote: But I don't want to force a decision right now; The beauty of the Apache Way is that you are free to do whatever you feel is best for the project. As am I. So, short of the PMC voting and veto-ing each and every commit made to the code we contribute, there is no way you or anyone else can force a decision, now or ever. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Take a chill pill. ;) Really? Nice! I prefer contributing over chillin, thank you. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Really. On Sun, Jan 27, 2013 at 10:11 AM, Erik de Bruin e...@ixsoftware.nl wrote: Take a chill pill. ;) Really? Nice! I prefer contributing over chillin, thank you. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
On Sun, Jan 27, 2013 at 5:52 PM, Erik de Bruin e...@ixsoftware.nl wrote: I think I can now pinpoint the difference to RequireJS: It is in the existence of deps.js. deps.js says it's generated, and seems to be the extracted dependencies of all the other JS files, right? Aha, so this is how the necessary scripts get loaded in advance. And this is where you need the build tool: To extract the dependencies and generate this additional file deps.js. No, the deps.js is just a list of ALL the require statements in the entire library + application (indeed generate during the publish process. However, ONLY the files listed that are ACTUALLY USED are loaded dynamically by the code in 'base.js'. If you look in either Chrome or FF you can see which script files are actually loaded and compare that list agains the 'deps.js' list. You'll see that the only file hard-coded into the HTML is 'base.js', which is the equivalent of 'require.js' in your approach. All the other script files are loaded dynamically, in order, based on the dependencies as given in their contents, much like with Require.js. With the AMD approach, you can re-generate exactly one file and reload in the browser, and everything will work. Same with the 'goog' way. One more thing, something I didn't find out is how deps.js gets loaded. It has to be triggered by base.js somehow. Can you please explain? It's a kind of magic :-) As I explain above, 'base.js' uses it, together with the 'provide' and 'require' statements to figure out which other project files to load. Let me press that point, since it seems to be pivotal to the discussion: ONLY the files that are ACTUALLY needed to run the application are loaded into the browser. NOT all the files in 'deps.js' and certainly not all the files in the Closure Library. To get one misunderstanding out of the way, I never claimed base.js would load more scripts than required. I just wonder all the time how base.js can know *in advance* which scripts to load. And deps.js seems to be the answer to that question. Believe me, I'm just trying to understand how it works and where it is substantially different from RequireJS. So deps.js is not only the list of all require statements starting at the main class, but as you say a list of ALL the require statements in the entire library + application. My example was that you change a single file, but change it in a way that you add a dependency. Without re-generating deps.js, base.js could not know in advance that the newly dependent module is needed, so just generating the class' own output file would result in a non-working state. And (re-)generating deps.js is exactly the pre-processing step AMD so elegantly avoids from the start. Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? I enabled View Source on the Flash output, so you can grab the AS source and put it through Jangaroo if you please. You can also pick up Alex's FlexJS source and do the same with that.Might be interesting to see what comes out and compare the various approaches when using a different compiler. Yes, I'll try to do that, but except from the deps.js file discussed above I expect the difference to be rather small. I think you're not going to convince me to throw away all the work I did so far (and I strongly believe is at least as valid for our purpose as what you are suggesting) and start the whole process again based on your approach, only to do away with one step in the build process of the intermediate output (the 'deps.js' you object to plays no role in generating the 'release' code). I'll continue development of my proof of concept and I hope to find other contributors willing to help out. Nobody asks you to throw away your work. We are discussing which library / tool better supports the JS target of Apache Flex. From a code-generation point of view, our approaches are fairly similar, and there are suggestions (see Roland's thread) that it should be easy to switch between such similar code output patterns. So we'll probably have both of them. However, I still think it is better to consolidate than to offer too much to chose from (where it brings no benefit). And I'd still like to hear your opinion on my warning that the input language for GCC is a dialect of JavaScript (restrictions, extensions), not standard JavaScript. -Frank-
Re: [ASJS] Integration with existing JS libraries and components
Hi, entire library + application. My example was that you change a single file, but change it in a way that you add a dependency. Without re-generating deps.js, base.js could not know in advance that the newly We're talking AS - JS cross compilation. So changing one file would be changing one AS file. To turn that AS file into a JS file needs a compilation step. The generation of 'deps.js' is part of the compilation step. So, in the scenario we're discussing, the regeneration is of no consequence. Also, more importantly, 'deps.js' is only needed for the 'intermediate' output, not in the release output. I think if we're going to be comparing anything, we should be comparing 'production/release' code, not 'convinience/intermediate' code, right? and compile it with Jangaroo 3 and also deploy the output. What do you think? I enabled View Source on the Flash output, so you can grab the AS source and put it through Jangaroo if you please. You can also pick up Alex's FlexJS source and do the same with that.Might be interesting to see what comes out and compare the various approaches when using a different compiler. Yes, I'll try to do that, but except from the deps.js file discussed above I expect the difference to be rather small. So, if 'deps.js' is not needed -- like it's not needed in the 'release' output of my proof of concept -- there really isn't any practical difference between our approaches? However, I still think it is better to consolidate than to offer too much to chose from (where it brings no benefit). And I'd still like to hear your I'd love to consolidate, and I'm reading your Wiki pages with interest on how to tackle some of the language inconsistencies between AS and JS. I just wish that we could work together on code, instead of going round and round on theory and relative merits of two different but equal approaches. opinion on my warning that the input language for GCC is a dialect of JavaScript (restrictions, extensions), not standard JavaScript. If by GCC you are referring to the compiler, [1] should answer your question. The Google Tools (which include, but are not limited to, the compiler) like to have their JavaScript in a 'pseudo-classical' pattern, but that doesn't mean they won't gladly handle other patterns, like AMD. The JSDoc annotations are only there to help the GCC do an even better job, but are not required for the code to function as coded. What about the input language for GCC do you regard as a dialect of vanilla JS? EdB 1: https://developers.google.com/closure/compiler/faq#restrictions -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
The title of this message says exactly what I mean. Right now we're talking about cross compiling the Flex SDK itself, along with all of its components. No, neither Alex nor I are taking that approach. The way that TypeScript and Randori/SharpKit integrate with JS is by declaring some sort of interface which has exactly the same signatures of their JS counterparts. I think this will quite probably make the most sense for Apache Flex as well. That's what I'm doing, and what I understand from Alex's approach the same goes for him. I'm building a JS library with the same signature as the Flex SDK, Alex has started a new AS framework and is building a complementary JS framework with the same API. And we could just use regular actionscript interfaces to do it. Probably with a small bit of annotation, so, for example, ... What we then would need is some sort of compiler support that recognizes the annotation and automatically includes the specified .js file. (instead of trying to cross compile the interface) That's exactly what I've done for the Vanilla SDK: it's a Google Closure Library supported JS framework that uses a specific cross compilation implementation in the FalconJx compiler, the 'goog' emitter. If we want to gain some traction in the HTML world I strongly believe we need to make friends out there :) And what better way of making friends than through integrating with them :) The VanillaSDK approach does this for the Closure Library and the way Mike set up make this 'easy'. I've even set up the initial code needed to implement Frank W's AMD/RequireJS approach. Please feel free to call me a fool and tell me my idea is crap, because I might just be talking out of my ass as usual. :) Not a fool at all, and I like your idea so much that I've already started work on one implementation :-) Hope we can work together to make this the future of Flex! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
While both Erik and I are using Goog, I think Roland is asking why we aren't use Jquery or ExtJS UI components. In my framework, I'm not right now because I had trouble getting my head around them and the ones I looked at seemed to come with application framework infrastructure, and I want to start with the basic built-ins. One difference in API between my new framework and the Flex SDK is that the Flex SDK tried to have one button that did everything, whereas I want the new framework to have many buttons, some that are bare bones and then fancier ones. The ones I'm working on new wrap HTML button. Then I would like to see ones that wrap the built in HTML5 button. And someone else is welcome to wrap some other JS framework's button if they want. On 1/25/13 12:13 PM, Erik de Bruin e...@ixsoftware.nl wrote: The title of this message says exactly what I mean. Right now we're talking about cross compiling the Flex SDK itself, along with all of its components. No, neither Alex nor I are taking that approach. The way that TypeScript and Randori/SharpKit integrate with JS is by declaring some sort of interface which has exactly the same signatures of their JS counterparts. I think this will quite probably make the most sense for Apache Flex as well. That's what I'm doing, and what I understand from Alex's approach the same goes for him. I'm building a JS library with the same signature as the Flex SDK, Alex has started a new AS framework and is building a complementary JS framework with the same API. And we could just use regular actionscript interfaces to do it. Probably with a small bit of annotation, so, for example, ... What we then would need is some sort of compiler support that recognizes the annotation and automatically includes the specified .js file. (instead of trying to cross compile the interface) That's exactly what I've done for the Vanilla SDK: it's a Google Closure Library supported JS framework that uses a specific cross compilation implementation in the FalconJx compiler, the 'goog' emitter. If we want to gain some traction in the HTML world I strongly believe we need to make friends out there :) And what better way of making friends than through integrating with them :) The VanillaSDK approach does this for the Closure Library and the way Mike set up make this 'easy'. I've even set up the initial code needed to implement Frank W's AMD/RequireJS approach. Please feel free to call me a fool and tell me my idea is crap, because I might just be talking out of my ass as usual. :) Not a fool at all, and I like your idea so much that I've already started work on one implementation :-) Hope we can work together to make this the future of Flex! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [ASJS] Integration with existing JS libraries and components
We most certainly will, once we get our misunderstandings out of the way :) I think we both aim for the same things, we just need to find the same wavelengths :) Your followup mails -- and me re-reading the original one, I know I was lazy reading it the first time :-) -- cleared things up a bit, and I must say I like what I think I now understand. I'd love to help out to get a demo of this idea going. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
On 25 January 2013 22:03, Erik de Bruin e...@ixsoftware.nl wrote: We most certainly will, once we get our misunderstandings out of the way :) I think we both aim for the same things, we just need to find the same wavelengths :) Your followup mails -- and me re-reading the original one, I know I was lazy reading it the first time :-) -- cleared things up a bit, and I must say I like what I think I now understand. I'd love to help out to get a demo of this idea going. Alright, glad we're on the same page :) Only, it does involve some other things I've been thinking a bout concerning the compiler architecture. I'm going to dump those into a new message to the list, since it doesn't belong in this particular thread :) Plus I need to get my own thought in order first, since it'll probably be a long email :) cheers, Roland
Re: [ASJS] Integration with existing JS libraries and components
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!
pluginhttps://github.com/brettz9/shim/#readmethat 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
(ExtAsApiGeneratorhttps://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
jsduckhttps://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-
Re: [ASJS] Integration with existing JS libraries and components
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!
pluginhttps://github.com/brettz9/shim/#readmethat 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
jsduckhttps://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-
Re: [ASJS] Integration with existing JS libraries and components
Hey Frank,
thanks a lot for your elaborate answer (as usual). Basically everything I
had in mind
you pretty much described. So I'm pretty stoked that this could be
implemented rather
quickly.
Between your and Erik's approach I already prefered yours to be honest
(Erik, this is
no stab under water in your direction, its just my opinion, hehe).
My main problem with using Closure is that it introduces a second parsing
and manipulation
pass while, IMHO, all of the necessary work can be done inside Falcon since
all necessary
information is contained within the AST. Therefore implementing the whole
shebang inside
Falcon will be faster. Plus it removes a dependency, which is always good,
again IMHO.
The fact that your requireJS approach is also asynchronous is a big boon as
well. It means
an application could be loaded incrementally much easier, and from what I
understand
incredibly granular.
Its awesome to read that you already have a system in place to generate an
AS3 shim for the
extJS components, that'll definitely save some typing :)
Anyways, I have some thoughts about the actual implementation of all of
this, but I'm gonna
write those down tomorrow. For now I think I want to head to bed :)
cheers everyone,
Roland
On 25 January 2013 23:25, Frank Wienberg fr...@jangaroo.net wrote:
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!
pluginhttps://github.com/brettz9/shim/#readmethat 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
jsduckhttps://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
Re: [ASJS] Integration with existing JS libraries and components
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!
pluginhttps://github.com/brettz9/shim/#readmethat 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
jsduckhttps://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
Re: [ASJS] Integration with existing JS libraries and components
@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!
pluginhttps://github.com/brettz9/shim/#readmethat 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
jsduckhttps://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
Re: [ASJS] Integration with existing JS libraries and components
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, I really wish you would stop saying this. It is simply not true. Please look at the 'js-intermediate' output to see how 'base.js' dynamically loads only those files from the 'goog' library it actually uses, in the order needed to allow proper instantiation. How is that different from RequireJS? Also, how is 'many, many more features' a bad thing? Please take a look at the proof of concept (both the intermediate and release code) before making these kinds of statements. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
