python - mvc - Renderizar objetos JSON utilizando una plantilla Django después de una llamada Ajax

crud php mvc ajax

Question

He estado tratando de entender cuál es la forma óptima de hacer Ajax en Django . Al leer cosas aquí y allá, pude deducir que el proceso común es:

1. formule su llamada Ajax utilizando alguna biblioteca de JavaScript (por ejemplo, jQuery ), configure un patrón de URL en Django que capte la llamada y la pase a una función de visualización

2. en la función de vista de Python recupere los objetos que le interesan y envíelos de vuelta al cliente en formato JSON o similar (mediante el uso del módulo serializador integrado, o simplejson )

3. define una función de devolución de llamada en JavaScript que recibe los datos JSON y los analiza, para crear el HTML que se necesita para mostrarse. Finalmente, el script de JavaScript coloca el código HTML donde debería permanecer.

Ahora, lo que todavía no entiendo es ¿cómo se relacionan las plantillas de Django con todo esto? Aparentemente, no estamos haciendo uso del poder de las plantillas en absoluto. Idealmente, pensé que sería bueno devolver un objeto JSON y un nombre de plantilla, para que los datos puedan repetirse y se cree un bloque HTML. Pero tal vez estoy totalmente equivocado aquí ...

El único recurso que encontré que va en esta dirección es este fragmento (769) pero aún no lo he probado. Obviamente, lo que sucederá en este caso es que todo el HTML resultante se crea en el lado del servidor y luego se pasa al cliente. La función de devolución de llamada JavaScript solo tiene que mostrarla en el lugar correcto.

¿Esto causa problemas de rendimiento? De lo contrario, incluso sin utilizar el fragmento de arriba, ¿por qué no formatear el HTML directamente en el back-end utilizando Python en lugar del front-end?

¡Muchas gracias!

ACTUALIZACIÓN: utilice el fragmento 942 porque es una versión mejorada del anterior. Descubrí que el soporte de herencia funciona mucho mejor de esta manera ...

Answer 1

Así es como utilizo la misma plantilla para el renderizado tradicional y la representación de respuesta Ajax.

Modelo:

<div id="sortable">
{% include "admin/app/model/subtemplate.html" %}
</div>

Plantilla incluida (también conocida como: subtemplate):

<div id="results_listing">
{% if results %}
{% for c in results %}
.....
{% endfor %}
{% else %}

La vista Ajax:

@login_required
@render_to(''admin/app/model/subtemplate.html'')#annoying-decorator
def ajax_view(request):
.....
return {
"results":Model.objects.all(),
}

Por supuesto, puedes usar render_to_response. Pero me gustan esos decoradores molestos: D

Answer 2

Cuando estás haciendo Ajax, no creo que tengas ningún uso para las plantillas. La plantilla está allí para que pueda generar HTML dinámico en el lado del servidor fácilmente y, por lo tanto, proporciona pocos enganches de programación dentro de HTML.

En el caso de Ajax, está pasando datos JSON y puede formatearlo como desee en Python. y los elementos de HTML / documentos se generarán en el lado del cliente utilizando el JSON mediante alguna biblioteca de JavaScript, por ejemplo, jQuery en el lado del cliente.

Tal vez si tienes un caso muy específico de reemplazar algún HTML interno del HTML del lado del servidor, entonces tal vez puedas usar plantillas pero en ese caso ¿por qué necesitarías JSON? Puede consultar la página HTML a través de Ajax y cambiar el código interno o externo o el HTML.

Answer 3

Desafortunadamente, las plantillas de Django están diseñadas para ser ejecutadas solo en el lado del servidor. Hay al menos un proyecto para renderizar plantillas de Django usando Javascript, pero no lo he usado, así que no sé qué tan rápido, bien soportado o actualizado es. Aparte de esto, debe usar las plantillas de Django en el servidor o generar elementos dinámicos en el cliente sin usar plantillas.

Answer 4

Hola gracias vikingosegundo!

Me gusta usar decoradores también :-). Pero mientras tanto he estado siguiendo el enfoque sugerido por el fragmento que mencioné anteriormente. Lo único, use en cambio el fragmento n. 942 porque es una versión mejorada de la original. Así es como funciona:

Imagine que tiene una plantilla (por ejemplo, ''subtemplate.html'') de cualquier tamaño que contenga un bloque útil que pueda volver a utilizar:

 ........
<div id="results">
{% block results %}
{% for el in items %}
<li>{{el|capfirst}}</li>
{% endfor %}
{% endblock %}
</div><br />
........

Al importar en su archivo de vista el fragmento de arriba, puede hacer referencia fácilmente a cualquier bloque en sus plantillas. Una característica interesante es que se tienen en cuenta las relaciones de herencia entre las plantillas, por lo que si hace referencia a un bloque que incluye otro bloque, etc., todo debería funcionar bien. Entonces, la vista ajax se ve así:

from django.template import loader
# downloaded from djangosnippets.com[942]
from my_project.snippets.template import render_block_to_string
def ajax_view(request):
# some random context
context = Context({''items'': range(100)})
# passing the template_name + block_name + context
return_str = render_block_to_string(''standard/subtemplate.html'', ''results'', context)
return HttpResponse(return_str)

Answer 5

Las plantillas son con el propósito de presentación . Responder con datos en formato X (JSON, JSONP , XML, YAML , * ml, etc.) no es una presentación, por lo que no necesita plantillas. Simplemente serialice sus datos en el formato X y regréselos en una respuesta HttpResponse.

Answer 6

No hay motivo por el que no pueda devolver un bit renderizado de HTML usando Ajax, e insertarlo en la página existente en el punto que desee. Obviamente, puede usar las plantillas de Django para representar este HTML, si lo desea.

Answer 7

Puede usar jquery.load() o similar, generando el HTML en el servidor y cargándolo en el DOM con JavaScript. Creo que alguien lo ha llamado AJAH .

Answer 8

Si bien las plantillas son solo para propósitos de presentación, no debería importar si lo hace en el lado del servidor o del lado del cliente. Todo se reduce a separar la lógica de control que está realizando una acción, desde la lógica de la vista que es la responsable de crear el marcado. Si su lógica de control javascript tiene que manejar cómo está renderizando o mostrando el HTML, entonces puede que lo esté haciendo mal, pero si aisla esa lógica de renderizado a otro objeto o función, y simplemente le pasa los datos necesarios para el renderizado, Entonces tú deberías estar bien; refleja cómo separamos nuestros controladores, modelos y vistas en el lado del servidor.

Eche un vistazo al proyecto github: http://github.com/comolongo/Yz-Javascript-Django-Template-Compiler

Compila plantillas django en funciones javascript optimizadas que generarán su presentación html con los datos que usted pasa. Las funciones compiladas están en javascript puro, por lo que no hay dependencias en otras bibliotecas. Dado que las plantillas se compilan en lugar de analizarlas en tiempo de ejecución, las cadenas y variables ya están ubicadas en cadenas javascript que solo necesitan concatenarse, por lo que se obtiene un aumento de velocidad enorme en comparación con las técnicas que requieren manipulación dom o análisis de scripts para obtener la presentación final. En este momento, solo están disponibles las etiquetas y los filtros básicos, pero deberían ser suficientes para la mayoría de las cosas, y se agregarán más etiquetas a medida que las personas comiencen a hacer solicitudes para ellos o comiencen a contribuir con el proyecto.