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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to