You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Shawn Bayern <ba...@essentially.net> on 2002/04/03 00:43:15 UTC
[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 <ba...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by Shawn Bayern <ba...@essentially.net>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by Bjørn Bouet Smith <bb...@bsw.dk>.
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"
debug="true">
</cache:cache>
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
BSW
http://www.bsw.dk
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
----- Original Message -----
From: "Shawn Bayern" <ba...@essentially.net>
To: <ta...@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 <ba...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by Justyna Horwat <Ju...@Sun.com>.
+1
Justy
----- Original Message -----
From: "Shawn Bayern" <ba...@essentially.net>
To: <ta...@jakarta.apache.org>
Sent: Tuesday, April 02, 2002 2:43 PM
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by po...@lokitech.com.
Hi. This is the James mail server at beethoven.lokitech.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
mpangaro@liszt.lokitech.com
Could not connect to SMTP host: liszt.lokitech.com, port: 25
The original message is attached.
Re: [PROPOSAL] Cache Taglib
Posted by Pierre Delisle <pi...@sun.com>.
+1
-- Pierre
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 <ba...@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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by Shawn Bayern <ba...@essentially.net>.
Okay, I've added the Cache Taglib to CVS. Once it propagates to the site,
I'll send an introductory message to taglibs-user.
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Cache Taglib
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
+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 <ba...@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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>