8

I mean I understand that these templates are aimed at designers and other less code-savvy people, but for developers I feel the template language is just a hassle. I need to re-learn how to do very simple things like iterate through dictionaries or lists that I pass into the template, and it doesn't even seem to work very well. I'm still having trouble getting the whole "dot" notation working as I would expect (for example, {{mydict.dictkey}} inside a for loop doesn't work :S -- I might ask this as a separate question), and I don't see why it wouldn't be possible to just use python code in a template system. In particular, I feel that if templates are meant to be simple, then the level of python code that would need to be employed in these templates would be of a caliber not more complicated than the current templating language. So these designer peeps wouldn't have more trouble learning that much python than they would learning the Django template language (and there's more places you can go with this knowledge of basic python as opposed to DTL) And the added advantage would be that people who already know python would be in familiar territory with all the usual syntax and power available to them and can just get going.

Am I missing something? If so I plead django noob and would love for you to enlighten me on the many merits of the current system. But otherwise, any recommendations on other template systems that may be more what I'm looking for?

mindthief
  • 12,755
  • 14
  • 57
  • 61
  • Short answer: for the web/template designers who the framework writers envision do not necessarily come with a programming background and who will in all likelihood work together, in parallel, with the web application programmers in producing the whole website. – Santa Dec 06 '10 at 05:34
  • 1
    seems like there is a place for this kind of template system. I see that everyone here explaining this by "designers are evil", "separation of layers" when actually this is rather limiting and adds another "confusing" markup to the mix for every party related to template defining and building. It would be actually more useful to limit such separation with organization rule and let the templates be a regular classes that inherit from core template where both markup and python code could be used. – Anton S Dec 06 '10 at 12:17
  • yeah i'm not entirely convinced (as I note in my comment in Rafe's answer), but I'll reserve my judgement until I have more experience with these things :). thanks! – mindthief Dec 07 '10 at 05:36

4 Answers4

10

The reason that most people give for limited template languages is that they don't want to mix the business logic of their application with its presentation (that wouldn't work well with the MVC philosophy; using Django I'm sure you understand the benefits of this).

Daniel Greenfeld wrote an article a few days ago explaining why he likes "stupid template languages", and many people wrote responses (see the past few days on Planet Python). If you read what Daniel wrote and how others responded to it, you'll get an idea of some of the arguments for and against allowing template languages to use Python.

Rafe Kettler
  • 75,757
  • 21
  • 156
  • 151
  • 3
    +1 for separation - that's the real reason, its far too tempting to put your business rules in your HTML if you don't have a template system _less powerful_ than your main language... while i don't have much love for MVC specifically, the separation of logic from presentation is a prerequisite for sane code – tobyodavies Dec 06 '10 at 03:34
  • hmm that does make sense. So, does this mean that what I am trying to do may not actually be possible inside a template? I describe the problem in http://stackoverflow.com/questions/4363032/how-to-use-django-template-dot-notation-inside-a-for-loop – mindthief Dec 06 '10 at 03:53
  • 3
    @mindthief: Possible (as per my answer to that question), but not built-in. This discourages anything "too complex" from going into the template, forcing a better separation of logic and presentation. It's up to you to decide if you prefer more power (which offers more flexibility at the cost of increased complexity and the responsibility not to shoot yourself in the foot) or not (which offers enforced separation of logic and content). – Cameron Dec 06 '10 at 04:39
  • makes sense, thanks for the answers. I see that there are indeed strong arguments for maintaining this separation. But I'm not yet sure which path is best for me -- someone I know wrote his own template language that is very flexible but disregards MVC as you describe. And he seems to be doing okay for himself. I respect the wisdom in following best practices though, so I'll give DTL (and MVC) a sincere shot! :) – mindthief Dec 07 '10 at 05:32
2

Don't forget that you aren't limited to Django's template language. You're free to use whatever templating system you like in your view functions. However you want to create the HTML to return from your view function is fine. There are many templating implementations in the Python world: choose one that suits you better, and use it.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
1

Seperation of concerns.

Designer does design. Developer does development. Templates are written by the designers.

Design and development are independent and different areas of work typically handled by different people.

I guess having template code in python would work very well if one is a developer and their spouse is a designer. Otherwise, let each do his job, with least interference.

lprsd
  • 84,407
  • 47
  • 135
  • 168
  • yeah maybe if I were a designer the dot notation would be less intimidating (and therefore perhaps more successful in outreach) than learning elementary python. thanks! – mindthief Dec 07 '10 at 05:34
1

Django templates don’t just use Python code for the same reason Django uses the MVC paradigm:
    No particular reason.
    (ie: The same reason anyone utilizes MVC at all, and that reason is just that certain people prefer this rigid philosophical pattern.)

In general I’d suggest you avoid Django if you don’t like things like this, because the Django people won’t be changing this approach. You could also, however, do something silly (in that it’d be contradictory to the philosophy of the chosen software), like put all the markup and anything else you can into the "view" files, turning Django from its "MVC" (or "MTV" ) paradigm into roughly what everything else is (a boring but straightforward lump).

Jan Kyu Peblik
  • 1,435
  • 14
  • 20