[Grok-dev] Re: grokcore.view -> grokcore.browser

[Martijn Faassen]

Hey,

Philipp von Weitershausen wrote:
> Kudos to Godefroid and Lennart for factoring out view-related stuff out 
> of Grok and making it work in Zope 2. May I suggest to call the package 
> grokcore.browser instead of grokcore.view, though? Reasons:

> 1) we have different kinds of views and this package is about browser views

I wonder whether the intent is to factor out JSON and REST and the like 
into a separate package eventually? I imagine it does need to go into 
its own package, as it's not something that's going to be easy to 
support in a Zope 2 context and in some ways quite different.

I also think we're going to have to factor Permission out of 
grokcore.view eventually if we want to support model-checked security.

> 2) the package already contains other browser-related components (e.g. 
> browser resources for CSS/JS/...)
> 
> 3) it's a familiar Zope 3 naming convention (and part of factoring 
> things out to separate packages is to ease adoption in pure Zope apps, 
> after all).
> 
> Thoughts?

I don't really like the convention 'browser' very much, nor do I think 
that 'browser' is such a good name. 'browser' is somewhat overloaded as 
a term - people might think it's a form of object browser, or support 
for particular web browsers, or non-existent relationships with things 
like zope.testbrowser, and the like. In addition, Grok hasn't been 
following the Zope 3 'browser' convention in Grok applications at all. 
The 'browser' convention only makes sense to people already very 
familiar with Zope 3. So, if you tell a random python programmer that 
grokcore.browser's central purpose is to make available grok.View and 
friends, they'd wonder why it's not called grokcore.view.

(In fact I think these browser sub-packages in Zope 3 libraries is 
actually generally the *wrong* convention... Many 'browser' packages add 
ZMI-style stuff that I wish were off in packages of their own so we 
easily could stop using them... Where it doesn't contain ZMI stuff but 
more generally useful things, I don't see much sense in partitioning the 
code away off into a sub-package at all - it only serves to make the 
namespace more nested for no real purpose. I do see the utility in the 
distinction View/BrowserView, but not in the package naming conventions.)

The benefit of using 'view' is that people tend to have a better clue 
what 'view' means in "model/view", and we *do* call the main component 
in grokcore.view "grok.View", after all. We don't really have much 
called "Browser" in there, except indirectly where we import from Zope 3 
(BrowserView, BrowserPage, IBrowserSkinType, BrowserRequest), and not at 
all in the __init__.py.

An alternative would be 'Page'. Not ideal either, as the word 'Page' is 
not really used much in the package either (PageTemplate, BrowserPage), 
and is only represented as PageTemplate (and PageTemplateFile?) in 
__init__.py

Regards,

Martijn