Which Plone caches land where#
A stock Plone 6.2 has ten functions decorated with plone.memoize.ram, plus the RAM page cache of plone.app.caching.
The test suite scans the installed Plone for them, so a release that adds, removes, or renames one fails a test and this table gets updated.
The Evidence column says how each route is known. Tested means a test calls the real function on a Plone site and checks where the value went. Return type means the route follows from what the function returns, read from its source, without a test that drives it.
Function |
Returns |
Route |
Evidence |
|---|---|---|---|
|
status, headers, body, and a flag |
|
Tested |
|
a dictionary of translations |
|
Tested |
|
the sitemap compressed with gzip, as bytes |
|
Tested |
|
dictionaries of strings |
|
Tested |
|
name and plugin pairs |
|
Tested, both cases |
|
event accessor objects |
|
Return type |
|
HTML, as a string |
|
Return type |
|
a list of dictionaries of strings |
|
Return type |
|
HTML, as a string |
|
Return type |
|
an image tag, as a string |
|
Return type |
|
never cached |
none |
Source |
Two rows deserve a comment.
getPlugins returns the registered theme plugins as (name, plugin) pairs.
A stock Plone registers none, so the list is empty, which is plain data, and it is shared.
As soon as an add-on registers a theme plugin, the list holds a utility, the function is routed to RAM, and the log names the plugin's class.
Both cases are tested.
The recent items portlet calls ram.cache(...) on a line of its own instead of using it as a decorator, so its render method is never cached, in stock Plone or with this package.