Forgot your password?
typodupeerror

Practical Ajax Projects with Java Technology 98

Posted by samzenpus
from the more-ajax dept.
Simon P. Chappell writes "Is there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers? Like many, I've read several books on it and now I'm even brushing up on JavaScript so that I can try it out. There is, however, an aspect of Ajax that often seems to get lost in the rush to play with the new browser tricks; Ajax enhanced web applications still need to work closely with server-side components. To even up the balance of books that concentrate on the browser end of Ajax, Apress brings us Practical Ajax Projects with Java Technology by Frank W. Zammetti.
Practical Ajax Projects with Java Technology
author Frank W. Zammetti
pages 504 (16 page index)
publisher Apress
rating 9 out of 10
reviewer Simon P. Chappell
ISBN 1590596951
summary A useful and practical book for those wishing to write web applications that combine Ajax front-ends with Java technology on the server-side.


This is a book for anyone developing web applications with Java server-side components. It does assume a minimum level of Java ability, but not that you should know any specific frameworks. If you know basic Servlet and JavaServer Page programming, then you'll be fine for working your way through the frameworks presented in the book.

The book is divided into two parts. The first part is just three chapters and covers the principles of programming using Ajax and Java. Chapter one is the "hurrah for Ajax", obligatory examples and brainwashing. A discussion of the "classic web" and its problems leads into examples of the new web and Ajax enhanced websites. Chapter two is an introduction to the technologies behind Ajax for those who may be less familiar with JavaScript, the DOM, XML and parsing XML using JavaScript and Cascading Style Sheets (more usually known by its acronym CSS). Don't expect to learn these technologies from scratch out of this chapter, but if you have some amount of exposure to them, it will remind you of all the bits that you'll need for Ajax. Chapter three then does a similar thing for the server-side Java technologies. Again, if you snoozed through Java classes at school, don't expect this to get you caught up, but it will refresh your memory on the useful pieces.

The second part of the book holds the seven example projects. These are the meat of the book, given that the title promises practical projects and I think that the book pretty much delivers on its promise All seven projects are interesting; six are practical and the last one is just good old fashioned fun. The projects build in terms of size, so the first one is the simplest and the game, coming last is the most complex. The first project is a type-ahead suggestion engine, modeled after Google's Suggest. Next we have an Ajax-based webmail client. Chapter six builds a RSS newsfeed reader (because, as the book says, every Ajax book has to have one). Chapter seven is a photo sharing application, which, while it may not compete with Flickr, is quite usable for its size. Chapter eight is an organizer. Umm, needless to say you'll either love this or ignore it. (What can I say? If I was organized enough to use an organizer, I'd be organized enough not to need it!) Chapter nine brings yet another chat program to the world.

Last, but as the phrase goes, not least, chapter ten is the grand finale of the example projects. As befits the author's fine sense of humor, the final project is a game; Ajax Warrior! This application has graphics designed by a professional graphic artist and looks far above any other example application that I've ever seen.

As soon as I saw that Mr. Zammetti had written a book, I rushed to be the first to volunteer to review it. This will need no explanation to members of the Struts mailing list, but for the rest of you it might help if I explain that he is that wonderful combination of a funny and helpful guy. I knew that anything he wrote was going to be first rate technically and was also going to be written in a light and relaxed style; always a winner in this kind of book.

I liked the fact that Mr. Zammetti covers a number of approaches to writing both the client and server-sides of the applications. For the server-side of a number of the applications, he uses plain JavaServer Pages, yet for others he uses industry-leading frameworks including WebWork and Struts. On the client-side he continues to mix it up, with some applications using "naked" Ajax, others using DWR, AjaxTags from Java Web Parts, DWR, Dojo, JSON and Prototype.

One more thing to like about the book is that the applications actually look very nice and quite professional. Perhaps the folks at 37signals shouldn't be nervous, but Mr. Zammetti has certainly raised the bar for the appearance of example applications for books.

The flip side of the use of multiple frameworks and Ajax libraries is that all of the breadth means reduced depth. Each of the frameworks and libraries is introduced and demonstrated, but then just as it begins to get interesting, it's off to the next one. If you're looking for more depth in each introduced item, then this book may not be for you.

In conclusion, this is a useful and practical book for those wishing to write web applications that combine Ajax front-ends with Java technology on the server-side. Strongly recommended.


You can purchase Practical Ajax Projects with Java Technology from bn.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.

Practical Ajax Projects with Java Technology

Comments Filter:
  • by CastrTroy (595695) on Monday October 23, 2006 @03:47PM (#16550688) Homepage
    If you plan to use lots of Ajax, it's probably better to build your own framework rather than using 3 different ones so that you have all the functionality you need. There really isn't all that much to AJAX, and it's not to hard to build your own framework to support all the features you need.
  • Ultimate?? (Score:5, Insightful)

    by Reality Master 101 (179095) <RealityMaster101 ... m ['gma' in gap]> on Monday October 23, 2006 @03:56PM (#16550818) Homepage Journal

    ...the ultimate client-side technology for web developers?

    Er, I like some of the results that people have made from AJAX, but to call it anything like the "ultimate client-side technology" is utterly bizarre and casts extreme doubt on the reviewer's credentials to review anything computer-related. I think it's safe to say that everyone that has studied AJAX has one overwhelming common opinion:

    "For the LOVE OF GOD! Why the hell in the year 2006 do we need to write anything in this godawful buggy language? There HAS to be a better solution. THERE HAS TO BE! STFU, there HAS to be! Please, GOD, there must be!! [breaks down in tears]"

    If AJAX is the "ultimate", then we might as well all take the poison kool-aid, because human civilization is an abject failure.

  • by truckburnt (1017180) on Monday October 23, 2006 @04:12PM (#16551044)
    "Like many, I've read several books on it and now I'm even brushing up on JavaScript so that I can try it out".

    Who reads several books on a technology before they "try it out"?

  • Re:AJAX problems (Score:3, Insightful)

    by thelifter (1017186) on Monday October 23, 2006 @04:23PM (#16551236)
    If you're maxing out CPU, you have problems bigger than the use of ajax. Ajax usually results in using the same bandwidth differently. You make more server requests than a traditional app, but the requests exchange smaller amounts of data. It's possible to misuse any technology and blame the technology for your own incompetence. Sounds like you've achieved the latter.
  • Put another way: it's a poll technology. There is no way to allow the server to initiate a connection to a client.

    Mainframes worked the same way, and that didn't stop them any. In fact, it would be stupid to have a server trying to contact a bunch of firewalled client boxes out on the Internet. Besides not being scalable, the pull design of the web ensures that the clients are protected against exactly that sort of communication.

    I think the issue you're concerned about is that there's no way to maintain an open channel. i.e. IRC maintains an open connection. Telnet maintains an open connection. FTP maintains an open connection. Pretty much everything except AJAX can maintain a connection rather than having to poll for the latest content at regular intervals.

    I agree that such a design can be annoying, but it's something of a requirement for the web to function properly. Right now, you've got a few ways around this:

    1. Use Mozilla APIs in a signed web application to obtain a low-level TCP/IP connection.

    2. Find a Draft Web Application standards compliant browser, and use that so you can open a TCP/IP connection. (Good luck on that.)

    3. Use the Livescript interface between Java and JavaScript to maintain a TCP/IP connection over a hidden applet.

    4. Use an IFrame pointing to a servlet that keeps the connection open. Every time the server wants to tell you something, it "pushes" (i.e. writes and flushes) a few JavaScript commands down that pipeline. Those commands get executed immediately, thus providing a remote event system. The JavaScript code monitors the connection and automatically reconnects if the connection is lost. (This is what most web<->IRC portals do.)

    5. Redesign your application. You're probably trying to do something that's a bad idea in the first place.
  • Re:AJAX problems (Score:2, Insightful)

    by Bill Dog (726542) on Monday October 23, 2006 @05:05PM (#16551900) Journal
    Writing code that uses more network bandwidth than you've got is not an AJAX problem. It's a "writing code that uses more network bandwidth than you've got" problem. One could achieve the same thing in Java. That doesn't make it a Java problem.
  • by Anonymous Coward on Monday October 23, 2006 @05:07PM (#16551944)
    Is there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers?

    Yes, me. The only AJAX I've heard of is the DHTML rebranding that presumes scripting is enabled and breaks the back button. AJAX is something for idiots to inflict on themselves.

  • by LDoggg_ (659725) on Monday October 23, 2006 @05:16PM (#16552086) Homepage
    Ajax only breaks the back button when it us use for a site's navigation.
    This is just as bad as when someone develops a site entirely in flash.

    Sure the technology can be misused, but the fact that some people misuse it, doesn't make it a bad technology.

  • superstitious (Score:2, Insightful)

    by Bill Dog (726542) on Tuesday October 24, 2006 @02:19AM (#16556354) Journal
    AJAX is not some magical voodoo that is somehow uniquely capable of bringing down a web server. All it is is a means for doing an HTTP request, just like for a web page, in the background, without re-requesting and re-rendering the whole page. That's it. Just HTTP requests to a web server.

    If you want to use it to make a web page that hits the server on every mouse click, you can. That's your business. But you could also code it up the traditional, non-AJAX way, to also hit the web server on every mouse click. AJAX is no more the problem than submitting forms is.

    I must say, our existing CGI-based solution worked far better.

    That's not an alternative to AJAX. I'm building an AJAX app that is serviced via CGI. CGI is just a way to respond to a web request. Whether a form post, a get request, or an AJAX request. It sounds like you don't really know what you're talking about.

Practical people would be more practical if they would take a little more time for dreaming. -- J. P. McEvoy

Working...