Posts tagged ajax

Cache busting AJAX requests and redirects

0

AJAX get and head requests are cached by default. This can cause problems when AJAX requests use the same URLs as a user would use during normal site navigation. jQuery can disable caching on a global or per-request basis. When doing so, jQuery adds a _={timestamp} parameter to the query string which should make each request unique. However, there are cases where an AJAX request results in a redirect which jQuery will happily follow. When that happens the _={timestamp} isn’t automatically appended to the new request, so the final response can still end up being cached by the browser even when you’ve told jQuery not to cache it. You can get around this in 2 ways:

  1. Make sure all redirects persist the _={timestamp} parameter, if present
  2. Add the proper header response parameters to prevent the browser from caching the request.

Here’s an easy way to implement the 2nd solution in Rails:

Dynamic enum fields in nested association forms in Rails Admin

4

We’ve had a few projects at Panoptic Development recently that made use of the RailsAdmin gem. Out of the box, RA satisfied about 95% of what we needed to do to complete each project, but there were a few edge requirements that we either had to make do without or find workarounds for. Don’t get me wrong, RA is a wonderful utility for quickly spinning up an administrative area for your Rails app. It’s loaded with really slick bells-and-whistles, and it has an incredibly flexible DSL for configuration. However, there are a few things it just doesn’t seem to be able to handle as-is and for which I’ve searched high and low for solutions for the last 9 months. I’m happy to report that I finally cracked one of these problems, and it wasn’t even all that complicated in the end.

(more…)

A note about synchronous xmlhttp requests and Firefox

0

Since I just spent the better part of Friday debugging this problem and then the better part of Friday night Googling for a work around, it’s worth noting that there is a “bug” in the Firefox implementation of the xmlHTTPRequest object when using it for synchronous calls (i.e. the rest of the script pauses and waits for the request to complete, unlike typical asynchronous AJAX calls). When using the xmlhttp object in a synchronous fashion, Firefox does not process the onreadystatechange handler. Thus, any libraries that are dependent on this (for running post processing functions for example) will fail to work under these conditions. Interestingly, having the Firebug extension installed causes the object to behave properly. So a secondary note is to always test your apps in a “clean” instance of Firefox.

Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem.

I’ve also set up a set of tests to demonstrate the problem. Try in both Firefox and IE to see the differences.

* This post was originally published on June 5, 2007 at http://www.csb7.com/blogs/whyblogwhy/2007/06/05/a_note_about_synchronous_xmlhttp_request

Go to Top