4 ms·

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 be

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...
  - zeemonkee 16y ago
    Sure, but that's a workaround for something that arguably belongs in the template language to start with.
    - kingkilr 16y ago
      Well, that's a matter of perspective. In any event if this were to be implemented in the Django template language it would be implemented as a tag like this, just as {% for %}, {% if %} and everything else are. Everything is a first class citizen :)
- metamemetics 16y ago
  You can already drop in a nested comments system with Pinax super easy. But if you want to write your own, use {% include %} tag to render them recursively using multiple templates. This also allows you to implement AJAX loading\closing of subcomments much easier than if you came up with some macro to display\load every single comment in one template
- erlanger 16y ago
  The included simple_tag and filter decorators should be used for simple tags and filters. More sophisticated tags can specify a separate renderer class, which must be what you mean by "boilerplate." from django.core.urlresolvers import reverse from django.template import Library register = Library() @register.simple_tag def menu_item(req, viewname, label): url = reverse(viewname) cls = '' if url == req.path: cls += 'active' return '<li class="%s"><a href="%s">%s</a></li>' % (cls, url, label) Using the tag: {% menu_item request 'accounts.views.profile' 'Your Account' %} The only part of that I don't like is passing the request, but I'm willing to bet there's a simpler way to access the request object from the function. A simple filter: @register.filter def subtract(x, y): """Subtracts the arg from the value""" return int(x) - int(y) And maybe in a for loop for overlapping elements: <li style="z-index: {{ 100|subtract:forloop.counter }}"> Yes, I use two spaces in my Python code too.
  - stevenwei 16y ago
    I'm not really a big fan of how writing custom template tags throws you back into the land of string substitution: the entire problem that templating languages were meant to solve in the first place! Jinja2's macros are a much more elegant solution, IMO.
  - zeemonkee 16y ago
    The above solution is just plain ugly, HTML in Python. Another PITA, where Django templates just fall down, is forms. Suppose you have a form: class MyForm(forms.Form): name = forms.CharField() You then add that in the template: {{ form.name }} All well and good; but what if you want to change the size, maxlength, or add a class ? These things clearly belong in the template, but no, you have to either add them in the form declaration: name = forms.CharField(widget=forms.TextInput(attrs={'class' : 'foo'})) or in the view: form.fields['name'].widget.attrs = {'class' : 'foo'} Both of which clearly break the separation of concerns. yes, you could write a template tag to get around this; but it's not in standard Django. Contrast the following in Jinja2 (using WTForms, but you get the idea): {{ form.name(class_="foo") }}
    - 16y ago
metamemetics 16y ago
<li>{{home}}</li> <li>{{home.features}}</li> <li>{{home.pricing}}</li> <li>{{home.contact}}</li> You saved one line of code, but had to pass related data members that should be containerized in a home object to the template seperately, which means you actually used more total code if you include your view function. If you really want to do it that way, why not have a .list() interface method on your Home model that returns all of its string data members in a list? {%for label in home.list%} <li>{{label}}</li> {%endfor%} But I think the first way reads more like HTML and allows you to style them seperately which your going to have to often do 90% of the time Edit: also, you can recurse all day long in django with clever use of the {%include%} tag. The {%include%} tag is seriously worth looking into in any complicated situation. Writing your HTML in seperate chunks also make rolling out an AJAX version of the page really easy, because you can just render the included subcomponent in an ajax request instead of the page that includes it, using the same view function.
- stevenwei 16y ago
  Like I said, it was a simplistic and contrived example. Obviously if the list was longer or the HTML contained more than a simple <li> tag, then the boilerplate repetition becomes more annoying. But who said anything about a Home model? What if I was just adding a list of links to the footer of my page? E.g. things that have nothing to do with the application or data but are necessary for presentation on a webpage.
  - iamelgringo 16y ago
    You're absolutely correct in saying that you shouldn't have to create boilerplate to have a footer with nav links on the bottom of every page. I believe that the preferred way to do this in Django is by either creating a custom template tag, or by using template inheritance. Template inheritance: create a base.html template with a {% block footer %} that can inherit and/or over ride it from any other template that needs. Template Tags: Create a simple tag that renders the comments thread, what's related links, etc... in a separate tag. This is the "preferred" way if you need to query the database for something that's related to multiple different views. For an example of that, see the django-pagination app.
MWinther 16y ago
I believe they suggest you write custom logic as a template tag, rather than in the view. However, I do agree that the naming conventions are unfortunate, to say the least. In my experience not doing this separation encourages people solving controller-level problems on the view level, just because they can. Of course, it's just a "quick fix, I'll fix that properly later" everytime that happens. This philosophy is what drew me to Django in the first place, I really dislike HTML fragments in code, and having done enough rewriting of code when it's time to redesign the web site makes this a big feature for me. Of course, being Django, it's loosely coupled and you can easily switch out the template language to something else.

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...
- zeemonkee 16y ago
  Sure, but that's a workaround for something that arguably belongs in the template language to start with.
  - kingkilr 16y ago
    Well, that's a matter of perspective. In any event if this were to be implemented in the Django template language it would be implemented as a tag like this, just as {% for %}, {% if %} and everything else are. Everything is a first class citizen :)
metamemetics 16y ago
You can already drop in a nested comments system with Pinax super easy. But if you want to write your own, use {% include %} tag to render them recursively using multiple templates. This also allows you to implement AJAX loading\closing of subcomments much easier than if you came up with some macro to display\load every single comment in one template
erlanger 16y ago
The included simple_tag and filter decorators should be used for simple tags and filters. More sophisticated tags can specify a separate renderer class, which must be what you mean by "boilerplate." from django.core.urlresolvers import reverse from django.template import Library register = Library() @register.simple_tag def menu_item(req, viewname, label): url = reverse(viewname) cls = '' if url == req.path: cls += 'active' return '<li class="%s"><a href="%s">%s</a></li>' % (cls, url, label) Using the tag: {% menu_item request 'accounts.views.profile' 'Your Account' %} The only part of that I don't like is passing the request, but I'm willing to bet there's a simpler way to access the request object from the function. A simple filter: @register.filter def subtract(x, y): """Subtracts the arg from the value""" return int(x) - int(y) And maybe in a for loop for overlapping elements: <li style="z-index: {{ 100|subtract:forloop.counter }}"> Yes, I use two spaces in my Python code too.
- stevenwei 16y ago
  I'm not really a big fan of how writing custom template tags throws you back into the land of string substitution: the entire problem that templating languages were meant to solve in the first place! Jinja2's macros are a much more elegant solution, IMO.
- zeemonkee 16y ago
  The above solution is just plain ugly, HTML in Python. Another PITA, where Django templates just fall down, is forms. Suppose you have a form: class MyForm(forms.Form): name = forms.CharField() You then add that in the template: {{ form.name }} All well and good; but what if you want to change the size, maxlength, or add a class ? These things clearly belong in the template, but no, you have to either add them in the form declaration: name = forms.CharField(widget=forms.TextInput(attrs={'class' : 'foo'})) or in the view: form.fields['name'].widget.attrs = {'class' : 'foo'} Both of which clearly break the separation of concerns. yes, you could write a template tag to get around this; but it's not in standard Django. Contrast the following in Jinja2 (using WTForms, but you get the idea): {{ form.name(class_="foo") }}
  - 16y ago

metamemetics 16y ago

<li>{{home}}</li> <li>{{home.features}}</li> <li>{{home.pricing}}</li> <li>{{home.contact}}</li> You saved one line of code, but had to pass related data members that should be containerized in a home object to the template seperately, which means you actually used more total code if you include your view function. If you really want to do it that way, why not have a .list() interface method on your Home model that returns all of its string data members in a list? {%for label in home.list%} <li>{{label}}</li> {%endfor%} But I think the first way reads more like HTML and allows you to style them seperately which your going to have to often do 90% of the time Edit: also, you can recurse all day long in django with clever use of the {%include%} tag. The {%include%} tag is seriously worth looking into in any complicated situation. Writing your HTML in seperate chunks also make rolling out an AJAX version of the page really easy, because you can just render the included subcomponent in an ajax request instead of the page that includes it, using the same view function.

stevenwei 16y ago
Like I said, it was a simplistic and contrived example. Obviously if the list was longer or the HTML contained more than a simple <li> tag, then the boilerplate repetition becomes more annoying. But who said anything about a Home model? What if I was just adding a list of links to the footer of my page? E.g. things that have nothing to do with the application or data but are necessary for presentation on a webpage.
- iamelgringo 16y ago
  You're absolutely correct in saying that you shouldn't have to create boilerplate to have a footer with nav links on the bottom of every page. I believe that the preferred way to do this in Django is by either creating a custom template tag, or by using template inheritance. Template inheritance: create a base.html template with a {% block footer %} that can inherit and/or over ride it from any other template that needs. Template Tags: Create a simple tag that renders the comments thread, what's related links, etc... in a separate tag. This is the "preferred" way if you need to query the database for something that's related to multiple different views. For an example of that, see the django-pagination app.

MWinther 16y ago

I believe they suggest you write custom logic as a template tag, rather than in the view. However, I do agree that the naming conventions are unfortunate, to say the least. In my experience not doing this separation encourages people solving controller-level problems on the view level, just because they can. Of course, it's just a "quick fix, I'll fix that properly later" everytime that happens. This philosophy is what drew me to Django in the first place, I really dislike HTML fragments in code, and having done enough rewriting of code when it's time to redesign the web site makes this a big feature for me. Of course, being Django, it's loosely coupled and you can easily switch out the template language to something else.