[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
>> 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
> 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?
Sure. I would never call setSite() myself, unless I'm in a unit test or
trying this out.
>> 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
More information about the Grok-dev