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

[Philipp von Weitershausen]

Lennart Regebro wrote:
> 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.

Is using a convenience base class really that much more complexity for 
the user? It's perhaps a little more typing, but it gives you less magic 
in return. Less magic is less complexity in a way.

I think browser2:page is an extremely easy directive. Because it's so 
stupid. It will eat an IBrowserPage factory and register it as an 
adapter. Implementing IBrowserPage OTOH is also dead simple given our 
convenient base class. Just implement __call__.

Perhaps I'm too deep into the matter to see the aroused complexity.

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

Not sure what you mean by that. One page is implementing by one class. 
The "implementation" of the page is in __call__. So I can't see how 
these classees would be empty. They at least have a __call__ method.

> or create magical classes dynamically. That in turn creates
> this complexity. I´m trying to see if we can get rid of it.

Be my guest. The browser2:pagesFromClass were added as part of the 
compromise so that people can conveniently put code for pages that use a 
lot of common code on one class. I admit that this will still have to 
use magic, however, there people explicitly choose to use magic. 
Currently they almost have no choice.

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

So, basically, register pages and all other adapterish things with an 
<adapter /> directive? Fine by me :).

> Which, I think, is what you wanted to do before, but loads of people
> (including me ;) ) screamed.

... hence the compromise :)

Philipp