[z3-five] calling views

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
> 
>> Great work on fixing this issue!
>>
>> What about the case where in TALES you want to say something like:
>>
>> views['someview'](foo, bar, baz)
> 
> 
> Note that 'views' is deprecated. You should use
> 
>   context/@@some_view

It still needs to be callable from python though; doesn't Zope 3 allow 
this? I don't even know whether @@ works in ZPT in Five yet.

>> Is that a legitimate use case?
> 
> 
> I don't think so. The views you call from TALES are usually views 
> providing a certain functionality, such as absolute URL. This 
> functionality is described thru an interface, so we make them views 
> providing an interface (queried using getViewProviding()).
> 
> Same goes for macros (context/@@standard_macros/foobar) where views 
> aren't supposed to be called but to provide extra functionality. If 
> views are to be called, they should provide a __call__ themselves. We 
> shouldn't provide this rather hackish implementation of __call__ ourselves.

But Zope 3 provides a __call__ for views itself.

Here for templates:

src/zope/app/pagetemplate/simpleviewclass.py

And here for attributes:

src/zope.app/publisher/browser/viewmeta.py (class simple at the bottom)

It does quite a bit of work to make the __call__ exist.

> If you think about it, only browser pages have to provide __call__ 
> because that's the API zope.publisher/ZPublisher expects. So, we're 
> actually thinking about only having views providing IPublishedView or 
> similar published. A published view would almost never be called from 
> ZPT; it would be published by zope.publisher/ZPublisher.

Here you seem to be saying __call__ is actually supposed to exist on 
views. I don't understand anymore what you are proposing. :)


> On a side note: I think the metaclass majyck would allow us to not 
> require browser views to inherit from Products.Five.browser.BrowserView. 
> Instead we would mix this in using the metaclass stuff. That would make 
> external products indepentend of Five-imports.
> I'm not sure whether this would really work, since we might be mixing an 
> ExtensionClass with a regular old-style class. Also, we would make an 
> assumption that their classes are not new-style classes.

The metaclass magic is there explicitly to allow mixing in 
ExtensionClass with old style classes. It won't work with new-style 
classes though, which gave me some issue in template integration that 
isn't yet fully resolved. You ripped out some base classes in your 
recent change that are there in Zope 3, and do contain some useful 
functionality like __getitem__() to look up macros.

Regards,

Martijn