Comment 9 for bug 100620

OK, I've implemented caching support for Silva (using Zope Cache Managers)
There is an accelerated http cache manager added on silva install (or refresh),
called service_asset_cache_manager. This caching policy can be set per
container (and inherited by objects within that container), or set by
Silva objects implementing caching support (currently files and images). The
policies are set in the properties tab.

Since not all Silva objects implement caching support, I've created a new
metadata set "silva-caching", with one field "cache_manager". This set is
now mapped to Folder, Root, Publication, File and Image. I created a cacheable
mixin class that SilvaObject now extends from, which extends from Cacheable and
contains two helper methods:
validate_cache_manager: This needs to be called before the cache manager
 is resolved when rendering the content, so that the setting from the metadata
 can be applied. Changes the cache_manager property ARE NOT applied until
 this method is called!
get_cache_managers:
 This method returns the values for the cache_manager property.

I would have preferred not extending SilvaObject with another mixing class,
especially when not all SilvaObjects take advantage of this. Here are some
reasons why this was necessary:
1) In order to specify container policies, containers need to have the
   silva-caching metadata set. This set _needs_ a helper method in order
   to populate the fields. Adding this method to a mixin and using it
   to extend the base SilvaObject provides this functionality TO ALL containers
   without having to alter the definitions for each container
2) Putting this support in SilvaObject provides a path for any Silva object
   to easily support caching...
Had this not been used to extend SilvaObject, each class that is either a
container which could contain cacheable objects, or an object supporting caching
would need to extend this mixin class.

So, how to use:
1) You can specify a cache manager for a container, and this policy
   is then acquired / inherited by all contained objects
2) For an object supporting caching (i.e. one having the silva-caching
   metadata set): if no manager is set for the object, it inherits the
   manager setting from the conainer. It can specify not to use
   caching, or it can specify it's own cache
3) Since the cache manager is inherited, you can "override" a policy
   for a cache manager for a container by adding a cache manager with
   the same id in that container.
   E.g. The default "file and image cm" is added in the Silva root with
   id "service_asset_cache_manager". You could set this cm in the Silva root,
   so it is acquired by all objects implementing caching. In a sub-folder,
   if you want a different cache manager, or a different settings, you can
   add a cache manager with the same id, and objects within that container
   will use this nearer cache manager.

Eric: I tested the silva export, and it does not lookup the cache managers
      during the export, so this is no longer a 'con'

Also: there was mention in this issue about allowing only Editor+ to change
the cache policy. I believe this could be handled using SilvaMetadata write
guards, but it doesn't appear that this has been fully implemented in Silva?
If I try to set a write guard in the SMI, I get a 404 error because the
python method that is called doesn't have a docstring. If I add a docstring,
it still doesn't appear to work.

So, please evaluate, and let me know if this can be merged in with the Silva
trunk.