[Grok-dev] the beginnings of megrok.feeds

[Brandon Craig Rhodes]

Christian Theune <ct at gocept.com> writes:

> On Sat, 2008-07-19 at 17:36 -0400, Brandon Craig Rhodes wrote:

>>  Why does the "ViewGrokker" ... call "provideAdapter", which ...  is
>>  a global registration command...?  Shouldn't it instead register the
>>  view as a local adapter inside of its particular Grok site?  Imagine
>>  that ...  I instantiate two different Grok apps in my database that
>>  both use "Foo" objects ...  it seems that ... the global
>>  registrations would make each application's views magically appear
>>  over in the other application?
>
> Only if your 'Foo' objects really refer to the same class objects.

Yes, which is precisely what I am imaging; that two Grok apps, for
example, might both provide views for a single class, like the standard
library class "email.Message".

> 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.  Instead, when Grok code declares a local
adapter and asks that it be installed on a Grok Site, this should be
something done in RAM, at runtime, as part of grokking.  Zope traversal
should be extended, if it does not already support the feature directly,
so that local adapters can get activated as it traverses past an object
of a particular class.

In other words, if I create a local adapter "X" in my "EmailSite" Grok
Application, then at grokking time some Zope registry (which we might
have to create) mapping classes to local adapters should get the
registration:

   "EmailSite class objects, when traversed, activate local adapter X"

Then, when Zope is traversing into our App objects, the correct adapters
get activated.  Beautiful!  This would have the magnificent property
that when someone added a new local adapter to their code and restarted,
it would immediately start working without their having to delete and
re-create their Application object; and, when someone removed a local
adapter, it would immediately start working.

In Grok, we declare things in code.  They should stay there.

2. We Should Rename LocalAdapter to PersistentLocalAdapter
----------------------------------------------------------

We should keep the current local adapters around; I am not suggest that
we delete or remove them!  Someone might have found them useful, and, if
so, they should still be able to use them.  But they should have the
word "Persistent" attached to them so that anyone crazy enough to use
them gets a big, obvious signal that unlike most of the things that they
create in Grok - like Views and Viewlets - PersistentLocalAdapters will
*not* simply work because they exist in the code.  The word "Persistent"
will be a hint that this is a crazy hybrid concept that straddles the
world of code and the world of storage, and that has to exist in *both*
places (both in your code, and also in the database with your
application) before it will work.

3. Views and Viewlets Should Become New-Style Local Adapters
------------------------------------------------------------

Once we have working the concept of lightweight, non-persisted,
traversal-activated adapters working, then all normal Grok adapters like
Views and Viewlets should become new-style local adapters.  If your Grok
app defines an "EmailIndex" view that renders an "email.Message" object
for your site, then the "EmailIndex" should only be active and available
when a user is actually browsing beneath your Grok app.  Other apps
should not have the view available, since this makes it impossible to
install several Grok apps inside of a single ZODB instance without their
views bleeding over and becoming available inside each other.

This will require a small bit of code so that the grokkers will "see"
where your Application object is inside of your Grok application code
base, so that they can make all of your Views these new-style local
adapters.  It might now become an error (I'm not sure it is right now?)
to have two grok.Application objects inside of a Grok application; or we
might allow a single code base to provide multiple Applications so long
as the user could signal which views went with which others.

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; but if we are going
to support multiple Grok apps in a single ZODB, as we do today, then the
above steps seem to me quite necessary to stop them from trampling all
over each other.

ME GROK WANT APPLICATION ORTHOGONALITY :-)

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon