Time for another weekly status update. Thanks to all the team members for their regular input and help in preparing the post (this time Thomas, thanks). Let's start with the tooling:

Generator

• URI handling has been further revamped. URIs to reference resources in generated JS code can now be influenced either through the "library/uri" or the "compile-source/root" config keys. See the special section of the manual.
• Configuration documentation has been amended. There were several config keys missing from the manual (desc, migrate-files, lint-check, clean-files (partly), fix-files, exclude, debug, log (partly)).

Bug Fixing

A lot of bug fixing has been going on, both in the 0.7.x as well the 0.8/trunk branches. Major areas of concern were

• key event handling (#1520, #803, #1645)
• TableModel (#1560, #1578)
• memory leaking in 0.7 (#1633)
• Window got a new getMode() method, to inspect minimized/maximized/normal states (#1531)
• browser detection has been improved (#1638)

The use of Python under Windows Vista requires some special attention (i.e. installing as an Administrator), and there is a dedicated troubleshouting entry.

The HtmlArea contrib received some love, too. The issues were around key handling, scrollbars and IE support.

Data Binding and Validation

As a feature related to the upcoming data binding, Martin put some initial code into trunk. It's about validation and is integrated into the property system. Now every property can include in its definition a validate key and specify a validator for it. Therefore, a new ValidationError class was added to the framework as well. Also, a set of common validators have been added to qx.util.
Please note that this feature is still experimental. There might be some changes in the API during the ongoing development process. But you can give it a try anyway. You will find some tests in qx.test.core.Validation and a demo has been added to the trunk version of the demobrowser.

Gadgets

Open Ajax Alliance

Daniel spent some time looking into the OpenAjax Alliance (OAA) Widget Metadata Specification and tried to figure out how to make qooxdoo apps play nicely with the OAA Message Hub. The result is a contribution consisting of two small qooxdoo apps that can be run as gadgets in OAA's Sample Mashup Application, demonstrating how to publish and subscribe to hub messages.

Google and Netvibes

The two other popular gadget specifications from Google and Netvibes have also been addressed. A while ago Torsten Wesolek posted a nice proof-of-concept to the mailing list for a qooxdoo 0.7 based Google Gadget. Just include his event calendar (sorry, in German only) to your iGoogle start page. It's using a qooxdoo Table to display the search results.

See Daniel's wiki documentation for creating qooxdoo-based Gadgets for Google and for Netvibes. If you managed to set up some nice gadgets yourself, please let us all know.

"A Rose with any other Name..."

Don't be surprised if you come across a name of Jonathan Weiß while Jonathan Rass seems to have vanished all of a sudden - it's the same guy! Core developer Johnny recently got married and took on his wife's name. - Congrats, Johnny!

Upcoming releases

The roadmap has been updated to account for the upcoming releases: We expect a release qooxdoo 0.7.4 of the legacy 0.7.x line to be available next week on 2008-12-04. On of its highlights is a substantially improved memory management, which allows for creating memory-leak-free applications. If you have an existing 0.7.x based application, please try out the current version in the legacy_0_7_x branch and report any issues asap. Thanks.

The other release qooxdoo 0.8.1 is planned for 2008-12-18, so that you get something to play with during holiday season. Wait, actually, you should start playing with the trunk version during the next two weeks already. It would be great you could help to find and possibly fix any open issues. qooxdoo 0.8.1 is expected to be quite a solid maintenance and bugfix release. Thanks for your collaboration in making this happen.

Thats' for this week - be in touch next time!

It's a recurring theme: People keep asking about a qooxdoo "library", a pre-built .js file containing the entire qooxdoo class library, which they can grab, include in their web pages and program against, using the well-known qooxdoo API. Just recently, there was a lively thread on the mailing list about that (starting off from and thus not being very aptly titled "Passing named parameter without the URL"). This post tries to summarize and contrast the various arguments on the issue.

First, a bit of history

During the 0.7.x line of qooxdoo there was a deliverable among qooxdoo's release files that was exactly that: a pre-built .js file containing all classes of the qooxdoo class library, surrounded by a minimal set of accompanying files and information. Its name was quickstart. People could dash ahead extending the included Application.js and not worry (or thinking not to need to worry) about tooling or build process altogether. Even qooxdoo's 0.8-beta1 release featured a quickstart package, but after that the package was dropped from the set of release files.

Reasons for dropping the package were:

• People were complaining about the number of packages in each release, and were confused over the question which one to choose. So we cut down the number of packages to the one we couldn't miss: the SDK. The quickstart package was just one of the left-behinds.
• There were also concerns on our side about how the package would be used. Meant as a quick start (he, get the pun ) to try out qooxdoo, it was never meant to be more than that. We were afraid people would start building heavy-weight applications based on it, and then start to struggle with the limitations of the pre-built library. Many of our standard tools and procedures would not apply, and help would be harder to give.
• For the decision it also helped to know that with 0.8 we had a build system that would allow the creation of any kind of custom-built, library-style application anybody could think of.

But then, it would be nice...

On the other hand, there were people coming back and asking for such a package. Besides the read-to-go quality of such a package, more serious arguments were raised pointing at issues when lacking such a package. The various arguments speaking in favor of a quickstart package were:

• Lower entry level
  It is easier to grab a one-file library and start trying out qooxdoo, than installing an SDK and its prerequisites first. Many say not being able to do this is a killer argument against qooxdoo when evaluating Javascript frameworks. They feel that Python as a prerequisite for the SDK is too much of a barrier - especially compared to other JS frameworks -, which would deter people from looking any further into qooxdoo.
• Good enough
  A pre-built library was deemed good enough for people that are willing to accept the size penalty for their project, because they do an Intranet or otherwise controlled-environment application where they have known bandwidth and run time parameters, so paying the extra cost would not be an issue.
• Prerequisite for dynamic code generation
  People that generate qooxdoo code on the fly, e.g. on the server as a response to a client request, or that otherwise cannot follow the build-and-run development cycle, need a pre-built qooxdoo library that encompasses all potential classes that might be referenced by the dynamic code upfront.

It's not that easy

But providing a read-to-go library for qooxdoo is not as care-free as it may seem. Some of the issues involved are:

• Size penalty
  With a static library you necessarily make compromises. You include classes that might not be needed for the current application. You loose some of the optimization potential, e.g. by including variant code that could be left out in the final product. While all of this might be acceptable in a development environment, it rapidly becomes a concern for the deployment of the application.
• Inflexibility
  The pre-built library is inflexible not only when code optimizations are concerned, but also e.g. regarding themes. Since themes are not runtime-switchable with 0.8, you "burn" a theme into the library when you create it. There is no way to switch later for those using the library.
• Selection
  It is not easy to cut out an ideal set of classes to include into a pre-built library. Of course, you could always include all framework classes. But the qooxdoo class library has grown to well beyond 400 classes. Should we really include e.g. the qx.legacy.* name space? For someone porting an 0.7 application to 0.8, it is absolutely vital and helpful. For somebody starting from scratch with 0.8 development, this would all be unnecessary overhead. - And there are other candidate name spaces to worry about.
• Resources
  qooxdoo is not only a large set of JavaScript files. The framework contains a huge set of resource files, mostly graphics, currently well above 4000 files only of that type. And this is not just a pool of nice icons and appealing graphics, for the application developer to choose from. With 0.8. graphics are essential for some of qooxdoo's core classes, e.g. when using decorators which are composed of small graphics. In order to have working widgets, those graphics have to be in place when running the final application. They have to be in predictable places so they can be correctly referenced from the Javascript code through URIs. This is defeated by copying the JavaScript files to arbitrary places without taking care of the graphics files.
• Lock-in
  People that start out using the quickstart might do a quick evaluation with it. But we all know how things work out in a project sometimes. Time pressure is high, and so you extend the toy example you did for evaluation into a real prototype. The boss likes it and pushes you, and all of a sudden you are faced with a production release that is build entirely on the pre-built library. The effort to maintain this scenario has grown over the project, still you shy away from a radical shift to working with the SDK, and now you feel there is no alternative than to go ahead with it. You are trapped with the static library.
• Getting help and the programming model
  qooxdoo comes with a programming model. Roughly put, it targets RIA developers that are heavily OO-slanted, wanting to produce rich-client, single-page, performant, desktop-like GUI applications in an industrial style. Many efforts within the project have this scenario in mind, and try to foster it particularly. In order to achieve that, compromises are being made that lead among other things to the up-front effort of setting up a build environment. I mean, it's hard to cater for everything. And we are particularly glad that we could reduce the set of a-priory requirements from a Unix-like environment (until the 0.7.x releases) to Python-only (with 0.8). That doesn't mean you cannot use it otherwise, it's just not the proposed way and not supported. Particularly, proven tools and procedures we have developed over the years will not be applicable to the pre-built library approach, and it is thus hard to provide efficient help. It simply seems hard to properly support another programming model, and not to confuse users about the "minimalistic" and the "regular" application development.

So you see, there are technical and non-technical aspects to it. Particularly, we have only so many resources on the project, and need to focus efforts in order to achieve good results.

One solution: qooxdoo's build system

Now you may say "Wait, that was the initial problem, wasn't it?!". Well, this is in fact addressing those developers specifically that want to or even need to use a pre-built qooxdoo library file, e.g. due to server-generated run-time components served by their individual application architecture. The beauty of 0.8 tooling is that it gives you full control over the framework library, yet you can get around the build process on a regular basis. So the recommendation is: roll your own! There will be a wiki page specifically dedicated to that topic. It would be great if people that require and already use such a pre-built library could then add more information about that scenario.

This week had us participate in the Eclipse Summit Europe, which was quite a successful and exciting tech event. Besides that highlight, work on the framework continued as summarized below:

IE Pampering

Chris continued to look into some IE issues and managed to fix them in collaboration with Alex:

Inline applications

When using qooxdoo for an inline application, page reloads, e.g. triggered by clicking an hyperlink, would fail occasionally. This was due to script loading and initialization, which could be fixed for all IE versions.

Rendering issues

Two annoying problems with rendering could also be solved, which showed up in quirks or standard mode of IE6 and quirks mode of IE7:

First, some combined images shipped with the framework were inconsistent. They were packaged up as PNG images, but actually contained GIF images as well. IE didn't like that much (well, we haven't been too nice to it in the first place) and so rendered mostly black images.

Second, the minimum size of div elements is limited by the font size, e.g. they couldn't become smaller than the corresponding CSS line-height. Particularly, some fundamental decorators were affected that led to some non-perfect theming, also menu separators, but all is fixed now.

URI Handling

There has been some reason for confusion and discomfort about the
way URIs are handled and can be tailored for an application (see also bug#1413). In this regard, a substantial piece of documentation about URI handling has been added to the manual, detailing the use and meaning of URIs in the config and generated application code. But mind that this particular section reflects the upcoming 0.8.1 implementation.

Generator logging

Generator console logging is now divided into STDOUT (levels "debug" and "info") and STDERR (levels "warning", "error" and "fatal"), so you can redirect streams as you would normally expect. Logging into the console and an optional log file now behaves identical. The progress indication, i.e. the "percentage steps", has been fixed to "info" level logging, which also means that it is turned off when you use the '-q' command line switch of the generator.

Application skeletons

The 'with-contrib' skeleton (component/skeleton/with-contrib) has been removed from trunk (bug#1420). Its main feature was to support an additional library, typically a "contrib" from qooxdoo-contrib, in the application. With the new config options, this is more easily achieved and has been included into the standard "gui" skeleton as comments (see config.json). Particularly, the "libraries" job has been published to hold additional library entries. Talking of contribs, please note that the default location for the download cache (where contrib:// libraries are placed) is now the "downloads" subdirectory of the compile cache.

More bug fixes

Other issues that have been resolved include an extension to the way browser caching of XmlHttp requests may be prohibited (i.e. by adding a "nocache" parameter to the URL). There is now a new setting in trunk that prevents the "nocache" parameter from being added to the URL if the POST method is used. This is useful if your backend does nasty things like mixing parameters specified in the URL into form fields in the POST request. Helder and Derrell worked together to resolve the issue, more details are in the API doc of "prohibitCache()" in the "Request" class.

The TextArea widget didn't correctly show scroll bars for text overflow in non-Firefox browsers, which has also been fixed.

Weekly bug report

We are still figuring out what the best reporting format is for the issues that have been fixed during the week. In the previous weekly blog posts we tried a few variants, and we received mixed feedback. Apparently most people prefer to have a short written summary of the most relevant bug fixes (or "topics") in the blog post instead of an all too detailed list of bug fixes. Best solution might be to offer an additional link for a query that brings up such a detailed list. The current output format, i.e. of a regular Bugzilla query, isn't very appealing, but it should do it for now. We'll continue to work on providing a better format for a weekly report of bugs, nicely grouped by category. Anyway, here's the Bug list of week 2008-11-21.

Releases

We are planning to make a 0.7.4 release available soon, which besides several bug fixes of the legacy 0.7.x line of qooxdoo will also include an substantially improved, leak-free memory management. It would be great if existing users of 0.7.x based apps could test-drive the current version of the legacy_0_7_x branch and report any issues, thanks. Shortly after 0.7.4, and well before Xmas season, there will also be a 0.8.1 winter edition, ah, release.

Ok, that's it for the moment. Have a nice weekend.

This year again we participated in the Eclipse Summit Europe, a premier event of the Eclipse community.

Fabian, Sebastian Marsching (1&1) - left to right

Fabian, Sebastian M., Istvan Ballok (CAS)

We were happy to see so many talented people of the Eclipse community being interested in the possibilities and vision of qooxdoo as a JavaScript application framework. This reminded us of the rather surprising interest so many Java devs showed at the Java Forum Stuttgart a while ago. It is an indicator that especially the more experienced programmers and open-minded software engineers appreciate the RIA capabilities and architecture of qooxdoo. On the AJAX side, it is unfortunately all too often "Look at my JS library, it's much smaller than yours!" or even "Frameworks suck, I do HTML/CSS/DOM/JS all myself!". Geez...

Real Men Do JavaScript!

If you haven't read the following articles by Dave Thomas, please do so: "Real Men Do JavaScript!" and "Programming the World in a Browser".

It was a real pleasure to meet him at the Eclipse Summit, where he gave quite a controversial key note (e.g. envisioning JavaScript to compete successfully with - or even supersede - Java in many areas, particularly in mobile technology). Dave Thomas is an extremely smart, well-informed and influential IT person, and we appreciate he spent so much time with us to discuss lots of JavaScript and qooxdoo related topics. Exciting.

Andreas, Wayne Beaton (Eclipse), Dave Thomas, Fabian

Thanks ...

... to all the people we met and that we had so many interesting discussions with. We are looking forward to continue to work closely with the Eclipse community (e.g. RAP, e4) and to be participating next time again.

Recent Presentation

Thanks again to Tobi Oetiker for presenting qooxdoo training at the Large Installation System Administration Conference LISA '08. According to attendees it was a fine introduction on how to create RIA applications with qooxdoo. Tobi put his great material online that you shouldn't miss!

What's your next tech event?

If you plan on attending a conference, a code camp, basically any kind of tech event you think qooxdoo should be presented at, why don't you take the chance and become a speaker and let people know about it? Just drop us a note, we'll support and help you as much as we can (material, slides, give-aways, etc.).

Eclipse Summit Europe

Eclipse Summit Europe 2008 is the premier European event for users, contributors, adopters, add-in providers and service providers to learn, share expertise and discover new opportunities and solutions in the Eclipse ecosystem. It takes place on November 19-20 in Ludwigsburg/Germany. We are going to participate (make sure to stop by the United Internet booth to meet Fabian and me for some qooxdoo chat and job opportunities). We are looking forward to all the exciting technical discussions and to meeting people (again).

Generator

The following features have been added to the configuration system of the generator:

• Name resolution for imported jobs is now extended to include the local (i.e. the importing) config, and then the original config. This way job references in imported jobs that cannot be resolved in the current config will be resolved in the original config (i.e. the config the imported job was defined in).
• You can now use macros from the config's top-level let in other top-level keys, like include or export. This fixes a common inconvenience to e.g. specify a path to the qooxdoo installation as a macro, but not being able to reference it when including application.json.
• In the import subkey of a top-level include you can now use little maps in place of a plain job name. The format of the maps is {"name": <jobname>, "as": <alias>}, so you can import the named job under a different name. This is helpful to circumvent name clashes with local jobs.
• To enforce overriding behaviour of a job or job feature during job extension, you now have to use "=" as a prefix for the job or feature name. The "__overriding__" map key to achieve the same result is no longer supported.
• The export key for filtering jobs exported during config includes has been deprecated for the time being, due to potential interference with job name resolution. This affects all config files that are being included by others, but is safe to use for application-level configs that are user-facing and are not further included (In these cases, it is helpful to limit the user-visible list of jobs). - This might get revoked in the future.

Also, work on a schema definition for configuration files has started.

IE8 Support

Some info about the current state of IE8 support: This week Chris spent some time to test Internet Explorer 8 support in qooxdoo. We tested qooxdoo 0.8 (trunk) and 0.7.x with IE8 Beta2 (the latest pre-release) in all three modes (Quirks, IE7 standard and IE8 standard).

Good news is, qooxdoo (0.8 als well as 0.7.x) supports both Quirks and IE7 standard mode. Your qooxdoo application should run fine in any of these two modes. See the wiki page about IE8 modes and how you can select one for your application.

The not so good news is, that we don't (at the moment) support IE8 standard mode, due to some strange rendering problems that we think are present in this second beta of IE8. We might continue to try to figure out a solution, but at the moment it seems we need to wait for another (pre-)release of IE8 that has less problems. Currently we suggest to run IE7 standard mode to get the best result for your qooxdoo application.

Bug fixing

As announced in the previous blog post, we started to include info about the issues that have been fixed during the week. If you have comments and suggestions about the presentation of bug information, please let us know. Ok, so here are the bugs fixed since last week:

UI Core

• #1564 It is not possible to create an element and apply styles at the same time
• #1452 Tab key to navigate between widgets doesn't always work inside a TabView
• #1512 Command doesn't stop the default action in the browser when using browser shot cuts.
• #1576 The shortcut parsing is incorrect.
• #1480 Zooming in or out distorts text on widgets in IE7
• #1523 terminate() and close() methods are not called
• #1530 Property "selectable" for qx.ui.basic.Label doesn't work in all browsers
• #1376 Chrome problem with document.getElementsByTagName
• #1556 Flash detection doesn't work in bom.
• #1566 Couldn't change the color by setting hex value.
• #1572 External API from Flash is not available in IE8.

Window

• #1465 blockerColor and blockerOpacity don't work
• #1532 maximized windows cant be unmaximized!
• #1575 Negative coordinates i window.center()

Table

• #1560 Filtered Table Model does not Restore values more than once.

Menu

• #1561 qx.ui.menu.CheckBox doesn't fire changeChecked event

Framework

• #1577 qx.bom.client.Multimedia: "has" method needs implementation
• #818 qx.client.Timer misbehaves in Firefox

Demobrowser

• #1551 Clip (BOM): Script error "Invalid argument" when clicking "ResetClip"
• #1552 Label (BOM): Ellipsis doesn't work with long label
• #1553 Request (BOM): Script error "Object doesn't support this property or method"
• #1554 Selection (BOM): The "result div" is show without border and correct size.
• #1555 Event Iframe (Event): Demo has a script error in build.
• #1544 Translation Color (Animation): The demo doesn't show the "Welcome to qooxdoo animation!" element.
• #1545 Translation Position (Animation): The demo doesn't show the "Welcome to qooxdoo animation!" element.
• #1546 Tree Highlight (Animation): Script error when do some action with nodes.
• #1557 Save Dialog (Animation): Can't read the dialog text , when the dialog is opened a second time.
• #1562 Calculator shows -8 after click on 1, +/-, 2

Testrunner

• #842 Can't select test result output of TestRunner in IE

Tooling

• #1252 Add support for macro expansions in "include" section in config.json

That's it for now. Have a nice weekend.

Here the blog post that wraps up last week's topics:

New team member

We are happy to welcome another new team member: Daniel Wagner just joined the qooxdoo core team at 1&1. He has a strong background in traditional web development and technologies like XML and XSLT, and he is eager to extend his basic qooxdoo know-how and learn more about JavaScript-based application development. Besides getting involved in regular framework core development, he is expected to work closely with other in-house teams to create and extend qooxdoo-based architectures.

Framework

As an ongoing task regular framework development continued, mostly focusing on fixing bugs and adding documentation. These blog posts here being weekly status reports, we start to include references to all the bugs fixed during the week in question. The most relevant bugfixes often get a more detailed treatment in the blog, but have a look at the following kind of queries if you are interested in all the details of issues resolved (we are about to setup an improved presentation of bugs for the next blog posts):
Bug list of week 2008-10-31
Bug list of week 2008-11-07

Generator

Heavy lifting has been done this week - and is still continuing - to improve customization of generator jobs (see the dedicated post). The goal is to make it easier to customize existing jobs by providing just enough information to tweak certain features. While the desired goals are easily named, the workings of the generator behind the scenes are subtle and tedious, to sort out consequences and side effects. They don't require a lot of coding, but a lot of thinking and testing. Results have not been finalized yet, and feedback is welcome.

There is also a new wiki page providing some optional background information for the interested, about how the configuration system is deployed in the SDK.

IE woes

Alex had an interesting, somewhat frustrating, post about how easy it is to break IE's Undo/Redo in HTML editing mode. Sometimes you wonder why such rather fundamental problems haven't already been discovered and addressed. At least we were not aware of such problems. If you think of all the other HTML editors as fans, aren't there enough targets to be hit? Anyway, if you have an idea how to fix or workaround it, please let us know.

TextMate bundle

There are a few solutions for qooxdoo specific support in editors and IDEs. A new and interesting one, particularly for Mac users, is the freshly-baked TextMate qooxdoo bundle. At least 3 of us are enthusiastic about it: Fabian, Johnny, Martin. It has been asked for by qooxdoo users a few times, so the current bundle in qooxdoo-contrib should be a good place for collaborating on such a support. Just get yourself involved.

C U L8R

Oops, that week status report never went online in time. So here it is, mostly for the record, as the regular blog post covering the most recent week will also be published soon.

Past Conference

As expected, "AJAX in Action" was a fine conference. There has been a detailed blog post by Fabian about it already. Particularly, meeting (again) many of the German committers of other AJAX frameworks (Dojo, jQuery, mootools) was great. Always a pleasure is to meet other qooxdoo users in person, many of them for the first time, e.g. Sebastian Fastner who also started blogging about qooxdoo (German only).

Blogosphere

Talking about blogs there has been some more activity from qooxdoo users, for instance by Atamert Ölçgen, who published quite a nice tutorial beyond the Hello World.

In general the volume and rate of posts about qooxdoo in the world-wide blogosphere is still rather low. Many qooxdoo users are developing applications from within an enterprise and hardly are the guys that run a blog. But there is no reason (and not much use) for qooxdoo as an Open Source framework being a best-kept secret. So if you run a blog, please don't hesitate to talk about qooxdoo. There is also nothing wrong in pointing to some interesting qooxdoo features from comments made to other people's blog posts (just try to add some value to a discussion without bothering people, try to stay out of framework bashing). Comments by you as an actual qooxdoo user are usually more relevant to others than comments by us as full-time core developers. Thanks for letting more people know about qooxdoo and the features you like best.

Upcoming conference

A qooxdoo user that is so enthusiastic about qooxdoo that he wanted to share his experience with others at a conference is Tobi Oetiker. You most certainly know him from his famous RRDtool or the more recent qooxdoo-based applications like du2rrd or SmokePing. He'll host a training session about qooxdoo at the Large Installation System Administration conference LISA '08. Thanks Tobi and good luck!

That's it for now, next is last week's status report.

During the migration of the HtmlArea to the 0.8 codebase I encountered serious problems concerning IE's execCommand method. To be more precise: only the Undo and Redo commands are affected.

In short: the HtmlArea is using an approach to do a kind of monitoring of the user manipulations, but it does rely internally on the native execCommand method to actually revert/recover these manipulations. This approach worked with the 0.7.x - honestly there were some issues, but since Undo/Redo functionality is non-trivial stuff for WYSIWYG editors I concluded to live with it.

Now comes the show-stopper. With 0.8 joining the game things are different as we're are doing more on-the-fly DOM manipulations (like for hover effects on buttons) which shouldn't be a problem for a today's browser. Still the clash with IE's execCommand hit me unprepared and I must admit I never ever considered this could happen in a modern browser. See for yourself.

 
<html>
  <head>
    <title>Iframe-Test</title>
    <script type="text/javascript">
      var domChange = function()
      {
        var content = document.createTextNode("DOMCHANGE");
      };
    </script>
  </head>
  <body>
<div style="border: 1px solid lightgrey">
      <iframe name="area" src="iframe.html" width="400" height="400" border="0" frameborder="no"></iframe>
    </div>
<div style="position:absolute; top:450px; left:20px">
      <button onclick="window.area.document.execCommand('Bold', false, null)">Bold</button>&nbsp;
      <button onclick="window.area.document.execCommand('Undo', false, null)">Undo</button>&nbsp;
      <button onclick="domChange()">DOM-Change</button>
    </div>
 
  </body>
</html>
 

For the inpatient reader: the above snippet breaks the internal Undo/Redo stack of IE.

The used iframe holds a document which is set editable with the help of the onload event and with the two buttons Bold and Undo you can manipulate the editable document to prove it is really in edit mode.

Well you can manipulate the document until you hit the third button DOM-Change. Hit the button and your internal Undo/Redo stack is broken. Every manipulation performed so far can't be reverted any more. Sad but true.

DOM manipulations are a red rag for IE, even only creating not actually adding a text node suffices for the clash. What really bothers me is that this manipulation is done at the parent window, not inside the editable iframe. One could argue that it should not interfere the Undo/Redo stack because it's happening in a different document (sounds quite logical to me *sigh*), but it seems IE does not separate this.

And yes, this bug is still reproducible with the beta versions of IE 8. Try it out the demo for yourself!

If anyone is in the position to file a bug report for this at Microsoft's bug database I would be very happy. I've created an account at Microsoft's Connect service and joined the Internet Explorer Beta Feedback connection (that's how they call it). Now I'm in position to view bugs but not to file them. So if anybody figures out how to send a bug report to Microsoft let me know.

The Problem

Until now it was tedious to customize an imported job in your application's config.json. This has given headaches to various people that needed to go beyond a simple config file that just includes the standard "application.json" and adds a few macro definitions. We received various feedback to that end after releasing 0.8, and one of the objectives for 0.8.1 is to improve on that.

In the tool chain so far, you had to define local jobs in order to tweak job parameters. In most cases you wanted to take an existing job and change one or two settings of it. This might have been the optimization setting for a build job, or some additional options for a pretty-print action. Faced with this issue, you could go all the way of creating the complete job on your own, thereby duplicating many of the settings found in the application.json/base.json default config files.

But re-using their knowledge was difficult. You had to define your local job under a different name, so you just couldn't e.g. invoke 'generate.py build' anymore, since "build" was pre-defined. To overcome this you could either invent new names (thereby breaking the well-known invocation API), or import application.json with a differentiating name prefix, like "appconf". Now you could name your local job "build", since the imported job was filed under the name "appconf::build" so there was no name clash. But now all imported jobs had that prefix, so you needed to invoke them as appconf::source, appconf::api, appconf::test and so on.

To overcome this you could have added stub jobs to your config that simple wrapped each imported job under its well-known name:

"source" : {
  "extend" : ["appconf::source"]
},
 
"api" : {
  "extend" : ["appconf::api"]
},
 
...

Now you could again invoke a "source" job that would do the expected thing, but this also resulted in blowing up your local config file with a lot of boilerplate code. Worse still, if the job you wanted to tweak was a run job (meaning it simply listed a bunch of other jobs to run), as is the case with build, you had to re-define such a run job locally, listing the sub-jobs from the imported config that you wanted to re-use, and filling in local jobs where you wanted a different behaviour:

"build" : {
  "run" : ["my-build-script", "appconf::build-files", "appconf::build-resources"]
}

Finally, in the my-build-script job you could extend the original appconf::build-script job, to at least make some use of its settings. But you could essentially only add features not specified in the original job, or (more often) override a feature entirely. E.g. if you wanted to modify the optimize feature of the build-script job from base.json, you had to repeat the whole compile-dist map; there was no way just to override the optimize feature alone, and keep everything else.

Well, you see, it's even tedious to write about it ...

The Solution

So we thought about new ways of doing things. There were generally two strategies available: either devise an easy way to customize existing jobs through jobs that extend them; or "lift" all interesting settings into macros that application developers can re-define. Although there was some sympathy in the community for the second approach, I saw a couple of problems with it. Pre-defined macros can only be made available with every new release, leaving the application developer to his own devices meanwhile. You're always stuck with a fixed set of macros, and lost if the feature you want to tweak is not covered by any of them. Also, maintaining an every-growing list of macros would be like "flattening out" the structure of the jobs. The structure information, which is instrumental in organizing hierarchical settings, is lost, and can only gradually be re-inserted by creating monstrous macro names like "PRETTY_PRINT_COMMENTS_TRAILING_PADDING" (for the corresponding feature in the pretty-print key) and such.

So we settled for the first approach. It builds on extending jobs, which is a cornerstone of the new configuration system. But we had to introduce some subtle changes. For one, the new version supports "job shadowing". If the generator detects an existing name in an imported config file, it doesn't consider it a fatal error as before, but the local job takes precedence. The corresponding job of the external config will be imported under a different name (to avoid the name clash), but will be added to the extend list of the local job. This means the local job inherits its settings (as with any explicit extend) and the relation between the two jobs is established just by using the same name. The generator will issue a warning to that end so you know what is happening.

The second aspect we wanted to change was the way job extending was resolved. Basically, it is a form of data inheritance where the extending job provides the initial settings, and the jobs from the extend list are then adding their features to it (This is what we call job merging). In case both jobs define the same feature, a conflict resolution is used to determine the resulting value:

• for simple Json data types (strings, numbers, boolean, null) the initial job takes precedence, and it's value is retained.
• for lists both lists are concatenated (modulo stripping duplicates)
• for maps a deep map merging is deployed that applies all of these rules recursively

(Earlier, the local value would take precedence in all but a few, selected cases (like the library list, or the let and settings maps), were data merging was applied). All of that allows you now to add to a minimal skeleton config the following job definition:

"build-script" : {
  "compile-dist" : {
    "format" : "off"
  }
}

to just override the format parameter of the job from base.json, and without repeating the whole darn thing. You just provide a sparse/partial definition of the job with just the feature you want to tweak .

Finally, a third change was needed, to catch those cases where you just want your value to override the corresponding value from the extended job, in case the value is a complex type (list or map). This is achieved by adding a new "meta" key to your config that lists keys in the current map that you want to be unaltered during extend unfolding. The key is "__override__", and is used like

{
  ...
  "__override__" : ["key1", "key2", ...],
  "key1" : {"a":1},
  "key2" : [1,2,3]
  ...
}

where key1, key2, ... are keys on the same level as __override__ itself. It is new in so far as it is a key that can be used on any level in the nesting of maps within a job definition.

I don't want to bother you with all the implementation details, but one interesting piece is to synchronize the new way of deep merging with the use of macros. Since macros have to be evaluated as late as possible, some of the job merging can only be performed at the time of macro evaluation. That means if one of the two jobs uses a macro in place of a value (which might be a placeholder for a complex data item), you have to insert an intermediate representation for this value that is resolved later. Go figure...

We've gone a long way to implement these configuration mechanics, and I hope it was worth it. The new system is available in the trunk version, from revision 16607. If you get the chance to play with it, let us know what you think.

I have just checked in the initial qooxdoo TextMate bundle into qooxdoo-contrib. TextMate is a very popular editor on the Mac, which is very easy to extend. Some time ago I started to hack on a TextMate bundle for qooxdoo just for fun. Thanks to some requests from the community and from my Mac using colleagues Jonny and Martin, I polished the old bundle, added some support for qooxdoo 0.8 and checked it in. You can easily give it a try by following the installation instructions in our wiki.

The bundle is still very basic. It supports building and running the application (Both source and build versions). Further it is able to verify the validity of the JavaScript code and checking it using qooxdoo's lint program.

I would like to encourage everyone to help growing this bundle. There are many simple yet very useful ways everyone can contribute. E.g. I would like to see much more code snipplets for common qooxdoo constructs and maybe some file templates to create new files. Let me know if you want to contribute.