Django: ¿Es una buena idea generar JS dinámicamente?

Question

Cuando escribo mis archivos JS para un proyecto Django, por supuesto hago algunas llamadas AJAX, y por el momento las direcciones URL para esas llamadas están codificadas (lo cual es muy feo).

Estaba pensando en tener los archivos JS servidos por django (en lugar de Apache), para poder aprovechar las etiquetas de plantilla ({% url %} !!!).

¿Hay alguna razón por la que no deba hacer esto?

¿O hay una forma correcta de hacerlo?

(Puedo dar al menos uno: va a consumir mucho tiempo reenviar archivos JS que no han cambiado. Lo que sería genial es tener una aplicación que genere archivos al reiniciar el servidor django, y les sirve estáticamente después !)

Answer 1

busqué más profunda en aquellas aplicaciones de gestor de activos de djangopackages, han descubierto que django-mediagenerator proporciona esa característica, incluso si no está bien documentada: se puede generar sus js o css como plantillas de Django, y luego servirlos de forma estática (también están agrupados, y el almacenamiento en caché se gestiona, etc. ... ¡así que dos pájaros con una piedra + es realmente fácil de configurar!).

Con el fin de tener archivos JS generados como plantillas de Django (después de haber puesto en marcha django-mediagenerator), sólo tiene que añadir el filtro:

ROOT_MEDIA_FILTERS = { 
    'js': 'mediagenerator.filters.template.Template', 
} 

en la configuración.

Answer 2

El archivo .js que se envía al navegador puede variar. Eso podría hacer que la depuración sea más engorrosa. Tal vez no sea un problema, pero algo a considerar potencialmente ...

Answer 3

Generar Javascript de forma dinámica en su servidor puede ser una herramienta tremendamente poderosa y he experimentado tanto ventajas como desventajas en mis proyectos.

En general, desea mantener la mayor cantidad posible de datos estáticos para minimizar el trabajo que se debe realizar en cada solicitud. Esto incluye tener el caché del navegador tanto como sea posible, lo que podría convertirse en un problema en su caso.

Lo que suelo hacer es tener un bloque en el encabezado de mi plantilla base. En las plantillas que necesitan un javascript personalizado que solo se conoce en el tiempo de ejecución (personalización basada en el usuario que ha iniciado sesión, por ejemplo), lo agrego al bloque. Aquí puedo generar dinámicamente javascript que sé que no se almacenará en caché para poder hacer algunas suposiciones. La desventaja es más complejidad.

Si lo que necesita son solo apuntando a direcciones URL, o tiene alguna configuración simple, etc., entonces le sugiero que cree una vista que devuelva un archivo Javascript con esta configuración. Puede establecer los encabezados correctos (Etag, Cache-Control, etc.) para que el navegador guarde en caché el archivo durante un tiempo razonable. Cuando actualice su código, asegúrese de que el Etag cambie.

En el código que debe utilizar la configuración, es necesario comprobar siempre que la variable que busca es en realidad se defina otra cosa que se a tener problemas que son difíciles de depurar cuando por alguna razón la configuración JavaScript es no cargado correctamente

Answer 4

Me gustaría una técnica híbrida. Sirve la mayor parte de tu javascript estáticamente. Pero en su plantilla Django, tenga un bloque <script> que define varias variables globales, que son generadas por el código del lado del servidor - url es un buen ejemplo. Entonces su JS estática puede referirse a las variables que se generan en el código dinámico.

Answer 5

Hoy en día, la mejor manera de hacer esto es utilizar Django.js

Aquí es el documento donde se habla de la URL de marcha atrás: http://djangojs.readthedocs.org/en/0.8.1/djangojs.html#reverse-urls