I've just returned from Birmingham where EuroPython, the European Python conference, has been held for the second time in successive years. The organizers have done a tremendous job to make it a friendly and productive conference. I attended the preceding tutorial days, taking a full-day tutorial on py.test by Holger Krekel, a half-day introduction to Google App Engine by the venerable Wesley Chun, author of Core Python, and a half-day tutorial about TextTest held by Geoffrey Bache. All of them were excellent.

During the main conference which lasted from Monday through Thursday I focused on presentations relating to code quality and performance. Highlights for me were Raymond Hettinger's Idiomatic Python who was given another free time slot to cover more material, and the talks about virtual machines (PyPy, HotPy). Guido van Rossum, Python's "Benevolent Dictator for Lifetime", gave a very insightful questions-and-answers keynote session, where he addressed many issues both interesting and relevant for Python's future. Concerning one of them, which is also very close to my own heart, he mentioned that he is interested in high-level concurrency constructs and is attending all CSP-related talks in the conference (e.g. [1], [2]). There was also a CSP-related sprint in the days following the conference. I think this is a very important field, and has to be covered in good manner in Python. One other thing that struck me was the way people twist and bent Python, using its meta programming facilities, as e.g. Kay Schlühr demonstrated with Langscape, a framework to define language extensions which get translated to standard Python. There were also two lightning talks sessions which were a very good way of presenting interesting topics to a large audience in a few minutes.

During the conference there was also the first meeting of the PSF ever to be held outside the US. The PSF, the Python Software Foundation, is the non-profit legal entity behind Python that holds the intellectual property rights and tries to promote and protect the language. Twenty non-members where invited to attend and I managed to slip in. It was an interesting insight into the inner workings of an international open-source organisation. All in all it was a very interesting and enjoyable conference, with lots of contacts and chats during breaks and in the after-conference evenings. Way to go, EuroPython! (Ah, I wish they would rename it into PyCon Europe).

Welcome back to another weekly status update.

RingBuffer

Carsten Lergenmüller, one of our fellow colleagues that work as qooxdoo application developers here at 1&1, took some time and refactored qooxdoo's -->RingBuffer appender-->. He stripped out a generic -->RingBuffer class-->, which can now be used to store any kind of data. If you ever had the feeling that you need to save a specific amount of data and you only want to keep the latest data sets, the RingBuffer is a good choice now.

What are selectables?

During researches on a bug we discovered some inconsistency in the selection API. The getSelectables() method of the tree for example only returned items selectable for the user, which means hidden tree folders or files were not included in this list of selectables. But what if a developer wants to select something different in the tree programmatically? So we added a parameter to getSelectables() to determinate if the method should return only selectables for the user or just all selectables.

Disabled selection

With the changes of the selectables API it was possible to fix bug #3344 and enable all widgets to select disabled items with the given API. Don't worry, the user of the application is still not able to select a disabled item.

Bugfixes

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

User app with new looks

Some of you may already know the di-lemmata app, which has been around as a real-life example for quite some time. Hardly noticed, its creator Norbert Schröder updated the description this week and also added a new screenshot:

Looks quite stylish, congrats! When considering jazzing up your own app, you might want to look into qooxdoo's advanced (and fully cross-browser) theming capabilities. They allow to create any kind of custom theme, e.g. to resemble your corporate design.

Online apps

You certainly know that each Friday we publish the latest devel versions of the apps that come with qooxdoo. Well, not this time. Today we noticed some technical issues with the publishing process, so we decided to put them online next Monday.

Have a nice weekend!

Here's another weekly status update, so let's go medias in res:

Developing API Documentation

Developing API documentation has been a bit tedious so far. Editing the JSDoc comments in class files was fine, but if you wanted to look at the result to check your changes you had to go through a complete build run of the Apiviewer. This was mitigated by a full cache, but still took considerable amounts of time. Making five subsequent changes to the comments with always a generate.py api in between was not exactly rapid development. Just fixing a typo or small formatting glitch became a major interrupt in your work flow.

This has been amended.  You can now re-generate API data for individual classes. To this end, a new generator job has been added, api-data. This job just generates the API data for the involved classes, which is also done as part of the more general api job. But in contrast to this it does not generate the viewer application itself. To speed up the generation process further you can add class names as command line arguments to the api-data job. This way you can specify the exact classes you want API data to be generated for. Just make sure you run the full generate.py api initially so that the viewer application is present. Then, on changes to individual classes, just re-generate the API data for those classes:

generate.py api-data my.ownClassA ...

After re-generating API data you still have to reload the Apiviewer to see the results, but this should be considerably faster than re-building the whole Apiviewer. Mind that if you generate individual API data the index information (what you see in Apiviewer's tree view in the left pane) is restricted to those classes (plus stubs for their ancestors for hierarchy resolution). But this should be fine for developing individual class documenation.

Tutorial Update

Certainly everyone has already heard of the qooxdoo tutorials that we keep continuing now and then. Unfortunately Twitter will change its API and will disable their current API, which we used in the tutorial for posting tweets. So we changed the tutorial a bit to get all pieces back into shape.

Real-life Example: VZAweb

Henner Kollmann of Software-Kontor Helmert let the community know about their real-live qooxdoo application called "VZAweb": This web-based traffic census data base is the successor to the previous access-based stationary software. The web application is completely based on open-source components and combines GeoInformation e.g. from OpenstreetMap (OSM) with voluminous filtering functions and a report generator. It combines qooxdoo with OpenLayers and BIRT. The backend is a Java servlet running on a Tomcat server. It can be used with different databases, e.g. Firebird, Postgres, Oracle or Microsoft SQL Server.

Bugfixes

Framework: You can now disable all application tooltips by using qx.ui.tooltip.Manager's showToolTips property. qx.util.StringSplit has been updated with the newest version of Steven Levithan's cross-browser split method.

Applications: The Playground's log window now supports real-time updates and it can also be cleared by using the new "Clear" button that was added to it.
The FeedReader application got a minor usability update: the "Add Feed" window can also be submitted by pressing the ENTER key on one of title or URL text fields.

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

Devel demos

Talking of the development versions of the apps that come with qooxdoo: do you remember that the current snapshots of the SVN trunk are always put online each Friday by us as public "devel" demos? That way you can pretty closely follow the development without generating those apps from trunk yourself. Despite being devel versions they should be fairly stable, so if you find any issues, please report them so they can be addressed.

EuroPython 2010

Thomas left today for Birmingham as he is Going to EuroPython 2010. Have a great time there, enjoy many interesting talks and chats, and good luck with your own presentation as a speaker.

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

Welcome back to another weekly status update.

Team members

We briefly blogged about our new framework colleague Adrian (or just "Adi") last week. He is making good progress on his way into qooxdoo. He continued working with the framework back in the Romanian office of 1&1, and we expect him and his work to be more visible around the project soon. While we're happy about this new colleague, there is also another change in the framework team that got hardly noticed so far: Jonathan Weiß set sail for some new endeavours, left the core team just recently and moved to a different region and a new company. Johnny, we enjoyed having you in the team a lot, and wish you all the best and much fun with your future work!

API Viewer improvements

In the past you could only view exactly one class or package description in the API Viewer at a time. This often limiting constraint is now history. We added a tab view feature to the API Viewer in trunk. Now you can open a distinct tab for every class or package description you like, and switch between those tabs. To open a class/package description in a new tab use "shift + mouse click", "ctrl + mouse click" or "middle mouse button click". Regular left mouse clicks will still offer the default behavior, i.e. the hyperlinks are opened in the currently active tab, which is perfect for following cross-referenced information.

Bugzilla Moved

We have moved our Bugzilla installation to a new hardware and a new version. By now, everybody should hit the new installation, as the DNS change has propagated around the world. Clients and user profiles seem to work fine so far. The new software version features a few new user profile settings (e.g. automatically cc'ing when commenting), so you might want to check your profile. If you experience any problems using the issue tracker, let us know.

Bugfixes

Talking about bugzilla, here's the complete list of bugs fixed during the last working week.

Jython 2.5.2

The Jython team recently released a beta 1 version of Jython 2.5.2, a Java-based Python implementation. We did a quick test and were able to build various of our standard applications (like Feedreader, Playground) alright, using the trunk version of qooxdoo. As this did not work with older qooxdoo versions (e.g. 1.1), it is probably due to the recent change to the generator's tokenizer, which now features a recursion-less implementation. Hitting the recursion limit was also the issue when we looked at Jython 2.5.1 some time ago.

Please note that Jython - unlike the regular Python installations - is not officially supported by us for being used by qooxdoo's tool chain. Nevertheless this might be interesting for all of you that try to come up with a deep integration of qooxdoo tooling into your Java-centric environment (or your Java-based frameworks on top of qooxdoo). If you like to experiment, there are some notes for an (apparently) successful installation and use of Jython within qooxdoo.

Bibliograph 2.0 Beta

Christian Boulanger, a long-time qooxdoo contributor, let us all know about a new version of his Bibliograph application. It is an AJAX-based multi-user open source on-line bibliographic data manager and bibliography tool. The application has been updated to the current version of all used libraries and will soon be released as a Beta version. See the online version of the app.

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

This week saw new colleague Adrian Olaru from our Romanian office on visit here in Karlsruhe. Adrian is making his way into qooxdoo, and we had a good time acquainting ourselves with each other. Adrian will be doing qooxdoo stuff, both within the framework and for app development, in Romania. Welcome, Adrian!

New Tutorial Available

We just want to  remind you  that we continued the tutorial series with a tutorial about custom widget creation. If you haven't read it, have a look at it and enjoy .

Framework Table

This week, we took some time to fix a couple of bugs in the qooxdoo Table. As the table is the most complex widget we have in the framework, most of the time  its bugs have the same complexity. So we're happy to get an important part of qooxdoo even more stable.

Forms

If you have ever used the form validation of qooxdoo, you may have recognized the difference between adding a validator and adding a plain event listener. You haven't been able to set a context for the validator. We added that possibility to the validation manager and to the form itself, which uses the validation manager.

Bugs

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

Tool Chain Script Names with Hash Code

Script file names can now be generated containing a hash code. This might be interesting for apps that are updated regularly and where a changed hash code indicates that the corresponding file has changed. The behaviour is controlled by the compile-options/paths/scripts-add-hash config key (defaults to false). For apps that are generated into multiple packages, e.g. because they use parts or dedicated I18N packages, this might be beneficial as returning clients only have to download the new packages after an update, and won't use client-cached files that are out of sync. The loader script will retain its simple name and will not contain a hash code in any case, so the main script reference from an index.html does not change. Also, with any of the other scripts having changed, the loader script will also change as it contains references to all other script files.

That's it for this week - see you around next time.

In this tutorial we will deal with how to create a custom widget for our Twitter application. It is necessary that you finished the tutorials part 1 through part 3 (1, 2, 3) to work with this tutorial, but previous knowledge from tutorial 4.1 is not needed.

Do you remember the mockup from tutorial part 1?

You can see that one tweet consists of a photo, a text and a creation date, but at the moment the Twitter application doesn't show the creation date of a tweet.  This is because we use the default ListItem to show a tweet and a ListItem can only show an image and/or label. To achieve our goal, we have to create a custom widget which we can use instead of the ListItem.

The code in this tutorial should also work when you haven't completed the 4.1 tutorial because it doesn't depend on the code changes from tutorial 4.1. But if you have any problems to run the tutorial, you can also checkout the code from tutorial 4.1 on github. The plan

First of all we have to create a custom widget which fulfills our requirements from the mockup. We will achieve this by combining a widget with two labels and one image. Afterwards we have to configure the controller so that it uses our custom widget for the tweets.

Create the custom widget class

You should know how to create a class from the previous tutorials. So please create a class for ''twitter.TweetView'', but in our case we need to extend from ''qx.ui.core. Widget''.

qx.Class.define("twitter.TweetView",
{
  extend : qx.ui.core.Widget,
  include : [qx.ui.form.MModelProperty],
 
  construct : function() {
    this.base(arguments);
  }
});

The attentive reader noticed that we use the include key for the first time. include is used to include a mixin in a class. This is necessary in our case to support Data Binding. Our Twitter application uses it and therefore it is expected that the new widget implements the qx.ui.form.IModel interface. Otherwise the widget can't be used with Data Binding. But fortunately the mixin qx.ui.form.MModelProperty already implements it, so we can reuse the implementation.

Define the needed properties

Our widget should show a Tweet as shown in the mockup. To achieve this, we need properties to save the data for a Tweet. Add this definition to the TweetView class:

properties :
{
  appearance :
  {
    refine : true,
    init : "listitem"
  },
 
  icon :
  {
    check : "String",
    apply : "_applyIcon",
    nullable : true
  },
 
  time :
  {
    check : "Date",
    apply : "_applyTime",
    nullable : true
  },
 
  post :
  {
    check : "String",
    apply : "_applyPost",
    nullable : true
  }
},

The properties icon, time and post contain the data from a tweet. In this definition you'll also find a property appearance. This property is needed for the theming, it tells the appearance system that the TweetView should be styled like the ListItem. We could also use a new appearance id, but than we'd have to define an appearance for it and that's not part of this tutorial.

How to define properties was explained in tutorial part 3, so we don't repeat it. But we use some unfamiliar keys for definition and I will explain them:

• check: check ensures that the incoming value is of this type. But be careful, the check is only done in the source version.
• apply: here you can define which method should be called when the value changes.
• refine: this is needed when an already defined property should be overridden.
• init: defines the initialized value of a property.

Using Child Control

qooxdoo has a special system to realize combined widgets like in our case. This system is called child controls and you can find a detailed documentation in our manual.

Okay, back to our problem. To achieve the requirements we need an Image for the photo, a Label for the post and another Label for the creation time. So three widgets, also called sub widgets, are needed for our custom widget. And last but not least the familiar Grid layout for layouting, but that's not created in the child control implementation. We just need to keep it in mind when adding the child control with _add.

members :
{
  // overridden
  _createChildControlImpl : function(id)
  {
    var control;
 
    switch(id)
    {
      case "icon":
        control = new qx.ui.basic.Image(this.getIcon());
        control.setAnonymous(true);
        this._add(control, {row: 0, column: 0, rowSpan: 2});
        break;
 
      case "time":
        control = new qx.ui.basic.Label(this.getTime());
        control.setAnonymous(true);
        this._add(control, {row: 0, column: 1});
        break;
 
      case "post":
        control = new qx.ui.basic.Label(this.getPost());
        control.setAnonymous(true);
        control.setRich(true);
        this._add(control, {row: 1, column: 1});
        break;
    }
 
    return control || this.base(arguments, id);
  }
},

The child control system has a special method to create sub widgets. The method is called _createChildControlImpl and we override it to create our subwidgets. This method is called from the child control system when it notices that a sub widget is needed but not already created.

In our case:

• icon: for the photo
• time: for the creation time
• post: for the text from the tweet

Dependent on the passed id we create the correct subwidget, configure it and add it to the Grid layout at the right position. If an unknown id is passed, we delegate it to the superclass.

Finishing the constructor

Now i'ts time to finish the constructor.

// create a date format like "June 18, 2010 9:31 AM"
this._dateFormat = new qx.util.format.DateFormat(
  qx.locale.Date.getDateFormat("long") + " " +
  qx.locale.Date.getTimeFormat("short")
);

The property for the date saves only a date object and our requirement from the mockup describes a spacial format and a simple toString usage is not enough. Therefore we need a special transformation which we can achieve by using DateFormat.

// initialize the layout and allow wrap for "post"
var layout = new qx.ui.layout.Grid(4, 2);
layout.setColumnFlex(1, 1);
this._setLayout(layout);

Now we create a layout for our custom widget. This should be known from tutorial part 2.

// create the widgets
this._createChildControl("icon");
this._createChildControl("time");
this._createChildControl("post");

Time for our child control implementation. With these lines we trigger the subwidget creation which we implemented before.

Adding the apply methods

We have already defined the properties, but we haven't implemented the needed apply methods for them. So, time to add the missing apply method for the properties to the members section.

// property apply
_applyIcon : function(value, old) {
  var icon = this.getChildControl("icon");
  icon.setSource(value);
},
 
_applyPost : function(value, old) {
  var post = this.getChildControl("post");
  post.setValue(value);
},
 
// property apply
_applyTime : function(value, old) {
  var time = this.getChildControl("time");
  time.setValue(this._dateFormat.format(value));
}

The apply methods for icon and post are trivial, we have to ensure that we delegate the value change to the correct widget. To get the correct widget instance we can use the getChildControl method and afterwards we can set the value on the widget.

The date, however, needs some extra love. We have to use the DateFormat instance to format the date before we set the value.

Finishing the custom widget

At the end we have to add the attribute _dateFormat to the members section and a destructor to clean up the created DateFormat instance.

Just add this line at the beginning of the members section:

_dateFormat : null,

And the destructor after the members section:

destruct : function() {
  this._dateFormat.dispose();
  this._dateFormat = null;
}

Great, now we have finished the custom widget.

Configure the List Controller

At the moment the controller doesn't know that it should use our TweetView class. Therefore we have to change the old controller configuration. Search for these lines of code in the Application.js file:

// create the controller
var controller = new qx.data.controller.List(null, main.getList());
controller.setLabelPath("text");
controller.setIconPath("user.profile_image_url");
controller.setDelegate({
  configureItem : function(item) {
    item.getChildControl("icon").setWidth(48);
    item.getChildControl("icon").setHeight(48);
    item.getChildControl("icon").setScale(true);
    item.setRich(true);
  }
});

First  of  all, remove these two lines:

controller.setLabelPath("text");
controller.setIconPath("user.profile_image_url");

Now to the delegate, just replace the current delegate with this one:

controller.setDelegate({
  createItem : function() {
    return new twitter.TweetView();
  },
 
  bindItem : function(controller, item, id) {
    controller.bindProperty("text", "post", null, item, id);
    controller.bindProperty("user.profile_image_url", "icon", null, item, id);
    controller.bindProperty("created_at", "time", {
      converter: function(data) {
       if (qx.bom.client.Engine.MSHTML) {
         data = Date.parse(data.replace(/( \+)/, " UTC$1"));
       }
       return new Date(data);
     }
    }, item, id);
  },
 
  configureItem : function(item) {
    item.getChildControl("icon").setWidth(48);
    item.getChildControl("icon").setHeight(48);
    item.getChildControl("icon").setScale(true);
    item.setMinHeight(52);
  }
});

The concept of a delegate should be known from tutorial part 3, I will only explain the modifications.

You can see that we added a createItem method: With this method we can configure the controller to use our TweetView for item creation. The method bindItem is used to configure the controller to keep the properties of the model and the widget synchronized. In our case it is important to keep the photo, post and creation date synchronous.

controller.bindProperty("text", "post", null, item, id);

Let us have a look at the above example. The bindProperty method is responsible for the binding between model and widget. The first parameter is the path from the model, the second is the name of the property in the widget, the third parameter is an options map to do e. g. a conversion, the fourth parameter is the widget and the last is the index.

In our case the photo and the post need no conversion because the source data and target data are of the same type. But the creation time needs a conversion because the model contains a String with the UTC time while the widget expects a date object. So we have to convert the data:

converter: function(data) {
  if (qx.bom.client.Engine.MSHTML) {
    data = Date.parse(data.replace(/( \+)/, " UTC$1"));
  }
 return new Date(data);
}

The converter method creates a date object from the given String. Don't be confused by the if statement. The Twitter model has a format which is not standard UTC format in JavaScript and Internet Explorer has problems parsing the String, therefore a short conversion is needed before the date object can be created.

The configureItem method should be known from tutorial part 3, there are only some improvements to keep the same behavior as before.

Great, now we've got it! Run generate.py source to create the application.

Again, if you want to take a look at the code, fork the project on github.

Here comes another status update. It's a short one, as the core team is about to leave for the legendary 1&1 summer fest after quite a busy week. We are currently working on various topics, from infrastructure to documentation, features and tooling, so stay tuned for some info in the next few days.

Bugfixes

Bug triage and resolving issues is also permanently done, which becomes increasingly important as we approach another double release in early August as planned. As usual, for a complete list of bugs fixed during the last working week, use this bugzilla query.

Bugs Data

Talking of bugs: since long we maintained bug related data, like sample applications to reproduce the bug and to collaborate with others on resolving the issues, in a dedicated path within the qooxdoo-contrib repository. We have moved the whole qooxdoo-contrib/Bugs folder to a new location within the repository, so it is no longer in the same path as the real contributions. The new repository URL for the bugs data is:
https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/data/bugs
If you used this bugs data, please update your checkouts accordingly. If you happen to come across an URL to the old bugs data folder in one of the bugzilla reports, please see the corresponding data in the new folder.

Ok, so we're off now to join our colleagues. C U next week.

I will be attending EuroPython, the  conference of the European Python community, this year. The event will be held in Birmingham, UK, on July 17th - 24th. I will also be giving a presentation, talking about how we use Python with qooxdoo.

Welcome back to another week in qooxdoo land.

Manual

The manual 1.2 preview went online this week, featuring the first manual version generated from reST files. Besides this online version, which is integrated nicely into the existing homepage, there is also an PDF version available for download and offline reading. So you'll also be able to print out the manual as some sort of "book". So even there is no qooxdoo manual to buy in a bookstore, you certainly find this useful, also as the electronic manual, unlike a print version, is always to be up-to-date for each release (and mostly in-between those as well).

Bugfixes

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

Visit

As one of the highlights this week, we met with Tobi Oetiker, long-time qooxdoo enthusiast and contributor. He took the change to stop by and say hello to the qooxdoo framework team while he was near the qooxdoo headquarters. We had a great time talking about qooxdoo, the projects of Tobi and his company Oetiker+Partner and of course all kinds of tech stuff and the likes. We enjoyed it very much, thanks Tobi for visiting us!

Open Source Project

During the week there has been quite some lively discussion on the mailing list about various issues related to the project. The discussion involved many valid as well as some invalid points, a good dose of praise, misleading expectations and useful suggestions. Some issues are to be answered (or already have been answered) specifically, often rather focused on technical features. The others are more about a few important general topics that are definitely worth to be looked at and further cleared up. There will be a separate blog post soon to account for that explicitly.

Jspresso

As a last minute addition to this due weekly blog post, here is some news from Vincent Vandenschrick, creator of an interesting server-centric framework that optionally uses qooxdoo:
"Just a quick message to inform you that Jspresso 3.5.0 has just been released with full support of qooxdoo 1.1 as one of its available UI engines. But before talking about Jspresso, let me thank the qooxdoo team as a whole (including contributors) for making such a good framework. Its superior design made it fit painlessly into the Jspresso architecture. As for the used contributions, you will find java-rpc, collapsable-panel and upload-widget. So kudos to their authors.

Jspresso is a full-stack Java/Flex/Javascript RIA framework that offers a server-centric architecture (Servlet/Spring/Hibernate) with server-driven, multi-channel UIs (qooxdoo/Flex/WingS/ULC/swing) that share the exact same application codebase. Jspresso builds are entirely Maven based (including the qooxdoo python build) and Jspresso projects are instantly bootstrapped by a Maven archetype."
For more info, see their expanded documentation or see some introductory screencasts and tutorials.

That's it for now, TTYL.

The new SVN-based qooxdoo manual is online. As you can see from the URL (http://manual.qooxdoo.org/1.2-pre/), we've followed an established scheme: We have a dedicated sub-domain, manual.qooxdoo.org, followed by a version-specific path like 1.2-pre here, and will support additional "meta" paths like 1.2.x (for the latest stable 1.2.x version), current (latest stable) and devel. This duplicates the scheme we have e.g. for the demos. We plan to update the devel version of the manual regularly like the demo apps (currently once a week, on Fridays).

The manual itself still closely resembles the 1.1 manual. The index page is slightly overhauled, but most "content" pages are direct copies of their 1.1 counterparts. Then contentual work will ensue in the course towards the 1.2 release. All pages are generated from reST-formatted source files that are processed by Sphinx. Parallel to the HTML version of the manual, this allows to create a PDF version of it, which you find offered in a download link from the index page. Some of you might find this interesting. There will also be a generated version of the manual as part of future SDK releases, so everybody downloading the SDK will have an offline manual ready.

As always, feedback is welcome, both regarding content, organization/structure and coverage of the information on one side, as well as hints going down to typos and mistakable formulations in specific text passages on the other. If you find yourself envisioning major modifications you can open a bug report and attach patch files, as with code issues. We hope that most people will be happy with this way of going about things and see the benefits of it, now that maintaining the manual no longer boils down to wiki editing .

Welcome back to the regular weekly blog post. After last week's conference and holidays, work continued on framework and especially infrastructure (e.g. manual). But now to some fine new contribution:

New charting contrib: QxJqPlot

After introducing OpenFlashChart as a new charting contribution last week, this time it was Tobi Oetiker, who contributed a qooxdoo charting solution called "QxJqPlot". It is a pure JavaScript and Flash-free solution based on the jqPlot project.

For more info on how to use it see the QxJqPlot homepage. The source code of this project in qooxdoo-contrib can be found in SVN.

Bugfixes

For a complete list of bugs fixed since the last status update, use this bugzilla query.

C U around next time.

As you might have already read in the pre post, I went to the Scandinavian Web Developer Conference (SWDC) last week. Surely you are interested in the experiences I made and what we can learn from those for qooxdoo. So here we go, in diary-style:

Day 1: Travel to Stockholm

I went to Stockholm a day earlier to be relaxed and settled for the conference the next morning. After some sight seeing I checked out the location of the conference, which is luckily only a few walking minutes away from the hotel. So everything is prepared for a good conference day tomorrow.

Day 2: Frontend and Backend Day

My second day in Stockholm was the first conference day, which was kicked of by Robert Nyman introducing HTML5. He gave a good impression of what HTML5 is about and how it could make life a bit easier for a developer.
The next talk was an experience report about developing large web sites, which hit the common sense of the first day: don't try to implement everything pixel precisely, especially not for IE6!
The following talk's topic was not a JavaScript, CSS or HTML topic. Alexander Lang talked about CouchDB and compared some typical use cases to relational databases. After that, we got some light lunch to be prepared for the rest of the talks.
Rik Arends, co-founder of Javeline, the organization behind Ajax.org, introduced in his talk their idea of how to develop not only but also for "the cloud". In their vision we should develop in the cloud with a web-based IDE, which was quite impressive from a technical point of view.
After that, Daniel Glazman talked about the browser war in 2010 from a standardization point of view, which was really interesting. He encouraged all framework developers not only to drop IE6 support. The best thing according to his mind is to remove the whole IE6 code to force the users to update.
Next up was Dylan Schiemann, co-founder of Sitepen, who gave the audience a look at how Dojo and MooTools use patterns in their basic OO model. Generally, we could have taken qooxdoo code and put it right beside the two options he showed and have the same functionality.
The topic of the next talk given by Sergey Ilinsky was his own framework, Ample SDK, which covers some interesting fields like SVG mapping to VML for IE.
After the dinner break three talks were still left. The first of those three talks was given by Mark Wubben. His topic, building extensions for Google Chrome, was completely new to me. He showed that it is quite easy to develop extensions, because you use all the technologies we already know, web technologies.
Next was Malte Ubl introducing node.js, a V8-based JavaScript server optimized for i/o and performance. He gave an high-level overview of this technology. The topic of the next talk was Google for developers held by Patrick Chanezon. He introduced the Google App Engine and the new App Engine for Enterprise stuff.
The last talk of the day was given by Chris Heilmann, an evangelist at Yahoo!. The title of the topic was Progressing and Enhancing. Chris is a good speaker with a good sense of humor, who kept the audience following him even he was the last speaker. His genius idea was not to just drop IE6 support. Instead, we should use IEs blur filter to randomly blur some text on the page so that the end users only recognize something is wrong. We developers wouldn't tell them that it is our fault so they have to upgrade their browsers. Here is the whole story. As I said, great sense of humor!

By the end of the day, I'm really satisfied with the talks and the conference, but also happy to be at the hotel and get some rest after so much cool information.

Day 3: Mobile

The topic of the second conference day was "The mobile web", which is sure a really interesting topic nowadays, especially in the context of web technologies, which I think is a clever way to solve the cross-platform problem in an elegant way.

First up was Wolfram Kriesing of uxebu. He introduced the audience to the mobile web along an application called "event ninja" they developed for a lot of platforms using web technologies. It's amazing how far you can go with only HTML, CSS and JavaScript.
Next speaker was Mikael Kindborg who showed an framework called DroidScript, which allows you to develop in a manner reminding me of Smalltalk.
Next up were two guys of Sony Ericsson, the main sponsor of the event. They showed their new SDK based on PhoneGap, which was pretty cool. Even being a sponsored talk, they showed some technology and it was not only a commercial thing.
Another speaker of Yahoo!, Tom Hughes-Croucher, was up next. His main message was that we have to reduce the number of requests, especially on the mobile web. Maybe we should use a technology like YQL for that?
After the lunch break, Tom Blackmore presented. He used a very simple taxi-service finding app to show the challenges you have to face when programming a location-based application.
Next up was another guy of uxebu, Nikolai Onken. The name of his talk was "Human APIs". This topic included extending the currently available JavaScript APIs for example in PhoneGap with everything the native environment can offer with ease. He had some impressive examples like connecting a heart sensor to the iPhone and accessing its data from JavaScript. But even more impressive were his ideas that basically everything is possible within the browser in the mobile world.
As on the first day, HTML5 was also a topic. Michael Mahemoff of Google gave a talk caleld "HTML5 gives you wings". He focused on caching and storing data on the client side. So he covered the whole offline capabilities of HTML5, which were really interesting to see.
"Building linked data applications for the iPhone" was the title of the next talk held by Henk Jurriens. He introduced the audience to linked data, RDF to be specific, and his framework called Lodsy, which is capable of handling such data.
The last talk of the conference was given by Tim Caswell. He showed a pretty cool demo of how to use node.js as a server to power a Raphaël-based iPad multitouch app. He used his own framework named connect on node.js to handle the AJAX long polling stuff and some other things.

After all those interesting talks, my final impression is very positive. The venue was just great and the speakers were all pros. Especially the second day showed how far we can already go with web technologies on mobile devices. Also big thanks to Peter Svensson, the organizer of the conference. Well done!

Hi, this is an out-of-schedule status update, since tomorrow (Thursday) is again a holiday here for the qooxdoo core team (and the typical bridging day on Friday). Despite being a short week, there are quite some news:

New contrib: OpenFlashChart

We added a new contribution for charting to qooxdoo-contrib (thanks Chris!). The contribution uses the Open Flash Chart (OFC) implementation to render charts with Flash. The interesting part is that you only need to use the qooxdoo-based wrapper for OFC, which then displays the chart in a (generic) Flash movie. You never get in touch with Flash code yourself. The chart is described in a specific JSON format. You can either generate this JSON data in the client with JavaScript, or you can generate it on a server. For the latter task OFC provides different backend implementations.

Have a look at the following two demos: one demo with external JSON data and the other demo with in-browser data.

Generator: New file copy tool

Until recently, qooxdoo's Generator used the Pyrobocopy tool to process the copy-files and copy-resources job keys. We replaced this tool with a simpler, custom made one appropriately named CopyTool to ease maintenance. If you're using trunk and run into any problems with missing resources, please let us know by posting on the mailing list or filing a bug report.

Bugfixes

Only a few bugs were addressed this time, here's the corresponding bugzilla query.

New releases: RpcPhp and RpcConsole

Christian Boulanger, long-time qooxdoo fellow, has released new versions of contribs concerning qooxdoo's JSON-RPC server communication:

RpcPhp 1.2.0

See the RpcPhp documentation for more general info. Important Changes since version 1.1.0:

• PHP4 support has been dropped, it now supports PHP 5.2-5.3 only.
• The handleQooxdooDates constant has been changed to false as default value. This means that by default, the JSON response doesn't encode dates as JavaScript objects. The main reason is performance: the PHP-based JSON encoder class performs really poor with large datasets compared to using json_encode() or json_decode(), so the default is now to use these functions.
• The error behavior has changed. We now fully rely on native PHP exceptions for handling errors.Instead of returning an error object, use throw new JsonRpcException("Error message", ); You can throw any other error, it will all be caught and reported to the client.
• The signature of JsonRpcError has been changed. In previous versions, it was (int $code, string $message, int $origin). Now it behaves like a normal PHP Exception and the signature is (string $message, int $code, Exception $previous, int $origin). Please update your code accordingly.
• Note that you no longer need to use the signature ($params, $error) for the service methods. Arguments are passed to the service methods as they are in normal PHP functions/methods. For backward compatibility, method introspection is used. See AbstractServer.php, lines 68-88, for more information on that.

RpcConsole 0.2

This contribution is a scriptable test client for your JSON-RPC backend. See the RpcConsole docs for more info or an online demo of it.

This is mainly a bug fix release, no major functionality has been introduced. The RpcConsole has only been tested with the PHP backend so far, but should in principle work with any of the qooxdoo RPC backends. Christian Boulanger would love to get feedback from the Java folks, for example, if it works for them, too.

That's it for this (half of a) week. C U next Monday.

As most of you might know we're in the process of moving our manual out of the wiki and into SVN. Along goes a change in markup (reST is the new one). But it also involves organizing the roughly 190 different documents into a coherent manual. A main entrance to such a manual is its table of contents (or "site map" in web speak). I think that besides the ubiquitous "search-don't-sort" mantra, there is a strong use case for systematics, where a user finds a particular piece of information because he understands where it fits into the overall order of things. This brings up the question of categorizing pieces of information. Here are some general notes concerning this topic. They use the term "site map", but the issues are all the same for a manual.

Important for any site map is the decision for a single organizing principle. Each documentation page or information item can be classified along multiple aspects or dimensions (as with all real-world things). E.g. a document such as the Hello World document has a contents aspect (”building a qooxdoo application” as opposed to “class system” or “compiler internals”), a style aspect (its step-by-step, taking-the-user-by-the-hand attitude would qualify for “tutorial” or “how-to”, in contrast to “background information”, “founding principles”, or “todo-list”), an audience aspect concerning the addressed audience (like ”newbie”,  rather than “experienced”, “advanced”, “user”, or “developer”), a location aspect (”local” vs. “external” with regard to e.g. the web site), or a completeness or relational aspect, which concerns its relation to other documents (”self-contained”, “overview”, “link-page”, “annotation”, ”part” etc.). Other aspects often seen in classifying information is along their format (.doc, .html, .pdf), author (see e.g. CPAN) or date. It’s easy to see that some aspects lend themselves better as an organizing principle than others (Have you ever searched for a document where the documents where organized by file extension?! ).

For a site map that should help the user find things through systematics, mixing the aspects by which items are organized is a bit of a killer. My preference for organizing a site map would be along the contents or concept aspect, i.e. all information items are classified along the question “Which conceptual part of qooxdoo do they mainly belong to?”. But usually you see manuals organized by user needs or train of thought: They start with some "getting you started" information that trace the user's steps to produce a first working example. This includes the installation procedure and a verification thereof. After that, usually the systematical part starts where things are organized conceptually. The first part is more process-oriented, the second more logical where categorization comes into play.

Of course, since all things have multiple aspects, deciding for one of them has some trade-offs. But usually users pick up the chosen aspect dimension easily, and are then better able to find things. Also, even with a single dimension it is sometimes hard to classify a specific document, since documents can jump and mix all around (although they shouldn’t ). But it’s still beneficial to weigh the document’s contents in this regard as good as possible and then make an informed decision. There is no taxonomy that is pure and without ambiguities, but it’s worth to try for the best.

Besides this general index/site map, there might be other manual-relevant documentation pages that reside outside the manual. But those pages should never contain additional information, but serve only as additional navigational aids, like topic-related link pages for a release, news, whats-new-and-hot hints, pre-factored searches and such. Nothing that can be found in the manual through these additional pages should be missing in the site map, otherwise its main purpose becomes void. New documents should always be linked from the site map first, and only then optionally from a topic-related page outside the site map. The site map should be the one-stop place from where all information about the manual contents can be accessed, reliable, exhaustive and systematic.

Welcome back to another weekly status update.

Manual goes SVN

We've decided to move the manual out of the wiki and into SVN. People working with trunk might have already noticed the new top-level documentation file tree. The benefits for this move include:

• keep the manual in close sync with the release cycles of the framework
• providing an offline version, alongside with the online version, that can e.g. be shipped with the SDK
• providing a PDF version, e.g. for download
• better editor support than what the wiki software can provide in the browser
• document management functions, like automatically generated TOC, indexes, etc.

So starting with qooxdoo 1.2, we will maintain the manual pages in SVN and will be putting static HTML pages online. It is expected to fit these manual nicely into the existing homepage structure and design just like the existing wiki-based manual. The new manual will also come with a full-text search facility. The HTML pages are generated from the text files in the repository. The markup for these text files will be reStructured Text, the current choice for the documentation system to create the various output formats is Sphinx. Just like the qooxdoo toolchain, Sphinx is also Python-based and runs cross-platform. The wiki-based homepage with all its non-manual pages will stay as it is, however it is planned to update the underlying Dokuwiki to a current version as well. There will be some more announcements relating to that topic in the weeks ahead, so stay tuned.

Bugfixes

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

qooxdoo + Lisp = qooxlisp

Kenny Tilton let us know this week that he released "qooxlisp", a new Lisp-based RIA framework under MIT license:

"What is qooxlisp? In brief, we drive a kick-ass Javascript RIA Web application framework from a Lisp application running on the server, managing in the end to turn a thick client into a slave programmed wholly from a server-side application.

Benefits

• The Grand Re-Unification of application code, with everything on the server side, including the code that has to run on the client-side. Thank you, content-type “text/javascript” and eval.
• All the power of a big programming language and all the libraries it can reach. Javascript is neat (and Lispy!) but just a toy.
• All the power specifically of Common Lisp. You have no idea, but this might help. And I do not even mention macros!
• The performance of a natively compiled language. Yes, Virginia, many Common Lisp implementations compile natively.

Ingredients

• qooxdoo: a great Web application development framework.
• Lisp: the only way to program.
• Cells: dataflow aka functional reactive programming aka constraints. The only thing better than Lisp. Fans of OpenLaszlo, FrTime, Python Trellis, or qooxdoo’s own databinding scheme will understand. Basically, one gets a declarative programming paradigm in which data dependencies are established transparently and arbitrary invariants enforced automatically, as if one were using a spreadsheet such as VisiCalc or Lotus 1-2-3.

For more info see here."

That's it for today. C U around next week.

I am really excited to have the opportunity to participate in the Scandinavian Web Developer Conference (SWDC) 2010, which will take place next week in Stockholm, Sweden. Other than the name suggests, the conference is very international. All talks will be held in English and the speaker lineup is great. Take a look at the conference homepage to see who is going to speak. There will be presentations about JavaScript in the browser, on the server and on mobile devices, so I'm really looking forward to hear all these talks.

I will be in Stockholm on June 1-3, i.e. arriving a day before the conference starts. If anybody is around and interested to meet up, just let me know. Drop me a comment or contact me via twitter.

Hi everyone, here's again the weekly status update.

Dependency Logging

A common question when analyzing class dependencies in qooxdoo is "Why is this class in my app? Which other class requires it?". Particularly in large applications it can be surprising which classes show up in a generated application, and you want to find the culprit that introduced the dependency. Since quite some time the qooxdoo generator had support for dependency analysis, with the log/dependencies config key. To answer the above questions, the log/dependencies/type:used-by setting would give you the necessary information, but so far the output was only as text on the console, and you had to track transitive used-by relations by hand. Now, the used-by analysis also supports dot output, so you can e.g. see all classes that require a particular class, and therefore cause it to be added to the application, in a proper diagram. This can also help to untangle multiple dependencies which are spread over many classes and destroy the single-interface principle.

Bugfixes

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

New backend: RpcJavaPojo

Jean-Baptiste Briaud, CTO of NovLog, was "proud to announce that a new contrib is now available in the qooxdoo SVN contrib.

RpcJavaPojo contrib is a Java backend implementation that is compatible with the current RpcJava contrib. Here POJO stands for Plain Old Java Object. That means we are using just classical, simple Java classes as business objects that go from and to client side. In the current RpcJava implementation, the name should rather be RpcJavaBean to explain that it relies on the JavaBean standard, i.e. getters/setters are mandatory.

The new RpcJavaPojo contrib is composed of 2 modules :

• serialization: It uses JSON to serialize Java objects, just like RpcJava including the “date hack”. Serialization uses code from json.org.
• RPC : it uses the qooxdoo serialization standard {service, method, param} just like the RpcJava contrib.

There are few differences from RpcJava :

• simpler (maybe a question of point of view): works at attribute level rather than getter/setter level. Less code is necessary since getters/setters are not used.
• more standard : rely on Java keyword transient to tell an attribute should not be serialized
• more modular : RPC and serialization are clearly separated
• more flexible : there are more programming hooks (maybe still not enough) to take control at different steps of both RPC and serialization
• quicker : 2 times faster based on a simple manual stopwatch
• more up to date : using Java 6 (Java 5 is a minimum) with generics, ... but this doesn’t change your life when you’re just using it

To checkout the contrib : svn co https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/RpcJavaPojo/trunk RpcJavaPojo

The only doc is currently the readme.txt file and few emails on the mailing list.

To download directly the jar file without the code/compile chore : http://www.novlog.com/json-rpc/lib/json-rpc-1.0.0.jar".

For more info about RpcJavaPojo also see its entry in the list of available qooxdoo contribs.


That's it for today. See you around next week. Please note that there's a national holiday here next Monday, so the qooxdoo core team is back at regular work next Tuesday.

Welcome back to another week in qooxdoo land. Actually, it was a rather short one for the qooxdoo team, with a national holiday here on Thursday and the usual bridging day on Friday. So lets focus on some cool stuff that qooxdoo users built recently:

User Success Story

John Spackman of Zenesis Limited wrote in to share information about a (non-public) qooxdoo app they created for a customer and launched successfully. Congrats!

"SPAR UK Limited are a UK national retailer (part of the European SPAR franchise) with an Own-Brand product range, who have to maintain audited food and product safety specifications documentation and marketing materials. Zenesis Limited recently developed the new Quality Assurance website for connecting suppliers, external product design and marketing companies, and the trading and marketing teams within SPAR Central Office.

The Quality Assurance specification app was developed using qooxdoo and has over 400 fields that need be completed, audited, and approved – plus the marketing and other design documents relating to every Own Brand product. SPAR use an external auditing company, Micron2, who have said that the SPAR QA website is more logical and user friendly than those of the other major UK national retailers.

Zenesis is proud to endorse qooxdoo because we could not have produced the QA website for SPAR without the support of the qooxdoo technology and the development team – at least not without making some serious compromises on usability and functionality!"

If you also have a success story to share with the qooxdoo community, feel free to add it to the wiki page that lists some real-life examples and/or send in some info to be broadcast via blog post.

qooxdoo+GWT wrapper updated

A few days ago Tom Schindl of BestSolution.at shipped a QxWT 1.1.0.0 release, about a week after the availability of the latest qooxdoo 1.1. If you're into Java-based programming, maybe already have experience with GWT, you should check it out. Most of the qooxdoo API is already available in QxWT, and for the last missing wrappers Tom welcomes everyone that helps fixing those spots. Lots of QxWT samples (including source code) are found in an online demobrowser similar to qooxdoo's.

Drinking Old Milk?

You certainly don't consume IE6 on a regular basis? Well, at least not without being forced to do so, e.g. for testing actual customer experience. Daniel pointed out a fancy campaign by Microsoft itself, asking users to upgrade from IE6. While they focus on outdated security features, there are tons of reasons not to use IE6, most notably inferior performance. Having said that, what about your plans to take advantage of the latest qooxdoo releases and migrating your apps from older, legacy qooxdoo versions?

Bugfixes

No status report without a list of bugfixes, so here you go: bugs fixed.

That's it for now, C U around next week.

Hi! The week in qooxdoo has been busy with after-release activities, cleaning up lose ends, bringing the issues database into shape and generally gearing up for the weeks ahead. Here are some more bits.

FeedReader

Most of you know the qooxdoo FeedReader, one of our demo apps. About a year ago, we ported the FeedReader to use the data binding features to show their qualities. This week, we added another step of data binding. We replaced the custom feed loader and parser with a YQL data store. So YQL now loads and parses the feeds. Additionally, we implemented the custom Add feed form with the new qooxdoo form handling. This gives us full validation support out of the box. Want to see the changes? Go and take a look at the current devel version.

APIViewer

APIViewer now supports child controls. These are sub-widgets of a complex widget, e.g. the the slide-bar and pane stack of a TabView widget, or the up and down buttons on a Spinner. This is interesting for anyone developing a custom theme, in order to be able to refer to these child controls and style them. Other use cases include developing classes derived from qooxdoo widgets, working with the Inspector on an application, or constructing qooxdoo locators for Selenium tests. Child controls expose the inner structure of a complex widget. That's why we've added this information to the APIViewer, where it can be found at the very bottom of a class' documentation (e.g. see the TabView widget).

Bugs

As always, here is the usual list of recently resolved issues.

Internationalization (I18N)

this.tr() and friends now allow the use of arbitrary expressions as their messageId argument which has to evaluate to a proper string at run time. That means you can use variables and function calls in those arguments. But as the value of those expressions is opaque to the generator when generating .po files they will be skipped for that purpose. Mind, though, that in order to have translations for those keys in the running app, you still have to provide the possible keys as literals somewhere in your code as an argument to a translation method (e.g. .marktr()). E.g. something like this will now work:

  var s = this.marktr("foo");
  qx.ui.form.Button(this.tr(s));

This allows you to maintain your translatable string literals out-of-line (e.g. in a separate class), and just retrieve them in some way in the code section that actually requires the translation. As a little treat, generate.py translation -v (verbose output) will now print the percent translated of the involved .po files.

Community

Two great qooxdoo use cases hit the mailing list this week.

Chat Service

Ilkka Oksanen wrote in to announce MeetAndSpeak. MeetAndSpeak is a web chat solution with a qooxdoo-based client. There is an introductory video online at MeetAndSpeak's web site, as well as a chat group for qooxdoo .

Sprite Engine

Heiko Stübner got interested in sprite-engines, and came out with a jazzy qooxdoo solution. He writes:

After reading about the "aves-engine" (http://www.dextrose.com/projekte/aves-engine) I wanted to try making something similar and began creating a sprite-engine based on qooxdoo. During a research-phase I found the gamequery library for jquery and a complex example called superjavascriptfighter. To get a feeling and the basics right I wanted to reimplement it based on my qooxdoo-sprite-engine.

So let me present SuperQxFighter ( http://www.sntech.de/superqxfighter.html ).

Some background:
The game-logic is only a reimplementation of the gamequery-demo so I can't take credit for it . The sprites are siblings to qooxdoo widgets (like the webwidgets shown before) and hopefully really lightweight. I haven't tested it on anything but Firefox yet, so expect breakage in other browsers. The underlying engine is far from finished but able to run the demo.

That wraps it up for this week - be in touch next time.



Hi all,

just for the records: The major achievement of this week is the release of versions 1.1 and 1.0.2 of qooxdoo . I hope you all caught the announcement, and are merrily making your way through software and docs. Check out the roadmap to see the future planning.

For those working with qooxdoo SVN check-outs: The 1.1 version is continued in trunk, working towards a 1.2, but there has also a 1_1_x branch been created where the next maintenance release will be prepared (Have a look at our release scheme if you want to see the rational behind it).  You guys might also be interested in the list of this week's bug fixes.

Have a good day!