Hmmm. Im not sure. This wasnt working for me in dev or production. And the
timestamps are there in both environments.You are right about what theyre
meant for though. I read about it here http://ahref.in/79887
Its explained a bit more in detail in the API under the Using Asset
"This allows you to set a cache-expiration date for the asset far into the
future, but still be able to instantly invalidate it by simply updating the
I updated my JS files in my project in dev but it dint work. Everything
following that line in the API, goes right over my head. He's talking about
setting a future cache expiration time.. dont quite grasp that.
On Mon, Apr 27, 2009 at 7:41 PM, Walter Lee Davis <wa...@wdstudio.com>wrote:
> Hmmm. Well, that's odd, but chalk one up to Rails and its development/
> test/production "environments". The querystring at the end of the
> filename is there to "force" the browser to get a newer version of the
> script. That number is the current time in Unix time() mode, I think,
> or it may be keyed to the migration timestamp, I can't recall. In
> production mode, I don't think you see that -- so the browser is
> encouraged to cache the script for better performance. Maybe your code
> was stuck on a cached version with an error in it -- an error you
> subsequently fixed.
> On Apr 27, 2009, at 9:38 AM, Vinay Seshadri wrote:
> > Im so sorry to have put you through all that only for it to end up
> > being something so silly!!
> > Im going to see if anyone else has discussed such behaviour before
> > anywhere online. If not, gonna start a thread in a Rails forum to
> > see what others think about it.
In Sport We Trust !!!
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at