[Product-Developers] Re: Where does it hurt?

Michael Hierweck team at edv-serviceteam.net
Mon May 19 12:35:09 UTC 2008

Dylan Jay wrote:
> Daniel Nouri wrote:
>> Michael Hierweck writes:
>>> Reinout van Rees wrote:
>>>> Martin Aspeli schreef:
>>>>>  - Areas where there appears to be more than one approach, and it's
>>>>> not clear which one to choose
>>>> Hooking templates up with views. I scream and curse every time someone
>>>> puts a hardcoded ZopePageTemplateFile('myhardcodedname.pt') in code. I
>>>> had to *monkeypatch* plone.app.content to wire in a different template
>>>> to render the folder listing (order of columns had to be different).
>>> Up to now I thought statements like
>>> render = ViewPageTemplateFile("xyz.pt")
>>> __call__ = ViewPageTemplateFile("xyz.pt")
>>> as if found them in Plone 3 for Viewlets and Portlets and other
>>> resources were good, modern style and best practice.
>>>> If we're going to be buried in zcml, please also use it for the places
>>>> where it is actually useful. Like the 'template' attribute so that you
>>>> can override it.
>>> How to make it better/more configurable?
>> If you're using your own layer, you can just register a view with the
>> same name for your layer.
>> You can't actually customize a view with the template argument unless
>> you use overrides.zcml or register it for something different.  So it
>> doesn't make too much of a difference if you assign the template in
>> Python or ZCML.
>> Of course, there's valid uses of registering a view class with a
>> different template.  To allow this, the author must use the 'index'
>> class variable name for the template, like so:
>>   >>> class MyView(BrowserView):
>>   ...     index = ViewPageTemplateFile("xyz.pt")
>> This allows you to register the same class with a different template,
>> for a different name or context.  (Naturally, registering it for the
>> same name and context will fail, unless you use a different layer.)
> great example of 2 different ways to do the same thing but have
> differetn unforseen consequences. 

Sorry, I did not understand the second, more flexible possibility.

More information about the Product-Developers mailing list