Comment by adrianh | Hacker News Reader

Comment by adrianh | Hacker News Reader

Parent Full thread

Not using/allowing Python code in HTML templates is a deliberate Django design decision. We created Django in an environment where the designers didn't know Python (or much programming, in general), and it was much simpler to explain a simple template language than to teach them Python.

Aside from that, there are some nice benefits to having a separate template language. One benefit is the extra level of security -- a designer can't bring the entire site down by making a syntax error in the template. And there's the benefit that it encourages you (rather firmly!) to separate logic and presentation. In my Django applications, I'm never tempted to give templates any logic that isn't strictly presentation-related.

Then there's stuff like the template system's automatic HTML-escaping, which we just introduced in the Django development version. Sure, I guess you could do that with a pure-Python-syntax template system, but it seems like you'd end up hacking things substantially to get that to work.

And, finally, if you don't care for Django's template language, you don't have to use it. The whole framework is just Python, after all -- import whatever external libraries you want to import.

As Mike Vanier has noted (http://www.paulgraham.com/vanlfsp.html), "LFMs [languages for the masses] deliberately restrict the abstractive power of the language, because of the feeling that users 'can't handle' that much power. This means that there is a glass ceiling of abstraction; your designs can only get this abstract and no more." In this context, the Django template language appears to be an LFM. In Mike's nomenclature, embedded Ruby is an LFSP (language for smart people).

It may be that an LFM is the right design decision in some contexts. For others, an LFSP is better. For my purposes (and please forgive the pretension), I prefer an LFSP. And, while you can use an LFM in Rails (e.g., the Liquid template language), I don't see how you can use an LFSP in Django---at least, because of whitespace, not the LFSP called Python.

Well, it doesn't just appear to be an LFM, it was explicitly designed as such.

I don't think that the Python syntax is an inappropriate choice to be used as a fully enabled template language - you could bolt on <% end %> tags with a preprocessor that indents automatically pretty trivially. Such a template language just doesn't exist yet.

Read the quote again: that's the canonical definition of an LFM. It's a language that restricts the user's power, not by accident, but by design.

Sorry, I meant that the authors themselves say that it's designed as one - i.e. there's no 'appears to be' about it.

But not only was I unclear, in hindsight it was a total nitpick to boot. :)

Ah. Gotcha. Sorry for the misunderstanding.

I've seen a couple of implementations of "Python as a template language with 'end' statements" over the years. Here's one:

http://www.kryogenix.org/code/vellum/docs/templates.html

Another one is Python Server Pages:

http://www.ciobriefings.com/psp/

(Edited to fix typo.)

Thanks for the links. I wonder how long it will be until someone puts one in Django.

"One benefit is the extra level of security -- a designer can't bring the entire site down by making a syntax error in the template."

What happens if there's a syntax error in the template language?

It depends on the type of the error, but most errors fail quietly in Django templates. For example, you can pass a Python object to your template, and can reference its fields using syntax like {{ object.absolute_url }} if, for example, you tried to access a field that doesn't exist {{ object.doesnt_exist_field }} then it simply doesn't emit anything (as opposed to failing loudly).

There are a few errors in the template language that do fail loudly, and these fail when the templates are compiled (something you have the easy ability to test by simply loading the page once on a development server. Or by writing unit tests with the Django testing framework to make sure that all your urls are returning non-error response codes). Anything that has to do with the specific context of the page you are loading (the specific instance of an Object you are looking at, etc) may cause some ugliness (blank space where you wanted to print the value of a non-existant value), but the page will still load properly.

So, answering your question, there are a few types of syntax errors in the template language (loading a non-existent template library, improperly using tags or filters) that can cause errors (but all of those errors are easily testable). But the vast majority of errors will simply be ignored and normal functioning will continue.

Reply on news.ycombinator.com