Pelletier Vincent
2007-01-10 10:05:48 UTC
Hi.
I commited a cache I wrote for skin tool.
This cache should be completely transparent : apart from cache populating
which costs some time, cache updates are handled and no manual invalidation
is required. Its use is implicit an no code need to be changed to use it.
Cache populating is done in 3 cases
- site startup (once per thread)
- skin selection change (portal_skins/manage_propertiesForm)
- when portal_skins object is modified
I've been the only user of this cache yet, so it can contain bugs I didn't
trigger. If you suspect this cache causes problems on your site or if you
want to disable it for a reason or another, you just have to comment out the
following lines in ERP5Type/ZopePatch.py and restart your zope.
from Products.ERP5Type.patches import CMFCoreSkinnable
from Products.ERP5Type.patches import CMFCoreSkinsTool
from Products.ERP5Type.patches import OFSFolder
Cache internals
It's not required to know how this cache operates since it's completely
transparent. Though, as there might be bugs, this description might help
finding if the bug comes from the caching system or not.
Caching is done in a volatile dictionary of dictionaries.
Outermost dictionary keys are Skin Selection Names (View, Print, CSV, ...),
innermost dictionary keys are existing object ids, and the value is the id of
their container.
OFS Folder class is patched so that when an object is attached to a Folder
object *and* this Folder is right below portal_skins tool the cache gets
updated.
As the cache is stored in a volatile property of skin tool, it's lost each
time skin tool is modified (adding a subobject, ...) or reloaded from ZODB
(another node in a zeo setup updated the object, ...).
I commited a cache I wrote for skin tool.
This cache should be completely transparent : apart from cache populating
which costs some time, cache updates are handled and no manual invalidation
is required. Its use is implicit an no code need to be changed to use it.
Cache populating is done in 3 cases
- site startup (once per thread)
- skin selection change (portal_skins/manage_propertiesForm)
- when portal_skins object is modified
I've been the only user of this cache yet, so it can contain bugs I didn't
trigger. If you suspect this cache causes problems on your site or if you
want to disable it for a reason or another, you just have to comment out the
following lines in ERP5Type/ZopePatch.py and restart your zope.
from Products.ERP5Type.patches import CMFCoreSkinnable
from Products.ERP5Type.patches import CMFCoreSkinsTool
from Products.ERP5Type.patches import OFSFolder
Cache internals
It's not required to know how this cache operates since it's completely
transparent. Though, as there might be bugs, this description might help
finding if the bug comes from the caching system or not.
Caching is done in a volatile dictionary of dictionaries.
Outermost dictionary keys are Skin Selection Names (View, Print, CSV, ...),
innermost dictionary keys are existing object ids, and the value is the id of
their container.
OFS Folder class is patched so that when an object is attached to a Folder
object *and* this Folder is right below portal_skins tool the cache gets
updated.
As the cache is stored in a volatile property of skin tool, it's lost each
time skin tool is modified (adding a subobject, ...) or reloaded from ZODB
(another node in a zeo setup updated the object, ...).
--
Vincent Pelletier
Vincent Pelletier