[Zope-dev] RAMcache and container vs. context

[Leonardo Rochael Almeida]

Sorry for comming late into the fray :-)

Em Qui, 2005-04-21 às 19:46 -0400, Paul Winkler escreveu:
> On Fri, Apr 22, 2005 at 12:27:18AM +0200, Stefan H. Holek wrote:
> > Note that aq_parent() gives you the URL parent, not the container. I 
> > see no way around that as the return value of a script may well depend 
> > on its context.
> 
> Yes, it may, agreed. Thanks much for pointing out the relevant
> code, at least now I understand what's happening.
> 
> But I still would like to argue against this behavior:
> There *is* an easy alternative, and that's to put one or more
> of the many location-related request variables into the
> cache manager's configuration.

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

> 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.

-- 
Leonardo Rochael Almeida <leo at hiper.com.br>