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

[Kevin Smith]

Philipp von Weitershausen wrote:
> 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.
>
That's what I meant :)


>> 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.
>

I think Grok would benefit from more template choices, Zope's marriage 
to ZPT is dangerous and possibly deadly for a project like Grok. 
Developers like choices, even in php/asp land they have lots of 
choices.  To do so means template neutrality and perhaps supporting an 
open template api like Buffet. http://projects.dowski.com/projects/buffet

Here's a sample:

class Root(object):
    @cherrypy.expose
    def multi_test(self):
        return (
                ('head', # template name
                    dict(title="Composition Test") # data for template
                    ),
                ('body', # and so on ...
                    dict(message="Thanks to Bill Mill")
                    ),
                ('foot', {}
                    )
                )


>> 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
>
I take Grok as a mission statement. I expect grok.View to be a view and 
it is.


>> 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.
>
Agreed.