On Mon, Apr 25, 2005 at 03:19:42PM -0300, Leonardo Rochael Almeida wrote:
Sorry for comming late into the fray :-) (snip) This alternative won't help you when:
* the pythonscript is sensitive to the context AND
* it is called w/ 2 or more different contexts on the same request
An artificial example I can come up w/ from the top of my head: Suppose you have a folder w/ an index_html that displays information about it's subfolders that is calculated by an expensive script and you want to cache the results of this script, you'd go:
<ul> <li tal:repeat="subfolder python: here.objectValues('Folder')"> Folder <span tal:content="subfolder/title_or_id"> contains <span tal:content="subfolder/expensively_calculate_shruberries"> shruberries. </li> </ul>
Then you'd go and RAMCache "expensively_calculate_shruberries"
But if we implement the change you're suggesting, then this page would list the same number of shruberries of the first subfolder for all of them.
-1 from me
OK, and now that you've said all that, -1 from me as well; I think the idiom you describe is very common. That's why I like to discuss things on the list before filing collector items :-) I kinda wish the RAMCache manager allowed other things than REQUEST variables for differentiation. Arbitrary TALES expressions would be nice. Then we could get rid of this hard-coded gunk and get the same effect by having context/getPhysicalPath as one of the expressions. But of course then you'd have the opportunity to kill your cache performance by making the expressions too expensive. Ah well, TANSTAAFL and all that. I'll probably just drop the idea.
For a related annoyance, see: http://www.zope.org/Collectors/CMF/343
This annoyance is indeed related, but the proper fix is for FSPythonScript to have a ZCacheable_manage page that takes into account the fact that it's usually part of a portal_skins setup and deal with it. Alternativelly, portal_skins should provide the functionality of expiring RAMCached subitems.
Of those, I'd prefer the latter approach. Added this as a comment to #343. Thanks for the valuable input! -- Paul Winkler http://www.slinkp.com