Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

GWT Java AJAX Programming 100

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.
This discussion has been archived. No new comments can be posted.

GWT Java AJAX Programming

Comments Filter:
  • Web 2.0 (Score:5, Interesting)

    by D-Cypell ( 446534 ) on Wednesday March 28, 2007 @03:52PM (#18519503)
    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 (Score:4, Interesting)

    by jesterman ( 932975 ) on Wednesday March 28, 2007 @04:15PM (#18519805)
    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.
  • by hansamurai ( 907719 ) <hansamurai@gmail.com> on Wednesday March 28, 2007 @04:20PM (#18519853) Homepage Journal
    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 database call for every node expansion.

    First thing I looked at was GWT because I'm a Google fanboy. Their demo seemed great, and we started getting hyped up that our solution was right in front of us. I started tinkering around with the demos, basically hacking their tree demo into something usable for us to get started quickly. Anyways, it didn't take long to find out that to make things worked, everything had to be basically compiled into this horrendous looking Javascript (yes, worse than the usual stuff) that was obviously unreadable (not that was supposed to be). For this and a few other reasons, it didn't take me and a coworker long to realize this was not the solution for us.

    I'm sure Google Web Toolkit is great for building a site from the ground up with, but didn't fit into our existing J2EE app very well.

    Anyways, if you must know, we looked into the Dojo Web Toolkit and I wrote our tree using that, unfortunately, that framework seems buggy and prone to memory leaks as expanding one node can take much longer than the initial load/render for the CSS tree. We're still using the CSS tree in production, if anyone has any help, let me know! But that's my experience with the Google Web Toolkit. Short and bittersweet.
  • by Anonymous Coward on Wednesday March 28, 2007 @04:49PM (#18520279)
    I'm sure Google Web Toolkit is great for building a site from the ground up with, but didn't fit into our existing J2EE app very well.

    Note that even Google doesn't use GWT for their own services. It's a company they bought, rebranded, and open-sourced.

    It seems a cool concept (if you can stand writing Java). But I wonder if *anybody* has written a serious app using it yet.
  • by SwiftOne ( 11497 ) on Wednesday March 28, 2007 @05:17PM (#18520641)
    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 well have won me over. As it is, you sound like someone that wants to implement all libraries yourself in assembler. (Yes, a strawman exaggeration. No, I'm not claiming you said that. I'm saying I have nothing better to work with from your argument)

    most things that need to be done can be done with very little of very simple javascript.

    GWT provides me:
    * ease of maintenance
    * tested compatibility across browsers
    which your "simple javascript" does not. Were I a JS programmer that kept current on all the trends, I would likely agree. GWT likely isn't written with you as an audience though.

    That you don't understand why your comment was marked as "Funny" ( I know I thought you were trying for it) indicates to me that you're missing something.

  • Unfortunately AJAX (Score:1, Interesting)

    by Anonymous Coward on Wednesday March 28, 2007 @08:03PM (#18522753)
    Unfortunately AJAX has evolved to fill the void: inefficient, ugly, non-standard, and totally counter-intuitive. The reason it is this bad is because the individual components of AJAX were never designed to support rich web-applications; AJAX is a hack. No programmer in their right mind would ever choose to use AJAX over a properly designed remoting and GUI framework. So, why do we tolerate it? Because its currently the only way to build anything that remotely resembles a rich application that is accessible from (most) web browsers. Simply put, its a compromise; however, a very nasty compromise. I pray for the day when people wake up from the buzzword stupor they're in and start demanding better standards.
  • by javabandit ( 464204 ) on Wednesday March 28, 2007 @10:27PM (#18523955)

    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 sometime. Talk about coding horror. Go look at the "dynamic" query portion of the Bugzilla search page. (Sidenote: This isn't a knock on Bugzilla developers. You guys did the best with what you had at the time). If Bugzilla's search page was AJAX enabled, it would be worlds easier to read, understand, and maintain.

    AJAX programming is so much cleaner. You post only what you need to, when you need to, and then update only the portion of the page that you need to. I don't know how you can say that is more "hard to read" or "a real pain". AJAX programming is the closest you can get to thick-client, event-driven UI programming in a browser. Combine it with JSON and you are talking VERY clean.

    I'd love to see examples of what you think "painful" AJAX code is versus the same code in the "classic" CGI paradigm.
  • GWT in production (Score:2, Interesting)

    by kilkenny ( 261332 ) on Thursday March 29, 2007 @03:07AM (#18525491) Homepage
    In case you are interested, a here is a list of GWT applications in production:
    http://www.ociweb.com/mark/GWT.html#WhoIsUsingIt [ociweb.com]

    ---
    check out => http://traceurl.com/rdS?r=1&l=2 [traceurl.com]

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...