[Grok-dev] Re: grok.Site

[Philipp von Weitershausen]

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