Mootools caveat #2: noCache in new Request() is your friend
Reading the docs is really worth it’s weight in gold. Namely, noCache option/parameter for a new Request (aka. Ajax for mootools) object really does make all the difference in the world.
“noCache – (boolean; defaults to false) If true, appends a unique noCache value to the request to prevent caching. (IE has a bad habit of caching ajax request values. Including this script and setting the noCache value to true will prevent it from caching. The server should ignore the noCache value.)”
I was having a problem with ajax being ‘retrieved’ by IE, but not actually making a hit in my access log. I was baffled, and figured it was a caching issue, but confused since safari/FF were working fine.
For those of you out there, be aware of this. My specific problem was actually based on a call to something like:
http://www.website.com/controller/action/
Now I can make that exact url call and have it return a bunch of html; but for the framework I’m working in, adding a header of AC:true (short form for ‘Ajax Call’) will change the output (namely, to a JSON object instead of pure html). It seems IE was caching the request since the page had been requested without the header, and then returning it every time.
Damn you IE!!!!! I understand <link /> and <script /> and <img />’s being cached, but XHR’s? Come on. They’re based on actions (eg. click events, mouse overs, key combinations), not default behaviors of a page load (ordinarily).
Why I use Safari.
There are many browsers out there: IE6, IE7, IE8, FF, Opera, Safari, Chrome
Then there are tons of mods for each of those. On the mac, a few lesser options (FF, Opera, Safari, soon to be Chrome). I used to scoff at Safari users when it was around the 2.0 release (even 3.0 seemed crap to me). When I adopted the Mac, however, Safari fell into a different light for me. The number one reason it did was because of it’s speed.
In the 4.0 release, the first thing you realize about Safari is how fast it is. While non-web developers would often remark that there isn’t much of a difference, it’s something you pick up very noticeably when you spend 10 hours in a browser. It’s not that every second counts, it’s just that you notice it and lean towards the one that will save you any time at all.
As a developer, it misses many things like Firebug, plugins (has a few, but not comparable), web developer toolbar, and while Safari has it’s own web-kit based inspector, in my opinion, it’s terrible. You can view the DOM, but not do much with it.
I find that the only time I’m not using Safari is when I need to do some post-render editing using firebug, or test out a plugin in FF; any other time, Safari and it’s speed an UI dominate for me. My only hope that it gets a little more plugin compliant to make it more useful more of the time.