Am 11.03.2010, 17:15 Uhr, schrieb Charlie Clark <>:

> I understand that and I've even had some success registering macros "the
> Zope 3 way" - although I'm not sure that I see any advantage this way to
> what you propose. However, zope.formlib.form.PageForm comes with it's own
> template which has macros and slots which I like to be able to use and  
> the
> default __call__ will use this template or a replacement one defined in a
> View class template attribute. And it's creating a template that uses
> zope.formlib.form.default_page_template where I'm stuck.

hm, seems that Maurits has already solved this problem:

Solution: assign the standard template to another class variable which can  
then be accessed from the new template in the view. I think this is  
probably one of the examples of Zope 3's tendency to indirection getting  
out of hand: NamedTemplates exist, in theory, to separate BrowserViews  
 from their templates. :-/

Personally I think this is overkill especially as the original adapter has  
to be registered again although I have no idea why this has to happen.

The pattern

class MyView(BrowserView)

        template = ViewPageTemplateFile(...)

in the rare cases where templates are defined in the view class, a  
perfectly reasonable approach. But thanks very much to Maurits for showing  
the way. It may be worth noting that the example uses NamedTemplate with  
impunity in a Zope 2 context. Maybe five.formlib.formbase.FiveFormlibMixin  
can do without the hardcoded zope.formlib.__file__ template definitions  
and just worry about character encoding?

Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to