Lennart Regebro wrote:

Great page. Heres the first thing I don't like:

Registering it would probably work like this::
 <view

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.

For reference what is the difference? Apart from page being a specific type of view (just like any specific implmentation) aren't they the same? (I am one of those newbies)

Second thing:

     name="index.html"
vs
     @page(u'update.html')

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! :-)
This kinda seems to make sense to me, I thought the same when reading the proposal but I can see the simplicity of having the names in python too. I guess it comes down to whether we believe the names are wiring or application specific. I am not sure about that it seems like one of those flip-flop decisions that could always be argued as the line has to be drawn somewhere.

Third thing:
"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...
What's the difference between boiler plate class and boiler plate ZCML? Apart from newbies that are coders are probably most used to python syntax than ZCML directives.

In general is the concept that one day (possibly now) there will be tools to make ZCML easier for everyone and usable by non-python coding site administrators so therefore things they want to be able to do often should be able to be done in ZCML?

Cheers,
Pete
_______________________________________________
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