[Deploying Sakai] OAE UI Caching

[Ian Boston]

Yes, agreed, except the UI devs don't build.

They edit, save, refresh.
A placeholder like /dev/ as in /dev/lib/jsfileA.js  is ok but one like
/dev/lib/jsfileA{sha1code}.js is going to prevent them from working.

I am thinking that I might be able to replace critical /dev/**
references in HTML with /dev-sha1code/** where sha1code is unique to
the build.
I havent tested yet so have no idea what this might break in OAE.
Ian

On 23 August 2011 12:12, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 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"
>