[Deploying Sakai] OAE UI Caching
ianboston at gmail.com
Tue Aug 23 02:47:40 PDT 2011
Applogies for replying to a Digest, this might not thread correctly:
Andrew Petro <apetro at unicon.net> wrote:
> And here I'll just quote Jen verbatim:
> As part of the uPortal build process, we ask maven to take a bunch of js/css resources, > aggregate them all together, minify them, and stick a hash code in the name. That minified, aggregated version gets long-term cache headers applied, but we also deploy all the original source files. The code that includes all the js/css in the page looks for a JVM > flag that indicates whether the aggregated/minified/cached version or the original versions should be used, so that we don't completely crush the souls of all the UX devs.
> There's a lot of really terrific code in that section of the project (resource-aggregator in the Jasig sandbox) and it'll eventually be a good resource for any servlet-based project (not just portlets). Unfortunately the key piece that includes the resources in the page is still XSLT-specific, so this isn't yet technology that can be adopted by not-uPortal projects without having to write some custom code. We definitely intend to write a JSP tag for this tech so that we can use it from portlets though, at which point it'd be more generally adoptable.
OAE does something very simular with requireJS on the compress, minify etc.
Its done as part of the build (maven->ant) and optimises the core JS
and CSS into 2 files iirc.
The bit it doesnt do is put a hash in the name. I was working on a
patch for that but was having problems getting jQuery to load from the
minified, and hashed core js bundle.
IMHO putting a hash in the filename based on a sha1 or md5 of the
contents of the file is the best solution since it avoids all the
problems associated with agressive browsers and broken intermediate
caches. The remaining question for OAE is, should there is a dynamic
intermediate JS loader in a JS file that has the hash hard coded, or
should all the HTML files be processed at build time to reference the
hashed files directly? The latter will avoid 1 network round trip.
Presumably, the uPortal solution re-writes the HTML rather than having
a dynamic client side JS loader ?
More information about the production