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

[Lennart Regebro]

On 10/29/07, Martijn Faassen <faassen at startifact.com> wrote:
> Actually this is somewhat attractive for inline templates for another
> reason - inline templates tend to grow a larger and larger list of
> arguments

Oh?

> I'm not sure I understand this approach.
>
> As far as I know, this wouldn't stop instances being imported from
> another module being grokked as well.

Sure, but is that a problem? We can make sure we only Grok them once,
and then this would only be a problem if they are imported from a
module that is not being grokked.

That said, I'm all for making the templates explicit on the views. I
find that approach much easier to understand anyway. Maybe that's a
Zope3 damage, but that's what I expected initially.

> I like approach C best. If other people like this, I'd suggest we don't
> wait for this to get implemented though before we merge the branch. It's
> only a small blemish we can live with for a while to have to add in that
> silly line.

+1

> This sounds attractive! Just one class would definitely be better than
> having to do two. How to go about collapsing this? Lennart, does this
> look doable?

Sure. Today inline templates take typically just one parameter, the
html, while file templates take two, the filename and the prefix.
We'd have to make the single class take all three and also make them
keyword parameters.

I suggest we standardize on

    def __init__(html, file=None, prefix=None):

Since the file instances are initiated from the template registration
class which is unique per template class, it's not actually necessary
to have a standard, but I think it would be good for clarity.

> In order to get this merged, I'd suggest we prioritize as follows:
>
> * single-class approach - would be nice to do this before merge if this
> is doable with a moderate amount of work. This would make the extension
> story that much cleaner and clearer.

OK, I'll try to get that done this week at least.

> * make grok.template() understand instances so we can get rid of
> __grok_module__ requirement: would be nice but could be done at a later
> stage. We need to examine the consequences of this.
>
> * namespace() situation - I think the design is flexible enough to work
> with now. If these are minor changes, by all means. But let's not go too
> deeply into the philosophy of this stuff before we gain a bit more usage
> experience and integrate a few more template languages and examine the
> use cases then. Interesting candidate languages that might exercise our
> pluggability a bit more: Mako, Templess, XSLT

I think the situation as it is now is pretty OK, but I would like to
make one change. I would like the template namespace() to be
responsible for both creating the default namespace, and updating it
with view.namespace().

It's just a matter of moving the namespace.update(view.namespace())
from one method in the template to another, and hence no big
improvement in many cases, but I find it clearer, since the render
method gets much cleaner:

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

Basically, it goes from three lines to one, while the namespace method
goes from 6 to 7. It's silly to count lines, but... yeah, it just
feels...cleaner. :-)

-- 
Lennart Regebro: Zope and Plone consulting.
+33 661 58 14 64