[Grok-dev] overriding Grokkers

[Fernando Correa Neto]

Hey!

On 10/19/07, Lennart Regebro <regebro at gmail.com> wrote:
> On 10/16/07, Fernando Correa Neto <fcdoth at gmail.com> wrote:
> > 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.
>
> But that would require you to have different view classes for
> different template classes, so no, it still isn't the right place.
>
> I would like to see another usecase before I make my mind up if this
> is needed or not. Normally you make a grokker because you have a class
> whose instances should all have something done to them. If that
> grokker does something that not all subclasses want done, then either
> the grokker is wrong, or you are using the subclass in a way that
> wasn't intended, IMO.

The point of subclassing from grok.View is that it was meant to be
another flavor of view and not introduce any other concepts of make it
so different than a usual view.

Creating another grokker was necessary because as I mentioned, I would
be passing template engine options through the view and thus a new
grokker is necessary to validate those options against Buffet
available engines plus the normal adapter registration, checkers etc.

I decided on getting the Buffet hooks in the View class because this
is where the zpt calls are and it wouldn't be so difficult..I wish.

I understand you've did all the work in the template level. That means
that for each template engine plugin that is already available in
Buffet, I would need to create a new megrok like you did with
megrok.genshi and many others like megrok.kid, megrok.breve,
megrok.myghty, megrok.cheetah etc, etc.

What I was actually trying to do, instead creating a new set of
separate packages to integrate the temples engines, was creating a
single megrok to would bridge the logic with the template engines that
buffet support. Because Buffet already knows how to handle that.

At this point I actually just wished that Buffet was a WSGI compliant
app so I could pass the view and handle all the template composition
in another package with a [filter-app:main] egg:buffet.bufet_factory
:D.

But yeah, I believe that having several template engines available in
grok, true for other components as well, would be awesome.
Integrating third party apps, like Buffet, without much effort is also
a good thing and shows grok extensibility.

BTW, thanks for the good work on getting megrok.genshi going. That's a
good thing :-).

Regards,
Fernando