[Grok-dev] RFC: Making the automatic registration of templates more explicit

[Philipp von Weitershausen]

On 30 Jan 2007, at 21:07 , Kevin Smith wrote:
> Assuming that grok.autotemplates() would *not* interfere with view  
> classes in the same module, I think it's an okay compromise,  
> however...

I'm not sure what you mean by "not interfere".

Say you have foo.pt and bar.pt in the app_templates directory and  
then in app.py you have:

   grok.autotemplates()

   class Bar(grok.View):
       pass

Then bar.pt will be associated with the Bar class and foo.pt would  
become its own view. If you left out the grok.autotemplates(), there  
would only be a 'bar' view, but not a 'foo' view.

> Isn't a template without a view class just a static page in disguise?

Not sure what you mean. A template is of course still dynamic, even  
if it had no view class. It can pull in a common look and feel using  
macros and it can insert variables from the request of the currently  
viewed object (context).

> If not, and there are alot of them, doesn't that indicate too much  
> logic in the template?

Perhaps. It depends on how much you believe in the "push model" and  
how much the template can find out by itself. I certainly wouldn't  
want the templates to do any complicated computations (e.g. search  
results) by itself. Simple computations (e.g. constructing a URL)  
might still be ok.

I've certainly written quite a few templates w/o any view class in my  
time with Zope 3. Also, I often tend to *start out* w/o a class and  
only add one later if I find out I need one. And that's exactly the  
point: I don't think we should make people having to write things  
that are dead chickens at the time of writing, even if they turn out  
to be useful at some future point. The road to a flatter learning  
curve is making people only know that what they currently need, not  
what might be useful in the future.

> From a newbie perspective I agree with Martijn and company about  
> requiring a view class. It's easier to grok. That's how the  
> competing frameworks do it.

How the competing frameworks do it is definitely an indicator, but I  
weigh your opinion as a newbie higher than that. I wish more people  
like you would give such feedback.

I can see your point about explicit classes being easier to grok. You  
wouldn't mind the repetition and the "dead chickens" (empty

> Perhaps what Grok really needs to do is develop a user story for  
> static pages instead.

Well, we essentially support static pages currently. They'd be  
templates w/o any templating commands.

I wonder how much people would really need absolutely static pages to  
work with grok. In the end, you'll always want *some* dynamics, even  
if it's just for the sake of a common layout.