The week in qooxdoo (2013-06-14)

Manual Search Improved

Until now the manual search (input field in the right upper corner) didn’t find words with dots (e.g. “qx.Class”) or hyphens (e.g. “watch-files”) which unfortunately prevented many search matches. With a small adaption of the search index generation we achieved much better search hits.

So if you now search for qooxdoo terms like “config.json” you get all the matches you’d expect. We fixed this also in previous realeases up to qooxdoo 2.0.

Also mind that if you search for upper case words exclusively (e.g. “FILENAME”) and get no results try to search lower case too. Due to a Sphinx (the documentation generator we use) issue it may be that you get more results when searching via lower case (and then finding the upper case word(s) too). As long as this issue exists we always lower case your search terms in the upcoming manual versions.

Bugfixes

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

The week in qooxdoo (2013-06-07)

Welcome to the weekly status update.

Using REST on Websites

Representational State Transfer (REST) is a popular architectural style, well-suited for elegant client-server communication. qooxdoo has been providing extensive REST support for quite some time already, most notably since shipping a comprehensive REST layer in qooxdoo 1.6. Now it has been made easier to let website-oriented applications work with resources and utilize the best of REST communication. See the recent blog post about the new REST module to be included on websites or low-level applications, respectively.

Contribution Catalogue

As another step towards an improved environment and workflow for user contributions to qooxdoo, a basic “qooxdoo-contrib 2.0″ infrastructure is in place. There have already been announcements and valuable feedback from the community in the last few weeks. Along those lines much progress has been made, so check out the recent post, which has all the relevant points. We keep looking forward to your feedback.

Bugfixes

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

Have a nice weekend.

qooxdoo-contrib 2.0 Rollout

The basic qooxdoo-contrib 2.0 infrastructure is in place. Referring back to the announcement a few weeks back,  here are the relevant points:

  • Catalog The new catalog repo is online.
  • Tool Chain The Generator has been adapted to use this catalog for contribution lookup.
  • Availability The changes are available with recent master, and will make it into the upcoming 3.0 release.
  • There are no plans to backport this solution to older qooxdoo versions. Previous SDKs will continue to work against the old Sourceforge SVN repository. There is no easy patching of the ContribLoader.py in older SDK’s (like with the recent Allura upgrade of the repo).
  • contrib:// URLs In contrast to the announcement we will continue to support the contrib:// pseudo URL scheme to trigger catalog lookups. But besides that directly linking to a catalog entry’s meta information (i.e. its Manifest.json) via HTTP is also supported.
  • This means that users of contributions do not need to change their configurations in general (provided the contributions they are using have proper catalog entries). With the new system the contributions should continue to work seamlessly.
  • Documentation Documentation is available in the upcoming manual.
  • Existing Contributions – Maintainers Many of the existing contributions from the SF repo have been imported into the new catalog, i.e. all that already have a Manifest.json. This was just to let existing applications continue to build, and is not meant as a general limitation.
  • Imported Contribs Those catalog Manifest.json’s have been augemented to hold additional necessary keys (like info/download). Mind that the automatic process has shuffled around the keys of the Json structure in these files, don’t be baffled. They have also gotten empty info/checksum and info/category fields. checksum is not necessary as a version number is retrieved from SVN. The category field should be filled eventually, but we have yet to release a list of recognized categories.
  • If you maintain an existing contribution please check the corresponding entries in the catalog and amend them where necessary. See the manual for how to do that, it’s basically a fork-and-pull process on Github.
  • This also applies if you already maintain your contribution outside the old SF repo. I created some sample catalog entries to show how they may look. Please go about adding your contributions, that’s what we started the whole thing for.
  • Web Interface In this process please also revise contribution entries in the Available Contributions wiki page, and any potential contribution homepage.
  • We plan on adding a web-based interface to the catalog soon (which shall eventually replace the Available Contributions page).
  • Existing Contributions – Users If you are working with qooxdoo’s Git master and use contributions in your project, you can safely pull the recent changes. Your applications should build and work as before, no intervention required on your side.
  • If you run into problems, check the catalog entries for the contributions you use in the catalog repo, maybe there is a spelling mismatch in the name or the version of the contrib, or a particular version has not been entered in the catalog yet. In these cases get back to us or the contribution maintainer.

Utilizing REST with qx.Website

If you take a look at web APIs and the web service landscape nowadays you’ll notice that the predominant architectural style is REST (Representational State Transfer).

qooxdoo helps you utilize REST with our REST layer (qx.io.rest.Resource), which can be used to work against RESTful web-services in an elegant way. That means rather than requesting URLs with a specific HTTP method manually, you can define resource objects and invoke actions upon them. Our REST manual page explains this in greater detail.

Until now the REST layer was not available within qx.Website but this has changed. In order to provide the same functionality that qx.io.rest.Resource offers we had to introduce another Resource class: qx.bom.rest.Resource. This enabled us to change the API slightly where needed (i.e. smaller dependency footprint) while staying backwards-compatible (unchanged API for qx.io.rest.Resource).

So here is a small example of the usage of qx.bom.rest.Resource:

q.ready(function() {
  var resourceDescription = {
    "get": { method: "GET", url: "http://example.org/resources/{name}" },
  };
  var resource = q.rest.resource(resourceDescription);
  resource.on("getSuccess", function(e) {
    console.log(e.response);
  });
  resource.on("getError", function(e) {
    console.log(e.response);
  });
  resource.get({"name": "sample"});
});

This functionality is now available in the devel version of q (i.e. qx.Website) which is available in the download section (look for q-devel.min.js). If you want to dive deeper check out the qx.Website API documentation also.

The rest of this article simply goes into detail how qx.bom.rest.Resource differs from qx.io.rest.Resource – which is mainly interesting for those who already used the old one and want to try the new one within qx.Website:

  • The event object available in the listeners (e.g. success(), getSuccess() and getError()) is a native JavaScript object instead of a qooxdoo object (qx.event.type.Rest).
    • qx.io.rest.Resource vs. qx.bom.rest.Resource
      event.getId() => event.id
      event.getRequest() => event.request
      event.getAction() => event.action
      event.getData() => event.response
      event.getPhase() => --- (see below)
  • Methods which allow manipulation of the request (e.g. configureRequest()) will operate on an instance of qx.bom.request.SimpleXhr instead of qx.io.request.Xhr (the API is similar but not identical)
  • poll() returns no qx.event.Timer object. There are two new methods (stopPollByAction() and restartPollByAction()) available at qx.bom.rest.Resource which replace the functionality provided by the Timer object.
  • The phase support, which is a more elaborate version of readyState, is not available. So use readyState instead.
    • Phases (available only in qx.io.rest.Resource):
      • unsent, opened, sent, loading, load, success
      • abort, timeout, statusError
    • readyState (available in qx.bom.rest.Resource and qx.io.rest.Resource):
      • UNSENT
      • OPENED
      • HEADERS_RECEIVED
      • LOADING
      • DONE

We are looking forward to your feedback.