gifts2017

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

Опубликовал ivanov660 ivanov660 (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)        Другие правила.

 

См. также

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

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

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

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

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

Зачем?! Правильней переопределить открываемую форму подпиской на ОбработкаПолученияФормы.
7. ivanov660 ivanov660 (ivanov660) 23.09.14 13:22
(6) h00k,
В некоторых случаях удобнее использовать отдельную форму без использования каких -либо обработчиков.
А замечание дельное надо добавить в текст статьи.
8. Dim Dragonim (Dragonim) 23.09.14 13:26
(5) Моветон не в том что вы делайте префикс, а в том что используйте латиницу.
smartem; hulio; Ovrfox; NoRazum; Зеленоград; Taktic; CratosX; ojiojiowka; philya; ZLENKO; sivalor; ktb; Brawler; Yimaida; +14 Ответить
9. Андрей (h00k) 23.09.14 13:51
(7) ivanov660
В некоторых случаях удобнее использовать отдельную форму без использования каких -либо обработчиков

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

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

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


Про префиксы переменных, "венгерскую" нотацию так же можно упомянуть.
Восьмой; mythos; МимохожийОднако; +3 Ответить
10. Антон Рощин (wolfsoft) 24.09.14 10:40
в бедующих релизах

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


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

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

Если изменения делать в исходной форме, то при сравнении вы увидите, что в типовой что-то изменилось, а у вас как раз там доработка. А если делать свою форму, то вы это узнаете на этапе тестирования или эксплуатации.
Pipapalamm; nayd; AShley; alest; Ovrfox; Федосеев; Восьмой; freez1301; mythos; Bazil; CratosX; MRAK; Рамзес; ojiojiowka; philya; ZLENKO; sivalor; KapasMordorov; ВРедная; vasiliy_b; ktb; Brawler; swimdog; pumbaE; +24 2 Ответить 4
12. Александр Аляев (alyaev.a.v) 26.09.14 15:42
(11) monkbest, По-моему это ответ не программиста, а бухгалтера.Если правильно обновлять, еще раз подчеркиваю, правильно обновлять, с подготовкой цф файла, а не просто накатить новый релиз, то новая форма никак не нарвется на описываемые Вами грабли.
13. Андрей (h00k) 26.09.14 17:52
(12) alyaev.a.v я думаю что комментарий (11) monkbest имеет право на жизнь.
Если он, комментарий, появился, да его еще и плюсуют, то это говорит о том, что у некоторых разработчиков отсутствует этап документирования и контроля версий собственных доработок. А следовательно изменение типовой формы - единственный способ "вспомнить" где и что было изменено.
Возможно позднее они дорастут и до полностью программной модификации типовой формы через подписки, и до более сложных схем управления процессом разработки.
CratosX; Redokov; Serikpai; +3 Ответить 4
14. BabySG (BabySG) 29.09.14 10:14
(0) Показали на семинаре механизм, который планируется реализовать в платформе. Он перекрывает полностью текущие реализации в УТ/УП. Но, конечно, (13) можно будет выкинуть на помойку, ибо это почти (11) :)
Вообще другая концепция, мозги будет сносить у многих :)
ildarovich; +1 Ответить 2
15. Игорь Фелькер (Brawler) 29.09.14 10:17
(13) h00k, очень сложных и запутанных схем, потом увольнения программистов, набор новых, сакральные знания не всегда передаются корректно и как итог группа программистов заводит проект в глубокую ... ну ее вы знаете. И тут сложность схем играет первостепенное значение и не в лучшую сторону.
Восьмой; +1 Ответить 2
16. Андрей (h00k) 29.09.14 12:31
(15) Brawler, Под более сложными схемами управления разработкой подразумевается ведение разработки в соответствии с внутренними регламентами, полноценное ведение контроля версий и документирование.

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

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

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

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


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

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


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

Все это замечательно работает при открытии имеющихся в базе документов (или создании новых если создаются из списка с отбором по партнеру). Но как только речь заходит о создании нового документа и обработке события "ПриИзменении" элемента формы "Партнер". Вот тут совершенно непонятно что же должно быть написано в процедуре "ВыполнитьПереопределяемуюКоманду" модуля "МодификацияКонфигурацииКлиентПереопределяемый". Дело в том что наше действие полностью заменяет типовое. Вызвать типовой обработчик, не являющийся экспортным, из переопределяемого не представляется возможным.
Я правильно понимаю что единственным вариантом является копирование кода типового обработчика с внесением необходимых дополнений. Это приведет к необходимости ручной актуализации данного кода при обновлении типовой. Но других вариантов сделать это без правки формы просто не существует? Как бы Вы поступили в данной ситуации.
Размер вносимых изменений в форму казалось бы плевый - всего-то один элемент управления. Я что-то упустил? Глаз замылился?
27. ivanov660 ivanov660 (ivanov660) 31.07.15 15:19
Могу предложить несколько вариантов:
1. Если используете версию 8.3.6 попробовать механизм расширений, но пока он сыроват.
2. Если ваш функционал выполняется после основного кода или до основного кода, тогда можно получить код функции типового обработчика, сохранить его и вызвать в нужном месте и выполнить свой код. Пример как это делать можно посмотреть тут: Переопределение и вызов обработчиков событий для УФ 1С
3. Внести изменения в конфигурацию в соответствии с правилами хорошего тона
4. Сделать копию формы и вызывать ее вместо основной.

1c.pro.fun; +1 Ответить
28. Vald T (2tvad) 24.09.15 11:26
Если Форма.Имя


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

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

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


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

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

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

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