Simon Willison’s Weblog

The part I find quite bizarre is how he considers that:

if you wanted a different presentation of a list of items depending on the length of the list, you can't just write:
[...]
Instead, you need to write your own little template tag (say {% if_length_less_than items 3 %}) , which moves the use of those unsupported language constructs into the backend Python code.

On one hand, yes of course it moves the logic into the Python backend, I don't quite see the problem with that though, you can just build a nice library and it forces you to think about what you actually need.

On the other hand, I think he's fighting against the wrong windmill: we shouldn't be able to include arbitrary Python logic anywhere in Django template, but the filters should be part of an object's identifier:

In this case, if we could just use filters inside {% if %} tags, he could just write {% if items | length | lessThan 3 %}

This would give Django templates a huge power boost without introducing much additional complexity (especially since filters are already used and custom filters already exist), and custom filters are much faster and less verbose to create than custom tags.

This would also help eliminate redundancy as you can easily compose filters by chaining (here two extremely general filters replace a single extremely specific tag).

I think that's what the members of the "Django templates aren't powerful enough" camp should be fighting for: the generalization of the filter chains to arbitrary Django tags instead of them being restricted to {{ echo }} and {% filter %}.

Masklinn - 19th July 2007 11:01 - #

The great success of PHP is at least partly down to how straightforward it is to include 'real templating code' in your pages.

Rails has a similar system that allows you to put Ruby code in your templates.

I really resent templating systems that force me to learn *another* 'little language' just to do logic - *why not* allow me to use Python rather than inventing another programming language?

Michael Foord - 19th July 2007 11:27 - #

From memory, I think the {% for %} tag supports filters applied to its arguments but the {% if %} tag doesn't. This inconsistency should probably be fixed.

I didn't know it could work with {% for %}, but i think it should probably be extended to work with any tag that allows you to access objects. That would be consistent, would allow a single-point access to the object itself (from the viewpoint of the tag library creator), and would as I mentioned give more power with a low additional complexity to the templates and template builders.

Plus it feels like haskell-style function composition, I dig that (now to replace the pipe by a dot...)

As always with Django, if you don't like the template language there is absolutely nothing to stop you from using one that you prefer - you just need to import the library and use it in your views to help generate the response object.

Well I know I quite like the django template engine, so I'd rather go extend the engine myself (and I should do it if i ever find the time to do that).

As a side note, do you think I should submit the ability to use filters in any tag to the Django bug tracker?

Masklinn - 19th July 2007 12:10 - #

it's funny, one commenter is advertising full control in templates with PHP where it was abused the most.

also, i think people who like full language support in templates probably never had to deal with monster legacy apps where even database calls were being made from templates. (you also can see that happening in more and more rails applications btw).

I honestly believe Django's templating system is as good as you can get.

it's so simple and straightforward, i would not even call it a mini language.

pk11 - 19th July 2007 20:39 - #

Probably the most used templating language in the world is XSL. One thing that annoys me about XSL is the lack of assignment capabilities. (actually, you can assign, but all variables are immutable in their context). It gets around its difficulties using recursion.

Recursion seems like an ugly hack, especially when code size can be cut by 80% simply by allowing variable assignment. (cf http://www.bearfruit.org/blog/2006/06/21/counting- with-xsl )

This isn't about XSL though, it's about django templates. I agree with Simon that it's nice to be able to have reasonable confidence that template author's aren't doing crazy stuff - I think that the templating language should be a controlled subset of a language.

However, it would be nice to have a little more power. For example, say you have a page with a complex table and you feel it would be useful to repeat the heading every 12 rows.

Or what if you'd like to sum a column in a table showing a grand total at the bottom? This is absolutely in the scope of a templating language. (it's presentation, not business logic)

It's not hard to come up with examples where additional programming-language-like features would be useful.

And even if new features are added to the template language doesn't mean it will be come less accessible. Designers will just the parts they need.

Matt Nuzum - 20th July 2007 15:06 - #

Well my comment seems to be either lost or not accepted. But let's try again :-)

Altough django is not strictly MVC (it's MTV) you talk about "strict separation of presentation logic from everything else."

The following paper aims to formalize what that means and talk about an "Entanglement Index"

http://www.cs.usfca.edu/~parrt/papers/mvc.template s.pdf

In your opinion, which is the entanglement index of django templates?

Julián Hernández Gómez - 20th July 2007 15:40 - #