[z3-five] Re: calling views

[Martijn Faassen]

Philipp von Weitershausen wrote:
> 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.

Okay, let's talk about pages then:

Since pages do their best to provide a __call__, I think we'd better 
provide a __call__ in Five as well.

[snip]
> 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__.

That is incorrect; it is also used if there is a view class supplied, 
from viewmeta.py:

     if class_:
         ...
         if template:
             # class and template
             new_class = SimpleViewClass(
                 template, bases=(class_, ))

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

Despise viewmeta.py or not, still Zope 3 *always* creates a __call__ for 
pages, in *all* combinations of template, attribute and class.

There are bound to be use cases where I want to call a page. If not in 
pure Zope 3, I'll be able to want to call a Five page from a python 
script in the ZMI. It'd be very confusing to an unsuspecting scripter if 
I could call all 'methods' on an object except the ones defined through 
Five.

You seem to be suggesting that in Zope 3, __call__ is never used or 
deprecated. I'm curious to see whether there might not be some Zope 3 
use cases after all. Perhaps Python scripts are one; I can imagine use 
cases that as a scripter, I want to be able to call a view on some page, 
get the results, and do something with it. It might even be returning 
XML and I want to be able to transform it using XSLT or whatnot. :)

[snip]
>> 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.

As long as the right base class is mixed in this seems 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?

Like mixing in simpleviewclass.simple, which provides a __call__ and a 
__getitem__. Though you say later on that __getitem__ is apparently 
deprecated.

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

I thought you were talking about another feature, the 'views' namespace 
in ZPT.

This is rather frustrating; there should be some more clarity about what 
is deprecated in Zope 3; seems like half the page template system turns 
out to be deprecated. How is anyone supposed to know about this?

Note that I still see use of the __getitem__ feature in Zope 3, for 
instance in zope/app/undo/undo_all.pt:

<tal:var define="global macros nocall:context/@@undo_macros" />
<div metal:use-macro="macros/global_vars" />

<div metal:use-macro="macros/location_link" />

<form action="@@undoAllTransactions.html" method="post">
<div metal:use-macro="macros/previous_batch" />

<div metal:use-macro="macros/undo_log">
..

Another example is in zope.app.zptpage.browser (inlinecode.pt)

         <div metal:use-macro="context/@@form_macros/widget_rows" />


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

I've always considered the @@standard_macros way rather ugly myself. :) 
Seems to be flattening all the macros into a single namespace while 
having more namespaces would be more explicit.. Perhaps I'm missing 
something about the reasoning behind it.

Anyway, Five is not about providing a particular UI framework for Zope 2 
(though that could be a fun project), just about providing the view 
machinery. Particular applications will have their own system of macros 
in particular pages, and macros in general should be supported.

Zope 3 is still supporting

context/@@myview/macros/foobar

I presume? We should support this in Five.

I see one such case in:

zope.app.file.browser (image_edit.pt):

   <div metal:use-macro="view/generated_form/macros/body">

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

You haven't made the argument yet that __call__ on pages is deprecated.

Where is are the warning messages and/or the list of deprecated 
features? The exact same argument for not supporting deprecated code 
exists in Zope 3; why is all this in there?

Regards,

Martijn