Practical Ajax Projects with Java Technology 98
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.
"Ultimate client-side technology" ? Please! (Score:3, Interesting)
Hah! Ultimate? Hardly.
AJAX is a hack to add more "dynamicallness" to web sites. HTML currently relies on HTTP and HTTP suffer a fatal flaw: it is client-initiated. Put another way: it's a poll technology. There is no way to allow the server to initiate a connection to a client.
As sites integrate more and more AJAX you tend to notice that what they are ultimately striving for is a standard desktop application. But it won't work as is and so AJAX is just a mere band aid. Ever try to use Google calender or gmail with a slow/latencied connection or when their servers are busy? I've had to wait over 30 seconds for an event to display in their calendar without any GUI notification that it's working. This can be mitigated but my point that such failures as a GUI are prevalent in AJAX applications because they're trying to be something they can't -- a desktop app.
I don't care how nifty AJAX makes web sites but don't call it "ultimate". Please.
No, the "ultimate" technology will not include HTML, HTTP, or JavaScript in their current incarnations as all have fatal flaws that just can't measure up to a standard desktop app in terms of functionality. This would be fine if the goal was different but it's not and it's precisely why (all things being a equal as possible) I will never bet on an online office suite trumping a true desktop app.
Nevermind that what web apps are heralded for -- cross-platformness -- requires a lot of effort to make happen. IE, FF, opera, and safari just don't act the same way in terms of rendering and JS functionality. There are so many things working against this AJAX movement that I'm amazed that it works (mostly).
Re:GWT / Echo? (Score:3, Interesting)
*The book's goal is to teach you how AJAX actually works through coding JavaScript and JAVA in a sampleproject. GWT (I'm not real familiar with ECHO) very much abstracts what's going on at the browser level. In short, you could make AJAX apps with GWT, but you wouldn't really learn how AJAX apps function. For the purposes of illustratring how AJAX works, the libraries in something like Dojo work better.
*There is a surfeit of libraries and tools for AJAX. I've seen plenty of books that just catalog libraries; unfortunately, that broad coverage tends to keep you from using the technology in depth. If anything, until you start using one set of tools, you never really know what best suits your needs. It seems like it doesn't focus on just one toolkit anyway.
In short, the books gives you exposure to a few different libraries as you work through the projects so you can make a more informed choice later when looking at tools like GWT.
Why? (Score:3, Interesting)
Does anybody else get the same feeling when working with the web? We have had incredible advances in technology yet we keep using HTML and JavaScript as our base for no other reason than tradition and because that is what people expect.
GWT (Score:3, Interesting)
I believe this is the real benefit of AJAX methods that go beyond the asynchronous client/server communication.
Now you write Java programs that are compiled into complete Javascript programs that work on IE, FF, Safari and Opera with generated DHTML, etc. You use whatever you want back on the server side. The Javascript generated for you will probably be as good as anything you can write in JS and most likely more complex and better tested.
This is such a better parigdim than having the server create these user forms and controls using minimal Javascript and then posting back for more forms. Or simply sending all the forms over in a bloated DHTML mess. Now we have actual programs on the client side that behave like Websites and rich clients.
Make a site in GWT and see how easy and fun it is. It's a whole different world of Website and very clearly the future. Maybe not GWT, but having a Javascript program as the Website and the server agnostic. I would assume we will see better Javascript caching and a client/server versioning system to make sure users have the latest version of a site making for insanely fast Websites that are downloaded once with only calls for content and no longer infrastructure.
Re:GWT / Echo? (Score:3, Interesting)
Why just tell people they could use these amazing toolkit paragdims when you can sell them a book explaining how the pipes run?
GWT and Echo and related technologies are really great. I like GWT more because of it putting everything client related on the client side. I see this as the future of Web programming and we will see more and better tools to facilitate this. One being better program caching with checksums and client/server versioning to allow for download once, run every time Websites in the EOC (Everything On Client) model.
Icefaces (Score:3, Interesting)
Check out their Component Showcase [icesoft.com].
Re:GWT (Score:3, Interesting)
GWT, to me, is very cool technologically. I certainly appreciate the heck out of it as a coder. It's definitely a beat product.
But as someone who is involved in determining how things get done at work, I'd have a very hard time ever recommending it for anything but small projects that a single developer could do.
For years we've all (most of us anyway) been striving for that goal of having page designers, those that are good from an artistic standpoint, and the coders who take the pure markup and CSS and add the bits that make it work. GWT turns this approach in it's arse because now you need coders to do it all. Oh yeah, you can have the graphic artist sitting next to you during development, but that's not nearly the same thing. GWT reduces web development to pure coding, and I think that's the opposite of where we've been trying to go for years.
Now, I don't know how many organizations actually realize this separation... I suspect not as many as those pushing that idea would suggest... but that doesn't mean it isn't the goal to strive for (unless you really just plain disagree with the concept in the first place).
I've been doing Java coding for quite a few years now, and one of my least favorite things to do is GUI development. Java always, to me, made it more convutled than it should be. Bringing that to webapps doesn't strike me as a great idea. I realize some people feel quite the opposite on this point and really love GUI development in Java, but that's my opinion anyway.
It's just my opinion, but I view GWT as something that is great for those small projects where your only going to have a single developer anyway, but I don't view is as quite as suitable for larger projects where you want there to be a difference between the page designers and the coders.
Re:GWT (Score:4, Interesting)
You mention that now the coder has to develop the GUI and do the CSS. This is totally wrong. If the CSS classes are defined ahead of time, the programmer simply has to set them and all the different CSS states a UI object will have. this is usually done in the design segment of the software lifecycle.
Now the graphic artist can work on stylizing a Website and developing images, etc. They can also design the layout and have the programmers make sure each UI widget is in a panel that lays this out. Then, once again, the graphic designer styles the work.
And really, GWT doesn't make you do much GUI design at all. After the layout is done, a programmer only needs to create each UI object and be done with it. No different than in ASP.net or any other server side UI creation scheme.
GWT is amazing in that it forces the development to look at CSS as the designing part and Java as the logic part. The logic sets the design, but this isn't atypical by any means.
And GWT in my experiences has been successful on fairly large projects. It's fast, the easiest to debug for any Website and fairly compact.
I believe it's a radical shift in the paradigm of Website development and a great one at that.
I love the idea of a Java to Javascript/DHTML compiler, CSS centered design and wonderfully encapsulated asynchronous client/server communication. GWT allows you to make complex Web Apps that were near impossible to make a year ago.
I see the light anyways. And it's only going to get better. It makes Web programming more like programming. It's what I've dreamed of for years.
Ajax this, Ajax that. (Score:3, Interesting)
Anyone writing Ajax games? (Score:3, Interesting)
It is by far the most sophisticated Ajax base game I have seen. I'd be interested in comparing it so other Ajax based games.
Has anyone seen or developed an Ajax based game I could take a look at?
Grand Strategy [denizengames.com]