2012-06-15 9 views
15

Ho avuto qualche problema con questo tempo; vediamo se qualcuno può darmi una mano.Qual è lo schema standard per le convalide dei dati ember? (stato non valido, diventato non valido ...)

Sebbene non sia esplicitamente indicato nel file Leggimi, ember-data fornisce un supporto per alcune convalide. Si può vedere che in alcune parti del codice e la documentazione:

https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/states.js#L411

https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/states.js#L529

L'adattatore REST non aggiunge convalide supportano su se stessa, ma ho scoperto che se aggiungo qualcosa di simile nelle chiamate Ajax, posso mettere il modello in uno stato di "non valido" con l'oggetto errori che veniva dal lato server:

error: function(xhr){ 
    var data = Ember.$.parseJSON(xhr.responseText); 
    store.recordWasInvalid(record, data.errors); 
} 

così posso facilmente al seguente:

012.
var transaction = App.store.transaction(); 
var record = transaction.createRecord(App.Post); 
record.set('someProperty', 'invalid value'); 
transaction.commit() 
// This makes the validation fail 

record.set('someProperty', 'a valid value'); 
transaction.commit(); 
// This doesn't trigger the commit again. 

La cosa è: Come si vede, transazioni non cercano di reimpegnarci. Questo è spiegato here e here.

Quindi il problema è: se non riesco a riutilizzare un commit, come dovrei gestirlo? Sospetto che abbia qualcosa a che fare con il fatto che sto inserendo il modello allo stato invalid in modo asincrono - di reading the documentation, sembra come se fosse pensato per le convalide sul lato client. In questo caso, come dovrei usarli?

risposta

1

questa può sembrare una risposta eccessivamente semplice, ma perché non creare una nuova transazione e aggiungere il record preesistente ad esso? sto anche cercando di capire un approccio di gestione degli errori.

anche si dovrebbe probabilmente considerare di scrivere questo a livello di negozio piuttosto che il livello dell'adattatore per motivi di riutilizzo.

+1

Non sarebbe problematico dal momento che non è possibile aggiungere oggetti sporchi di transazioni? –

1

Per qualche motivo sconosciuto, il record diventa parte della transazione predefinita del negozio. Questo codice funziona per me:

var transaction = App.store.transaction(); 
var record = transaction.createRecord(App.Post); 
record.set('someProperty', 'invalid value'); 
transaction.commit() 

record.set('someProperty', 'a valid value'); 
App.store.commit(); // The record is created in backend 

Il problema è che dopo il primo fallimento, è necessario utilizzare sempre la App.store.commit() con i problemi che ha.

+0

Potrei sbagliarmi, ma penso che venga associato come transazione predefinita a meno che non specifichi specificamente un contesto. – Marco

+0

Avete qualche esempio? –

2

Ho provato la risposta di Javier, ma ottengo "Percorso non valido" quando faccio qualsiasi record.set(...) con il record in stato non valido. Quello che ho trovato è stato funzionato:

// with the record in invalid state 
record.send('becameValid'); 
record.set('someProperty', 'a valid value'); 
App.store.commit(); 

In alternativa, sembra che se io chiamo record.get(...) primi poi le successive record.set(...) chiamate di lavoro. Questo è probabilmente un bug. Ma il work-around sopra funzionerà in generale per essere in grado di re-commit dello stesso record anche senza modificare alcuna proprietà. (Naturalmente, se le proprietà sono ancora validi sarà solo fallire di nuovo.)

+0

Ho aggiunto 'record.send ('becameValid');' nella mia funzione 'diventareInvalid'. Questo ha funzionato intorno al mio problema. Questo è ispirato da un commento sulla richiesta di GitHub di Cyril. – ybart

Problemi correlati