tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Gusev <dmitry.gu...@gmail.com>
Subject Re: Coming soon: per-Asset checkums in URLs
Date Tue, 12 Mar 2013 12:37:00 GMT
On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hlship@gmail.com>wrote:

> I've been working, a few hours a week, on getting per-asset checksums into
> URLs.
> 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.
It depends on where you put the checksum.
If you put it as a GET parameter - then no relative URLs will be broken.

Have you read my blog post about Tapestry5 checksums in assets?

> 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
> JavaScript.
> 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
> http://howardlewisship.com

Dmitry Gusev

AnjLab Team

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