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

[Philipp von Weitershausen]

On 30 Jan 2007, at 19:59 , Jan-Wijbrand Kolman wrote:
> On 1/30/07, Philipp von Weitershausen <philipp at weitershausen.de>  
> wrote:
>> We've recently had a discussion about the automatic association of
>> templates with models. There are people who think that it bares  
>> too much
>> magic and should be done more explicitly.
>>
>> Martijn and others suggested that each fielsystem template would  
>> need a
>> view class to go with it, hence making the existence of a view  
>> class the
>> configuration knob for filesystem templates. While appreciating the
>> explicitness of this approach, I think that will produce a lot of  
>> dead
>> chickens if you have a lot of templates to publish.
>>
>> In an IRC discussion with Martijn just now, I suggested that
>>
>> * by default, filesystem templates would NOT be grokked  
>> automatically.
>> They will, however, be grokked when there's an accompanying view  
>> class.
>>
>> * you can put a `grok.autotemplates()` statement into your module  
>> that
>> will explicitly enable the automatic registration of templates  
>> *for that
>> module*. Having this statement there, the currently implemented
>> behaviour is carried out.
>>
>> With this in place, grok would only do the automation when it's
>> explicitly told to do so. I think a one-liner directive is a decent
>> compromise between explicitness and DRY. What do you guys think?
>
> Personally I do not see a huge advantage to telling people "Template
> files in the 'bar_templates' directory are automatically associated
> with module 'bar'" over having to explain "To automatically associate
> template files in the directory 'foo_templates' with the 'foo' module,
> add the line 'grok.autotemplates()' to 'foo.py'". But admittedely,
> this is based on intuition.

You're right, there isn't much difference which is exactly the point:

Both ways (the current one and the one with grok.autotemplates()) are  
easy for newbies to understand. And they let them and others like us  
get started with an application easily without a lot of extra typing.

The difference between them is that the grok.autotemplate() way  
allows us to opt for explicitness. The current behaviour does not.

> If we need a more explicit way of declaring templates for a module I
> could imagine allowing the 'grok.template' directive to be used on a
> module level. You would then get this:
>
> qux.py:
>
>  import grok
>  grok.template('fropple')
>  grok.template('frepple')
>  ...
>  grok.template('frupple')

Shrug. I would consider that quite an unnecessary repetition of  
grok.template(). Heck, you know what I'd end up writing to end the  
repetition? This:

   here = os.path.dirname(__file__)
   for file in os.listdir(os.path.join(here, __name__ + '_templates')):
       if file.endswith('.pt'):
           grok.template(file[:-3])

And then, because I would need it a lot, I'd end up putting this into  
a reusable function, and voila, we got:

   grok.autotemplates()

And if I didn't do this, others would (if they chose to adopt grok in  
the first place).

>  class Qux(grok.Model):
>    pass
>
> Sure, if you have dozens of template-only views, you would have dozens
> of 'grok.template(...)' declarations in the module. However, this
> would, IMHO, still be readable just fine, allow for fine grained
> control over what templates are associated without the
> dead-chicken-ness of having a view class per template.
>
> But probably you considered this option in the IRC discussion already?

We haven't, but IMO it doesn't provide a *that* much nicer  
alternative to the explicit classes for each template. In fact, if we  
went for a completely explicit approach, then I'd prefer the classes  
because they're better to start out with when you realize you want  
additional logic in your template (because then you'd have to write a  
class anyway).

I mean, if you *want* fine-grained control, you don't *have* to use  
grok.autotemplates()...