Django Book 1.0 online(djangobook.com)
djangobook.com
Django Book 1.0 online
http://www.djangobook.com/en/1.0/
19 comments
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.
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.
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.
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. :)
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.)
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.
[deleted]
"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?
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.
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.
I like not having a lot of heavy code inside my templates. The only stuff I do there is displaying values, formatting, and some simple logic. Isn't this one of the core principles of MVC?
Exactly. Having a "watered-down template language" is a good thing.
[deleted]
The problem is arguably that the indirection is really, really costly. Just today I wrote a custom template tag I needed in order to factor out some functionality common to every view on my application. In RoR it would have been maybe 2 lines, but that custom tag was more like 15.
I still adore Django for its efforts to remove all the "magic" code, though.
I still adore Django for its efforts to remove all the "magic" code, though.
There are advantages to both approaches. Obviously as you suggested, only using indentation makes templating more difficult than have an 'end' delimiter. But for the 90% of code that I write which isn't an HTML template, it is pretty nice to be able to not have extra ends all over the place.
But, if it is that big of a deal to you, it really is a solved issue in Python. Mako is Python in a templating language with the extra ends to make it work. Another language which is all-Python and I think pretty elegant is Breve. It uses s-expressions to do the job.
Using Mako with Django would really be very simple. I think the main reason the Django developers use Django is not so much because they don't like Python but because they are very strict about separation of display logic and business logic. Django's templates really are meant for designers, not programmers. That isn't totally appropriate in all contexts, but like I said, using Mako with Django should only be a matter of writing a few wrapper functions.
http://www.makotemplates.org/ http://breve.twisty-industries.com/
But, if it is that big of a deal to you, it really is a solved issue in Python. Mako is Python in a templating language with the extra ends to make it work. Another language which is all-Python and I think pretty elegant is Breve. It uses s-expressions to do the job.
Using Mako with Django would really be very simple. I think the main reason the Django developers use Django is not so much because they don't like Python but because they are very strict about separation of display logic and business logic. Django's templates really are meant for designers, not programmers. That isn't totally appropriate in all contexts, but like I said, using Mako with Django should only be a matter of writing a few wrapper functions.
http://www.makotemplates.org/ http://breve.twisty-industries.com/
The collaborative way this book was made is quite impressive. More books should be wikis or blogs in their infancy.
That color scheme still has got to go. Django needs a design that at least approaches reasonable aesthetic sensibility.
But eventually I realized that whitespace is an Achilles heel in one context: using Python as an HTML-embedded template language---unfortunately, a very important case. Seeing this Django book, and finally understanding how they solved the template-language problem with Python, appears to confirm this intuition. They solve it the same way all Python frameworks solve it: they introduce a separate, template-specific language.
This is one big reason why I love Ruby, and Rails. Because Ruby uses an "end" keyword, it works great as an HTML-embedded language. This means that, in Rails, you always have a full-strength language at your disposal, and never have to use a watered-down template language.
It's possible that Django is awesome nonetheless---it does seem to be attracting some first-rate hackers---and I could certainly be convinced to switch, but being able to use embedded Ruby will keep me firmly in the Rails camp for the time being.