Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Creating Web Pages With Ajax

Posted by samzenpus on Mon Oct 16, 2006 02:28 PM
from the if-you-build-them-they-will-come dept.
Ravi writes "Asynchronous Javascript And Xml, popularly known as Ajax, is a combination of Javascript, XML and some coding on the server side. Even though this technology existed for years, many believe it was Google which brought it to the front by implementing it on its sites and thus raising it to the cult status it enjoys now. There is something magical in seeing a website update its content without reloading the whole page, which is the visual essence of Ajax." Read the rest of Ravi's review.


I found the book titled "AJAX — Creating web pages with Asynchronous JavaScript and XML" authored by Edmond Woychowsky to be a very good introductory level book on learning the basics of Ajax. Spanning 390 pages and 16 chapters, this book imparts a sound understanding of the basic features which make ajax possible.

The author starts by giving a brief introduction to the different types of web pages — static and dynamic, the tools and code used to serve them.

In the second chapter which is titled "Introducing Ajax", the author dives into the philosophy and principles of Ajax and with the aid of three simple examples explains three different ways of implementing ajax in a webpage. I found this chapter to clear some of the doubts that a newbie will have about the hype surrounding ajax.

The third chapter takes a step backwards in that it gives a birds eye view of all the XHTML elements and their associated attributes. The author also provides a table which lists the most commonly used CSS 1 elements. I found this chapter more of a ready reference than an indepth thesis on XHTML and CSS.

The fourth chapter titled "Javascript" provides a very good understanding of the language. Javascript plays an invaluable part in the greater scheme of the working of Ajax. Apart from the snippets of code and explanations, this chapter also has a number of tables listing things such as the essential JavaScript functions, characters used to create regular expressions, event handlers, Javascript operators and so on.

In the next chapter titled "Ajax Using HTML and JavaScript", the author explains how to use HTML, Javascript and stored procedures incorporated in the latest version of MySQL to create a semblance of an Ajax shopping cart. What is worth noting is that this chapter explains an old fashioned but very reliable technique which uses hidden frames and inline frames to update the data on the page. Of course the author is quick to point out that this technique is not really Ajax in the sense that it lacks the XML part.

I found the author's narration quite refreshing as he explains each concept one at a time with the aid of snippets of code, gradually building up and eventually tying all the threads together to write a true Ajax web application.

XML — eXtensible Markup Language is the successor of SGML — the language which powers HTML. XHTML on the other hand uses the XML schema. XML is a vast subject which can easily fit in a book of its own. Perhaps knowing this, and because XML plays a significant part in Ajax, the author has intelligently provided just the necessary information about XML in the sixth chapter.

The seventh chapter is a very important chapter which gives an indepth understanding of the XMLHttpRequest object which can be considered the brain behind Ajax. The author also provides some insights into the XML document object model, RSS and Web services such as SOAP.

In Chapter 8, the author gives a more indepth take on the XMLHttpRequest object and the other technologies explained in the previous chapter and illustrates by applying them in building a shopping cart application. Throughout the book, the author has highlighted the fact that ajax is a browser dependent technology and if people disable javascript in their browsers, then the whole effort will come to naught.

XPath is a technology which can be used to locate and navigate the various parts of an XML. The ninth chapter gives an introduction to the syntax used by XPath.

The next two chapters explain the concept of eXtensible Stylesheet Language for Transformations (XSLT) and how it can be used to implement Ajax. XSLT can be compared in some ways to CSS but is much more powerful and can be used to display pure XML in different styles targeting diverse media. These two chapters contain all the necessary details such as the syntatic reference and snippets of code which walks one through creating an Ajax application using XSLT.

In chapter 12, the author talks about the advantages of code reuse where creating javascript objects are explained. Surprisingly, there are two chapters on Ruby on Rails — the latest fad with the web developer community.

I found the book to be a valuable reference for upcoming Ajax web programmers. The number of tables listing the tags and their attributes itself will more than make up for the cost of the book. It has the right amount of content covering all pertinent topics without overwhelming the reader, which makes it a very good introductory book on Ajax.

Ravi Kumar is passionate about all things related to open source and free software and likes to share his thoughts and experiences related to these through his site "All about Linux".


You can purchase AJAX - Creating Web Pages with Asynchronous JavaScript and XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Like frames, eh? (Score:3, Insightful)

    by xxxJonBoyxxx (565205) on Monday October 16 2006, @02:41PM (#16457315)
    There is something magical in seeing a website update its content without reloading the whole page
    Like frames, eh? (Or Java, Flash, older Javascript apps, etc. etc. etc.)
    • Once upon a time people were stuck with screens refreshing slowly on RS232-connected terminals or lags of busy centralized servers. Then they realized they can have a small computer right on their desk and get instant response. Why would anyone want to go back to retro lag? I am not saying applications shouldn't be installed or auto-updated form the web, but is JavaScript + text data files really a perfect client side UI? There is Java, .Net and even C++/Objective C in a virtualized sandbox.
        • Dude, I am talking about regular native apps, not web forms. While you don't want to "download the whole Internet", I don't see why I should upload my every button click to google.
            • Again, why should every application should limit itself to functionality of Internet Explorer 6 if all major browsers support plugins that can enable much more appropriate programming environment?
              • Re: (Score:2, Funny)

                Yea! Lets create a way for people to extend the functionality of IE...lets call it ActiveX! BRILLIANT!
              • by Sancho (17056) on Monday October 16 2006, @06:58PM (#16461409) Homepage
                It depends completely on what you're trying to accomplish.

                The AJAX model shines for web applications. You know, applications where you need to make frequent requests to the server. Flash can do this, but as others have said, you get the same latency issues with Flash making queries to the server as with an AJAX-like application.

                AJAX seems like a terrible idea for standalone applications, which is what you said in an earlier post. So far, I haven't seen a single AJAX application that didn't query a server somewhere. The reason for this is precisely because we have better options: Java/Flash if you want to stay in the browser, standalone applications if you don't.

                Maybe we've all just misunderstood you. Gmail is arguably the best-known AJAX application. Its primary user-interface is web-based. If you're suggesting that web-based e-mail is a ridiculous concept because you could just download a standalone client, download your messages, and read them off-line, I can see that as a valid viewpoint. But the reason that web applications exist (in general) is because nearly everyone has access to a web browser. You don't have to download a new program for each website you want to use. Imagine taking this idea to the extreme and having to download Google Internet Search rathern than just pointing your browser to http://www.google.com/ [google.com]. Wouldn't that seem a little weird (I'm old enough to have used Archie and Gopher, so no jokes about the young ones, please)

                Web browsers are good middleware because they're ubiquitous. Everyone who has an Internet connection has one. Using the functionality of the browser (much like the Java sandbox, incidentally, which you said was valid in http://books.slashdot.org/comments.pl?sid=200963&c id=16458167 [slashdot.org]) rather than writing a complete application has a number of advantages, not the least of which is version control (being able to ensure that people are using the latest version of your software, no version mismatches, etc).

                I think AJAX is an interesting model, and I'll be following its adoption with interest. I don't think it's the end-all be-all of computing, but I don't think it's completely without merit, either. Then again, I don't have anything against traditional web applications, for the most part, so that may be where our viewpoints differ.
                • Gmail is arguably the best-known AJAX application

                  I thought Google Maps was supposed to be the big important world-changing app that brought us the name...??

                  I'm still kicking myself for not giving this technique a name (and self-promoting For The Win!!!1!) when I started using it this way about seven years ago when IE5 showed up. It seemed like such an obvious thing to do. Within a few weeks we had built a pretty solid, easy to use RPC mechanism around it for internal use, long before SOAP had a name (and lo
  • json (Score:2, Informative)

    Google definitely didn't invent it. At this point I think more people are using JSON for the data format versus xml. There is just way too much overhead associated with xml. There are a host of javascript and other programming langauge libraries built up to make mall this more easy. For example, the dojo toolkit for javascript has functions for sending the request and decoding the JSON for you automatically. It also provides some framework for passing parameters, handlign errors, and more. Then JSON
    • by Anonymous Coward
      Actually, it is a Microsoft invention [msexchangeteam.com]. No kidding. The Outlook Web Access (OWA) team are the ones that lobbied the Internet Explorer team to include the (original) XMLHTTP object; which was originally MADE by the OWA team.

      It's fair to say that OWA for Exchange 2000 was the _first_ AJAX application. They started development of it all in 1998.
      • It was an evolution, not a revolution.
        Using a small or invisible frame/iframe to send hidden requests was older than that.
        And lots of people (at least me) used to push some logic to the javascript side, and modify html input elements according to other elements.
        Hidden (or shown) iframes were/Are great for queries.

        The same behavior of ajax pages could be acheived, and the effect for the user was the same. All without a C00l buzzword.
      • It definately has its place.

        However generally there is no right answer, only the one best for you. For example it depend how much load you want your browser to take compared to your server. Our servers are embedded devices, so it makes sense to send the raw data(in JSON or XML) and let the javascript on the broswer create the page. On the other hand some times its better to as you say just send raw HTML(Tables especially can be a nightmare, I always seem to end up losing memory when deleting and creating ta
  • by angelzero (935040) on Monday October 16 2006, @02:42PM (#16457333)
    ...a 4th grade book report.
  • by Anonymous Coward
    ...made a webpage out of AJAX, the FBI arrested me for attempting to poison the world as a terrorist act.
  • AJAX (Score:5, Funny)

    by nmb3000 (741169) <nmb3000@that-google-mail-site.com> on Monday October 16 2006, @02:52PM (#16457525) Homepage Journal
    My biggest problem with AJAX is the popular misconceptions that surround it. For example, I was speaking to somebody a few days ago and they asked me how I would implement some survey widget as a webpage. I thought about it for a bit and told them it would be pretty easy with some PHP and MySQL. I was informed that my idea is "old and outdated". It appears this guy had already hired somebody and he is "coding it in AJAX and Dreamweaver".

    I suggested that AJAX is nice, but it's not a programming language, and more importantly it is not always the best solution for a problem. His reply? That I need to get more "2.0 centric". I was done at this point, but not before informing him that Web 2.0 is little more than pastel colors and BS.

    Surprisingly, the reason he asked me in the first place is that the guy they hired has been working on the system for the last 3 months with "little visible progress". Oh well, at least he's "2.0" enough for them.
    • Re:AJAX (Score:5, Insightful)

      by Dynedain (141758) <{moc.nilcmynohtna} {ta} {2todhsals}> on Monday October 16 2006, @02:55PM (#16457565) Homepage
      To which you should have replied "PHP and MySQL are normally a part of AJAX". And you probably would have landed the job instead of getting into a semantics discussion with someone who obviously doesn't understand the technology.
      • To which you should have replied "PHP and MySQL are normally a part of AJAX". And you probably would have landed the job instead of getting into a semantics discussion with someone who obviously doesn't understand the technology.

        True enough, though they weren't looking to hire anyone. He was just asking what I thought of it because I'd told him that I've done webpages in the past.
      • Maybe, but I don't think you'd get much job satisfaction with a boss who has a complete lack of understanding about web design - Phrases like "Hey, where's the Flash?" and "Can you rewrite that page using AJAX?" spring to mind.
      • And you probably would have landed the job instead of getting into a semantics discussion with someone who obviously doesn't understand the technology.

        This is supposed to be a good thing?
    • To upgrade PHP and MySQL's image to the "new" Iterweb, they should revise their versioning to include the "2.0" moniker...

      PHP 2.0! MySQL 2.0 Just pass it on over to the marketing gurus...

    • yeah man , eye balls, who needs money... we can get all the money in the world. its the new new economy 2.0.4 ... get with the times, your so... release candidate 2.0. Now it you'll excuse me my star bucks mocha double late wont drink its self and my segway is double parked. TTFN
    • The guy they hired has been working on the system for the last 3 months with "little visible progress". Oh well, at least he's "2.0" enough for them.


      Haven't you heard the rule that it can't be web 2.0 unless it is in 'beta'?
  • by KalvinB (205500) on Monday October 16 2006, @03:03PM (#16457703) Homepage
    http://www.freeringtoneheaven.com/ [freeringtoneheaven.com] has tracked over 70,000 ips and about 64% have javascript enabled. At http://www.icarusindie.com/ [icarusindie.com] with 78,000 ips tracked only about 38% have javascript enabled.

    The only reason FRH is higher is because visitors were required to have javascript enabled in order to download ringtones. That restriction has been removed. Icarus Indie has never required javascript to be enabled. It just keeps statistics. The sites keep track by using javascript to switch an image from a jpg to a php script. Those without js just see the jpg and those with see the image returned by the php script which also updates the database to indicate the ip has js enabled.

    AJAX may be cool but if you use it you better have a good reason to convince people to turn javascript on or you're just going to lose visitors.

    There were all kinds of Javascript security issues not too long ago and people still don't trust it.
    • An important aspect of a properly developed AJAX application is graceful failure. Use AJAX not as a requirement, but an enhancement of the user experience. I believe gmail, for example, will work without javascript enabled, but the experience isn't nearly as fluid.
    • My all time favorite Firefox extension, Noscript, blocks Javascript [mozilla.org] in a flexible way that allows whitelisting by domain either permanently or temporarily. It's really fun to click and be able to turn on Javascript for just the site you're interested in and none of the advertisers on it.
      • I don't make any attempt to filter out bots so you can feel free to subtract as many IPs as you feel is reasonable from the total number of IPs counted. But when you're starting at 38%, you're going to have to dismiss a lot of IPs to justify breaking your site for a lot of people just because you want to use AJAX.

        The other thing that should be noted is that IcarusIndie is mostly visited by technical people. Free Ringtone Heaven is more mainstream.

        If you're using AJAX on a technical site you're going to ha
      • This sounds like the flash only argument of days old. Check the browser for compatibility. If flash isn't on send them to plan b. The parent makes the most important point. Tons of people don't trust public websites with js on them anymore.
      • Of course the primary advantage of a web app is the ability to be used from a variety of OS's. If you have an in-house application and you can control the configuration of the computers, a "fat client" application is probably going to be easier to develop and give a better user experience than an AJAX-based one.
  • XSLT (Score:3, Interesting)

    by gaspar ilom (859751) on Monday October 16 2006, @03:26PM (#16458131)
    I find it interesting that the review mentions XSLT, which, IMHO, is very powerful:

    You can completely separate most display logic from the "data" and business logic. (...which can be handled before the XSL transformation, and done such that you get XML nodes to feed into your transformations.)

    It may seem complicated at first, but there are so many advantages:

          1.) you get the layout of the site defined in a declarative manner, basically as as data. (and that XSL "code" can be easily analyzed or transformed, itself.)

          2.) you can disentangle a lot of markup from your PHP/ASP[VBS/JScript]/Python code.

          3.) The output of your XSLT transformation can be fed into other transformations.

          4.) Your XSLT is highly portable across platforms, even between server vs. client-side rendering.
    (Although, it bums me out that Microsoft has decided to not support XSL 2.0.)

          5.) Manipulating an X/HTML dom via a browser's built-in XSLT processor is much faster than using JavaScript only. (E.g.: using JavaScript-only to traverse a DOM in order to select, merge, append, and move nodes...)

    I'd be curious to know what this book has to say on the matter.

  • by leighklotz (192300) on Monday October 16 2006, @04:20PM (#16459037) Homepage
    Try AJAX with markup only, no hand-written JavaScript, by using the W3C [w3c.org]'s XForms [w3.org] standard. There are a number of implementations such as the Servlet-based Chiba [sourceforge.net] (which fronts for Dojo and other packages), FormFaces [formfaces.com] written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon [orbeon.com], and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin [formsplayer.com], or cell-phone capable implementations such as PicoForms [picoforms.com] and SolidForms [sourceforge.net].

    I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail [graflex.org]

    And for completness, I was an editor of an earlier version of the W3C XForms recommendation.
  • Google? (Score:4, Insightful)

    by CDPatten (907182) on Monday October 16 2006, @05:12PM (#16460005) Homepage
    "think" is the important word when suggesting Google had something to do with AJAX. They have had NOTHING to do with it's creation seeing how that is up to the makers of web browsers. Microsoft really invented the functionality while most of the slashdotters were still getting wedgies in school.

    The term AJAX may have been coined a couple of years ago in an article, but MS deserves the credit. Its also worth noting they were using it on microsoft.com before most of us had even heard the word google.

    Lets see how many of you can swallow that and actually give them their do.
    • Re: (Score:2, Funny)

      Could you run that management/marketing speak through a To Plain English filter and repost. I didn't understand a word you pecked out on yer keyboard and then posted...
      • Wow, I was actually going to fire off an empassioned response, until I landed on this jewel:

        > I give it two more years and it will be the latest in a line of bad ideas - javascript, dynamic html, xml rpc, java applets, etc.

        Move along, nothing to see. Hope that rock fits you comfy.

      • Can I ask why you lump XML-RPC in that list of Bad Ideas?

        Any technology can be misused, but it takes alot more than that to call it a Bad Idea.
        • Re: (Score:3, Interesting)

          "What's truly significant is the ability to make web requests and processing in the background."

          This is really just a hack to get around the fact that web standards weren't designed for anything beyond static pages. A better solution would be to rework these standards so that any user interaction with an HTML element could optionally trigger a request. For most web apps this would make Javascript unnecessary.
    • Ultimately, AJAX is nothing more than spagetti Javascript and HTML.
      Thats why frameworks like ASP.NET AJAX (formerly known as Atlas) come in to solve that issue. When you use Atlas (a much more appropriate name than its new one, as Ajax is only a fraction of the framework), you get to use classes, inheritence, interfaces, and all around reusable constructs in your javascript. So it is anything BUT spagetti code.
      • True.

        You can do very cool Ajax stuff in ASP.NET relatively easily with 3rd party controls from companies such as:

        http://www.telerik.com/ [telerik.com]
        http://www.componentart.com/ [componentart.com]

        and others.
        • Viewstate can be handled server side (except for a very small bit of data to track the server side part of course, though care needs to be taken for security, but thats easy), so its honestly a non-factor. Postback is to use asp.net specific page model. You don't have to use it, and its very simple to get back to the stone age if you don't want all these features, using the standard navigation and form models. Its not that way by default since ASP.NET aims more to mimic a desktop app's flow. But again, it
    • the typical end user (and most MacInfags) sure loves the stuff.

      You email your mother with that keyboard?
    • making my 2ghz CPU feel like a P2 running at 200mhz

      Don't worry, Vista will do that for you! Sure you don't want one of those Macinfags, you know, the one that has an OS that runs faster on the same hardware with each new release?
    • There are ways to get around this. If I remember well, for example, the GWT (is that the right name? The google toolkit for web UI) handles the back button and such while dealing with Ajax.

      That being said, Ajax shouldn't usualy be used in situations where you need these features. If you do, it was probably a bad place to use ajax in the first place. Things like cascading combo box, sorting grids/tables of data, paging (debatable), etc, is where its useful. Basical, all features that should be handled cli
    • Funny, I was just thinking that one of the nice things about AJAX was the ability to keep the back button behaving as users expect.

      An example (roughly inspired by a recent project I was working on):

      Say a user has a bunch of search results, and for each result they can navigate to a page where they can modify fiddle with things and push a lot of buttons and submit a few forms to change the data. Most users, myself included, would still want 'back' to take them to the search results, not to an earlier form.

      A
      • What are the multiple things that other servers understand that ASP.NET servers don't?
        • How to run on non-Microsoft platforms?
          • Sure, ASP.NET 2.0 doesn't run on Unix platforms, just as most other web servers only run on Windows and Unix compatible OS's. I was looking for a more significant factor. In my view you pick the web server that works best for your requirements and then choose the OS that it runs best on. If I were using Apache and it ran best under Linux, I couldn't care less whether it also runs less efficiently under Windows.
    • AJAX is the name given to the collection of language protocols of XML, XSLT, XSD, CSS, HTML, and Javascript. Microsoft would have you believe that you need a COM, or DOM object; But it is not necessary, and prone to cracking. It is best to start out with a client side XML page, and a XSLT line inserted to produce the web page. The top 4 browsers all can handle XML using the XSLT. If you need separate functionality, make use of a web service; Simple. And if you use this set of tools, your project comple
    • Re: (Score:2, Interesting)

      nice example.

      in theory this might work, ever tried to use "try() {...} catch() {...}" in IE6 ? good luck. the xmlhttprequest interfaces are not 100% the same on all browsers (which support it), one still has to write crossbrowser code, i could go on for days (there are many nice "ajax" libraries which deal with these issues).

      I haven't read the book ,however i was always happy with the oreilly books on javscript, because these books pointet out most of the browser differences/annoyances to keep in mind while