jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Bayern <bay...@essentially.net>
Subject Re: [PROPOSAL] Cache Taglib
Date Wed, 03 Apr 2002 15:08:34 GMT
On Wed, 3 Apr 2002, Bjørn Bouet Smith wrote:

> Im thinking about making the cache query string aware, such as it will
> be possible to make the cache only retrieve contents from the cache if
> the query string matches with the one in the cache, otherwise it
> should evaluate the body and add another cache element.
> 
> The same about session awareness, define a couple of variables that the
> cache should check, i.e.:
> <cache:cache cacheName="topPage" maxAge="1" cacheCapacity="100"
> scope="session" evalute="searchstring,searchscope">
> 
> Where the cache would get the session variables searchstring and scope
> and check for equality with the one in the cache, and so forth. I
> think it would be useful.

Yeah, we're thinking about the solution very similarly.  The taglib that
I've proposed accommodates this by letting the user 'factor out' whatever
dynamic nature a fragment has into a single 'key', which can be
constructed using JSTL's expression language.  If the fragment depends
only on the query string, for instance, then you'd write

  key="${params}"

If it depends on particular variables in the session, you could write

  key="${session.searchString}.${session.searchScope}"

That is, it's easy to construct a compound "unique identifier" string
using JSTL's EL.

The Cache Taglib doesn't currently have 'maxAge' and 'cacheCapacity'
attributes for the tag itself, primarily because I thought it would be
best to hide details like that from the page author.  It supports
configurable cache capacities and expiration times through the use of
back-end scoped variables (and fallback to a default).  The other reason
that I figured it was best not to expose these properties as attribute was
that it might lead to misleading behavior; the cache size and expiration
time are determined when the cache is created, so if different tag
invocations had attributes that "disagreed," the user might get confused.

> Either way, I would love to see a caching taglig in the jakarta taglibs.
> 
> Keep up the good work.

Thanks!  It's posted to the site today, although I think my build.xml
script must have had an error somewhere, since the documentation didn't
build.

Shawn


--
To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message