[Grok-dev] Re: should we support a "namespace()" View method
Martijn Faassen
faassen at startifact.com
Fri Oct 12 07:59:28 EDT 2007
Brandon Craig Rhodes wrote:
> Idea: when rendering a View (that lacks a render() method, of course),
> the Grok code that hands data to the template should check for whether
> the View has a namespace() method. The rule would be:
>
> - If a namespace() method exists, it is run, and the object it
> returns is made the root of the template's name space.
>
> - If no namespace() method exists, then the default is for the
> namespace to be the dictionary:
>
> { 'context': view.context, 'view': view, 'template': ..., ... }
>
> and so forth, that contains all the same things we hand ZPT files
> when using Grok today.
I believe Lennart and Guido's branch to enable template pluggability
already supports this method (we did discuss this at the sprint). I'm
not sure what it's called, but I'm sure Lennart could elaborate.
> - Should update() be called if namespace() exists? It seems to be
> that one would write each View with either an update() or a
> namespace(), but not both, so I am not sure what we should do in
> the presence of both functions.
Update has other uses than just set local view variables, so yet, it
should be called. It's simple enough to just not put in an update if it
has no meaning.
> - Should namespace() return a dictionary, or a dumb object with
> attributes? Can we support "pretty" traversal of both kinds of
> data structure? Having namespace() be a big "return" statement of
> a big dictionary has certain attractions, but not if that means my
> Genshi templates are full of ['xyz'] dictionary attribute
> references instead of simple .xyz attribute references.
A dictionary is more compatible with ZPT and with Genshi, as far as I
understand, so this method should be returning a dictionary. Once we run
into a template language that can't deal with this, we'll rethink.
Concerning Genshi templates: Genshi magically makes a.foo mean a['foo'],
so there is no problem with a dictionary there.
Regards,
Martijn
More information about the Grok-dev
mailing list