GWT Java AJAX Programming

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

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

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

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

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

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

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

---

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

Web 2.0

[D-Cypell]

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

[jesterman]

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.

Web 2.0 can be very much like Unix-style programs.

[MikeFM]

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

Re:

[namityadav]

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

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

Re:

[Shawn is an Asshole]

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 it uses Java.

[MikeFM]

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

Re:

[salimma]

Too bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require.

You can use Groovy [codehaus.org] with it, you know =)

Re:

[MikeFM]

Am interesting point - I suppose I could develop code in JPython and compile it with GWT. I usually use Python for my non-web GUI apps so that could be a workable concept.

Still, it's not significantly easier IMO than developing with Javascript and CSS so long as you have a framework that's already developed the widgets and worked out the compatibility issues.

Just a side rant.. I have to say that I really hate Internet Explorer. Even IE7 has significant problems with it's Javascript and CSS which require hou

Re:

[salimma]

I have an odd feeling that the reason IE developers are draging their feet on standard compliance is that they want to move web developers to using Visual Studio.NET for anything non-trivial.

VS.NET's WebForms does greatly simplify the development of web applications - they behave just like normal WinForms applications -- but you can only select HTML 4.0, Netscape 4.7, IE 4, 5, and 6 (this was back in VS 2003, if I remember correctly).

All of these frameworks are mostly overkill

[roman_mir]

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:

[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.)

Re:All of these frameworks are mostly overkill

[roman_mir]

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

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

Re:

[LuisAnaya]

Well, please reconcile the statement "simple java script" and long list of javascript code that you posted? That was a heck of a punch line :).

Re:

[roman_mir]

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:

[AKAImBatman]

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

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

Re:

[Sancho]

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:

[roman_mir]

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:

[SwiftOne]

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

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

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

Re:

[roman_mir]

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.

Re:

[roman_mir]

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

Re:

[s2jcpete]

Following your logic, anything beyond assembler or the abacus would be overkill to.

Re:

[roman_mir]

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:

[s2jcpete]

Are you posting via lynx?

Re:

[roman_mir]

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:

[s2jcpete]

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:

[roman_mir]

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.

Re:

[as6o]

Programming down to the metal is fine and all, but it often unnecessarily complicates the application, forces developers to write a lot of very tedious code repeatedly, and prevents developers from concentrating on the business functionality of the application. I think AJAX is AJAX and that developers should use the technologies and patterns that they are most familiar with in order to be the most productive. Besides, they almost all support AJAX to some degree and usually abstract away all of the rote an

Re:

[MikeFM]

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

Re:

[Sancho]

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:

[MikeFM]

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

Re:

[Serveert]

From what I have read, the GWT compiler attempts to minimize javascript code on the client by only providing code that it uses.

Re:

[erik.martino]

It's true that you can get far by a small amount of code without a framework. However in my experience, as complexity grows, javascript suddenly gets very hard. It is important to encapsulate complexity, which your code show nothing of. The main advantage of GWT is static types, and the ability to use a known language and mature development tools. The GWT framework is too low level in my opinion though. I don't wan't to download dubious 3rd party libraries that may or may not work.

Re:

[phaggood]

> I don't wan't to download dubious 3rd party libraries that may or may not work.

Tho your example may be more security minded, it made me think immediately of Delphi, the most productive app development system I ever used. My favorite feature was the visual form inheritance; with it I was able to visually generate data-aware interfaces in minutes. The only weak link in Delphi for me was the 3rd parties; Borland would release a new version with must-have upgrades and I some important 3rd party widget

Re:

[mr_e_cat]

Well I agree with you anyway, even if no one else does. Javascript is an underrated, powerful language. The sheep will have moved on from Java to the next 'Silver Bullet' in 5 years. How trendy is C++ now?

Any good programmer can code whatever subset he requires in the time it takes to understand and work around all the generalisations and limitations in a framework.

These Java guys have all their self esteem tied up in their choice of language and can't bear the thought that there are other ways of doin

Re:

[design1066]

notice how your script will only work in internet explorer

Re:

[roman_mir]

This script was tested in IE6 and FF 1 and 2 and it works in both. I never write for IE only.

AJAX is Irrelevant

[Anonymous Coward]

Actually, it's worse than irrelevant - it is a real pain. From a lead programmers point of
view in a web-based billing environment, it's a chore trying to keep the kids focused on the
(perhaps boring) task at hand and keep them using clean, simple, classic CGI programming
techniques. 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. Invariably, I ask them to describe the problem that

Re:

[Locutus]

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

AJAX is NOT irrelevant...

[javabandit]

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

Re:

[MikeFM]

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

Re:

[enomar]

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.

Re:

[DrFalkyn]

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

My experience with GWT

[hansamurai]

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

Re:

[CastrTroy]

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

Re:

[SnapShot]

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:

[xannik]

You shouldn't need to know what the compiled javascript looks like. If you need to access methods within your compiled JavaScript you can use JSNI to create hooks into your google web app. This way you can write your own external methods in javascript and set/get data in the compiled google web app. I had an existing inventory system that I implemented this very way. Perhaps you had other issues besides this, but if this was your main reason perhaps GWT deserves another look. I have found the code to b

Re:

[brunes69]

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

Re:

[xannik]

Just out of curiosity what were you going to use GWT to do in your web app? For instance, if you have your existing AJAX framework that was communicating with your server and fetching the data and all you wanted to do was say display that data, perhaps in some sort of tree structure or whatever, you could write a JSNI method for your GWT code that accepts the data from the existing ajax framework. So in this case your existing AJAX framework would be doing the heavy lifting of communicating with the serve

Re:

[Anonymous Coward]

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.

Re:My experience with GWT

[bwt]

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.

Re:

[suv4x4]

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

Re:

[bwt]

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

Re:

[suv4x4]

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

Re:

[suv4x4]

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

Re:

[Raenex]

I use a very simple library which is a subset of Prototype (the popular JS library)

What library is this?

Re:

[suv4x4]

What library is this?

I created it on my own for personal use (I don't like all of the things Prototype chose to do).

This is the original library [prototypejs.org].

Re:

[Raenex]

Hmm, ok. Could you explain what you changed?

Re:

[suv4x4]

Hmm, ok. Could you explain what you changed?

Merged the $ and $$ selectors, I dropped the "enumerator" extensions, I altered the way classes are created and so on.. But why are you so intensively interested in what I changed :D

FYI I change things as I suffer mild to moderate NIH syndrome :P I just see a better/more standard way to do something and prefer doing it this way. Prototype is trying too much to copy other languages which I do not care about.

Re:

[Raenex]

Thanks for your answer. The reason I'm interested is because I'm looking to do an Ajax-based web app after having been out of the web development game for a few years. It helps to know what people like/don't like about the various frameworks.

Re:

[m50d]

Bear in mind that quite often that has been deliberately "compressed" (by renaming variables etc.) so it downloads faster, compared to the copy that is actually worked on.

Look into DomAPI

[brunes69]

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.

Re:

[kevin_conaway]

Try DWR [getahead.org]. We use it in all sorts of places and it works beautifully (logged in now).

Re:

[anton_kg]

I would stick with any toolkit which you have a control on. If you know a bug in Dojo - open a bug file. Sign a paper and send it to Dojo developers if you have a patch and want to fix it yourself.

Re:

[Dan Berlin]

What do you mean?
GWT is open source and accepts external contributions.

the issue of layout

[kisrael]

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

Re:

[Tablizer]

If you like the idea of web programming feeling like writing an [Java] applet, GWT is just the thing.

In other words, GWT is dead ;-)
             

Re:

[random0xff]

Still, programmatic layout is kind of an odd duck.

Only if you're used to doing it with HTML and CSS. A basic layout often seen in desktop applications is the borderlayout. This layout can not be created with HTML and CSS without the help of javascript (onload and onresize event handlers to keep everything in place). So when you need layout such as these, you need to program them, you can't 'declare' them. Have a look at the demo (Desktop App Clone) on the GWT website to see what I mean.

Re:

[kisrael]

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

"Hello World" with GWT

[A Friendly Troll]

Opera's Hallvord [opera.com] blogged a bit about GWT yesterday. He doesn't seem to like GWT much [opera.com], and neither do I, based on what I've seen there.

I'm all for faster and easier development, but when such an app gets stuck on the client side, then you are in a lot of trouble; at first glance, it looks undebuggable (if that's even a word).

Re:

[nate nice]

But at second glance you realize it's very debuggable because you run in client mode. That is, you debug Java, the same Java you wrote.

A lot of people don't understamd this technology.

Works for me.

Re:

[A Friendly Troll]

I was thinking more along the lines of "View Source" and debugging HTML and CSS. Other examples might be different, but for this one, you have to look at the generated source somehow. Also, if there's no source, search engines go crazy, and screen readers for visually impaired people aren't very useful.

I prefer Yahoo's YUI

[mha]

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]

JBoss Seam with Seam Remoting and AJAX4JSF

[jazir1979]

Try looking at the above if you need a web-app where you can use AJAX as required, but also require full JEE integration including OR mapping with EJB3/Hibernate and a strong GUI component/event model. It makes the disjoint between the various JEE tiers SEAM-less.

GWT online documentation is sufficient

[MarkWatson]

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

Re:

[account_deleted]

Comment removed based on user account deletion

IDE tools available as well

[owlstead]

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

Unfortunately AJAX

[Anonymous Coward]

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

upload tag

[kisrael]

That's the big thing GWT is missing....clean support for uploading files

GWT in production

[kilkenny]

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]

Last Summer of AJAX

[Markavian]

I spent all my last summer looking into the XMLHttpRequest object, Google maps, Local Live, Dojo, prototype.js, and found them to be very resourceful and capable tools for developing web applications. Most useful for FireFox 2 for debugging js. Any programmer can take an idea and make it fly in a matter of weeks (that was my commerical task, find out the possibilities).

Since then, I've moved jobs and settled back into normal web dev. Web 2.0 is a distant memory, a tool to smooth over the mudane page refresh