Book Excerpt: AJAX Warrior


News: Book Excerpt: AJAX Warrior

  1. Book Excerpt: AJAX Warrior (4 messages)

    In Practical Ajax Projects with Java Technology, author Frank Zammetti provides a learn-by-example experience, featuring the planning, design and implementation stages of seven complete example applications. Included among the applications are an Ajax game, a Webmail client, and a Flickr-style photo gallery application. Technologies covered include Apache, Ant, Ajax Tags, Struts, Prototype, DWR and Dojo. In chapter 10 of this book, titled "AJAX Warrior: Back to the Future in a Fun Way!", Zammetti walks through his final Ajax project, a game. With this example application Zammetti covers "naked" Ajax (not using a library or toolkit), JSON, and CSS and DOM scripting techniques. Associative arrays and a new server-side framework are also discussed. After walking through planning, design and implementation stages, readers can see the fruits of their labor firsthand, and play the game.

    Threaded Messages (4)

  2. I've never used AJAX. I have written VERY complex javascript and found it to be a horribly unstandard language which broke differently on every browser (IE 5 on Mac doesn't understand the [] syntax of arrays, Firefox on Windows loads JS files in a different order to running scripts on the page to IE 6 on Windows, Applet init() methods get called at different stages ... horrible). One thing I hate about javascript is that there is no way to control your threads. If I have a CSS page downloading, how can I know when it is finished? Well in IE I can have an onLoad="callme()" on the link tag. In Firefox I have to keep running a check on a style I know will be there every 50ms or so. But then the thread it runs it will go off and run some event handling code while other JS files are still downloading because CSS gets downloaded in parallel to JS and not in-order. So how do I control the effects between the threads? I have to use ready-wait states with local variables. Arrggg. All this made me very jaundiced towards AJAX and here's why: If I have a slightly slower than usual network connection and I'm playing this game of his, won't clicking to "pick up" some artifact generate an AJAX call thereby filling in the "request" property of his object? Well then clicking again quickly before the first request ends, will result in his code thinking that it is the response rather than another click and try to handle the response, close the request while it is running and screw up the game. How on earth do AJAX frameworks handle this sort of thing? It must happen a lot because this is after all a NETWORKED environment. Looking forward to some clarifying answers. Michael
  3. The clarification[ Go to top ]

    The only clarification you can get for your real world experience of the AJAX world is this: using AJAX for designing an app is suicide. Tipically, the enthusiasm a developer experiences for AJAX is inversely proportional to the experience he has on it. While some hazardous problems like javascript syntaxis can be somewhat diminished using incredible toolkits like GWT or Echo2 (I call those frameworks incredible because it's really admirable what a number of really capable developers have accomplished while taming a so crappy technology like DHTML and Javascript) in the end it is so hard that it gets in your way. The only place I can see for Ajax is in little embellishments of some web site. Even with that, be careful...
  4. "True developers write HTML with vi". It is a real phase from the very past. Then, true developers programed with Perl. Today, there is a new vogue - True developers write Ajax with Javascript. For me, developing the modern web applications with Javascript is some sort of masochism. The technique of asynchronous communication between browser and server announced and re-announced during the last and an half year already. It is a good time to build high level abstraction on the top of the popular technology and shift the developers' energy from "how to do" to "what to do". Should everybody understand the idea of XMLHttpRequest well to write Ajax-enabled rich applications? Just a several years ago, it was absolutely necessary to know HTTP protocol specification. How many web developers have an idea what is written inside this specification? -- Sergey : Ajax4jsf Open Source Framework
  5. Some responses...[ Go to top ]

    Hi folks... let me see if I can address some of the questions/issues raised in the first few posts... First, about Javascript being a difficult to understand language, or being broke differently on various browsers... I suppose it will always come down to a matter of opinion, but I don't myself view Javascript as any more difficult to understand than most other languages out there. I'm doing probably 95% Java development at this point in my life, and I certainly wouldn't say Javascript is any more difficult to understand than is Java. Someone may come along and claim Ruby, or any of 100 other languages is an easier language to grasp, and for them it may be true, but I don't think most people are scared off by Javascript's "complexity" these days :) About it being broken in various browsers... yes, that's true to a degree. However, over the past maybe 2-3 years, the brwosers have all pretty well implemented ECMA standards, so you won't find a whole lot of issues these days. True enough, some still exist, and of course they tend to bite you hardest on a weekend at 10:30 at night trying to meet a Monday deadline :) I for one don't think calling the situation "horrible" is really fair any more... a few years ago, absolutely yes, I'd agree, but not today. Today its managable, albeit not perfect, if you stick to standards. On the issue of threads... It's certainly true that some things can be difficult because the language is not inherently threaded, and you certainly won't find things like synchronization, mutexes and critical sections to deal with (for better or worse!). However, because Javascript uses a single processing thread in all implementations I'm aware of, it in fact makes some things easier... you can usually get away with simple locking mechanisms based on variable values and such. Take a look at the source in this chapter of my book for instance... the issue raised about picking up an object can't really happen because of the way the code is implemented. Now, some can argue that it's in a sense making an asynchronous request into a synchronous one, and while not strictly accurate, there's a nugget of truth to that. In the case of this particular project though, it makes sense to do it that way, in other cases it might not. As for using AJAX being suicide... well, having written a book on AJAX, something would be wrong if I actually agreed with that, right?!? :) I don't think its suicide, at all. In fact, with more RIA's coming online, I'd say its probably more suicidal to ignore it! I don't think there is any question that AJAX, and Javascript in general, can somtimes be tricky. No one should underestimate the expertise needed to do it well! Even beyond the pure implementation details, there are a lot of considerations that go into it, i.e., accessibility, complexity, training, etc. So should you approach with some caution? Yeah, for sure. Then again, I'd give the same advice about Hibernate, Spring, JSF, EJB, and virtually everything else. NEVER make a technology decision because its the hip new kid on the block, and don't just assume something that everyone tells you will make your life easier is going to be easy and smooth from the start! Diego mentions toolkits, and I think this is an excellent point. There are tons of AJAX/Javascript toolkits and libraries out there to choose from. Some are excellent, some not so much. Unless you have a good reason not to use one, like in this game project for instance where I needed to have full control over things (and also because its specifically written for a book as a learning tool!), I would advise against using "naked" AJAX. Other projects in the book do in fact use various libraries, and in my day job we use libraries as well. I'm not myself a huge fan of GWT, but Echo2 certaily looks very cool, and others are also fantastic (Dojo, DWR, APT, etc). Regardless of that though, the point is that either any of them can save you from a lot of problems associated with AJAX and Javascript, and even putting aside the problems they avoid, they also tend to save you time, and that's a Good Thing(tm). As Sergey mentions, most of the time, aside from debugging, you don't have to know all the details of HTTP to do web development. Likewise, having to know all the details of XMLHttpRequest is generally not required. There will always be times when that knowledge helps, but generally, it's extra. That's why something like my own AjaxParts Taglib is a really nice thing IMO... it avoids even having to know Javascript, which probably most other libraries do require, to some degree. Either way though, your not dealing with *all* the details, and that's what ultimately matters. As I say pretty clearly in my book, AJAX is far from a new concept. I have an app, still in production today, that I wrote in 1998. You hit the initial URL, and you download about 300k of markup, most of it in hidden
    s. Then, as you work, certain
    s we hidden or shown as appoppriate, and the fields in them populated with data. When the server is needed, the request is sent through a centralized bit of Javascript (it was just one master form that got submitted), and the request is targeted at a hidden frame. The response includes a bit of Javascript that populates the appropriate
    , and shows the next one. This is AJAX without XML, or XMLHttpRequest. Of course, I didn't know I was doing anything special at the time or I would have given it a name and been all rich and famous now! ;) To me, it was just an approach that made sense. That's where we are today, but in a much cleaner and richer form. Don't get hung up on the technology. Don't think as much as what toolkit to use, or what difficulties Javascript might present. Instead, think of AJAX as a paradigm, an approach to developing webapps. The underlying concepts are whats important here, and what ultimately changes the game for many people for the better. It's not a perfect world, I agree, but its getting better all the time, and the basic ideas are what count at the end of the day. For me, those ideas are both good and frankly obvious as how modern web development should be done... it's not even a question for me whether AJAX is good a bad, it's simply a question of how best to go about it.