¿Cómo construir página web agraciados Degradación AJAX?

Question

Quiero construir página web con "degrade correctamente". Es decir, las funciones de la página web, incluso javascript está deshabilitado. Ahora tengo que tomar una decisión de diseño en el formato de la respuesta AJAX.

Si javascript está deshabilitado, cada solicitud HTTP al servidor generará HTML como respuesta. Las actualizaciones del navegador con el HTML devuelto. Eso está muy bien.

Si está activado Javascript, AJAX cada solicitud HTTP al servidor generará ... bueno, JSON o HTML.

Si se trata de HTML, es fácil de implementar. Sólo tienen Javascript para sustituir parte de la página con el HTML devuelto. Y, en el lado del servidor, no se necesita mucho cambio de código.

Si es JSON, entonces tengo que aplicar la lógica en JSON-a HTML en javascript nuevo que está casi duplicar la lógica del lado del servidor. La duplicación es el mal . Realmente no me gusta. El beneficio es que el uso de ancho de banda es mejor que el HTML, que aporta un mejor rendimiento.

Así que, ¿cuál es la mejor solución a la degradación agraciada? petición AJAX mejor para volver JSON o HTML?

Answer 1

No creo que no puede haber una 'mejor disoluciones para cualquier situación dada. Sólo tal vez, una 'solución adecuada' para una en particular. Realmente depende de lo que está tratando de hacer. ¿Qué significa una degradación elegante para mí es:

• Construir una interfaz 'suficientemente bueno' que funciona en el mayor número de navegadores (escritorio y móvil) como sea posible.
• añadir discretamente en algunas secuencias de comandos (métodos de validación, elementos de la interfaz como los tabuladores y deslizadores o lo que sea) que sólo estará presente si el navegador la página se ha cargado en cuenta con las características necesarias para que funcionen.

Si hay que usar HTML o JSON en la respuesta del servidor es altamente subjetiva, a menudo me encuentro luchando para elegir entre ellos. Uno podría argumentar, por ejemplo, que recibir un montón de pares de valores clave desde el servidor y los hace en un elemento de selección existente significaría más código y por lo tanto un mayor tiempo de codificación y errores potenciales. En su lugar, simplemente podría solicitar el elemento select de pre-construidos desde el servidor, y lo inyecta en un recipiente. La lógica de la construcción del elemento ya reside en el servidor, ¿por qué construir dos veces, en dos idiomas diferentes.

La otra perspectiva es que minimiza el uso de ancho de banda JSON, por lo que vale la pena hacer un esfuerzo adicional para analizar algunos JSON para construir algunas marcas en el cliente. Me resulta fácil estar en desacuerdo con ese punto de vista, por un par de razones (soy no generalizar, no me malinterpreten). En primer lugar, muchos, muchos servidores web están configurados para comprimir / desinflado / gzip su producción, y muchos, muchos navegadores aceptan comprimen contenido. De marcado es extremadamente compresible, ya que contiene botes llenos de redundancia (<strong></strong>). Por tanto, es razonable considerar que el tamaño de una respuesta JSON no sería abrumadoramente más pequeño que un margen de beneficio respuesta-con-nosotros. En segundo lugar, un gran conjunto de datos podría significar un tiempo de ejecución considerable en el cliente (desagradables, bucles anidados son comunes - evidente en algunas de las preguntas que aparecen aquí)

.

Mi consejo es tratar de comprender las ventajas y desventajas de cada método, y para aprovechar esa información. Es posible que desee leer esto:

http://www.quirksmode.org/blog/archives /2005/12/the_ajax_respon.html

Answer 2

OMI, trabajando con HTML trae mayores riesgos de seguridad (MITM inyección de scripts, etc.). Cualquier tiempo ahorrado en la "duplicación" en realidad debe ser gastado en la desinfección antes de añadir.

JSON se puede analizar de forma segura y es por lo general mucho más compacto, como usted dice, el ahorro de ancho de banda.

Yo sé lo que yo elegiría (JSON).

Answer 3

En primer lugar, pensar cuidadosamente acerca de si realmente se necesita para apoyar tanto a los usuarios habilitados para JavaScript y no habilitados. Para mi dinero, lo bueno de AJAX es que separa la pantalla (construcción de HTML) a partir de información.

Dicho esto, aquí hay un enfoque que la fuerza de trabajo:

1. Escribir un programa de servidor que hace lo que sus necesidades de página para hacer y devuelve la respuesta (cualquiera que consiste en) en la forma más simple posible. Para la salida sencilla - como acaba de indicar si ha funcionado o no - esto podría ser sólo un número o una cadena sencilla. Para algo más complicado que un solo resultado que probablemente será XML.

2. Escribir un script del lado del servidor que simplemente llama al programa y muestra el resultado como texto sin formato o XML.

3. escribir otro script del lado del servidor que llama al programa y construye una página HTML de la misma.

4. En la página que las llamadas de los usuarios para ejecutar la rutina, incluir javascript, que escriben un control (por ejemplo, un botón), que cuando se pulsa envía una petición AJAX para llamar a la primera secuencia de comandos, a continuación, analiza el resultado y actualiza la página en consecuencia. También incluya otro control, dentro de las etiquetas NOSCRIPT de modo que los usuarios que están habilitados para JS no lo verán, lo que lo hace una forma estándar de someterse a ejecutar su segundo guión. Por lo que aún necesita dos scripts, pero la carne principal de su cálculo sólo se realiza una vez.