[Grok-dev] template association - suboptimal magic?

[Martijn Faassen]

Hey JW,

Thanks for doing this analysis!

Jan-Wijbrand Kolman wrote:

> My sugestion is basically to make the template association simpler by
> making it more explicit and use less magic. Let try to sketch out the
> "rules":
> 
> * The grok.template() directive can be used on a (view) component.
> 
> * By absence of the grok.template(...) directive, the component's
> grokker decides what to do. Most likely is to require the component to
> have a render() method instead.

I'd say for backwards compatibility's sake alone we'd need to generate 
the template name based on the class name. It's a bit weird also to 
require the implementation of render() if and only if a directive is not 
there. The general idea about directives is to have some default 
behavior as much as possible by default. Requiring grok.template() if 
you want to use a template at all means a lot of 'grok.template()' 
everywhere, which I hope can be avoided.

I'd rather have it pick up 'render' when it is there by itself.

> * The grok.template() directive sets a template name explicitly:
> 
> class ViewA(grok.View):
>   grok.template('sometemplatename')
> 
> * The grok.template() directive can be "empty" (i.e. no explicit value
> is used). In that case it is the component's classname, lowercased, that
> is used for the template name:
> 
>   class ViewB(grok.View):
>     grok.template()
> 
> Would be equvalent to:
> 
>   class ViewB(grok.View):
>     grok.template('viewb')
> 
> * The grok.template() directive does a lookup for the template file
> corresponding to the template name. The directive implementation stores
> the filename:
> 
>   * It looks for this file in a directory named according to the
>     module name or as explicitley defined by a grok.templatedir()
>     directive in this module.
> 
>   * When it cannot find a template file, or when it finds multiple
>     files (i.e. with different extensions) it issues an error.
> 
> * The (view) component grokker can take the value (filename) from the
> grok.template() directive and take appropiate action (e.g. like looking
> up the template factory utility or checking for a render() method).
> 
> You might notice that there's no registry in play here, still most of
> the "exepected" current behaviour is still there and the afformentioned
> bug is solved.

It sounds like a good plan!

> There's also something that is lost: templates defined in modules. These
> templates need a registry of some sort, since at the time the
> grok.template() directive is called, such a template might not yet be
> defined.
> 
> Now, let me make a wild guess and a blunt statement about templates
> defined inside modules: I don't think anyone is using them for real in
> applications, so let's get rid of them.

They're nice for demonstration purposes as everything can be done in one 
file. I do agree that they're not that useful in practice, however.

> There's another thing that I didn't cover: Although not essential it is
> really nice to report about templates that are not used at all. This
> helps the developer keep his codebase clean. I think the
> grok.templates() directive could keep a global list of templates
> filenames and check, late in the grokking process, whether all template
> files that can be found for the application actually are used at least once.

Do you mean the 'grok.template' directive (without 's')?

> Words of warning:
> 
> I found the current template association not very easy to follow, so I
> might be overlooking essential elements - esp. since I couldn't let go
> of this topic for the whole day and it is getting a bit late in the
> evening by now.
> 
> Also, I have no code yet that illustrate these ideas. I would be willing
> to work on this code though. I also realize that it would not be a small
> change in grokcore.view and it is already released as 1.0... 

> Thoughts?

We shouldn't be afraid of doing large changes. I think with the 
modification I gave above, we can make this largely backwards 
compatible. Since it also sounds like things will be simplified, that's 
good.

It also gave me the idea that perhaps a grok package can have some kind 
of special module that contains global configurations that apply to 
*all* modules in a package, similar to the way module-level directives 
are inherited by individual classes. You could configure a default 
'grok.templatedir' in there then, and perhaps it would also be useful 
for other purposes. That said, if you were to use that in your project 
the template association behavior would suddenly change quite a bit.

Regards,

Martijn