6 ms·

I subscribe to the view that the template language is for designers and should only allow safe constructs. As someone who does both design and programming,

by samdk 16y ago

I subscribe to the view that the template language is for designers and should only allow safe constructs. As someone who does both design and programming, I hate template systems that do this with a passion. I don't want to have to learn another language just so I can write templates. Especially when that language makes me jump through hoops to do various simple tasks the designers didn't anticipate--which is the case with every such language I've used. Erb is one of the nicer templating systems I've used. I've never had any trouble getting it to do exactly what I want it to do, and I've never had it behave in a way I didn't expect--which is another advantage to having it just use Ruby. It doesn't have anything on Haml, though.

stonean 16y ago
I wrote something, better described as an attribute language, that fits the idea of a 'template language is for designers' called RuHL. http://docs.stonean.com/page/ruhl http://docs.stonean.com/page/ruhl
tene 16y ago
This is one of the reasons I'm fond of Perl's Template::Declare. It's a declarative syntax for generating HTML that's still just plain Perl. http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Template/Declare.pm http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Tem... I certainly understand the use case of more-limited and embedded template languages, for working with designers or people less-comfortable with actual programming, or whatever, but when I'm just working on my own, or only with other programmers, Template::Declare works so much more nicely for me.
- zbrock 16y ago
  There's a ruby equivalent that's pretty nice called Erector: http://erector.rubyforge.org/ http://erector.rubyforge.org/ http://pivotallabs.com/users/alex/blog/articles/1029-why-wouldn-t-you-use-erector- http://pivotallabs.com/users/alex/blog/articles/1029-why-wou...
catch23 16y ago
It's funny the author put templating as one of the things he dislikes about rails, especially when the Django templating system is probably one of the worst (of all templating systems out there). They invented their own pseudo language for templating so anything more complicated requires you to write your own special helper functions. I remember back in Django 0.9 (which is still fairly recent), I had to write template library code to do a nested loop over a data structure. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? Every time I use django templates, I have to look up documentation on how to do something as simple as string/number comparison. When I write Myghty templates, I'm writing python on top of html and it just feels so much nicer this way.
- jmatt 16y ago
  I agree this was frustrating initially. After a certain number of django projects most of the django devs I know use the heck out of it's modularity. If the templating system is driving you insane drop in Jinja2 and go. If it just needs to be tweaked then implement the template command yourself. I felt confined and frustrated with Django until I realized that it was built with the intention that developers should just crank code on top of it. And not just page code - anything that you need. It's more than just an end product that is just configured, tweaked and templated. Of course ruby similar in the same way... But in comparison to java and .NET web frameworks this was a big change. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? I think they were trying to get away from the horrid nastiness that had become php or before that cgi. Yet they still wanted to provide options for designers. It definitely has a learning curve and requires the programmer to just roll with it and adopt the "django way". At least until you figure out you can just move to another templating system. http://docs.djangoproject.com/en/1.2/howto/custom-template-tags/ http://docs.djangoproject.com/en/1.2/howto/custom-template-t... http://docs.djangoproject.com/en/dev/ref/templates/api/#topic-template-alternate-language http://docs.djangoproject.com/en/dev/ref/templates/api/#topi... http://djangosnippets.org/snippets/2063/ http://djangosnippets.org/snippets/2063/
  - catch23 16y ago
    Shouldn't the included templating system be the one everyone uses? It doesn't make sense to include a templating system if everyone will eventually just replace it with something better. Even though there are alternative rails templating systems out there, I would say a good 80% of the projects out there use the default "erb" mechanism for templates -- it's simple, it's ruby, and it works. Capitalization or minor string manipulation in erb doesn't require one to write a template filter function somewhere else. 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.
newaroundhere 16y ago
I think there are two valid approaches here, depending on the project. One project I'm currently involved with has a team of content/design people who work on Django templates - giving them more power with a template engine like Jinja2 or Mako would introduce nightmares. On the other hand, when I'm building my own applications the Django template engine seems ridiculously bureaucratic, when I just want to drop in a Python function without reams of template tag boilerplate. That's one of the main reasons why I prefer Flask/Jinja2 for my side-projects (well that, and SQLAlchemy).

by samdk 16y ago

stonean 16y ago

I wrote something, better described as an attribute language, that fits the idea of a 'template language is for designers' called RuHL. http://docs.stonean.com/page/ruhl http://docs.stonean.com/page/ruhl

tene 16y ago

This is one of the reasons I'm fond of Perl's Template::Declare. It's a declarative syntax for generating HTML that's still just plain Perl. http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Template/Declare.pm http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Tem... I certainly understand the use case of more-limited and embedded template languages, for working with designers or people less-comfortable with actual programming, or whatever, but when I'm just working on my own, or only with other programmers, Template::Declare works so much more nicely for me.

zbrock 16y ago
There's a ruby equivalent that's pretty nice called Erector: http://erector.rubyforge.org/ http://erector.rubyforge.org/ http://pivotallabs.com/users/alex/blog/articles/1029-why-wouldn-t-you-use-erector- http://pivotallabs.com/users/alex/blog/articles/1029-why-wou...

catch23 16y ago

It's funny the author put templating as one of the things he dislikes about rails, especially when the Django templating system is probably one of the worst (of all templating systems out there). They invented their own pseudo language for templating so anything more complicated requires you to write your own special helper functions. I remember back in Django 0.9 (which is still fairly recent), I had to write template library code to do a nested loop over a data structure. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? Every time I use django templates, I have to look up documentation on how to do something as simple as string/number comparison. When I write Myghty templates, I'm writing python on top of html and it just feels so much nicer this way.

jmatt 16y ago
I agree this was frustrating initially. After a certain number of django projects most of the django devs I know use the heck out of it's modularity. If the templating system is driving you insane drop in Jinja2 and go. If it just needs to be tweaked then implement the template command yourself. I felt confined and frustrated with Django until I realized that it was built with the intention that developers should just crank code on top of it. And not just page code - anything that you need. It's more than just an end product that is just configured, tweaked and templated. Of course ruby similar in the same way... But in comparison to java and .NET web frameworks this was a big change. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? I think they were trying to get away from the horrid nastiness that had become php or before that cgi. Yet they still wanted to provide options for designers. It definitely has a learning curve and requires the programmer to just roll with it and adopt the "django way". At least until you figure out you can just move to another templating system. http://docs.djangoproject.com/en/1.2/howto/custom-template-tags/ http://docs.djangoproject.com/en/1.2/howto/custom-template-t... http://docs.djangoproject.com/en/dev/ref/templates/api/#topic-template-alternate-language http://docs.djangoproject.com/en/dev/ref/templates/api/#topi... http://djangosnippets.org/snippets/2063/ http://djangosnippets.org/snippets/2063/
- catch23 16y ago
  Shouldn't the included templating system be the one everyone uses? It doesn't make sense to include a templating system if everyone will eventually just replace it with something better. Even though there are alternative rails templating systems out there, I would say a good 80% of the projects out there use the default "erb" mechanism for templates -- it's simple, it's ruby, and it works. Capitalization or minor string manipulation in erb doesn't require one to write a template filter function somewhere else. 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.

newaroundhere 16y ago

I think there are two valid approaches here, depending on the project. One project I'm currently involved with has a team of content/design people who work on Django templates - giving them more power with a template engine like Jinja2 or Mako would introduce nightmares. On the other hand, when I'm building my own applications the Django template engine seems ridiculously bureaucratic, when I just want to drop in a Python function without reams of template tag boilerplate. That's one of the main reasons why I prefer Flask/Jinja2 for my side-projects (well that, and SQLAlchemy).