Great page. Heres the first thing I don't like:
Registering it would probably work like this::
You would register them using a ``browser:pages`` call:
It is not immediately obvious to thew Zope3 newbie what the difference
between a "page" and a "view" is and why we would need to
differentiate between them. So I think we shouldn't use both view and
page statements, but probably only have "page" and "pages" statements.
I think that unless we can move all naming into python (and I'm not
sure we can) we shouldn't have any naming in Python. Consistency is
the enemy of confusion! :-)
"What if someone wants to customize this view by changing the template
but not the helper method? You either have to subclass this view class
and add a custom __call__ to your subclass, or you use *named
templates* from zope.formlib:"
Naaaah. I don't like this, but I can't tell you why. Maybe just
because it's too complicated. Same goes with your usecase 1. I
actually don't want to create a boilerplate class just to hold page
templates. And sure, if we could get rid of the automated class
creation in Usecase 3b, then I'd might opt for getting rid of this
class creation too, but now I just don't see why.
On the other hand, in most cases it means I'll create one view class
per object and tuck a lot of templates on it, but still, it doesn't
feel quite right...
Zope3-dev mailing list