But the best part is: Chrome Beta also supports the CSS properties overflow:auto and position:fixed, which are essential for mobile HTML5 apps. Seems like Christmas is in February this year for all mobile developers.

qooxdoo mobile works out of the box with the new browser. Overall Google has done a great job with Google Chrome Beta for Android. Let's hope that Chrome will become the default browser for Android soon. Right now, even as a beta, it's better in all tested scenarios than the default Android browser.

The framework now offers two new classes, one for the CSS implementation and one for the JavaScript implementation. Both can be accessed through a single interface which has taken the place of the old CSS only implementation. Just take a look at the following code snippet to see how it can be used.

var button1 = new qx.ui.form.Button("Click to move");
this.getRoot().add(button1);
 
var move = {duration: 500, keep: 100, keyFrames : {
  0: {left: "0px", top: "0px"},
  100 : {left: "200px", top: "50px"}
}};
 
button1.addListener("execute", function() {
  var el = button1.getContainerElement().getDomElement();
  qx.bom.element.Animation.animate(el, move);
});

The first two lines are basic code for adding a button to the application. The next section defines the animation and is the most interesting part. Over the time of 500ms, the animated element should move from 0px / 0px to 200px / 50px and stay there. In the third section, we start the animation on the button itself. As you can see, we need to get the appropriate DOM element for the animation because it's based on DOM elements and low level usage. This also shows the next development steps for this feature: Bringing a good API to the widget level for widget animation. This works in both scenarios, whether CSS animations are supported or not. You don't have to worry about that.

But before moving on, we want to encourage you to give it a try and see how far you can go with it. Take a look at the API documentation and see details of both implementations and feel free to give us feedback.

Bugfixes

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

Have a nice weekend.

Source code? In my API Docs?

It's more likely than you think, thanks to a new feature in the API Viewer. You just need to define the base URI for your SCM's web view (e.g. GitHub, ViewVC, ...) in your library's Manifest.json file and the API Viewer will automatically add links to the source file for each class. For functions, the link can optionally include a line number parameter, so the source view can jump straight to the implementation. See the API viewer manual page for details.

Bugfixes

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

C U around next time.

Bugfixes

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

C U again next time.

There are more individual posts about community projects and real-life app examples to be published in the future, so stay tuned.

Bugfixes

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

C U.

In traditional client-server development...

Traditional web-based client-server application development has been accomplished in two separate pieces: the frontend portion which runs on the client machine has been written in HTML and JavaScript; and the backend portion which runs on the server machine has been written in PHP, ASP.net, or some other "server-side" language which typically interfaces to a database. The skill sets required for these two pieces are different, meaning that sometimes the frontend and backend are developed and tested completely independently, based purely on an interface specification. More recently, server-side JavaScript has begun to gain momentum, allowing for more overlap of skill set, but still requiring separate development and testing of the frontend and backend pieces.

Be LIBERATED from those hassles!

LIBERATED is a new methodology for web-based client-server application development, in which a simulated server is built into the browser environment to run the backend code. This allows the frontend code to issue requests to the backend in either a synchronous or asynchronous fashion, step, using a debugger, directly from frontend code into backend code, and to completely test both the frontend and backend portions. That exact same backend code, now fully tested in the simulated environment, is then moved, unaltered, to a real server. Since the application-specific code has been fully tested in the simulated environment and moves unchanged to the server, it is unlikely that bugs will be encountered at the server that did not exist in the simulated environment.

Be LIBERATED!

LIBERATED is a fully in-browser client and server web application debug and test environment, and qooxdoo-based backend environment. It allows (but does not require) you to write all of your code, both client- and server-side, in JavaScript, using qooxdoo coding style. It has a database abstraction layer, with existing database drivers for App Engine's object datastore and SQLite's SQL-accessed relational database. Additional database drivers can easily be written. There is also a built-in JSON-RPC Version 2.0 server. Additional handlers, such as REST, could be implemented for use instead of or in addition to JSON-RPC.

The real benefit of LIBERATED is that it allows the entire application, both frontend and backend, to be debugged and tested fully within the browser environment, running the backend code in the LIBERATED server simulator. This means you can set breakpoints with Firebug in your backend code, step through to find bugs, etc. Once all of your code is fully debugged and tested in the simulated environment, you simply move the backend code, generally with no changes, to the real server.

Architecture

The figure above shows the architecture of the development and production environment when developing with LIBERATED. The frontend code runs on the client machine (i.e., in the browser). Backend code runs on a server machine and/or on the client machine, with the exact same application code ("business logic") and application communication protocol, e.g., JSON-RPC, REST, etc., code in both environments. The actual database differs in the two cases, but the application's interface to the database is identical regardless of which backend is in use. Similarly, the application communication protocol code is the same regardless of backend, but the messages arrive from web servers unique to the backend, for parsing.

Further details

LIBERATED is simply a "library", in qooxdoo parlance. It is installed like any qooxdoo contrib or other library by referencing its Manifest.json file in the application's config.js "libraries" section. LIBERATED currently runs in App Engine or with the Jetty web server.

As to using it, LIBERATED is described in excruciating detail in Derrell's thesis. Although that document uses the current name of the library (LIBERATED), it predates the renaming of the namespace, so anyplace you see rpcjs in the document is now called liberated.

The API documentation should be quite complete, so running ./generate.py api from the top level will provide the normal API viewer with a fair amount of useful information. In particular, for database manipulation, see liberated.dbif.Entity. Some additional and better user-level documentation would definitely be useful, and might be added over time. Derrell invites you to get familiar with LIBERATED and appreciates your feedback.

The new year is taking up slowly, with a couple of colleagues still away from the office. But, lo and behold!, we got some news to share nevertheless.

qooxdoo Book

We are happy to report that the first dedicated text book on qooxdoo has materialized . Rajesh Kumar Bachu and Mohamed Raffi have written the qooxdoo Beginner's Guide, published by Packt Publishing. Thank you, guys! It focusses on RIA development and takes the reader through all the stages, from the basic OO foundations, over widgets, containers and layouts, to backend communication, theming and custom widgets, featuring a Twitter application for the demonstration. It covers qooxdoo version 1.4, but should be helpful for anybody starting with qooxdoo, even with the current 1.6 kit. If you ever longed for a comprehensive introduction into the qooxdoo framework in book form (one of those three books you would carry onto the island ), by people coming from the application development field, this book should be interesting.

Changes in rest.Resource

In qooxdoo 1.6, the body of a request sent by invoking a resource’s action included all parameters not associated to a URL placeholder. This works when the service expects URL encoded parameters or JSON, but the automatic distribution of parameters also has its limitations. For instance, it is not possible to populate the request body with an array (or any kind of none namespaced value). Therefore, we decided to introduce another parameter to invoke() and associated methods which allows to set the request’s body directly. For better consistency, we dropped the automatic distribution, so if you've been relying on it please make sure to split the parameters. For more details, please refer to the API doc.

Bugfixes

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

Github via SVN

Since we switched to Github for our main qooxdoo repository we recommended the "old-ish" SVN gateway that Github offers (svn.github.com), for those that used to follow our old SVN trunk and that were not ready to jump boat and embrace Git as their client VCS. Although there were new offers for SVN access from Github at that time, we found that the new interface was less reliable and often a lot slower. Meanwhile, Github has been busily working on the new interface, and recent tests show that the new interface is performing much better, even being faster than the old. So, if you are stuck with reading qooxdoo sources through SVN for the time being, you may want to give the new interface another try. Please report back how it is working for you.

To recap, here are the two interfaces again:

old: svn co http://svn.github.com/qooxdoo/qooxdoo.git
new: svn co https://github.com/qooxdoo/qooxdoo/trunk

The new interface also features checking out branches or subpaths of the repository.

Real-life Example: MeetAndSpeak

MeetAndSpeak is an advanced but lean chat tool for groups. It is currently completely free for everyone to use. The user interface mimics classic desktop IRC clients.

Included are secure HTTPS connections, logging and always online functionality. Users can't miss messages. The creator of a group has full control over it. It is also possible to use MeetAndSpeak as an IRC client, connections to Freenode and IRCNet networks are possible. The main view is window-based and allows the user to easily follow several parallel discussions in different groups.

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

Regression in 1.6

Just after the 1.6 release, we discovered a bug that slipped through testing. To our knowledge only Opera is affected. And only if the method getStackTraceFromError() is being used, which mainly happens in a development/debugging context, typically not in a regular app context. Due to these special preconditions, we decided this did not warrant a bugfix release. Please let us know if you notice this problem in the deployment version of an application.

Now for some detailed information: As mentioned above, it affects qx.dev.StackTrace.getStackTraceFromError: This method will throw an exception if called with a qooxdoo exception object (qx.type.BaseError, qx.core.WindowError, qx.core.GlobalError or qx.dev.unit.RequirementError) in a browser that supports the stacktrace property on error objects - apparently only Opera.

Bugfixes

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

That's it for today. C U again next week, then already close to Xmas.

Releases

qooxdoo 1.6 and the accompanying patch release qooxdoo 1.5.1 shipped on Wednesday as planned. We hope you enjoy both releases, particularly version 1.6 with all the great new features.

The ramp-down towards the releases was again quite smooth. Many things keep paying off: the well-structured, agile development process, continuous QA with tons of unit tests and GUI simulations, intermediate manual app tests, efficient bug triage, a strong team performance and last but not least the collaboration with a great community of contributors, bug reporters and users. Thanks again to all of you for your support!

Support

Talking of support: As a community member you can do your share to support the project even more with some public statements and votes. For instance, leave a comment at the announcement, (re-)tweet at Twitter or "like it" on Facebook. Additionally you could vote or comment at the following social sites: Digg, reddit, Echo JS or Hacker News.

You'll certainly have your own ideas on how you spread the news to other JS enthusiasts and web developers. Your help in promoting the new framework releases is much appreciated, thanks.

Kameleoon

Jean-Noël Rivasseau let us know about a slick new web application based on qooxdoo: Kameleoon Analyst. From the application summary:

"Kameleoon is a web intelligence solution that allows marketers to improve their conversion rates through A/B testing. First, you easily create variations of your website. Then these variations are randomly presented to your website's visitors. Eventually, each variation's performance is measured using accurate statistics. Our approach takes out the technical complexity of creating variations for testing: everything can be done via a JavaScript layer, without ever touching the server-side code. A marketing team is thus free to conduct A/B tests without worrying about the technical details."

Kudos, Jean-Noël!

It has been a busy but also very successful week. Have a nice weekend, and have fun with the latest qooxdoo versions!