[Grok-dev] Re: grok.Site

[Philipp von Weitershausen]

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 
straight-forward manner.

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.

Philipp