3 ms·
Shouldn't the included templating system be the one everyone uses? Agreed. I think they know that this is a weakness. I'd expect it to improve over time. In a
by jmatt 16y ago
Shouldn't the included templating system be the one everyone uses?
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.
- catch23 16y agoWell, anyone can still write crap code with Django, it doesn't require an enterprise C# language to produce crap. Django templates still have logic that needs to be tested & debugged so the template filter functions don't alleviate all the pain either. Plus, the concept of template filter functions is available in pretty much all web frameworks out there, but it's more painful to use if the templating language forces one to write a filter function every time you need to wield the python language.