Django design philosophies DTL - confirm if should update

Django Internals
1

Hello :wave: this was raised by @e11bits at the Django Cologne Meetup.

In Design philosophies | Django documentation | Django it says:

The Django template system recognizes that templates are most often written by designers , not programmers, and therefore should not assume Python knowledge.

We agreed that “templates are most often written by designers, not programmers” is not true based off our experience and might want to be updated.

I would propose that we keep the philosophy of “Don’t invent a programming language” but just remove this last sentence around designers. What do you think? :grin:

1 Like
2

Hi. Nice :honeybee:

Yes… so…

In My Ideal Django Shop™ programmers are often creating lots of Django Template Language (DTL) tags and filters, and in so doing they’re freeing designers to write expressive templates that don’t require Python knowledge per se, and don’t contain lots of business logic, which by the DTL’s philosophy has no place there.

Now, those programmers and designers are very often the same person — but we might keep them separate (and which role they’re playing) in our minds, even if not so in reality.

There’s no harm in rephrasing here, but I’d be keen to keep that distinction in place, and even emphasise it more.

For me, it’s the strength of the DTL. It’s the reason I prefer it. It’s not everyone’s cup of tea: many find it restrictive. But that’s why there’s room for other templating options.

So modulo all that. Yep :+1: :stuck_out_tongue_winking_eye:

3

How about:

  1. Move “Don’t invent a programming language” to be just under “Separate logic from presentation” as to me, these philosophies are related
  2. Rephrase the sentence to “The Django template system recognizes that designers should be able to write templates, and therefore should not assume Python or programming knowledge.”

Or does this not improve the clarity enough to justify the translation work :thinking:

4

If you can find a good clarification it’s always worth the translation work. (It’s just rephrases that don’t really improve the situation that we try to avoid…)

I guess as long as you can keep clear that, you shouldn’t be using more than the most simple conditional logic when writing the templates themselves, then that’s what matters. If the designer/programmer terms are what triggers then, maybe, perhaps, something like: The goal is that templates can be written by someone with HTML but little or no Python programming knowledge.

IDK :person_shrugging: — I’ll let you play with drafts :sweat_smile:

(I’m not anti an improvement here, though, yep)

1 Like
5

The goal is that templates can be written by someone with HTML but little or no Python programming knowledge .

This sounds like a good philosophy.

Just to add my experience in this area while I’m passing through, with a little stating the obvious to maybe help defining roles. I think I’ve worked with 3 roles/types where django templates are concerned.

Designers who create mockups for new templates, creating the HTML & CSS.

Frontend developers who can write those HTML templates, the CSS and integrate HTML with DTL. Sometimes they might dabble with tags & filters of their own because python is approachable like that.

Backend developers who add the more complex logic to templates after the FE devs and generally maintain those complete templates. They should know to keep their complex logic in their backend code, helping to keep the templates simple.

Then there’s some people, as Carlton says, who wear many hats. But I don’t think we need to worry about those people. They know enough already.

2 Likes
6

To continue on this remark:
If you want to have a separation of concerns, you could say that templates are not allowed to retrieve or mutate raw data. They are allowed to present the given view data however they desire.

What programmers should be aware of:

  • They should provide a sensible set of data, already normalized for use, to the template.
  • The provided data should be named in a way that describes the value.
  • The template writer should not have to be aware of any Python or Django logic.
  • The template writer should only need to use Built-in template tags and filters as a reference.
  • If the view data contains hard-coded strings needed for presentation, they should be translatable. (Or never; depending on the agreements you made with the project team)
1 Like
7

Bottom line first: I agree with @sarahboyce original post. It seems to me that the most clear and direct modification is simply to remove that sentence.

The current DTL already makes some concessions away from being a “purist” approach.

Examples:

  • The add filter adds a value to a field.
  • The dictsort filter that sorts a list of dict
  • References through foreign keys that cause queries to be executed.
  • And, even references to model methods that could alter the state of that (or another) model

Additionally, you can add tags and filters to do just about anything.

So unfortunately, I think the more specific we try to get with this, the less accurate we are.

Since we’re expressing a set of principles here, I think “short and sweet” works better to express the idea.

Side note: While I very much agree with Carlton’s concept of My Ideal Django Shop™, I’ve yet to encounter a situation where it’s practical in its pure form. Either the designer needs to know enough about the DTL and the data being used to be able to craft a complete template, or you end up with almost a “pseudo-template” requiring a fair amount of work to be usable as a template.

3 Likes
8

Wow! I didn’t think that would have sparked such a good discussion!

I said that from my experience I don’t think the statement is true anymore as it might have been when Django first started.

START: some thoughts (don’t take too seriously)

I think designers now and back then create new designs, figure out the best way of (non) visual communication with the user and mostly do mockups that do not require knowledge of HTML, CSS or any programming.

I assume the role of the webdesigner transitioned over to the frontend developer, who knows HTML/CSS/JS and many frameworks based on that.

Again, I think designers won’t touch any HTML, CSS or even a template language.

So that leaves a frontend developer or any developer to do the work of writing templates. They know how to do programming. The DTL, with its restricted capabilities, doesn’t make it easier for them, but more difficult. They have to find creative ways to overcome the restrictions.

The restrictions were setup to make it easier for non-programmers under the assumption any non-programmer would write templates and could easily learn the DTL (and HTML, CSS, JS).

And I wouldn’t call this a philosophy nor a principle, but a good intention that paved a road to where Django is now with the DTL.

Non-programmers, who are introduced to the DTL can quickly produce amazing results. But they also quickly reach the limits of the DTL and have to deal with the quirks and idiocracy of the language. They can’t grow with the language and can’t use it in any other project (maybe in a project that uses jinja). If they could start with python for example to write templates, they could grow with the language seamlessly and eventually grow beyond templates and and take their new skill to other projects or frameworks.

Programmers have to deal with the same quirks and idiocracy of the language, but they could circumvent some problems by writing their own tags or filters or use a different template language. But most stay with the DTL, because it is the lowest common denominator.

Take this for example from the admindocs template_tag_index.html:

{% block title %}{% translate 'Template tags' %}{% endblock %}
...
<h2>{% firstof library.grouper _("Built-in tags") %}</h2>

Translation is once done using the translate tag and once by a python function, that you must know.

The good intention of the DTL could also be perceived as being condescending in a sense.

irony on

Yeah, start with this template language. Programming is too complicated for you. Yeah, it’s actually not that easy and has quirks and problems and after you managed to learn all this you can only use it here. But anyway this is a language programmers think non-programmers find easy, so please use it.

Or the designer that’s handed a toy hammer by a construction worker, because he’s going to do only interiour work anyway. Which he never will.

irony off

END: some thoughts

9

I absolutely agree that the roles have morphed over time, and the knowledge sets used have changed where the separation of duties lie.

But I look at this from a different perspective. It’s not a question of if certain things can be done in the template, but should they be done there - and my answer is a resounding no.

I personally am extremely happy with the limitations created by the DTL - and actually wish they were more restrictive.

I came to Django from working in environments using templating systems that were indistinguishable from the rest of the language or were even complete programming languages of their own - and the maintenance load of those systems was a nightmare. (The maintenance load of one of those systems was so bad that we actually got approval to do a complete rewrite of that system into Django. Two years and 120k+ lines of code later and we have what everyone agrees is a far superior system.)

Having felt first hand the pain of trying to figure out where the business logic for “X” was because someone decided to program it into a template is something I will never go through again.

I would much rather “jump through hoops” in my views to prepare the data for rendering than to permit it to be done in a template. At least I’ll know where to look for the code when it needs to be modified.

Yes, it might feel nice to do stuff like that now, but the “four-years-from-now you” - or the person who replaced you - will be cursing that decision.

So while the DTL may not be perfect, it’s closer than any other system I have used - and I’m extremely grateful for that.

Having said that, I also acknowledge (as I commented on above) the ability for developers to add tags and filters to provide any desired additional functionality.

If someone wants to do that for their projects, great. If someone wants to use another templating language, also great. (Django even provides Jinja2 for that purpose)

However, neither of those (when it comes to adding programmatic functionality to a template) will ever pass a code review that I’m a part of. That’s a personal and professional architectural decision I made about 10 years ago and have never encountered a reason to change it.

2 Likes
10

Yes, this.

Like many folks, I began with PHP, back in the day when it was essentially used as a templating language, which just happened to be a full programming language.
From time to time I find myself missing the freedom, thinking Oh, if only I could <?python … — but that’s an ounce of dopamine now, for a world of pain later. It doesn’t lead to maintainable projects or good patterns.

In contrast, the DTL’s restrictions force a certain hygiene. Exactly as Ken says, it’s not that you couldn’t just bang the code there, but (on this view) you shouldn’t.

The DTL’s is a view I agree with, and it’s why I continue to choose the DTL over other options. Many do the same. Rephrase the paragraph by all means, but it would be a big jump for the proposal here to suggest changing the approach, changing what makes the DTL itself.

There are other options. Jinja is the main one in the Python space. People are free to use those if they prefer a bit more freedom.

11

Well, I guess I went overboard with my thoughts regarding if the mentioned statement is still true. And I can see the approach of the DTL having more benefits than just being a good entry level language for writing templates for most because of its restricted capabilities.

I’m still not entirely convinced that a main aspect of a template language should be to prevent people from putting logic into templates that doesn’t belong there, because there are no restrictions in place for other views as well.

But in the end I guess it comes down to what works best for most and has worked for a long time. And, as already mentioned, there are always other options.

12

or have a link to “My Ideal Django Shop™”?

13

I come from C++ where operator overloading is an absolute horror. In Python we can overload MORE things than in C++ and it’s not even remotely a problem people care about.

The difference between these two scenarios is culture.

Not being able to call free functions, and not being able to do plus, minus, multiply, divide… that doesn’t actually help imo. It moves single use logic to models where it certainly does not belong.

14

That’s fine. That’s a perfectly valid opinion for you to have. It may even be one shared by a plurality of individuals.

You have Jinja for that.

1 Like