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

[Jan-Wijbrand Kolman]

(wraaah - forgot to reply to the list... sorry.)

On Mon, Sep 15, 2008 at 2:34 PM, Martijn Faassen <faassen at startifact.com> wrote:
> In the discussion with template assocation I realized that the magic
> rule that views currently have concerning 'render' and template
> association is perhaps a bit too magic.
>
> 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.
>
> It would break backwards compatibility, but not in a very complicated
> way. The ViewGrokker could look for render methods and issue an error
> message when it finds one, at least initially. The thing the developer
> will then have to do is rename render to __call__, and grok.View to
> grok.PythonView, a shallow operation.
>
> What do people think?

Yes please.

Frankly, when you first suggested this I thought it would not be a
good idea, but the more I tried to come up with reasons "to not split"
the more I found reasons to actually "do split" these views...

It would BTW make the grok.template() situation I'm trying to fix on
much, much, much simpler... I'm breaking my head right now how to
implemented the suggestion in the current un-split situation in a
reasonable way.

I do not really like "PythonView" - but I'm not relegious about it
either. Let's see if I have any alternatives:

class RenderView():
 pass

class CallableView():
 pass

class PythonScript():
 # /me hides around the corner.
 pass


regards,
jw