[Grok-dev] Why must a CodeView have a render() method?

Martin Aspeli optilude+lists at gmail.com
Sun Jul 12 21:01:23 EDT 2009

Jan-Wijbrand Kolman wrote:
> Martin Aspeli wrote:
>> Hi,
>> I often use views that are not browser pages, i.e. they are not meant to 
>> be published, but contain utility functions looked up by traversal in 
>> other contexts (e.g. conditional expressions).
>> I had thought this was one of the use cases for a 
>> grokcore.view.CodeView, but I guess not, since it requires a render() 
>> method.
> I'm sorry, but no, that's not the use case. Its mere existence is to be 
> able to have views that not use a template to render content versus 
> views that have a template, without the complex, hard to explain 
> stratetgy for finding an implicitely or explicitely associated template 
> and checking there's no render() in that case that we had before.

Right. Then I think the name is confusing. But hey, let's not have that 
debate. ;)

>> Would it make sense to either relax this requirement, so that a CodeView 
>> without a render method can still be looked up but can't be published 
>> directly? Or maybe to add some other kind of base class for this use case?
> I looked up a thread of quite a while ago where we discussed this before.
> Even after re-reading the thread some nuances for such a component are 
> not completely clear to me. I would in any way encourage to write a 
> megrok.* package to extend Grok with such a component! Eventually this 
> component could then go into "core" Grok of course.

Erm, it's pretty straightforward, I think. Just don't implement __call__ 
and don't have any required attributes (in particular, don't require 
render) and don't look for a template.

For an example, look at 



Lots of templates do things like 

One thing to note: you need to be able to declare security on the 
methods, so that they're publicly accessible.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Grok-dev mailing list