On Fri, Apr 22, 2005 at 12:27:18AM +0200, Stefan H. Holek wrote:
> This is due to how Python Scripts compute their cache keys. The 
> relevant snippet from PythonScript._exec() is:
>             asgns = self.getBindingAssignments()
>             name_context = asgns.getAssignedName('name_context', None)
>             if name_context:
>                 keyset[name_context] = aq_parent(self).getPhysicalPath()
> 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 has two advantages: it's more explicit, and control
is given to the site admin rather than hardcoding it.

The disadvantages I see to using my current
"container" workaround are:

* The templates are client code. Having to change potentially
  multiple templates just to affect cacheing behavior of one script
  violates the Don't Repeat Yourself principle.

* It's too surprising.
  When reviewing code, the difference between "context" and "container"
  brings many things to mind. Cache hit/miss ratio is not one of them.
  When I stumbled on the workaround, if I hadn't bothered to
  ask here but had merely committed the change to my templates
  and moved on, I would have been "programming by coincidence"
  (see "The Pragmatic Programmer").

  I'll probably remember it now, but it seems like kind of an
  obscure guru-level thing for a template author to have to know,
  especially if they are not even a developer and only know how to
  write some simple TALES expressions.

* It's an implicit implementation detail.  The difference in caching
  behavior between "context" and "container" is AFAIK not documented 
  anywhere, not even in the source code (unless you argue that
  the semantics of the lines you posted above count as documentation).

  Anyway, I have no guarantee that future versions of zope
  won't silently break it.

* There are other reasons I might be forced to use "context".
  For example, if my site offers two CMF skins, each of which
  provides some scripts with the same names, I might have common
  templates that need to acquire the script from the current
  skin and thus may not be able to find it via "container".

  admittedly there are hacky workarounds in such situations, 
  e.g. have trivial wrapper scripts live near the templates.

For a related annoyance, see:


Paul Winkler
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to