5 ms·

Django advent is a very good series of articles about 1.2 http://djangoadvent.com/ http://djangoadvent.com/

by igorgue 16y ago

metamemetics 16y ago
My favorite quote on that is: >"One of Django's core design philosophies is that template languages shouldn't try to be programming languages. To that end, we've kept the template language deliberately simplisitic so that you'd be more or less forced to push advanced logic up into the view." Very view people seem to understand this at first unfortunately and try to do crazy things like swap out the template language for something else or add on a bunch of hacks. Why create additional custom template logic and the parsing instructions for converting it to python when you can just write the functionality in probably one line of standard python in your view fuction and have it run faster.
- sidmitra 16y ago
  I agree with you but i've seen cases where we needed extra functionality to push some logic to the template, since that's what the design/UI guys use. It could have been done without adding separate template tags, but it certainly seems cleaner/logically consistent to keep things together and have the views/presentation as loosely bound as possible. And for some reason, i don't personally enjoy polluting my views with statements that do nothing but populate context variables.
  - njharman 16y ago
    > polluting my views with statements that do nothing but populate context variables. That's pretty much all I like to put in views. The rest goes in models/managers, or forms, or elsewhere.
- seiji 16y ago
  Anybody creating a template engine (or having to pick an engine) should read the paper justifying StringTemplate: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf Generic summary: templates should only be able to do substitution, iteration, and existence checks on variables.
  - enjo 16y ago
    Far to simplistic. There is a reason Django is introducing range checking and simple logic into their template statements. How often do you specify something like: "If the amount owed is more than $100, make it red in the table" That's not a question of separation of view/logic in my mind. It's a question of formatting. Forcing the view to resolve it down to a simple boolean statement results in a lot of cruft in the view layer that really doesn't belong there. It is just as evil to move presentation logic into a view as it is the other way around.
    - ubernostrum 16y ago
      "If the amount owed is more than $100, make it red in the table" Well, my usual advice on this goes back to the first time I encountered someone pushing a similar situation. In that case he was showing government safety ratings for cars, and if the rating was above a certain level wanted to show a special graphic because that got it some special certification. Rather than try to force that logic into a template, I suggested giving the relevant model a "meets_certification_standard()" method, since that's the sort of thing you'd probably want to reuse for more than just presentation. And in your case I'd bet a similar approach would be the best solution.
      - wvenable 16y ago
        Makes sense but a lot of decisions are much less "important" than that as some are purely about the rendering and don't have many meaning beyond it.
- stevenwei 16y ago
  I disagree with this philosophy entirely and think it leads to a poor separation of concerns. There is plenty of template specific logic that has no business being in the view, and being forced to put it into your view because your template system is crippled ends up mixing concerns and causing more maintenance headaches than it needs to. As a very simplistic (and somewhat contrived) example: % for label in ('Home','Features','Pricing','Contact'): <li>{{ label }}</li> % endfor I'd much rather write that than repeat myself 5x, especially if what I'm doing is more complicated than a simple list tag. In my mind, the view should be responsible for dealing with application logic and business logic. E.g. stuff like pulling things out of the database, dealing with GET/POST request data, validating forms, verifying user authentication and permissions, and whatever application specific logic is necessary. The views should pass their data to the template, but not assume anything about how the template is being rendered, and not be doing things for the template. E.g. if you're doing something that renders a HTML snippet to pass into the template, you've done something wrong. Once you start going down that road you make it much more difficult to render alternate versions of your templates (for mobile users for example). Another case where the crippled templating system ends up pushing concerns into the wrong layer is rendering hierarchical data: e.g. a nested comments tree. Deciding how to render that data should be entirely within the scope of the template. But because of the lack of simple recursion support, the 'recommended practice' is to unravel the tree in your view code, and pass the unraveled version into the template. Or write your own template tag, but that is even more complicated. It's also a bit silly that Django calls controllers 'views' and calls views 'templates', but perhaps it explains why they think it's okay to do view specific rendering at the controller level.
  - zeemonkee 16y ago
    Absolutely agree. Writing template tags in Django involves a lot of boilerplate. Compare for example Mako or Jinja2 where you can easily write a macro to handle something like nested comments.
    - kingkilr 16y ago
      FWIW it's pretty easy to write a {% macro %} tag for Django: http://alexgaynor.net/2008/dec/25/building-a-function-templatetag/ http://alexgaynor.net/2008/dec/25/building-a-function-templa...

Django advent is a very good series of articles about 1.2 http://djangoadvent.com/ http://djangoadvent.com/

by igorgue 16y ago

Django advent is a very good series of articles about 1.2 http://djangoadvent.com/ http://djangoadvent.com/

My favorite quote on that is: >"One of Django's core design philosophies is that template languages shouldn't try to be programming languages. To that end, we've kept the template language deliberately simplisitic so that you'd be more or less forced to push advanced logic up into the view." Very view people seem to understand this at first unfortunately and try to do crazy things like swap out the template language for something else or add on a bunch of hacks. Why create additional custom template logic and the parsing instructions for converting it to python when you can just write the functionality in probably one line of standard python in your view fuction and have it run faster.

sidmitra 16y ago
I agree with you but i've seen cases where we needed extra functionality to push some logic to the template, since that's what the design/UI guys use. It could have been done without adding separate template tags, but it certainly seems cleaner/logically consistent to keep things together and have the views/presentation as loosely bound as possible. And for some reason, i don't personally enjoy polluting my views with statements that do nothing but populate context variables.
- njharman 16y ago
  > polluting my views with statements that do nothing but populate context variables. That's pretty much all I like to put in views. The rest goes in models/managers, or forms, or elsewhere.
seiji 16y ago
Anybody creating a template engine (or having to pick an engine) should read the paper justifying StringTemplate: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf Generic summary: templates should only be able to do substitution, iteration, and existence checks on variables.
- enjo 16y ago
  Far to simplistic. There is a reason Django is introducing range checking and simple logic into their template statements. How often do you specify something like: "If the amount owed is more than $100, make it red in the table" That's not a question of separation of view/logic in my mind. It's a question of formatting. Forcing the view to resolve it down to a simple boolean statement results in a lot of cruft in the view layer that really doesn't belong there. It is just as evil to move presentation logic into a view as it is the other way around.
  - ubernostrum 16y ago
    "If the amount owed is more than $100, make it red in the table" Well, my usual advice on this goes back to the first time I encountered someone pushing a similar situation. In that case he was showing government safety ratings for cars, and if the rating was above a certain level wanted to show a special graphic because that got it some special certification. Rather than try to force that logic into a template, I suggested giving the relevant model a "meets_certification_standard()" method, since that's the sort of thing you'd probably want to reuse for more than just presentation. And in your case I'd bet a similar approach would be the best solution.
    - wvenable 16y ago
      Makes sense but a lot of decisions are much less "important" than that as some are purely about the rendering and don't have many meaning beyond it.
stevenwei 16y ago
I disagree with this philosophy entirely and think it leads to a poor separation of concerns. There is plenty of template specific logic that has no business being in the view, and being forced to put it into your view because your template system is crippled ends up mixing concerns and causing more maintenance headaches than it needs to. As a very simplistic (and somewhat contrived) example: % for label in ('Home','Features','Pricing','Contact'): <li>{{ label }}</li> % endfor I'd much rather write that than repeat myself 5x, especially if what I'm doing is more complicated than a simple list tag. In my mind, the view should be responsible for dealing with application logic and business logic. E.g. stuff like pulling things out of the database, dealing with GET/POST request data, validating forms, verifying user authentication and permissions, and whatever application specific logic is necessary. The views should pass their data to the template, but not assume anything about how the template is being rendered, and not be doing things for the template. E.g. if you're doing something that renders a HTML snippet to pass into the template, you've done something wrong. Once you start going down that road you make it much more difficult to render alternate versions of your templates (for mobile users for example). Another case where the crippled templating system ends up pushing concerns into the wrong layer is rendering hierarchical data: e.g. a nested comments tree. Deciding how to render that data should be entirely within the scope of the template. But because of the lack of simple recursion support, the 'recommended practice' is to unravel the tree in your view code, and pass the unraveled version into the template. Or write your own template tag, but that is even more complicated. It's also a bit silly that Django calls controllers 'views' and calls views 'templates', but perhaps it explains why they think it's okay to do view specific rendering at the controller level.
- zeemonkee 16y ago
  Absolutely agree. Writing template tags in Django involves a lot of boilerplate. Compare for example Mako or Jinja2 where you can easily write a macro to handle something like nested comments.
  - kingkilr 16y ago
    FWIW it's pretty easy to write a {% macro %} tag for Django: http://alexgaynor.net/2008/dec/25/building-a-function-templatetag/ http://alexgaynor.net/2008/dec/25/building-a-function-templa...