[Grok-dev] Re: final sprint report - please review my branch!
faassen at startifact.com
Tue Apr 8 10:46:57 EDT 2008
Philipp von Weitershausen wrote:
> 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.
It's a mixin that doesn't actually do anything though, and it's dead
simple. Since grokcore.component is about subclassing anyway (Adapter,
GlobalUtility, MultiAdapter), I'd say this is perfectly acceptable.
If we take another approach, it'll have to compete in briefness with:
If we're concerned about subclassing, we can eventually expand Martian
with the facility to recognize classes by interface as well:
I think this could then even be used to implement the base classes we
have now (which I think are actually more readable):
I think such a thing is neat but of limited benefit, but it's something
to thin about. Until we have such a thing, let's just stick with Context.
>> 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.
Please. I think you're going to have a hard time engineering something
better than the elegant solution we already have. Going for a
registration approach sounds way more complicated and I don't see any
benefits so far. It also presupposes ZCML being used, which
grokcore.component shouldn't have to require from a programmer who wants
to use it.
More information about the Grok-dev