[Grok-dev] Re: final sprint report - please review my branch!
Philipp von Weitershausen
philipp at weitershausen.de
Tue Apr 8 08:39:15 EDT 2008
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
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.
More information about the Grok-dev