2012-05-22 13 views
7

Estoy usando la edición en línea para actualizar el texto en la base de datos con AJAX. Este es básicamente el proceso, algo bastante habitual:Al hacer la edición AJAX a la base de datos, ¿debo actualizar la interfaz inmediatamente con los datos nuevos?

  • texto no se puede editar
  • hago clic en el texto, se hace editable
  • que escriba el nuevo texto
  • continuación, haga clic para enviar el texto actualizado de la base de datos
  • luego regresar el texto a formato no editable

Mi pregunta es ¿cuándo debería actualizar la interfaz con los nuevos datos? ¿Debo actualizarlo inmediatamente antes de la llamada ajax, o debo esperar a que la respuesta de actualización regrese de la base de datos?

Mi preocupación:

  • Si no actualizo la interfaz inmediatamente y espera la respuesta de la base de datos, entonces he perdido el beneficio asíncrono que viene con el Ajax.
  • Pero si lo actualizo de inmediato, entonces si la respuesta de la base de datos tiene un error, de alguna manera tengo que rastrear el cambio que ya hice y revertirlo, lo cual es mucho más trabajo.

Entonces, ¿cómo se suele hacer este tipo de cosas?

+0

que te pueden también quiero publicar esto en http://ux.stackexchange.com/ – climbage

Respuesta

3

Creo que es completamente razonable esperar la respuesta y la actualización como resultado de una devolución de llamada. Hacerlo no resta valor al enfoque asincrónico. Todavía es completamente asincrónico porque no está bloqueando toda la página ni volviendo a cargarla por completo.

Muchas veces en las aplicaciones, especialmente en las móviles, donde el ancho de banda puede ser limitado, veré un indicador que indica que el campo se está enviando. Esto no contiene ninguna otra parte de la aplicación. Incluso stackoverflow hace esto cuando uso la vista móvil. Confíe en las devoluciones de llamada para mantenerse asincrónico y sincronizarse con los valores de retorno de la base de datos.

2

Las llamadas AJAX son bastante rápidas, exceptuando los problemas de red, por supuesto. Personalmente, no creo que pierda el beneficio de AJAX al esperar una respuesta de la base de datos. Es decir, a menos que planee que sea lento debido al procesamiento del lado del servidor, etc.

Ahora, si configurara el campo de texto en un estado no editable, el usuario podría pensar que su cambio ha sido aceptado y se confundirá cuando el servidor devuelva un error y el valor vuelva a su estado original. Dejaría el campo editable hasta que el servidor regrese.

0

Si está utilizando jQuery es bastante simple, pero si está utilizando su script de llamada ajax homebrew tendrá que agregar algún mecanismo para ver si todo salió bien o mal.

$.ajax({ 
url: '/ajax/doSomething.php', 
type: 'POST', 
dataType: 'json', 
data: { 
    'q': $("#editableText").val() 
}, 
success: function(json) { 
    $("#editableText").html(json.value); 
}, 
error: { 
    alert('something went wrong!'); 
} 
}) 

Así que cuando su doSomething.php devuelve verdadero o falso, nuestras llamadas ajax hacen algo de acuerdo con él.

Sí, las llamadas ajax son bastante rápidas, pero antes de cambiar los datos mostrados en la página supongo que debes asegurarte de que todo salió bien, de lo contrario el usuario podría abandonar la página sin saber si la editó o no.

0

El caso que ha mencionado es una actualización de interfaz de usuario optimista. En este caso, asume (implícitamente) que la actualización se realizará en el servidor sin ningún error.

La desventaja de este enfoque sería con un escenario siguiente

  1. usuario hace clic en el texto no editable
  2. texto se convierte en
  3. tipos de usuario editables en el nuevo texto
  4. El usuario hace clic envían
  5. La interfaz de usuario cambia al texto nuevo y lo hace no editable
  6. El usuario cierra la ventana del navegador (o navega fuera de la página) antes de que la respuesta vuelva a aparecer (suponiendo que se realizó el cambio)
  7. La próxima vez que el usuario inicie sesión (o regrese a la página), se desconoce por qué el cambio no se aplica.

Sin embargo, también desea utilizar la naturaleza asincrónica de ajax y asegurarse de que el usuario aún pueda interactuar con su aplicación (o el resto de la página) a medida que se realiza este cambio.

la forma de hacer que (en mi lugar de trabajo) sería típicamente (Uso del sondeo de largo o empuje http)

  1. el usuario interactúa con el texto no editable
  2. El texto se puede editar
  3. usuario teclea nuevo texto
  4. el usuario hace clic envían
  5. en lugar de actualizar el texto optimismo mostramos una especie de ruleta (sólo en el texto) que indica al usuario que estamos a la espera de algún tipo de re sponse del servidor. Tenga en cuenta que dado que solo desactivamos solo la parte de la página que muestra este texto, el usuario no tiene que esperar a que vuelva la llamada ajax para interactuar con el resto de la página. (De hecho, tenemos muchos casos que permiten actualizar varias partes de la página en paralelo). Piensa en gmail, donde puedes chatear con alguien en la ventana del navegador y al mismo tiempo recibir un correo electrónico. El chat puede continuar y el contador de correo electrónico también se incrementa. Ambos están en la misma página, pero no dependen el uno del otro (o esperan el uno al otro de ninguna manera)
  6. Cuando la actualización se completa, le quitamos la ruleta (que usualmente se muestra usando la clase css - alternar) y reemplace el valor del elemento con el nuevo texto.

Por último, si está haciendo algo como esto, asegúrese de que su servidor también sea compatible para agregar una clase pendiente al campo de texto (que hará que aparezca una ruleta). Esto se hace por la razón siguiente

  1. actualizaciones de los usuarios de texto y envía
  2. usuario inmediatamente navega a una página diferente
  3. usuario luego regresa a la página original de nuevo (y supongamos que la actualización no es aún completo)
  4. Dado que su servidor sabe que el campo se está actualizando y puede agregar una clase css pendiente al campo de etiqueta/visualización, la página aparece cargada con una ruleta.(Por otro lado, si no hay ninguna solicitud pendiente no habrá ningún spinner muestra)
  5. Finalmente, cuando el mensaje poller largo regresa desde el servidor de la ruleta se retira y se muestra el valor actual
Cuestiones relacionadas