djConfig support for dojo.require url versioning

[guest]

When a new verion of dojo is required, it is wise to force a client to retrieve the new javascript from the server, bypassing the client side cache. To this end, it would useful to have a setting in djConfig (e.g. djConfig.version) such that all dojo.require statements would append this value to each request:

djConfig = { .. version=1.23 .. }

=>

"../dojo/event.js?1.23"

[jburke]

It seems like this could be accomplished just by putting the new version of Dojo in a new directory, and have the dojo.js URL point to that directory. You can also use djConfig.modulePaths { "dojo": "/path/to/1.23/dojo" } or dojo.registerModulePath("dojo", "/path/to/1.23/dojo"); to force an update of the files.

Why would that not be an acceptable solution?

[jburke]

And if you did not want to use another physical directory on the server, use mod_rewrite on the server to map the "/path/to/1.23/dojo" to the path you want.

[guest]

Sometimes physically changing the directory is not possible. For instance, Struts2 packages a dojo distribution in a jar file. In this case, it is not possible to change the physical path.

Secondly, using mod_rewrite assumes apache which may or may not be present in the target environment. Even if url rewriting is supported, this may be a poor choice simply because it hinders web application encapsulation.

One advantage the proposed solution has is that one could apply this versioning technique independent of a dojo distribution. For example, say if there are new versions of custom application modules, and the dojo distribution hasn't changed, but any cached javascript from previous dojo.require('custom.application.module') should be cleared. This would make it possible to change application module versions without changing a physical directory -> goodness :)

[jburke]

It still seems that even if Dojo was in a JAR file is delivered by Struts2, it would not be changing (it is effectively just a lib you use), so forcing a refetch does not seem to be needed in that case. If the Dojo JAR contents actually change, it seems like you should be able to change how it is packaged.

But I am speaking from a position of ignorance on Struts2. I'm just having a hard time using a querystring parameter when the Dojo files are static resources. If you want a different version of a resource, it should be on a different URL path. And I do not see querystring params as a valid part of the path. I'm seeing it in a more RESTful perspective where the querstring params may filter info on a resource, but are not used to point to a fundamentally different resource.

But I know not everything operates like this. Alex accepted the ticket, so he'll get to decide on it, but I'm initially skeptical on adding additional code to the loader for this. It may not be a lot of code, but all of these types of feature requests add up.

If the feature is added, it sounds like you want to be able to version specific module prefixes, not just apply a generic version number to all modules. In that case, the version thing should probably be part of specifying djConfig.modulePaths and when calling dojo.registerModulePath().

[bill]

Move all milestone 1.1 tickets to 1.2, except for reopened tickets and tickets opened after 1.1RC1 was released.

[dylan]

Marking as future and anonymous... we'd be interested in a patch for this if there's interest.