[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
Hi,
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
associated.
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?)
regards,
jw
More information about the Grok-dev
mailing list