Django snippets: Smart {% if %} template tag | Hacker News Reader

Django snippets: Smart {% if %} template tag

djangosnippets.org

25 pointsjacquesm13 comments

This is good. Of course, this is how the if tag should work in django to begin with.

agreed. The 'crippling' has gone a bit too far I think, I can see the reason why they want to limit what you can do within a template but to not have the ability to combine expressions gets tedious really quickly.

The argument seems to be that a template designer should not be able to break the site, that's not a very strong one because after all any brace or % sign removed will break the site just fine.

I'm not entirely sure how

    {% if a == b %}

will break the site, but

    {% ifequal a b %}

will not. Maybe if someone destructively overloads __eq__?

I figure if I were a template designer I would treat anything between { and } as if it were radioactive.

ifequal uses __eq__ anyways.

Agree. Seriously, don't know what they're waiting to commit this to the trunk. IMHO the template system in Django is too restricted and should get some steroids, despite the designer point of keeping it simple. I think you can get the best from both worlds.

I think part of the resistance here is that rolling this in to trunk would be an admission they got it wrong in the first place.

There is a lot of psychology behind the scenes in open source projects.

In big companies this can express itself as NIH and other symptoms like that, in open source projects it usually means that sooner or later somebody admits they were wrong in the past or that a project will fork or that there will be 'unofficial' patches.

The python absence of a 'switch' statement is another nice example of such an issue.

The absence of 'switch' seems reasonable - it's pretty rare that you need a switch, so is it really worth introducing another keyword?

I'm not so sure the problem comes down to a fear of admitting getting it wrong in the first place, as much as it is a desire to hold tightly to a rule for template design that the creators feel has served Django well (keeping the templates simple). When it comes to your own rules, everyone is a little afraid of the dreaded 'slippery slope', no?

For the record, I agree that something this basic should be built in to Django. I certainly use it often, I'd be a bit surprised if its use wasn't common in the Django community.

> keeping the templates simple

That's the whole point here, isn't it?

They're keeping the language simple at the expense of making the templates more difficult to read and less efficient.

There is no slipperly slope here, only in the eyes of those who want to present it that way. It's a simple design flaw that has been kept in its place against a fair bit of community pressure.

There are other issues like this, for instance at the ORM level, have a look here for a fine example of that, you won't even have to leave this site:

http://news.ycombinator.com/item?id=523661

If it is broken, and people put up very solid arguments for it being broken the idea is to fix it, not to come up with all kinds of arguments 'why it isn't broken'.

What is broken or not depends on your use case. If you ORM or template language forces people to twist themselves in to all kinds of weird shapes to jump through your hoop you should make life easier for them, even if your personal experience is different. It's a matter of viewpoint, and by playing 'dictator' you are making life harder for others.

Before you go reading hidden motivations into the design of Django's template language, I think you should read Jacob's explanation of his approach to templating:

http://jacobian.org/writing/salt/

Personally, I'm inclined to agree with him, and I take a stance similar to what's expressed in one of the comments there: it's better to leave a potentially-good feature out, but provide the means for people to implement it when they need it, than to burden the language with a potentially-bad feature that's hard to disable.

If you have an if, and ifequals and their functions are such that if you need to do a combined if something and something > somethingelse you have to resort to either duplicating a bunch of code or including small fragments of html in order to avoid the duplication severely decreasing readability then your design is simply lacking.

There is an outstanding ticket on adding boolean functionality to the ifequals conditional. The argument that others 'should learn to cook' can be countered with that if you're a cook you should cook what people like to eat, not to dictate your taste to others.

The if, ifequals and other animals in the conditional zoo could be replaced with a single multi purpose and powerful if statement such as listed in the link above.

You either have an if or you don't, if you have one it might as well work.

There is not much 'bad' about an if statement that would be worse than the endless duplication of template code that the current construct forces you to adopt.

This is a problem because any django apps that are going to be released using the more powerful 'if' statement will immediately have an extra dependency.

I have yet to see a single good argument about what would be so dangerous about having a more powerful if statement in the template language.

I wound up ditching Django templates for Jinja 2 in my app engine sites. No regrets. There was just enough irritation with Django templating issues (e.g., the if implementation, filter arguments) that I swapped in Jinja. This article has been posted before but I figure it's pertinent to the OP:

http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-an...

Reply on news.ycombinator.com