Problem Mixing SmartSWT and GWT Widgets

I set out implementing my Address GUI using SmartGWT 1.0b1 together with GWT 1.5.3 for Windows - both are latest releases available for download. The SmartGWT does not have any formal documentation. Information are scattered in Javadoc, showcase and developer/user forums. Although not ideal, the documentation is generally adequate.

I quickly ran into problem with SmartGWT. I wanted to have a menu bar at the top of my application as shown in the following diagram (which is a screenshot of SWT-Ext implementation of the same application).

SmartGWT does have a MenuBar in its API. However, this class does not seem fully implemented - there is no method to add menus (the addMenus() method is missing from the download although it appears in the online javadoc). As a workaround, I decided to use GWT's own MenuBar and MenuItem in combination with SmartGWT's ToolStrip and TabSet widgets as shown below.

I have done the same thing with the SWT-Ext version of the Address GUI (as shown in the first diagram above) using GWT's Menu with SWT-Ext's ToolBar and TabPanel widgets without any problems. However, in SmartGWT, the drop-down menu appears behind the SmartGWT widgets and get obscured by them. So I cannot really use the menu items any more. This result is shown in the above diagram.

It seams that SmartGWT is not so smart after all. [Update 2009-01-03]: Just joking!

GWT vs. ZK - SLOC Count

I often read about how compact the ZK code was compared to GWT. I couldn't quite believe it. I thought it must have been different design patterns and style of coding used. So I decided to do it myself - I implemented my pet project in both GWT-Ext (GWT 1.4.6 and GWT-Ext 0.9.3 in December 2007) and ZK (ZK 3.5.1 with ZK Studio 0.9.0 in November 2008) and compared the Source Line of Code (SLOC) counts using Code Count tool.

Before I show the SLOC comparison, I need to give a brief introduction of the little demo program that I wrote. The program is a GUI to show various capabilities of the Address package, which has a service tier and DAO implementations behind it. The Address package provides a meta-data driven way of managing address records (see here for the data model). The concerned application here is only the GUI portion. The GUI has the following screens (left=ZK, right=GWT):

CRUD

This screen is used for Create, Retrieve, Update and Delete (CRUD) of the Address records from/to the database.

Find

This screen is used to call the corresponding Address services to find addresses either by keywords or by location.

Compare

This screen is used to call the corresponding Address services to compare two given Address records. Note that the ZK implementation supports drag-and-drop - i.e. I can drag a row from the list of addresses and drop it onto the text box and the text box will be populated with the content of the address (as a string). On the other hand, the GWT implementation does not support DnD because at the time of writing it, GWT-Ext did not support this kind of DnD yet (and I am not about to rewrite it using new version of GWT-Ext now considering Sanjiv has left the project... but that's another story).

Preferences

This screen is used to manage user preferences of the GUI application. Cookies are used as the storage.

In my SLOC count, I divided the source code into the following groups:

1. Main View - this includes the main screens: CRUD, Find and Compare tab panels.
2. Preference View - the user preference window
3. Model/Controller - the code behind the screen components, including models, event handlers, interaction with the service tier, helper/utilities
4. Splasher - this is the Splasher screen displayed at the beginning of the application. Only ZK version has implemented this (using index.zul and automatically forwarding to the main view after initialising the Address service); other versions do not have this screen.

Note that in ZK, all the views are a result of drag-and-drop from the components palette with modifications by hand.

The physical and logical SLOC counts are shown below.

The results speak for themselves.

UPDATE [2008-12-08]:

• The GWT implementation source code can be found here: Address_gwt.zip
• The ZK implementation source code can be found here: Address_zk.rar

GWT/GWT-Ext screenshots have also been added after the ZK ones (i.e. GWT screenshots are on the right-hand side).

The Shortest Self-Printing Code

#!/bin/ksh
cat `whence $0`

Could this be the shortest self-printing code?

Of Tatami, jMaki and Others...

Tatami 1.2 Beta was released a few days ago.

Both GWT and Dojo are Javascript frameworks for creating Rich Internet Applications (RIA). The GWT team focuses on the foundation of the framework and does not bother with making state-of-the-art cool widgets. While Dojo has a mature and good-looking widgets library. Wouldn't it be good if the two can be seamlessly integrated at the API and runtime levels so that one can leverage on the advantages of both frameworks? That's exactly what Tatami offers.

Tatami is a widget/component library for GWT. What makes it interesting is that it is a GWT wrapper of Dojo components. With Tatami, the Dojo widgets become GWT widgets; the Dojo utilities become GWT helper classes. If you don't have the stomach for editing CSS+XHTML+Javascript directly, but still want to use the Dojo components, then Tatami is good news. The development experience is back to Java and that's it.

Another web framework which provides Dojo wrapper is the jMaki framework. While jMaki has a nifty NetBeans plug-in, the development experience is improved somewhat. However, as a developer, you'd still have to deal with a mixture of JSP, Javascript and Java: the page templates are written in JSP, the glue code is written in Javascript for event handlers (using a pub-sub mechanism), the server side code is written as Java servlets - maybe this hodge-podge is really what they mean by mash-up.

Another wrapper is the GWT-EXT, which is a GWT wrapper for EXT/JS. I have blogged about the EXT/JS, EXT-GWT and GWT-EXT and the licensing issues revolving EXT/JS previously. Well, the licensing of Dojo is very liberal, without the GPL issues introduced by EXT/JS. Thankfully, Tatami is LGPL.

Why Google Chrome?

The release of Google Chrome beta is indead exciting news. Chrome is going to be bigger than iPhone! What makes it exciting is not the GUI - in fact, it looks and behaves pretty much just like any other browser. It is what's under the hood that make people (OK, developers) pumped about the new browser.

Google made it very clear on why they built a browser: "What we really needed was not just a browser, but also a modern platform for web pages and applications, and that's what we set out to build." So it is clear that Google intends to make Chrome to host and run next generation rich internet applications (RIA). Google's RIA platform is the Google Web Toolkit (GWT), which just had version 1.5 released a few days ago (Developer's Guide here). JavaFX folks are also excited about Chrome as shown in this article.

Google is a big proponent of Javascript. GWT 'compiles' Java code into Javascript and uses Javascript in runtime. A sophisticated GWT application can result in a large Javascript file, which poses a performance problem for the initial download of the application (a similar problem faced by Java Applets, which Java 6 Update 10 solves by allowing downloading relevant JARs only, without having to download the whole JRE libraries). Google Gears is another component that Google pushes to increase performance of Javascript applications. Yet, users have to download and install it separately if they want to take advantage of it. Therefore, it is natural for Google to come up with a browser as a unified platform for great support of Javascript. From Chrome web site, Google stated: "We also built V8, a more powerful JavaScript engine, to power the next generation of web applications that aren't even possible in today's browsers." Here we can see a glimpse of what to expect from Google on the Chrome, Gears and GWT fronts. GWT applications will run faster on Chrome than any other browser, thanks to Javascript optimisation on Chrome.

No wonder people are speculating that Microsoft is contemplating on suing Google for antitrust!

Related posts: Why Not Chrome?

GWT - RIA of Choice ?

I have been evaluating RIA frameworks (incl. Echo 2, GWT, JavaFX and Silverlight) for building business applications since a year ago. So far GWT has come as a clear winner.

GWT is especially appealing to Java developers - you develop your application in Java: server side, client side GUI, the lot. The GUI development is much like Swing, except that you are dealing with GWT APIs, but the programming experience is pretty much the same. AJAX is also supported by simply writing Java callback code without touching any XML or Javascript. These Java code is then translated into high quality and high performance Javascript by GWT and at deployment time, the JS code is downloaded to the browser and gets executed there - freeing the server side from handling presentation responsibilities. (Echo 3 also promised to take a similar approach). When I first learnt and programmed in GWT, it was such a refreshing experience - it was a joy to use.

The GWT team focuses on the foundation of the framework and does not bother with making state-of-the-art cool widgets. That responsibility has been given to third-parties. Sanjiv Jivan has created the wonderful GWT-Ext project which takes on this responsibility. Some people claimed that between GWT and Flex, they chose Flex because of its better look and feel. I guess they did not include GWT-Ext in their picture.

GWT-Ext provides a set of cool and useful widgets with complete documentation, demo and sample applications. It is a tremendous amount of work for an individual to take on. The result is simply superb.

One major issue of GWT-Ext is that it is a GWT wrapper of Ext-JS library, which used to be LGPL and now GPL (since version 2.1) and a commercial license is also available. Apparently this change of licensing policy has created much stir in the community. The effect of this change is also evident in the GWT-Ext distribution - in earlier versions (e.g. v0.9.2) the Ext-JS is bundled with the GWT-Ext download; but in newer ones (e.g. v2.0.3) you have to download and install Ext-JS yourself.

Furthermore, the maker of Ext-JS, Ext also created a similar product called Ext-GWT (not to be confused with GWT-Ext), which directly competes with GWT-Ext. The technical difference between GWT-Ext and Ext-GWT can be found here.

As a commercial application developer, if you want to stick with GWT-Ext, then there are the following choices:

1. use older version of Ext-JS with new version of GWT-Ext for free
2. pay for latest version of Ext-JS but use GWT-Ext for free
3. hope/wait for someone to fork Ext-JS and maintain a LGPL branch

I can't wait to work with GWT-Ext 2.0.3 which has full Drag-and-Drop (DnD) support in its widgets. Note that by DnD I don't mean just repositioning a widget on screen (which many RIA frameworks can do), but the kind of DnD capability that you would expect in Swing or WinForms, e.g. to drag a row in a grid and drop it into a text area so that the text area can be populated with the data from the corresponding business object being DnD'ed.

I hope Sanjiv stays true to the open source ideology, continues with the good work of GWT-Ext and doesn't change the licensing policy.