[Grok-dev] Re: grokcore.view -> grokcore.browser
faassen at startifact.com
Sat Jul 19 07:39:37 EDT 2008
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).
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
More information about the Grok-dev