qooxdoo 0.7 (2007-06-05)

Up to now it was planned to have the rework of dynamic properties more or less separated from the implementation of the advanced OO features. They were expected to be released in a later release 0.7.1 Given that a release 0.7 will be a rather big step for migrating existing applications and eventually learning new OO syntax and features, and given that the property implementation has shown to be an integral part of the new scheme, it has been decided to include them in this major revision as well. This will of course delay the official release of 0.7, but it will not extend the time span for including the features expected for a later release 0.7.1.

This release is supposed to introduce a new style for class declaration. The current declaration style has been shown to be inconsistent and limited in features, and it is also hard to process and migrate automatically by the generator. This will allow for a much cleaner way of leveraging JavaScript's built-in OO capabilities. Both Java-like interfaces as well as Ruby-esque Mixins will be supported. The improvements in OO capabilities are a prerequisite for the challenging task of rewriting the layout engine (planned for 0.8).

More information about the proposed new class definition scheme is available to allow for discussion and input across the community:

Of course, for such a major change (almost automatic) migration support will be available for your custom code. However, the automatic reorganization of the code will lead to a reformat of your code. The system will by default unify existing code to match the style used inside the qooxdoo framework. While it is a very consistent and quite favorable coding style (also by objective means), it may not fit your personal coding style. Since coding style is a matter of personal taste and programming history, we won't try (hard, promised) to argue you into switching to qooxdoo's JavaScript style guides. Therefore, some parameters determining major aspects of code style have been identified and included in the pretty-printer. They will allow for some custom tuning of the code output. It is hoped, that most users should be fine with the feature set of tuning the pretty-printer.

Also, not regarding code style unification during migration, if different programmers (with different coding styles) are involved in your projects, you may find it quite useful to use the code unifier (some call it a "code beautifier") for assuring a truly consistent coding style.

If you prefer to simply keep your existing coding style exactly as it is, just don't use the automatic migration support. You will then have to do all the adjustments to your custom classes by hand, though. This manual migration is not recommended. We are sorry for any inconveniences. As you will notice or may have already noticed, we try hard to make such migrations as less cumbersome for you as it is technically possible.

Even if you use migration support, it actually won't be completely automatic. There is a good chance that some of your individual code simply cannot be migrated automatically. For example, top-level cross-browser switches have to be moved into the new class definition by hand. Migrating to 0.7 could mean some hours or even days of work - depending on the size of your project. YMMV.

During development towards the 0.7 release, an 0.6.x line has been made available (branches/legacy_0_6_x) to account for bugfixes and extensions for the latest stable code base. This branch will be the base for the planned release 0.6.6 described above.

The following has been moved from a separate release 0.7.1 into the implementation phase of 0.7:

A new implementation of dynamic properties (a successor of the existing properties defined by qx.OO.addProperty()) will be integrated. These properties allow for a more performant and less memory intensive lazy-generation of setters and getters. Those dynamic properties are also at the heart of the upcoming new theming capabilities supporting individual user-defined styles.

The following features planned for qooxdoo 0.8 have been moved into the implementation phase of 0.7: