Here's another roundup of qooxdoo happenings. This time we'll start with one of the most important parts of the framework, i.e. the tool chain, more precisely the Generator:

Dependency Analysis

An essential part of the work of the generator is finding dependency relationships between classes. You throw a few classes at it to start with (like the main application class of your app), and it will work out which other classes are necessary to make the whole application work. If it finds unknown classes in your code it would spill out "! Unknown classes referenced" warnings. But these warnings were not entirely reliable, partly due to stale cache information. If a required class was missing, you could add it to your application and the generator would still produce the same warning. On the other hand, if you removed a class that had been detected before, the generator might silently ignore that it is now missing. This has been fixed, along with other omissions, where the generator e.g. would silently skip existing dependencies in the code, so both the depth of the analysis as well as the reliability of the cache has been increased. The classical #ignore compiler hint is supported again, so you can switch off the "unknown class" warning for global references you know are ok. As a payoff, the new implementation is more demanding in terms of run time. But once the cache has been populated by relevant dependency information, you won't notice any difference.

Chrome Frame

You've surely heard the following news: Google published a plug-in called "Chrome Frame" for Microsoft's Internet Explorer 6, 7 and 8. This plug-in makes it possible to use the JavaScript and rendering engine of Google Chrome instead of the Internet Explorer originals. The plug-in can be downloaded and it comes with documentation.

There has been quite some debate and lament, on the net as well as among the qooxdoo community, about the usefulness of Google's approach. While at first it might appear to be a brilliant idea to get rid of IE's deficiencies and inferior performance, it does have some drawbacks. For instance, in a corporate environment, would the system administrators now install such a 3rd party plug-in into IE, given that they didn't upgrade or switch browsers before (for whatever reason)? In other scenarios, though, this might be a chance to keep IE running for some corporate legacy apps, while offering new web 2.0 intranet solutions in the same browser users are already familiar with. Well, who knows how successful Chrome Frame will be in the long run ...

Anyway, when we heard about the plug-in, we had, of course , to test Chrome Frame to find out if qooxdoo runs in it without any problems. Therefore we installed the plug-in on one of our test computers and ran the nightly test environment. Good news is: qooxdoo seems to run without any problems. The plug-in behaves like its big brother (i.e. Chrome 4), but appears to be a tiny bit slower.

Due to the positive test results we are currently thinking about adding the following meta tag to the qooxdoo skeleton applications:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

So each custom application, typically built upon those skeletons, would always be rendered with Chrome Frame if the plug-in is installed. Is that something you would expect, so that it's a welcome feature addition? What is your experience with qooxdoo in Chrome Frame? Oops, I just stumbled across a discussion on the Frame mailing list, where qooxdoo user John Spackman reported some potential issues with AJAX calls? Anyway, we'd be glad you all shared your experience and opinion about the meta tag with us.

Bugfixes

For a complete list of bugs fixed during the last working week, use this bugzilla query.

Community

Contributions galore... three more additions this week in qooxdoo-contrib , read on ...

cometd

This is a wrapper of the client-side part of the well-known Cometd protocol in qooxdoo, contributed by Christian Boulanger. He says:

"[...] ever since Alex Russell coined the term "comet" for a server push technology
for http, I have been fascinated by the idea. Being dissatisfied with the
responsiveness of my app, I have long wanted to use it in qooxdoo - but
without having the full overhead of including yet another javascript
framework like dojo. I have finally gotten around to porting the client
javascript code to qooxdoo."

You can find the top-level hook to this contribution on its entry in the contributions overview. There is still some code porting to be done, and Christian appreciates support regarding the transport layer. Check the mailing list if you feel like jumping in.

jqxPlot

Fritz Zaucker has provided jqxPlot, a demo application to showcase the integration of the jqPlot plotting library into a qooxdoo application. This is not only interesting for those wanting to bring charting to their qooxdoo apps, but are interested in integrating foreign libraries in general. Have a look at his nice online demo.

jqxPlot Demo

CollapsablePanel

Also from Christian Boulanger, there comes CollapsablePanel, an accordion-style widget which allows you to open multiple items at the same time; this has already received lively feedback on the mailing list. Not only that. Matthew Gregory, another qooxdoo power user and contributor (e.g. of the TileView widget), helped in advancing Christian's solution based on some previous implementations of his own. There are quite some activities around the CollapsablePanel right now. For the time being, you can check Christian's original demo and also the current state of the improved demo.

Collapsable Panel Screenshot

With all the new stuff to try out, don’t forget to check back for next week's regular status update.