GWT Java AJAX Programming

simon_kehler writes "The Google Web Toolkit (GWT) is a Java AJAX framework that provides an easy to use programming paradigm for web developers using the Java programming language. It is one of the more recent entrants into this field, but has been gaining a lot of traction and popularity. GWT Java AJAX Programming authored by Prabhakar Chaganti and published by Packt Publishing addresses the use of GWT to build ajaxified user interfaces. The author gently introduces the reader to GWT and then leads the reader through a series of tasks, each of which shows how to perform an useful action with GWT." Read below for Simon's review.

GWT Java AJAX Programming
author	Prabhakar
pages	240
publisher	Packt Publishing
rating	8
reviewer	simon Kehle
ISBN	1847191002
summary	A great book for learning the different facets and features of GWT

I am a software architect working for a startup that is evaluating the use of GWT for a new project. I lead a team of experienced Java developers that are comfortable working with Swing and have reasonable familiarity with Struts. We have looked on with envy at all the nice things you could do with the AJAX integration built into web frameworks in languages such as PHP and Ruby. When I came across GWT we decided to take it for a spin and see if your team would be comfortable using it. The documentation that comes with the GWT download is a bit sparse. I was looking for a more in depth intro to the framework and came across this book. this seems to be the first print book on the GWT framework.

The book is divided into ten chapters. An introduction to GWT and its download and setup is provided in the first chapter. The author then shows how to create random quote GWT application in chapter 2. This is a nice example that immediately gives you the flavor of what its like to work with GWT. It shows you the steps involved in writing and running a simple GWT app. Chapter 3 details the service interfaces that you need to create as a part of any GWT application. These are the heart of how the AJAX mechanism works in this framework. Chapters 4-6 go through a lot of tasks that show you how to create increasingly complex user interfaces using the GWT framework. Chapter 7 deals with creating custom widgets that can be shared across applications. Unit testing for GWT applications is covered in chapter 8 (Yes, you can unit test your AJAX apps!). I18N and client XML support are dealt with in chapter 9 and finally chapter 10 shows how to deploy your applications.

This book moves along at a fairly rapid pace and is a quick read. The examples chosen for the tasks are well thought out and show different features in GWT. There are several really cool and innovative examples in this book: Password strength checker, uses colored check boxes to visually show the strength of a password. A very different way of using a check box. Dynamic Lists, change list entries as selections change. Flickr label, recreates the cool label widget that was made famous by Flickr. Sticky Notes, you create post it notes in your browser and drag them around to place them as you want (uses GWT drag support.) Mona Lisa jigsaw puzzle, rearrange Mona Lisa (uses GWT drag support.) Moo.fx, uses moo.fx javascript library for effects (uses JSNI.) Color Selector, integrates Rico Javascript library into GWT (uses JSNI.) Calendar, a very cool mac os x like calendar widget (Creates a compound widget.) Weather, another widget (creates a compound widget.) I18N, displays the country flag based on the locale (uses i18n support.)

I had played around a bit with GWT before. So some of the things in the book were not new to me, but there were several things that I found very useful. GWT provides a way to integrate Java and Javascript (you can call into Java from JS or from JS to Java) called JSNI (Javascript Native interface). The JSNI examples in this book showed how to integrate with moo.fx, Rico and scriptaculous libraries. This was great as we have some homegrown Javascript libs that we would like to continue to use even when we move to GWT. If we can try to hook those in and call them from GWT, that would be sweet! The ability to create widgets that can be shared across applications is very important to our project. The author creates two widgets in chapter 7 — calendar and weather. Both of these were very cool and reminded me of my mac desktop widgets! The weather widget uses Yahoo's weather service to retrieve the information that is displayed. Again, very nicely done. The ability to unit test is another thing that is crucial for us. GWT leverages and extends JUnit to provide this support. However, this is one of the parts of GWT that people do not seem to be using much. Searching on the GWT forums reveals as much confusion about this topic. This book contains a chapter that shows how to unit test a GWT application. The examples are quite simple, but the creation of test suites was a good one, as I had struggled with that before. I really liked the author's coverage of deployment. He first shows how to manually deploy a GWT application. this gives you a feel for whats involved and what's going where. Then he automates that using ant and finally shows how to deploy from within eclipse. This is very useful as I have tripped over deployment before.

Overall, this is a well written book that was very useful to our team. There were a few examples that we had implemented differently than the author — table sorting, paging and in place editing of the tree nodes. I18N is a big topic and the author covers only one way to use it. It would have been nice to have a complete chapter devoted to that topic, as this is a topic of particular interest to us as we work with a multitude of languages. This is a very developer oriented book and assumes that you know Java, HTML, some Javascript and some CSS. Of course if you did not know those topics, you probably wouldn't be too interested in GWT! This is not a book that dives into the internals of how GWT works or tries to impress you with all the nitty gritty of the GWT architecture. The author provides you with ways in which you can accomplish most common tasks that require GWT. They may not be the only way to do things using GWT but it gets you comfortable using GWT and thinking about how you would actually apply it for your problem. I really enjoyed reading this book and its focus on the practical side of using GWT.

---

You can purchase GWT Java AJAX Programming from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Web 2.0

I have also looked at GWT and it is pretty innovative. While everyone with ways to abstract the Javascript functions to deliver 'web 2.0', 'ajaxified' applications, Google has treated Javascript, HTML and CSS like the 'byte code' of the web application.

Personally, I think it would be nice to see Google work on a standard for 'application markup'. Perhaps lending a few developers to help move the XUL forward.

I can see the benefits of web based applications, but having to write a tonne of script to achieve such a basic HCI function as drag and drop is not whree I want to be.

Re:Web 2.0

Personally, I think it would be nice to see Google work on a standard for 'application markup'.

I would simply preferr a rethink of the whole web application thing. I mean, I'm *so* tired of having to deal with tons of languages that don't work very well by themselves (imagine work together with others) and are not properly implemented in browsers....etc

I look at old designs such as the Unix with its services (read: small applications) and shell, wich provide the means to have applications interacting with each other in non-obvious ways and it makes me (pardon) sick of having to deal with such a messy place that is web applications.

Frankly, I would be very excited to see a single idiom on server/client side talking to each other without layers of translations and the like, and, of course, fully enjoying the power of scripts on browsers.

IMHO, there are many things wrong when it comes to web app, and I'm not sure the efforts are going in the right direction.

Re:

Hmm .. Since reading about GWT the first time (And creating an asynchronous CLI module from it within an hour), I have been on and off about GWT. I wasn't sure I wanted to rely on one more framework that I may have difficulty debugging later. Since then I've come to appreciate GWT more and more.

For a Java developer like me (Who never feels comfortable with Javascripts), GWT is valuable. A swing like UI library like GWT gives you easy RPC and Serialization support. That's all that you need as an applicati

Re:

Something I'm more impressed with is Echo2 [nextapp.com], which is dual licensed under the LGPL and MPL. Try out the demos. It's possible to do some really cool stuff with it. I started learning it a few days ago, so far it seems really nice.

All of these frameworks are mostly overkill

There is nothing that can't be done with a few lines of very simple javascript, here is a simple synchronized xml request test page that loads a simple data file and evaluates data quickly into an array and a map.

Test code:

<HTML><SCRIPT LANGUAGE="JAVASCRIPT"><!--
function handleHTTPResponseForArray(str) {
// UNPARSED TEXT EXAMPLE
handleHTTPResponse(str);
// ARRAY EXAMPLE
var textarea = document.getElementById("textarea2");
var result="";
var array=eval(str);
var hashMap=new Array(array.length);
for(var i=0;i<array.length;i++) {
hashMap[array[i][0]] = array[i][1];
result += "key:" + array[i][0];
result += "\t\t\tval:" + array[i][1] + "\n";
}
textarea.value=result;
// HASH MAP EXAMPLE
result="";
for(var i=0;i<array.length;i++) {
var tmpKey = array[i][0];
result += "key(" + tmpKey + ")=" + hashMap[tmpKey] + "\n";
}
textarea = document.getElementById("textarea3");
textarea.value = "Use result as a hash map with key/value pairs:\n";
textarea.value += result;
}
function handleHTTPResponse(str) {
var textarea = document.getElementById("textarea1");
textarea.value=str;
}
function handleHTTPError(str) {
alert(str);
}
function makeHTTPRequest(url, onLoadFunc, onErrorFunc) {
var request;
if(window.XMLHttpRequest) {
try {
request = new XMLHttpRequest();
} catch(e) {
alert(e);
return;
}
} else if(window.ActiveXObject) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e1) {
alert(e1);
return;
}
}
}
try {
window.status = "ECSM:AJAX:Connecting to "+ url;
request.open("POST",url,false);
request.setRequestHeader('Content-Type','applicati on/x-www-form-urlencoded; charset=UTF-8');
request.send(null);
window.status = "";
} catch (e) {
window.status = "";
alert(e);
return;
}
if (request.status==200)
onLoadFunc(request.responseText);
else
onErrorFunc(request.status);
}
function testHTTPRequest() {makeHTTPRequest("mockups/load-data.txt", handleHTTPResponseForArray, handleHTTPError);}
//-->
</SCRIPT><BODY><input type="button" value="Run Test" onclick="javascript:testHTTPRequest();">
<table>< tr><td>Unparsed Text:</td><td><textarea id="textarea1" rows="10" cols="100" style="background

Re:

There is nothing that can't be done with a few lines of very simple javascript, here is a simple synchronized xml request test page that loads a simple data file

You keep using that word. I do not think it means what you think it means.

(Especially after posting 75 lines of ugly Javascript.)

Re:All of these frameworks are mostly overkill

Ooh, goody gumdrops, /. never ceases to surprise me. Seriously, I wasn't going for Funny in the previous post.

For my next comedic number I will solve a quadratic equation.

Re:

Like it or not, that WAS simple Javascript. I usually write Javascript that reevaluates the entire page DOM and does something strange with it. You can [mozilla.org] see it [mozilla.org] for yourself. [mozilla.org]

Re:

That was NOT a simple example. That was a full-up demo with all the bells and whistles in place. You don't make your point by showing the bells and whistles! The message ends up getting lost in all the excess code.

Oh, and you do realize that setting window.status no longer works on many browsers? It is considered a security hazard.

Re:

I have to concur. I saw "simple code" and then more than a page worth of code in my browser and thought, "Simple, my ass." Sure, it may be simple for Javascript, but if the GWT actually ends up making it easier to code, I'm all for it.

Re:

Until the moment you need to do something that the framework does not do, and then you have to debug into it to add your features and introduce modifications, which of-course will not be supported by the newer versions of the framework. As I said, most things that need to be done can be done with very little of very simple javascript.

Re:

Until the moment you need to do something that the framework does not do

One point of a framework is to standardize the things that you do, and do all the prep work to do them. There are good frameworks (ooh, a compiler that does linking!) and bad frameworks (Yay! Frontpage!). To say that a framework is a bad idea because you might need to work outside it is to argue a vague point. Pick the right framework and that doesn't happen.

Now, if you said GWT doesn't handle that, and provided examples, you may

Re:

Yep, I know about the window.status I wrote the code in question as a demo for an intranet project long time ago, so it has all the bells and the whistles and still fits into a couple of pages of text.

Re:

Frameworks like the GWT allow users to use their current experience in a language (in the GWT's case, that language is Java) and transform it into whatever the current fad is (in this case, AJAX).

Yes, they're a little bloated. So is code written in Delphi, C++ Builder, Visual Studio, etc. Obviously, the more you abstract away the details, the more bloat you get. What you have to evaluate is whether or not you get enough of a benefit from that abstraction. In the GWT's case, that benefit is likely to com

Re:

You'd be assuming that the average developer writes better code than the framework developers. My experience is that the average coder, through lack of time, laziness, or inability, writes pretty crappy code. On average you probably get lighter, and better, code by using a framework. Of course I've seen some pretty crappy frameworks too.. but you can choose not to use those. :)

Re:

aaah, no. Javascript frameworks pack mostly unnecessary bloat. Only use what is absolutely minimally necessary to build your solutions, don't fall into these 'be all' frameworks.

Re:

Are you posting via lynx?

Re:

No, FF, it's bloated like hell. I am also posting from work, where I am given a WinXP machine to use, terrible bloat. I am posting bloated HTML content over a bloated HTTP protocol too, which runs on top of bloated TCP/IP etc. None of which undermines my earlier point that most solutions do not require complex frameworks and can use simplest solutions.

Some may need more complex frameworks, but most do not.

Re:

Your earlier point reads like a grumpy old man saying that you should walk to school uphill both ways. From machine code -> C -> C++ etc. They were all developer to make OUR life easier, and turn out code quicker with less bugs.

Re:

Fitting all solutions into similar frameworks is fine and all, but it often unnecessary bloats the application, forces the developers into unnatural (for the application at hand) coding patterns, prevents developers from using sufficient and most efficient solutions to the problem. I think learning the basics is necessary to make sound decisions. Once you understand the basics of the technology, then you can make your own educated guesses whether a framework in question is worth your time.

My experience with GWT

A couple months ago, I was looking into different AJAX frameworks to leverage for an internal web app my group supports. Right now, we basically have a giant tree that is loading about 40,000 nodes from a database at once and then using CSS to show and hide our hierarchy of nodes. This was starting to become inefficient at load time, taking a couple of seconds for the tree to generate and then for the browser to render it. So I started investigating dynamic loading trees using AJAX and then doing a new d

Re:

Ajax is a very easy concept. If you just want to throw together some Ajax for one part of you application, it shouldn't take more than a couple days to get a solution to a problem like yours. You'll understand the code a lot better, and it will be a lot easier to fix things when something goes wrong. You'll probably need maybe 300 lines of javascript to support the Ajax calls, and rendering of the response. There's not that much involved. Just start coding and get it done.

Re:My experience with GWT

What do you care what the javascript looks like? The whole idea of GWT is that the javascript,html, and CSS (somewhat) are an alternative form of bytecode to compile your java classes to. You "look at" the java code, in an IDE like eclipse with lots of code assist features like syntax checking, completion, problem underlining, quick assist, refactoring, etc..., etc..., etc... .

Part of the value proposition of GWT is that java is easier to maintain than javascript. There are probably a few javascript monkeys out there who don't know much java that don't agree, but most of the javascript (human written) that I see when I do "view source" out on the web is horrible stuff with negative maintainability.

I prefer Yahoo's YUI

I was looking for which framework to use. I didn't look (further) at Google's offering because I wanted a JS framework, not Java, so I cannot comment on it. Yet I would like to make a posting to point out my personal favorite, the YUI, and how I got there.

First, on the page http://developer.yahoo.com/yui/theater/ [yahoo.com] the Yahoo "JavaScript Architect" Douglas Crockford gives some really *excellent* learning presentations on JS and the DOM that convinced me that there are really knowledgable people whos philosophy I like too.

Second, the license is BSD - it can hardly be any more free.

Last, if I have to rely on a framework I want to be sure it stays around. So even if some of the others are nice too and would fit, I must say I trust Yahoo a lot more to stay around and improve their framework - especially since they use it themselves for everything they do.

I also must say that I wasn't impressed at all when I finally tried GMail a few weeks ago, as a regular user of Yahoo mail for all my "public" mail (my own domain has 4000 email addresses left but I prefer Yahoo because of the excellent Spam-filter and only use my own domain-address for close friends) I find the Yahoo mail interface superior and much nicer.

What's more, there's YUI-ext, an extension for YUI (and now available for Jquery too), which provides some great-looking and very functional add-ons: http://www.jackslocum.com/blog/index.php [jackslocum.com]

AJAX is NOT irrelevant...

Every so often, someone wants to start using AJAX and automatic form reposting
and a bunch of stuff that makes their code unreadabale and unmaintainable by the rest of the
crew.

I think you're crazy. Have you looked at the source code of "classic" CGI pages that do a full form post and then return back to the same page... all the while trying to retain the state of existing fields or refresh the screen dynamically based on a selection? Gimme a break. Go read some of the "classic" source code in Bugzilla som