jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjørn Bouet Smith <...@bsw.dk>
Subject Re: [PROPOSAL] Cache Taglib
Date Tue, 02 Apr 2002 22:58:51 GMT
Hi there,

I have experimented in making my own cache taglib, much simpler than the one
that you have described, but with an option to make object expire by time or
never expire. No awareness at all regarding the container's sessions,
application what so ever.

just simple caching of the body contents of the tag. ie something like:

<cache:cache cacheName="topPage" maxAge="1" cacheCapacity="100"

Where the attributes works as below:

cacheName = Id of cached item
maxAge=Minutes to expiry
cacheCapacity=number of items in the cache before the oldest is thrown away
debug=print information regarding time to fetch from cache.

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.

Either way, I would love to see a caching taglig in the jakarta taglibs.

Keep up the good work.

Bjørn Bouet Smith

----- Original Message -----
From: "Shawn Bayern" <bayern@essentially.net>
To: <taglibs-dev@jakarta.apache.org>
Sent: Wednesday, April 03, 2002 12:43 AM
Subject: [PROPOSAL] Cache Taglib

> So, even though I seen any response yet to the Cache Taglib currently in
> the sandbox, I figured I'd call a vote to add it to the main CVS archive
> and inform the 'taglibs-user' list that it's there.
> +1 for adding the Cache Taglib.
> Shawn
> ---------- Forwarded message ----------
> Date: Sun, 31 Mar 2002 22:53:48 -0500 (EST)
> From: Shawn Bayern <bayern@essentially.net>
> To: taglibs-dev@jakarta.apache.org
> Subject: Cache Taglib
> To encourage experimentation with using JSP taglibs to cache page
> fragments, I've checked in a new taglib offering into the Jakarta Taglibs
> sandbox.  I'll call a vote to add it to the main CVS archive in a few
> days, after we've had some time to play with it.  Broadly speaking, I'm
> trying to encourage experimentation for a few reasons:
>  - to see how useful this functionality really is
>  - to refine the syntax and features
> This might be useful in case we want to explore adding caching support in
> JSTL 1.1.
> The "Cache Taglib" in the sandbox currently has two tags:  one to cache
> content and one to explicitly invalidate a cache entry.  (There are also a
> number of utility functions exposed to allow back-end developers to modify
> cache properties, such as the cache size and the lifetime of cache
> entries.  Back-end developers can also seed values into the cache and
> explicitly invalidate entries themselves.)
> The current tags support a two-tier model:  a cache functions like a Map,
> in that it stores keyed values.  (The two tiers are thus "cache name" and
> "key.")  An application may use an unlimited number of different caches,
> each with different properties, including
>   - scope
>   - size
>   - element lifetime
> To create or use a cache, use the <cache:cache> tag:
>   <cache:cache scope="session" name="birthdays" key="${user.mother}">
>     <expensiveLookup:birthday ... />
>   </cache:cache>
> This tag caches the user's mother's birthday under the key ${user.mother}
> in a session-wide cache with the default lifetime and cache size.  In
> general, the entire body is cached, minus leading and trailing whitespace.
> (Oh, by the way, note the use of the expression language.  This taglib
> might be a good example for those wishing to incorporate the EL into their
> own tags.)
> The configurable scoping lets you cache values across various pages.  (By
> default, the scope is "application.")  You can't cache anything beyond the
> entire application, however.  To remove a cache entry, you can use
> <cache:invalidate>, which destroys either a whole cache (by name) or an
> individual item (by key).
> Though the current "Cache Taglib" is usable as-is, I've tried to keep the
> usage and implementation relatively simple for now.  Ideas for future
> improvements could include -
>   - multiple tiers with scoping "invalidation" behavior (e.g.,
>     "invalidate all subkeys for key, but leave the rest of the keys
>     intact").  This might be useful for values that change but have
>     various modes of display -- e.g.,
>        name="birthdays" key="${user.mother}" subKey="${verbose}"
>   - per-key lifetime (currently per-cache)
>   - dynamic adjustment of cache properties (current fixed at
>     creation-time)
>   - tags to modify the default cache size (after debating this
>     with myself, I decided it's better currently to require code)
>   - explicit cache exclusion for fragments within fragments -- e.g.,
>      <cache:cache>
>          ...
>          ...
>          <cache:noCache>
>             ...
>          </cache:noCache>
>          ...
>          ...
>      </cache:cache>
> I've posted documentation at
>   http://www.essentially.net/cache
> so that you can easily view the info without having to download build the
> taglib.
> I'm curious what you guys think.  The current design is generally in the
> spirit of JSTL, in that my overall goal was to keep usage simple for the
> page author.  Would page authors that you know be able to use it?
> Thanks,
> Shawn
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message