QxWT 1.0.1.0-rc1 and other cool stuff

As the blog title suggest I’ve uploaded a first release candidate for the QxWT 1.0.1.0 which is going to be released on about a month.

The most important new features coming with this release:

  • Postprocessing to use qooxdoo toolchain
  • Support for Databinding

Beside this I am in need of a browser charting library and played around a bit with Raphael this weekend which also has a very tiny charting module which is released under MIT. Because of my QxWT-work I’m quite good now in writing JSNI-Wrappers and so I did that for Raphael. You can look at the result of this here.

The wrapper is released under EPL and LGPL and I guess QxWT will in cooperate this library in 1.0.1.0.

Looking back and into the future – First conclusions

I admit I’ve been depressed a bit after having looked back to year 2009 because making the summary showed that I failed in most of my Eclipse “Jobs”. Until then I’ve had a lot of fun working on OpenSource projects but still the question remains how to do a better job in 2010.

My current belief is that I tried to help in my spare time at too many places and this has to change so that looking back on to 2010 is better than it’s been to the last year.

Here are the first 2 action items

  • Action-Item 1: Unsubscribe from newsgroups. Hard but saves me about 1 hour a day answering questions on platform, swt, jface newsgroups. To me it’s an imporant task every committer has to fullfill but because of action item 2 I’m not in charge of this any more.
  • Action-Item 2: Those of you who are attached to the ~80 platform bugs I owned might already received a mail. I plan to step back as a platform-ui-comitter after EclipseCon. This is one of the really hard decision because getting the comittership on the platform was the door opener for me to the Eclipse Ecosystem but when looking back to the last year I’ve the feeling that I don’t deserve the committer status any more and owning bugs I’ve no time nor business use case for is harming more than it helps.
    • A strange thing is that I lately had discussions with different people who stated that they wanted bring in stuff into the platform (or require bugfixes) but failed because none of the committers had enough time to work with them on their contribution. I told them and repeat it once more that I’d be willing to help them but don’t have the resources to do so.

      My current hope is that I can find my way back into e4 development but if I see me failing there as well in the next 2 months I guess I’ll also step back from my committership there also (though I also believe that some things I’d like e4 come with e.g. flexible modeled workbench loading e.g. from CDO won’t be available in 1.0 then).

QxViewers – The first steps towards a UFaceKit-Webport

I’ve talked a lot (1,2,3,4) lately about my progress on QxWT towards release 1.0.0.2. Now that all the codeing is done more or less I can restart working on my master plan:

Single APIing for Web and Desktop programing use Eclipse Libraries like Eclipse Databinding – In short UFaceKit

Having completed the SWT-Port more or less since some time, having portotype implementations for Qt and Swing (to check if the concept can be transfer easily to other Desktop-UI-Frameworks) the missing thing is a port for a Web-UI-Framework.

The problem is in the Web/GWT-UI space that GWT itself comes with a very restricted UI library missing important things like Table/TreeTables for example and one needs an external framework. I couldn’t find a framework that fully satisfied my needs (most important a clear, reliable license scheme allowing me to use it in commercial applications) so I started my work on QxWT and now that this framework enters in a stable phase I can once more shift sources back to UFaceKit.

To get to a first UFaceKit-Webport I have the following workitems:

  1. Done: Eclipse Databinding 3.5.2 for GWT – (no builds until Eclipse 3.5.2 itself is declared)
  2. In progress: UFaceKit-Viewers for QxWT-Structured-Controls – this gives automagically support for ufacekit-viewers-databinding because UFaceKit-Viewers are split in generic and widget-toolkit parts and ufacekit-viewers-databinding only talks to the generic part
  3. Not started: UFaceKit-Wrapper for QxWT – the thoughest thing might be to write write the native layouts

As the blog title suggests I’ve made good progress today and I can show off the first demo results from this work. The implementations are not finished yet but for people who are familiar with JFace-Viewers lines like the following might look familiar (beside the obvious Java5 features of UFaceKit-Viewers):

/** 
 * Combo Viewer Setup
 */
ComboViewer<Person, Collection<Person>> viewer = new ComboViewer<Person, Collection<Person>>();
viewer.setContentProvider(new CollectionContentProvider<Person>());
viewer.setLabelConverter(new LabelConverter<Person>() {
  @Override
  public String getText(Person element) {
    return element.getFirstname() + ", " + element.getLastname();
  }
});

Collection<Person> ps = new ArrayList<Person>();
for (int i = 0; i < 300; i++) {
  ps.add(new Person("First " + i, "Last" + i, i));
}
viewer.setInput(ps);

/**
 * TableViewerSetup
 */
TableViewer<Person, Collection<Person>> tableViewer = new TableViewer<Person, Collection<Person>>();
tableViewer.setContentProvider(new CollectionContentProvider<Person>());

TableViewerColumn<Person> col = new TableViewerColumn<Person>(tableViewer, "Firstname");
col.setLabelConverter(new LabelConverter<Person>() {
  @Override
  public String getText(Person element) {
    return element.getFirstname();
  }
});

// ...
Collection<Person> ps = new ArrayList<Person>();
for (int i = 0; i < 300; i++) {
  ps.add(new Person("First " + i, "Last" + i, i));
}
tableViewer.setInput(ps);

/**
 * TreeViewer setup
 */
TreeViewer<Person, Collection<Person>> viewer = new TreeViewer<Person, Collection<Person>>();
viewer.setLabelConverter(new LabelConverter<Person>() {
  @Override
  public String getText(Person element) {
    return element.getLastname() + ", " + element.getFirstname() + " ("+ element.getAge() + " years)";
  }
});

viewer.setContentProvider(new ITreeContentProvider<Person, Collection<Person>>() {
  public Collection<Person> getChildren(Person parentElement) {
    return parentElement.getChildren();
  }

  public Person getParent(Person element) {
    return element.getParent();
  }

  public boolean hasChildren(Person element) {
    return element.getChildren().size() > 0;
  }

  public void dispose() {
  }

  public Collection<Person> getElements(Collection<Person> inputElement) {
    return inputElement;
  }

  public void inputChanged(IViewer<Person> viewer, Collection<Person> oldInput, Collection<Person> newInput) {
  }
});
viewer.setInput(setupData());

The widgets look like this:

I’d like to point out once more that UFaceKit is structured in a way that you can use all parts independently from each other. So if you are in need to a Databinding-Framework for GWT and a light weight Domain-Technology like UBean then you can use them, you only need Java5 ready viewers for SWT and Databinding integration, … all of them are useable standalone with minimal dependencies.

Beside that I’m still struggeling with setting up a build for the SWT-Port on the Eclipse-Servers so that people can start consume stuff from there but that’s a problem many small project suffer.

e4@JUGS

Yesterday I presented e4 to members of the JavaUserGroup Schweiz. There’ve been 80+ people (I was told that this was the highest number of participants ever taken part in Special Interest Group talk).

I’d like to thank Edwin Steiner from inventage for giving me/us the possibility to present e4 to a interested group of people. I think the talk ones more was quite well received (which was every talk I gave about e4 in the last year BTW).

The slides I used in my presentation can be downloaded from here.

QxWT explained Part 4

In the last 3 blog entries (part 1, part 2, part 3) we concentrated on generating JavaScript code using the GWT-Compiler integration and Java-Annotations. In this blog post we’ll concentrate on something completely different.

One of the major problems of JSNI-Wrappers for JavaScript libraries is that you always have to deliver the complete JavaScript-framework though you probably don’t need vast parts (e.g. your application doesn’t use a Tree-control so why still sending out the JS-Code for tree creation?).

A nice feature of the qooxdoo-library is that it comes with a toolchain which analyzes your code dependencies and creates an optimized js-Files for you only holding the code and classes you really need (please note this is still not as good as GWT because GWT even strips out methods you are not calling).

The task now is that we need to teach QxWT to spit out informations about which Java-Classes are used in your application and collect somewhere which JavaScript-class(es) those are related to.

Step 1: Is once to define an annotation:

/**
 * This holds meta informations about JS-Resource-Files required by this class
 */
public @interface QxJsResource {
  /**
   * @return list of qooxdoo javascript resource files
   */
  String[] jsResourceFiles();
}

Step 2: make the GWT-Generator regonize those meta information

Well the GWT-Generator only steps in when creating a Class-Instance using GWT.create() which is a bit of a problem for us because this would required that people create widget-classes like this:

QxLabel l = GWT.create(QxLabel.class);

instead of

QxLabel l = new QxLabel();

beside that inconvenience the second problem is that this concept assumes that there’s a no-arg constructor which is not available always in QxWT and there are even static classes which are not instantiated at all. This means we need to find some other way to make the GWT-Generator to kick in.

The only solution I came up with was to create an inner class, call GWT.create() in an static-init block like this:

public class QxAtom extends QxWidget {
  @QxJsResource(jsResourceFiles={ "qx.ui.basic.Atom" })
  private static class I extends QxJsResourceBuilder {
		
  }
	
  static {
    GWT.create(I.class);
  }
}

Step 3: Collect informations in a GWT-Generator

The information we provide through the annonations have to be collected by a generator which and passed on to the GWT-Linking chain where we can access them and spit out a bootstrap class we can feed into the qooxdoo-Toolchain.

The Generator looks like this:

public class QxToolchainGenerator extends Generator {
  /**
   * {@inheritDoc}
   */
  @Override
  public String generate(TreeLogger logger, GeneratorContext context,
    String typeName) throws UnableToCompleteException {

    try {
      QxJsResource resource = context.getTypeOracle().getType(typeName).getAnnotation(QxJsResource.class);
      for( String jsFile : resource.jsResourceFiles() ) {
        QxToolchainArtifact art = new QxToolchainArtifact(jsFile);
        context.commitArtifact(logger, art);
      }
    } catch (NotFoundException e) {
      throw new UnableToCompleteException();
    }
    return null;
  }
}

The trick here is to generate a so called linker artifact we can pass on to the linker chain and plug in ourselves there with a class like this:

@LinkerOrder(Order.PRE)
public class QxToolchainLinker extends AbstractLinker {
  /**
   * {@inheritDoc}
   */
  @Override
  public String getDescription() {
    return "QooxdooToolChain";
  }

  /**
   * {@inheritDoc}
   */
  @Override
  public ArtifactSet link(TreeLogger logger, LinkerContext context,
    ArtifactSet artifacts) throws UnableToCompleteException {

    ArtifactSet toReturn = new ArtifactSet(artifacts);

    StringBuffer buf = new StringBuffer(template_1);

    for (QxToolchainArtifact e : toReturn.find(QxToolchainArtifact.class)) {
      buf.append("#require(" + e.getQxClassName() + ")\n");
    }
		
    buf.append(template_2);

    // Add a new artifact to the set that we're returning.
    toReturn.add(emitString(logger, buf.toString(), "class/qooxdoogwt/Application.js"));

    return toReturn;
  }
}

This generates the main-Application file used by qooxdoo as the start of an application (similar to class with the main-Method on your Java-Application). We add all collected information to this class using a special meta-data tag “#require” recognized by the qooxdoo toolchain.

Step 4: Call the qooxdoo tool chain

Calling the qooxdoo toolchain is not a very hard task but it still involves some steps you need to follow to use it with our QxWT-Project. That’s why QxWT 1.0.0.2 will come with an extra build-project which provides you with an ant-file to create an deployable QxWT-Application.

One only have to define in 2 parameters:

  • qxproject.name: the project name
  • qxproject.source: the project source directory

For my QxDemo-Project the call looks like this:

ant build.xml -Dqxproject.name=QxDemo -Dqxproject.source=/Users/tomschindl/ws/ufacekit/QxDemo

QxWT explained Part 3

I continue the blog post series (Part 1, Part 2) about the internal of QxWT by describing how one can even extend qooxdoo-JS-classes using the GWT-generator features without writing a single line of JavaScript-code.

In the last blog entry we learned how to define a qooxdoo-JS-Class from scratch which was quite an easy task and so is the extending of qooxdoo classes. The idea is that we need to generate code which overloads an existing qooxdoo-class method and delegate the method call to our JavaCode.

Let’s take a look at an qooxdoo-example at first to see how extending a class and changing it’s behavior is done in “native” code. A good example is the JsonStore which makes it very easy to work with JSON-Datasources in qooxdoo.

A problem though is that if you need to load the data from an URL which is different than the one our application is coming from you can not use the JsonStore coming with the qooxdoo-framework but need to extend it so that the requested is done differently.

In plain qooxdoo a specialized JsonStore which e.g. connects to twitter looks like this:

qx.Class.define("demobrowser.demo.data.store.Twitter",
{
  extend : qx.data.store.Json,

  statics : {
    saveResult: function(result) {
      this.__result = result;
    }
  },

  construct : function(user)
  {
    var url = "http://twitter.com/statuses/user_timeline/" + user + ".json";
    this.base(arguments, url);
  },

  members :
  {
    _createRequest: function(url) {
      var loader = new qx.io.ScriptLoader();
      url += "?callback=demobrowser.demo.data.store.Twitter.saveResult";
      loader.load(url, function(data) {
        this.__loaded();
      }, this);
    },


    __loaded: function() {
      var data = demobrowser.demo.data.store.Twitter.__result;

      if (data == undefined) {
        this.setState("failed");
        return;
      }

      // create the class
      this._marshaler.toClass(data);
      // set the initial data
      this.setModel(this._marshaler.toModel(data));

      // fire complete event
      this.fireDataEvent("loaded", this.getModel());
    }
  }

The above class inherits from the base implementation and overloads the method _createRequest to make a cross domain request. What we want to achive is that the GWT-Generator creates a qooxdoo-class like this:

qx.Class.define("demobrowser.demo.data.store.Twitter",
{
  extend : qx.data.store.Json,
  members :
  {
    _createRequest: function(url) {
      // Delegate to Java
    }
  }
}

The first thing we need is another annotation which makes it possible to declare a Java method to be the delegate of the JavaScript-method:

/**
 * Define a the native method that will call back to this java method
 */
@Target(ElementType.METHOD)
public @interface QxNativeMethod {
  /**
   * @return name of the javascript method
   */
  String name();

  /**
   * @return <code>true</code> if the js method should call the overloaded
   *         method before delegating to java
   */
  boolean callsuper() default false;
}

We can now annotate Java-Methods like this:

@QxNativeMethod(name = "_createRequest")
public void qxcb_createRequest(String url) {
  // Logic written in Java
} 

and our GWT-Generator takes care of generating a qooxdoo-class and delegating method calls to our Java implementation.

Reimplementing the Twitter-JsonStore from above in plain QxWT would look like this:

@QxClass(jsBaseClass = "qx.data.store.Json", properties = {})
public abstract class TwitterStore extends QxJsonStore<Object> {
  private JavaScriptObject result;

  /**
   * @param o
   */
  public TwitterStore(JavaScriptObject o) {
    super(o);
  }

  @QxNativeMethod(name = "_createRequest")
  public void qxcb_createRequest(String url) {
    QxScriptLoader loader = new QxScriptLoader();
    url += "?callback=saveResult";
    VoidParam<String> statusCallback = new VoidParam<String>() {
      @Override
      public void invoke(String value) {
        loaded();
      }
    };
    VoidParam<JavaScriptObject> globalFunctionCallback = new VoidParam<JavaScriptObject>() {
       @Override
        public void invoke(JavaScriptObject value) {
           result = value;
        }
    };

    loader.load(url, statusCallback, "saveResult",globalFunctionCallback);
  }

  private void loaded() {
    if (result == null) {
      setState(State.FAILED);
      return;
    }

    QxModelObject model = QxJsonMarshaler.createModel(result, true);
    setModel(model);

    // fire complete event
    this.fireDataEvent("loaded", this.getModel());
  }
}

The Store can now be used like this:

// fetch some data from Twitter
final TwitterStore store = GWT.create(TwitterStore.class);
store.setUrl("http://twitter.com/statuses/user_timeline/wittemann.json");

Behind the scenes GWT generated the following Java-Class for us:

package org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data;

public class TwitterStore_Gen extends org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.TwitterStore {

  /* Define the native-qooxdoo class and load it when the class is loaded */
  static { defineQxClass(); }

  private static native com.google.gwt.core.client.JavaScriptObject defineQxClass() /*-{
    $wnd.qx.Class.define("qxwt.org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.TwitterStore_Gen",
    {
      extend : $wnd.qx.data.store.Json,
      properties : {

      }
      , members: {
        _createRequest: function(url) {
          this._gwt.@org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.TwitterStore::qxcb_createRequest(Ljava/lang/String;)(url);
        }}
      });
    }-*/;

    /* Create an instance of the native class */
    private static native com.google.gwt.core.client.JavaScriptObject createNativeObject() /*-{
      var rv = new $wnd.qxwt.org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.TwitterStore_Gen();
      return rv;
    }-*/;

    public TwitterStore_Gen() {
      super(createNativeObject());
    }

  }

I think this is once more a nice feature QxWT and GWT is bringing to you because it gives you the power to modify and extend framework classes quite easily without dealing with JavaScript but staying in your wellknown Java environment.

Though we now solved our uses cases from the last blog this blog series will continue because QxWT 1.0.0.2 is going to leverage the extensibility of the GWT-Compiler-Toolchain (GWT-Generator and Linker this time) even more by collecting meta data about the used QxWT-classes and feeding them into the qooxdoo-toolchain to optimize the qooxdoo framework code based upon your projects need. So stay tuned a give QxWT a try by checking out the dev-Demos provided and the source.

QxWT explained Part 2

In my last blog post I started explaining how QxWT adopters get support from us in release 1.0.0.2 (due end of February). We are going more into detail in this blog post.

Let’s once more recap what we are trying to achieve:

  • Generated qooxdoo class for domain model usage (e.g. when working with databinding and forms)
  • Extend exisiting qooxdoo classes

Since the last blog post the I added some more features so let’s look at the Annotations I presented in my last blog:

/**
 * Definition of a Qooxdoo-class
 */
@Target(ElementType.TYPE)
public @interface QxClass {
  /**
   * @return Java super class
   */
  String javaSuperClass() default "org.ufacekit.qx.wrapper.core.QxObject";

  /**
   * @return javascript base class
   */
  String jsBaseClass() default "qx.core.Object";
	
  /**
   * @return the fully qualified class name of the js-class generated
   */
  String jsClassName() default "N/A";
	
  /**
   * @return the properties
   */
  QxProperty[] properties();
}

and the property definition:

/**
 * A property of a qooxdoo object
 */
@Retention(RetentionPolicy.SOURCE)
public @interface QxProperty {
  /**
   * @return name of the property
   */
  String name();

  /**
   * @return the value to check for e.g. String, ...
   */
  String check() default "N/A";

  /**
   * @return the event
   */
  String event() default "N/A";

  /**
   * @return whether property can be null
   */
  boolean nullable() default false;

  /**
   * @return initial value
   */
  String init() default "N/A";
	
  /**
   * @return the class to wrap the init value in 
   */
  String initQxClass() default "N/A";

  /**
   * @return validate function to call
   */
  String validate() default "N/A";

  /**
   * @return the method called when the value is applied
   */
  String apply() default "N/A";
}

The information in the property are the ones one can use to when defining a class property.

We are now ready to address the first use case for and showing you an example how it is used in a demo:
Step 1: Define the domain interface

public interface Person extends IQxObject {

  public String getName();

  public void setName(String name);
	
  public String getEmote();

  public void setEmote(String emote);

  public boolean isOnline();

  public void setOnline(boolean online);

  public void toggleOnline();
}

Step 2: Annotate the interface

@QxClass(properties = {
  @QxProperty(check = "String", event = "changeName", name = "name", nullable = true),
  @QxProperty(check = "String", event = "changeEmote", name = "emote"),
  @QxProperty(check = "Boolean", event = "changeOnline", name = "online", init = "true")
})
public interface Person extends IQxObject {
  // ...

Step 3: Use the annotated interface in your GWT-Application

// names
String[] names = { "Max", "Jakob", "Tim", "Jack", "Dan", "Dustin","Karl", "Jim" };
String[] emotes = { "embarrassed", "kiss", "plain", "sad", "surprise","angel" };

// create the data
Person[] rawData = new Person[20];
for (int i = 0; i < 20; i++) {
  Person person = GWT.create(Person.class); 
  person.setName(names[i % names.length]);
  person.setEmote(emotes[i% emotes.length]);
  person.setOnline(i % 3 == 0);
  rawData[i] = person;
}

Easy isn’t it? Yes it is but how does it work? We’ve never defined a class which implements the Person interface nor there are things like dynamic proxy available in GWT. The important call is GWT.create(Person.class) which triggers the GWT-Generator which allows one to generate Javacode.

In case of the above the code generated looks like this:

package org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.model;

public class Person_Gen extends org.ufacekit.qx.wrapper.core.QxObject implements org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.model.Person {

  
  static { defineQxClass(); }

  private static native com.google.gwt.core.client.JavaScriptObject defineQxClass() /*-{
    $wnd.qx.Class.define("qxwt.org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.model.Person_Gen",
    {
      extend : $wnd.qx.core.Object,
      properties : {
        name: {
          check : "String",
          event : "changeName",
          nullable : true
        },
        emote: {
          check : "String",
          event : "changeEmote",
          nullable : false
        },
        online: {
          check : "Boolean",
          event : "changeOnline",
          init : true,
          nullable : false
        }
      }
    });
  }-*/;

  
  private static native com.google.gwt.core.client.JavaScriptObject createNativeObject() /*-{
    var rv = new $wnd.qxwt.org.ufacekit.qx.wrapper.demo.client.demobrowser.demo.data.model.Person_Gen();
    return rv;
  }-*/;

  public Person_Gen() {
    super(createNativeObject());
  }

  public java.lang.String getName() {
    return  native_getName( getNativeObject() );
  }

  private native java.lang.String native_getName(com.google.gwt.core.client.JavaScriptObject self)/*-{
    return self.getName();
  }-*/;

  public void setName(java.lang.String name) {
     native_setName( getNativeObject() ,name);
  }

  private native void native_setName(com.google.gwt.core.client.JavaScriptObject self,java.lang.String name)/*-{
    return self.getName();
  }-*/;

  public void setName(java.lang.String name) {
     native_setName( getNativeObject() ,name);
  }

  private native void native_setName(com.google.gwt.core.client.JavaScriptObject self,java.lang.String name)/*-{
    self.setName(name == null ? null : name + "");
  }-*/;

  public java.lang.String getEmote() {
    return  native_getEmote( getNativeObject() );
  }

  private native java.lang.String native_getEmote(com.google.gwt.core.client.JavaScriptObject self)/*-{
    return self.getEmote();
  }-*/;

  public void setEmote(java.lang.String emote) {
     native_setEmote( getNativeObject() ,emote);
  }

  private native void native_setEmote(com.google.gwt.core.client.JavaScriptObject self,java.lang.String emote)/*-{
    self.setEmote(emote == null ? null : emote + "");
  }-*/;

  public boolean isOnline() {
    return  native_isOnline( getNativeObject() );
  }

  private native boolean native_isOnline(com.google.gwt.core.client.JavaScriptObject self)/*-{
    return self.isOnline();
  }-*/;

  public void setOnline(boolean online) {
     native_setOnline( getNativeObject() ,online);
  }

  private native void native_setOnline(com.google.gwt.core.client.JavaScriptObject self,boolean online)/*-{
    self.setOnline(online);
  }-*/;

  public void toggleOnline() {
     native_toggleOnline( getNativeObject() );
  }

  private native void native_toggleOnline(com.google.gwt.core.client.JavaScriptObject self)/*-{
    self.toggleOnline();
  }-*/;
}

A lot of code right! So what you are getting back from the call to GWT.create(Person.class) is an instance from this dynamically generated class named Person_Gen (If you are interested how this works you should take a look at QxClassGenerator.java).

The nice thing is that we can now directly use such an instance or list of instances as input for qooxdoo-Databinding:

QxArray<Person> p = QxArray.breed(rawData);
		
final QxDataArray<Person> data = new QxDataArray<Person>(p);
		
// create the widgets
QxFormList<QxFormListItem> list = new QxFormList<QxFormListItem>();
list.setWidth(150);
// add the widgets to the document
container.add(list, QxOption.leftTop(10, 80));

// create the controller
QxListController<Person,QxFormCheckBox> controller = new QxListController<Person,QxFormCheckBox>(null, list);

Delegate<QxListController<Person,QxFormCheckBox>, QxFormCheckBox, Person> delegate = new 
  Delegate<QxListController<Person,QxFormCheckBox>, QxFormCheckBox, Person>() {
    public int delegatesMask() {
      return DEFAULT;
    }
			
    public boolean filter(Person data) {
      return true;
    }
			
    public QxFormCheckBox createItem() {
      return new QxFormCheckBox();
    }

    public void configureItem(QxFormCheckBox item) {
      item.setPadding(3);
    }
			
    public void bindItem(QxListController<Person,QxFormCheckBox> controller,
      QxFormCheckBox item, int id) {
      controller.bindProperty("name", "label", item, id);
      controller.bindProperty("online", "value", item, id);
      controller.bindPropertyReverse("online", "value", item, id);
    }
};
		
controller.setDelegate(delegate);
controller.setModel(data);

This creates an UI like this:

I think this example shows how powerful the GWT-Generator features is. We have now seen how we can use it to solve our first use case and in the next blog post will discuss how the GWT-Generator helps us solve the second use case “Extending existing qooxdoo classes”.

If you’d like to follow my progress towards 1.0.0.2 you can take a look at the extended demos.