[Zope3-dev] Re: RFC: The browser:page compromise

[Philipp von Weitershausen]

Lennart Regebro wrote:
> I'm -1 on this proposal.
> 
> I agree, browser:page is too complex and magic. The reason for it's
> complexity and magic is that there are two things that clash: 1. The
> need to have simple and easy view registrations, and 2. The
> requirement that view must be callable classes.

A publishable view must provide IBrowserPublisher. We happen to call 
such browser views "pages". This requirement and this nomenclature has 
worked well since very early days of Zope 3. I'm not suggesting to 
change that.

I'm just suggesting to change the awareness of that fact for the end 
user to make everything less magical.

> The second requirements mean that you have to create a lot of callable
> classes that do nothing particularily useful. There can created by the
> programmer, which is a lot of stupid work. Requirement 1 sais that we
> shouldn't do that. The result is that we then create them
> automatically which creates a lot of hard to understand magic.
> 
> All this proposal does it to try to split that magic up into three
> different ZCML statements to make it slightly less complex. It is
> after all a compromise. I would like to see if there s a way we
> instead can actually fix the problem completely.

Hmm, the goal wasn't to make things more complex. If you think that 
having three directives, each of which does exactly one thing, is more 
complex than having one directive that does everything together, I must 
have failed somehow.

Fixing the problem completely is certainly a pious wish, but we may 
never get there. Hence the compromise. I'm trying to improve what can be 
improved now. Just see how much of a fuss this tiny proposal made already.

> Evidently we do NOT want to get rid of requirement 1, because then
> people will again find making views a pain. Therefore, lets think
> about f we can get rid of requirement 2.
> 
> There are two parts to that requirement.
>   2a: Be a class that implements IBrowserView.

IBrowserPublisher

>   2b. Be callable.

Which is expressed by IBrowserPage. Basically, IBrowserPage extends 
IBrowserPublisher by a __call__ method.

> Can we get rid of one of these?

Why?

> For example, could we have an optional
> argument on view registration that tells the view which attribute to
> be called? (I know, that's not possible when views are just adapters,
> it's an example).

What's wrong with having to implement a specific attribute (__call__)? 
After all, having well-defined APIs means that you have to implement 
certain attributes/methods. We do and require it for lots of other 
stuff, why can't we require it for browser pages?

It makes everything darn simple if you can tell people "Just implement 
IBrowserPage" when they ask how to write a publishable browser view.

> If we can't get rid of either 2a or 2b, we will either have to
> sacrifice requirement 1, and making views will be a boring pain, or
> have to have a lot of hard to understand magic with dynamically
> created classes.
> 
> If we want to sacrifice the ease of registration, which this proposal
> does to a small extent

Does my proposal really make registration harder?

> I think we in that case should go all the way
> and remove the browser:page completely. It can in that case be moved
> out to a separate product for people like me, who want it.
> 
> 
> Summary: I think that we at this moment should do either:
> 1. Nothing.
> 2. Remove browser:page and browser:pages completely.
> 3. Remove requirement 2a or 2b on views.

#2 is what I'm suggesting so I'm not quite certain how to count the -1 
from above.

#3 I don't understand. Views are adapters. Publishable views need to 
provide IBrowserPublisher (this an old requirement in Zope3, you just 
never saw it because browser:page did magic). IBrowserPage makes 
IBrowserPublisher-compliance easy by offering you __call__ to implement. 
I can't imagine how it can get simpler than that. But I'm open to 
constructive suggestions.

Thanks for your comments.

Philipp