Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Java The Internet IT Technology

Better Web Apps With Ajax 184

Posted by Zonk from the sounds-like-a-clean-idea dept.
An anonymous reader wrote to mention an article on IBM's site detailing the fundamentals of Java-based Ajax. From the article: "This article gives you a good understanding of the fundamental principles of Ajax, and a nuts-and-bolts knowledge of the client and server side components that participate in an Ajax interaction. These are the building blocks of a Java-based Ajax Web application. In addition, you will be shown some of the high-level design issues that come with the Ajax approach."
This discussion has been archived. No new comments can be posted.

Better Web Apps With Ajax More

Better Web Apps With Ajax

Comments Filter:

  • With AJAX, you know you've got (Score:3, Funny)

    by knightinshiningarmor ( 653332 ) on Thursday September 22, 2005 @06:58PM (#13625702)
    Cleaner code than the rest!

  • Two camps (Score:4, Insightful)

    by sexyrexy ( 793497 ) on Thursday September 22, 2005 @07:04PM (#13625741)
    I'm glad to see another serious technical article on the pros and cons of implementing an AJAX solution. Most everyone who says the acronym "AJAX" usually falls into one of two camps - either the "OMFGZ teh AJAX is so amazing! It will change the interweb!" How? Oh, it allows parts of the page to be updated without a refresh. How interesting. Perhaps you could go a little more in-depth? No? Thanks...

    The other camp... too many Slashdotters, IMO... feel the need to flex their superior understanding of the fundamental dynamics of the internet and development and offer this gem: "AJAX is just an assortment of pre-existing technologies. Nothing to see here".

    The automobile was just an assortment of pre-existing technologies, and it radically changed the world. It also introduced a whole bevy of new challenges, both technical and otherwise, that we still haven't fully figured out yet. It was not a transportation panacea, and AJAX is no cure-all. But just because it doesn't solve every problem doesn't mean it doesn't have the power to be revolutionary.

    • Re:Two camps (Score:5, Informative)

      by museumpeace ( 735109 ) on Thursday September 22, 2005 @07:30PM (#13625895) Journal
      It is not so much the technology as the economic might of the one of the biggest developers of AJAX: Google. They are giving a wall to wall 24x7 demo of AJAX technique and its effectiveness to anyone who pays attention. The fact that middleweight clients that can support a bit of asynchronous update traffic in what , to the user, is the "background", is not so much technically amazing as perceptably practical and a better web experiance. I was looking for better doc on AJAX, having first got the impression it had to be JavaScript [which, frankly, is a crappy tool for designing ambitious software]. This article is a good addition to a topic that doesn't have much presence in the bookstores yet. There are other [mozilla.org] sources [theaimsgroup.com] on line [apple.com]. Its not just for XML and its not just a J language either... Ruby will do. [onlamp.com]

      • The Three Conditions of AJAX (Score:5, Informative)

        by Kamiza Ikioi ( 893310 ) on Friday September 23, 2005 @01:19AM (#13627196)
        "Its not just for XML and its not just a J language either... Ruby will do."

        No, XML isn't really a requirement of functionality. If by J you mean a Java backend, you are correct, but not if you mean Javascript Without Javascript you cannot have AJAX-like functionality unless you use a plugin or browser addon like JRE, Flash, etc.

        I just wanted to clarify this point to those who might take that statement the wrong way. Coding something in C++ that talks to a server is not AJAX, for instance. AJAX, imho, is defined by 3 characteristics.

        1. AJAX involves dynamic content, not static content. This means that there is a seemless interaction, without the application appearing to "reload".

        2. AJAX involves a stand alone web browser or an embeded web browser that is running the common scripting language Javascript.

        3. AJAX involves data retrival from a source outside of the client-side application itself, and does not solely use data embedded in the application itself.

        I could refine those a bit, but I think the general ideas come across. So, really, a Java applet embeded in your browser that talks to the server, such as an IRC chat client, is not AJAX, though it may provide AJAX-like functionality. The language of the backend is irrelevant; the data formats are irrelevant. The only relevance, really, is that you are taking something that has generally been static (web pages) and made the operate like a fully functioning application. It's the transition from "Information" (HTML) to "Application" (AJAX).

        The definition really can't go beyond this. If it isn't limitted to seemless dynamic content, you could call any webpage that contained Javascript AJAX. If it isn't limitted to browsers and Javascript, then you could call an SSH program, chat applet, multiplayer game XBOX game, etc. "AJAX clients". If it isn't limitted to outside data, then you'd have to call Javascript clocks AJAX. An application must (at least) satisfy these three conditions before it can be called AJAX. If it doesn't, it may still be a really good interactive and dynamic application, though not AJAX.

        The core of AJAX, XMLHttpRequest, is the only place I think the term XML is validated in the AJAX acronym. And, certainly, you can load any type of data you wish with it. If there was any single thing to define AJAX, it is this command. Without it (or something like it coded in a round about way... who knows, some people like the challenge) you cannot satisfy all 3 conditions.
        • Hidden IFrames are the preferred method when XMLHttpRequest isn't available, IIRC. There's also the cunning trick of sticking a script element into the page, but I'm not sure how well that works and could cause all sorts of issues.
          • The simplest trick I remember was to use the innerhtml property of hidden divs, and write var data there, and then use a timer in the JS to load it up.

            I still use that trick as it's a good replacement for session cookies when you really don't want to code a any backend scripts or mess with cookies for some little "play page".

      • Re:Two camps (Score:3, Informative)

        by Tim C ( 15259 )
        Its not just for XML and its not just a J language either

        Technically, the X in AJAX is XML, while the J is JavaScript, so yes AJAX is just for XML. You can do the same sort of thing using whatever technology you want, of course, but to do AJAX requires:

        a browser
        XML
        JavaScript

        The server can be written in anything you want, as long as it can receive HTTP requests and interpret XML. You're free to implement AJAX-style functionality using whatever collection of technologies and languages you wish, but unless you
        • Technically, the X in AJAX is XML, while the J is JavaScript, so yes AJAX is just for XML.

          It's actually a bit of a misnomer. Despite its being called XmlHttpRequest, there's no reason you actually need to work with XML. You can use HTML or even plain ol' text just as well.

    • Third camp sees this? (Score:2, Insightful)

      by Anonymous Coward
      <html>
      <head>
      <title>Ajax app</title>
      <script type="javascript" src="ajax.js">
      </head>
      <body onload="ajaxInit()">
      <noscript>
      We are very sorry but we, the developers of this website don't understand the web. We would like to provide a non-script alternative for the visually impaired, disabled and people with security smarts but "Ajax" is the future of the interweb and you are not. If you do happen to be visually impaired, disabled or security conscious then fuck off
      • I already get mad enough at developers that do everything in flash. God forbid I want to find out about the newest blockbuster movie without having my computer bogged down with tons of flash filled with impossible to find information. I don't see why everyone is out there to make the browser do more work then it really should. We have a hard enough time getting browsers to display HTML correctly. We don't even know what's going to happen with random browsers that are out there that may or may not interp

      • AJAX is a technique for updating a page with new information without a reload. The result is an updated page. Why would a visually impaired person be able to read a normal page but not an updated page? You do know there are javascript-enabled text-only browsers [elinks.or.cz], do you?

        'security smarts' are irrelevant. Javascript can make your site more attractive. A more attractive site attracts more visitors. A javascript site loses some visitors. When you gain more visitors by using javascript than you lose visitors, y

        • Why would a visually impaired person be able to read a normal page but not an updated page?

          All things in moderation. Keep in mind that Google is the worlds most popular blind web user. Whether real blind people will use your web app or not, you most certainly will want Google to still find it's way around to your content. Certain situations are or course the exceptions. Use AJAX where appropriate, and only AFTER the same functionality works without javascript enabled. This is especially true for anything

    • How? Oh, it allows parts of the page to be updated without a refresh. How interesting. Perhaps you could go a little more in-depth? No?

      Well, one of the things we use AJAX for is to prevent two people from modifying the same story. AJAX hits the server every 10 seconds with a basic "My name is Bob and I'm modifying story 197342". Then if the user's browser crashes or if they just close the window, the story will auto-unlock after 10 seconds.

      This doesn't really "change everything!" but it's just one more th
    • But just because it doesn't solve every problem doesn't mean it doesn't have the power to be revolutionary.

      And it probably is.. But so what? We're developers and we're constantly in the middle of the next revolutionary technology. Christ most of us just want to take a frickin breather and make sure we do it right. The next big thing(tm) is constantly in our ear, ITS HERE! ITS HERE! THE NEW PHONE BOOK IS HERE!

      So don't be surprised when we *yawn* while accepting the inevitable new shiny baubble
    • The other camp... too many Slashdotters, IMO... feel the need to flex their superior understanding of the fundamental dynamics of the internet and development and offer this gem: "AJAX is just an assortment of pre-existing technologies. Nothing to see here".

      It's not that AJAX is just an assortment of pre-existing technologies. It's the fact that it's nothing more than that -- there's no AJAX development tools, no IDE, no solid definition of what it is or isn't. The definition of AJAX pretty much begins and
    • Personally I quite like the idea of AJAX, that of being able to dynamically update web pages, however I'm not sure I'd consider it revolutionary in enabling that. However there is one thing I am curious about is why I should use AJAX over an alternative such as a hidden iframe? Certainly, the AJAX approach will likely be cleaner, as working with iframe's can be a pain to put it lightly, but in doing so I would sacrifice some browser compatibility, not necessarily a vast amount, but enough to cause me some d
    • Ajax requires JavaScript; it doesn't work in links or w3m (or emacs-w3m). It is, therefor, missing the whole frickin' point of the World Wide Web. A RESTful approach is much better.

  • Atlas (Score:5, Informative)

    by ThinkFr33ly ( 902481 ) on Thursday September 22, 2005 @07:05PM (#13625746)
    Atlas [asp.net] is Microsoft's entry into the suddenly-popular-even-though-it-has-been-around-fo r-7-or-more-years AJAX trend.

    Atlas is a set of extensions to ASP.NET 2.0 that allows for web developers to use AJAX with little or no plumbing work on their part.

    It integrates with ASP.NET extremely well and maintains the "event driven" style that ASP.NET is known for.

    There is also a Channel 9 video [msdn.com] about what Microsoft is doing on the AJAX front elsewhere.

    • Re:Atlas (Score:3, Informative)

      by badriram ( 699489 )
      Microsoft entered AJAX when they created XMLHTTP, and used it in OWA. They just created easy to use developer APIs in .Net now. Dont get me wrong, I am liking Atlas, it is a very good framework, and takes care of a lot of plumbing that i know would have taken me years to write.
  • Ya sorry but everyone knows that to obtain Buzzword Fad Certification (TM) AJAX *must* be coupled with Ruby on Rails, an Agile Development Model and legendary programmer Bill Brasky. Java does not fit in that picture (although apparently Brasky once coded a complete J2EE Web commerce framework in one hand on his BlackBerry while siring a child with his best friend's wife ... that framework launched a little site called Half.com).

  • When you're using java, you can... (Score:4, Informative)

    by fireboy1919 ( 257783 ) <rustypNO@SPAMfreeshell.org> on Thursday September 22, 2005 @07:07PM (#13625762) Homepage Journal
    ...use JSON-RPC instead. XML is longer and hard for a javascript interpreter to interpret. Why does everyone want to use it as a wire protocol? I've never understood this. It makes a lot more sense to me to just store everything as a javascript hash.

    Anyway, unlike the almost most ajax libraries, which are at this point almost totally devoid of docs, the guy who wrote a JSON-RPC library actually tells you how to use it. If you've got java, its the way to go, I think. Here it is. [metaparadigm.com]

    Personally, I'm a perl monger, so I use this lib [cpan.org], which isn't nearly as good, as you have to do most of the javascript stuff yourself. Faster than XML though, and its still rather trivial to turn a DOM object into a plain javascript one for use with JSON.
    • Okay, let me try to understand this. I'm putting together a brand spanking new web application that would greatly benefit from this technology. But to me, simplicity is the cardinal rule. Why do something in 50 steps, translating data from one langugage to another, when you can just keep it in one?

      I have over a decade of experience writing programs that spit out HTML. Why not have my Perl scripts spit out garden variety HTML which can then be substituted appropriately on the page?

      It seems to me that woul
      • Converting XML into HTML requires the use of a XSLT document, and some funky browser facilities normally.

        Why not do it in straight HTML? Here's a few reasons not to:
        1) Repopulating elements you've already got with new data is faster than re-rendering part of the page. That's the whole reason why you're using AJAX at all instead of just using CGI.
        2) That can introduce memory leaks.
        3) Then you need html generating code on the server side. You can speed up development time if you're not worried about the
        • What I want to do, essentially, is to change HTML within a page to whatever's generated by a server-side script. For example, let's say my application was a shopping cart.

          I want to replace the former value of the span called cart containing cart contents with, say, "Cart contents: Foo $53.95, Bar $25.75, Baz $32.95"

          So all I want is for my server-side script to output Cart contents: Foo $53.95, Bar $25.75, Baz $32.95 to the client, and have my client take that string and set cart's innerHTML property to it.
          • I really think that this sending XML back and forth would be a real pain too. I'm kind of against this whole Ajax thing to begin with. Basically, all I trust a browser to be able to do, is to render HTML correctly, submit forms correctly, and follow links correctly. I'ved worked enough with Netscape 4, and all the other browsers out there, to know that putting that amount of extensive javascript in your application is just asking for trouble. Even if it works most of the time, there will be bugs in your
            • I used to think exactly as you did. But we're not in the good old days of Netscape 4 anymore. In all modern browsers, we can, in fact, reliably change data within our web pages using the document.innerHTML property. I don't think there's any reason now not to use that to limit the amount of data we have to send, and give our users a better experience.

              The approach shown in the link I was sent as one of the first replies to my message looks pretty good and I'm going to be trying it over the next few days.
          • If you tag all your elements with id attributes, there is no reason why you couldn't have the XmlHttpRequest return just the elements that need to change, and have some javascript to alter the DOM based on what is returned. But you'll need an HTML parser in your javascript, since the javascript DOM API does not deal with HTML, it deals with DOM objects.
      • I've done this. I have a lib (not ready to share yet) that takes an XML document and assimilates it into the current document as XHTML. There's a corresponding pair of objects in my PHP toolkit, XMLPage and XHTMLPage -- XHTMLPage extends XMLPage -- that I can use to return content in a full page, or atomically to the rewrite module, using the same subroutines.

        Here's what happens:
        (JS) Rewrite.load(url[, postdata[, callbackfn]]);
        (PHP) Create XML document:

        <?xml blah blah blah>
        <response>

    • on the other hand the article as posted above goes into detail on degradability whereas JSON-RPC is specifically latest versions only. Of course the advantage of latest version use is that your machine is unlikely to be owned by one of the many nefarious sites out there just waiting to infiltrate and destroy you. On the other hand if your IT department is run by any one of the dolts I've seen managing IT departments, you won't have permission to update your browser and they won't bother.

      Still - got a versio

    • Re:When you're using java, you can... (Score:2, Insightful)

      by Anonymous Coward

      XML is longer and hard for a javascript interpreter to interpret. Why does everyone want to use it as a wire protocol?

      XML might be hard for a Javascript interpreter to interpret, but you don't interpret the XML with Javascript. The XML parsing routines are built into the web browser itself, you just access it with the DOM, same as with all the other Javascript you write.

      Yes, that's marginally harder than having i as a native Javascript object, but it has the benefit of being reusable no matter what

    • For one, by spitting out XML you can specify an XSL stylesheet or a CSS file and make it possible for browser to render contents directly - including when the user has javascript turned off. It's a great way to allow the site to gracefully degrade. Add to that an argument to your scripts to let the server side do the XSL processing and pass back HTML and you can trivially build lots of fancy AJAX functionality but have the site gracefully degrade for clients that can't or won't handle either javascript or X
      • No you can't. You have to use CGI and rerender the entire page if you're doing that.

        You might as well use html if you have to redo the whole page anyway.
        Repeat this to yourself until you remember:
        WIRE PROTOCOL! WIRE PROTOCOL! WIRE PROTOCOL!

        Its not for making a page! Its for moving data from server to client! Just data! Thats the whole point! And it requires javascript. Without javascript, you can forget all of it entirely.

  • An "arrr" solution. (Score:2, Interesting)

    by Anonymous Coward
    I much prefer a seaside [seaside.st] solution.

    --
    The "are you a script" word for today is platform.

  • The problem with AJAX is the X (Score:5, Interesting)

    by MarkEst1973 ( 769601 ) on Thursday September 22, 2005 @07:13PM (#13625791)
    JSON [json.org] is a much better mechanism for handling data transmission in AJAX applications.

    Why? Less verbose (easier on bandwidth) and no parsing (ever tried parsing XML using XmlHttpRequest? It sucks). JSON is object syntax. It is a real, live object serialized to string.

    It just so happens that JSON is also legal Python object notation.

    Hmmm... GMail, Google Maps, Google Suggest... none of these use XML. Google is also renowned for using Python. JSON syntax is the same in client-side javascript and server-side python... hmmm... makes me think twice, anyway, instead of drinking the web services kool-aid Sun and Microsoft are serving.

    • I do some parsing. But instead of XML, I use the HTTP-headers format.

      My-var1: Something
      My-var2: (Something_base64_encoded)

      Has been pretty useful for me.
    • Not so. In both IE and Mozilla XML parsing is done in native code, and is pretty darn fast. Granted, accessing the nodes in that resultant document can be tedious from a development standpoint, but if it's performance you care about, then XML will most certainly be faster. While JSON may be more terse, and easier to deal with as a developer, the browser still ends up having to create a lot of objects in interpreted code, which is a lot slower.
      • And the parsing of javascript is also done in native code. The very fact that XML has a Javascript interface implies the browser "still ends up having to create a lot of objects in interpreted code". And the underlying design of DOM makes me think there will actually be more objects created through XML than through JSON. Remember, the JSON objects are almost all primitives in the Javascript language and there is a lot of optimization surrounding them.

        Anm
    • For that matter you could use something like YAML [yaml.org] and get over your problem with the "koolaid". If web services are useless from your POV that's fine, but some of us use XML for stuff other than doing OOB requests in JavaScript.

      You can move anything over HTTP, and as long as the receiving end understands you, you'll be OK. You can move INI files if you want. But some people prefer to use existing infrastructure (stable/tested parsers, WS-*, schema validation and so on) so as to avoid reinventing the wheel

    • JSON is object syntax. It is a real, live object serialized to string.

      So it is a proxy, and when I call a method on the object, the behaviour occurs on the server side? I find that pretty hard to believe (or a very bad idea if it is true). Fine grained method calls were pretty much abandoned with the total failure of early EJB applications to scale gracefully (a lesson which had already been learned by many DCOM and CORBA programmers). I'm guessing that JSON actually uses serialized structs, possibly with i

  • Ajax with lots of languages (Score:2, Informative)

    by Anonymous Coward
    revolutionary or not, "AJAX" is now used in lots of languages. and there are some good tools out there. there's ruby on rails [rubyonrails.org] with the prototype library which is also now available in perl. there's also CGI::Ajax [cpan.org] which is pretty simple to apply... and it's perl!

  • IBM comparison (Score:3, Informative)

    by Mostly a lurker ( 634878 ) on Thursday September 22, 2005 @07:23PM (#13625854)
    Also interesting on the IBM site is a comparison between the use of J2EE and Ruby on Rails [ibm.com], another great way of achieving Ajax functionality.
  • Why not just use Echo2 [nextapp.com] and not have to worry about the details of an AJAX implementation for Java? I generally prefer not to reinvent the wheel, and with all of the various browser quirks with respect to AJAX, that's quite a non-trivial wheel to try and recreate.

  • Ajax, Java, Echo2 (Score:2, Interesting)

    by cbozic ( 679475 )
    TrackIt [sf.net] is an application that takes advantage of all of the above technologies.

  • Ajax library for Java (Score:3, Interesting)

    by strokerace ( 912726 ) on Thursday September 22, 2005 @07:54PM (#13626022)
    There's a pretty good library I've used recently called DWR [getahead.ltd.uk].

    If you're looking for a Java library to do some of the heavy lifting, check it out.

  • For examples... (Score:4, Informative)

    by bad_outlook ( 868902 ) on Thursday September 22, 2005 @07:59PM (#13626054) Homepage
    Check out the new cal for Hula http://hula-project.org/Hula_Server [hula-project.org] - amazing work.

    And the front end to the webmail for Zimbra http://www.zimbra.com/ [zimbra.com]

    Really, really nice stuff.

  • AJAX can be fun! (Score:4, Interesting)

    by Klowner ( 145731 ) on Thursday September 22, 2005 @08:06PM (#13626092) Homepage
    I made a little window-manager-esque thing in Javascript/CSS/HTML a few weeks ago (Looks messed up in IE, works fine in Firefox)

    http://dugnet.com/klown/ajwm/ [dugnet.com], all that's needed are some AJAX functions to swap out the contents of each window, instant freakish web-app thing..

  • Remarkable omission (Score:2, Informative)

    by UhhhClem ( 852495 )

    Here we have a detailed, in-depth article about client-side browser XML processing that doesn't once mention XSLT. If you're writing JavaScript to transform your XML responses into updated client-side HTML by manipulating your browser's DOM, you probably should be listening to those who are recommending nonstandard-but-terse formats for data interchange.

    And while we're on the subject of terseness: complaints about "bloated" XML are meaningless outside of a context that takes the application's overall b

    • complaints about "bloated" XML are meaningless outside of a context that takes the application's overall bandwidth requirements into account

      Totally untrue!
      There's also the issue of latency and local computation time. The less time between the click of a button, and the reciept of data, the better it is.

      The lower bound is very, very low, and every little bit helps.

  • JWP has a great AjaxTags component (Score:4, Interesting)

    by fzammett ( 255288 ) on Thursday September 22, 2005 @09:02PM (#13626310) Homepage
    Since everyone else is mentioning their favorite AJAX toolkit, I'll list one too:

    http://javawebparts.sourceforge.net/javadocs/index .html [sourceforge.net]

    This is a component of the larger Java Web Parts project called AjaxTags. It's a taglib that allows you to easily add AJAX functionality to arbitrary page elements in a purely declarative manner, i.e., *NO* coding on your part (although there is more capability there if you need more). It really makes AJAX a breeze, and is pretty powerful at the same time. If you are a Java web developer, have a look, you may very much like what you see!

    P.S., The parent projects' page is here:

    http://javawebparts.sourceforge.net/ [sourceforge.net]
  • When we can do that, we'll know this "Web 2.0" is really here finally.
  • Does anyone know of any AJAX toolkits targeted towards PHP developers? I am currently working on a project that could definately gain a lot from AJAX.

  • Japano AJAX Integration (Score:3, Insightful)

    by fforw ( 116415 ) on Thursday September 22, 2005 @11:46PM (#13626927) Homepage
    The article is surely a good entry to developing java webapplications with "AJAX" (Can't someone invent a better name?).

    For me (I am the author of japano [sourceforge.net], an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:

    • Usability first. Don't use AJAX without a decent fallback. Don't use AJAX just because you can. Use semantic, standard-conform HTML/CSS layouts.
    • Use JSON [json.org] instead of XML
    • Keep it simple. No object brokering or other fancy things. JSON transports data. Javascript requests and browser requests uses the same mechanisms.
    • Integrate. AJAX has quite some complexity overhead. Try to minimize that complexity by offering framework assistance. Japano offers two different AJAX mechanisms. Javascript views [fforw.de], and Partial updates [fforw.de].
  • Why does the Java applet security model require a browser user to set a value in their "Java Control Panel" (or other security policy equivalent), just to allow a browser to use URL class communications via a Proxy object that points at the server from which the applet was served? I'm talking about security exceptions on URLConnection.openConnection(Proxy). Stopping connections to any other host makes sense, because that could be a host within the client's firewall. But what's the point of stopping another
  • Before you jump on the AJAX bandwagon you should make sure you use it correctly. Using it correctly means augmenting your application with AJAX until assistve devices have caught up with AJAX/based apps.

    More on AJAX and accessibility can be found here: AJAX and Accessibility [standards-...ndards.com].

Slashdot Top Deals

E = MC ** 2 +- 3db

Close