[Grok-dev] proposal: splitting up View from PythonView
Brandon Craig Rhodes
brandon at rhodesmill.org
Tue Sep 16 09:30:57 EDT 2008
[Whoops, I sent my first response only to Martijn!]
Martijn Faassen <faassen at startifact.com> writes:
> It seems reasonable to split up these responsibilities. 'grok.View'
> would remain our normal template-associated view. 'grok.PythonView'
> (better name possible?) would become the view with the 'render'
> method, which we might decide to rewrite to '__call__' instead of
> 'render'. We can then make grok.View be a subclass of grok.PythonView,
> which implements the template association.
I might have more to say when I return home on Friday, but for the
moment wanted to throw in three ideas from here in my hotel room:
- Does this mean that, when subclassing a view, you would now be
"locked in" to generating its content the same was as the
superclass's author had? If he had used a template, you would have
to use one too, and the same with render()? If so, then I am not
sure I like this loss of flexibility; but, then, maybe we don't
inherit from views often enough to matter?
- I agree that 'PythonView' is a bad name and that 'RenderView' or
something is more appropriate. Let's think about it for a week.
- It would make Grok more complicated to use, at least for me, and more
complicated to explain. Remembering that there are two ways to use
grok.View is much easier than trying to remember the name of two
entirely different kinds of view. I probably need to read back
through the archives for the past few weeks, to try to remember how
the current behavior is causing problems.
- I *strongly* object to renaming render() to __call__(), and think it
is a horrible, horrible idea. In general, the Python __call__()
magic should only be used when writing something that wraps functions
or, for other good and obvious reasons, needs to imitate a function
call; and template rendering seems to do neither. Creating objects
that support __call__() for whatever random function they're designed
to perform is like C++ kiddies saying, "Hey! We can override 'plus'!
Let's override plus to support <some random operation that isn't
actually an addition or concatenation>." Yes, when we were young C++
kiddies, it was neat to save a few keystrokes and get to use a built-
in operator instead. But the downside is that no one could
understand our code! Removing the name of the function removes a
level of self-documentation. It is much better to expend seven extra
characters and be able to actually read a statement like:
content = myt.render()
than to be extra-obscure and say:
content = myt()
and leave everyone in the dark about what operation is being
performed until they go look up what __call__ does on that particular
kind of object.
Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon
More information about the Grok-dev