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:
<li tal:repeat="subfolder python: here.objectValues('Folder')">
Folder <span tal:content="subfolder/title_or_id"> contains
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
-1 from me
> For a related annoyance, see:
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 <[EMAIL PROTECTED]>
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -