[Grok-dev] RFC: Making the automatic registration of templates
Philipp von Weitershausen
philipp at weitershausen.de
Tue Jan 30 15:40:30 EST 2007
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,
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:
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.
More information about the Grok-dev