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."
It's the rather scary idea of using JavaScript on a webpage to run XML-RPC requests to a remote server and update the local page, allowing for flashy stuff like Google Maps and GMail that does not require a new page to be loaded.
Too bad it requires JavaScript!
-mkb
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.
If you want a one hour summary, take a listen to our most recent audiobook at http://www.developeradvantage.com/products.html . It's free for now.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
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!
Not the most definitve source, but this should give you an adequate overview:
http://en.wikipedia.org/wiki/AJAX
An overhyped buzzword.
...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.
Ajax was a king of Salamis, and a legendary hero of ancient Greece.
The World Wide Web is dying. Soon, we shall have only the Internet.
You don't have the slightest idea what it is, do you? I was going to moderate this down, but there was no selection for 'ignorant'
THIS post is off-topic.
The World Wide Web is dying. Soon, we shall have only the Internet.
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
See AJAX
Um, no. That first "A" stands for Asynchronous. There's more to it than just some javascript and server-side scripting. Just for fun, rtfa?
Wow. Usually I would make sure I know what I'm talking about before referring to people as morons or PHB's. You really have no idea what an AJAX page is, do you? You seriously think it's related to PHP and server side scripting? Maybe you're trolling, if so - good one.
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.
Or would you rather they posted AC with a "d00ds look at this cool link I just found"?
(Probably would have worked better for 'em ;-)
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.
... and a bleach!
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.
Thanks. Sometimes I really don't understand the censoring, I mean mod system here. Our audiobooks are currently freely downloadable, we have no advertising on our side, and it seems reasonable and on topic that if someone asks about Ajax to point them to our material. After all, this whole thread is about an article from a huge, profitable corporation. Maybe instead of audiobooks, I should call them "audicles", and then it will be ok to mention them when people are looking for information.
Anyway, thanks again.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
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
You'd be wrong. I don't believe slashdot uses any Javascript, except maybe some ad stuff. And even if it did, that's not a good definition. The point of Ajax is updating the client's display with new data from the server without reloading the entire page. This is why Ajax is so trendy - these pages are more pleasant to use because they respond more quickly, and without unrelated parts of the display going away and coming back or causing everything to scroll away from what you were looking at.
Ajax accomplishes this with the XMLHttpRequest() object. (It's a misnomer - XML doesn't have to be involved at all.) It's just a way to issue a request and execute some code when it completes (by success, failure, or timeout). That code can update a status bar, add some text to the page, or do something more sophisticated.
AJAX was in Flash Gordon!!!
:-D G
Flash!!!
AAahhhh!!!
He saved everyone of us!!!
So have they figured out how to have the back button not wreak havoc on the page yet?
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
The core concept of AJAX is to use Javascript in the browser to make requests to the server and then update the browser without having to load a new web page. This is accomplished by using the XMLHTTPRequest object which is available in one form or another in the lastest major browsers. This concept isn't particularly new (I worked on a project in 1999 that used a Java Applet to do the work that XMLHTTPRequest now does). However, what is new is that the technology is available natively in the major browsers, and can be used to make web-based applications more interactive and user friendly, without requiring any additional plug-ins. However, AJAX is currently a hot buzzword and way over-hyped. Anyone who already has solid Javascript skills and knows a server side scripting language should be able to pick up AJAX in a couple of hours. Eventually, there will be a nice OSS AJAX library available that will hide the details, but for right now, there's nothing better than an intimate understanding of the XMLHTTPRequest object.
In a nutshell, AJAX allows the client (your web browser) to talk to the server (whatever site you're browsing) without requiring you to reload the page. It uses JavaScript's XMLHttpRequest object to open a connection, send, and receive data. Generally you either recieve data in a long string of text, or you can use the browser's built-in ability to parse and XML sent over the wire.
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.
Call them "podcasts" for Web 2.0 compliance.
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
Yeah! Really! Too bad it uses a common technology most browsers implement!
Go back to your <blink> tags...
Ajax is a recent word used to describe a combination of a couple of elements JavaScript (specifically the xmlhttprequest call), XML (used to send organized data that can be easily parsed), and an html page.
There are a couple of good examples mentioned above.
Firefox 2.0 - Spell Rightly.
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...)
Does AJAX do anything that Flash can't?
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.
The acronym actually stands for Asynchronous Java-Script And XML
...and I'll recognize that as an honest answer, as long as you weren't trolling with that question.
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.
It actually works pretty well in Gmail.
It won't break your "rich web application" every time they decide to ship a new version or player?
sounds like a personal problem!
Ajax is also Ontario's First ISO 9001 Quality Community.
It has a beautiful waterfront.
Thanks for the downloads. I'll listen to them later this week.
It runs on browsers that don't have the Flash plugin installed.
No, I'm not being a smartass. It situations where the plugin may not be installed, such as a public terminal, AJAX would work as long as JavaScript was enabled.
There's a lot of stuff that Flash can do that AJAX can't right now. Animation, specificaly. However, there's been some work put into the CANVAS tag (inc. having one available for IE) that can handle some pretty cool animation stuff without requiring a plugin.
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.
It's that stuff you clean your bathtub with.
I was born and raised there and lived mere steps from the waterfront. Let me tell you: it was not beautiful. It was mostly a construction dumping ground populated by gulls and garbage. It's only redeeming value is that it provided at least one direction to look which was not interupted by Ajax's only other distinguishing feature: an abundance of coffee shops, strip malls, and seniors' homes. Seriously, if there isn't a coffee shop on a street corner, there's a seniors' home. I remember one strip mall that had two drivethru coffee shops in the parking lot alone. Another coffee shop or two inside the mall, with one across the street in the another strip mall.
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".
Well-formed (X)HTML would be considered a subset of XML.
*pant* *pant* *heave*
prevent back button havoc : document.request.replace('empty.html')
xhtml IS html presented as xml... and you can still use AJAX without touching XML.
"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..
Degrades gracefully.
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