It's also interesting that in Django 1.2, they pulled away the nastiness of "ifequal" and "ifnotequal". Also, I don't buy their argument that the Django templating system is easier for "designers". Most designers whom I've worked with also do designs in other frameworks and Django's system is no more foreign than jsp, asp, or erb.

Agreed. I think they know that this is a weakness. I'd expect it to improve over time. In a similar fashion to them addressing ifequal and ifnotequal in 1.2.

Capitalization or minor string manipulation in erb doesn't require one to write a template filter function somewhere else.

Personally I'd prefer defining it once somewhere. Then use the function everywhere. Even with the initial code cost.

I think this is from past bad experiences. I once "repaired" a million plus line of code enterprise app that had misused some open source code that did date and number coercion (similar to django.contrib.humanize but for ASP). Needless to say the code was a mess and nearly the same code had been mixed in all over the place. The template code, the backend business logic and the asp C# files. After a few days of regexing then testing then fixing then searching then repeating. And then dealing with all the edge and special cases - I'll take a simple defined template function. All that being said - my example is a gnarly enterprise example involving bad code monkeys. So take it with a grain of salt - it's likely that the story isn't applicable to a lot of people here. But still - lesson learned. In the future designers can request template improvements and I'll deliver.