search

greenlaw110 / greenscript

A tool help web developers manage javascript/css rendering, including minimize and dependence management
42 stars 24 forks source link

Greenscript does not respect the staticDir:public route mapping #36

Open tazmaniax opened 12 years ago

tazmaniax commented 12 years ago

The following discussion suggests a mechanism to avoid browser cached resources when deploying a new application version: https://groups.google.com/d/msg/play-framework/1saij-OP1go/CcuN2VxxD4YJ

This mechanism involves inserting a version number contained in a local file into the external prefix for static 'public' resources, e.g.: GET /public/%{out.write(play.getVirtualFile(".version").contentAsString())}%/ staticDir:public

Greenscript does not take this sort of mapping into account when returning URLs for managed resources.

greenlaw110 commented 12 years ago

I think this is to avoid browser to cache js/css file, while greenscript encourage browser to cache them. Maybe I can add support to versioned resource in dev mode. But I don't think this is really needed from greenscript's perspective. The power of GreenScript is not only compressing and minimizing, but also dependency management. And this feature is built on the basis that your resource files are loaded directly with pages, not via ajax call. Meaning you use greenscript in case you have all html/js/css code loaded along with page refresh. In that case I don't think we need versioned resource at all. Because you can press ctrl-f5 to force browser to reload all resource files. And ctrl-f5 only fails when you load resource files in ajax call, in which case the dependency management is done via javascript libraries like LAB.js, instead of greenscript.

On Wed, Feb 15, 2012 at 10:37 AM, tazmaniax < reply@reply.github.com

wrote:

The following discussion suggests a mechanism to avoid browser cached resources when deploying a new application version: https://groups.google.com/d/msg/play-framework/1saij-OP1go/CcuN2VxxD4YJ

This mechanism involves inserting a version number contained in a local file into the external prefix for static 'public' resources, e.g.: GET /public/%{out.write(play.getVirtualFile(".version").contentAsString())}%/ staticDir:public

Greenscript does not take this sort of mapping into account when returning URLs for managed resources.

Reply to this email directly or view it on GitHub: https://github.com/greenlaw110/greenscript/issues/36

tazmaniax commented 12 years ago

The idea is to only avoid browser caching if there is modified static content with a new release in which case everything should be reloaded. Maybe I should have done some more testing in production mode but my assumption was that the generated minimised files would have the same file name across new releases as they are generated based on the collection of minised file names contained and therefore another mechanism was needed to ensure modified static resources were guaranteed to be picked up on new version release.

greenlaw110 commented 12 years ago

I am a bit confused. So to load modified static content you just need to press ctrl-f5 to reload, isn't ?

On Wed, Feb 15, 2012 at 11:14 AM, tazmaniax < reply@reply.github.com

wrote:

The idea is to only avoid browser caching if there is modified static content with a new release in which case everything should be reloaded. Maybe I should have done some more testing in production mode but my assumption was that the generated minimised files would have the same file name across new releases as they are generated based on the collection of minised file names contained and therefore another mechanism was needed to ensure modified static resources were guaranteed to be picked up on new version release.

Reply to this email directly or view it on GitHub: https://github.com/greenlaw110/greenscript/issues/36#issuecomment-3972607

tazmaniax commented 12 years ago

Probably but when does an 'end user' know to do that? They might not even see the problem. On Mac ctrl-f5 doesn't exists and I don't know what the equivalent is. Not something I would want to rely on. If the client static content needs to be in sync with the server then it should be refreshed when the server is updated outside of the end user involvement, no? This change is only to handle application upgrades that affect content cached on the client.

greenlaw110 commented 12 years ago

Well, if you are talking about the product environment, then what you need is to RELEASE an new version of your javascript, like from jquery-1.4.2 to jquery-1.7.1, these kind of things need to be managed by process, not by a tool. What I was talking about is only on development environment and from developer's perspective.

On Wed, Feb 15, 2012 at 9:39 PM, tazmaniax < reply@reply.github.com

wrote:

Probably but when does an 'end user' know to do that? They might not even see the problem. On Mac ctrl-f5 doesn't exists and I don't know what the equivalent is. Not something I would want to rely on. If the client static content needs to be in sync with the server then it should be refreshed when the server is updated outside of the end user involvement, no? This change is only to handle application upgrades that affect content cached on the client.

Reply to this email directly or view it on GitHub: https://github.com/greenlaw110/greenscript/issues/36#issuecomment-3978166

tazmaniax commented 12 years ago

ok but then you really need to be consistent and apply versioning to every static resource including graphics and css. Clearly including a version as part of every static resource file name would be a much better fine grain solution then what I've suggested but then that doesn't play easily with SCMs etc - maybe GIT is better suited then most. This general URL mapping mechanism is applicable where there is no per resource versioning already in place, and the effort to introduce and manage such a mechanism is currently a barrier, which is in my case :) I'm looking at the static URL mapping as a quick win, accepting the fact that when the version is incremented clients are forced to download all resources again. A matter of tradeoffs.

greenlaw110 commented 12 years ago

Fair enough. Let me think it twice.

On Wed, Feb 15, 2012 at 10:19 PM, tazmaniax < reply@reply.github.com

wrote:

ok but then you really need to be consistent and apply versioning to every static resource including graphics and css. Clearly including a version as part of every static resource file name would be a much better fine grain solution then what I've suggested but then that doesn't play easily with SCMs etc - maybe GIT is better suited then most. This general URL mapping mechanism is applicable where there is no per resource versioning already in place, and the effort to introduce and manage such a mechanism is currently a barrier, which is in my case :) I'm looking at the static URL mapping as a quick win, accepting the fact that when the version is incremented clients are forced to download all resources again. A matter of tradeoffs.

Reply to this email directly or view it on GitHub: https://github.com/greenlaw110/greenscript/issues/36#issuecomment-3978645

tazmaniax commented 12 years ago

Cool. The change I've made, https://github.com/greenlaw110/greenscript/pull/37, seems to be working well and I've tested it on my Heroku cluster. I've added a configurable parameter to completely disable integration with the play Router.