Добрый день!
Есть задача создать Вкладку "История филиалов", в которой отображать стандартные детали филиалов данного контрагента (из детали Взаимосвязи).
В принципе добавить детали по филиалам ясно. Переопределить return в AccountPageV2, и возвращать значение функции, которая добавит в структуру страницы нужные детали(в detailes) и элементы страницы (в diff).
Загвоздка заключается, в том, что если пользователь захочет внести изменения в структуру страницы через "Мастер раздела", то мастер сформирует стандартную структуру страницы, затерев функцию динамического формирования Вкладку "История филиалов".
Может кто-нибудь сталкивался с подобной задачей или может подсказать в какую сторону двигаться, чтобы обойти эту проблему.
Спасибо.
Нравится
Здравтсвуйте, Игорь!
Если я правильно понял, то замещать таким образом модуль некорректно. Все замещающие модули должны иметь идентичную структуру с маркерными комментариями, чтобы мастер разделов мог с ними работать. Можно предпринять 2 вещи:
1) динамику отображения вкладки реализовать с помощью методов и зависимостей таким образом, чтобы сохранилась структура модуля. Хотя я может быть неверно понял то, как Вы хотите замещать страницу. На всякий случай приведите код.
2) разместить свой замещающий модуль страницы в отдельном пакете, чтобы мастер разделов создавал свой модуль и не "затирал" Ваш.
Здравствуйте!
Схема такая:
define('AccountPageV2', ['AccountPageV2Resources', 'GeneralDetails', 'BusinessRuleModule'], function(resources, GeneralDetails, BusinessRuleModule) { var pageConfig = { entitySchemaName: 'Account', details: /**SCHEMA_DETAILS*/{}/**SCHEMA_DETAILS*/, diff: /**SCHEMA_DIFF*/[]/**SCHEMA_DIFF*/, attributes: {}, methods: {}, rules: {}, userCode: {} } function UpdateBaseConfig(pageConfig){ //Здесь делаю запрос к таблице Relations. получаю все филиалы текущего контрагента // Обновляю структуру baseConfig.diff и baseConfig.details - добавляю детали для каждого филиала на на вкладку "история филиалов" return pageConfig; } return UpdateBaseConfig(pageConfig); });
Очень интересно Ваше мнение. Спасибо.
Здравствуйте, Игорь!
В целом, это некорректный подход, но трюк с выносом этой схемы в другой пакет может сработать. Но опять же, мастер раздела, скорее всего "не увидит" Вашего автогенерированного конфига и может возникнуть конфликт при отрисовке контролов.
Боюсь, что если мастер сгенерирует новый замещающий клиентский модуль в новом пакете, то замещённый модуль, в котором будет моя логика не отработает.
Можно ли каким-то образом обратиться к Diff при отрисовке карточки контрагента?
Вы можете унаследоваться от карточки контрагента и назвать её таким же именем.
"Олейников Владимир Владимирович" написал:Вы можете унаследоваться от карточки контрагента и назвать её таким же именем.
Не совсем понял Ваше предложение.
Я и так работаю с замещающим клиентским модулем карточки контрагента.
Думаю, что мастер раздела её просто не откроет даже, так как не распознает вашу структуру
"Олейников Владимир Владимирович" написал:Думаю, что мастер раздела её просто не откроет даже, так как не распознает вашу структуру
Открывает, ведь структура возвращается стандартная.
Вы пробовали вносить изменения? Мастер перезатирает? Или вы только так думаете?
Если я выбираю тот же пакет при открытии мастера, то при сохранении клиентский модуль перезатирается мастером.
Игорь, в самом первом комментарии я Вам написал рекомендацию по этому поводу:
"Андрей Каспаревич" написал:2) разместить свой замещающий модуль страницы в отдельном пакете, чтобы мастер разделов создавал свой модуль и не "затирал" Ваш.
Вы пробовали так сделать? Есть ли какие-то результаты?
"Андрей Каспаревич" написал:Вы пробовали так сделать? Есть ли какие-то результаты?
Да, исходный клиентский модуль не затирается, но меня смущает тот факт, что новый клиентский модуль имеет стандартную структуру и дублирует весь массив details. Не будут ли в нём отражаться детали, которые были сформированы динамически.
И ещё: каким образом можно сделать синхронный запрос к таблице Relationship для получения массива филиалов, связанных с текущим контрагентом?
Также в моём примере есть недочет - страница собирается один раз, и для того чтобы моя динамическая вкладка собралась для другого контрагента, нужно выйти обратно в реестр раздела.
Игорь, добрый день.
Проанализировав Ваш код, можем сказать что весь массив details дублироваться не будет.
Отвечая на второй вопрос, для выполнения синхронного запроса, нужно реализовать метод, одним из параметров которого, будет callback-функция:
syncRequest: function(callback, scope) {
var esq = this.Ext.create("Terrasoft.EntitySchemaQuery", {
rootSchemaName: this.entitySchemaName
});
// добавляем в запрос нужные колонки
esq.addColumn("Id");
// объявляем необходимые фильтры
esq.filters.add("primaryColumnFilter", this.Terrasoft.createColumnFilterWithParameter(
this.Terrasoft.ComparisonType.NOT_EQUAL, "Id", this.get("PrimaryColumnValue")));
esq.filters.add("nameFilter", this.Terrasoft.createColumnFilterWithParameter(
this.Terrasoft.ComparisonType.EQUAL, "Name", this.get("Name")));
esq.getEntityCollection(function(response) {
if (response && response.success) {
if (response.collection.getCount() > 0) {
result.message = “Текс ошибки”;
result.success = false;
}
// непосредственно вызов callback-метода, который будет обрабатывать результат запроса
callback.call(scope || this, response);
}
}, this);
}
}
Спасибо.
Не совсем понятно, какую функцию передавать в callback, если нам необходимо в итоге получить дополненную структуру AccountPageV2? и где выполнять перебор связанных филиалов?
Игорь, добрый день.
Проанализировали еще раз Вашу задачу, и предлагаем использовать вариант вызова запросов цепочкой :
onPreviousElementChanged: function() {
Terrasoft.chain(
function(next) {
//запрос
/*this.getPreviousElementData(function(response) {
if (this.validateResponse(response)) {
next();
}
}, this);*/
},
function(next) {
//обработка данных запросов
/*this.set("isElementChanged", true);
this.onDelayTypeChanged();
this.set("isElementChanged", false);*/
next();
},
this);
},
Спасибо.