Django Book 1.0 online

http://www.djangobook.com/en/1.0/

by nickb • 19 years ago

44 17 19 years ago

The collaborative way this book was made is quite impressive. More books should be wikis or blogs in their infancy.

downer• 19 years ago

That color scheme still has got to go. Django needs a design that at least approaches reasonable aesthetic sensibility.

mhartl4• 19 years ago

Python was the first language I ever loved. And I've defended it, and especially its whitespace for block structure, more times than I can count. (One Perl programmer I know can't mention Python without describing it as "that whitespace language", and I couldn't understand why until I saw some of his, ahem, "creatively indented" Perl code. I'm so anal about indentation that I really never noticed.)

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.

staunch• 19 years ago

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?

bdr• 19 years ago

Exactly. Having a "watered-down template language" is a good thing.

tel• 19 years ago

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.

AF• 19 years ago

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/

adrianh2• 19 years ago

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.

mhartl4• 19 years ago

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.

simen• 19 years ago

"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?

Django Book 1.0 online

Related Stories