3

I've done a few small-ish Django projects, and each time I've been struck by the apparent limitations of Django's templating language. Just as a random example, I was shocked to learn that if, in the context of a template, I had a variable bar and a dict foo, I couldn't access foo[bar] unless I wrote my own filter to do it.

I've read that the reason for this is because Django was created for environments where the people designing the pages were not programmers. I understand that.

But let's say that's not a problem for me. Is there a reason why I should stick with Django's templating language, rather than switching over to something with a lot more power, like Mako (where you can even execute arbitrary Python expressions)?

I had the opportunity to use Mako for a school project a while back, and I really loved the power of it. For example, as part of the project, we had to make a big table, where building each row and cell was fairly complex. Yet, I could make my template look something like:

<table>
    % for foo in foos:
        ${makerow(row)}
    % endfor
</table>

<%def name="makerow(row)">
    <tr>
        # Blah blah blah (possibly a call to makecell somewhere)
    </tr>
</%def>

Maybe this is a violation of separation of presentation and logic, but boy is it nice and clean. Subroutines! Abstraction! Good stuff.

And a follow-up question: If using an alternative templating language isn't frowned upon by the Django community, does anyone have any to suggest? Like I said, I really like Mako, but it's literally the only one I've used other than Django's.

Coquelicot
  • 8,775
  • 6
  • 33
  • 37

6 Answers6

4

I'll be honest, I didn't thoroughly read the responses. But I'm guessing it's a lot of "no python in your templates" and "your view shouldn't have much logic" type stuff.

If you put idealism aside and opt for pragmatism then I think Mako is a fine choice. I'm using it in a production capacity (mainly for speed, power and dynamic inheritance) for 3+ years now. It hasn't failed or been otherwise annoying in any way.

The idealists are correct, but sometimes you have to go for what's doable vs what's right. If you are not limited by the Django templating engine use it. If you need more power, Mako and Jinja are fine choices.

Django makes it very easy to swap out templating engines and keep most things working as before: http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language

Xealot
  • 1,659
  • 14
  • 26
3

Executing arbitrary code in templates should not be considered an inherently good thing. Taking advantage of such functionality is usually a sign that your architecture is broken.

That said, if you read the Django documentation, it explicitly says that you should feel free to use, discard, and replace any components you wish. Django is intentionally modular, and in fact, the two most trivially-replaceable components are the templating engine and the ORM.

If you want to use Mako instead of the Django templating engine, just use Mako.

Nicholas Knight
  • 15,774
  • 5
  • 45
  • 57
  • My gut feeling is that I do want to use something like Mako, but I'm a Django novice and don't want to start down that road if I'm inevitably going to run into a bunch of problems that I haven't foreseen or if it's going to lead me to make poor design decisions. That's why I'm asking. – Coquelicot Nov 22 '10 at 03:02
  • @Coquelicot Each part of Django operates independently of the others. The only thing you're sacrificing is the ability of another Django developer to come in and immediately grasp the entire system -- e.g. they'll have to learn about Mako if they don't already know about it. As for making poor design decisions, that's up to you, not your libraries. – Nicholas Knight Nov 22 '10 at 03:05
  • 1
    But in your comment, you say that "taking advantage of [arbitrary code execution in templates] is usually a sign that your architecture is broken", which seems to suggest that you think such a feature is an invitation to write bad code. Surely certain libraries make it easier to write well-structured code (and likewise, surely some make it difficult to do so). – Coquelicot Nov 22 '10 at 03:11
  • @Coquelicot _Programming languages_ are an invitation to write bad code. Languages and libraries that try (and inevitably fail) to enforce writing of "good" code are called "bondage and discipline" for a reason. I'm cautioning against creation of a particular type of potentially-bad code -- not the library that enables it -- because you mentioned it and it sets off alarm bells. There's also a reason I used the word "usually" -- sometimes you have to do what you have to do, even if it leaves a smell. – Nicholas Knight Nov 22 '10 at 03:16
  • I fully agree with everything Nicholas has said. Django's templating engine is *intentionally* limited. This can at times be very frustrating, but the guiding principle is sound. Separation of concerns is a very good practice and leads to better code. Templates are not the place for complex logic. If you need that much logic, it likely belongs in a view or a template tag *more often than not*. That said, there are many exceptions to any rule. Django's template engine works well for tens of thousands of users, but a different template engine may work much better for you. – Gabriel Hurley Nov 22 '10 at 06:31
2

The one reason I'd refrain from using jinja, Mako or anything else is that it may not make your app future proof with django enhancements.

There was a GSoc project proposal last year, by Alex Gaynor to make the template loading fast. - It was then retracted in favor of NoSQL project.

But with many more core developers and faster clearing of tickets, I'd stick to django full stack, knowing fully well, that components have to be changed to by home grown ones eventually.

If you are really looking for a glue framework on awesome python libraries, including the ones you choose, Flask is out there.

lprsd
  • 84,407
  • 47
  • 135
  • 168
1

addons.mozilla.org is using Django + Jinga: https://github.com/jbalogh/zamboni

Not sure whether or not the community frowns on Jinga, but many people like it, as an example.

Adam Vandenberg
  • 19,991
  • 9
  • 54
  • 56
  • Jinja is a perfectly good templating engine with a good community behind it. Django's community overwhelmingly uses Django's templating engine, but by no means discourages the use of Jinja or anything else. – Gabriel Hurley Nov 22 '10 at 06:32
0

If you did mean "app", rather than "project", and it's not for entirely private use, I would recommend that you not change the template engine; it will make the app much less likely to ever be used by anyone else as it'll require them to alter some core settings, and it may break interaction between it and other apps or the project as a whole.

Chris Morgan
  • 86,207
  • 24
  • 208
  • 215
0

Your example reminds me of the old PHP days when people would mix PHP with html all over the place. Felt really powerful. Until one day people realized that the mess is unmaintainable.

If the design is chopped up into "functions", will a designer understand it then? It will probably annoy him.

Kugel
  • 19,354
  • 16
  • 71
  • 103
  • 2
    php is controller logic + SQL + calls to web services + everything else all shoved into giant spaghetti templates. A system like Mako isn't used at all like that. There is a distinction here. Rest assured the PHP approach is abhorrent to the creators of Mako. – zzzeek Nov 23 '10 at 03:55