[Grok-dev] the beginnings of megrok.feeds

Tim Terlegård tim.terlegard at valentinewebsystems.se
Tue Jul 22 07:03:52 EDT 2008

On Jul 21, 2008, at 2:27 PM, Brandon Craig Rhodes wrote:
> Christian Theune <ct at gocept.com> writes:
>> On Sat, 2008-07-19 at 17:36 -0400, Brandon Craig Rhodes wrote:
>>> Non-persistent configuration is a good thing if it works for you.
>> Maintaining component registration in the database can be a huge
>> drawback WRT to code restructuring/deprecation.
> Thank you, Christian; while puzzling over why Grok uses global
> registrations for views that should obviously only exist beneath each
> particular Grok app, I forgot that local adapters are currently
> implemented using the ZODB.
> It is now clear to me that I need to make some proposals.
> 1. Grok Local Adapters Should Not Live In The Database
> ------------------------------------------------------
> I am beginning to think it is entirely misguided that Grok attaches
> local adapters to Application objects through the database.  This  
> seems
> to have only bad consequences.

I think it's more common this happens for utilities. But I agree that  
grok should
not persist utilities or adapters if there are ways not to do that.

I don't have any experience of z3c.baseregistry, but I think it allows  
you to
add local utilities with zcml.



> Anyway, remember that I have always been a bit skeptical of why we
> create Application instances in the first place instead of a Grok
> Application just being always the root of its site

I agree the use of application is a bit weird. It's been discussed  
but it didn't look anyone agreed with me. As it is now, an application  
not necessarily the root of the website. Have no idea why anyone would
want to nest grok.Application objects. It just makes stuff more  
at least educationally.

But I'm not sure this has to be resolved with traversers. The registries
and their hierarchy will always be the same on every traversal.


More information about the Grok-dev mailing list