Использовать прокси расширенный Ext.data.Operation

Question

Я продлил Ext.data.Operation для реализации пользовательского метода commitRecords.

Класс Ext.data.Operation используется для связи между магазинами и их прокси.

Метод commitRecords специально используется для обновления данных в хранилище данных в соответствии с данными, полученными от прокси-писателя.

Я не могу понять, как настроить мои прокси, чтобы использовать мою расширенную версию Ext.data.Operation.

Я нарезы через Ext.data.* пакет, но не могу найти, где Ext.data.Operation создан таким образом, я знаю, что класс сказать, чтобы использовать этот новый расширенный Ext.data.Operation класс с пользовательской commitRecords метода.

Кто-нибудь еще продлил это раньше, мог бы дать мне несколько указателей?

Answer 1

Я нашел его, batch метод Ext.data.Proxy где Ext.data.Operation объект создан для отправки на сервер.

Я продлил Ext.data.proxy.Ajax с помощью нового метода batch, где я просто выключаю new Ext.data.Operation для собственного класса операций.

EDIT

Только потому, что вы спросили DmitryB. Короткий рассказ о том, почему мне пришлось реализовать свой собственный метод commitRecords, заключается в том, что мне нужны поля данных «internalId» для данных, которые соответствуют фактическому полю ID записи базы данных. Я не буду вдаваться в то, почему именно, это слишком запутанным для меня, чтобы выразить, но вот что я сделал:

Как я понимаю, метод commitRecords обжигают в качестве одного из последних действий при вызове store.sync() он автоматически заменяет грязные записи на стороне клиента с новыми записями на стороне сервера, если вы пишете серверный контроллер, чтобы вернуть новую запись сервера в ответе Ajax, он делает это всякий раз, когда запрос синхронизации выполняет вставку или обновление.

Официальная реализация commitRecords пытается совместить эту возвращенную запись сервера с грязной записью клиента, используя поле «internalId» модели данных.

Очевидно, что я не знаю, каким будет следующий инкрементный идентификатор базы данных для новых записей, поэтому я не могу назначить его на стороне клиента как идентификатор до того, как запись синхронизируется с базой данных, поэтому запись сервера никогда не будет совпадение может совпадать с внутренним идентификатором грязной клиентской записи при вызове commitRecords, т. е. запись клиента не получит правильный идентификатор базы данных, который мне нужен.

Таким образом, потому что все мои модели данных записываемых для этого приложения имеет поле «create_time» Я решил сделать метод commitRecords соответствовать записям сервера с клиентом записями, используя поле «create_time» вместо «internalId» ,

Вот расширенный Ext.data.Класс работы, где я сделал это:

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(); 
        } 
       } 
      } 
     } 
    }, 

}); 

Как я уже говорил в ответе, я обнаружил, что я должен был расширить проксите использовать мой новый класс операции. Единственное, что я сделал, это метод batch, заменивший только две строки в методе, который сказал new Ext.data.Operation, чтобы сказать new MyApp.ux.QueryOperation (мой новый класс Operation выше). Затем это вызвало мой собственный метод commitRecords, когда ответ вернулся с сервера. Я также дал расширенный прокси псевдоним «proxy.query», так что я мог бы сказать, мои магазины, чтобы использовать его как это:

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

(Если это кажется, что я буду об этом неправильно или что-то пропустил в docs, пожалуйста, дайте мне знать. Я был бы более счастлив со встроенным методом достижения этой функциональности.)