Lennart Regebro wrote:
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> 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
I'm just suggesting to change the awareness of that fact for the end
user to make everything less magical.
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
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:
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
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 :)
Zope3-dev mailing list