Stories
Slash Boxes
Comments
typodupeerror delete not in
  • Preferences

Comments: 100 +-   GWT Java AJAX Programming on Wednesday March 28 2007, @02:37PM

Posted by samzenpus on Wednesday March 28 2007, @02:37PM
from the prefix-programming dept.
bookreview
books
media
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.
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

GWT Java AJAX Programming 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Web 2.0 (Score:5, Interesting)

    by D-Cypell (446534) on Wednesday March 28 2007, @02: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, @03: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.
      • Your comments seem a little odd because web design has become very much like working with Unix-style single purpose programs. If you have trouble it's probably because you aren't coding in Unix-style. My web applications are composed of many smaller programs that each do a single thing. These can be written in whatever language is most appropiate but they speak to each other in common interfaces. My back-end is composed of services that communicate with XML-RPC. The front-end is a thin layer that usually di
    • 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
    • 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.
    • To bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require. Of course the saving grace might be the number of tools that exist to make building GUIs in Java easy. Still, I'd rather see something more RAD oriented than the Java is. It's impressive work even if it isn't perfect though - I think it'll lead the way for better development models in web design.

      I think a domain-specific markup language designed for high power web apps i

  • All of these frameworks are mostly overkill (Score:5, Funny)

    by roman_mir (125474) on Wednesday March 28 2007, @02:56PM (#18519563) Homepage
    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: (Score:2, Funny)

      by Anonymous Coward

      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.)
    • 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.
        • 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: (Score:3, Informative)

            by AKAImBatman (238306) *
            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.
            • 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: (Score:3, Insightful)

                by roman_mir (125474)
                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: (Score:3, Interesting)

                  by SwiftOne (11497)
                  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

                  • 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. - understanding something and expecting something are different things and I think you are missed the difference here.

                    For everything else the answer is here [slashdot.org], I don't want to repeat myself.
            • 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.
    • 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: (Score:3, Insightful)

        by MikeFM (12491)
        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. :)
      • 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: (Score:2, Insightful)

          by s2jcpete (989386)
          Are you posting via lynx?
          • 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: (Score:2, Insightful)

              by s2jcpete (989386)
              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: (Score:3, Insightful)

                by roman_mir (125474)
                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.
                • Using a framework is like using functions or objects. If you go crazy with the concept then it'll end up being crap but if you use it in a way that makes sense then it'll help you a lot. You don't want to create a function for a single line of code you're going to use once but you may want to create one for ten lines of code you're going to use a dozen times. You don't want to create a class for a single on line function you'll use once but if you begin building up application logic in a way that needs to h
  • 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
    • 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.
      • There are also JavaScript libraries that work at a lower level (which makes integration much easier). I use JQuery [jquery.com] which has a nice cross-browser way for accessing DOM elements, a few bells and whistles, and, most important, a standard way to access the server via their Ajax methods. Nothing revolutionary (I've never used it but I think Prototype does the same thing) but easy to use and seems to be very well supported.

        However, for my next "clean" Ajax project I think I'm going to give GWT a try. I've don

    • Re:My experience with GWT (Score:5, Insightful)

      by bwt (68845) on Wednesday March 28 2007, @03:54PM (#18520351) Homepage
      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.
      • 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.

        And that's a great idea, unless you have account for the fact that HTML/CSS/JS *aren't* application bytecodes.

        There are lots of concerns in a web app that aren't there in compiled bytecode app:

        1. data/code sharing among pages (number of file read requests, repeated data in every page)
        2. incompatibilities among browsers (you
        • There are lots of concerns in a web app that aren't there in compiled bytecode app:

          1. data/code sharing among pages (number of file read requests, repeated data in every page)
          2. incompatibilities among browsers (you rely on GWT for browser compatibility, it's frequently not accounting for some rather unobvious details, then you're screwed).
          3. GWT goes against MVC as it follows a more traditional "apps and forms" paradigm, which means you're severaly limited in code reuse and separation of concerns in your a
          • Please look yourself in the mirror and say your organization is better than Google and the GWT community at understanding browser specific DHTML differneces.

            You know, I'll accept the rest of your comments as I truly don't know GWT well enough to be certain. I evaluated it, saw sufficient hurdles in using it and rejected it.

            However, I don't need to look in the mirror and practice self-help exercises to know the obvious. If you've ever inspected the code of the google pages (the main google search page, googl
          • The code *I write* doesn't have case statements in it that switch behavior by browser.

            You know I refuse to accept you're having sufficient experience with any of this if you'll be talking to me that you must absolutely have browser detection code branching to NEED to test in different browsers.

            I've seen my share of out-of-nowhere bugs in browsers trying to interpret code they normally support but fail to render properly, including stuff like Firefox improperly rendering the DOM tree if you nest relative and
    • http://www.domapi.com/ [domapi.com]

      It's not free for commercial use, but the licenses are cheap. It is a very powerful and robust toolkit, not only does it do AJAX but also has a ton of useful GUI widgets and other core functions.
    • Try DWR [getahead.org]. We use it in all sorts of places and it works beautifully (logged in now).
      • I can back up the parent on the fact that GWT is not at all suited for plugging into an existing application.

        I am in charge of a fairly large web app (hundreds of thousands of lines of Java, JavaScript, and AJAX). I looked into GWT when it first came out - it only took me about 20 minutes of fiddling with the demos to realize that a) This is a great toolkit for basing a web app off of and b) this is a horrible toolkit to tie into.

        The things that make GWT so great are what makes it near impossible to integr
  • The short description of GWT is:
    If you like the idea of web programming feeling like writing an applet, GWT is just the thing.

    Probably my biggest concern after evaluating it was the layout issue; though I guess the "AbsolutePanel" or that "Instantiations GWT Designer" Eclipse plugin might help... along with hunkering down and learning the damn CSS....

    Still, programmatic layout is kind of an odd duck.

    Also, is it "easy" to add in 3rd party javascript widgets, per se? Seemed a little akward, or at least un-GWT
      • A good point, I may have been a bit corrupted by HTML/CSS, but...
        I dunno, it seems like even old fashioned tables and CSS might be a more reliable way of accurately reproducing a screenshot into a screen...

  • I prefer Yahoo's YUI (Score:3, Informative)

    by mha (1305) on Wednesday March 28 2007, @05:12PM (#18521377) Homepage
    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]
  • I thought about buying a GWT book, but the general documentation at http://code.google.com/webtoolkit/documentation/ [google.com] made it simple to build and modify projects.

    See for yourself, use the section "Creating an Application from Scratch (without Eclipse)" at http://code.google.com/webtoolkit/gettingstarted.h tml [google.com] (using command line tools).

    I keep the GWT "Kitchen Sink" examples source handy to copy CSS, code, etc.

    GWT is very cool, especially if you need to build one large application. I must say though, if you j

  • Maybe this isn't targetted to me, but I just don't get it. I'm a solid Ruby developer, and Rails offers a similar feature, "RJS." You write your DOM changes in ruby, which gets compiled to javascript and executed by the client on an XHR call. This is fine for simple effects, but useless for real javascript apps.

    What's the advantage? Keeping everything in one language? That sounds like a wrapper for writing your C apps in assembly.

  • As you can see on Google [google.com] itself, there is already some (commercial) support for the GWT. Of course it always helps to know at least the basics of a toolkit even if you start to use an IDE GUI builder. But my experience with e.g. Instantiations is pretty good and the toolkit does not seem too expensive (and, you can see and change the generated code on the fly as well). Of course, if you really go for the GWT for a larger application, you need to know all the bits and bytes and you should at least buy one we
  • That's the big thing GWT is missing....clean support for uploading files
  • 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]

    • 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

    • AJAX shouldn't be a pain. Maybe your programmers are overly excited about it and want to throw the kitchen sink at every problem but that doesn't make the concept a bad concept. My general rule is to make it work without bells and whistles first, and then you can use clean methods like CSS and Javascript behaviors to improve the apps for people that have CSS and JS.

      Saying you don't need AJAX for anything isn't right. If you really can make your applications more user-friendly and avoid using bloated technol
    • For most AJAX frameworks, I'd agree with you. However, with GWT, almost everything is AJAX, so you're never asking yourself, "how can I use AJAX here?" It's closer to writing a traditional client-server app over RPC. The AJAX is very much "under the covers", so you never think about it.

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

      Well, there's you're problem. You shouold never look at the javascript code GWT generates anymore than you should look at the Java bytecode javac generates. Raw javascript might be OK for small applications, but for large, complex, apps it gets increasingly difficult to read, debug and maintain. And you can't build applicatio

      • it was most likely your title that started the tone for your responses. Myself, I didn't read your thread because of the title.

        LoB
Search
All phone calls are obscene. -- Karen Elizabeth Gordon

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.