Eclipse Databinding and QxWT

If you followed my blog closely you already know that I invested some time into makeing Eclipse Databinding available for GWT (as part of the Eclipse UFaceKit project) and because I couldn’t find a GWT-UI-Library who suited my needs I started on writing a GWT wrapper for Qooxdoo.

In my last blog entry I show a very minimal example of a UFaceKit-TableViewer. One of the major problem of the code base by then was that I had to load myriads of small tiny JavaScript files which made the start up extremely slow and unusable in a none local environment.

Though I haven’t solved the problem completely I improved the situation by using the YUI-Compressor and merging the all necessary files into as few as possible (I ended up with 6 yet). This still makes the download around 1MB (which is cached by the browser once loaded) so still a “bit” too high but for Intranet Applications acceptable.

Besiding doing this necessary downsizing of the download size I also improved the UFaceKit-Viewer support and implemented some databinding properties to observe some standard widget attributes (currently only text attributes of various widgets).

Example code

So time to show of some demo and the accompanying code. Let’s at first take a look on the following screencast I created:

It’s a simply application but it the important thing is to see how it is created.

The first important thing when it comes to databinding an GWT is that we need a domain object which informs us about attribute changes. In case of Java and Eclipse one has 2 main choices:

JavaBeans(tm) with reflection and PropertyChangeSupport

EMF with it’s reflective EObject-API and Adapter

where I would preferr the latter.

The problem in GWT is that one can’t use the JavaBeans because of the (out of the box) missing reflection support nor one can use EMF because there’s no port available yet (long ago I worked on such a thing but its simply a very huge task) but there’s a very minimal EMF-like domain model implementation named UBean (part of the UFaceKit project) which provides a similar reflective API than EObject does.

At the moment one has to hand craft those UBean classes but in future I want to provide a JET-Template to generate them from your Ecore-Model. The complete domain model has 2 more classes named Account and Mail.

The UI itself is made up from 3 classes until now:

UMail: Which is simply the Application with its main start point

MailFolderPart: Representing the Accounts and the folders as a Tree

MailDetailPart: Representing the MailFolder contents and displaying the mail content

I think it’s not really a miracle what the code above this. It simply splits the main window area into 2 parts so let’s take a look at the second class which makes up the left hand side folder structure.

This code is a bit longer but in the end for those familiar with Eclipse Databinding and JFace it should look quite straight forward:

Line 18 – 66: Creates a TableViewer and binds the detail list (=list of mails) of the selected folder to it and observes the current selection to bind their detail values to the controls afterwards

Line 68 – 196: Binds labels and widgets using QxWidgetProperties and UBeanObservables

UFaceKit Development

A new homepage is available which is going to example backgrounds and more about UFaceKit.

Licenses
I was not sure about this in my last blog so here’s the current status:

Qooxdoo-Wrapper: Released under EPL

Eclipse Databinding, Viewer and UFaceKit-API: Released under GPLv3 and UFaceKit.org Commercial License

The decision not to release everything under EPL made is necessary to setup my own server with SVN and a bug tracker. Beside the current code available already yet there’s much more we are going to provide which is currently on my workstation.

Give a try yourself

All code shown is available from the above mentionned Subversion repository but if you are not familiar with setting this up you can give it a try your own here (Please note that as mentionned above there’s still ~1 MB JS-code so application startup could be better)