4 ms·

If you got a talented person who knows their stuff, then they should be able to handle whatever template language you throw at them. Gimping the power and expre

If you got a talented person who knows their stuff, then they should be able to handle whatever template language you throw at them. Gimping the power and expressiveness of your template language happens for 2 stated reasons: 1) To make it designer friendly 2) To force you to put logic into back one layer If you have talented folks, #1 shouldn't be a concern. Any technical artist should be able to learn enough of any template language to be trusted to not break things. Just as one coder has to code review the work of another, someone should code review the designer's work. Maybe that's a developer, maybe it's a senior technical artist; it doesn't matter. Choosing the right tool for the right people puts a lot of trust in the fact that you choose the right people! #2 is idealistic bullshit. There is HTML-specific view logic. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. But imagine the case were you have an "Export to CSV" button. That is simply two different templates over the exact same data. The HTML version might need to do some smarts about grouping or human-readable adjustments. There will surely be some javascript that depends on particular elements and structure. Forcing all of that logic into template tags is just silly.

ubernostrum 17y ago
If you have talented folks, #1 shouldn't be a concern. On the contrary; we don't expect programmers to master design and become Photoshop gurus, for example, so why should we expect designers to master what is, essentially, programming? There's a lot to be said for having different groups of people whose strengths are in particular domains. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. Actually, this only works in the most trivial (and thus non-real-world) of situations. Usually, API access needs to be mediated through additional logic (authentication, access control, rate limiting, etc.). Forcing all of that logic into template tags is just silly. I have to admit that I don't really know what you're getting at here. If you do have a case that's as simple as "use another template", well, you use another template. If you don't, no amount of program logic in templates is going to save you. Anyway, here's how I see it: 1. Django's template language is designed to permit enough logic to handle presentation, and to be easily extensible for cases where you need something more. 2. Jinja is designed to permit quite a lot of free-form programming constructs, and is not particularly easy to extend when you run up against a wall. These are fundamentally different approaches to "templating", and what I've found is that people who prefer, say, Jinja tend to just use it and move on. The people who stick around to argue are the ones who think that some particular tag or extra bit of logic should be made available by default in Django, and so are arguing about differences of degree rather than differences of kind.

ubernostrum 17y ago

If you have talented folks, #1 shouldn't be a concern. On the contrary; we don't expect programmers to master design and become Photoshop gurus, for example, so why should we expect designers to master what is, essentially, programming? There's a lot to be said for having different groups of people whose strengths are in particular domains. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. Actually, this only works in the most trivial (and thus non-real-world) of situations. Usually, API access needs to be mediated through additional logic (authentication, access control, rate limiting, etc.). Forcing all of that logic into template tags is just silly. I have to admit that I don't really know what you're getting at here. If you do have a case that's as simple as "use another template", well, you use another template. If you don't, no amount of program logic in templates is going to save you. Anyway, here's how I see it: 1. Django's template language is designed to permit enough logic to handle presentation, and to be easily extensible for cases where you need something more. 2. Jinja is designed to permit quite a lot of free-form programming constructs, and is not particularly easy to extend when you run up against a wall. These are fundamentally different approaches to "templating", and what I've found is that people who prefer, say, Jinja tend to just use it and move on. The people who stick around to argue are the ones who think that some particular tag or extra bit of logic should be made available by default in Django, and so are arguing about differences of degree rather than differences of kind.