Inappropriate context variable in FSPageTemplates within DirectoryViewSurrogates

Bug #599325 reported by Enrique Pérez Arnaud
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope CMF buildout
Confirmed
Low
Unassigned

Bug Description

The problem is hit with FSPageTemplates that live within a DirectoryViewSurrogate (within a DirectoryViewSurrgate within a ...) whithin a DirectoryView. The problem is that such a template gets as context the DirectoryViewSurrogate whithin which it lives, and that such an object doesn't get in its aq_inner.aq_parent chain the "real" context object on which the template is called. As a consequence, browser components that get rendered in macros surrounding or within the template get an unexpected context, and bad things happen such as (in a plone site) totally wrong breadcrumbs, portlets not getting found by managers, wrong css class for the body element of the produced html, etc.

My investigations, greatly helped by Hanno Schlichting on the plone-dev list, have led me to think that the problem lies in the pt_getContext method of Products.CMFCore.FSPageTemplate.FSPageTemplate. This method is directly got from Products.PageTemplates.ZopePageTemplate.ZopePageTemplate. IMHO, that method makes sense in a PageTemplate living in the zodb, but not in nested directories in the filesystem. So my proposed solution goes through giving a special pt_getContext method to FSPageTemplate (I'm in the proccess of attaching a proper patch, once I manage to write a proper test):

from Products.CMFCore.interfaces import IDirectoryView
from Acquisition import aq_inner, aq_chain, aq_parent, aq_base

...
class FSPageTemplate:
...

    zpt_pt_getContext = ZopePageTemplate.pt_getContext.im_func

    def pt_getContext(self, *args, **kwargs):
        c = self.zpt_pt_getContext(*args, **kwargs)
        if IDirectoryView.providedBy(c['context']):
            context = c['context']
            for obj in aq_chain(context):
                if not IDirectoryView.providedBy(obj):
                    context = aq_base(context).__of__(obj)
                    break
            c['container'] = c['container'].__of__(aq_parent(aq_inner(context)))
            c['context'] = c['here'] = context.__of__(c['container'])
        return c

--------------------

I am finding this with both:

python2.4 + Zope-2.10 + CMF-2.1
python-2.6 + Zope-2.12 + CMF-2.2

Revision history for this message
Enrique Pérez Arnaud (enriquepablo) wrote :

I am adding a patch (with a test) that addresses the above issue. The patch also needs a new file in the tests directory of CMFCore, which I also attach (testNestedPT.pt), that would live in

Products.CMFCore/Products/CMFCore/tests/fake_skins/fake_skin/test_directory/testNestedPT.pt

Is this the right way to add a file?

The patch differs from the above code in that I am not including the line

            c['container'] = c['container'].__of__(aq_parent(aq_inner(context)))

First, that does not change the c['container'], it remains the same as before. Second, I do not fully understand the semantic relationship between context and container, my first guess was that container was the context.aq_inner.aq_parent but that does not seem to be always (generally?) the case. And third, my use case, which is browser components that get the context from the template, does not involve the container variable at all.

So, untill further notice, I will leave it at this.

Revision history for this message
Enrique Pérez Arnaud (enriquepablo) wrote :
Revision history for this message
Enrique Pérez Arnaud (enriquepablo) wrote :
Revision history for this message
Enrique Pérez Arnaud (enriquepablo) wrote :

I guess I should havce metioned that the patch is against

 svn://svn.zope.org/repos/main/Products.CMFCore/trunk

using Python 2.6.5 and the buildout.cfg in the svn:svn.zope.org://repos/main/CMF.buildout

Changed in zope-cmf:
importance: Undecided → Low
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.