[Grok-dev] Re: grok.Site

Martijn Faassen faassen at infrae.com
Mon Nov 6 11:28:44 EST 2006


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.

>> 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.

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

[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.

>> 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.

Yes, agreed.

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 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.

Regards,

Martijn


More information about the Grok-dev mailing list