Django Book 1.0 online
djangobook.com
djangobook.com
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.
I still adore Django for its efforts to remove all the "magic" code, though.
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/
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.
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.
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.
But not only was I unclear, in hindsight it was a total nitpick to boot. :)
http://www.kryogenix.org/code/vellum/docs/templates.html
Another one is Python Server Pages:
http://www.ciobriefings.com/psp/
(Edited to fix typo.)
What happens if there's a syntax error in the template language?
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.