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 created classes. 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: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
