jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: [PROPOSAL] Cache Taglib
Date Wed, 03 Apr 2002 02:11:09 GMT
+1

Shawn Bayern wrote:
> 
> 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:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

--
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