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

[Godefroid Chapelle]

Martijn Faassen wrote:
> 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.

Eventually is the right word ;-)

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

I think Page is wrong because some views are not pages...

> Regards,
> 
> Martijn

I think arguments against 'browser' make sense.

Nevertheless, the current egg contains more than views; that will stay 
so even if some of it is factored out. IOW, 'view' might be too 
restrictive.

What about 'grokcore.presentation' ?

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be