Dagblastit

Separate logic from presentation

We see a template system as a tool that controls presentation and presentation-related logic – and that’s it. The template system shouldn’t support functionality that goes beyond this basic goal.

If we wanted to put everything in templates, we’d be using PHP. Been there, done that, wised up.

Couldn’t agree more.

Discourage redundancy

The majority of dynamic Web sites use some sort of common sitewide design – a common header, footer, navigation bar, etc. The Django template system should make it easy to store those elements in a single place, eliminating duplicate code.

This is the philosophy behind template inheritance.

Agreed.  Chunk gets this done with “exec” and “include” but, same idea.

Be decoupled from HTML

The template system shouldn’t be designed so that it only outputs HTML. It should be equally good at generating other text-based formats, or just plain text.

Absolutely.  I use Chunk all the time for templating plain-text e-mail, JSON, CSV, config files, XML etc.

XML should not be used for template languages

Using an XML engine to parse templates introduces a whole new world of human error in editing templates – and incurs an unacceptable level of overhead in template processing.

I think this is a dig at XSLT and funny XML-based templating solutions like Thymeleaf.  I never understood the appeal of these either.

Assume designer competence

The template system shouldn’t be designed so that templates necessarily are displayed nicely in WYSIWYG editors such as Dreamweaver. That is too severe of a limitation and wouldn’t allow the syntax to be as nice as it is. Django expects template authors are comfortable editing HTML directly.

Hear hear.  Chunk keeps both options open, however.  A file full of snippets probably won’t open in DreamWeaver but if you stay away from snippets and define one template per file, you should be able to use just about any HTML Editor out there.

Treat whitespace obviously

The template system shouldn’t do magic things with whitespace. If a template includes whitespace, the system should treat the whitespace as it treats text – just display it. Any whitespace that’s not in a template tag should be displayed.

Okay, so here I disagree.  If you don’t do some “smart” handling of whitespace, your template gets contorted and unreadable when you actually do care about the whitespace in the final output.

Don’t invent a programming language

The template system intentionally doesn’t allow the following:

• Assignment to variables
• Advanced logic

The goal is not to invent a programming language. The goal is to offer just enough programming-esque functionality, such as branching and looping, that is essential for making presentation-related decisions.

The Django template system recognizes that templates are most often written by designers, not programmers, and therefore should not assume Python knowledge.

Wow.  Couldn’t have put it better myself.  This is what Chunk is all about.  If you want to write code in your templates, go use PHP or JSP.  Knock yourself out.  But man, your templates are ugly and your whole team is going to suffer headaches from looking cross-eyed at your mishmosh code.

Safety and security

The template system, out of the box, should forbid the inclusion of malicious code – such as commands that delete database records.

This is another reason the template system doesn’t allow arbitrary Python code.

Bingo.

Extensibility

The template system should recognize that advanced template authors may want to extend its technology.

This is the philosophy behind custom template tags and filters.

Chunk is similarly extensible: write your own filters, make your own tag-command protocols.