Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

GWT in Action 216

Posted by samzenpus from the read-all-about-it dept.
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.
This discussion has been archived. No new comments can be posted.

GWT in Action More

GWT in Action

Comments Filter:

  • The more I learn about JavaScript... (Score:5, Insightful)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Wednesday August 29, 2007 @02:52PM (#20402385) Journal
    The more I learn about JavaScript, the more I like it as a language.

    I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point. I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

    Well, almost. The problem with JavaScript is that it's horribly slow to execute. But then, you still have that problem, even if it's JavaScript generated from Java code.

    • Re: (Score:2, Funny)

      by jmyers ( 208878 )
      "I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter."

      duh... IIS and asp
      @ Language=JavaScript

    • Re: (Score:3, Interesting)

      by AKAImBatman ( 238306 )

      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 [mozilla.org] 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. Wh

      • 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.

        How fast is it, really? Compiling down to Java bytecode doesn't necessarily make it faster.

        Consider a Bash script -- for most of what people use Bash for, you're not going to get any significant speed improvement out of "compiling" it, if you could.

        I think JavaScript could be very fast

    • Re: (Score:3, Interesting)

      by fireboy1919 ( 257783 )

      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

      • "I like Javascript, but it has the same problem as PHP: no namespaces."

        You can work around this by writing object-oriented Javascript, like this:

        function myNamespace()
        {

        }

        myNamespace.prototype =
        {
        var1: null,
        var2: null,

        func1: function(){alert('yay');},
        };

        myObject = new myNamespace();

        The only problem you run into is if you want to call a member function as a result of an event. I haven't found a good way to do this without using some sort of global varia

        • I know someone replied to your 'this' problem. You can also check out mochikit [mochikit.com], they got a great bind() metoth which let's yuo 'set the this pointer, also, they got 'bindMethods()' which binds all methods of an object ao that objeect always is the this pointer, very neat. also other goodies like partial functions, map(), filter(), standardised event handleing over ie and ff (look a bit like Qt event handling) and more for you to play with - lovely stuff
        • It's actually not braindead. It makes a lot of sense, when you understand in more detail how javascript works...

          But look up Douglas Crockford. He had one way of solving this: var that = this. Since Javascript supports closures, you can then refer to that, even in nested functions in which "this" gets overwritten.

      • I mean, there are plenty of things to hate about PHP, and even object-oriented PHP, but you can no longer complain that it doesn't have namespaces.

        And Javascript is just far too flexible not to let you hack together namespaces on your own. Watch this (sorry about the lack of indentations; stupid Slashdot):

        var mynamespace = function() {
        var privateNSvariable = 'foo';
        function privateNSfunction() { ... }
        var that = {
        publicNSfunction: function() {
        I can access privateNSvariable or privateNSfunction(), and

    • - In JavaScript you find all errors at runtime, in Java you can catch many at compile time.
      - Differences in browsers object models makes it counter-intuitive to write cross-browser JavaScript code, GWT can take care of these differences for you.

      • In JavaScript you find all errors at runtime

        This may be more of a DOM issue than a javascript issue but I find a lot of situations where you don't get an error at all. It just doesn't do what you instructed. Sometimes execution just halts in that method and sometimes it doesn't.

        Also, don't get me started on javascript's this variable which is a complete joke.

        • This may be more of a DOM issue than a javascript issue but I find a lot of situations where you don't get an error at all. It just doesn't do what you instructed. Sometimes execution just halts in that method and sometimes it doesn't.

          You want a good debugger. Or, hell, just look at Firefox's error log -- it'll show you errors in HTML and CSS, also.

          Also, don't get me started on javascript's this variable which is a complete joke.

          It's completely easy to work around, also. Would you care to explain what ab

      • In JavaScript you find all errors at runtime, in Java you can catch many at compile time.

        So what?

        Most of the errors I catch at compile time in languages like Java are things that would not be errors in languages like Javascript. And in any case, what is so magically better about compile time?

        Differences in browsers object models makes it counter-intuitive to write cross-browser JavaScript code, GWT can take care of these differences for you.

        So can Dojo, the Yahoo UI library, and so on. I understand the

    • > I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

      Netscape did that, back in the "four days", google up "server-side javascript".

      > Well, almost. The problem with JavaScript is that it's horribly slow to execute.

      Bullshit. The types of JOBS people usually try to do with JavaScript may be slow, however. Or the native methods that the javascript programs are using might be... But that's a far cry from making it a slow language. It's not substancially s

      • That said, there is a JavaScript interpreter written in Java called Rhino. But if you were looking for speed, I would certainly look at a C implementation (like spidermonkey or NJS) first.

        That's just goofy. Spidermonkey is quite a bit slower than Rhino. They both contain runtime compilers, but Spidermonkey has its own interpreter. Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino!
        • Sorry, that should read "Spidermonkey has its bytecode own interpreter." Which is slow. Very slow.
        • > Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino

          Now that IS interesting, I wasn't aware of that. Thanks!

          ATM, Spidermonkey seems to perform VERY well for my needs. I have used NJS in the past and been satistfied with it (from a speed perspective) as well.

          Of course, when I profile my javascript code... only a VERY SMALL amount of time is spent in the JavaScript interpreter. Wall time is mostly consumed doing pesky things like I/O. So I tend to conce

          • Have you ever seen C libs embedded in Rhino, maybe built with gcj?

            I'm not really sure what you're asking here, so I'll just give a generic answer. Rhino compiles scripts to Java classes based on Rhino's hashtable-like data-model classes. Java classes can be passed to Rhino either by extending/implementing the data-model classes [mozilla.org], or by using the Livescript-like Javascript APIs [mozilla.org].

            Native libraries are incompatible with Java save for when they are mapped to a class through JNI. So if you want to link in a library

    • A couple of days ago I was thinking about what would an ideal scripting language would look like.

      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.

      So I
      • > I think Javascript gets a bad rap because you have to worry about browser compatibility.
        > But if you ever use it while only targetting a single browser, it's a dream to work with,
        > and all of the annoyances go away.

        I use JavaScript frequently, and have for years. I don't write much for the browser any more, but I often use JavaScript for general purpose projects.

        I'm a hardcore C hacker, know enough LISP to write macros for emacs, and I totally agree with your assessment. About the only thing I RE
        • I haven't considered doing xdialog in the browser, but it's a good idea. Vian came out of a desire for a web-based unix environment. The next step is a command shell, which can use the same editor/cursor class that vian uses, so it should be very easy to do.

          I think the coolest thing potentially is being able to send the commands to a real unix server and then pipe the output back to the Javascript shell. Obviously this has potentially serious security implications, but with a secure setup could be extrem
        • Like many things, this can be hacked to be better in Javascript. Crockford's idea of a "superconstructor" is actually really useful, I think.
      • I realized that Javascript has just about every one of those features

        Funny thing is, so does, say, Perl (probably to an even greater degree... how do you do macros in Javascript? I know Perl allows script pre-processing modules). However, both language suffer from a flaw that I think makes it difficult to write large scale applications: weak typing. Dynamic typing, that kicks ass, absolutely. But *weak* typing creates a whole class of errors easily avoided with a strong type system, just so the program

    • Re: (Score:2)

      by misleb ( 129952 )

      I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.

      Um, you understand that GWT is not a language, it is a framework, right? Java is the language. And JavaScript is most CERTAINLY not more powerful than Java.

      I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

      Don't give in to the temptation because it would make you look quite foolish.

      -matthew

      • Um, you understand that GWT is not a language, it is a framework, right? Java is the language. And JavaScript is most CERTAINLY not more powerful than Java.

        Really? What features are missing from Javascript that are in Java?

        Because I could come up with a very long list of things that are nowhere to be found in Java, but are actually cleverly hid in Javascript.

        Don't give in to the temptation because it would make you look quite foolish.

        Only because it's been done already.

        However, you just claimed Java is

    • Re: (Score:2)

      by plams ( 744927 )

      I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.

      I think "the point of GWT" is clearly stated on their front page [google.com]. The ability to write your web application more like a real application. The ability to share client and server side code. The possibility of using a real debugger. Support for browser history (havn't seen this for AJAX before).. just to name a few.

    • I'm not really sure I see the point of GWT

      Millions of dollars and 5 years of Java IDE development by some of the best IDE developers in the world. Also the Hotspot JIT Compiler and class libraries.

      There are many 'languages' that Java developers would probably prefer to use if they had had the same massive cross-industry investment as Java - like Ruby, Python or Smalltalk.

      Matt

    • Re: (Score:3, Informative)

      by ispeters ( 621097 )

      The more I learn about JavaScript, the more I like it as a language.

      I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.

      I agree with you that Javascript is a nicer language than Java and more powerful to boot, but I'm using GWT for one big reason: dead code elimination. The GWT compiler takes advantage of the static analysis possibilities in Java and the closed-world nature of a web page and produces dramatically optimized Javascript. Th

  • I Still don't know what GWT is (Score:5, Informative)

    by chad_r ( 79875 ) on Wednesday August 29, 2007 @03:19PM (#20402759)
    The review had everything except a brief summary of what GWT actually is. I had never heard of it until now. From http://code.google.com/webtoolkit/overview.html [google.com]:

    What is Google Web Toolkit?

    Google Web Toolkit (GWT) is an open source Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler translates your Java application to browser-compliant JavaScript and HTML.

    Here's the GWT development cycle:

    1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
    2. Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
    3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.
    • Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server. ...provided you have some other server capable of running the necessary services to put the A&X in AJAX, which raises the rather obvious question: what does this simplify again? So it's JSF-lite, except I have to roll my own SOAP services for everything?

      Hell. No.

      • Re: (Score:3, Informative)

        by Eponymous Bastard ( 1143615 )
        I looked into GWT a month or two ago. From what I understood, you can write both client and server code in Java and then GWT compiles the client to Javascript and the server to a servlet.

        You don't actually write any SOAP code, but rather use Java Remoting to call across the wire, getting a Java object back that you can manipulate. The GWT compiler translates that into a XML request and writes all the serialization/deserialization code and so on. In fact it doesn't seem to be able to call an XML web service

    • Re: (Score:2)

      by jilles ( 20976 )
      GWT is a development kit for developing AJAX applications, such as for example GMail. The concept consists of doing all the programming in Java (similar to how you would develop a Java desktop application) and cross compiling the client components to javascript + html. The advantage of this is that you don't have to think about html, javascript, browser-server communication and many other difficult browser issues that most other web developers waste most of their time on (instead of implementing functionali

    • Re: (Score:2)

      by tyrione ( 134248 )
      Cocoon 2.2 Frameworks does this and a helluva lot more.

  • Beyond hope (Score:5, Insightful)

    by k-zed ( 92087 ) on Wednesday August 29, 2007 @03:22PM (#20402801) Homepage Journal
    The sentence "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts - including more robust integrated development environments (IDEs)." is possibly the most retarded thing I have ever seen on Slashdot. Ever.

    Come on, doesn't anybody read these?
    • I'm glad to see someone else thinks so too. I was beginning to think it was just me, or that I'd misread it.

    • Re:Beyond hope (Score:5, Funny)

      by Bluesman ( 104513 ) on Wednesday August 29, 2007 @04:06PM (#20403485) Homepage
      Yeah, it's one of the dumbest things on the front page *today*, but ever? Let's not get carried away.

    • Spot on, that's a really terrible summary. It's like a reverse summary really as there are few to no IDEs which come close to Visual Studio. Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants.
      • "Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants."

        Funny, that, I am using both as well, and I feel the same thing. The other way around. VS is way behind Eclipse on some features, and a lot more on others. VS 2005 now has acceptable support for operations on the abstract syntax tree, but nothing really powerful. Of course, VS has more functionality integrated. But Eclipse has its vast number of functional plug

    • Re: (Score:2)

      by ceoyoyo ( 59147 )
      I thought the same thing. Then I realized that the writer probably doesn't realize there's any other type of programming in the world other than web apps. Then it's just oversimplified and erroneous as opposed to retarded.
      • I don't even think that the author does not know this. I think he was deliberately limiting his view to web applications. And to state that there is less support for languages supported in the browser (JavaScript, some Visual Basic) against those supported by the server (all of 'm really). Well, that's true, isn't it? So that would make the statement true, at least in the - supposedly - domain he was targeting. The initial reply of the grandparent was a bit over the top, in my opinion.

  • GWT *and* Java (Score:5, Informative)

    by owlstead ( 636356 ) on Wednesday August 29, 2007 @03:27PM (#20402861)
    I would like to point out that the GWT can also be used from a Java server application. I'm using a package from Instantiations, WindowBuilder Pro, that can generate Swing (default Java GUI), SWT (IBM/Eclipse GUI) as well as the Google Window Toolkit. It's an application/plugin for creating graphical interfaces, so you would probably not get too exposed to the GWT itself. I haven't yet tried it out, but it might be a good idea to start of with a GUI builder and only delve deeper when needed. Of course, understanding what happens is great when you need to debug something, or if you are not happy with the functionality. But I would not start off by writing web-pages when trying out this relatively new technology.

    Before somebody grills me, the version of WindowBuilder Pro that I am using is a bit unstable and crashes Eclipse now and then. Lots of memory is also recommended (then again, if you are a developer, you need lots of memory anyway).

    • Re: (Score:3, Informative)

      by owlstead ( 636356 )
      I *knew* I was too tired to write this reply. Google Web Toolkit it is. Are there any slashdottees that would like to proofread my replies?

      Nah, didn't think so :)

  • Why should GWT be on my radar screen? (Score:3, Insightful)

    by scottsk ( 781208 ) on Wednesday August 29, 2007 @03:50PM (#20403243) Homepage
    Does the book - or somewhere else - address why GWT ought to be on my tla radar screen? Does it work with Apache, or just J2EE containers? Is it open source? I know I could find that out by, um, googling the information, but if the book is meant to evangelize the tla, I would have expected it to concentrate more on why I should use GWT and in which situations, not how to build a tic-tac-toe game.

    • Re: (Score:2)

      by nuzak ( 959558 )
      > Does it work with Apache, or just J2EE containers?

      It is a servlet, so it works with servlet containers. Like tomcat, resin, jetty, or those big ol JavaEE containers.

      I'm not sure that tells you anything about why to use it though.
  • I thought they said GWOT [wikipedia.org]. My bad.

  • I want to write desktop apps with JS/GWT/whatever (Score:3, Interesting)

    by joe_n_bloe ( 244407 ) on Wednesday August 29, 2007 @04:00PM (#20403393) Homepage
    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.

  • Very nice toolkit with some problems (Score:4, Informative)

    by plams ( 744927 ) on Wednesday August 29, 2007 @04:48PM (#20404077) Homepage

    The content on Google's GWT site [google.com] almost speaks for itself concerning the power of it, so I'll elaborate on some negative aspects I've encountered.

    I went to explore the possibility of a non-servlet based backend and very quickly encountered problems that are not really GWT's fault but a side effect of having a hosted environment: the browser is based on Mozilla and thus inherits the security restrictions of it. I could not make RPC calls to my backend web server because Mozilla disallows cross-domain access. I spent a lot of time trying to circumvent this, and did find some work-arounds but nothing that worked to my satisfaction (too cumbersome). GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml [crossdomainxml.org] file in the root of the target webserver (to see whether access is allowed or not).

    Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM. Setting up a 32bit JVM isn't that difficult, but it's not a good solution (However, I talked to a GWT developer on IRC who claimed this issue was high on their priority list).

    Lastly, GWT is a nice environment, but it's still a bit young. It seems stable enough, but if you engage in a large GWT based project you may find yourself doing a lot of low-level client-side code unless their limited palette of widgets and other client-side features completely cover your needs

    • "GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not)."

      Distributing a specific web client to make it possible to view (some) web applications? That's not a good idea. Maybe for intranet use, but people won't go for a specific web client just to view some GWT based websites. The idea of a crossdomain.xml for use within JavaScri
  • Is there anywhere I can find out how to make the Google DB accessible to software that can query only an LDAP API?

  • 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 [jinchess.com].

  • GWT in Python and Ruby (Score:3, Informative)

    by egghat ( 73643 ) on Thursday August 30, 2007 @06:21AM (#20409345) Homepage
    My major gripe about GWT ist the use of Java, which I never liked.

    So I want to give oyou two pointers to projects that could need help to transfer the idea of GWT from Java to Python and Ruby:

    Python: pyjamas - build AJAX apps in Python (like Google did for Java) [pyworks.org].

    Ruby: Blog Entry from Michael Neumann, who tries to port GWT to Ruby [ntecs.de].

    The Ruby stuff is in the very early stages ...

    Bye egghat.

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close