Slashdot Mirror
Better Web Apps With Ajax
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."
Cleaner code than the rest!
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.
Rex is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Atlas 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 about what Microsoft is doing on the AJAX front elsewhere.
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).
...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.
Personally, I'm a perl monger, so I use this lib, 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.
Mod me down and I will become more powerful than you can possibly imagine!
I much prefer a seaside solution.
--
The "are you a script" word for today is platform.
almost as though there was nothing there. Except the concept...
By the by, from the IBM site:
> Server load
>
> Implementing an Ajax UI in place of a regular forms-based one may dramatically
> increase the number of requests made to the server.
Will be interesting to see how it responds to a slashdotting...
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.
revolutionary or not, "AJAX" is now used in lots of languages. and there are some good tools out there. there's ruby on rails with the prototype library which is also now available in perl. there's also CGI::Ajax which is pretty simple to apply... and it's perl!
Also interesting on the IBM site is a comparison between the use of J2EE and Ruby on Rails, another great way of achieving Ajax functionality.
Why not just use Echo2 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.
TrackIt is an application that takes advantage of all of the above technologies.
There's a pretty good library I've used recently called DWR.
If you're looking for a Java library to do some of the heavy lifting, check it out.
Check out the new cal for Hula http://hula-project.org/Hula_Server - amazing work.
And the front end to the webmail for Zimbra http://www.zimbra.com/
Really, really nice stuff.
bad_outlook
--
Is this vague enough for you?
<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 because we are too busy fapping to the latest buzzword to give a shit about you.
</noscript>
</body>
</html>
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/, all that's needed are some AJAX functions to swap out the contents of each window, instant freakish web-app thing..
brand name?
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 bandwidth requirements into account. Is an XML document bigger than a binary data stream? Sure. Is this significant? Depends on your application.
First, Unicode under JSON is abit exciting. In XML there are no surprises.
Secondly, XML is transported over HTTP 90% of the time.
Almost all modern HTTP implementations implement GZIP as an encoding. If you don't already have this enabled in your servers, then you don't really care about bandwidth utilization.
JSON offers nothing useful over XML+GZIP (which is a transport/encoding issue anyway). It can, however, make it vastly more difficult to interchange your data and tie you to a limited object model. If anything, I support the process used by the W3C. I like their standards. JSON is nice, but not nice enough. Sorry guys.
Learn XML. Learn XPATH. Try to use Twisted's XMLSTREAM implementation for a taste of how easy and flexible it can be. Write some Jabber apps. JSON can't really be in those spaces. Not anytime soon at least.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
Since everyone else is mentioning their favorite AJAX toolkit, I'll list one too:
x .html
http://javawebparts.sourceforge.net/javadocs/inde
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/
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Cpaint
I am using it now. seems to be working very well. has a Javascript library and both PHP and ASP backends. Can't talk to how the ASP side works, but the php side is very simple/straightforward.
To E-mail me, replace the first period in my domain with an @
For me (I am the author of japano, an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:
while (!asleep()) sheep++
"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.
I8-D
More on AJAX and accessibility can be found here: AJAX and Accessibility.
Standards Schmandards