[Grok-dev] Re: first thoughts on "regebro-guido-templates"

Brandon Craig Rhodes brandon at rhodesmill.org
Thu Nov 1 11:22:25 EDT 2007


"Lennart Regebro" <regebro at gmail.com> writes:

> Having the html parameter in the call for a for a template file
> factory also seems silly. We need a better solution for this. Until
> that, I'm -1 for merging the inline and template classes.

In other languages - but this might not be Pythonic? - one would
provide class-method constructors that could each satisfy a different
factory interface, without extra (and thus "silly") parameters.  Like:

    class GrokFileTemplate(...):

        @classmethod
        @directlyProvides(IFilePageTemplate)
        def from_file(cls, path):
            ...

That way one does not wind up creating an entire class, just to give
it a single __call__ method.  That's what functions are for. :-)

You might object (though I myself don't know if this is the case) that
Grok cannot grok methods and turn them into utilities, only classes;
and that therefore my one-class suggestion will require either a full
grokker or a post-grokking action for page template engines.  My own
preference, in response, is that we ought to have a little grokker or
post-grokking action for this anyway, because I am fuzzy on why it's a
good idea for grok.name() to declare an extension.  If I were king, :-)
someone plugging in a template would just write something like
(assuming they're plugging in the ZPT):

    class MyTemplateForGrok(grok.PageTemplateBase):
        extension = 'pt'

        def build_from_file(self, path):
            _prefix, filename = os.path.split(path)
            self._template = PageTemplateFile(filename, _prefix)

        def build_from_string(self, source):
            self._template = PageTemplate()
            self._template.write(source)

        def render(self):
            return self._template.render(self.namespace())

Per earlier discussions, they could provide a default namespace()
that's different than the Zope namespace, but both would be ignored if
the user provides .namespace() on the view.

And: then, having settled on the above as being an appropriately
attractive way to have people plug in templates, that provides exactly
the information they need and no more, I would write whatever
inherited methods, pre-grokking actions, post-grokking actions, or
grokkers as were necessary to turn the above into both the working
template class for Grok to use, and the utility necessary for Grok to
recognize files with the given extension.  I imagine that all
subclasses of PageTemplateBase would simply inherit its "from_file()"
classmethod, and could register it as a named utility with
"cls.extension" as the utility name; but other simple schemes could be
suggested.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Grok-dev mailing list