[Grok-dev] Re: grok.Site
Philipp von Weitershausen
philipp at weitershausen.de
Sat Nov 4 11:40:53 EST 2006
Martijn Faassen wrote:
> Yesterday JW and I started working on grokblog. We're using this as
> another experimental package to test grok on, and of course we'd like to
> write blogging software.
Me too, btw. :)
> It's only a skeleton now, but we wanted to use
> 'getSite()' in it and while grok didn't stop us, we needed to pull in 4
> or 5 different imports.
Huh? How come? from zope.app.component.site import getSite. Easy :)
> ME GROK NO LIKE IMPORTS! ME GROK SMASH IMPORTS!
> So, just now I've checked in a new grok mixin, called grok.Site. It can
> be mixed into grok.Model or grok.Container. If you do that, the object
> will be turned into a site. This means that getSite() works to get the
> application root.
Well, it would also get any other site object. The problem I currently
have with sites, or rather the term "site", is that it is used
synonymously used with "application root", like in the CMF. In your
discussion below, you even try to encourage us to find a sensible way to
make grok applications synonymous with sites. I think that's a bad idea.
Truth of the matter is that a site is merely a place where you can make
local registrations. Often that is the same place as the application
root. But as you know, you can nest sites. Recently I even discovered
the use case of having (event handler) registrations local to a single
view, so the view was a site even. While that sounded wicked at first
(how can a view be a site?), it served the use case well and in a very
In Zope 2, by the way, you can define "local components" anywhere you
like, too. Things like the "error_log" are acquired wherever you are, so
you can put it directly on the object or folder you're in, or anywhere
up in the hierarchy. In Zope 3 we don't do attribute-based acquisition
anymore, but we still do acquisition, explicit interface-based
acquisition that is. I think it's valuable to still be able to place the
definitions of such components (e.g. the IErrorREportingUtility)
anywhere in the hierarchy (and you can, after all).
Yesterday I talked to Jim about this. Our conclusions were:
* The 'site' term was borrowed from the CMF because at first sight
there's a strong resemblance. On second sight, however, is confusing as
a "site" is merely an object that has a component registry associated
with it (formerly known as "site manager"; note that zope.component has
almost no mentioning of that word anymore). Both Jim and I are not too
fond of the term "site".
* On a counter point, it should be noted that you shouldn't over-do
sites. Every site has its component registry which can consume a lot of
memory since it caches all lookups. That doesn't mean you shouldn't put
sites where they make sense. It just means that making every object in
your hierarchy a site can lead to problems.
* Zope 3.3 raised a lot of critique because it moved and renamed so many
things. Jim (and I, too) is reluctant to any drastic changes like that now.
So, we really don't have a way forward. All I know is that I'm less and
less fond of "site", though I have very little constructive ideas for
replacements. The name with the least impact regarding change would be
"component site", making it clear what "site" really is about.
> We've discussed at the sprint that perhaps we should call this grok.App.
> We could still do so, but this would entail renaming getSite to getApp
> and potential confusion. So, I've decided to stick with the Site
> terminology for now. Perhaps someone can up with a good motivation on
> why using grok.App and 'getApp' doesn't actually lead to confusion - it
> might not, I just didn't want to run the risk right now. Hoping someone
> will show conclusively it's fine to call it App, as it's just better to
> speak of apps or applications than it is to speak of sites.
I think grok.App could be useful, but primarily as an application root
object in terms of he object hierarchy, not so much as a (component)
site. getApp() would then be something like getRoot(), except you would
get the application's root, not the ZODB's root. And nesting grok.Apps
would probably not make a lot of sense.
More information about the Grok-dev