Opened 12 years ago

Closed 10 years ago

#4328 closed enhancement (wontfix)

djConfig support for dojo.require url versioning

Reported by: guest Owned by: anonymous
Priority: high Milestone: future
Component: General Version: 0.9
Keywords: Cc: James Burke, dante
Blocked By: Blocking:

Description (last modified by dylan)

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"

Change History (10)

comment:1 Changed 12 years ago by alex

Milestone: 1.0
Owner: changed from anonymous to alex
Status: newassigned

comment:2 Changed 12 years ago by James Burke

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?

comment:3 Changed 12 years ago by James Burke

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.

comment:4 Changed 12 years ago by 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 :)

comment:5 Changed 12 years ago by James Burke

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().

comment:6 Changed 11 years ago by bill

Milestone: 1.11.2

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

comment:7 Changed 11 years ago by dylan

Description: modified (diff)
Milestone: 1.2future
Owner: changed from alex to anonymous
Status: assignednew

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

comment:8 Changed 10 years ago by dante

Cc: jbruke dante added

isn't this djConfig = { cacheBust:"1.2.3" } ?

want to mark invalid/wontfix.

comment:9 Changed 10 years ago by dante

Cc: James Burke added; jbruke removed

comment:10 Changed 10 years ago by James Burke

Resolution: wontfix
Status: newclosed

I agree, using querystring params defeats caching, and if you really want it djConfig.cacheBust can be used.

Note: See TracTickets for help on using tickets.