On 7. des. 2005, at 23.52, Bob Ippolito wrote:
Generating a random number is insignificant. A timestamp would probably be better though given the use case.
Anyway, the right answer is to do it from _javascript_ if you have to do it at all. Doing it from the TG side is nearly worthless because only one unique identifier is going to end up in the page, but you almost definitely need to fetch that JSON URL more than once during the page view.
Is it *really* that hard?
loadJSONDoc(url, {uid: (new Date()).getTime()});
or if you already have a query string in there you'd have to do it yourself:
loadJSONDoc(url + "&uid=" + (new Date()).getTime());
-bob
I may not have made my self completely clear in my original proposal.
I'm unable to make loadJSONDoc("${std.url('/Edit'/,rand="+Math.random()+"tg_format='json')}") work. KID obviously frowns upon gluing together a template function.
The one way I found to get this to work was to have turbogears.stdvars create the hash when firing the ${std.} function: loadJSONDoc("${std.url('/Edit'/,rand=std.hash(),tg_format='json')}")
That way the hash gets created only when using the ${std.} function in a template, and it guarantees a "fresh" hash every time function ${std.} is called.
regards /rune
On Dec 7, 2005, at 2:21 PM, Erik Smartt wrote:
I like the idea of providing a workaround for URL caching (I know I've dealt with this problem in the past as well), but at the same time, if the proposed code is added to turbogears.view, then computing a random number happens with every page view whether you want it or not. Personally, I'd rather avoid adding extra processing overhead when not needed. Can this be something we toggle on/off or only use when needed? (ex., one can already add their own variables to 'std' if needed.)
Cheers, Erik
On Dec 7, 2005, at 1:30 PM, Jonathan LaCour wrote:
On Dec 7, 2005, at 3:58 PM, Bob Ippolito wrote: If we were adding something for this explicit purpose, I'd prefer to add a flag to the url function and then have TurboGears eat the incoming "tg_random" variable so that you don't need to add another parameter to your methods.
FYI, I've opened ticket 196 to implement this solution. It's a small enough task that I've targeted it for 0.9.
Why not just set the cache headers correctly instead?
I tried this repeatedly, and never was able to get it working with IE. The only solution I have found that works is sending a timestamp in the URL (which is similar to the proposed hash solution).
Have you had a different experience with XMLHttpRequest and caching in IE? If so, exactly what headers did you have to send? This would be a much more elegant solution if it actually works :)
Setting Expires should work, but I don't have a Windows box in front of me to confirm that I'm remembering it correctly.
-bob
--------------------------------------------------------------------- Behind the firewall, nobody can hear you scream...
|
