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.
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.
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.
2b. Be callable.
Can we get rid of one of these? 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).
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
If we want to sacrifice the ease of registration, which this proposal
does to a small extent 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:
2. Remove browser:page and browser:pages completely.
3. Remove requirement 2a or 2b on views.
Zope3-dev mailing list