On Wed, 2003-09-17 at 17:38, Fred Yankowski wrote:

> My original question concerned a detail of how the CMF Caching Policy
> Manager interprets the 'Predicate' of a caching policy:  it seems to
> interpret any 'content' object in that predicate as a reference to the
> *parent* object of the object being considered for cache header
> management.  That made no sense to me, and I pointed to the exact code
> involved, but I still don't know if that code is the result of
> Undocumented Wisdom or merely a Goof.

The CMF CPM was not initially designed to ease caching of skin images; 
it was originally intended to allow caching of the page templates which
serve as views on the "real content".  In fact, in CMF 1.3 only
FSPageTemplates know to talk to the CPM at all;  CMF 1.4 extended this
to the other types, but without a lot of thought about how their needs
were different.

I have wanted to add a binding to the TALES namespace to allow access to
the "skin object" for some time:  the current values in the namespace

    'content' -- the skin object's aq_parent

    'view' -- the skin object's name (a really bad choice for the key)

    'keywords' -- any keywords passed to the "method"

    'request'  -- the request object

    'member'  -- the authenticated member (None for anonymous)

    'modules', 'nothing' -- typical TALES

    'time' -- request time

I think we should be adding in another binding, perhaps 'skinned' for
the skin object, which would allow you to filter on its metatype in your

> Meanwhile, back on the ranch, I'm getting good results with this
> policy predicate:
>       python: content.meta_type == 'Filesystem Directory View'
> With that, all objects in a Filesystem Directory View get cache
> control headers.  The aforementioned Wisdom|Goof prevents me (AFAICT)
> from discriminating different meta_types of the individual objects
> within the various FSDVs, but so far one policy across all such is
> just fine.

I typically want to have skin images, as well as javascript and CSS
files, cached for much longer than rendered content views. YMMV.

Tres Seaver                                [EMAIL PROTECTED]
Zope Corporation      "Zope Dealers"       http://www.zope.com

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to