2012-05-22 12 views
7

Uso la modifica in linea per aggiornare il testo nel database con AJAX. Questo è fondamentalmente il processo, roba abbastanza usuale:Quando si esegue la modifica AJAX nel database, è necessario aggiornare immediatamente l'interfaccia con i nuovi dati

  • testo non è modificabile
  • clicco il testo, diventa modificabile
  • ho digitare il nuovo testo
  • quindi fare clic per inviare il testo aggiornato al il database
  • poi tornare il testo in formato non modificabile

la mia domanda è quando devo aggiornare l'interfaccia con i nuovi dati? Dovrei aggiornarlo immediatamente prima della chiamata ajax, o dovrei aspettare che la risposta dell'aggiornamento torni dal database?

La mia preoccupazione:

  • Se non aggiornare immediatamente l'interfaccia e l'ora di ottenere la risposta dal database, poi ho perso il vantaggio asincrono che viene fornito con l'Ajax.
  • Ma se lo aggiorno immediatamente, quindi se la risposta del database ha un errore, devo in qualche modo tenere traccia del cambiamento che ho già fatto, e invertire, che è molto più lavoro.

Quindi come si fa di solito questo tipo di cose?

+0

si potrebbe voglio anche postare questo in http://ux.stackexchange.com/ – climbage

risposta

3

Penso che sia completamente ragionevole attendere la risposta e l'aggiornamento come risultato di una richiamata. Ciò non toglie nulla all'approccio asincrono. È ancora completamente asincrono perché non stai bloccando l'intera pagina o ricaricandola completamente.

Un sacco di volte nelle app, in particolare quelle mobili dove la larghezza di banda potrebbe essere limitata, vedrò uno spinner che indica che il campo sta presentando. Questo non regge altre parti dell'app. Anche StackOverflow fa ciò quando utilizzo la vista mobile. Affidatevi ai callback per rimanere asincroni e continuare a essere sincronizzati con i valori di ritorno del database.

2

Le chiamate AJAX sono piuttosto veloci, ad eccezione ovviamente dei problemi di rete. Personalmente, non penso che perderà il beneficio di AJAX aspettando una risposta dal database. Cioè, a meno che tu non stia pianificando di rallentare a causa dell'elaborazione lato server, ecc ...

Ora se dovessi impostare il campo di testo su uno stato non modificabile, l'utente potrebbe pensare che il suo cambiamento sia stato accettato e verrà confuso quando il server restituisce un errore e il valore viene ripristinato allo stato originale. Vorrei lasciare il campo modificabile fino a quando il server non ritorna.

0

Se si utilizza jQuery è piuttosto semplice, ma se si utilizza lo script di chiamata ajax homebrew è necessario aggiungere un meccanismo per vedere se tutto è andato a buon fine o male.

$.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!'); 
} 
}) 

Così, quando il vostro doSomething.php restituisce vero o falso, le nostre chiamate ajax fa qualcosa in base ad esso.

Sì, le chiamate ajax sono piuttosto veloci, ma prima di modificare i dati visualizzati nella pagina credo che sia necessario assicurarsi che tutto sia andato a posto, altrimenti l'utente potrebbe lasciare la pagina senza sapere se ha apportato o meno la modifica.

0

Il caso che hai citato è un aggiornamento dell'interfaccia utente ottimista. In questo caso si presuppone (implicitamente) che l'aggiornamento verrà eseguito sul server senza errori.

Lo svantaggio di questo approccio sarebbe con un seguente scenario scatta

  1. utente su testo non modificabile
  2. testo diventa modificabile
  3. tipi utente nel nuovo testo
  4. clic dell'utente Invia
  5. L'interfaccia utente passa al nuovo testo e lo rende non modificabile
  6. L'utente chiude la finestra del browser (o si allontana da la pagina) prima che la risposta ritorni (supponendo che la modifica sia stata eseguita)
  7. La prossima volta che l'utente effettua l'accesso (o torna alla pagina) viene confuso sul motivo per cui la modifica non è stata applicata!

Tuttavia, si desidera anche utilizzare la natura asincrona di ajax e assicurarsi che l'utente possa comunque interagire con l'app (o il resto della pagina) mentre viene eseguita questa modifica.

Il modo in cui farlo (al mio posto di lavoro) viene in genere (usando polling lungo o http spinta)

  1. l'utente interagisce con il testo non modificabile
  2. Il testo diventa modificabile
  3. utente inserisce il nuovo testo
  4. clic dell'utente invia
  5. Invece di aggiornare il testo ottimismo mostriamo una sorta di trottola (solo testo) che indica all'utente che siamo in attesa di un qualche tipo di ri risposta dal server. Nota che poiché disabilitiamo solo la parte della pagina che mostra questo testo, l'utente non deve attendere il ritorno della chiamata ajax per poter interagire con il resto della pagina. (In effetti abbiamo molti casi che supportano l'aggiornamento di più parti della pagina in parallelo). Pensa a gmail dove potresti chattare con qualcuno nella finestra del browser e allo stesso tempo ricevi un'email. La chat può continuare e anche il contatore delle e-mail viene incrementato. Entrambi sono sulla stessa pagina ma non dipendono l'uno dall'altro (o aspettano l'un l'altro in alcun modo)
  6. Quando l'aggiornamento è completo, togliamo lo spinner (che di solito viene mostrato usando css - toggle class) e sostituisci il valore dell'elemento con il nuovo testo.

Infine, se si sta facendo qualcosa del genere, assicurarsi che il server abbia anche il supporto per l'aggiunta di una classe in sospeso al campo di testo (che farà apparire uno spinner). Questo viene fatto per il seguente motivo

  1. aggiornamenti utente di testo e lo invia
  2. utente immediatamente naviga a una pagina diversa
  3. utente poi torna alla pagina originale di nuovo (e supponiamo che l'aggiornamento non è ancora completo)
  4. Poiché il server sa che il campo viene aggiornato e può aggiungere una classe css in sospeso al campo etichetta/display, la pagina viene caricata con uno spinner.(D'altra parte, se non v'è alcuna richiesta in sospeso non ci sarà alcun filatore mostrato)
  5. Infine, quando il messaggio poller lungo ritorna dal server del Spinner è decollato e il valore corrente viene visualizzato