Slashdot Mirror
Advanced Requests and Responses in Ajax
An anonymous reader writes "The Web is no longer a place where simple applications are tolerated; 'users have become more advanced, customers expect robustness and advanced error reporting, and managers are fired because an application goes down 1 percent of the time. It's your job then, to go beyond a simple Ajax application that requires a more thorough understanding of XMLHttpRequest.' This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly."
What is AJAX really?
FP AJAX RULEZ
Great, if everyone starts using AJAX to build "sick" web apps, then it's just a matter of time before they're hitting some registers that will force me to reboot my windoze pc at work from a freaking javascript error. Yay!
stuff |
Um, aren't these concepts something we learned in college??? This is just basic stuff... although I think it highlights how RAD languages can teach you sloppy coding habits if you don't take the time do do things correctly.
ConsultingFair.com
Perhaps someone should write an article on how to write robust AJAX code. Oh, wait...
sigs, as if you care.
I think the article covers some things that are missing in a lot of ajax classes available, but really is nothing new. My own ajax class is far, far superior (trying to get the okay from work to OSS it).
Too many classes are using a global httprequest object. This is not good if you are doing many requests (though I suppose uses less memory). There's also no timeout for graceful handling of a slow server. I've done quite a bit in the way of error handling.
At least this one doesn't make you learn a damn mini-language... a major pet peeve of mine!
...This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly.
That's good, because none of the commercial "enterprise class" software that I have to work with handles errors and problems smoothly. They just crash or send an error message that has no relation ot the actual problem.
You never really know how close to the edge you can go until you fall off.
users have become more advanced
.. do they care how those are achieved? Generally, nope.
.. the article talks about AJAX .. AJAX relies on JavaScript. Between 7% and 10% of web users have JavaScript turned off either implicitly or due to their IE security level. Surely if you're creating an AJAX application then you must realise the application is already unavailable to 7% of users even when your server is up and running? If high availability is key then you'd better not be using anything beyond HTML.
They really haven't actually. They've stopped being mostly geeks and academics and now the internet is open to all. Users are much, much less advanced today than they were ten years ago. What has changed in more recent times is that the users now they're think more advanced. They're presented with interesting social networks (FlickR, Blogger, deli.co.us, etc), and they're capable of using these straightforward interfaces with lots of handholding (rebranding categories as tags for example) and they get the impression that they're learning something. Does that mean they know, or care, what an XMLHTTPRequest is? Nope.
The same goes for customers. Yes, they want advanced reporting and robust apps
As for managers being fired for an application being unavailable 1% of the time
http://twitter.com/onion2k
In this day and age a lot of us are asked to program who are not by nature computer programmers. In a perfect world all the programmers would be CS majors. For example, I am an Aerospace Engineer, however I spend 6 hours a day writing code in c++. It isn't pretty but it works. Why? The company I work for could either:
:P
(a) Hire engineers who know engineering and are crappy programmers, and make them learn programming, or
(b) Hire CS majors who don't know engineering, and spend 4 years to teach them engineering
(a) makes more sense to me. A lot of my code looks like crap, and I know my CS friends could do better quicker, but they don't know the engineering principles I do. Long story short, I didn't have CS101, CS102, etc. There are a lot of us out here who are asked to code, who weren't brought up to be coders, who have to be taught some principles that aren't immediately apparent
Any decent webdev entering the field should know about http status codes, HEAD requests and all that. Also it should be noted that article didn't even mention how many times state 3 is hit for a particular request - I got caught by that one once.
Quidquid latine dictum sit, altum videtur
For a moment there I thought I was reading propaganda from the back of the latest video game...
http://download.boulder.ibm.com/ibmdl/pub/softwar
Taking the "%20" away from the final "/" made it work.
(There should be no spaces in the URL.)
sigs, as if you care.
Every Ajax application uses the XMLHttpRequest object, so you'll want to be intimately familiar with it to make your Ajax applications perform and perform well.
I think this is true right now, at least to some extent, but as frameworks solidify and become proven, there will be less benefit to being "intimately familiar" with the XMLHttpRequest object. Of course, knowing more about the underlying technology can't hurt, and you will need to know them if you are the one writing a framework.
For a very good source on frameworks, take a look at http://ajaxpatterns.org/Ajax_Frameworks
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
Sure it is. Most web applications that I use, whether if they make use of AJAX or not, could certainly be plenty usable and valuable without AJAX.
AJAX makes some things possible that aren't possible using plain HTML, but it doesn't make ALL plain HTML so much better that it would be impossible to imagine the site without it.
This will merely lead to better javascript filters.
Your adds will continue to be blocked.
The Web is no longer a place where simple applications are tolerated
Not so. Simple = GOOD, just look at the success of google; no fancy front end required. AJAX, like good special effects in a movie, can enhance the end-user experience when applied selectively and intelligently. They are NOT an end in themselves.
The truth is, the web is a place were only USEFUL applications are tolerated, whether or not they use AJAX.
"Is this just useless, or is it expensive as well?"
The Web is no longer a place for information exchange. It is a place to invest your money, to hire more and more coders/artists/testers/managers, to maintain all this eye-candy. There is a reason: It looks just like a real application inside your web browser!
We don't have anything special to say. But now instead of looking for a `Back' button, you may drag-n-drop our whole corporate site directly to your Recycled Bin!
Truly implementing good error handling in web pages is something that would take a lot more effort for most people than with Swing or Windows Forms. You need to not just alert the user, but highlight their mistake which means good page layout and cooperation with your JavaScript. Highlight the field that is invalid and provide a well-designed error message explaining what went wrong.
One of the biggest problems out there is that web development is not taught in CS. Like most CS geeks, I picked up what I've learned through my own studies, few of which included how to integrate CS concepts into web page development. You either tend to see material and classes that teach web development from a page designer's perspective, or from the perspective of an enterprise architect. None of the formal classes I took in any of the different majors that touch on web development taught how to do something as simple as this for separating the JavaScript from the HTML.
What Quarters said, plus you have problems with verification and validation. You need the engineers to do the actual verification and validation of the codes with the algorithms, how can they do that if they didn't write and are not compotent with the code? I think the better compromise is to hire engineers with some level of programming experiance and tolerate the fact that they will spend a few hours a week educating themselves.
Is this a joke? Thats just the usual crap that has been around for ages, and real(TM) programmers have been using this anyway.
The web went to shit back in 1996 back when Mosaic was released. ...and from there, browsers only got more and more bloated as time went on.
Putting the internet into the hands of the stupid undeserving proles
I'm typing this in Links and as a True Command-Line-Only Unix user you should too!
Simply using firefox does not make users 'more advanced'.
Just because you prefer DIV over TABLE does not make you a 'more advanced' HTML/CSS Programmer, it actually proves your lack of experience in the real-world.
Introducing asynchronous functionality into your web page does not make it 'more advanced', it is just an 'alternative' design pattern.
AJAX is simply a design pattern people.
Whoever made the site 'AJAXDesignPatterns.com', has no clue what they are talking about.
the only permanence in existence, is the impermanence of existence.
All this low-level stuff was nice to know a year ago, but I don't really think it's apropriate anymore to start from the bottom up like this. You should really be using one of the great AJAX frameworks out there for stuff like this. Dojo is great for any application, and if you're using .NET, you can't beat Atlas. Actually, I'm not sure that anything can beat Atlas. :D
AJAX was in Flash Gordon!!!
:-D G
Flash!!!
AAahhhh!!!
He saved everyone of us!!!
I know of an AJAX RAD framework (http://www.javeline.org/ that has implicit error handling through 'SmartBindings' it works by automatically keeping the client side data consistent using a transaction manager, independant of server architecture. Transactions can fail at a higher level than plain communication also (serverside validation failed or user logged out or things like that). Its works a bit like an 'undo stack' on the client, purely XML based. Its written by the developer of the vcXMLRPC library, one of first opensource ajax libraries.
'users have become more advanced'
try some usability testing and see how advanced typical users are
"where's the any key?"
Next to General Agamemmnon, he was the most ruthless of the Titans during the Butlerian Jihad.
Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.
You know, a downtime of 1 percent is almost 4 whole days a year. That is a lot of "sorry we're closed" (or "building is gone") if you are supposed to have a 24/7 business. I don't think it's unreasonable to have slightly higher demands than that.
Spine World
I still think AJAX is ok in a minimal use, but I've written plenty of ajax-free web apps that work great with no complaints from users. I'm all for the ipod approach -> Give them something that works and isn't hard to use, even if it does make the page refresh.
firestream.net
Where's the ajax on slashdot? Are we supposed to be rebelling because it uses the traditional get/post methods instead of the (new name, old technology) "ajax" version?
.com's? Or on mainstream news sites?
Where's the ajax on msn & yahoo
Ajax is a "web two point oh" buzzword, and 99% of "web two point oh" services/systems aren't going to be a success just because they utilize it.
I'm not disputing it can be useful and add something to an application, but the hype outweighs the benefit.
One thing I fear about ajax is the poor standards many developers work to - how long before we see phpbb/phpnuke/et al tearing servers apart because each visitor is suddenly making an extra 10 database queries a minute while previously they'd alt-tab back and hit refresh every few minutes?
The parent is not funny. Except to people with no life.
There just couldn't be room left in the summary for any more marketing hype. Blarf.
"users have become more advanced"
Uh, no. Sorry. Please don't try again.
AC
I Think ill stick with basic post pages.... this article gave me a headache... Does anyone know/care what all that crap means
Forget about the back button...that is an annoyance I've grown to tolerate (for almost a decade we've had to deal with "sticky" web pages). MY biggest concerns centre on SECURITY and PRIVACY.
;-)
One thing about Javascript is that it is very aware of the client's environment--we can use it to determine screen size, colour depth, browser type, browser history and so forth. Until the introduction of the XMLHTTPRequest object, developers were limited in how they could bring this information into the server. It wasn't impossible (you could do stuff with traditional javascript and server-side programming involving hidden input tags, cookies, automatic page submits/reloads, etc), however the user would usually have a visual cue (IE would produce an audible "click" during page submits and redirects by default, the page would blink, the "throbber" icon and status bar would indicate an HTTP request was happening, etc). Furthermore, such schemes were more easily breakable (disablihng cookies, etc).
Now with AJAX, a coder could write client side script that (for example) enumerates your browser's history and ships it back using the XMLHTTPRequest object. The page does not need to use cookies, install special software like IE "browser helper objects" or need to expose itself through the use of hidden input tags. It's the greatest thing since sliced bread for spyware developers (multi-platform, lightweight, not yet easy to detect). I think javascript is generally better contained than, say, VBS, from a security standpoint, but I still have my concerns.
Worse yet, there isn't much in the way of user control--a person can disable Javascript entirely but then the whole app breaks. Browsers like Firefox can limit the use of javascript to do popo-up ads, alter toolbars and such, but I see nothing regarding security control of the XMLHTTPRequest object. As far as I can tell, if Javascript is enabled at all, a script can make full use of that object, and it'd be REALLY easy to use it to report my browsing history on a constant basis, without me knowing about it unless I do a lot of sleuthing in source files and cache.
In any case, I have some questions for "seasoned" AJAX coders (I am well-versed in Javascript but am a neophyte with ful-blown AJAX apps): What do you do to make sure your app is secure from client-side shenanigans (perhaps an AJAX-equivalent to SQL-injection), what can a user do to manage security within your AJAX app, and have you used AJAX techniques for potentially intrusive purposes (sniffing a client's environment in particular)? You can post anonymously if you've had to "do evil" as part of your job if you want
(BTW, a competent AJAX developer would at least take measures to disable the back button's functionality, and there are measures that can be taken to handle the back button gracefully. It is mostly a matter of sound design...)
There is a common misconception in this thread that needs to be cleared up.
The website visitors are not customers. The customer is the company buying the ads. The website visitors are the product being sold to the advertisers.
http://www.nextapp.com/platform/echo2/echo/
If you want a proper application that handles user and error conditions gracefully, it helps to use a tool that aids good design.
Echo2 lets you build AJAX applications as if you were writing a swing app.
No messy html/javascript. You don't even need to know that XMLHttpRequest exists.
I'm currently in the process of building an AJAX app for a large financial institution and all I can say is thank god I don't have to mess about in javascript to make a nice application.
If this line of reasoning, there would be no need for medical malpractice insurance either, because doctors would learn to do things exactly right each and every time early in medical school.
Fact is, the world is a complicated place. Not only do people, even highly trained professionals, make mistakes from time to time - situations change, often unpredictably, and even the most reasonable and appropriate strategies suddenly become grossly inadequate.
Software solutions are developed with budgets and schedules in mind, for problem domains that are vastly more complex than those of the toys we write in college. We interface with systems over which we have little or no control. Design specifications, even if they were clear at some point, are often exceeded. Honestly, it's amazing that we do manage a 99% uptime.
This is of course not an excuse for when things fail. We need to prevent failure, anticipate it and avoid it when possible. We need to handle it gracefully when unavoidable, so that we could learn from the failure and avoid it the next time.
But the cavalier attitude of saying that writing perfect, flawless and error-free software is something we learn in CS-101 is naive, and condescending to the hundreds of thousands (millions?) of professional software developers all over the world. It's like saying that just because we learned how to make a paper airplane in introductory Physics, we should be expected to design and build jumbo-jets that never crash, use air for fuel, and provide plenty of over-head storage and leg-room for everyone on-board.
-- What you do today will cost you a day of your life.
I've heard this line of thought more times than I care to remember, and the standard response is that it's possible to write good or bad code in any language.
I've seen (in school) C++ programs where the "programmer" had named all of their variables after fruits (strawberry, kiwi...), and all of their methods after greek letters (theta, alpha...). Style is style is style. You can't put a bad programmer in front of a c++ compiler and expect their code to be any better than it would have been in perl or python.
On the other hand, any good programmer can sit down with any language *that they know well* and write beautiful code. The learning process certainly impacts style in the short term, which is why I emphasize this.
I don't understand this insistence that a compiler somehow makes code better. After all, even the more complex "scripting" languages are basically JIT compiled to some fashion of bytecode these days (read: perl, python, and, I think, ruby, among others). They'll barf at compile-time, as opposed to running until they hit a syntax error, like shell or the old BASICs.
So, I call "strawman" on the compiler argument, and say that the real problem is bad programmers.
The whole issue is a lot like this recent hot topic of "free speech." Just because you *can* say something doesn't mean you *should* say it at the first opportunity. A certain consideration must be made. The analogy is a direct one. Human language to computer language. You've been given more power with a scripting language. Use it responsibly. A good programmer will do this, just as a gentleman will consider his words carefully.
Gentleman == Good programmer
It's easy.
There are many applications that could make good use of AJAX, it will just likely become a way to create intrusive advertisements when marketing departments get a hold of it (IE: Popup Windows, Flash, Gifs, etc).
The other half will consist of developers who just want to put AJAX on their resume and so they over complicate Hello World! apps.
YAY!blaming bad links on ajax is sort of desperate.
-pyrrho
It is simple really,
The attempt was to get a sleep function going because I wanted to load a very big picture but not have the user wonder why nothing was happening so I wanted to check if the image had loaded (img.complete) and if not display a loading message. Normally you would use a while loop with a sleep() call to just check every so often but javascript does not have such a function.
Oh just running an empty while loop causes firefox to popup a warning after a second or 2 about the script taking to many resources.
I figured out how to do it properly but not after first having to killall firefox-bin and shutdown explorer.exe processes. Opera, the one true king, ofcourse had no problem with it.
Relevant? Maybe, I needed the code because people can't be bothered anymore to just look at the spinning whatever or the status bar to see if a page is still loading you got to put it in the page itself so they do not hit the same request a hundred times thinking this is going to speed up the download.
Useless javascript but needed if you want your site to be accepted in this day and age.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Didn't i read all of that when i first learn about XmlHttpRequests from http://developer.apple.com/internet/webcontent/xml httpreq.html
The stuff talked about in that article is stuff we've been doing with AJAX here at my office for well over a year.
I wonder who's sleeping with the /. mods to get this sort of dated material up here.
-David
This push to create "enterprise applications" in AJAX is non-starter. You simply cannot create a robust application that can handle errors gracefully, is cross-platform, and scales well when you base it on HTTP, run it in an untrusted-browser environment, require client-side polling, and all within a language that lacks a reasonable standard library.
There are reasons CORBA quietly died, agent-based computing hasn't made any progress in industry, and open RPC-systems quickly disappeared; and it wasn't because they lacked twelve months of blogger hype.
At times like these, it's nice to know that Ruby on Rails' AJAX helper functions already handle neat things like scripting actions on errors or sending errors to a different DOM element.
Karma: It's all a bunch of tree-huggin' hippy crap!
It depends on the business. If you're selling trailer hitches to people in the US and Canada, you can get away with having "downtime" in the middle of the night because -- as much as everyone says, "you'd be surprised at how many people buy trailer hitches at 3 AM" -- the core of your business is most definitely done between 6:00 AM and 10:00 PM. This raises the question then -- what specifically is downtime. Planned? Unplanned? Etc. etc.
Please don't use "umm" or "err" or "erm".
*pant* *pant* *heave*
"from a business standpoint it isn't optimal"
That's only because business is built on greed instead of honest exchange of value. In the long run it is much better to build your business to be sustainable, but hardly any big corp now does this, they rely on being pirates and crooks more, ie, "greed".. Quick and dirty leads to quick and dirty results, which always in hindsight look retarded, because they are. What's wrong with learning from past mistakes in economics?
Oh wait, we can't, we have a greed based economy! Not fair exchange and honest effort, it's how much you can squeeze out SHORT TERM.
Mostly because most businesses are tied to two incredibly stupid functions. They must show increases every quarter or they are doing something "wrong". A simple maintenance of a reasonable profit level isn't enough, it must always *increase*. Do the math big business, this isn't possible, it's called market saturation. The second is shareholder pressure, which is tied to the "something for nothing" principle of wealth accumulation. Again, not possible in the long run, it leads to overly speculative markets,based on the lie, the con, the dodge, the shill and the bribe, leading to severe and prolonged crashes, after the inevitable bubble build up, from more or less totally insane stock prices that have no basis in any conceivable reality as to true worth. When a business or market is about to crash, you see a few things, cuts in R&D,it becomes top heavy in management and sales,and then you'll see legislative pressure for "relief". In the software world you will keep seeing this, precisely because they demanded and got all the perqs, including *patents*, with no corresponding check/balance, which is normal warranties. IF the company had to provide a warranty,legally, you WOULD see more attention made to a longer term view and better coding practices. And IF we had a more regulated market that helped eliminate speculation, such as time limits for holding shares before sales, eliminating bundling and most hedging, and increasing thresholds for divestiture, etc, along similar lines, you wouldn't see as much pressure for "this quarter's profits".
Yes. As a bonus it also fixes bookmarking and deep linking, automatically. The key is to store any changing page state data in the URL itself using the hash portion, which you can change without causing a page reload.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
I really do hate it when people try to convince me with their opinion by creating random, totally unproven statements like:
And omitting any example or proof about why they think that they are right.
-- Watch me working: www.magerquark.de
Unfortunately my answers are pretty boring, but...
:)
What can a user do to manage security within your AJAX app?
The browser gets an encrypted authentication cookie that contains your login credentials and an expiration time. When your credential expires, you are prompted to log in again. Such a system is vulnerable to sniffing, in which case you would be exposed until the credential expires. (If we were being good, we would only communicate over HTTPS, but we don't.)
What do you do to make sure your app is secure from client-side shenanigans (perhaps an AJAX-equivalent to SQL-injection)?
It's pretty straightforward: never trust any data the server receives; always assume it could be malicious, malformatted, corrupt, etc. Sanity-check and escape all values, whether received via POST, XML post, or query string. If anything is fishy, blow an exception. If you forget to check or escape a value, it's a potential security hole (yeah... we frequently forget to check them. Perl has a concept of 'taint' flags for data... ISAPI doesn't though, that I know of. We should probably roll our own!)
Have you used AJAX techniques for potentially intrusive purposes?
No, that would be gauche. Our users pay us, we don't want to risk annoying them!
Does nobody know that IBM also uses the Dojo-Toolkit, see http://www-03.ibm.com/press/us/en/pressrelease/191 87.wss?
See http://wyoguide.sf.net/papers/Cross-platform.html
It is hard to handle all these important points by just writing JavaScript manually.. For big projects, i recommend not to use AJAX or use a safety and stabilitiy proven AJAX framework.
:)
After all you won't get angry with yourself..
JavaScript lacks a good mechanism for dealing with libraries. This means that these so-called frameworks are really just a big mass of .js files which must be included into the source HTML document. Everyone ends up making their own local copies of these libraries because there is no secure way to transparently install these components in browsers for several sites to share. Consequently what you get from using one of these "frameworks" is a lot of extra cruft in your application or, if you're being conservative, your own home-rolled subset of the framework containing just the bits you're using.
So what do I want? I want some way to load, in the script itself rather than in the HTML document, a library written by someone else. I want to reference this library from its developer without having to mirror it. I want a mechanism where the browser can go off and fetch the library if it doesn't already exist, and the ability to import that module into any JavaScript object I want rather than polluting the global namespace. For all this to work without causing major problems, JavaScript's security model needs to be overhauled so that including someone else's library doesn't surrender my entire site to the library author.
Sure, I'm asking for a lot, but until something resembling the above is available we're not going to see many good "frameworks" for doing this kind of stuff, and lots of web developers will resist using them even where they do exist purely because it's far more efficient to just re-implement the little bits of framework you want than to pull in a gargantuan set of libraries just to call one function.
I do get your point (I've read the Mythical Man Month a couple time... excellent recommendation).
What I think you are forgeting in practice is that what people usually do with software flaws is live with them...
And this the hard reality of a lot of coding, they are not committing to top notch software. They don't incur those costs they just put up with the crap... and if was delivered "working" (aka "running") in the first place, it'll still be running.
people don't have the fund up front and then don't have them later either.
-pyrrho