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

[Lennart Regebro]

On 4/23/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> 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.

Sure.

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

Well, yes I do. I see that the code for the directives are less
complex but it gets more complex for the users of these directives.
The complexity has just moved. So it´s not actually more complex, just
in different ways.

I guess you can say that's why I´m -1 on the proposal. I'd like to get
rid of complexity, not move it around. :-)

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

I know what you are trying to do, and I'm not saying that's a bad
thing. I'm just saying that I don't really think this proposal does
it, or at least not enough. :-) All I'm doing is trying to point out
why this is so hard to fix, and maybe try to see if there is an
alternative route.

> > There are two parts to that requirement.
> >   2a: Be a class that implements IBrowserView.
>
> IBrowserPublisher

Right, sorry.

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

Because that would fix the problem.

> What's wrong with having to implement a specific attribute (__call__)?

Because it means that wee need to have one class per view. And that in
turn means that we either have to have a lot of essentialy empty
classes, or create magical classes dynamically. That in turn creates
this complexity. I´m trying to see if we can get rid of 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.

No, you are suggesting to refactor them and maybe rename them. My #2
is to deprecate them completely and do nothing else. Which, I think,
is what you wanted to do before, but loads of people (including me ;)
) screamed.

--
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/