GWT vs Flex

We have now some experience with GWT while implementing an enterprise price management system's UI. There are some nice features that GWT provides, but there are a lot of pain also while using some 3rd party widget library, like GWT-Ext. In my mind, the main problem is that while coding the solution using GWT, you loose the feeling of the application (especially if using a wrapper around a native JavaScript library). But this is just my feeing and doesn't really show if GWT is bad or good. Related to the real problems, when we had too many records to render in a data grid, we faced some performance problems - rendering all the records took quite a time and stalled the browser instance until the end of rendering process.
The 3rd issue I find relevant is the amount of code had to be produced for the layout and interactive behavior of the application. The Swing-style coding is a real blocker. IMHO, GWT probably make heavier use of annotations, perhaps even introduce some custom annotations for simplifying the implementation of user actions (i.e. listeners as inner classes).

After we almost finished the prototype, I started to think that probably, GWT is not really what we'd like to use in our application for the UI. I'm still strongly convinced that for this application we need a rich UI to satisfy the user. Adobe Flex was the next technology in our list. More than that, Flex is approved for our internal development by the architects council. So one our colleague presented us how is he using Flex to implement a RIA for loan management.. and smashing!!! I really liked the code separation for the UI: layout is defined in MXML files, events for the UI components are defined in a separate ActionScript files, and some utility code can also be separated into other scripts. Further more, the speed of making a convenient application was really fast. And also the amount of code to be written is much less than with GWT. No layout problems in the resulted swf, rendering a data grid with thousands of rows was just blizzard-fast compared to JavaScript analog.
I found some comparisons of GWT, Flex and Echo2 on the web: one and two

Both GWT and Flex 2 are Rich Internet Application (RIA) frameworks whose code is downloaded and executed on the client side, in the browser. GWT compiles Java code to JavaScript whereas Flex compiles a combination of ActionScript and MXML code to a Flash swf file.

And here's the quote I was waiting for:

...both GWT and Flex 2 have different situation where they each are better suited. HTML, CSS, JavaScript are still the best option when developing a web application intended for the general public. Flex 2 is would fit well when developing flashy business minded applications with a targeted audience.

I think this describes our case the most - a targeted audience.

More Widgets for Guvnor

For properties and XML editors in Guvnor I'm trying to make use of GWT-Ext components. The widgets from this library look really nice. Also the API looks OK. For the properties widget, theres a PropertiesGridPanel available, which provides some nice features for editing the properties (see the screenshot below).



.. and a piece of code that assembles the panel:

PropertyGridPanel grid = new PropertyGridPanel();
GridView view = new GridView();
grid.setView(view);
Map map = new HashMap();
PropertyHolder[] props = getProps(); //RPC call here
for (PropertyHolder holder : props.list) {
  map.put(holder.name,holder.value);
}
grid.setSource(map);

How does it know which editor should be attached to the value column? Simple the type is known at the compile time! One of the benefits of GWT is claimed to be its performance. It is fast, but this power comes at a price - you cannot leave the type undefined, i.e. you cannot use java.lang.Object for the type of your class members.

Consider the following class, which is intended for exchanging the information via RPC calls:

public class PropertyHolder implements IsSerializable {
    public String name;
    public Object value; // coudn't use Object type here
}

While trying to compile this code down to javaScript, we'll get the following messages from the GWT's compiler:

org.drools.guvnor.client.ruleeditor.PropertyHolder
[java] Analyzing the fields of type 'org.drools.guvnor.client.ruleeditor.PropertyHolder' that qualify for serialization
[java] public java.lang.Object value
[java] java.lang.Object
[java] [ERROR] In order to produce smaller client-side code, 'Object' is not allowed; consider using a more specific type
[java] [ERROR] Type 'org.drools.guvnor.client.ruleeditor.PropertyHolder' was not serializable and has no concrete serializable subtypes

So that's it! I couldn't think of any solution how to cheat the compiler and leave the value's type undefined, so I have to use strings for now.

GSOC2008: Rolodex Panel Assembly for Guvnor

In my previous post about integrating rolodex into Guvnor I tried to create the example just with a set of pre-compiled images which are then assembled into drools-guvnor.war. But the real goal is actually to display the pictures stored in Jackrabbit repository for Guvnor.
Now, after some experiments with rolodex and Guvnor, I have a widget where one may upload a picture and display it.


Currently it can accept only one picture per RuleAsset class instance. Therefore the content handler for this asset should be extended to support multiple images per RuleAsset.

RolodexCardBundle images = getImagesFromAsset();
RolodexCard[] rolodexCards = images.getRolodexCards();
if (rolodexCards.length > 0) {
  final RolodexPanel rolodex = 
    new RolodexPanel(images, 3, rolodexCards[0], true);
  layout.addRow(rolodex);
}

I have set the hight of the panel manually as the picture was cropped otherwise in the widget. (Don't know the reason yet). getImagesFromAsset() is used for converting the asset's content to the RolodexCard:

public RolodexCardBundle getImagesFromAsset() {
  return new RolodexCardBundle() {
    public int getMaxHeight() {
      return 200; 
    }

    ClippedImagePrototype clip = new ClippedImagePrototype(
      GWT.getModuleBaseURL() + 
      "asset?" + HTMLFileManagerFields.FORM_FIELD_UUID + 
      "=" + asset.uuid,
       0, 0, 300, 200 );

    RolodexCard card = 
      new RolodexCard(clip, clip, clip, 300, 100, 10);

    public RolodexCard[] getRolodexCards() {
      return new RolodexCard[]{card};  
    }
  };
}

I've cheated with the code that composes the RolodexCard, as ClippedImagePrototype's javadoc says:

This class is used internally by the image bundle generator and is not intended for general use. It is subject to change without warning.

But the implementation of ClippedImagePrototype is actually what I need. Probably, if it is really the subject to change at any time, I would rather cope'n'paste this class into Guvnor code base.

TODO:
A heavy part of the work will have to be carried out by the content handler. The content handler will have to support the multiple images per asset and also perform some graphics routines in order to replace the pre-compilation phase implemented in rolodex to adjust images.

GSOC2008: GWT magic - Deferred Binding and Generators

While reading the book further, I realized that I do not need any special library for plugging new content editors to Guvnor.

Currently, the editors are instantiated via EditorLauncher class, which provides several static methods for working with the editors. Now, we could actually remove the static property, change EditorLauncher to be interface and instantiate EditorLauncher like this:

EditorLauncher launcher = (EditorLauncher) GWT.create(EditorLauncher.class)

This will actually force the EditorLauncher implementation to be generated at the compile time using our generator (which would be subclassed from com.google.gwt.core.ext.Generator). This cool feature of GWT is called deferred binding ...

... which works by resolving and inserting the required class during compile time instead of runtime, as is the case in the Java language.

Basically, the need for any external library is diminishing in this case.

GSOC2008: Reflection Libraries for GWT

GWT Reflection appeared to have GPL licence and thus cannot be incorporated into Drools code base :(
I've found another library which has the support for introspection/reflection of Java beans - Gwittir, which comes with LGPL, and thus can only be included as a jar, but actually it doesn't provide the functionality that could provide us the features for plugging the content editors via Java Reflection API. So anyway we need to extend it.
I think I better go my own path and re-implement the code generation myself. There are 2 reasons for that: I will have the better understanding of the mechanisms behind GWT, and also improve my commit rate for the project :)

GSOC2008: GWT Reflection for Pluggable Content Editors in Guvnor

GWT Reflection is a cool project which inspired Mike for the idea of pluggable content editors for Guvnor (aka JBoss Drools BRMS). The challenge is that the content editors are selected on the client side and therefore we couldn't use Java's reflection API in order to enable the plug-in functionality. But with the GWT Reflection we can probably get as close as possible. GWT Reflection does a lot of what we need but most probably we'll need some more features and therefore I'm integrating it into Guvnor's codebase at the moment. I hope I will have some basic workflow ready next week. Stay tuned! :)