The week in qooxdoo (2009-11-27)

After this week’s release of 1.0-beta1 we thought we’d get around a substantial blog post. But since Daniel had to tell about a feature addition to the qooxdoo Simulator, this might be a good idea to raise awareness about testing.


The area of testing web applications, in the sense of ensuring quality over a longer period of time, can involve quite a number of measures. Here, I’d like to remind you of taking advantage of the following three, that are fully supported by qooxdoo:

  • Code Validation: it is so trivial to use, in fact only a lint call inside your qooxdoo project, and you’ll get a checklist of all the typos, mistakes, ugly or potentially dangerous code, etc. Don’t worry about the amount of warnings when you use qooxdoo’s ecmalint tool for the first time. Just work yourself through the checklist from top to bottom and fix all the issues. Typically there are much less issues to fix than the length of the initial list suggests. BTW, for the qooxdoo framework and the built-in apps we’re basically down to zero “real” issues.

  • Unit Testing: there’s no way you can reasonable well develop software – particularly in an “agile” way or in an scripting language like JavaScript – without proper (unit) testing. qooxdoo comes with a complete unit testing framework: just put your own unit test classes into the test folder inside your top-level app namespace, and run test from the command shell. This will create the TestRunner for your application, and you can select and run any of your unit tests. If you’re into it, you can also do test-driven development (TDD), as qooxdoo supports this for the “source” version of your app with the test-source target of the generator. qooxdoo itself has more than 1.300 unit tests (and counting), which are automatically run each night on 30 “browser x OS” combinations.

  • Automated GUI Testing: Ever wondered how you could have an “invisible user” that interacts with your app in all the browser x OS combinations you’re interested in? Well, then the qooxdoo Simulator is the tool of choice. It’s based on the Selenium RC infrastructure and comes with a so-called “qooxdoo user-extension” that has many built-in commands that let you easily write test cases for your app. Of course, this kind of testing might be a bit harder to setup, but then it really pays off. qooxdoo runs quite comprehensive simulations for 6 of the built-in apps in a total of over 160 simulations, plus the startup of each of the more than 200 samples of the demobrowser. This is done each night, and yes, it takes time.

If you care about software quality and testing, you should definitely go for the first two if not all three of the tools mentioned above. But now to yet another improvement of the Simulator:

Simulator: Simplified typing

When creating an automated test case for a qooxdoo application using Selenium, simulating a user entering text into a form widget could be a bit tricky. For Selenium’s type and typeKeys commands it’s necessary to use a locator that finds the HTML input or textarea element of the widget. For widgets like qx.ui.form.ComboBox, this meant digging into the DOM structure to find the qx.ui.form.TextField child control’s input element. With the qxType and qxTypeKeys commands newly added to the Simulator contribution, a test developer only needs to specify a locator that returns any DOM element that is a part of the widget to be typed in. The qooxdoo Selenium user extension will then search for the corresponding HTML input or textarea element. This is especially convenient when assigning IDs to widgets, e.g:

In the application code:

var comboBox = new qx.ui.form.ComboBox();
comboBox.getContentElement().getDomElement().id = "comboBox42";

In the test case:

qxSelenium.qxTypeKeys("comboBox42", "Some text");

That’s it for now. Since there’s Thanksgiving weekend in the US today, many of you will probably read this next week. The qooxdoo core team at 1&1 is going to enjoy tonight another legendary and fabulous Xmas party with many colleagues. C U.

qooxdoo 1.0-beta1 released

Today qooxdoo 1.0-beta1 was released as planned. Please download this beta release as a regular SDK and give it a spin.

As with any beta release there are some known issues that we like to address in the next few days, and postpone the ones that are either regarded insignificant or too intricate for the 1.0 time frame. It would be great if you could report all issues you find while working with this preview release.

Documentation for qooxdoo 1.0 is also in the works in a separate wiki space, and should become more consistent and accurate day-by-day. As brought forward in a previous blog post, we’d really appreciate if some of you could help with correcting and polishing the docs (may it just be typos or language issues).

For detailed info about the specific changes in qooxdoo 1.0-beta1 checkout the release notes.

With your help and support we’ll continue to work on the 1.0 release, planned to ship right before Xmas.

Download for a test drive!

The road to qooxdoo 1.0

Please note: This is a re-post of a section in a weekly status update from early November. Some feedback indicated that it’s worth an individual blog post. Since most of it still applies, also given the upcoming qooxdoo 1.0-beta1 release, please read this copy in case you missed it before.

“[...] Talking of maturity this is to remind you of qooxdoo’s ramp down towards the 1.0 release, which is still planned for the end of the year. During the last weeks, actually for several months now, a huge number of bugs have been resolved, enhancements implemented, larger topics and inconsistencies in the framework addressed. The testing infrastructure, that was established and improved in the course of the year, became a valuable tool as it helps ensuring a sufficiently high level of software quality. Among all the regular development activities, which we’re able to pursue ourselves as full-time framework developers, the input and support of the community, contributors and committers naturally is of great importance. This is especially true for the challenges when approaching a 1.0 release.

We’d like to ask for your dedicated help and support during the next few weeks. For instance, if you encounter issues and inconsistencies that to your knowledge (please scan bugzilla first) aren’t recorded or addressed already, please let us know. Pay special attention to all API related issues, as it gets naturally much harder to address those after a 1.0 release, which is supposed to gain much from API stability. Clearly, not all open issues can be resolved for qooxdoo 1.0, or any release after, but we’re focused on addressing the most important and relevant defects as well as the most significant enhancements in a reasonable manner. Again, when reporting real defects, or requesting enhancements, please choose qooxdoo’s regular bugtracking over the mailing list. This usually guarantees for the most effective and least redundant workflow without cluttering up the list.

All assignees of a bug are asked to review the issues soon, possibly working closely with the reporters in resolving them. If you happen to be the reporter of a defect or an enhancement, or otherwise interested in the issue being resolved, please feel free to approach the current assignee and offer your help. We regularly perform bug triage to never have a real defect unassigned. That doesn’t mean that the assignee is going to work on such an issue promptly. If he/she does or plans to, the status is supposed to be switched from “new” or “reopened” to “assigned”. See the bug handling documentation for more info. If you’re in doubt, talk to each other.

In the next few days we’ll also prepare for the 1.0 copy of the qooxdoo manual (Update: available now). Like the rest of the homepage it is just a wiki, so after a simple registration you can collaborate in improving the existing documentation. Everybody is encouraged to review the current articles, i.e. finding, reporting and preferably enhancing/fixing the docs. Language corrections by native English speakers are appreciated. Much of this also applies to the API reference, which is generated from the JSDocs of the qooxdoo code base. If you identify issues that should be addressed, at least report them, at best fix them yourself. It would make sense to carefully go through a current SVN checkout and review individual namespace packages. After you make the changes to your local copy, a patch file can easily be generated and attached to a corresponding bug report. We’d take care of applying your API corrections asap. Does anybody feel like participating and help coordinating efforts around the wiki and/or API docs?

When preparing the wiki for 1.0 in the next few days, we’d also like to correct a milestone misnaming: being in the ramp down for qooxdoo 1.0 for a while now we decided to rename the formerly planned (but then postponed) 0.9 release to a 1.0-beta pre-release (Updated: renaming to 1.0-beta1 finished). While there are certainly pros and cons of having another “formal” major release, this renaming matches best the status and progress of previous and current framework development. As with any release, beta or major, we’d appreciate you tried this code base at the time of availability, planned for end of November, in order to spot any open issues. This even more applies to SVN trunk, thus anyone of you that is able to run his/her qooxdoo apps against a recent trunk version, is encouraged to do so. Of course, we can’t expect you to do this for your production code, i.e. in its deployed version, but often it might not be much effort for you to have a parallel version built and tested against qooxdoo trunk as well. Besides helping framework development, you’d also help yourself and your investment as being close to the qooxdoo trunk helps you to notice and react to any changes and regressions you’d not be comfortable with in a 1.0 or after.

It would be great if you kept an eye on the mailing list to help other community members with their problems and answer their questions. On a daily basis the members of the core team use to take care of supporting the mailing list. With more users helping out others (and some of you are really excellent in doing so!), the time saved could rather be invested in framework development and the upcoming releases.

Think about all ways you could (even more actively) support qooxdoo. Thanks!”

The week in qooxdoo (2009-11-20)

Welcome to another round of tidbits from the qooxdoo world. WebTech09 has passed with some interesting presentations and meeting people (see more in this weekly), and now we’re off to higher goals…

1.0 Beta

1.0 – we’re getting there. As announced earlier we plan to ship a 1.0 beta of qooxdoo this coming week. It’s a preview release, and everybody is invited to check it out and provide feedback. If you want to hold your breath, hold it around Wednesday :-) .


Script Core

A small change can sometimes reveal bugs which are otherwise hard to find. Fabian changed the event which triggers the placement of a widget from resize to appear and suddenly disappear events from widgets were not fired any more. With this trail in mind we found out that unregistering an appear event will also unregister a disappear event and vice versa since only the target hash code was used to store the data. The fix was quick and easy: store the data using both the target hash code and the event type.

Data Binding

We added some work into the data binding this week. First, we added a data store for JSONP. On top of that, we added a YQL data store. The whole story can found in a separate blog post.


Performance is always an issue and with the 1.0 release on the horizon even more. We have identified a few bottle necks, which we could remove:

  • setStyle vs. setStyles: All CSS styles in qooxdoo are applied by calling This resulted in a lot of function calls and some duplicate operations. To solve this we have enhanced the setStyles() function which is able to set several styles at once. We basically have manually inlined the code of setStyle() and moved as much as possible out of the loop.
  • Assertions: Even if assertions are mostly used in debug code, it’s still important that the checks are as fast as possible. The assertion class has been reworked internally which gained some significant performance improvements.
  • Dispose: While measuring performance we were surprised how expensive disposing of objects is. One small optimization was the deprecation of the _disposeFields method, which basically sets the given fields to null. Instead we set the fields directly to null which is equally concise but way faster.

History Manager

New browsers including IE8 Firefox 3.6 and newer WebKit based browsers support the hashchange event, which is fired whenever the fragment identifier (hash) of the URL changes. If available we now make use of this new feature to detect hash changes instead of the more expensive polling technique. In addition some issues in IE have been fixed as well.


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


We introduced a new feature for the API Viewer this week: The throw information will be displayed for every method which can throw errors. is a good example for this new feature.

Generator Configuration

The generator has a new command line option -m (or –macro for the long form) that  allows you to pass macros and their definition to the generator. Example: -m foo:bar myjob

where foo is the macro name and bar the assigned value. You can specify multiple -m options. The effect is as if you wrote these definitions in the global let section of the configuration file  you use. Since these macros are evaluated very early, you can use them e.g. in top-level include keys if you want to parameterize an include file. In this vein, macros are now also supported in jobs’ extend and run keys; this was formerly not supported, as these keys are among the earliest keys that are evaluated in a job (prior to full macro expansion), as they guide job construction.

That’s it for this week, see you around next time.