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

Jan-Wijbrand Kolman janwijbrand at gmail.com
Thu Sep 25 08:03:51 EDT 2008


Hi,


I'm fighting some mystical dragon here: each time I chop off one of the
grok.template()-issue's heads, two new heads appear...


Now I find myself with the following rather fundamental issue with
module-level directives in the light of inheritance.

Consider example 1):

module foo.py:

  import grok

  class FooContent(grok.Model):
    pass

  class FooViewOne(grok.View):
    def render(self):
      return u"A view for FooContent"

module bar.py:

  import grok
  import foo

  class FooViewTwo(foo.FooViewOne):
    def render(self):
      return u"Slightly different view for FooContent"

Question: What context will grok find for FooViewTwo?

Answer: It won't find a context and it'll complain.


Example 2):

module content.py:

  import grok

  class FooContent(grok.Model):
    pass

module foo.py:

  import grok
  import content

  grok.context(content.FooContent)

  class FooViewOne(grok.View):
    def render(self):
      return u"A view for FooContent"

module bar.py:

  import grok
  import foo

  class FooViewTwo(foo.FooViewOne):
    def render(self):
      return u"Slightly different view for FooContent"

Question: What context will Grok find for FooViewTwo?

Answer: It won't find a context and it'll complain.


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.

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

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.

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

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


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.


regards,
jw




More information about the Grok-dev mailing list