Re: OT: Versioning in Javascript Files
On Mon, Apr 11, 2011 at 23:47, George Sexton geor...@mhsoftware.com wrote: I'm looking for ideas on how other people are doing versioning in Javascript files. I'm hitting issues if I change my files in an incompatible way, or I upgrade files. For example, if I upgrade from DOJO 1.5 to DOJO 1.6, the user's browsers are not always refreshing the DOJO files, and things don't work. Similarly, if I update a javascript function to take additional arguments, then the browser using the old version throws an error. I've spent a lot of time in the past few days telling users to click on the refresh button of their browser and I'm pretty sick of it. I've thought of versioning my whole scripts directory. IOW, if my app version is 3.4.9, make the scripts directory scripts-3.4.9 to force the browser to get files from the new location. This is kind of a pain for version control reasons but otherwise it's OK. I'm really looking for ideas on how other web developers are handling this problem. Simple solution: change paths if you change versions! 1.5 would be /static/dojo-1.5.js, 1.6 would be /static/dojo-1.6.js, etc. I don't know your setup exactly, but it is highly probable that the server sends back cache control headers saying that this file at this URL expires some time in the future. If the URL doesn't change, the browser won't even bother reloading. It is only if the path changes that you can be sure that the new version will be reloaded. -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
On 11.4.2011 23:47, George Sexton wrote:
I'm looking for ideas on how other people are doing versioning in Javascript
files. I'm hitting issues if I change my files in an incompatible way, or I
upgrade files.
For example, if I upgrade from DOJO 1.5 to DOJO 1.6, the user's browsers are
not always refreshing the DOJO files, and things don't work.
Similarly, if I update a javascript function to take additional arguments,
then the browser using the old version throws an error.
I've spent a lot of time in the past few days telling users to click on the
refresh button of their browser and I'm pretty sick of it.
I've thought of versioning my whole scripts directory. IOW, if my app
version is 3.4.9, make the scripts directory scripts-3.4.9 to force the
browser to get files from the new location. This is kind of a pain for
version control reasons but otherwise it's OK.
I'm really looking for ideas on how other web developers are handling this
problem.
For all static resources (css, images, js) you might add artificial
parameter that will trigger reload, like this:
href=some.css?v=${parameter}
Where 'parameter' might be:
1. Static resource last modification time. This will trigger reload
every time resource is changed.
2. Static resource hash, this will trigger reload every time static
resource is changed (except for the insignificant number of cases)
3. Application version (1.3.1, 1.3.2...). This will trigger reload every
time new version of application is released. This requires proper
release process, and triggers some extra reloads even when there is no
need for that.
4. Current system time. This will trigger reload of resource every time.
We use no. 3, since Maven packaging makes it really easy to implement
(${pom.version}}.
Regards,
Ognjen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
I've loathed this issue too. There are 2 major cases to deal with - Libraries changing (like dojo, prototype, etc) - Your external files changing The first is easy to change .. in that you create a /scripts/ dir and all 3rd party libraries go into their own directory with version number. New version - new directory (and hope the file names remain the same). Then *hopefully* you have a common include file that you just need to change once to point to the new directory. (Of course a global find/replace in this case is easy) The second is trickier. Relying on random query string is not fun since it may cause some browsers/proxies to be less prone to caching which can really affect performance. Especially if the the query string is dynamic. An easier solution is to use place your scripts is a special directory - then use a rewrite (or similar) rule to access them. So that the path is dynamic (and somewhat bogus). For example: /scripts/2011-04-11-072730/dojo.js - and in this case - you can have a rewrite rule look for a pattern and remove it from the path and forward to the script and let the default servlet handle things. Then to populate 2011-04-11-072730 - you can do that one of 3 ways: - At build time - calculate the timestamp and replace it - At run time - use a configuration parameter in context.xml - A combo of both - I like this one best since a build can trigger a new name, but sometimes you may run into situations where you don't need a build but you need it refreshed - so a server parameter tweak makes this easy too (and if savvy enough can be done via JMX to save a restart from occurring) Good luck ... -Tim On 4/11/2011 5:47 PM, George Sexton wrote: I'm looking for ideas on how other people are doing versioning in Javascript files. I'm hitting issues if I change my files in an incompatible way, or I upgrade files. For example, if I upgrade from DOJO 1.5 to DOJO 1.6, the user's browsers are not always refreshing the DOJO files, and things don't work. Similarly, if I update a javascript function to take additional arguments, then the browser using the old version throws an error. I've spent a lot of time in the past few days telling users to click on the refresh button of their browser and I'm pretty sick of it. I've thought of versioning my whole scripts directory. IOW, if my app version is 3.4.9, make the scripts directory scripts-3.4.9 to force the browser to get files from the new location. This is kind of a pain for version control reasons but otherwise it's OK. I'm really looking for ideas on how other web developers are handling this problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
On Tue, Apr 12, 2011 at 13:31, Tim Funk funk...@apache.org wrote: [...] The second is trickier. Relying on random query string is not fun since it may cause some browsers/proxies to be less prone to caching which can really affect performance. Especially if the the query string is dynamic. An easier solution is to use place your scripts is a special directory - then use a rewrite (or similar) rule to access them. So that the path is dynamic (and somewhat bogus). For example: /scripts/2011-04-11-072730/dojo.js - and in this case - you can have a rewrite rule look for a pattern and remove it from the path and forward to the script and let the default servlet handle things. Then to populate 2011-04-11-072730 - you can do that one of 3 ways: - At build time - calculate the timestamp and replace it - At run time - use a configuration parameter in context.xml - A combo of both - I like this one best since a build can trigger a new name, but sometimes you may run into situations where you don't need a build but you need it refreshed - so a server parameter tweak makes this easy too (and if savvy enough can be done via JMX to save a restart from occurring) No need... Just have the server part calculate an appropriate ETag for this case. It is no replacement for the first solution (which is, and always will be, the best one), but it allows the client to query the server with an If-None-Match header. Apache does this by default with a combination of mtime and inode number IIRC. I don't know, I never use ETags but only adapted Cache-Control directives. -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ognjen,
On 4/12/2011 5:37 AM, Ognjen Blagojevic wrote:
For all static resources (css, images, js) you might add artificial
parameter that will trigger reload, like this:
href=some.css?v=${parameter}
Some clients and proxies will refuse to cache resources with a query
string. In those cases, caching (obviously) won't work and there might
be a significant loss in performance of the web site.
Changing the path is safer and more effective.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2kXlcACgkQ9CaO5/Lv0PDWtACfQI42BqpvM+Lus3YKKOwWbjXe
SfcAnR3zITZa0muhZcQYj/NzO3qMa1eD
=zmBL
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 4/12/2011 7:31 AM, Tim Funk wrote: The second is trickier. Relying on random query string is not fun since it may cause some browsers/proxies to be less prone to caching which can really affect performance. Especially if the the query string is dynamic. An easier solution is to use place your scripts is a special directory - then use a rewrite (or similar) rule to access them. So that the path is dynamic (and somewhat bogus). For example: /scripts/2011-04-11-072730/dojo.js - and in this case - you can have a rewrite rule look for a pattern and remove it from the path and forward to the script and let the default servlet handle things. This is exactly what we've done in a particular case, mostly for testing: we have a service provider that handles IVR telephone calls and we have to provide the audio files for them to use via HTTP. They cache all audio files so, ideally, the file is only obtained from us once (at least once per server in the cluster, I suppose). Unfortunately, they don't have an automated way to EXPIRE a particular cache entry, so we invented a bogus path element that we can change to force a cache miss and a reload. Something like this: http://www.oursite.com/audio/version/1.wav We have mapped /audio/*/ mapped to /audio so the version is just a random string that gets ignored by the web server -- but it's important for clients so they can properly cache. Whenever we have to update an audio clip, we just change the version number in the URL and the new file gets used. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kXzsACgkQ9CaO5/Lv0PD/nACgjCDevK8RBSG+sHkUTC/dN1DE qFMAn13KseQKN5Qw0dLPDAKRedutYcz9 =sIHp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OT: Versioning in Javascript Files
Chris,
href=some.css?v=${parameter}
Some clients and proxies will refuse to cache resources with a query
string. In those cases, caching (obviously) won't work and there might
be a significant loss in performance of the web site.
Exactly. I tested on one usecase (no proxy, limited number of web
browsers), which is not representative. Now I see that it should not be
used as a general solution.
-Ognjen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: OT: Versioning in Javascript Files
Thanks to everyone that responded.
I'll make a few comments.
DOJO tends to make a million calls for images/scripts/css files. The ETag
solution isn't going to optimize well because there will still be a ton of 304
requests which all take time to make happen. Also, I'm not using Apache in
front of tomcat. I'm using Tomcat bare. Besides, let's face it. If the browser
were doing the right thing then they would pick up that the script file changed
using the last_modified header that tomcat presents. The problem is that the
browsers are just using the cached version rather than making an
if-modified-since request.
The .js?arg=someval option is a pretty reasonable idea. It offers the advantage
that I don't have to do hocus-pocus with my scripts path name. The problem I'm
seeing here though is that with something like the dojo library which makes its
own internal calls to load child javascript files it won't work. For example,
dojo loads the dijit files including dijit/_Dialog.js. There's no way to attach
the argument to the dojo request into the dijit directory. So, I think this is
a fragile solution.
My previous best plan was to rename my scripts directory to scripts-x.x.x. The
downside of the scripts-x.x.x is that when I upgrade my customers, I've got to
make the old scripts-x.x.x directory go away. I'll also have to do some hocus
pocus to make CVS, the version control system OK with it. Perhaps I can just
make scripts a symlink to scripts-x.x.x and keep it happy that way. The other
big problem I see is that if I make the dir name change on every build, then
even the tiniest of changes will force me to rename the directory. I run a
hosted application and this would have to be done across hundreds of
deployments.
The rewrite solution is OK. It solves the problems but adds another component
to my request cycle, and to my distribution load. On the other hand, it doesn't
have the icky problem of needing to rename the directory every time I push out
a trivial change. The other advantage I see is that using this, I can set
arbitrarily long expires headers on my responses so that the browser should
only request files when the program version changes. This is probably the
solution I should go with.
Again, thanks to everyone who responded.
George Sexton
MH Software, Inc.
303 438-9585
www.mhsoftware.com
-Original Message-
From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com]
Sent: Tuesday, April 12, 2011 1:06 PM
To: users@tomcat.apache.org
Subject: Re: OT: Versioning in Javascript Files
Chris,
href=some.css?v=${parameter}
Some clients and proxies will refuse to cache resources with a query
string. In those cases, caching (obviously) won't work and there
might
be a significant loss in performance of the web site.
Exactly. I tested on one usecase (no proxy, limited number of web
browsers), which is not representative. Now I see that it should not be
used as a general solution.
-Ognjen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
OT: Versioning in Javascript Files
I'm looking for ideas on how other people are doing versioning in Javascript files. I'm hitting issues if I change my files in an incompatible way, or I upgrade files. For example, if I upgrade from DOJO 1.5 to DOJO 1.6, the user's browsers are not always refreshing the DOJO files, and things don't work. Similarly, if I update a javascript function to take additional arguments, then the browser using the old version throws an error. I've spent a lot of time in the past few days telling users to click on the refresh button of their browser and I'm pretty sick of it. I've thought of versioning my whole scripts directory. IOW, if my app version is 3.4.9, make the scripts directory scripts-3.4.9 to force the browser to get files from the new location. This is kind of a pain for version control reasons but otherwise it's OK. I'm really looking for ideas on how other web developers are handling this problem. -- George Sexton MH Software, Inc. 303 438-9585 www.mhsoftware.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
