2đź‘Ť
“This seems wasteful” Why does it seem that way?
Every template is a mix of tags and text. In your case some block of text has already been visited by a template engine. So what? Once it’s been transformed it’s just text and passes through the next template engine very, very quickly.
Do you have specific performance problems? Are you not meeting your transaction throughput requirements? Is there a specific problem?
Is the code too complex? Is it hard to maintain? Does it break all the time?
I think your solution is adequate. I’m not sure template tags in dynamic content is good from a debugging point of view, but from a basic “template rendering” point of view, it is fine.
0đź‘Ť
What you’re doing sounds fine, but the question could be asked: Why not put the templatetag references directly in your template instead of manually rendering them?
<div>
{% if object matches some criteria %}
{% render_type1_object object %}
{% else %}
{% render_type2_object object %}
{% endif %
... etc ...
</div>
Or, better yet, have one central templatetag for rendering an object (or list of objects), which encapsulates the mapping of object types to templatetags. Then all of your templates simply reference the one templatetag, with no type-knowledge necessary in the templates themselves.
The key being that you’re moving knowledge of how to render individual objects out of your views.
- [Answered ]-Best way to store and serve static content in bulk
- [Answered ]-Django – grabbing error message from MySQL trigger via handling OperationalError