Этот функционал представлен следующим блоком общих модулей (разбивка на наш взгляд):
1) События форм. Этот блок представлен двумя общими модулями — «События Форм» и «События Форм Клиент».
Если вернуться в статьям о механизмах минимального изменения конфигураций, то эти два модуля позволяют разместить динамически элементы и обработчики на форме и обрабатывать их. В модуле «События Форм» находится процедура «ПриСозданииНаСервере», которая вызывается из практически каждой формы в функции формы «ПриСозданииНаСервере». Соответственно в ней удобно разместить код позволяющий создавать динамически элементы на формах и обработчики событий этих форм. К примеру, можно это сделать следующим образом:
Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;
Однако разработчики предложили перенести этот код в общий модуль «МодификацияКонфигурацииПереопределяемый». И из процедуры идет еще один вызов:
МодификацияКонфигурацииПереопределяемый.ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка);
Для отработки динамических команд элементов практически в каждой форме добавлена только одна обезличенная процедура Подключаемый_ВыполнитьПереопределяемуюКоманду, обрабатывать события предлагается в специальных общих модулях – «События Форм Клиент». Решение элегантное. С общим модулем «События Форм Клиент» ситуация аналогичная, в нем происходит перевозов процедуры.
2) Модификация конфигурации. Этот блок представлен следующими общими модулями:
«Модификация Конфигурации Вызов Сервера Переопределяемый», «Модификация Конфигурации Клиент Переопределяемый», «Модификация Конфигурации Клиент Сервер Переопределяемый», «Модификация Конфигурации Переопределяемый».
В каждой форме документа коллеги вставили следующий код для поддержки механизма модификации конфигурации. На серверной части:
— В процедуре «ПриСозданииНаСервере» вызывается «СобытияФорм.ПриСозданииНаСервере»;
— В процедуре «ПриЧтенииНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПриЧтенииНаСервере»;
— В процедуре «ПослеЗаписиНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПослеЗаписиНаСервере»;
— В процедуре «ПередЗаписьюНаСервере» вызывается «МодификацияКонфигурацииПереопределяемый.ПередЗаписьюНаСервере»;
На клиентской части:
— В процедуре «ПослеЗаписи» вызывается функция «МодификацияКонфигурацииКлиентПереопределяемый.ПослеЗаписи»;
— И универсальная процедура для обработки событий для всех элементов формы на клиенте «Подключаемый_ВыполнитьПереопределяемуюКоманду».
Для обработки действий связанных с инициализацией, обработкой событий необходимо провести проверку по условию принадлежности к той или иной форме. Для этого необходимо воспользоваться свойством наименование управляемой формы, к примеру, сделать это в следующем виде:
Если Форма.Имя= «Доумент.РеализацияТоваровУслуг.ФормаДокумента» Тогда
ИначеЕсли ….
КонецЕсли;
И для обработки команд дополнительное условие:
Если Команда.Имя= «Команда_Х» Тогда
ИначеЕсли ….
КонецЕсли;
3) Особенности. К особенностям можно отнести некоторые специфические моменты.
Во-первых, пока не во всех формах и списках добавлена поддержка этого механизма. Вполне возможно, что в бедующих релизах этот пробел будет восполнен.
Во-вторых, в некоторых случаях разработчики сами используют блок динамической инициализации обработчиков изменений элементов. При первоначальном включении в их блок мы сперва очень удивились, что почему-то некоторые наши обработчики не совсем адекватно и не всегда отрабатывают в некоторых документах. Объяснение этому простое, как оказалось для документов в которых используется механизм согласование: Заказ Клиента, Реализация Товаров и Услуг и др.; используется динамическое создание подписок на события изменения элементов, которое происходит после нашей точки инициализации (в процедура При создании на сервере). На сброс флага согласован влияет множество изменений реквизитов и чтобы не обрабатывать каждый реквизит в отдельности они создают динамическую привязку события изменения к одной функции. К тому же эта операция происходит не всегда, а зависит от статусов документа.
В связи с этим при данную ситуацию необходимо обрабатывать самостоятельно, если у вас есть необходимость повестить свою обработку событий на эти реквизиты.
Зато можно воспользоваться готовой встроенной функцией для установки подписки на событие элемента формы:
ОбщегоНазначенияУТ.УстановитьПодпискуНаСобытияИзмененияЭлементовФормы(ЭтаФорма, МассивЭлементов, УстановитьПодписку);
В третьих, не все случаи по прежнему удается обрабатывать данным нововведением. Хотя это уже большой плюс. И мы выражаем глубокий респект разработчикам конфигурации ERP 2.0 за такую возможность.
4) Бонус. Правила которые мы используем при доработках типовых конфигураций.
a) Добавление своих объектов метаданных с префиксом. Мы добавляем префикс в таком формате «DI_»+наименование объекта. Иногда используется вариант добавления префикса поле наименования: наименование объект+ «DI»; но этот вариант менее нагляден. Для дополнительной фильтрации новых объектов создается своя подсистема, в которую включаются все новые объекты.
b) Добавление своих реквизитов к существующим объектам метаданных. Мы используем добавление реквизитов по аналогии с добавлением своих объектов: «DI_»+наименование реквизита.
c) Изменение форм объектов. Изменение форм объектов и подписок на элементы осуществляем динамически. Также уже используем технологию, о которой говорится выше. В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.
d) Использование модификаций запросов. В связи с нововведениями в версии платформы 8.3.5, а именно: конструктор запросов в управляемом приложении и объектная модель схемы запроса — появилась возможность более удобно вносить модификации в запросы. Если ранее пользователь создавал рваный запрос или использовал функцию СтрЗаменить, то теперь достаточно использовать объектную модель. К примеру, добавить в исходный запрос новое поле в выбранных полях:
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Запрос.Текст);
//при создании схема содержит один пакет и один оператор в пакете.
Пакет = СхемаЗапроса.ПакетЗапросов[0];
Оператор = Пакет.Операторы[0];
Оператор.ВыбираемыеПоля.Добавить(«РеализацияТоваровУслуг.Ссылка»);
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();
Ожидаем использование подобного механизма в скором будущем в текущих типовых конфигурациях.
e) Использование подписок на события. Мы используем подписки на события для дополнительных проверок, формирования своих движение и т.д. В этом случае создается необходимая подписка на событие и формируется код проверки. Позволяет не вносить изменение в типовой функционал.
f) Использование дополнительных команд. Для увеличения удобства интерактивной работы с нашими доработками довольно часто используем данный механизм.
g) Поиск точки минимального изменения или воздействия. Прежде чем вносить изменения согласно задания на доработку ищем в коде тот участок, при изменении в котором понадобится минимальное число исправлений. Как вариант возможно переписывания какой-то функции целиком.
h) Добавление реквизитов в регистры. При добавлении изменений в регистры мы поступаем по следующему правилу. Если это регистр накопления оборотный, то можем смело добавить измерение. Если это регистр накопления остатков, то в данном случае стараемся не вносить изменения в измерения и ресурсы, а создать свой новый регистр остатков. Если затрагивает реквизиты, то в данном случае можно выполнять эту операцию без проблем.
i) Комментарии и документация. При внесении изменений мы обязательно делаем комментарии, указывая Автора, Дату, Задачу, Пояснения, вход и выход изменений. Дополнительно вносится информация в реестр изменений с такими же параметрами.
j) Использование средств командной разработки. Мы используем механизм хранилище конфигурации, систему баг-трекинга, трёхуровневое тестирование – внутренне тестирование разработчиком, тестирование таксировщиком самостоятельно и по кейсам и внешнее тестирование представителем от заказчика.
k) Техническое задание. Хорошей практикой является формализация требований к доработкам. Они могут
l) Другие правила.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Какой баг-трекинг используете?
(1) newgluk, глупо сознаваться, но после всей статьи у меня возник тот же вопрос )))
(0)
К сожалению, это оказалось тестовой версией, в прочие конфигурации такое отказываются включать 🙁
Это моветон. Использовать смешанные наименования без необходимости — крайне плохо. Исключения допускаются вида WebЦвета, например, но никак не для префиксов объектов. Набор таких объектов, запросов — и Вас припомнят не раз.
(1) newgluk, jira
(3) BabySG, согласен удобнее использовать второй вариант: наименование+»DI». По факту каждое такое решение при принятии согласуется с заказчиком. Но мы настаиваем на добавлении префикса в большинстве случаев.
Надеемся что подобный механизм все таки включат в БСП. Пока такое удобство можно использовать в ERP 2.0 и УТ 11.
(0)ivanov660
c) … В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.
Зачем?! Правильней переопределить открываемую форму подпиской на ОбработкаПолученияФормы.
(6) h00k,
В некоторых случаях удобнее использовать отдельную форму без использования каких -либо обработчиков.
А замечание дельное надо добавить в текст статьи.
(5) Моветон не в том что вы делайте префикс, а в том что используйте латиницу.
(7) ivanov660
Только в случае доработки конфигурации на обычных формах. Если конфигурация на управляемых формах, то только подписку. Причем решение одинаково эффективно как для добавления реквизита на форму, так и для замены стандартной формы на свою.
Про префиксы функций: второй вариант сложнее выделить, поэтому смысл использования такого префикса сужается только до защиты от возможного дублирования имени.
Префикс в начале позволяет еще и визуально выделить «свои» участки кода.
Использование латиницы: При работе со встроенными объектами, наименования которых начинаются с символов латинского алфавита, использовать присвоение этого объекта переменной написанной на кириллице.
Пример:
Про префиксы переменных, «венгерскую» нотацию так же можно упомянуть.
Это вот, хоть и оговорка, но точно сказано.
Мой опыт обновления измененных конфигураций говорит:
изменяй существующую форму, не надо создавать свою и переопределять её ЛЮБЫМ способом.
Объясню почему, если кто не знает:
Ваша форма при обновлении не будет мешать, сравнение её просто не заметит. Типовая обновиться и останется типовой, а Ваша не затронется и новый функционал не затрется. На первый взгляд все довольны. Проблемы начинаются тогда, когда вы в первый раз запускаете в обновленной конфигурации Вашу форму и она падает с ошибкой. Причина в том, что мало какая форма живет сама по себе. Она вызывает общие процедуры, обращается к другим данным, да и к своим данным обращаются. И все это может измениться, сколько раз 1С переименовывало реквизиты, процедуры переезжали в другие модули. Данные кочевали между регистравми сведений и табличными частями.
Если изменения делать в исходной форме, то при сравнении вы увидите, что в типовой что-то изменилось, а у вас как раз там доработка. А если делать свою форму, то вы это узнаете на этапе тестирования или эксплуатации.
(12) alyaev.a.v я думаю что комментарий (11) monkbest имеет право на жизнь.
Если он, комментарий, появился, да его еще и плюсуют, то это говорит о том, что у некоторых разработчиков отсутствует этап документирования и контроля версий собственных доработок. А следовательно изменение типовой формы — единственный способ «вспомнить» где и что было изменено.
Возможно позднее они дорастут и до полностью программной модификации типовой формы через подписки, и до более сложных схем управления процессом разработки.
(0) Показали на семинаре механизм, который планируется реализовать в платформе. Он перекрывает полностью текущие реализации в УТ/УП. Но, конечно, (13) можно будет выкинуть на помойку, ибо это почти (11) 🙂
Вообще другая концепция, мозги будет сносить у многих 🙂
(13) h00k, очень сложных и запутанных схем, потом увольнения программистов, набор новых, сакральные знания не всегда передаются корректно и как итог группа программистов заводит проект в глубокую … ну ее вы знаете. И тут сложность схем играет первостепенное значение и не в лучшую сторону.
(15) Brawler, Под более сложными схемами управления разработкой подразумевается ведение разработки в соответствии с внутренними регламентами, полноценное ведение контроля версий и документирование.
Возможно вы будете удивлены, но при подобном подходе «ценность» конкретного программиста значительно снижается, и уход программиста уже не является катастрофой.
А вот если уходит программист, который только при сравнении/объединении вспоминает что и для чего было изменено, то тут как раз и происходит описываемый вами случай. Единственный владеющий «сакральными знаниями» ушел, его приемнику нужно время, много времени, чтобы понять что его предшественник «наваял», а главное зачем…
П.С.: Кстати, одна из причин, почему подобный подход отвергается некоторыми разработчиками — они осознают, что потеряют свою «исключительность» и незаменимость на проекте. А всевозможные рассуждения про нехватку времени или избыточность документирования — всего лишь отговорки.
(15) Brawler, у нас в конторе принято (наверное как и в другой) вести документацию по изменениям в проекте, поэтому если программист будет уходить, то по данной документации относительно легко включится в работу.
Со своей стороны я прикладываю усилия, чтобы в разумных рамках велась документация 🙂
(12) чем подготовка cf файла поможет по сравнению с 3х сторонним сравнением?
(13) хотел бы я посмотреть на ваше документирование и версионирование. А то все думаю как же мне задокументировать изменения форм, что-бы потом легко и просто накатывать типовые конфигурации и не потерять ничего.
(12) alyaev.a.v, я программист. Причем настоящий, у меня высшее образование IT, а не пару курсов по 1С.
Расскажите, как Вы подготавливаете cf, что эта подготовка позволяет избежать описанных мною ошибок? Если под подготовкой cf вы подразумеваете предварительное тестирование, то да, но я об этом писал
В общем с Вас методика подготовки файла cf 🙂
(13) h00k, у разработчиков есть все этапы, за которые им платят 🙂 Если заказчик готов платить за макулатуру — будет макулатура. (в случае штатного 1Сника под заказчиком понимаем его начальника).
Второе — чужая макулатура — это реально макулатура, которой только новичков пугать. Вот свои бумажки — это дело, хорошо выручает. Мы применяем не бумажки а базу написали на 1С для отслеживания измененных объектов. Но опять-таки, пользуем её, когда на это есть оплаченное время.
Третье, даже при наличии макулатуры — не исключает возможности продолбать изменение. Все мы люди и все ошибаемся.
(14) BabySG, на сколько я понимаю речь идет про «заметки из зазеркалья» изменения в технологии сравнения и объединения, которое планируется реализовать в версии 8.3.6. Поддержка трехстороннего объединения с использованием внешних компонент. Я думаю, что ничего существенного эта технология фактически не меняет, если конечно не появится внешний модуль типа AI+ 🙂
(14) BabySG, там вроде еще была просьба особенно не распространяться пока? — А так, конечно, круто и подождать теперь всего чуть-чуть.
(21) Но это ведь никакая не революция, UI элементы форм, так не по объединяешь.
никто не в курсе когда этот механизм в БП3 и ЗУП3 добавят?
Ну, наконец то 1с-ники написали информацию по давно ожидаемой фитче из зазеркалья: Расширения. Вопросы:
Когда это будет доступно пощупать (понятно что с релизом 8.3.6)?
Когда появится стабильный релиз, чтобы это можно было использовать на практике, а пока живем так как есть 🙂
Могу предложить несколько вариантов:
1. Если используете версию 8.3.6 попробовать механизм расширений, но пока он сыроват.
2. Если ваш функционал выполняется после основного кода или до основного кода, тогда можно получить код функции типового обработчика, сохранить его и вызвать в нужном месте и выполнить свой код. Пример как это делать можно посмотреть тут:
3. Внести изменения в конфигурацию в соответствии с правилами хорошего тона
4. Сделать копию формы и вызывать ее вместо основной.
Если Форма.ИмяФормы
(11) monkbest, если форма является основной формой: списка, объекта, выбора , как её изменение останется незамеченным? При сравнении-объединении сразу видно что основная форма с предыдущего релиза изменилась. Затираем основную форму формой поставщика. Поскольку мы находили точку минимального изменения, повторно внести свои изменения не составляет _никакого_ труда. Свои дополнения ты знаешь точно и не надо разбираться в тонкостях изменений, внесённых поставщиком. Про остальные формы спорить не буду, надобности не возникало.
(29) NittenRenegade, простой пример, запускаем обновление и смотрим в тройное сравнение:
1. между старым типовым релизом и старым доработанным (Вашим): в свойстве объекта «Основная форма списка» будет стоять другая форма.
2. между старым типовым и новым типовым: в форме списка добавили код, убрали пару элементов формы и изменили код вызова процедур из общего модуля, т.к. там другие параметры теперь.
1 — изменение свойств объекта
2 — изменение свойств формы
это изменения разных сущностей
1ю сущность изменяли только мы
2ю сущность изменяли только они
выставляем фильтр «показать только дважды измененные объекты» и бабац, все спряталось. Мы ведь не меняли форму, которую изменили они, они ведь не меняли объект, св-ва которого изменили мы.
Мы жмем «ОК» и продалбываем изменение.
Но потом на этапе тестирования мы видим косяк и понимаем, что надо бы дообновить. Запускаем сравнение объединение типовой старой и типовой новой, открываем нашу форму и пытаемся туда вкрячить новшества. Но «бабац» и не получается, т.к. уже 5 обновлений подряд все «прокатывало» гладко и наша форма не эквивалентна старой типовой, она эквивалентна еще более старой на 5 релизов назад форме.
(30) monkbest, по поводу:
Я так понимаю, изменения на форме стали известны из отчета о сравнении? Хочешь сказать что им удобно пользоваться? На мой взгляд там туча мелких правок, за которыми совершенно не видно общей картины. Да и деталей тоже.
При таком подходе, я уверен, что-то обязательно будет упущено. И эта погрешность будет расти с каждым изменением формы. А искать её будет сложнее, ибо разбираться придётся в чужом коде.
Второй аспект касается сравнения с использованием фильтра по дважды изменённым объектам. Это зло, с которым нужно бороться. Именно по той причине, которую ты (можно на ты?) так подробно описал.
Если у тебя на поддержке много баз, вероятно что дорабатывал их не только ты. Поэтому изменения в них могут быть самые разнообразные. Особенно это касается случаев когда ты занимаешься аутсорсингом. Здесь нужно перестраховываться каждый раз.
Если же баз не много, ты знаешь их доработки наизусть и пропустить их никак не сможешь. Проще и быстрее повторить свои изменения в форме, чем разбираться что там было добавлено, удалено, исправлено, передвинуто. А ведь есть ещё свойства, которые в отчете о сравнении просто не отображаются.
Пытаюсь по этой технологии создать кнопку на форме. Но не могу привязать к ней переопределяемую команду «Подключаемый_ВыполнитьПереопределяемуюКоманду». Как это сделать?
(32)
Может через метод «УстановитьДействие» ?
(33)
Это для элемента управления. В команде просто указывается ИмяКоманды = «МояКоманда»;
Потом в модуле формы пишешь
&НаКлиенте
Процедура МояКоманда(Каманда)
КонецПроцедуры;
И все работает. Но тут хрень какая-то.
(32) А команду вы программно создали ?
Короче разобрался. Вот код:
Общий модуль МодификацияКонфигурацииПереопределяемый
// Переопределяемая процедура, вызываемая из одноименного обработчика события формы. // // Параметры: // Форма — форма, из обработчика события которой происходит вызов процедуры. // см. справочную информацию по событиям управляемой формы. // Процедура ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка) Экспорт // {1c-aspect; rybakov@1c-aspect.ru; Начало 28.05.2018} Если Форма.ИмяФормы = «Документ.ЧекККМ.Форма.ФормаДокументаРМК» Тогда НоваяКоманда = Форма.Команды.Добавить(«aspect_TradeIn»); НоваяКоманда.Действие = «Подключаемый_ВыполнитьПереопределяемуюКоманду»; НоваяКоманда.Заголовок = «Trade-in»; НоваяКоманда.СочетаниеКлавиш = Новый СочетаниеКлавиш(Клавиша.L, Ложь, Истина, Истина); НоваяКнопка = Форма.Элементы.Добавить(«aspect_TradeIn», Тип(«КнопкаФормы»), Форма.Элементы.ГруппаВерхняяКоманднаяПанель); НоваяКнопка.Вид = ВидКнопкиФормы.ОбычнаяКнопка; НоваяКнопка.Заголовок = НоваяКоманда.Заголовок + Символы.ПС + «(Ctrl+Shift+L)»; НоваяКнопка.Ширина = 12; НоваяКнопка.Высота = 2; НоваяКнопка.ИмяКоманды = «aspect_TradeIn»; Форма.Элементы.Переместить(НоваяКнопка, Форма.Элементы.ГруппаВерхняяКоманднаяПанель, Форма.Элементы.Еще); КонецЕсли; // {1c-aspect; rybakov@1c-aspect.ru; Конец 28.05.2018} КонецПроцедурыПоказать
Общий модуль МодификацияКонфигурацииКлиентПереопределяемый
// Вызывается в формах при выборе команды, которая добавлена программно // // Параметры: // Форма — УправляемаяФорма — форма в которой расположена команда // Команда — КомандаФормы — выбранная команда // ДополнительныеПараметры — Структура — дополнительные параметры // Процедура ВыполнитьПереопределяемуюКоманду(Форма, Команда, ДополнительныеПараметры) Экспорт // {1c-aspect; rybakov@1c-aspect.ru; Начало 28.05.2018} Если Форма.ИмяФормы = «Документ.ЧекККМ.Форма.ФормаДокументаРМК» И Команда.Имя = «aspect_TradeIn» Тогда // делаем что-то КонецЕсли; // {1c-aspect; rybakov@1c-aspect.ru; Конец 28.05.2018} КонецПроцедурыПоказать
(35)Да, конечно. Разобрался. Не то действие привязывал на команду. Затупил. Ниже как должно все быть.
(37) Сейчас, к стати, в новых версиях платформы 8.3.10 или 8.3.11 можно удобно воспользоваться механизмом расширений.
(38) Поясните чем это удобнее чем добавлять элементы формы программно ?
(38)Я работаю «по старинке» :). Механизм расширений ограничен все равно. Переделывать по 5 раз не мой вариант.
(39) Во-первых, это еще один вариант изменений.
Далее, не требует снятия с поддержки,
В некоторых случаях может не требовать кодинга,
Быстрее и проще накатить изменения, а также откатить )
(40) Соглашусь, что пока еще расширения не заменяют полноценного кодинга. Но мы в некоторых решениях уже перешли на расширения и используем их постоянно (когда не много изменений и они не касаются изменений метаданных), к примеру, бухгалтерия и казначейство.
Для ERP пока используем программное изменение конфигураций уже почти 4 года.
(42)Ага. НУ у меня ситуация немного другая. Я подрядчик. Сейчас клиент хочет вот такие изменения. А через месяц может прийти задача на что-нибудь другое. И плодить изменения, сами понимаете. Одно тут, второе тут. Но хочется максимально упростить процесс изменений и обновлений. Может Вы в своей статье добавите пример моего кода?
(41)
Единственный плюс.
В остальном гемора больше.
(43)мы код чуть более оптимизированный используем: добавление программно элемента у нас вынесена в отдельную функцию, чтобы не писать каждый раз, а данные передаются параметрами в структуре. А в остальном похоже.
(45)Может дадите свой пример? Будет полезно мне)
(46) Вот пример:
Функция вставки элемента программно:
Показать
По коду вызов функции выше так:
Остальной функционал в подобном ключе.
Пытаюсь по этой технологии использовать Подключаемый_ВыполнитьПереопределяемуюКоманду
чет не пойму
имеем в итоге процедуру
ВыполнитьПереопределяемуюКоманду(Форма, Команда, ДополнительныеПараметры)
Т.е. из данных у нас только Форма, ДополнительныеПараметры — всегда неопределено
обычно, нам надо произвести некие действия с Объектом и, как правило, все делается на сервере
получить мы его можем только так: Форма.Объект
так вот — как передать на сервер и получить обратно этот Объект
Как решить такую задачу ?
(48)
Вообщем, сам извернулся, передавая, ДанныеФормыКоллекция как элемент структуры