[Grok-dev] Re: grok.Site

Philipp von Weitershausen philipp at weitershausen.de
Mon Nov 6 20:58:20 EST 2006


Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> 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 :)
> 
> I'm well aware of getSite(). If you want to use getSite you need to make 
> something a site.

Well, those are two separate problems, really :). But I see now, your 
problem was making something a site.

>> 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.
> 
> I imagine an app is always a site, but a site isn't always an app.

That's right.

> It also doesn't help that currently I haven't seen any uses of sites 
> outside of the concept of application root. I don't doubt that such 
> usage exists, but I don't know what the patterns would be as I have
> no examples.
> 
>> 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.
> 
> Ah, good, you have a use case. What called setSite() in this case? Still 
> the traversal machinery?

Sure. I would never call setSite() myself, unless I'm in a unit test or 
trying this out.

> [snip]
>> 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.
> 
> Okay, from this it's clear we'll keep the name 'site' for the thing that 
> can have local component registrations for now.

I guess. I think I'll write an email to zope3-dev advocating "component 
site", for the lack of a better alternative.

> So, we should consider a grok.App mixin that makes something into an 
> application root. This would require some API to get to the app root 
> that isn't getSite(). I imagine we can follow the pattern for sites in 
> that it'd be defined as a thread-local.

I guess we could. It feels a bit fishy to me, but that's probably some 
irrational doubt of mine.

> I must note that grok.App appears the first time in grok where we appear 
> to be inventing a new feature that isn't in Zope 3. Not necessarily a 
> bad thing, just something to be aware of.

At least the use case doesn't seem to be new, as Theuni stated in one of 
his replies.

Philipp



More information about the Grok-dev mailing list