[Grok-dev] template association redux: module-level directives and inheritance

[Martijn Faassen]

Hey,

Jan-Wijbrand Kolman wrote:
[snip]
> The problem here is the module-level directives. The (implicit or
> explicit) information "set" with these directives is available to the
> components within the same module, but this is information is not
> "transferred" or "available" to subclasses of these components in
> another module.

It's at least good both cases give the same answer, as 'grok.context()' 
on a module-level has the default of 'find the only model or complain'.

> This is very unexpected behaviour for the general application developer
> - it is quite natural to expect to inherit all "information" from a
> baseclass.

Right, that sounds fairly natural as an expection.

> Now, I expect not too many people ran into this for grok.context(). I
> can only guess, but I *think* this is because in *practice*
> grok.context() is declared explicitely on a class-level anyway for most
> context-sensitve components in an application - and that'll work just
> fine in the light of inheritance.

I have indeed not run into this issue before.

> However now for the real problem: for grok.templatedir() there is no
> class-level equivalent. And it does not really make sense either. 

There being no class-level equivalent makes no sense? Or do you mean 
that having one on a per-class level makes no sense? I can see 
grok.templatedir() doing something on a per-class level as well as a 
per-module level.

> This means, I'm afraid at least at this moment, we cannot actually solve the
> grok.template() issue reliably as the information set by
> grok.templatedir() is crucial for finding the correct template.
> 
> Ok. So, Now What?
> 
> Well, I can see a couple of possible directions:
> 
> * We'll just give up the possibility to inherit grok.template()
> information, which means you'll have to declare grok.template() again on
> a subclass, pointing to the same template as the
> baseclass-in-another-module does. This can still be problematic if both
> modules point to different templatedirs.
> 
> * We take over, in modified form, Lennart Regebro's suggestion to
> actually use a path-like syntax for grok.template(). We can then get rid
> of the grok.templatedir() directive alltogether. Without much thinking,
> I could imagine something like:
> 
>   grok.template('mytemplates/foo')
> 
> and we can probably think of all kinds of sensible defaults for
> different kinds of path-like values.

How would the absence of grok.template() interact with inheritance?

> * We think of a fundamental solution for "inheriting" directive
> information for subclasses of components that a defined in another
> module than the baseclass.

Perhaps another fall-back level:

1) look for the directive on the class

2) look for the directive on the module

3) look for the directive on the module of the base class.

Whether 2) should come first or 3) can be debated. For backwards 
compatibility's sake 2) should at least come first.

The question would be whether we can implement 3) in Martian. I think it 
is indeed possible to check in which module a class originated. We do 
this somewhere to check whether a class is imported.

> Anyway, with all these questions still ahead of me, I hope I can make it
> in time for the grok-0.14 release with the grok.template() issue.

I think we should just assume we can't before monday, and make this one 
of the bigger items for 0.15. We don't need to delay that release very long.

Regards,

Martijn