[Grok-dev] proposal: splitting up View from PythonView

[Brandon Craig Rhodes]

[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