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."
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.
...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!
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.
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 sources on line. Its not just for XML and its not just a J language either... Ruby will do.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
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?
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.
DWR integrates integrates nicely with the Spring Framework (see this blog entry for an example), which is why I've been using it in my apps lately. Very cool stuff!
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)
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 @
"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
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're using the above three things it's not AJAX. For instance, while you could replace JavaScript with VBScript (in IE), that'd more correctly be called AVAX.
Personally, I think calling AJAX AJAX is stupid, as it leads to the sort of misunderstandings that you seem to have, but I guess most people like to have short, snappy names for things.
It's official. Most of you are morons.
More on AJAX and accessibility can be found here: AJAX and Accessibility.
Standards Schmandards