safe - ¿Por qué los autores originales de Django estaban en contra de incluir etiquetas?

templates dirs django

Question

En esta excelente Google Tech Talk de Jacob Kaplan-Moss, Jacob dice que ellos agregaron soporte para la etiqueta de plantilla de include pesar de objeciones dogmáticas anteriores, y dice que la gente no debería usarla.

¿Alguien sabe por qué? Una búsqueda rápida no mostró nada que explicara por qué. No hay nada relevante en el ticket ahora fijo donde se agregó soporte para una etiqueta de include . Utilizo etiquetas de inclusión abundantemente para evitar repetirme, lo cual parece una buena idea , pero tal vez me falta alguna razón central por la cual aquellos que saben piensan que es malo.

Answer 1

Supongo que quiere alentar la reutilización de la plantilla por herencia (utilizando extends ) en lugar de por composición. Quizás la implicación es que si no puede organizar sus plantillas de esta manera, la opinión dogmática es que su sitio está mal organizado. (Por ejemplo, si está reutilizando un menú de navegación, ¿no debería estar siempre en el mismo lugar en la estructura de la página? ¿Por qué debería cada página individual decidir dónde colocarlo?)

Por cierto, el uso de include no hace mucho para ayudarlo a mantenerse SECO, ya que cualquier contexto que requiera la plantilla incluida debe pasar de todas las vistas que lo usan.

Por el contrario, el uso de una etiqueta de plantilla de inclusión personalizada le permite ejecutar código Python arbitrario en el punto donde se incluye la etiqueta, en lugar de en la vista (o empujándolo a un modelo para facilitar el acceso en la plantilla).

Como ejemplo trivial, quería mostrar una lista de los avatares de los usuarios. Usando include , se ve así:

{% for user in users %}
{% with user.gravatar_url as avatar_url %}
{% include "foo/bar/avatar.html" %}
{% endwith %}
{% endfor %}

Con una etiqueta personalizada:

{% for user in users %}
{% gravatar user.email %}
{% endfor %}

El uso de la etiqueta de inclusión personalizada significaba que la lógica de hashing de Gravatar ya no tenía que ser una preocupación del modelo de User , ni de la función de vista.

Dicho esto, creo que hay algunas situaciones en las que, inevitablemente, tienes datos similares en el contexto de varias plantillas, no necesitas hacer nada elegante con eso, solo quieres mostrar algunos de sus atributos para que no quieras escribe una función para que funcione.

Por ejemplo, escribí una aplicación de blog (¿quién no?) Que tenía dos tipos de vista de archivo: una secuencial básica, publicaciones X por página y una vista de archivo mensual. Ambas plantillas obviamente tenían una lista de publicaciones en su contexto, ambas usaban exactamente el mismo fragmento de plantilla de resumen para mostrar un título y un extracto de cada publicación, pero cada plantilla las presentaba en un contexto ligeramente diferente. Entonces usé:

{# in archive_index.html #}
{% extends "base.html" %}
{# some stuff specific to sequential archives here #}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{# probably more stuff specific to sequential archives #}

Y...

{# in archive_monthly.html #}
{% extends "base.html" %}
{# some stuff specific to monthly archives here #}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{# probably more stuff specific to monthly archives #}

Realmente parece que en este caso, la composición tiene más sentido que la herencia. De hecho, al principio fue difícil imaginar cómo funcionaría la herencia aquí. Bueno, todavía es posible:

{# in base_archive.html #}
{% extends "base.html" %}
{% block archive_header %}{% endblock %}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{% block archive_pagination %}{% endblock %}

Ahora, los dos archivos diferentes amplían esto y solo inyectan su material único en los bloques:

{# in archive_monthly.html #}
{% extends "base_archive.html" %}
{% block archive_header %}
<h1>Archive for {{ month }}</h1>
{% endblock %}
{% block archive_pagination %}
{# previous/next month links here #}
{% endblock %}

Voy a dejar de imaginar lo que archive_index.html parece como un ejercicio para el lector (sin duda aburrido).

¡Uf! Se siente inteligente haber encontrado una forma de hacer lo mismo utilizando la composición y la herencia, pero ¿está el último simplemente haciendo lo imposible para ajustarse al dogma que Jacob Kaplan-Moss mencionó?

Después de haber visto el video (sí, todo 1 hora y 5 minutos, solo para poder terminar de responder esta pregunta), no creo que Jacob se sienta enormemente molesto. Parecía un comentario improvisado, tal vez una referencia a la técnica que deberías considerar primero.