[Grok-dev] Re: final sprint report - please review my branch!

[Philipp von Weitershausen]

On 8 Apr 2008, at 13:38 , Brandon Craig Rhodes wrote:
> Philipp von Weitershausen <philipp at weitershausen.de> writes:
>
>> P.S.: On a technical note, I should add that I'm not entirely
>> satisfied with some of the details, for instance the "Context" base
>> class that was introduced. So some details may change.
>
> Right now that's how an application stack like Grok "signals" that
> certain of its classes are eligible to be automatically picked up as
> the context for Adapters (and specializations of adapters like Views)
> inside a module - by having things like Model and Container inherit
> from Context.

Yes, I saw that.

> But, you're right, it's probably a waste of resources to use
> inheritance to signal something about an object - since inheritance
> imposes all sorts of costs, probably including a performance penalty
> every time a method is called on a Model or Container.

I'm not really worried about that. I'm worried about making people  
subclass something at all. It'll hinder the reusability of the  
grokcore.component package.

For Grok-the-webframework, it's absolutely fine making people subclass  
a specific class to gain functionality (grok.Model, grok.View, etc.),  
but the supposedly-reusable packages shouldn't have to do that.

> Are you thinking of, instead, introducing a directive with which
> application stacks would mark up their classes as being eligible to be
> automatically detected as adapter contexts?  Maybe grok.autodetect()
> or something?

Yes, something like that. We won't be able to grok them because we  
can't grok before we grok ;). Rather, I have some very simple  
registration in mind that'll be part of the *meta* configuration  
(meta.zcml). I need to write down a story for this first, though.