Greenscript does not respect the staticDir:public route mapping

[tazmaniax]

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]

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 <
[email protected]

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:
#36

[tazmaniax]

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]

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 <
[email protected]

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:
#36 (comment)

[tazmaniax]

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]

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 <
[email protected]

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:
#36 (comment)

[tazmaniax]

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]

Fair enough. Let me think it twice.

On Wed, Feb 15, 2012 at 10:19 PM, tazmaniax <
[email protected]

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:
#36 (comment)

[tazmaniax]

Cool. The change I've made, #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.