[z3-five] Re: calling views

[Philipp von Weitershausen]

Martijn Faassen wrote:
> 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 probably didn't stress enough the difference between pages and views. 
Pages are things that are traversed and then published using the 
ZPublisher/zope.publisher. They need to provide __call__ or 
__browser_default__ so that ZPublisher can actually publish them.

I never seen a use case for calling browser *pages* from ZPT. I have 
seen use cases for traversing simple views, like absolute_url, from ZPT 
and doing stuff with them. In the case of absolute_url, a __str__ is 
provided so it can be included in ZPT.

> I don't even know whether @@ works in ZPT in Five yet.

I don't either but we should make it work.

>> 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

SimpleViewClass (that name is as much confusing as it is misleading) is 
only used when solely page templates are specified as browser pages and 
no class is used. Then it makes sense to provide a __call__.

> 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.

I absolutely despise of viewmeta.py. The naming of things is a start 
(e.g. 'simple').

Fact is that both Zope 3 and now Five use browserDefault or 
__browser_default__, respectively, when providing a hacky __call__ can 
be avoided. That is the case when a python method is specified for the 
page and not a template. Whenever a template is involved, it makes sense 
to provide a __call__.

>> 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. :)

I'm proposing to get rid of BrowserView.__call__.

>> 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.

Ah good. So that means, as long as we stay away from new-style classes, 
view classes wouldn't be required to inherit from Five's BrowserView. I 
propose to make that possible.

> It won't work with new-style 
> classes though, which gave me some issue in template integration that 
> isn't yet fully resolved.

Like?

> 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.

That functionality is deprecated as I said earlier. Macros should now be 
looked up with context/@@standard_macros/foobar, at least in Zope 3 
where the Rotterdam skin provides a "standard_macros" view. We could 
emulate that in Five.
No matter how we decide to do this, I don't think it's a good idea to 
port deprecated things because people would start using them and then 
find out that they don't exist in Zope 3 anymore at some point.

Philipp