С ExtJS 3.x я смог использовать свойство "fields" в Магазине, но, похоже, ExtJS 4 мне нужно абсолютно использовать модель. Это хорошо, но в моем случае это не статическая модель, и мне нужно определять поля "на лету" и иногда менять их.
Я мог бы воссоздать модель, но мне нужно использовать другое имя, поскольку, по-видимому, невозможно изменить существующую модель, и не удалять ее. Если я пытаюсь использовать Ext.regModel с тем же именем, сбой ExtJS.
Спасибо за вашу помощь!
4.1 ОБНОВЛЕНИЕ:
Как обновление... в 4.1 теперь есть статический метод setFields, который можно использовать для определения полей прототипа модели. Он хорошо работает в методе инициализации контроллера.
Когда я это сделал, я хотел иметь некоторые статические поля, определенные в классе модели, а затем установить более динамически. К сожалению, новый метод setFields заменяет все поля аргументом, с ним было легко справиться.
В этом примере используется шаблон MVC, в котором моя модель и хранилище включены в массив контроллера model и массив store (предоставляя мне удобные геттеры, используемые ниже):
Ext.define('ST.controller.Main', {
extend: 'Ext.app.Controller',
models: ['User', 'Reference'],
stores: ['CurrentUser', 'PermissionRef'],
views: ['MainPanel'],
init: function() {
var me = this;
me.getPermissionRefStore().on('load', function(store, records) {
var model = me.getUserModel();
// this returns the static fields already defined
// in my User model class
fields = model.prototype.fields.getRange();
// add the permission options (dynamic fields) to the static fields
Ext.each(records, function(permission) {
fields.push({name: permission.get('name'), type: 'bool'});
});
// 4.1 method to update the User model fields
model.setFields(fields);
// now load the current user (it will use the updated model)
me.getCurrentUserStore().load();
});
}
});
Модель User и CurrentUser хранилище создаются точно так же, как обычные, нединамические модели и хранилища будут включены в их соответствующие массивы контроллеров, модель "Пользователь" просто пропускает динамические поля, которые добавляются как показанный выше.
Я также занялся этой проблемой. У меня есть служба, которая отвечает за выборку метаданных с сервера и адаптацию моделей и хранилищ к этим метаданным.
Поэтому я определил пустую модель и настроил хранилище для использования этой модели.
Когда метаданные обрабатываются, я добавляю новые/дополнительные поля к прототипу модели, подобной этой (metaDataStore - это хранилище, содержащее метаданные, модель - это модель, которая может быть получена от диспетчера модели):
var fields = [];
metaDataStore.each(function(item) {
fields.push(Ext.create('Ext.data.Field', {
name: item.get('field')
}));
});
model.prototype.fields.removeAll();
model.prototype.fields.addAll(fields);
Когда я затем вызываю нагрузку на хранилище с использованием этой модели или создаю новые экземпляры модели, новые поля обрабатываются правильно.
Вот очень простой пример. Просто используйте обычный файл Ext.data.Store, но вместо модели укажите свойство полей:
// you can specify a simple string ('totally')
// or an object with an Ext.data.Field ('dynamic')
var fields = ['totally', {name : 'dynamic', type : 'string'}];
var newStore = new MyApp.store.Object({
fields : fields
// other options like proxy, autoLoad...
});
Не указывайте свойство модели - кажется, что оно переопределит свойство полей.
Я также хотел динамически менять столбцы и содержимое существующей сетки:
// reconfigure the grid to use the new store and other columns
var newColumns = [
{header: 'Totally', dataIndex: 'totally'},
{header: 'Dynamic', dataIndex: 'dynamic'}
];
myGrid.reconfigure(newStore, newColumns);
В документации Ext JS 4 о свойстве "полей" Ext.data.Store:
Это можно использовать вместо с указанием конфигурации модели. поля должны быть набором Объекты конфигурации Ext.data.Field. Магазин автоматически создаст Ext.data.Model с этими полями. В общий вариант конфигурации следует избегать, он существует для цели обратной совместимости. Для чего-то более сложного, например указав конкретное свойство id или ассоциаций, Ext.data.Model следует быть определены и заданы для модели конфигурации.
Поэтому будьте осторожны - Sencha может удалить его в будущем.