[z3-five] Re: calling views

[Philipp von Weitershausen]

Martijn Faassen wrote:

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

No, pages do their best to be publishable. A page *should* provide its 
own __call__. Only if it doesn't, we do something. In case of a 
template, we provide a __call__, in case of a publishable attribute, we 
tell the publisher to go there.

> [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_, ))

Right, what I wanted to say was: Only when a template is involved, we 
make up 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__.
> 
> 
> Despise viewmeta.py or not, still Zope 3 *always* creates a __call__ for 
> pages, in *all* combinations of template, attribute and class.

Only for templates. And that's the only case where it's really 
necessary. For the other cases, you can tell the publisher where to look 
for things.

> 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 won't be able to call views on an object. You will have to do 
something like this in PythonScript:

   absolute_url_view = zapi.getViewProviding(context, request,
                                             IAbsoluteURL)
   absolute_url = str(absolute_url)  # IAbsoluteURL promises __str__


When you get a view that is a browser page from a template, you will get 
__call__ anyway (since this is the case when we provide it):

   edit_html = zapi.getView(context, request, "edit.html")
   return edit_html(context, request)

So, I don't see a problem there.

> You seem to be suggesting that in Zope 3, __call__ is never used or 
> deprecated.

No, you're getting me wrong. Views that are published should provide a 
__call__. Views that aren't should have them. And if a view is to be 
published but doesn't have a __call__, we use browser_default.

> I'm curious to see whether there might not be some Zope 3 
> use cases after all. Perhaps Python scripts are one;

I don't see the use case. If it's a view to be published (== page), it 
must have a __call__ anyway. If it doesn't, then it has a method we can 
call. That means it provides an API which should be declared in an 
interface.

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

I guess I'm wrong. I take that back. I was confusing this, as you 
suspected, with the 'views' namespace. I'll put it back in.

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

Right, valid use cases (this is actually my code :))

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

I know, there are prettier solutions.

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

Well, we won't have to emulate standard_macros; I'll put the __getitem__ 
stuff back in.

> Zope 3 is still supporting
> 
> context/@@myview/macros/foobar
> 
> I presume? We should support this in Five.

No, I think it only supports

   context/@@myviewfromtemplate/foobar

where foobar is a macro.

> I see one such case in:
> 
> zope.app.file.browser (image_edit.pt):
> 
>   <div metal:use-macro="view/generated_form/macros/body">

Hmm. The view must be doin something there. Looks odd to me.

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

Well, there hasn't been an official warning about the 'views' namespace 
in TALES. You _are_ supposed to use context/@@view though. As for the 
__getitem__ thingy, I was wrong. Sorry again, I'll put it back.

Philipp