[Deploying Sakai] OAE UI Caching

[Steve Swinsburg]

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.

Regards
Steve

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.
>> 
>> ]
>> 
>> resource-aggregator:
>> 
>> https://source.jasig.org/sandbox/resource-aggregator/
> 
> 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 ?
> Ian
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> 
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"