Inconsistent access to macros of page templates

Bug #377948 reported by Patrick Gerken on 2009-05-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope 2
Won't Fix
Undecided
Unassigned

Bug Description

If one acquires a page template from zodb which is actually stored in file system, one gets a class
Products.CMFCore.FSPageTemplate.FSPageTemplate.

One can access the macros defined in that page template with
obj.macros

The class looks like a plone class, but actually it inherits the macros as a property from Products.PageTemplates/PageTemplate.py

If one acquires a page template that is defined as a browser:view via zcml, one can acquire macros via
obj.index.macros
or
obj['macros']

at least in 2.10 in trunk, one can acquire macros via
obj.index.macros,
or if he knows the macro name, he can acquire the concrete macro via
obj['macro_name']

I have no idea who is wrong about all this, but it would be cool, if we could agree that at least one implementation is wrong, so that third party code needs only one way to get the macros. Currently there is no single one way that will work with all implementations. Also, I think that the way it works in trunk is wrong too.

Lennart Regebro (regebro-gmail) wrote :

Since in BrowserViews, obj.index is the template, what you call obj.macros and obj.index.macros is actually the same thing.

obj['macroname'] is a convenience method which at least in Grok I found more incovenient than convenient, and if I remember correctly I deprecated in Grok.

Patrick Gerken (do3cc) wrote :

I was expecting that the browser view, if configured without a class but only a template, could work as a drop in replacement for a page template that resides in zodb. But it currently is not, or only half baked.
It is possible to retrieve the macros directly, but only if you try to access it like an element of a dictionary.
So a tal Expression can retrieve the macros from a page template and browser view, since it will try both attribute access and dictionary access. But in code, you can not write code that works transparanently with both browser views and page templates. Either you can only access macros as a dictionary item only, or as an attribute only.

Look here for an example:
http://dev.plone.org/archetypes/browser/Products.Archetypes/trunk/Products/Archetypes/generator/widget.py#L140

It is easy to make this code look up a browser view page template. But then it breaks because it assumes that the template has an attribute macros. There is currently no way to access the macros in a way that you can transparently replace the Browser View with a page template in zodb. And this is the bug, imho. Now I don't know who is wrong and who is right...

Lennart Regebro (regebro-gmail) wrote :

No, BrowserViews are BrowserViews, and not drop-in replacements for templates. That's not half baked, it's fully baked with mascarpone and amaretto on top. :-) It's not a replacement, it's an improvement. If you want to override a template, then override it with a template. If you want to override it with a BrowserView, then use a BrowserView.

Lennart Regebro (regebro-gmail) wrote :

It's a feature, not a bug.

Changed in zope2:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers