[Grok-dev] solving the grok.template() bug - part B of the solution

Jan-Wijbrand Kolman janwijbrand at gmail.com
Sun Jan 11 15:35:22 EST 2009


With only slow progress I'm still working on the grok.template() issue.

Recently Martijn and I had a couple of hours to spend on this problem.
We found there to be several parts to a solution.

This is part B - making reasoning over how and why a view component gets
rendered way simpler.

Will pondering over different solutions for getting the grok.template()
issue solved, we found ourselves constantly confused over the exact
rules for rendering a view component. This is, because there multiple
mechanisms in play: a view component can have a render() method or a
template associated, where in addition, a template can be implicitely

For a single view class this is still not very hard to follow, but when
we drew a matrix of the different situations you can encounter (and thus
that had to be tested!) when subclassing view components, we found
literally dozens and dozens of combinations as a result of the seemingly
simple rules.

We concluded that situations can occur where it is very hard to reason
about how a view component is rendered - or why there is an error at
startup(!) - in the face of subclassing views. Not only that, it also
proofed to be very difficult to reason about the actual *implementation*
of these rules (once the grok.template() bug would've been fixed).

And as the Zen of Python states...

  "If the implementation is hard to explain, it's a bad idea."

...we need a simpler mechanism.

The way to simplify things *a lot* is by splitting view components that
render by way of a render() method and view components that render by
way of a template.

This has been proposed before, and at that time of the people involved
in that discussion, only one was "-1" on it.

I'd like to make the proposol again with the following two (in my
opinion strong) arguments:

  1) The implementation will be much simpler.

  2) It will be much simpler to explain how each of these views
     components work for users *with* Grok.

As for the naming, it is clear the current "grok.View" should stay and
be the view component that will have a template associated to it. The
view component that is rendered by way of a render() method can then be
called "CodeView" (Martijn, that's what we chose at that point, right?)


More information about the Grok-dev mailing list