[Grok-dev] overriding Grokkers
Fernando Correa Neto
fcdoth at gmail.com
Tue Oct 16 10:46:48 EDT 2007
On 10/16/07, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
> Fernando Correa brought the following use case for Martian to my attention:
> * we have a grokker defined for some class inside Grok
> * we want to define a subclass for this class
> * we want there to be a grokker for this subclass
> * we *don't* want the grokker for the base class to do any work
> (I hope I got it correct)
Yeah this is correct.
> The questions up for discussion is now:
> * is this a valid use case at all? We can argue that of course the
> grokkers for base classes should kick in. Normally when you subclass the
> behavior of the base class is still intact, why do it differently with
To be honest it was quite easy to break.
But I agree there are scenarios where you want grokkers to grok all
subclasses of the component class it groks because sometimes you are
just adding few more convenient methods for your new subclass and the
original grokker is enough for the setup.
OTOH, sometimes you add some more stuff that you need to check in the
grokker and the original grokker won't be enough.
> * in what kind of concrete implementation scenarios is this necessary?
In my case, I needed to add more behavior to a grok core component and
it wasn't possible due to this limitation.
So I think we should have a standard way for "extending grok".
> * are there alternative possible solutions to these problems?
Yes. Base classes for core grok components without grokkers registered
for it is an alternative like Leornado suggested.
Another solution is too add some kind of strategy in Maritan so it
decides what to do like you say below.
> I can imagine a rule for Martian like this:
> If you have grokkers A and B, where B is a subclass of A, and we have
> classes X and Y, where Y is a subclass of X, and A groks X and B groks
> Y, we don't want grokker A to kick in as well, as it indirectly kicks in
> being a superclass of B.
> Rules like this might be complicated to follow though, so I'm not sure
> about it. Opinions?
> Alternatively we could introduce some directive to control this:
> If this is defined on your grokker, it will be the only grokker for that
> object. This may be a bit excessive though - you might block off too
> many grokkers for your own good this way.
> In order to figure out whether any of this is necessary we really need
> to be specific and concrete about our use cases first. Fernando, could
> you try to spell this one out again? Not just what you're trying to do
> in code, but also why you're trying to do it, and what your final goal
> is that you try to accomplish.
Before the Neanderthal sprint I started some work to integrate
universal template system through Buffet which is used by Pylons.
That means that I wanted to accomplish something like:
Where megrok.buffet.View subclass grok.View.
Why I decided to do it with grok.View? Because this is where it calls
the zpt and renders it so I thought wiring up buffet code in there
would be the right place.
This would interpret app_tempates/index.pt using kid engine, which of
course would not work because kid wants a index.kid and I would need
to talk to temlatereg first and add some more configuration so it
So I assume grokker is needed here to do all kind of checks like
checking if the template engine is available in buffet and possibly
making associations with templatereg. I am not sure about the
templatereg itself because I didn't go that further on it.
My motivation to get another grokker is quite clear:
Setup the template engines and possibly do all sort of magic to get
the index.pt or index.kid going.
I can think about another scenarios when you need to create some
conventions for say, megrok.storm for example and you'd need to do the
same sort of operations like I was trying to do in my use case.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev