tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Coming soon: per-Asset checkums in URLs
Date Mon, 11 Mar 2013 20:35:11 GMT
I've been working, a few hours a week, on getting per-asset checksums into

Some parts of this have been a challenge to accomplish without completely
breaking the Asset interface and a bunch of public services.

For ordinary assets, it's pretty easy ... but for aggregated JavaScript
libraries its been a pain that's affected a bunch of stuff.

CSS files are now rewritten, since relative URLs will be broken by the
addition of the checksum. I have a first (but not final) pass at this,
where url() patterns in the CSS are converted into complete paths. This
also opens the door to CSS aggregation as well as JavaScript aggregation.

I still don't have a great solution for JavaScript modules; RequireJS/AMD
expect that there's a common root folder name (such as "/assets/modules/"),
and module "a/b" is simply "*root*/a/b.js". For individual modules, you can
write your own overrides.  In fact, Tapestry has to strip off the ".js'
part (which is hard-wired by RequireJS) because the actual server-side
resource could be CoffeeScript or some other language that compiles to

Short of iterating all server-side module files and writing a RequireJS
config for each one (mapping each name to a URL with an embedded checksum),
there isn't a great solution.  Alternately, something could iterate all the
server-side modules and built a composite checksum, but there are at least
a couple of virtual modules generated at runtime (and locale specific for
extra kicks).

Modules may have to stay on the 5.3 approach: using the application version
number for everything.

Finding the sweet spot where assets of all kinds (CSS, JavaScript
libraries, JavaScript modules, etc.) can be changed freely and the URLs
automatically reflect the actual content (that is, include a checksum of
that content) for ideal client-side caching ... may simply be out of reach.

Perhaps for modules we should use an alternate approach based on ETags (
http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not
need to be any version number of checksum in a module URL, but clients
would request the module content more often (and based on ETag, would often
get a 304 Not Modified).  I would prefer to see a URL that changes when the
content changes (which prevents the request entirely).

Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message