Utilizzare proxy esteso Ext.data.Operation

Question

Ho esteso Ext.data.Operation per implementare un metodo personalizzato commitRecords.

La classe Ext.data.Operation viene utilizzata per tutte le comunicazioni tra negozi e relativi proxy.

Il metodo commitRecords viene utilizzato specificamente per aggiornare i dati in un archivio dati in base ai dati restituiti da un writer proxy.

Non riesco a capire come configurare i miei proxy per utilizzare la mia versione estesa di Ext.data.Operation.

Ho rigatura attraverso il pacchetto Ext.data.* ma non riesco a trovare dove il Ext.data.Operation è creato così saprò quale classe per dire a utilizzare questa nuova estesa Ext.data.Operation classe con il metodo personalizzato commitRecords.

Qualcun altro l'ha già spiegato prima, potrebbe darmi qualche suggerimento?

Answer 1

L'ho trovato, il metodo batch di Ext.data.Proxy è dove viene creato un oggetto Ext.data.Operation da inviare al server.

Ho esteso Ext.data.proxy.Ajax con un nuovo metodo batch in cui ho appena sostituito lo new Ext.data.Operation per la mia propria classe operativa.

EDIT

Solo perché avete chiesto DmitryB. La breve storia sul perché ho dovuto implementare il mio metodo commitRecords è che avevo bisogno dei miei campi "internalId" dei modelli di dati per abbinare il campo dell'ID del record del database reale. Non voglio entrare in perchè esattamente, è troppo complicata per me esprimere, ma ecco quello che ho fatto:

Come ho capito, il metodo commitRecords viene licenziato come una delle ultime azioni al momento della chiamata store.sync() si sostituisce automaticamente il record sporchi sul lato client con i nuovi record lato server finché si scrive il controller lato server per restituire il nuovo record server nella risposta Ajax, lo fa ogni volta che la richiesta di sincronizzazione esegue un inserimento o un aggiornamento.

L'implementazione ufficiale di commitRecords tenta di far corrispondere questo record del server restituito al record del client dirty utilizzando il campo "internalId" del modello di dati.

Ovviamente, non ho idea di quale sarà il prossimo ID del database incrementale per i nuovi record, quindi non posso assegnarlo sul lato client come ID prima che il record si sincronizzi con il database, quindi il record del server non sarà mai la corrispondenza può essere confrontata con l'ID interno del record del client sporco quando viene chiamato commitRecords, ovvero il record del client non ottiene l'ID del database corretto, di cui ho bisogno.

Quindi, perché tutte dei miei modelli di dati scrivibili per questa applicazione hanno un campo "create_time" Ho deciso di rendere il metodo commitRecords corrisponde ai record dei server con i record client utilizzando il campo "create_time" invece di "InternalID" .

Ecco l'estensione Ext.data.classe di funzionamento, in cui ho fatto questo:

Ext.define('MyApp.ux.QueryOperation', { 
    extend: 'Ext.data.Operation', 

    /** 
    * Use the date_created timestamp if we cant match to an ID. 
    * This allows client records that did not previously exist on the server 
    * to be updated with the correct server ID and data 
    * NB: All implementing data models require a "date_created" field. 
    */ 
    commitRecords: function (serverRecords) { 
     var me = this, 
      mc, index, clientRecords, serverRec, clientRec; 
     if (!me.actionSkipSyncRe.test(me.action)) { 
      clientRecords = me.records; 
      if (clientRecords && clientRecords.length) { 
       if (clientRecords.length > 1) { 
        mc = new Ext.util.MixedCollection(); 
        mc.addAll(serverRecords); 
        Ext.each(clientRecords, function(clientRec) { 
         serverRec = mc.findBy(function(record) { 
          var clientId = clientRec.getId(), 
           clientTime = clientRec.get('date_created').getTime(), 
           serverTime = record.get('date_created').getTime(); 
           if(clientId && record.getId() === clientId) { 
            return true; 
           } 
           // timestamp can be within 2ms of record 
           // (it seems to change slightly in serialization) 
           return (clientTime > serverTime - 2 && clientTime < serverTime + 2); 
         }); 
         me.updateClientRecord(clientRec, serverRec); 
        }); 
       } else { 
        clientRec = clientRecords[0]; 
        serverRec = serverRecords[0]; 
        me.updateClientRecord(clientRec, serverRec); 
       } 
       if (me.actionCommitRecordsRe.test(me.action)) { 
        for (index = clientRecords.length; index--;) { 
         clientRecords[index].commit(); 
        } 
       } 
      } 
     } 
    }, 

}); 

Come ho già detto nella risposta, ho scoperto che ho dovuto prolungare il proxy per fare uso della mia nuova classe di funzionamento. L'unica cosa che ho esteso è stata il metodo batch, che sostituiva solo due righe nel metodo che diceva new Ext.data.Operation per ora dire new MyApp.ux.QueryOperation (la mia nuova classe Operazione sopra). Questo poi ha chiamato il mio metodo commitRecords quando una risposta è tornata dal server. Mi ha anche dato il proxy esteso un alias "proxy.query" in modo da poter dire ai miei negozi per usare in questo modo:

Ext.define('MyApp.store.MyStore', { 
    extend: 'Ext.data.Store', 
    requires: [ 
     'ST.ux.QueryProxy', 
    ], 
    title: 'Student', 
    model: 'MyApp.model.MyModel', 
    proxy: { 
     type: 'query', 
     // ... ^^^^^ uses my QueryProxy now 
     // other configs... 
    } 
}); 

(Se sembra che sto andando su questo modo sbagliato o perso qualcosa nel documenti, per favore fatemelo sapere Sarei più felice con un metodo integrato per raggiungere questa funzionalità.)