Slashdot Mirror


GWT in Action

Michael J. Ross writes "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts — including more robust integrated development environments (IDEs). In contrast, Web-focused languages, such as JavaScript, benefit from the global accessibility of the Internet. Bridging this gap, and leveraging the strengths of both sides, has long been an objective of the software development community — though not all attempts have been successful, e.g., Java applets. The Google Web Toolkit (GWT) is the latest attempt, and shows considerable promise, as illustrated in a new book intended to help programmers learn this new technology: GWT in Action." Read on for the rest of Michael's review GWT in Action author Robert Hanson and Adam Tacy pages 600 publisher Manning Publications rating 6 reviewer Michael J. Ross ISBN 1933988231 summary A practical introduction to programming with the Google Web Toolkit (GWT). Written by Robert Hanson and Adam Tacy, this book was published by Manning Publications on 5 June 2007, under the ISBNs 1933988231 and 978-1933988238. For any prospective reader who would like to learn more about the book, they can first try the book's Web page, where they will find online versions of the "about this book" section, table of contents, preface, and index. The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. In addition, there is a link to purchase the book's electronic version, and a link to the author's forum, where readers can post questions about the book or GWT, and likely receive a response — perhaps even by one of the authors.

The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.

GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.

Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.

One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.

Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.

We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.

In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.

The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.

The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.

The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.

Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.

Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.

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

13 of 216 comments (clear)

  1. Re:Wow by cromar · · Score: 3, Interesting

    He seems to be saying that overall it's a good book :D

    Is it just me or is anyone else glad to see a review on Slashdot without a chapter by chapter summary? One of the most pointless, pedantic mistakes in book reviews is to summarize each chapter. Hoozah for the writer!

  2. Re:The more I learn about JavaScript... by AKAImBatman · · Score: 2, Interesting

    The problem with JavaScript is that it's horribly slow to execute.

    Depends on your engine. I've put some thought into the same sort of server-side Javascript engine as you have. Someone else mentioned the Netscape Enterprise Server. That was... not so great. I was thinking more along the lines of building on top of a Java Servlet Engine. The Mozilla Rhino Javascript Engine actually compiles the JS down to Java byte code. That wouldn't be all that special, except that the JVM then JITs that to native code. Which means that Javascript doesn't have to be slow. ;)

    I figure you could create a JSHttpServlet object and map a file of your own extension (it can be *.js if you want it to be) to that servlet. The servlet then creates a JS environment that maps HttpRequest and HttpResponse as global variables. You can even map HttpSession and a PrintWriter output stream if you want. (That gets pretty close to JSP territory. ;-)) Load the script at init() time, and execute it when called.
  3. Worse than Wicket? by kisrael · · Score: 3, Interesting

    Yeah?

    I did an evaluation of it. I kind of liked it, but in general don't like "lets make a servlet environment pretend its an applet", so I didn't endorse.

    Now, after months of using Wicket, I wish I had pimped for it more. Seriously. If you're gonna pretend it's an applet, then REALLY do it like GWT does, fake JVM and all. This Wicket stuff.... ugh. keeping the html view and java in synch for anythign complex is SO IRRITATING.

    Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.

    Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.

    --
    SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
    1. Re:Worse than Wicket? by kisrael · · Score: 2, Interesting

      Yeah.

      Sometimes I worry that I come up with my philosophy about languages to suit my personal gripes and history, and that ultimately that limits me as a developer, but...

      Anytime you borrow someone else's toolkit that adds some kind of organization/abstraction over an existing technology... well, either you're losing bits of the functionality of the lower level, or what you're learning is about as complex as the lower level.

      My strong personal preference is to write your OWN, app-specific organization.

      The counter argument comes from people who are heavily OO in their outlook. (more specifically, I think a gap tends emerge between people who cut their teeth on simple CGI-wrapping things, and got used to using a HashMap mentality for most client/server interaction, and people who cut their teeth on apps and applets, for whom the gap between Java code and what's physically displayed onscreen seems weird and in need of being abstracted away.) Anyway, these folks say that, look, the organization I want is OO, writing this kind of Object->screen element->response mapping ls a repetitive task, so I'm willing to buy into someone else's approach to do that work. That's where something like Wicket comes in.

      My recent semi-revelation for this kind of tool-kit was this: "text" is amazing. It has been the lifeblood of programming for decades, ever since we could get away from punched cards I guess, despite attempts at cutesy visual languages. It's just so powerful, concise, easy to manipulate, easy to automate that manipulation, and in its own way visual (hence the wars over the one true brace style etc) that it will be around for a long long time. But text is, by the way we use it, rather procedural, and while you can do OO in it, that's a new level. But sacrificing the ability to adjust HTML and CSS and Javascript in TEXT on the alter of Objects just seems like too big of a sacrifice to me.

      Of course, taking an anti-OO stance is a heresy (see http://geocities.com/tablizer/oopbad.htm ) and you have to be careful so you don't seem like a crazy nut job who hasn't worked on large scale projects. But my latest take on it is this: "People and Programs are both best defined by what they DO, not what they ARE".

      Another way of looking at it: in Java, when stuff goes wrong, what's your stack trace like? There's always that boilerplate JVM/Server engine at the bottom, but if the core of what's at the top ain't your code, your debugging is going to be a lot harder, because your mistake is in how you set up the other guy's objects to do the work, not you doing the work yourself. (Assuming the other guy's stuff is solid.)

      --
      SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
    2. Re:Worse than Wicket? by nuzak · · Score: 2, Interesting

      Wicket's an example of a minimalist concept that refused to grow beyond it in order to satisfy some ideology of "purity". Refusing to support even a moral equivalent of taglibs is an example. Tapestry has always struck me as far more pragmatic, and Tapestry5 looks downright amazing. Seam with Facelets strikes me as an awesome solution, though you're dealing with an insanely complex stack (JSF) under the surface, and wherever JSF is inadequate and Seam doesn't cover for it, you're forced into workarounds that may have you ditching Java for your project altogether.

      I'm an example of the last case -- a java burnout. We never needed scalability (internal apps with maybe 50 total users), so I'm back to cobbling together perl and python and even php now. Ironically, the need to glue these apps together has led to adopting more enterprisey stuff like SOAP and ESB's, but in a very ala-carte way. Useful enterprise apps remain grown, not engineered.

      --
      Done with slashdot, done with nerds, getting a life.
    3. Re:Worse than Wicket? by Anonymous Coward · · Score: 1, Interesting

      but often I end up having to put placeholder HTML in the page, and the set visibility = null.
      If you're doing anything reasonably complex, there's really no way around that in Wicket.

      I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.
      This pissed me off as well.

      One of the parts of Wicket that annoyed me the most, was that if you needed reasonable URLs it offered very little abstraction over plain old servlets. The default URLs (ie. http://example.com/?wicket-id=?30kdjf309fj20fj30f8 4fj4) really aren't acceptable on public facing websites.... Many would argue that they aren't even acceptable on internal websites used within a single organization. Especially, when you link to that URL and it proceeds to generate session timeouts. To fix the ugly URLs, you have to use BookmarkablePageLink for practically every link in your application, parse the URL arguments for every associated page, and use a sufficient URL coding strategy. Dealing with the session timeouts requires even more boilerplate that apparently most Wicket developers don't even bother with. The wicket examples that are provided by the core Wicket team still suffer from ridiculous URLs and regular session timeouts. I won't even go into how these problems get worse once you start using complicated components and Ajax....

      How all this nonsense makes things easier is anyones guess. It's easier and cleaner to write a small abstraction over the servlet API and disregard the framework altogether.

      Although I don't really like Wicket, or any Java web framework for that matter, I do think well thought out web frameworks can increase productivity and result in cleaner code when used properly. I think Django, Rails and Seaside are reasonably good examples of this.
  4. Re:The more I learn about JavaScript... by fireboy1919 · · Score: 2, Interesting

    But then, you still have that problem, even if it's JavaScript generated from Java code. That's not really what's going on.

    GUI stuff happens in Javascript. Anything really complicated gets sent over to Java. That's why it's called an AJAX framework, not a Javascript framework.

    I like Javascript, but it has the same problem as PHP: no namespaces. Using it as a real language would causes the same problems you see there: security issues, hard-to-read code, difficulty refactoring, interoperability problems, etc. You can actually see those problems and the various mechanisms to overcome them in a lot of the modern pure-javascript libraries (prototype especially is known for breaking existing javascript libraries, for example).
    --
    Mod me down and I will become more powerful than you can possibly imagine!
  5. I want to write desktop apps with JS/GWT/whatever by joe_n_bloe · · Score: 2, Interesting

    Some day, I'll be able to use a browser to write desktop apps without resorting to plugins or XUL or whatever. No, Google Gears doesn't do that.

    JS is a great language and GWT is a great tool, especially the hosted development environment. But it will never reach its potential until it is a general purpose application programming language.

  6. Re:Wow by Angostura · · Score: 2, Interesting
    Here's what happens when I take the review and run it through Microsoft Word's 'Autosummarize' Tool, set to the most violent setting: "100 words or less":

    The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. Unfortunately, the book has many weaknesses. The authors do not appear to mention which version of GWT they used for the book. The sample code in the book has minor inconsistencies. For example, the code for Chapter 5 has a folder named "Dashboard -- Chapter 4."
    ... yup, that seems to cover most of it.
  7. Its called pike. by Anonymous Coward · · Score: 1, Interesting

    "The first thing I'd like are some of my favorite features from Common Lisp, like first class functions, ability to do procedural, functional, and object oriented programming with the same language, dynamic typing, macros, closures, and lexical scoping.

    Having a C-like syntax would be good for people who are used to C or Perl and don't want to learn about s-expressions. Automatic memory management is a must."

    You just described pike (although it has both static and dynamic typing).
    http://pike.ida.liu.se/

  8. Shameless plug - chess board diagram composer by SashaM · · Score: 3, Interesting

    Just a few hours ago I finished a small, mostly-for-fun project in GWT, and now I see a GWT-related story on slashdot. Surely it's not a coincidence and therefore I must pimp my project: a chess board diagram composer.

  9. Re:the point of GWT by Anonymous Coward · · Score: 1, Interesting

    David --

            Maybe take another look at it. The learning curve is pretty minimal if you a) know java and b) have exposure to any other windowing toolkit, ala tcl/tk, swt, swing, etc. Couple hours tops, honestly. Secondly, the obfustication tech. makes the resulting javascript much smaller than hand-coded javascript, much the same way that a C compiler can write more efficient assembly than you or I could. Finally, I actually found the opposite about app size when I have used it with my customers -- for small apps it is perfect because you can produce a really slick interface very quickly. If you app has a lot of distinct functionality, and maybe parts of it aren't yet ported to GWT (for example) GWT actually gets in your way.

  10. Point of existence by JochenBedersdorfer · · Score: 2, Interesting

    One of the most important points for using something like GWT has been missed: You can write test code for GWT very easily! If you ever tried to debug a mid-sized Javascript application, you know what I'm talking about. With GWT you have a hosted environment that makes debugging much easier. Also, you can employ Test Driven Development much easier. There is even explicit support for JUnit in GWT. For your favourite toy web application, GWT may be overpowered. For massive, distributed internet applications who need to involve the client side as much as they can, GWT currently is the best solution for Java shops.