I have a page that is a mashup of two internal web services - one that
serves organization structure, and another that serves IM presence
indicators - to produce a team listing for each of the groups that own
the content of one of our XWiki instances. Because queries to the first
are costly and their content is updated infrequently, a caching
mechanism is indicated.
I see two ways of doing this: one is to manipulate the URL object for
the outgoing request to provide for normal HTTP caching disciplines.
I'd prefer to do it this way, but haven't a clue at the moment of how to
do it, since it's inside org.dom4j.io.SAXReader, to whose read(String)
method I pass a URL.
Another way that I'd like to investigate in parallel is simply to use
XWiki's caching mechanism to cache the parsed org.dom4j.Document objects
that are returned. Establishing a new cache with a Velocity script
seems straightforward (though of course it requires programming rights):
#set($myCache = $xwiki.xWiki.cacheService.newCache())
$mycache.put("name", $myObject)
$myCache.get("name")
... etc...
but it suffers from two problems: first, it's only in the context of
the request, making it useless; second, there's no way to manage the
freshness exception thrown from the get methods. So apparently a plugin
is indicated; ideally, one that: could be used for any purpose; provided
simple means of specifying cache parameters, such as the freshness rules
and the operation required to refresh the cache.
I think that the best way to use it would look something like:
#set($myCache = $xwiki.myCachePlugin)
$myCache.setParameters(...)
$myCache.cached('$velocityCode') ## should pass the Context, or is
that part of the plugin API?
The method would use the unrendered Velocity code as the key to the
cache, look first in the cache and return it, rendering the code and
caching its result first if the value was not fresh.
In describing this, I'm thinking that the DefaultPlugin actually
provides for a lot of this.
Thoughts, anyone?
brain[sic]