Better Web Apps With Ajax 184
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."
Two camps (Score:4, Insightful)
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:When you're using java, you can... (Score:3, Insightful)
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 would be simple, clean and functional. And it might be a simple matter of saying my content type is text/html instead of application/xml.
Why put the burden on JavaScript on the client, when I already know how to do it on the server? In terms of server processor time, it's just as easy to spit out HTML directly than it is to spit out XML and translate it to HTML on the other side.
And if it is easy to do this, I'd appreciate a link to a tutorial.
Many thanks for your time and ideas.
D
Re:The problem with AJAX is the X (Score:3, Insightful)
Third camp sees this? (Score:2, Insightful)
<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>
Re:When you're using java, you can... (Score:2, Insightful)
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 language you are using. If I also want to manipulate the data with a script, I can write that in any language, using standard XML APIs, not just one that can interpret Javascript.
Given that the difference in effort between the two is so minimal, I prefer to use the more flexible approach.
Re:When you're using java, you can... (Score:2, Insightful)
Now picture this. A windowing system, to run in IE4 or Netscape 4 written by someone who doesn't know what they're doing. You want memory leaks? We had 'em. Most of the clients' machines would die after ten minutes running this. You want race conditions? Yup we those had those ose se e as we.
ll
This thing was so asynchronous it would frequently try to write to HTML elements that didn't exist yet... or that did exist but that the browser had decided they'd disappeared. Netscape 4 was the best at this. If a string was too long suddenly the rest of the dom disappeared into recursion hell and you couldn't drill down into the necessary layer.
In the end I had to write JavaBeans to write the HTML which would then modify itself or not as the case may be...
It was not merely a dog. It stank, whatever way you looked at it. Consequently the company never touched a DHTML project again and when they finally decided to upgrade the site they simply wrote a flat HTML version.
I get flashbacks just thinking about it.
But as a result I learnt that using a non-standard, custom server response may reduce project maintainability. And may reduce the likelihood of you keeping your job.
Re:Can't Colgate sue "someone" for using the AJAX (Score:3, Insightful)
You're thinking, no doubt (?), of trademark law. Trademarks are technology specific. So unless "someone" is creating a cleaning solution and "passing off" that product as Colgates (?) Ajax
Colgate could still sue. But they shouldn't win!
Japano AJAX Integration (Score:3, Insightful)
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: