You'll have to be mindful of your own cache too of course but depending on your deployment, you might also want to use the cajolers own jobcache which caches interim stages of output. For example, if you cajole foo.html which in turn pulls jquery as a script, it can cache the cajoled jquery so the next time some other page bar.html pulls jquery, jquery itself doesn't need to be recajoled. This can save some work but also adds some complexity to your project so it might be worth only pursuing once you're done building and are tuning.
For the cache, you need two things: a cache key and a cache implementation for your infrastructure. A good cache key might be the hash of the content or perhaps just the url or both. The cache implementation is handed a key and a List<? extends Job> to store which are serializable so you can store to taste in memcache or disk etc. A good example to follow might be: http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/demos/playground/server/AppEngineJobCache.java http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/demos/playground/server/AppEngineJobCacheKey.java On Fri, Jul 6, 2012 at 11:52 AM, Doug Koellmer <[email protected]> wrote: > Yea it's a use instance I saw. I first googled how to to turn a w3c Node > object into a String, and found some answers, but it was a pain getting > them to work...but then I figured you guys had to have done it somewhere in > the project. > > By caja cache you just mean whatever caching I'm doing myself right? Just > making sure that there's nothing in the caja library itself I should be > aware of. > > Thanks, he's in daycare now...have some precious hours alone to work :) >
