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.
If you plan to use lots of Ajax (Score:5, Insightful)
I'm not impressed by Ajax (Score:3, Funny)
Re: (Score:2)
Re: (Score:1)
Re:If you plan to use lots of Ajax (Score:5, Informative)
I think you have that backwards. For anything but the most trivial of Ajax programming, you should use an existing framework. Trivial examples fall into what the Gartner group classifies as "Ajax Snippets" http://www.adtmag.com/article.aspx?id=17953 [adtmag.com], which are simply quick hacks onto an existing web applications. And really, if you're adding a lot of snippets to your existing web application you should still use something like Prototype http://prototype.conio.net/ [conio.net].
Sure, the basics of XMLHttpRequest (XHR) are straight forward and can be mastered by anyone. And sure, you can hack the DOM or DHTML old school style... but you really should ask yourself one question... why? There are so many good Ajax toolkits and frameworks that you really shouldn't concern yourself with low-level stuff like that. Additionally, truely rich internet applications (RIA) require a lot more than just basic snippets. I'm not a big fan of Gartner one way or another, but I do find thier classification levels helpful. For those who aren't familiar with them, here they are:
Check out the following to get a feel of what an RIA application is like:
Re: (Score:2)
Re: (Score:2)
Personally, I don't like the frameworks that attempt to emulate desktop GUI toolkits with JavaScript widgets and such, but I do think that starting from scratch rather than using a nice library basically amounts to asking for a series of long and pain
Re: (Score:1)
Re: (Score:2)
Links are DOA.
Re: (Score:2)
Ultimate?? (Score:5, Insightful)
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.
Hear! Hear (Score:1, Offtopic)
At least I think that's what was happening. Instead I did
str += 'select name=whatev'
then put all the options in, then did
innerHTML = str;
(If anyone can show me what I was doing wrong -- other than writing an AJAX app -- I'd appreciate it)
Re: (Score:1)
Re: (Score:3, Informative)
What were you expecting it to do? Once you give the HTML to the browser, it attempts to parse it, add it to the DOM, and render it. It can't do that if you've still got open tags. So it assumes that you forgot to close your tag, and closes it. The exact same thing would happen if you accessed the DOM through Java, C/C++, or any other language.
This just goes to show the problems with the innerHTML psuedo-standard. People think tha
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
var htmlText = '';
for(var i=0; i {
htmlText += ''+myoptions[i]+'';
}
htmlText = '';
mydiv.innerHTML += code;
Re: (Score:2)
Seems someone forgot the <ecode> tag...
Funny, this code looks a LOT like the example I posted above you. Especially since you appear to have forgotten to change this line. :-/
The basic DOM functions are about as browser compatible as you can get. It's the DOM0 and IE specific stuff that you'll get in trouble for.
Re: (Score:2)
Heh, for me it was the other way around. I wrote some JS to screen-scrape a page couldn't figure out why var fld = document.getElementsByTagName("input")["somefield" ]; wasn't working on IE. Then I read the spec and found that Moz/FF actually enhanced GEBTN() to return a node list indexable by a string, whereas IE stuck to the standard and just returned an integer-inde
Re: (Score:1)
Check this out:
http://www.bzbyte.com/a/shop/EZAjaxDescription.js
Re: (Score:2)
Re: (Score:2)
If you look up "ultimate" in the dictionary, you'll see it actually means "final" [oed.com]. Since there will clearly never, ever be another client-side application platform ever again, "ultimate" seems appropriate.
What are you looking at me like that for?
OK, OK. AJAX is the penultimate client-side platform. Happy now?
Re: (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 somethi
Re: (Score:2)
I know this because I have an "in" with the guy, so to speak
Re: (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 v
Re: (Score:1, Funny)
Re: (Score:3, Insightful)
superstitious (Score:2, Insightful)
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 clic
Re: (Score:2)
My money is on b.
Re: (Score:2)
Maxing out CPU on a shared server is actually really easy. With 100's to even 1000's of websites sharing a single server, you learn very quickly what can and can't be run effectively. For instance, if more than a couple people use the web based mail system on our server, we get CPU warnings... this doesn't mean we use up the whole CPU, just
Re: (Score:1)
Re:AJAX problems (Score:5, Informative)
While this no doubt happens all the time, the main advantage of AJAX-enabled web applications is reduced load on the server. For instance, our intranet application uses the Tapestry framework, and the built-in tables component (at least for the 4.0 version) was useless because it required constant, complete page refreshing when all you really wanted to update was the contents of a table. We rolled our own table component that's fully ajaxificated and it's been nothing but positive for our end users and our servers.
Re: (Score:2)
Re: (Score:2)
Actually, we made a couple of compromises to traditional MVC design because we wanted to be able to control the contents of the cell (i.e., instead of just displaying simple text, it could be a link, or an image, or a javascript control, etc.). This necessitated implementing a t
Re: (Score:2, Insightful)
"I've read several books " (Score:3, Insightful)
Who reads several books on a technology before they "try it out"?
Re: (Score:1)
"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: (Score:2)
Re: (Score:3, Insightful)
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
Re:"Ultimate client-side technology" ? FUD (Score:1)
Re: (Score:1)
Re: (Score:2)
In a nutshell: AJAX work pays my bills; it still is a band aid; far from "ultimate" worthy; I never said cross-platform (misnomver)/cross-browser was impossible (you still have to put up with all the crap that comes with...the *whole* architecture of HTML + CSS + JS not being implemented the same). Not intending to toot my own horn, but I've done things with AJAX that I haven't seen anywhere on the net.
So, in short: don't pig
Re: (Score:1)
I just think you're being a little pedantic about all this. Ajax is good stuff and it's going to get better. What should we be using? Flex? Applets? ActiveX controls God forbid?
Let's keep a positive attitude and we'll defeat the terrorists one absolute positioned div tag a
Re: (Score:2)
The original claim was that AJAX was the "ultimate client-side technology" and if I have to be pedantic to explain why it's not then so be it. Is AJAX an improvement over the absence of it? Sure, I never claimed to the contrary, but this also not the line of discussion.
I described a couple attributes of what would be "more ultimate" since AJAX clearly is being used (or is trending that way) for things it can't do and is based entirely on non-stand
Incorrect. (Score:2)
Wrong. Read up on Comet request processing. For Jetty [webtide.com], for Tomcat [theaimsgroup.com], and for Glassfish [java.net].
Re: (Score:2)
Of course client/server designs in general aren't designed for servers to contact clients. Otherwise, you have something more like peer to peer.
Re: (Score:2)
Yes to the first part, no to the second. They use a keep-alive so the connection isn't closed, so you're right if you count the initial request for a page (which is initiated by the client). But that's not polling, which is repeated requests from the client. Once the connection is instantiated, you only need to keep the connection alive, but you don't have to keep as
Re: (Score:2)
Also, your problem with waiting on Google's app without notification would be there in a normal desktop app too: AKA: the issue is simply that the GUI didn't put the proper feedbacks. Nothing in the typical implementations of AJAX prevents the developer from adding such notifications ---> if
Echo2 is good! (Score:1)
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.
Re: (Score:2)
As an example, Flash can do above and beyond that of HTML and JavaScript, and people use it because everyone has it.
Playing to the largest audience, not tradition, is why we stick to our guns, as it were.
Re: (Score:1)
No, it's not tradition. It's all about installed-base inertia - many millions of online platforms that already grok html and javascript. Anything new faces the twin hurdles of fear and sloth or consumer resistance in marketing terms.
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: (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 anyw
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.
The AJAX flagellation sect (Score:1, Insightful)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
The only AJAX I've heard of is the DHTML rebranding that presumes scripting is enabled and breaks the back button.
Well, let me introduce you to some more useful and entertaining [english.ajax.nl] ways to use Ajax.
Re: (Score:1)
D'oh, missed a closing quote on the first link [colpalcommercial.com], and slashdot scrubbed it.
Re: (Score:2)
Re: (Score:1)
Icefaces (Score:3, Interesting)
Check out their Component Showcase [icesoft.com].
Java BluePrints also has guidelines for Java/Ajax (Score:1)
Ajax this, Ajax that. (Score:3, Interesting)
Totally agree. HTML injection == Coding Horror!!! (Score:2)
IMHO, AJAX and dynamic Javascript-based HTML injection really have very few use-cases where they should be used. Take for example Google Maps. If you want a dynamic application (from a browser) that graphically interacts with the user in a virtually real-time fashion, you are going to have to resort to AJAX and HTML injection.
But why in the hell would you use AJAX for a plain-old form-submission and a response page? Or for
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]
Re: (Score:1)
Re: (Score:2)
By the way, Grand Strategy looks very nice indeed, I'll enjoy giving it a closer look as time allows.
Re: (Score:1)
AJAX - which one (Score:1)
Interesting comment. I hosted a meeting here last week and someone mentioned Ajax. Several people hadn't heard of it. Main contenders were either a domestic cleaner or a Trojan war hero.
Atlas! (Score:1)
No more having to come up with all kinds of weird JavaScript to do the simplest things. Throw a few normal controls inside of an UpdatePanel, set your triggers, and you've suddenly got a much more responsive web app.
The whole ScriptManager makes it insanely faster to c
"Ultimate" crap again ... (Score:2)
And pray tell me, when and WHO have bestowed the ultimateness over ajax ? Its just another mesh-up of old existing stuff, all of which were not ultimate "technologies" when they came up, and all of which have not became "ultimate" any time after, just as ajax. Just another "new" thing, like many other "new" things to come in future.
That seems like a stupid rant in order to boost up
Not quite true. (Score:2)
Not quite true. You can use an XMLHttpRequest to pull data from any site, if you know where in the document to look. Even if the page returned isn't well-formed XML, you can still screen-scrape, then put the data to use on your page.
One acronym. WCAG !!! (Score:1)