So How Do You Code an AJAX Web Page?
PetManimal writes "Computerworld has a long excerpt from a book by Edmond Woychowsky about how to code Web pages in AJAX. It gives a good explanation of how the technology works, and also has some visuals and code snippets that you can play with. From the article: 'Beyond the XMLHTTP Request object, which has been around for several years as a solution looking for a problem, there is nothing weird needed. Basically, it is how the individual pieces are put together. When they're put together in one way, it is nothing more than a pile of parts; however, when put together in another way, the monster essentially rises from its slab.'"
Beyond the XMLHTTP Request object, which has been around for several years as a solution looking for a problem, there is nothing weird needed. Basically, it is how the individual pieces are put together. When they're put together in one way, it is nothing more than a pile of parts; however, when put together in another way, the monster essentially rises from its slab.
But more importantly, one needs to remember that the internet is not a big truck, that you can dump information on. It's a series of tubes.
The theory of relativity doesn't work right in Arkansas.
1. Open Visual Studio
2. Download and install the ATLAS framework
3. Wrap your webpage in an update panel
4. Add a script manager
5. Lather, rinse, and repeat
Seriously...one drag-and-drop and you'll never see another page refresh.
Instead of wading thru 7+ pages of clicking and ads ... Printer Friendly version. You can thank me later.
With the growing popularity of AJAX does anyone think it's time to update the HTTP spec? AJAX is cool tech but still hindered by the fact that the client has to initiate every request. Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.
Similes are like metaphors
Woychowsky repeats himself a lot. What's more, he says the same things over and over. In other words, he'll say something, and then re-phrase it with almost exactly the same words.
As I've mentioned, he seems to keep repeating himself
title So how (i) do (/i) you code an AJAX Web page? /title
:))))))
Haha, i mean, start ptocessing XML like this with Java and we will have a lot of browsers falling on their asses with exceptions
OK I am cruel!
How do I save an AJAX page in a given state, rather than just a state that will be "rebooted" on reload from storage?
--
make install -not war
Print version here.
Zero credibility points for trying to put markup in the <title> element and hiding the printable version behind a javascript:void(0) link.
If you want the technical stuff, skip about a third of the way down. The first third of the article just repeatedly tells you that Ajax is when the page doesn't "blink".
The code he supplies is crap. For instance:
Things wrong with even this tiny snippet of code:
Skimming the rest of the article, I see the following mistakes:
If this is a representative sample of the book it is excerpted from, steer well clear of it. The whole approach is poor.
The best way of producing compatible, accessible Ajax applications is to start with the bare HTML and make that work. Only then do you add the JavaScript, and you do it by enhancing the page, not replacing it. For instance, don't use <button onclick="...">, use a normal <input type="submit"> and hook into the form's submit event. That way:
Bogtha Bogtha Bogtha
The article is very verbose. It has some value, I suppose - it helped me to decide I didn't want to buy the book. There are more concise introductions to Ajax here and here
There is also an interesting library of Javascript/ECMAscript functions to perform common Ajax chores here
1. Download Echo2 http://nextapp.com/platform/echo2/echo/
2. Write AJAX applications like you would a Swing app, never touching HTML or Javascript.
3. Go outside and play.
'nuff said.
Comment removed based on user account deletion
Slashdot isn't anti Web 2.0, it's dissing your code... calling it lame garbage.
But don't take it personally.
Lose Weight and Feel Great with Isagenix
Are you suggesting that it didn't occur to those who created XMLHttpRequest how it might be used?
I think it was far more a case of it taking a while for someone to make a compelling enough application using it for it to get public acceptance and attention from mainstream developers. And probably a bit of reluctance to go down that path until a large enough percentage of users had a browser that supported it to make it make economic sense to invest in the use of such techniques on a large scale.
Nobody calls XmlHttpRequest() directly anymore. It's too much work, and there are slight differences between browser implementations. Nowadays everyone is using a wrapper library. Prototype is a very common one (it's certainly my favorite) -- abstracts everything into a nice set of functions for you -- you just specify the HTTP call you want to make, and the function you want it to call when the data comes back (because, in case you're not already aware, XmlHttpRequest() returns its data asynchronously).
The other nice thing you can do with Prototype is to avoid XML parsing altogether by saying "ok, here's the URL I want you to call; it's going to return pre-rendered HTML, and when it does, I want you to stick it in this DIV over here; don't bother me about it" and you can do things like automatically update portions of your page without reloading. You can even have an automatically recurring update, which is very cool for things like tickers, clocks, etc. We used it in our AJAX webmail/calendar system and it really worked well.
Tired of FB/Google censorship? Visit UNCENSORED!
One strike against AJAX is that search engines won't be able to see any of your 'dynamic' content. Sure, you can code around it by providing static links to the same content, but it's something to keep in mind.
We didn't really even need xmlhttprequest; you could use iframes, too. (And some notable "2.0" apps have)
Useful bits I've found getting into ajax stuff:
Dojo Toolkit, a nifty framework for doing all sorts of good stuff. Of particular note to me was dojo.io.* with its dojo.io.bind() function, which provides a simple, cross-platform compatible way to do an xmlhttprequest, with callback functions for completion and errors, an easy way to post variables, specify a method and caching, etc.
openrico. This provides all sorts of fun stuff. The smart stuff starts with declaring $ as a function, which after you get used to it provides a very convenient cross-platform way to access DOM nodes (ie, $('mydiv') or $(divvar)), and has all sorts of canned widgets for effects, like accordian widgets, move&resize, etc... although I've found practical application usually requires a bit more additional work, but their functions help get started.
Try...
$ vi <enter>
Really? Then why doesn't it say "+5 Funny" on my shirt?
This space intentionally left (almost) blank.
Why doesn't Slashdot implement it? This would be especially nice for expanding/collapsing in the discussions.
We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
I recently published my first Ajax application. It is an online game called Grand Strategy, a close of the well known board game Risk.
It is by far the most advanced Ajax based implementation of a board game to have ever been written!
I used Direct Web Remoting (DWR) and the Dojo Toolkit. My javascript talks to my server side java beans directly. It's really the easiest web programming model I have ever seen. I hurts to go back to doing ASPX and PHP pages after this.
Check it out here:
http://denizengames.com/grandstrategy/
After reading through five pages it all ended at "var dom = new ActiveXObject(......"
No thanks, next book please.
Off the top of my head: Google Suggest. The same page offers enhanced Ajax functionality and still works in Lynx, without any need for two pages or radically different layouts.
The ways you make Ajax work in a backwards-compatible manner are the same techniques decent JavaScript developers have been using for years. Unfortunately, not a lot of people are aware of JavaScript best practices and the field is still dominated by people who concentrate on making it work in their favourite browser and then bodging it to work elsewhere, rather than starting from a good solid design and enhancing it in a structurally sound manner.
If you're interested in learning more, I suggest DOM Scripting and the DOM Scripting Task Force website as decent starting points. I haven't read the book, but I've heard a lot of good things about it from people who know what they are talking about.
Bogtha Bogtha Bogtha
Command line interfaces are for n00bs. I use a magnet to change each byte on my hard drive.
Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.