Типовой механизм упрощенного изменения конфигурации в ERP 2.0 и УТ 11

Опубликовал ivanov660 в раздел Программирование - Инструментарий

В ERP 2.0 (и соответственно в УТ 11) появился функционал для упрощенной возможности модификации конфигурации разработчиками. Он касается в частности изменения форм объектов и размещения подписок на элементы, теперь задача изменения конфигурации на поддержке упростилась. Также появились дополнительные возможности в новой версии платформы 8.3.5, которые также упростят задчу.

Этот функционал представлен следующим блоком общих модулей (разбивка на наш взгляд):

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)        Другие правила.

 

См. также

Лучшие комментарии

11. monkbest 26.09.2014 12:00
c) Изменение форм объектов. Изменение форм объектов и подписок на элементы осуществляем динамически. Также уже используем технологию, о которой говорится выше. В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.


Мой опыт обновления измененных конфигураций говорит:
изменяй существующую форму, не надо создавать свою и переопределять её ЛЮБЫМ способом.

Объясню почему, если кто не знает:
Ваша форма при обновлении не будет мешать, сравнение её просто не заметит. Типовая обновиться и останется типовой, а Ваша не затронется и новый функционал не затрется. На первый взгляд все довольны. Проблемы начинаются тогда, когда вы в первый раз запускаете в обновленной конфигурации Вашу форму и она падает с ошибкой. Причина в том, что мало какая форма живет сама по себе. Она вызывает общие процедуры, обращается к другим данным, да и к своим данным обращаются. И все это может измениться, сколько раз 1С переименовывало реквизиты, процедуры переезжали в другие модули. Данные кочевали между регистравми сведений и табличными частями.

Если изменения делать в исходной форме, то при сравнении вы увидите, что в типовой что-то изменилось, а у вас как раз там доработка. А если делать свою форму, то вы это узнаете на этапе тестирования или эксплуатации.
Ответили: (12) (13) (14) (29)
− 1 [ NittenRenegade; ]
# Ответить
8. Dragonim 23.09.2014 13:26
(5) Моветон не в том что вы делайте префикс, а в том что используйте латиницу.
# Ответить
3. BabySG 23.09.2014 10:50
(0)
И мы выражаем глубокий респект разработчикам конфигурации ERP 2.0 за такую возможность.

К сожалению, это оказалось тестовой версией, в прочие конфигурации такое отказываются включать :(

Мы добавляем префикс в таком формате «DI_»+наименование объекта

Это моветон. Использовать смешанные наименования без необходимости - крайне плохо. Исключения допускаются вида WebЦвета, например, но никак не для префиксов объектов. Набор таких объектов, запросов - и Вас припомнят не раз.
Ответили: (5)
# Ответить

Комментарии

1. newgluk 23.09.2014 07:18
Какой баг-трекинг используете?
Ответили: (2) (4)
# Ответить
2. mmed 23.09.2014 10:34
(1) newgluk, глупо сознаваться, но после всей статьи у меня возник тот же вопрос )))
# Ответить
3. BabySG 23.09.2014 10:50
(0)
И мы выражаем глубокий респект разработчикам конфигурации ERP 2.0 за такую возможность.

К сожалению, это оказалось тестовой версией, в прочие конфигурации такое отказываются включать :(

Мы добавляем префикс в таком формате «DI_»+наименование объекта

Это моветон. Использовать смешанные наименования без необходимости - крайне плохо. Исключения допускаются вида WebЦвета, например, но никак не для префиксов объектов. Набор таких объектов, запросов - и Вас припомнят не раз.
Ответили: (5)
# Ответить
4. ivanov660 23.09.2014 12:40
(1) newgluk, jira
# Ответить
5. ivanov660 23.09.2014 12:55
(3) BabySG, согласен удобнее использовать второй вариант: наименование+"DI". По факту каждое такое решение при принятии согласуется с заказчиком. Но мы настаиваем на добавлении префикса в большинстве случаев.
Надеемся что подобный механизм все таки включат в БСП. Пока такое удобство можно использовать в ERP 2.0 и УТ 11.
Ответили: (8)
# Ответить
6. h00k 23.09.2014 13:16
(0)ivanov660

c) ... В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.

Зачем?! Правильней переопределить открываемую форму подпиской на ОбработкаПолученияФормы.
Ответили: (7)
# Ответить
7. ivanov660 23.09.2014 13:22
(6) h00k,
В некоторых случаях удобнее использовать отдельную форму без использования каких -либо обработчиков.
А замечание дельное надо добавить в текст статьи.
Ответили: (9)
# Ответить
8. Dragonim 23.09.2014 13:26
(5) Моветон не в том что вы делайте префикс, а в том что используйте латиницу.
# Ответить
9. h00k 23.09.2014 13:51
(7) ivanov660
В некоторых случаях удобнее использовать отдельную форму без использования каких -либо обработчиков

Только в случае доработки конфигурации на обычных формах. Если конфигурация на управляемых формах, то только подписку. Причем решение одинаково эффективно как для добавления реквизита на форму, так и для замены стандартной формы на свою.

Про префиксы функций: второй вариант сложнее выделить, поэтому смысл использования такого префикса сужается только до защиты от возможного дублирования имени.
Префикс в начале позволяет еще и визуально выделить "свои" участки кода.

Использование латиницы: При работе со встроенными объектами, наименования которых начинаются с символов латинского алфавита, использовать присвоение этого объекта переменной написанной на кириллице.
Пример:
лВебЦвета = WebЦвета;
лВебЦвета.Бирюзовый;


Про префиксы переменных, "венгерскую" нотацию так же можно упомянуть.
# Ответить
10. wolfsoft 24.09.2014 10:40
в бедующих релизах

Это вот, хоть и оговорка, но точно сказано.
+ 2 [ mythos; CratosX; ]
# Ответить
11. monkbest 26.09.2014 12:00
c) Изменение форм объектов. Изменение форм объектов и подписок на элементы осуществляем динамически. Также уже используем технологию, о которой говорится выше. В случае, когда требуется кардинальное изменение формы объектов, то мы создаем свою форму и назначаем ее основной.


Мой опыт обновления измененных конфигураций говорит:
изменяй существующую форму, не надо создавать свою и переопределять её ЛЮБЫМ способом.

Объясню почему, если кто не знает:
Ваша форма при обновлении не будет мешать, сравнение её просто не заметит. Типовая обновиться и останется типовой, а Ваша не затронется и новый функционал не затрется. На первый взгляд все довольны. Проблемы начинаются тогда, когда вы в первый раз запускаете в обновленной конфигурации Вашу форму и она падает с ошибкой. Причина в том, что мало какая форма живет сама по себе. Она вызывает общие процедуры, обращается к другим данным, да и к своим данным обращаются. И все это может измениться, сколько раз 1С переименовывало реквизиты, процедуры переезжали в другие модули. Данные кочевали между регистравми сведений и табличными частями.

Если изменения делать в исходной форме, то при сравнении вы увидите, что в типовой что-то изменилось, а у вас как раз там доработка. А если делать свою форму, то вы это узнаете на этапе тестирования или эксплуатации.
Ответили: (12) (13) (14) (29)
− 1 [ NittenRenegade; ]
# Ответить
12. alyaev.a.v 26.09.2014 15:42
(11) monkbest, По-моему это ответ не программиста, а бухгалтера.Если правильно обновлять, еще раз подчеркиваю, правильно обновлять, с подготовкой цф файла, а не просто накатить новый релиз, то новая форма никак не нарвется на описываемые Вами грабли.
Ответили: (13) (18) (19)
# Ответить
13. h00k 26.09.2014 17:52
(12) alyaev.a.v я думаю что комментарий (11) monkbest имеет право на жизнь.
Если он, комментарий, появился, да его еще и плюсуют, то это говорит о том, что у некоторых разработчиков отсутствует этап документирования и контроля версий собственных доработок. А следовательно изменение типовой формы - единственный способ "вспомнить" где и что было изменено.
Возможно позднее они дорастут и до полностью программной модификации типовой формы через подписки, и до более сложных схем управления процессом разработки.
Ответили: (14) (15) (18) (20)
+ 3 [ CratosX; Redokov; Serikpai; ]
# Ответить
14. BabySG 29.09.2014 10:14
(0) Показали на семинаре механизм, который планируется реализовать в платформе. Он перекрывает полностью текущие реализации в УТ/УП. Но, конечно, (13) можно будет выкинуть на помойку, ибо это почти (11) :)
Вообще другая концепция, мозги будет сносить у многих :)
Ответили: (21) (22)
+ 1 [ ildarovich; ]
# Ответить
15. Brawler 29.09.2014 10:17
(13) h00k, очень сложных и запутанных схем, потом увольнения программистов, набор новых, сакральные знания не всегда передаются корректно и как итог группа программистов заводит проект в глубокую ... ну ее вы знаете. И тут сложность схем играет первостепенное значение и не в лучшую сторону.
Ответили: (16) (17)
+ 1 [ Восьмой; ]
# Ответить
16. h00k 29.09.2014 12:31
(15) Brawler, Под более сложными схемами управления разработкой подразумевается ведение разработки в соответствии с внутренними регламентами, полноценное ведение контроля версий и документирование.

Возможно вы будете удивлены, но при подобном подходе "ценность" конкретного программиста значительно снижается, и уход программиста уже не является катастрофой.

А вот если уходит программист, который только при сравнении/объединении вспоминает что и для чего было изменено, то тут как раз и происходит описываемый вами случай. Единственный владеющий "сакральными знаниями" ушел, его приемнику нужно время, много времени, чтобы понять что его предшественник "наваял", а главное зачем...

П.С.: Кстати, одна из причин, почему подобный подход отвергается некоторыми разработчиками - они осознают, что потеряют свою "исключительность" и незаменимость на проекте. А всевозможные рассуждения про нехватку времени или избыточность документирования - всего лишь отговорки.
+ 1 [ 1cWin; ]
# Ответить
17. ivanov660 29.09.2014 16:43
(15) Brawler, у нас в конторе принято (наверное как и в другой) вести документацию по изменениям в проекте, поэтому если программист будет уходить, то по данной документации относительно легко включится в работу.
Со своей стороны я прикладываю усилия, чтобы в разумных рамках велась документация :-)
# Ответить
18. pumbaE 30.09.2014 15:40
(12) чем подготовка cf файла поможет по сравнению с 3х сторонним сравнением?

(13) хотел бы я посмотреть на ваше документирование и версионирование. А то все думаю как же мне задокументировать изменения форм, что-бы потом легко и просто накатывать типовые конфигурации и не потерять ничего.
+ 3 [ hulio; Urupa; monkbest; ]
# Ответить
19. monkbest 01.10.2014 18:59
(12) alyaev.a.v, я программист. Причем настоящий, у меня высшее образование IT, а не пару курсов по 1С.
Расскажите, как Вы подготавливаете cf, что эта подготовка позволяет избежать описанных мною ошибок? Если под подготовкой cf вы подразумеваете предварительное тестирование, то да, но я об этом писал
вы это узнаете на этапе тестирования или эксплуатации


В общем с Вас методика подготовки файла cf :)
# Ответить
20. monkbest 01.10.2014 19:08
(13) h00k, у разработчиков есть все этапы, за которые им платят :) Если заказчик готов платить за макулатуру - будет макулатура. (в случае штатного 1Сника под заказчиком понимаем его начальника).
Второе - чужая макулатура - это реально макулатура, которой только новичков пугать. Вот свои бумажки - это дело, хорошо выручает. Мы применяем не бумажки а базу написали на 1С для отслеживания измененных объектов. Но опять-таки, пользуем её, когда на это есть оплаченное время.
Третье, даже при наличии макулатуры - не исключает возможности продолбать изменение. Все мы люди и все ошибаемся.
# Ответить
21. ivanov660 01.10.2014 19:32
(14) BabySG, на сколько я понимаю речь идет про "заметки из зазеркалья" изменения в технологии сравнения и объединения, которое планируется реализовать в версии 8.3.6. Поддержка трехстороннего объединения с использованием внешних компонент. Я думаю, что ничего существенного эта технология фактически не меняет, если конечно не появится внешний модуль типа AI+ :-)
Ответили: (23)
# Ответить
22. ildarovich 01.10.2014 20:08
(14) BabySG, там вроде еще была просьба особенно не распространяться пока? - А так, конечно, круто и подождать теперь всего чуть-чуть.
# Ответить
23. pumbaE 02.10.2014 08:41
(21) ivanov660, так что-ли? Но это ведь никакая не революция, UI элементы форм, так не по объединяешь.
# Ответить
24. kauksi 03.10.2014 14:26
никто не в курсе когда этот механизм в БП3 и ЗУП3 добавят?
# Ответить
25. ivanov660 02.12.2014 15:00
Ну, наконец то 1с-ники написали информацию по давно ожидаемой фитче из зазеркалья: Расширения. Вопросы:
Когда это будет доступно пощупать (понятно что с релизом 8.3.6)?
Когда появится стабильный релиз, чтобы это можно было использовать на практике, а пока живем так как есть :-)
Ответили: (26)
# Ответить
26. 1c.pro.fun 31.07.2015 00:52
(25) ivanov660, есть вопрос по поводу применимости данного метода к одной конкретной задаче (с УТ 11 работаю совсем недавно - не обессудьте). Стоит задача в форме документа "Заказ клиента" вывести информацию о текущем долге на момент времени документа. Естественно хочется все сделать без модифицирования формы документа. Вписал вот такой код в модуле "МодификацияКонфигурацииПереопределяемый":

Процедура ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка) Экспорт
	
	Если Форма.ИмяФормы = "Документ.ЗаказКлиента.Форма.ФормаДокумента" Тогда
	
		// Вывод на форму текущего долга клиента на дату заказа
		ДобавляемыеРеквизиты = Новый Массив;
		ДобавляемыеРеквизиты.Добавить(Новый РеквизитФормы("ТекущийДолг", Новый ОписаниеТипов("Строка")));
		Форма.ИзменитьРеквизиты(ДобавляемыеРеквизиты);
		
		Если ЗначениеЗаполнено(Форма.Объект.Партнер) Тогда
		
			Запрос = Новый Запрос;
			Запрос.Текст = "ВЫБРАТЬ
			|	РасчетыСКлиентамиОстатки.СуммаОстаток КАК Долг
			|ИЗ
			|	РегистрНакопления.РасчетыСКлиентами.Остатки(
			|			&Период,
			|			АналитикаУчетаПоПартнерам В
			|				(ВЫБРАТЬ
			|					КлючиАналитикиУчетаПоПартнерам.Ссылка
			|				ИЗ
			|					Справочник.КлючиАналитикиУчетаПоПартнерам КАК КлючиАналитикиУчетаПоПартнерам
			|				ГДЕ
			|					КлючиАналитикиУчетаПоПартнерам.Партнер = &Партнер)) КАК РасчетыСКлиентамиОстатки";
			
			Запрос.УстановитьПараметр("Партнер",	Форма.Объект.Партнер);
			Запрос.УстановитьПараметр("Период",		Новый МоментВремени(Форма.Объект.Дата, Форма.Объект.Ссылка));
			
			Результат = Запрос.Выполнить();
			Выборка = Результат.Выбрать();
			
			Если Выборка.Следующий() Тогда
				Форма.ТекущийДолг	= Выборка.Долг;
			Иначе
			    Форма.ТекущийДолг	= "Отсутствует";
			КонецЕсли;
		
		Иначе
			Форма.ТекущийДолг	= "Не рассчитан";
		КонецЕсли;
				
		ПолеТекущийДолг = Форма.Элементы.Добавить("НадписьТекущийДолг", Тип("ПолеФормы"), Форма.Элементы.ГруппаСтатусПриоритет);
		ПолеТекущийДолг.Вид			= ВидПоляФормы.ПолеНадписи;
		ПолеТекущийДолг.ПутьКДанным	= "ТекущийДолг";
		ПолеТекущийДолг.Заголовок	= "Текущий долг";
		
		Форма.Элементы.Партнер.УстановитьДействие("ПриИзменении", "Подключаемый_ВыполнитьПереопределяемуюКоманду");
	
	КонецЕсли;
	
КонецПроцедуры
...Показать Скрыть


Если лень читать код полностью, то я:
1. создаю реквизит управляемой формы
2. вычисляю долг
3. присваиваю реквизиту значение долга
4. создаю элемент управления, связанный с реквизитом для вывода на форму.

Все это замечательно работает при открытии имеющихся в базе документов (или создании новых если создаются из списка с отбором по партнеру). Но как только речь заходит о создании нового документа и обработке события "ПриИзменении" элемента формы "Партнер". Вот тут совершенно непонятно что же должно быть написано в процедуре "ВыполнитьПереопределяемуюКоманду" модуля "МодификацияКонфигурацииКлиентПереопределяемый". Дело в том что наше действие полностью заменяет типовое. Вызвать типовой обработчик, не являющийся экспортным, из переопределяемого не представляется возможным.
Я правильно понимаю что единственным вариантом является копирование кода типового обработчика с внесением необходимых дополнений. Это приведет к необходимости ручной актуализации данного кода при обновлении типовой. Но других вариантов сделать это без правки формы просто не существует? Как бы Вы поступили в данной ситуации.
Размер вносимых изменений в форму казалось бы плевый - всего-то один элемент управления. Я что-то упустил? Глаз замылился?
# Ответить
27. ivanov660 31.07.2015 15:19
Могу предложить несколько вариантов:
1. Если используете версию 8.3.6 попробовать механизм расширений, но пока он сыроват.
2. Если ваш функционал выполняется после основного кода или до основного кода, тогда можно получить код функции типового обработчика, сохранить его и вызвать в нужном месте и выполнить свой код. Пример как это делать можно посмотреть тут: Переопределение и вызов обработчиков событий для УФ 1С
3. Внести изменения в конфигурацию в соответствии с правилами хорошего тона
4. Сделать копию формы и вызывать ее вместо основной.
+ 1 [ 1c.pro.fun; ]
# Ответить
28. 2tvad 24.09.2015 11:26
Если Форма.Имя


Если Форма.ИмяФормы
# Ответить
29. NittenRenegade 10.11.2015 10:18
(11) monkbest, если форма является основной формой: списка, объекта, выбора , как её изменение останется незамеченным? При сравнении-объединении сразу видно что основная форма с предыдущего релиза изменилась. Затираем основную форму формой поставщика. Поскольку мы находили точку минимального изменения, повторно внести свои изменения не составляет _никакого_ труда. Свои дополнения ты знаешь точно и не надо разбираться в тонкостях изменений, внесённых поставщиком. Про остальные формы спорить не буду, надобности не возникало.
Ответили: (30)
# Ответить
30. monkbest 10.11.2015 16:56
(29) NittenRenegade, простой пример, запускаем обновление и смотрим в тройное сравнение:
1. между старым типовым релизом и старым доработанным (Вашим): в свойстве объекта "Основная форма списка" будет стоять другая форма.
2. между старым типовым и новым типовым: в форме списка добавили код, убрали пару элементов формы и изменили код вызова процедур из общего модуля, т.к. там другие параметры теперь.

1 - изменение свойств объекта
2 - изменение свойств формы
это изменения разных сущностей
1ю сущность изменяли только мы
2ю сущность изменяли только они
выставляем фильтр "показать только дважды измененные объекты" и бабац, все спряталось. Мы ведь не меняли форму, которую изменили они, они ведь не меняли объект, св-ва которого изменили мы.
Мы жмем "ОК" и продалбываем изменение.

Но потом на этапе тестирования мы видим косяк и понимаем, что надо бы дообновить. Запускаем сравнение объединение типовой старой и типовой новой, открываем нашу форму и пытаемся туда вкрячить новшества. Но "бабац" и не получается, т.к. уже 5 обновлений подряд все "прокатывало" гладко и наша форма не эквивалентна старой типовой, она эквивалентна еще более старой на 5 релизов назад форме.
Ответили: (31)
+ 1 [ alest; ]
# Ответить
31. NittenRenegade 16.11.2015 13:31
(30) monkbest, по поводу:
2. между старым типовым и новым типовым: в форме списка добавили код, убрали пару элементов формы и изменили код вызова процедур из общего модуля, т.к. там другие параметры теперь.


Я так понимаю, изменения на форме стали известны из отчета о сравнении? Хочешь сказать что им удобно пользоваться? На мой взгляд там туча мелких правок, за которыми совершенно не видно общей картины. Да и деталей тоже.
При таком подходе, я уверен, что-то обязательно будет упущено. И эта погрешность будет расти с каждым изменением формы. А искать её будет сложнее, ибо разбираться придётся в чужом коде.

Второй аспект касается сравнения с использованием фильтра по дважды изменённым объектам. Это зло, с которым нужно бороться. Именно по той причине, которую ты (можно на ты?) так подробно описал.

Если у тебя на поддержке много баз, вероятно что дорабатывал их не только ты. Поэтому изменения в них могут быть самые разнообразные. Особенно это касается случаев когда ты занимаешься аутсорсингом. Здесь нужно перестраховываться каждый раз.

Если же баз не много, ты знаешь их доработки наизусть и пропустить их никак не сможешь. Проще и быстрее повторить свои изменения в форме, чем разбираться что там было добавлено, удалено, исправлено, передвинуто. А ведь есть ещё свойства, которые в отчете о сравнении просто не отображаются.
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл






IE 2016