2009-12-02 19 views
14

Estoy tratando de encontrar la arquitectura óptima para una aplicación Django de gran tamaño que estoy construyendo actualmente. Me gustaría mantener una forma coherente de formularios, validación, búsqueda de datos, formato de mensaje JSON, pero es extremadamente difícil encontrar una solución que pueda usarse de manera coherente.arquitectura Ajax en la aplicación Django

¿Puede alguien señalarme en la dirección correcta o compartir su punto de vista sobre las mejores prácticas?

+6

¿Qué tiene de especial en Ajax? Desde el punto de vista django, estas son solo solicitudes. – GabiMe

+1

Nada más que me encuentro odiando, por ejemplo, mezclando la representación de la plantilla del contenido utilizando el ciclo de solicitud/respuesta normal y el contenido procedente de las solicitudes ajax. Se siente sucio –

Respuesta

2

No se me ocurre ninguna forma estándar de insertar ajax en una aplicación Django, pero puedes echarle un vistazo a este tutorial.

También encontrará más detalles sobre django's page about Ajax

2
hace

dos semanas hice un write up cómo puedo implementar sub-plantillas para usarlas en "normal" y la solicitud "ajax" (por Django es el mismo). Tal vez sea útil para ti.

4

Realizo todo como vistas normales que se muestran normalmente en el navegador. Eso incluye todas las respuestas a las solicitudes AJAX (páginas secundarias).

Cuando quiero hacer que los sitios sean más dinámicos, uso jQuery para hacer AJAX, o en este caso AJAH, y solo cargo los contenidos de uno de los divs en la página secundaria en la página solicitante.

Esta técnica funciona muy bien - es muy fácil depurar las páginas secundarias, ya que son solo páginas normales, y jQuery te hace la vida muy fácil usando estas como parte de una página AJA [XH] ed.

+0

Ok, suena razonable. Pero, ¿realiza funciones de vista separadas para solicitudes AJAX y solicitudes ordinarias o utiliza if_ajax() para devolver respuestas diferentes? ¿Qué pasa con los formularios, utiliza las solicitudes comunes para enviar los datos del formulario o lo hace con AJAX? –

+0

Realizo una vista que funciona primero en la nave de frentes, luego uso jQuery para extraer los bits relevantes e insertarlos en la página de solicitud. No he usado 'is_ajax' todavía. En cuanto a los formularios, utilizo el envío de formularios jQuery para las páginas dinámicas sí. Estos POST a una vista django normal. –

+0

Soy un novato ajax/django, pero ¿no es tu método muy ineficiente? Significa devolver mucho más de lo que realmente necesita (todo el HTML circundante, en lugar de los datos reales). ¿O me estoy perdiendo algo? –

2

+1 a Nick para las páginas que se muestran normalmente en el navegador. Ese parece ser el mejor punto de partida.

El problema con los enfoques más simples de AJAX, como proponen Nick y vikingosegundo, es que tendrás que confiar en la propiedad innerHTML de tu Javascript. Esta es la única manera de volcar el nuevo HTML enviado en el JSON. Algunos considerarían esto como algo malo.

Desafortunadamente, no conozco una forma estándar de replicar la visualización de formularios usando Javascript que coincida con la representación de Django. Mi enfoque (que todavía estoy trabajando) es subclasificar la clase Django Form, por lo que genera bits de Javascript junto con el HTML de as_p(), etc. Estos luego replican la forma en que manipulo el DOM.

2

Por experiencia, sé que administrar una aplicación en la que genera el código HTML en el servidor y simplemente "inserta" en sus páginas, se convierte en una pesadilla. También es imposible probar usando el marco de prueba de Django. Si está usando Selenium o una herramienta similar, está bien, pero debe esperar a que la solicitud de Ajax regrese, por lo que necesita mucho sueño en su script de prueba, lo que puede ralentizar su suite de pruebas.

Si el propósito de utilizar la técnica de Ajax es crear una buena interfaz de usuario, recomendaría ir all-in, como la interfaz de GMail, y hacer todo lo posible en el navegador con JavaScript. He escrito varias aplicaciones como esta usando nada más que jQuery, máquinas de estados para administrar el estado de IU y JSON con ReST en el back-end. Django, en mi humilde opinión, es una combinación perfecta para el back-end en este caso. Incluso hay software de terceros para generar una interfaz ReST a sus modelos, que nunca he usado, pero que yo sepa que son geniales en lo simple, pero usted por supuesto todavía necesita hacer su propia lógica comercial. .

Con este enfoque, se encuentra con el problema de duplicar el código en el JS y en su back-end, como el manejo de formularios, la validación, etc.He estado pensando en resolver esto con la generación de información estructurada sobre las formas y la lógica de validación que puedo usar en JS. Esto podría compilarse en el momento del despliegue y cargarse como cualquier otro archivo JS.

Además, evite XML. Los navegadores son lentos en analizarlo, es un dolor generar y un dolor para trabajar en el navegador. Use JSON.

4

Para todas las respuestas a esto, no puedo creer que nadie haya mencionado django-piston todavía. Se promociona principalmente para usar en construir API REST, pero puede generar JSON (que jQuery, entre otros, puede consumir) y funciona igual que las vistas, ya que puede hacer cualquier cosa con una solicitud, convirtiéndola en una excelente opción para implementar interacciones AJAX (o AJAJ [JSON], AJAH, etc.). También es compatible con form validation. Actualmente

1

Im prueba:

  • jQuery & Backbone.js del lado del cliente

  • django-pistón (capa intermedia)

escribirá más tarde mis resultados en mi blog http://blog.sserrano.com

Cuestiones relacionadas