[Zope3-dev] Brainstorming about browser pages

[Peter Simmons]

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