[Deploying Sakai] OAE UI Caching
steve.swinsburg at gmail.com
Tue Aug 23 04:12:46 PDT 2011
I would suggest that the HTML files have a placeholder in them that is set with the value of the hashed JS library at build time.
Sent from my iPhone
On 23/08/2011, at 19:47, Ian Boston <ianboston at gmail.com> wrote:
> 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 ?
> production mailing list
> production at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
More information about the production