[Lift] Re: timestamp versioning for javascript includes
On Wed, Apr 29, 2009 at 7:14 PM, David Pollak feeder.of.the.be...@gmail.com wrote: /classpath/date_2009_04_29_18_20/json.js i don't really see many advantages to having the number half way through the path, only disadvantages, it makes it slightly more difficult to see / copy and paste the referenced path, for no real bonus. why not just use ?2009042912342343etc. the funny numbers in rails are inode numbers or unix date stamps (can't remember which). japanese style dates are much nicer. and use of currentyear makes it completely obvious what the number is which is not the case for rails style. On Wed, Apr 29, 2009 at 10:03 AM, Lee Mighdoll l...@underneath.ca wrote: I think the browsers cache urls with params... a quick glance at the rails docs suggest they expect these requests to be cached, though I haven't tested it mysolf. yes, the browsers cache. Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: timestamp versioning for javascript includes
On Wed, Apr 29, 2009 at 9:19 AM, Lee Mighdoll l...@underneath.ca wrote: I'm trying to avoid having to clear the browser cache when I change a javascript file. One approach is to append a timestamp to the script src tag in the html file. script id=json src=/classpath/json.js type=text/javascript/ becomes: script id=json src=/classpath/json.js?*12341234* type=text/javascript/ I'm told rails uses this approach. Is there already a handy way to do this in lift? Or is there a better way? So that's why there are those ugly numbers at the end of js file names in Rails... I've always wondered. I'd rather have something like: /classpath/date_2009_04_29_18_20/json.js There are a couple of advantages: - It's human readable - It's better for caching as the browser can continue to cache the file rather than making an HTTP request because of the params Happy to try and make a snippet for this if it's useful for others. Sure. Lee -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: timestamp versioning for javascript includes
I'd rather have something like: /classpath/date_2009_04_29_18_20/json.js There are a couple of advantages: - It's human readable Readable is worth a few bytes, I agree. I like the date_ prefix too, it leaves room for using a hash approach at some future date. - - It's better for caching as the browser can continue to cache the file rather than making an HTTP request because of the params I think the browsers cache urls with params... a quick glance at the rails docs suggest they expect these requests to be cached, though I haven't tested it mysolf. I'd imagine this also needs to work for non-/classpath served files. Does that push us back to the params style? Happy to try and make a snippet for this if it's useful for others. Sure. Glad to have a way to help. Heading on vacation now, I'll give it a try next week. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: timestamp versioning for javascript includes
On Wed, Apr 29, 2009 at 10:03 AM, Lee Mighdoll l...@underneath.ca wrote: I'd rather have something like: /classpath/date_2009_04_29_18_20/json.js There are a couple of advantages: - It's human readable Readable is worth a few bytes, I agree. I like the date_ prefix too, it leaves room for using a hash approach at some future date. - - It's better for caching as the browser can continue to cache the file rather than making an HTTP request because of the params I think the browsers cache urls with params... a quick glance at the rails docs suggest they expect these requests to be cached, though I haven't tested it mysolf. I'd imagine this also needs to work for non-/classpath served files. Does that push us back to the params style? No, because you can rewrite the incoming URLs back to what they should be. Happy to try and make a snippet for this if it's useful for others. Sure. Glad to have a way to help. Heading on vacation now, I'll give it a try next week. Have a fun vacation. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: timestamp versioning for javascript includes
I think the browsers cache urls with params... a quick glance at the rails
docs suggest they expect these requests to be cached, though I haven't
tested it mysolf.
I'd imagine this also needs to work for non-/classpath served files. Does
that push us back to the params style?
No, because you can rewrite the incoming URLs back to what they should be.
So if I understand you correctly, /date_{date_format} will become magic
anywhere in url request paths. so these work too:
classpath/js/date_2009_04_29_18_20/json.s or
/foo/bar/date_2009_04_29_18_20/json.s.
That's ok with me, though it's a bit more aggressive to mess with the
segments of the mapping of the url path to file system path.
Potentially could use dates on directories then too, although I'm not quite
sure why. e.g. foo/date_2009_04_29_18_20/bar/json.js would check the
modification date of the bar directory..
Lee
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: timestamp versioning for javascript includes
On Wed, Apr 29, 2009 at 10:58 AM, Lee Mighdoll l...@underneath.ca wrote:
I think the browsers cache urls with params... a quick glance at the rails
docs suggest they expect these requests to be cached, though I haven't
tested it mysolf.
I'd imagine this also needs to work for non-/classpath served files.
Does that push us back to the params style?
No, because you can rewrite the incoming URLs back to what they should be.
So if I understand you correctly, /date_{date_format} will become magic
anywhere in url request paths. so these work too:
classpath/js/date_2009_04_29_18_20/json.s or
/foo/bar/date_2009_04_29_18_20/json.s.
That's ok with me, though it's a bit more aggressive to mess with the
segments of the mapping of the url path to file system path.
Potentially could use dates on directories then too, although I'm not quite
sure why. e.g. foo/date_2009_04_29_18_20/bar/json.js would check the
modification date of the bar directory..
or:
/classpath/date_2009_04_29_18_20/classpath.js - /classpath/classpath.js
/dated_resource/date_2009_04_29_18_20/my_resource_dir/my_resource.js -
/my_resource_dir/my_resource.js
Lee
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
