Hi Frank, I won't be able to look at this for at least a couple of days.
BTW, how's it going with the ICLA/CCLA? Or did I miss seeing the notification for it? -Alex On 1/19/13 1:08 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote: > Hi folks, > > I have been rather quiet for a while, but that's because I have been busy > implementing JavaScript code generation according to the Runtime prototype > I posted some weeks ago. However, I started off implementing this in the > Jangaroo compiler, not in Falcon. I am far quicker implementing this in the > context I know, it would have taken me much longer getting started with > Falcon first. So of course now I hope that you guys help me porting this > solution to FalconJx... > > I'm about 80% finished implementing all the AS3 language features I started > documenting in the Flex Wiki and already have a demo of a large > application, namely the Open Flash Charts demo, recompiled with the new AMD > approach. > > Background on the demo: > Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure > ActionScript 3 > project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/ > Version%202%20Lug%20Wyrm%20Charmer/>, > and I only had to make very few changes to the original AS3 code to make > the JavaScript version generated by the Jangaroo compiler work in the > browser, without a Flash plugin. This has been working with Jangaroo 1 and > 2, and now I got it to run with the new runtime format proposed for > FalconJx. > > The demo comes in two flavors: > The "production" version <http://jangaron.net/ofc5/data-files/joo.html>, > where the whole application is a minified single JS file of about 380 kb > (unzipped, the original SWF has 320 kb, and that is zipped and of course > does not contain the Flash classes, because they come with the > FlashPlayer!): > *http://jangaron.net/ofc5/data-files/joo.html* > Or load the "debug" > version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>, > where the JS equivalent of every AS class is loaded as a single request, > simply by adding hash joo.debug to the URL: > *http://jangaron.net/ofc5/data-files/joo.html#joo.debug* > > This demonstrates the real benefit of the AMD approach: RequireJS is > capable of loading all needed scripts one by one (debug mode) as well as > optimize them into a single JS file for production. It can use Uglify, > Uglify2 or Google Closure for minification. > Loading every AS class as a single request is still astonishingly fast, > especially when using local deployment, which is what you usually do for > debugging. Note that the demo uses over 200 classes. > > Have a look at the generated JavaScript, and you'll see that Jangaroo keeps > the original ActionScript code either as comment (if there is no JavaScript > counterpart, like for "package", "class", type annotations), or as > executable code in the exact line where the original AS code was. That > means if you want to debug say line 20 of AS class "Foo", you open script > "Foo.js" in the JavaScript debugger and find the code and set the > breakpoint in that same line: 20. This is a special Jangaroo feature which > we do not necessarily need to implement for FalconJx. However, I still > think it is a good feature, and since it does not slow down the optimized > version, why not implement it for FalconJx, too? > > What I think we do need in any case is the ability to load AS classes by > single requests, as otherwise they are really hard to find when debugging > in the browser. And this is what you get for free when using RequireJS. In > Alex' prototype, the only way to achieve this behavior was to list all > needed single class scripts in the HTML (see FlexJS Wiki page). Of course, > such HTML could be generated, but I think RequireJS' approach is more > elegant. > > Another thing you can see in the Open Flash Chart demo is how I implemented > static code execution. ActionScript executes all static code of the whole > "compilation unit" the first time its "primary declaration" (usually a > class) is accessed. > Consequently, not (only) an ActionScript class, but an ActionScript > "compilation unit" is put into a JavaScript AMD module definition. Thus, > the module's value is not the class itself, but a compilation unit > containing the class. I use the property "_" for the class or any other > primary declaration, which in AS3 can also be a function, variable or > constant. The static code of the compilation unit is *not* executed when it > is *loaded*, but when the "_" property is *accessed* for the first time. > (Because code has to be loaded asynchronously in the browser, we cannot > load the module when it is accessed synchronously, but have to load all > static dependencies in advance.) This is equivalent to the original AS3 > behavior, and only introduces the minimal overhead of accessing Foo._ > instead of just Foo. > > If you want to play with the new Jangaroo compiler to see what JavaScript > output is generated for your ActionScript input, the simplest way is as > follows. > > You need to have Java, Git and Maven installed and properly set up. > > Clone the jangaroo-tools repository and switch to branch jangaroo-3: > >> git clone git://github.com/CoreMedia/jangaroo-tools.git > >> git checkout jangaroo-3 > > Then run the integration tests via Maven: > >> cd jangaroo-tools > >> mvn install -pl :jangaroo-compiler-itests -am > > This should result in a BUILD SUCCESS. > > The jangaroo-compiler-itests module is under > jangaroo/jangaroo-compiler-itests: > >> cd jangaroo/jangaroo-compiler-itests > > For the intergration tests, all *.as files under src/test/joo/ are compiled > to target/temp/joo/classes/, respecting their package sub-directory. So if > you add an *.as file under the src/test/joo/ directory, the corresponding > *.js file will appear under the target/temp/joo/classes/ directory after > the following Maven command: > >> mvn test-compile > > Note that you cannot use Flash API here (will result in compile error, as > classes are not found), only basic classes like String, Array, and built-in > functions like trace(). > > Another good news is that my employer signed the CCLA, and it has been > confirmed by Craig, so now I am all set to contribute Jangaroo code to > Apache Flex! > > The code that generates the new JavaScript runtime format is in jangaroo-tools > on the "jangaroo-3" > branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3> > (see > above), especially class > JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/ja > ngaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerat > or.java>(Michael > Sch. knows this already!) is interesting for porting code to > FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format. > > I am also working on another demo, which is written in AS3 and MXML (!), > but instead of Flex components, uses "native" Ext JS JavaScript components > through an AS API. It does not use the Jangaroo Flash library > re-implementation (JooFlash), so this sounds similar to Alex' approach to > not use the display list to render MXML components. More update on this to > follow. > > Would really be great if we could consolidate our solutions! > > Can't wait for your feedback, > > -Frank- -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
