В карточке сотрудника нужно вместо поля Photo из контакта отображать другое поле.
Каким образом можно это реализовать, если в карточке сотрудника метод init() реализован таким образом:
init: function() {
this.primaryImageColumnName = "ContactPhoto";
this.on("change:OrgStructureUnit", this.onChangedOrgStructureUnit, this);
this.callParent(arguments);
},
То есть мне нужно, чтобы в моей карточке сотрудника в init были 2-я и 3-я строчки, а первая нет.
Но из-за описанной выше реализации, я не могу теперь реализовать свой код просто добавив свою логику и после вызвать родительскую.
Можно ли вообще каким-то образом указать, чтобы в моем методе вызывались 2-я и 3-я строчки, именно из тех карточек, из которых нужно, а не из непосредственного родителя?
Нравится
Григорий Чех,
Допустим, и что дальше?
В карточке редактирования реализован определенный механизм отображения картинки, в котором в любом случае нужно указать this.primaryImageColumnName.
В init
this.callParent(arguments);
this.set(this.primaryImageColumnName, null);
Григорий Чех,
Не уверенна, что так заработает, но можно попробовать.
Григорий Чех,
Хотелось бы по данному вопросу услышать комментарий службы поддержки!
Можно попробовать заместить модуль, в котором описана данная логика
init: function() {
this.primaryImageColumnName = "ContactPhoto"; this.on("change:OrgStructureUnit",this.onChangedOrgStructureUnit, this);
this.callParent(arguments);
}
Переписав тот же самый код (без первой строки), а в наследниках уже дополнить метод под каждую карточку отдельно
Колодяжный Владислав Эдуардович,
Да, но проблема в том, что в базовую карточку сотрудника я не могу вносить изменения, потому и не могу изменить в ней наследника.
С таким подходом я могу реализовать и свой раздел с нужной логикой, но смысл тогда в базовых разделах, особенно, таком, как сотрудники.
Весь вопрос в том, что метод реализован некорректно и, если бы код в 1-й и 2-й строчке метода init был вынесен в другую функцию, то никаких бы сложностей не возникло.
Мне нужно было бы всего-то переопределить эту функцию и все.
но смысл тогда в базовых разделах, особенно, таком, как сотрудники.
Смысл, внезапно, в ведении информации о сотрудниках.
Весь вопрос в том, что метод реализован некорректно
Метод реализован корректно. Фото выводится.
По поводу обнуления после вызова this.callParent(arguments), то в странице SysProcessUserTaskPage есть такое обнуление:
onImageChange: function(image) { if (!image) { this.set(this.primaryImageColumnName, null); return; }
То есть присваивание значения с последующим его удалением, в принципе, может работать. Но доработанную логику нужно тестировать.
Зверев Александр пишет:
Смысл, внезапно, в ведении информации о сотрудниках.
Я имела ввиду другой смысл использования базовых разделов: зачем изобретать велосипед, если его уже изобрели до меня.
Если реализован раздел сотрудники в базовой версии, то зачем мне реализовывать свой раздел, если я могу использовать его немного доработав под свои нужды.
Зверев Александр пишет:
Метод реализован корректно. Фото выводится.
Да, этот метод рабочий - фото выводится. Можно сказать с этой точки зрения, что он реализован корректно, но вот с точки зрения последующей работы с ним, как показала практика, совсем некорректно.
Зверев Александр пишет:
Но доработанную логику нужно тестировать.
Да, теперь мне придется, чтобы доработать свою логику, "забить" костыль 
Я немного в шоке. Вместо пары строк кода вы развели вайн на пару страниц.
init: function(callback, scope) { //сначала вызовутся родительские init-методы this.callParent([function() { debugger; //тут можно занулить this.primaryImageColumnName callback.call(scope); }, this]); }
Зверев Александр,
Это всё замечательно, но вот ситуация: я захотел заместить в одной схеме ViewModel. Модули (внезапно!) с 7.13 замещать нельзя. Ну ок, делаем свой через extend. Лезем в схему, а там прямо в init зашита сторчка а-ля:
this.viewModelName = '123'; this.callParent(arguments);
Ну клёво теперь. И как в таком случае менять что-либо? (принимая во внимание, что 95% пользователей не знают о коде выше). Делать сначала callParent, а потом простановку своего viewModelName — бред. Привет асинхронность, непонятно какое присвоение выполнится первее. Таймауты/деферы - костыль. Так-то вынести всю кастомную логику из init в отдельную функцию - правильнее будет.
PS. Пользуясь случаем - какой гений догадался запретить перегруз модулей?
Если есть идеи по разработке собственного раздела сотрудников, улучшенного по сравнению со стандартным, можно его выпустить и продавать в маркете.
Варфоломеев Данила пишет:
Так-то вынести всю кастомную логику из init в отдельную функцию - правильнее будет
Так вот об этом же и речь, что нужно не только реализовать "шоб работало", но и так, чтобы потом с этим другие могли работать!
Тут палка о двух концах. Если вообще всё выносить в отдельные функции, в ожидании, что кто-то захочет их переопределить, то сам код станет более громоздким и хуже читаемым. Хотя и более структурируемым. Видимо, при создании этой функции не предполагалась потребность в смене поля с картинкой.
В 3.Х и 5.Х не было разграничений по пакетам, весь код доступен для изменений, но там и нет автоматизации обновления конфигурации на новые версии.