[Zope3-dev] Brainstorming about browser pages

[Philipp von Weitershausen]

Hey Lennart, Peter,

I'll just be lazy and reply to both of you in one email.

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

/me wonders if that "great" was ironic :).

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

Good point about the page vs. view thing. This nomenclature predates my
involvement with Zope 3 even (and I got in around 2002). I think the
term "page" was initially associated with something that's HTML, so
something that comes out of a page template and is displayed by a browser.

I really would like to reuse the simpler directives as much as possible
which is why I'm trying to mention <view />. Perhaps we'll have to end
up using <browser:view /> because of the layer problem I mention. In
analogy, perhaps the browser:pages directive should be named
browser:views so that we can ditch the "page" nomenclature once and for all.

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

It's not only about simplicity, it's also about instrinsic information
or not:

"...what gets viewed and for what request as well as the names of the
actual browser pages, are intrinsic to the implementation.  Why are
the page names intrinsic? Because the different method refer to each
other in URLs, form handlers and redirect calls."

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

Yes. Note that I don't feel strongly about this. This is just an idea. I
understand Lennart's concern about the consistency, so I leave it up to
Lennart to convince me of something else.

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

It's not my invention. It's in zope.formlib and it's being used, whether
you like it or not :). Seriously, as I point out in my proposal, you can
either hardwire the template via ViewPageTemplate or use a loose
coupling via NamedTemplate.

Btw, I think the name "NamedTemplate" is confusing,
"NamedTemplateImplementation" even more (and too long).

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

That's indeed right, the class becomes a lot less boilerplate when you
stick every browser view method and template you have on an content type
on it.

>> but still, it doesn't feel quite right...
>>
> What's the difference between boiler plate class and boiler plate ZCML?

Good point.

> Apart from newbies that are coders are probably most used to python
> syntax than ZCML directives.

This is exactly why I (we) want to move the stuff that is better done by
Python to Python.

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

I'm not sure what you mean by these "tools"...


Thanks for the feedback from the both of you.

Philipp