Am 13.03.2013 14:56, schrieb Robert:

About uglifying the API, I think if I needed to do this, I would just derive from implementing class and override the method instantiating the vibe template. Wouldn't this work?

In particular, in my code I ended up wrapping Diet templates in rendering functions. This way I got an explicit interface to the template (the function signature), which I can document with DDoc comments. That is also why I like the new compileDietFileMixin, as I already have my interface explicit via the functions parameters, so having to pass over values explicitly twice seemed like a wasted effort. I basically considered the template as a part of the function, just at a different place. The reasons I did this:

  • I get an explicit interface, which can be documented.
  • I can put display related D code into the D function before instantiating the template.
  • If I wrote a reusable component, I can customize it by simply overriding the rendering functions. (No need to override Diet templates)

-> An additional benefit: This way it is possible to use multiple variants of the component in the same code base.

So basically the fact that the rendering happens via a Diet template got an implementation detail, that is hidden from client code.

Okay what I meant with overriding was more in cases where you have a
layout.dt that is extended by another template. In a derived project you
then want to use a different layout.dt. This is out of reach of any
object oriented features or whatever means.

Now if it weren't for staying compatible with Jade I would simply extend
the Diet template syntax with explicit parameter declarations so that
proper type checking can be done at the call site (and possibly
automatically generating a proper function or another alternative kind
of interface).