Plantillas JavaScript de Django y del lado del cliente

client-side-templating

Question

Introducción

Actualmente estoy escribiendo una aplicación basada en Django muy estándar (básicamente una especie de lista CRM / lista de contactos). Está funcionando, pero a medida que trato de mejorar la interfaz con más y más código de interfaz de usuario AJAXy (usando jQuery), empieza a ser un verdadero dolor trabajar con él. Estoy recibiendo bloques largos de manipuladores de eventos jQuery frágiles que analizan el DOM, envían los cambios al servidor, recuperan un poco de JSON e intentan actualizar el DOM en función de eso.

Siento que, como mínimo, probablemente quiera agregar algunas plantillas del lado del cliente en la mezcla. Alternativamente, podría intentar cambiar a un marco JS, y simplemente usar mi aplicación Django como una capa de abstracción de base de datos. O a pesar de que conozco y amo Python, podría abandonar la aplicación Django e intentar con una solución JS / Node.js o algo así.

Alguien mas ha estado en esta situación? ¿Cómo lo resolvió?

Objetivos de diseño

1. SECO: No quiero tener que replicar mis modelos o mis plantillas (o al menos, más de lo necesario).
2. Quiero que los visitantes aterricen en una página para obtener los resultados que aparecen en el servidor.
3. A medida que los visitantes hacen clic en las cosas, me gustaría manejar eso a través de plantillas y representación del lado del cliente, y mantener el servidor actualizado a través de llamadas AJAX a una interfaz REST.

Entonces ... ¿cómo hago esto? He recopilado enlaces a algunos frameworks y sistemas de plantillas. Sin ningún orden en particular:

dust.js :

Aparentemente, LinkedIn lo está utilizando para resolver un problema similar. Utiliza Node.js en el lado del servidor que no es ideal (nunca he usado Node) pero al menos no está basado en JVM. También parece estar inactivo en github. Encontré listas de correo donde la gente se preguntaba dónde estaba el mantenedor. Suena bastante bien: la publicación de blog de LinkedIn hace un buen trabajo vendiendo la tecnología, especialmente la capacidad de compilarla. Pero parece SOLO ser una plantilla. ¿Es eso suficiente para lo que quiero?

Mustache :

Esta opción tiene implementaciones de Python y JS, y parece popular ... pero no puedo encontrar a nadie que parezca estar usando plantillas de Bigote con Django. ¿Es eso porque es demasiado fácil merecer una publicación de blog, o es imposible o desaconsejable? También es bastante limitado; como mínimo, probablemente necesite recurrir a algún tipo de marco MVC JS, ¿verdad?

Backbone, Spine, KnockoutJS, EmberJS, JavascriptMVC, etc.

Hay tantos marcos que es algo desalentador. Todos parecen perfectamente buenos a primera vista. También parece que necesitaría volver a escribir MUCHA mi aplicación si fuera por esta ruta, y realmente me gustaría encontrar a alguien que ya haya hecho algo como esto. Además, estaría bien si hubiera una opción clara para alguien que viene de Django como telón de fondo; No quiero tener que aprender media docena de marcos diferentes para evaluarlos.

DerbyJS

Esto parece interesante, ya que maneja los lados del cliente y del servidor en un solo paquete, pero un poco inmaduro. Advierten sobre el uso en producción, y si entiendo los documentos, aún no admite ninguna forma de persistencia, que es ... limitante. Tengo la sensación de que si estuviera terminado sería perfecto para lo que quiero ...

Asi que....

Entonces, uh ... ¿y ahora qué? ¿Alguien ha usado alguna de estas herramientas para tratar de agregar una representación del lado del cliente a una aplicación web de Django? ¿Como le fue?

Answer 1

He usado Moustache tanto del lado del servidor como del lado del cliente, y funcionó muy bien. El proyecto en el que lo usé era solo un pequeño proyecto paralelo, pero estaba muy satisfecho con los resultados y lo recomendaría.

El proyecto, una aplicación web para la depuración de servicios HTTP, está en GitHub si desea echarle un vistazo: Spyglass .

Answer 2

Para una integración completa con las plantillas de Django encontré esto: Yz-Javascript-Django-Template-Compiler . Nunca lo usé yo mismo y desafortunadamente parece un poco perdido.

Swig es un rápido motor de creación de plantillas JS django.

Pure es una herramienta de plantillas JS compilada que, con un poco de pensamiento, podría funcionar bien con Django, creo, porque las plantillas son simplemente HTML válido normal.

Otras bibliotecas de plantillas JS interesantes:

• Handlebars (una extensión de Mustache )
• Underscore

Answer 3

Sé que es una vieja pregunta, pero de alguna manera llegué aquí, por lo que probablemente otros lo hagan.

También trato de encontrar una solución para construir RIA, que funcionará en tantos dispositivos como sea posible, receptivo, de alto rendimiento y con buen uso. Django en back-end con plantillas se están implementando para tener la opción de repliegue con elegancia cuando sea necesario.

Ahora estoy mirando todos esos frameworks js y estoy un poco preocupado, principalmente sobre el rendimiento y la accesibilidad.

Teniendo en cuenta que las plantillas se implementan en el servidor, me incliné por la solución al hacer actualizaciones parciales de DOM con fragmentos html renderizados en backend y enviados al cliente grueso en lugar de json. Parece la mejor opción para mí.

Idea tomada de: http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/

Saludos, Mike

Answer 4

Todos los frameworks mencionados solo funcionan en el lado del cliente. Por otro lado, valen la pena ya que son una pieza del rompecabezas al que se enfrentan.

Sus objetivos de diseño son exactamente lo que estoy tratando de lograr con mi proyecto actual. Lo que estoy intentando hacer en este momento es:

Lado del cliente

Usando Backbone + (algunas máquinas de plantillas aquí)

Lado del servidor

Renderiza el primer conjunto de html, además de mostrar algunos datos JSON que Backbone puede recoger y trabajar (por ejemplo, la página actual que se cargó, páginas máx., Etc.)

Ejemplo

Cargas del cliente: http://mysite.com/blog/archive/5

Renders de servidor:

<html>
<head>
<script>
var data = {
page:5 // Rendered by Server,
maxPages: 10
};
$(function(){
// Hook up all Backbone stuff, and hook into interaction events
});
</script>
</head>
<body>
<!-- Content -->
</body>
</html>

Esto resuelve los puntos de diseño 2 y 3: su servidor carga el estado inicial de su aplicación web y el usuario puede navegar desde allí desde el lado del cliente.

Con el punto de diseño 1: en el lado del cliente, todo está bien. Sin embargo, para el lado del servidor necesita un motor js para representar sus plantillas tal como están. LinkedIn menciona esto en su artículo:

• Soporte de servidor: si tiene un cliente que no puede ejecutar JavaScript, como un rastreador de motor de búsqueda, una página debe mostrarse en el lado del servidor. Una vez escrito, la misma plantilla dust.js se puede representar no solo en el navegador, sino también en el servidor que usa node.js o Rhino .

Entonces estás atrapado con 2 opciones:

• utilizar un motor de plantillas con node.js o Rhino, o
• encontrar un motor de plantillas con soporte en otras pilas de tecnología.

Curiosamente, gracias a la publicación anterior, me di cuenta de que Mustache , que tiene bibliotecas disponibles para las pilas más comunes, cumple perfectamente esta necesidad, así que comenzaré a ver cómo se integra con mi proyecto. (No estoy seguro de si hay bibliotecas disponibles para Handlebars.js) Esto debería permitirnos escribir plantillas de Moustache.js tanto para el servidor como para el cliente, y hacer que rindan html en cualquier extremo con las mismas plantillas.

EDITAR: No debería ser que una solución "del lado del servidor" no necesariamente tenga que estar en su idioma / pila de elección. Por ejemplo, solo porque estés usando Dust.js significa que TIENES que codificar toda tu aplicación en Node.JS. En su lugar, es posible ejecutar sus scripts de compilación a través de un comando de shell.

EDITAR: Resulta que Moustache no parece tener una solución de "precompilación", lo que significa que las plantillas deben representarse directamente en la página para la representación del lado del cliente (por lo tanto, no hay almacenamiento en caché), que no es 100% ideal.