gifts2017

v8: Концепция минимального изменения конфигурации для легкого обновления

Опубликовал Сергей Марченко (MarSeN) в раздел Программирование - Теория программирования

"Лучше день потерять потом за пять минут долететь" ((с) "Крылья, ноги и хвосты") или как сделать так чтобы обновление конфигурации проходило с минимальными трудозатратами.

 

 

 

 

Структура статьи:

  1. Цель
  2. Концепция
  3. Объекты системы без четкого описания методики изменения
  4. Методики

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

 

ЦЕЛЬ

Модификация конфигурации, находящейся на поддержке, с возможностью последующего «быстрого обновления».

 

КОНЦЕПЦИЯ ИЗМЕНЕНИЙ

  1. Минимальная правка кода в модулях конфигурации.  Все требуемые изменения нужно выносить в общие модули или модули менеджеров новых объектов (справочников / регистров / обработок),  логически связанных с вносимыми изменениями.
  2. Отказ от «непосредственного» изменения текстов запросов. Касается как запросов расположенных в текстах модулей, так и запросов-источников динамических списков.
  3. Отказ от изменения форм объектов на уровне конструктора форм. Использование только программного (при помощи написанного кода) способа. Речь идет не только о добавлении/изменении элементов форм, но и о добавлении реквизитов форм, событий элементов форм (и самой формы) и условного оформления форм.
  4. Максимальное использование подписок на события.   

 

ОБЪЕКТЫ СИСТЕМЫ БЕЗ ЧЕТКОГО ОПИСАНИЯ МЕТОДИКИ ИЗМЕНЕНИЙ

  1. Изменение ролей
  2. Изменение функциональных опций
  3. Изменение состава реквизитов
  4. Изменение состава регистраторов
  5. Изменение состава общих команд
  6. Изменение схем компановки данных

 

МЕТОДИКИ

  1. Комментарии к изменениям.  Считается хорошим тоном, а в случае изменения модуля, находящегося на поддержке являются обязательными комментарии с открывающимися и закрывающимися «тегами» к программному коду который вы внесли/модифицировали. Обычный минимум – это дата изменения и «ФИО» разработчика. Плюсом будет номер тикета или краткое описание изменений. 
  2. Минимальная правка кода в модулях конфигурации.  Руководствуемся «достаточным» минимумом изменений.  Конечно, если Ваши изменения в объеме 1-3 строки, то не стоит для этого их выносить в отдельный модуль.  В случае если код «большой» или он используется в нескольких местах, выносим его из  тела модуля.

Все вызовы функций/процедур воспринимаем как некий «черный ящик» у которого есть параметры/источники данных (передаваемые или общие)  на вход и результат на выходе.  Если мы можем изменить входные параметры таким образом, чтобы «метод» вернул нам требуемый результат – меняем входные параметры (передаем их в нашу процедуру/функцию) и там их переопределяем. Если есть возможность изменить/дополнить данные на выходе – вызываем наш метод после.  В случае невозможности «подменить» входные/выходные параметры принимаем решение: либо разбираемся-«осветляем» ящик и ищем «точку входа» в нем, либо пишем свой метод взамен текущего.

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

Если есть некая конструкция кода с условиями и циклами, результат которого вам «не подходит» после нее напишите свой и «переопределите»  результат. Нужно ли комментировать исходный код зависит от его ресурсоемкости. Желательно его оставить «как есть».

Свои процедуры и функции можно располагать в новых общих модулях или менеджерах Ваших новых объектов. К примеру, если Вы создали справочник «Номенклатура клиентов» и в печатных формах Вам нужно модифицировать запрос таким образом чтоб вместо артикула номенклатуры компании выводился артикул клиента – процедуру модификации запроса целесообразней расположить именно в модуле менеджера справочника «Номенклатура клиентов».

По возможности стараемся не менять обработчики событий форм. О переопределении обработчиков событий, их «отключении» без модификации самих обработчиков и формы см. в разделе «Отказ от изменения форм объектов на уровне конструктора форм»

 3. Отказ от «непосредственного» изменения текстов запросов. Часто используемым подходом к изменению текста запросов является «непосредственное» изменение запроса с закомментированными в нем «исходными» блоками. Основной недостаток такого подхода – при случайном или необдуманном использовании конструктора запросов «слетают» комментарии и «куски» закомментированного запроса от поставщика конфигурации.  Другой способ – копирование и модификация исходного запроса целиком в своей процедуре и последующая подстановка нового запроса. В этом случае при обновлении конфигурации есть необходимость сверять запросы м/у собой – новый от поставщика старый от поставщика и измененный разработчиком. Причем, так как нужно сравнивать уже 3 текста,  делать это приходится не средствами 1С, а сторонними программами,  к примеру - KDiff3.

 

Предлагаемый подход направлен на сохранение первоначального текста запроса и «точечной» его модификации.  Для этого находим требуемые задачей «точки входа» и функцией СтрЗаменить() меняем исходный текст запроса – вставляем необходимые условия, соединения, выбираемые поля. Небольшой пример для понимания (пример надуманный и очень простой, но помогает понять вышеописанный принцип):

               ТекстЗапроса   = «

|ВЫБРАТЬ

               |             Номенклатура.Ссылка КАК Ссылка,

               |             Номенклатура.Наименование КАК Наименование

               |ИЗ

               |             Справочник.Номенклатура     КАК Номенклатура»;

 

Нам нужно ограничить выборку записями, имеющимися в некотором регистре сведений и вывести некоторые значения из этого регистра

               Добавим внутреннее соединение

               ТекстЗапроса   =  СтрЗаменить(ТекстЗапроса, «

|             Справочник.Номенклатура     КАК Номенклатура», «

|             Справочник.Номенклатура     КАК Номенклатура

|ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ДляПримера КАК Пример

|             ПО  Номенклатура.Ссылка = Пример. Номенклатура»);

              

Вынесем в результат требуемые поля

               ТекстЗапроса   =  СтрЗаменить(ТекстЗапроса, «

|             Номенклатура.Ссылка КАК Ссылка,», «

|             Номенклатура.Ссылка КАК Ссылка,

|             Пример.Поле1              КАК Поле1,

|             Пример.Поле2                               КАК Поле2»);

 

Таким образом, мы, сохраняя исходный текст на поддержке, при изменении его поставщиком (без кардинальных изменений), можем гарантировать обновление запроса поставщика без обдумывания наших изменений.

 

Немногим более сложна модификация предложенным способом пакетного запроса.  Как вы уже догадались, пакетный запрос – это набор «одиночных» запросов. Нам остается разобрать пакет на отдельные запросы, изменить/подменить  конкретный (ые) и собрать  пакет запросов обратно.  В УТ11 есть замечательные функции для этого «СтроковыеФункцииКлиентСервер.РазложитьСтрокуВМассивПодстрок()» и «СтроковыеФункцииКлиентСервер.ПолучитьСтрокуИзМассиваПодстрок()». Делителем строк будет являться символ «;».

 

Для динамических списков  текст запросов меняем аналогично.   В случае если динамический список использует реальную таблицу – меняем настройки динамического списка и подставляем текст запроса:

              .УстановитьТекстЗапросаДинамическогоСписка_ЗаказНаПеремещениеСписок(Список);

 

               Процедура УстановитьТекстЗапросаДинамическогоСписка_ЗаказНаПеремещениеСписок(Список) Экспорт             

               Список.ПроизвольныйЗапрос                = Истина;

               Список.ТекстЗапроса

                               = "ВЫБРАТЬ

                                 |           ЗаказНаПеремещение.Ссылка, ……

              

 4. Отказ от изменения форм объектов на уровне конструктора форм. По моему мнению, самым проблемным в обновлении измененных конфигураций – это обновление форм. Решение, позволяющее упростить эту задачу – менять форму  программным способом, т.е. использовать  динамическое/программное изменение состава, отображения, поведения формы.  

На программном создании элементов форм особо останавливаться не стоит, так как примеров и механизмов написано достаточно. Нужно только выбрать подходящий для себя. Я писал свой.  Список добавляемых элементов хранится в макете.  Вызов процедуры общего модуля происходит в процедуре ПриСозданииНаСервере(). При таком подходе я добавляю новые реквизиты в модифицируемый объект, прописываю вызов процедуры динамического создания элементов и добавляю в макет описание добавляемого реквизита.  На все уходит не более 5 минут.

Реквизиты формы (те что нужны на форме только на момент ее существования и не должны храниться в базе) тоже создаю программно. Подход аналогичный подходу, используемый при создании элементов форм. При этом динамически созданный реквизит может являться источником (прописанным в пути)  для динамического элемента формы.

Условное оформление  тоже доступно для модификации программно.  На момент написания статьи я еще не разработал более-менее внятного механизма по его «настройке» и просто прописываю в виде куска кода (конечно же, с вызовом в общем модуле).

Динамическое переопределение и добавление обработчиков событий формы.

Зачастую при модификации форм Вам, к примеру, на событие ПриИзменении нужно «добавить» обработку события. Обычно мы в форме определяем вызов метода «ПриИзменении» и уже в теле созданной процедуры описываем поведение. В этом случае при обновлении конфигурации у нас «распознаются» не только изменения модуля формы, но и изменения самой формы.

 

Мною разработан модуль «динамически подключаемых обработчиков событий» элементов форм и самих форм со следующим функционалом:

  • Добавление обработчика события
  • Удаление обработчика события
  • Переоределение обработчика события с возможностью вызова оригинального обработчика до, после, либо возможность его отключить.

 

На практике на момент написания данной статьи мною разрабатывается конфигурация для крупной торговой компании, занимающейся поставкой инструментов, на базе УТ11. Формы справочников и основных документов товарооборота и планирования сильно доработаны. Добавлены реквизиты шапки, табличных частей, вычисляемые реквизиты форм, добавлены и переопределены обработчики событий форм и реквизитов. Блокируются строки в табличных частях товаров и многое другое. Всего не описать. Примечательно, что при всех этих изменениях в модулях измененных форм всего несколько вызовов процедур в процедуре «ПриСозданииНаСервере» и в случае динамически подключаемых событий по одному «шаблону-процедуре» на событие.

Данная статья не предполагает детального описания разработанного вышеуказанного механизма.  В случае здорового интереса к нему готов написать отдельную статью с детальным описанием и выложить исходники с примерами использования модуля по созданию динамических реквизитов, элементов и подключаемых обработчиков.  

5.       Максимальное использование подписок на события.   Собственно если есть возможность использовать подписку на событие – используйте.

 

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Виктор Лебедев (eeeio) 28.01.13 10:23
интересна реализация вашего механизма быстрого внесения изменений в форму, а также как вы модифицируете проведение документов.
Zebar; antowski; +2 Ответить 3
2. aleksei (alekseies) 28.01.13 11:21
Неплохо бы посмотреть отдельную статью с детальным описанием и выложить исходники с примерами использования модуля по созданию динамических реквизитов, элементов и подключаемых обработчиков. А так +
NittenRenegade; iov; yaguarrr; +3 Ответить 3
3. Сергей Марченко (MarSeN) 28.01.13 11:56
(1) по модификации проведения документов зависит от задачи, но чаще всего реализация сводится к модификации запроса по принципам рписанным в статье. Если у вас есть конкретный вопрос, буду раз описать решение
(1)(2) я постараюсь до 04.02.2013 написать статью по динамическому изменению форм. сложнее всего будет создать пример и хелповое описание ).
4. Евгений Сосна (pumbaE) 28.01.13 13:05
По мне , так идея модификации запроса через "СтрЗаменить" плохая идея - получается собрать полностью запрос возможно будет только во время исполнения программы.
5. Сергей Марченко (MarSeN) 28.01.13 13:14
(4) Тут каждый волен выбирать что хочет получить ). Видить всегда полный запрос всегда, даже когда уже закрыл задачу и потом париться с объединением, либо "собрать" его тогда когда надо для отладки. На этапе программирования можно делать по старинке. но я стараюсь делать сразу таким образом.
6. Tsaregorodtsev (TSSV) 28.01.13 14:02
Думаю здесь важно избежать ситуации, когда упомянутое увеличение трудоемкости при разработке выльется в увеличение трудоемкости при модификации доработанного, причем уже в логарифмической зависимости, а в некоторых случаях и при обновлении в итоге тоже может получиться усложнение вместо ожидаемого упрощения. Ведь "докопаться" до физического смысла доработки становится сложнее, что весьма затрудняет сопровождение доработанного по данной технологии решения, а сопровождение ведь это не только обновление. Думаю об этом не стоит забывать тоже. Плюс.
kolya_tlt; astrius; Open-BS; jamirza; MarSeN; Дмитрий74Чел; expert.1c8; pumbaE; +8 Ответить 1
7. Сергей Марченко (MarSeN) 28.01.13 14:32
(6) Согласен. Всегда ко всем рекомендациям нужно относиться "дозированно" и никогда не принимать "на слово", потому что ответственность всегда лежит на исполнителе.
Мы всегда несем ответственность за свои изменения. Более того, изменения стандартной конфы зачастую несут глобальный характер с переименованием и переписыванием кода целиком. Могу ссылаться только на свой опыт. А получилость так что при обновлении на новый релиз мне пришлось проверять и вылавливать "стационарные" изменения регистраторов, реквизитов, комманд и т.п. и ни одной проблемы с динамическими элементами/событиями сменой текстов запросов и тп. Может повезло-не спорю, но факт остается фактом.
Спасибо за рекоммендации
8. Дмитрий Глеков (glek) 28.01.13 17:30
Насчет модифицирования запросов - спасибо. Почему то не пришел в голову такой метод
9. Vlad Matveev (psamt1k) 28.01.13 17:48
Как раз начал задумываться над тем, как "изменять конфигурацию с минимум изменений".
Большое спасибо за статью!
С нетерпением жду следующей, с примерами!
10. Сергей Марченко (MarSeN) 28.01.13 17:54
(9) Спасибо, следующая статья уже в процессе. В ней будет минимум описания и прикреплена маленькая самописная база примеров.
11. Василий Петров (expert.1c8) 28.01.13 19:23
В принципе ничего нового, но такие статьи всегда актуальны и полезны, как напоминание

Если изменений в запросе много или изменился запрос в основной поставке,
то метод с СтрЗаменить() иногда только затрудняет обновление,
мне проще переопределять текст запроса ниже типового текста зароса.

Для динамического создании элементов форм так и не нашел удобного для меня инструмента,
который позволял бы делать это быстро и удобно..
Но в конфигурациях на УФ с этим стало попроще благодаря встроенным механизмам

А в остальном все указано верно и соответствует здравому смыслу и метод. рекомендациям 1с по этому вопросу )
12. Игорь Хитров (Новенький_2209) 28.01.13 19:41
(11) expert.1c8, основная проблема при обновлении - это форма. При этом, казалось бы, т.к. форма управляемая, она полностью описываемая - почему в сравнении не указывать конкретные изменения в форме?...Я тоже не нашел никакого более или менее удобного инструмента для динамического создания элементов формы. Хотелось бы взглянуть на описываемую автором реализацию :)
13. script Мальчинко (script) 29.01.13 02:10
Могу только подтвердить справедливость всего описанного выше и поставить +.

Правда, маловато написано про формы.
На этом сайте присутствует замечательная статья
Методика переопределения и вызова обработчиков событий формы в 1С 8.
С первого раза идея, изложенная в статье, мне показалась сложной, но прочитав текст статьи 2 раза и код процедур, я осознал простоту и гениальность метода.
Теперь для изменения форм я использую такой подход:
1) Все доработки я делаю только на копиях форм. Т.е. если я меняю форму элемента или списка справочника, я всегда делаю копию оригинальной формы (например, script_ФормаЭлемента), устанавливаю ее основной, и только потом приступаю к доработке.
При обновлении, в разделе объединение и сравнение ... такой объект отобразится как измененный.
В свойствах такого объекта будет значиться, что изменена основная форма элемента.
Среди форм данного объекта появится "МОЯ" форма, а оригинальной формы не будет. Это значит что кроме моей формы, других изменений в объекте нет. Если же появляется и оригинальная форма, тогда становится понятным то, что поставщик внес свои изменения в данную форму и мы сможем увидеть отличия без наших доработок.
Далее принимаем решение, что проще? Перенести изменения в "Нашу" форму или скопировать обновленную, оригинальную форму и внести доработки повторно.
2) Элементы на форму я стараюсь поместить программно, но поскольку большинство моих конфигураций работают на обычных формах, такой подход не всегда реализуем или правильнее сказать, не всегда простой в реализации, но предпочтение я отдаю именно ему.
3) Это переопределение обработчиков событий элементов форм по, указанной в статье, методике.
santi___kr; МимохожийОднако; РоманКокарев; Новенький_2209; +4 Ответить 3
14. Аркадий Кучер (Abadonna) 29.01.13 07:23
Из опыта: умудрился подключить свою систему бюджетирования к БП 2.0, добавив только одну строчку в стандартной.
Все остальное - новые объекты.
15. Игорь Сарафанов (ivs200999) 29.01.13 07:31
Подписки на события форм, существуй они, серьезно бы облегчили нам жизнь.
16. Сергей Марченко (MarSeN) 29.01.13 09:54
(13) спасибо на ссылку по обработчикам. Хорошо то я ее не видел до текущего момента, так как, наверное, не заморачивался бы над своим механизмом. В итоге у меня подход к реализаии совсем другой, хотя методы установки и выполнения похожи, так как продиктованны возможностями платформы.
по п1. решение, по моему скромному мнению, интересное и, как вариант, может применяться должно при очень больших изменения форм. но в этом случае мы отказываемся от поддержки такой формы, а как следствие и вызываемых методов общих модулей (1С часто грешат тем что перекидывают из модуля в модуль и меняют параметры написаннх методов).
Небольшое дополнение здесь: если вы используете платформу 8.2 последних версий то для того чтобы не переопределять основную форму в метаданных есть подписка на событие менеджера объекта "ОбработкаПолученияФормы" в которой можно переопределить вызов основной формы.
17. Dmitriy Kuklin (amadeus2011) 29.01.13 09:55
довольно таки интересная статья, есть что использовать и применить на практике. Вот только вопрос обновление нетиповой конфигурации до конфигурации с УФ все равно приходиться делать методом сравнить-объединить конфигурации
18. Eugeneer (Eugeneer) 29.01.13 20:39
Прямо и не знаю. Спорная статья по коэффициенту полезности.
Даже наводит на мысль написания свой статьи с правильной методикой!

Чем сейчас наверное и займусь. Уж больно эта статья не раскрыла сути. А наоборот внесла не то что надо.
19. Сергей Марченко (MarSeN) 29.01.13 20:58
(18) Хотелось бы увидеть аргументированную позицию
Буду рад прочитать статью ознакомиться с Вашей статьей и почерпнуть новые подходы, в чем я лично сомневаюсь.
Статья конечно не доработанна, но это не повод "так" о ней отзываться
20. Geo Leo (GerHard) 30.01.13 01:57
Плюсик за приятное воспоминание о наивной молодости ;-))

ИМХО: код и формы лучше вообще не трогать, если хочешь их потом обновлять типовыми...
Стараться обходится внешками и максимум новыми объектами.
Igor030370; +1 Ответить 1
21. Алексей Бобылкин (alex_bob) 30.01.13 07:42
Эx...Хорошо бы, если бы кто-нибудь раскрыл тему "ОБЪЕКТЫ СИСТЕМЫ БЕЗ ЧЕТКОГО ОПИСАНИЯ МЕТОДИКИ ИЗМЕНЕНИЙ"
23. aleksei (alekseies) 30.01.13 10:32
Хотелось бы побольше услышать о динамическом переопределении и добавлении обработчиков событий управляемой формы....
24. f f (fnv) 30.01.13 11:23
Если запрос глобально поменяется при обновлении, то при доработке с использованием закомментированных вставок легче будет понять, что конкретно было доработано, чем через "СтрЗаменить". Имхо. А вообще, вопрос поднят важный. Сталкивалась с обновлением нетиповой, когда даже печатные формы не были сделаны внешними, а вносились изменения непосредственно в макеты, вот это перебор уже:(
25. Сергей Марченко (MarSeN) 30.01.13 15:08
(20) Спасибо за плюсик )
(20)(22)(23)
Конечно же в статье я не рассматривал вопросы с простыми случаями, ситуации когда можно и нужно делать новые документы, либо возможность использования дополнительных реквизитов и сведений. Речь шла о том, когда у вас "нет выбора" либо нецелесообразно создавать новые объекты.
К примеру у вас есть Заказ поставщику и часть его строк связана к "примеру в поступлением" ч/з код строки (пример надуманный, но имеет место быть. конфа УТ11). И клиенту нужно чтобы: эти строки выделялись в таблице
каким либо цветом и система не давала удалить и менять эти строки. Не думаю что в этом случае целесообразно создавать новый документ или новую форму, которые поддерживать придется. В моем случае будут произведены след. изменения: 1. в процедуре ПриСозданииНаСервере в конце процедуры будут добавлены примерно такие вызовы.
//добавляем динамически реквизит формы
// прописанно в макете "ДинамическиеРеквизитыФорм" служебной обработки "Служебная"
ДинамическиеЭлементыКлиентСервер.СоздатьДинамическиеРеквизиты(ЭтаФорма);
//подключаем подписки на события
ДинамическиеЭлементыКлиентСервер.ПодключитьОбработчики(ЭтаФорма);
//применяем условное оформление
УсловноеОформлениеФорм.ЗаказФормаДокумента_ПрименитьУсловноеОформление(ЭтаФорма);

и еще 2 процедуры-шаблона обработчиков событий (я прописываю эти шаблоны в самом начале)
&НаКлиенте
Процедура ПодключаемыйОбработчик_ТоварыПередНачаломИзменения(Элемент, Отказ)

МассивИнструкций = ДинамическиеЭлементыКлиентСервер.ПолучитьИнструкцииПереопределаемыхОбработчиков(ЭтаФорма, "ТоварыПередНачаломИзменения");

Для Каждого Инструкция из МассивИнструкций Цикл
Выполнить(Инструкция);
КонецЦикла;

КонецПроцедуры

&НаКлиенте
Процедура ПодключаемыйОбработчик_ТоварыПередУдалением(Элемент, Отказ)
МассивИнструкций = ДинамическиеЭлементыКлиентСервер.ПолучитьИнструкцииПереопределаемыхОбработчиков(ЭтаФорма, "ТоварыПередУдалением");

Для Каждого Инструкция из МассивИнструкций Цикл
Выполнить(Инструкция);
КонецЦикла;
КонецПроцедуры

Дальнейшый код будет существовать вне "поддерживаемых" объектов системы.

Другой пример в документе с таблицей товаров рядом с количеством выводить колонку кратности указанного количества. т.е. если 10 шт. товара а основная упаковка 8 штук в кратности должно быть "1,25(8/16)" и эта строка подсвечивалась. Решается таким же набором изменений. только шаблонов будет не один а 3-4. Шаблоны меняются только наименованием и строковым параметром внутри процедуры.

Я готовлю конфу с примерами в которой приведу примеры использования мое подсистемы динамических объектров и событий
26. Денис (Den_D) 30.01.13 16:21
Какие бы ни были споры по поводу полезности статьи, я считаю, что это очень хороший, благодарный труд. Автору спасибо.
27. Сергей Маслов (LexSeIch) 31.01.13 07:06
Мир этому дому! Статья безусловно полезна и сама тема актуальна. Каждый двигается своим путем, наступая на грабли и получая шишки, но в конце концов рождается решение, и оно работает. Чужой опыт бесценен. Я думаю, что статья будет расширяться, обретая новые направления и примеры.
28. Сергей Марченко (MarSeN) 31.01.13 07:51
(1),(2),(9),(11),(12),(13),(15),(17),(23),(26),(27)
В качестве анонса: вчера дописал статью "v8.2 Управляемые формы: Динамические элементы формы и переопределяемые события или как изменить поведение и внешний вид управляемой формы программно без лишних хлопот ". Это статья по примеру реализации пункта "Динамическое переопределение и добавление обработчиков событий формы."
В данный момент статья на модерации. Как только она станет активной - сразу скину ссылку всем заинтересовавшимся.
29. Vlad Matveev (psamt1k) 31.01.13 09:37
(28) MarSeN, еще раз спасибо за труды! Ждем-с!
30. Сергей Марченко (MarSeN) 31.01.13 10:08
(1),(2),(9),(11),(12),(13),(15),(17),(23),(26),(27)
Статья опубликована.
http://infostart.ru/public/171514/

Спасибо
31. Tsaregorodtsev (TSSV) 01.02.13 18:58
(4) pumbaE, Думаю использование данной методики (СтрЗаменить для модификации текста запроса) будет оправдано в случае с динамическими списками, когда источником данных списка является произвольный запрос. В случае корректировки типового запроса непосредственно в свойствах динамического списка мы не увидим деталей при анализе различий в процессе сравнения/объединения конфигураций.
32. Oleg Ya (yaguarrr) 02.02.13 15:34
(3) MarSeN, очень заинтересовали, спасибо что сдержали обещание
33. Сергей Марченко (MarSeN) 02.02.13 20:32
(32) спасибо, приятно что обе статьи получили достойный отзыв.
34. Александр Гончаров (aegoncharov) 03.02.13 12:02
При модификации типовой надо понимать, что "минимальное изменение типовых объектов и кода" не есть основной критерий, который определит трудоемкость последующих обновлений.

Нам, конечно, с одной стороны нужно добиться:
1. минимизации ручного переноса изменений в новые релизы
Но с другой стороны нам нужно:
2. обеспечить, чтобы все изменения надежно переносились в следующий релиз и надлежащим образом адаптировались к новому релизу, если есть такая необходимость.

Поэтому практику:
а) копирования семиэтажных запросов и изменения в них пары строчек
б) копирования типовых форм ради добавления пары элементов формы на них
и т.п. считаю вредной.

Если нам надо внести изменения в программу, то мы должны внести их так, что при обновлении было сразу видно что они, собственно, внесены, а также куда именно они внесены, и зачем они внесены.
KapasMordorov; +1 Ответить 1
35. Сергей Марченко (MarSeN) 04.02.13 07:19
(34) К сожалению, не совсем понял Вашу позицию. Вроде Ваши слова не расходятся с описанной в статье методикой, но ощущения посте прочтения остались, как-будто Вы не согласны со статьей.
36. Александр Гончаров (aegoncharov) 04.02.13 11:02
(35) Да, по сути не расходится.
Но пункт №3 лучше переименовать, назвать не "Отказ от «непосредственного» изменения текстов запросов.", а что-то вроде "Модификация запросов при помощи СтрЗаменить()".
Поясню: в статье, по сути предлагается отказ как от
1.непосредственного изменения,
так и от
2. копирования
и предлагается 3-ий метод - СтрЗаменить().

А сейчас из названия пункта №3 возникают ощущения, что предлагается именно отказ от неопосредственного изменения запроса.

Еще я б конечно поспорил насчет того, какой вариант лучше, 1 или 3, но про это уже было выше :)
37. Сергей Марченко (MarSeN) 04.02.13 11:15
(36) Спасибо, что разъяснили Вашу позицию.
Учту замечания при корректировке статьи, которая будет обязательно произведена на основаниии Ваших замечаний и других "высазавшихся".
Так же планирую дополнить статью - так сказать по максимуму заполнить "белые пятна"
38. Игорь Юндин (kereo) 05.02.13 11:21
У меня скорее вопрос, чем утверждение. А не проще вместо СтрЗаменить добавить вызов процедуры в общем модуле, где будет осуществлена замена текста запроса и (если необходимо) указаны значения дополнительных параметров?
39. Сергей Марченко (MarSeN) 05.02.13 20:15
(38) Это всего лишь подход. Я задумывался по процедуре, только хотел чтоб она по определенной константе проверяла на то что сделала изменения в запросе. Нужно это только 1 раз при обнновлении конфигурации чтоб понять "отработала" ли замена корректно. если после выполнения стрЗаменить запрос не изменился тогда Сообщать
40. Александр Гончаров (aegoncharov) 06.02.13 07:15
(38) Смотрите сами. Сделали вы так. В следующем обновлении 1С внесла в свой запрос некоторые изменения, допустим исправление критичной ошибки. Вы при обновлении видите свое изменение, переносите вызов подменяющей запрос процедуры. Исправление критичной ошибки пройдет мимо, если вы конечно не будете специально анализировать на изменение поставщиком все такие места, где производили дублирование типового кода.
41. Сергей Марченко (MarSeN) 06.02.13 11:01
(40) Вы не поняли смысла подхода. В том то и дело что в моем случае я вношу только свой код, а в нем нет критических ошибок поставщика
42. Игорь Юндин (kereo) 06.02.13 11:39
(40) aegoncharov, с таким же успехом, вы можете перенести замену подстроки, которая не будет работать...я в любом случае анализирую, что изменил поставщик в исправленном мною коде, иначе можно перенести кусок который с исправлениями поставщика будет работать еще хуже.
43. Сергей Марченко (MarSeN) 06.02.13 12:58
(40)(42) тут конечно нужно написать в комметариях дополняющей/правящей запрос функции что именно Вы в нем коректируете. Чаще всего это Ваш новый функционал, который вряд ли пересечется с дорабтками 1С.
Если Вы сами исправляете критическую ошибку 1С, то, наверное, правильнее править вносить изменения непосредственно в запрос с описанием типа "исправление такой-то ошибки" в надежде что ее поправят в послед. релизах. В этом случае Вы при объединении увидите и смодете проанализировать изменения на устранение оной.
44. Александр Гончаров (aegoncharov) 07.02.13 07:33
(42), (43) Я просто понял фразу "где будет осуществлена замена текста запроса" из (38) как то, что будет замена всего текста запроса.

А в СтрЗаменить один из минусов заключается в том, что заменяемых текст должен точно совпадать с куском текста запроса, вплоть до пробелов и прочих символов. Переформатируют текст - и пролетит СтрЗаменить мимо.
СтрЗаменить применительно к текстам запроса признаю только когда идет замена специально подготовленных меток, как это часто делается в типовых.
45. Сергей Марченко (MarSeN) 07.02.13 11:28
(44) по точному соответсвию текста Вы совершенно правы. По этой причине я подумывал о спец. процедуре оберткекоторая сама бы проверяла произошла ли замена текста. К сожалению я не увидел ни одной из специально подготовленных меток в тех местах где мне они были нужы. В качестве меток я беру сущетвующую строку запроса и в замене заменяю на нее + свой текст.
46. Александр Гончаров (aegoncharov) 07.02.13 11:46
(45) Метки это типа такого:

| //ДляРеглУчета СУММА(УчетЗатрат.ПостояннаяРазница) КАК ПостояннаяРазница,
| //ДляРеглУчета СУММА(УчетЗатрат.СтоимостьНУ) КАК СтоимостьНУ,
| //ДляРеглУчета СУММА(УчетЗатрат.КоличествоНУ) КАК КоличествоНУ,
|
| СУММА(УчетЗатрат.Стоимость) КАК Стоимость,
| СУММА(УчетЗатрат.Количество) КАК Количество
|
|ИЗ
| РегистрНакопления.УчетЗатрат%СуффиксРегл% КАК УчетЗатрат
|ГДЕ
| УчетЗатрат.Регистратор = &Регистратор

Используются для "ручной сборки" текста запроса.
В тех местах где они нам нужны их конечно не будет :)
47. q_i 11.02.13 18:58
(46) aegoncharov, куда более удобны метки вида &<ИмяПараметра>, например:
ТекстЗапроса = "ВЫБРАТЬ &Поле ИЗ Справочник.Номенклатура ГДЕ &Условие";
а потом ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&Поле", "Ссылка") и ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&Условие", ?(ТолькоНепомеченныеНаУдаление, "НЕ ПометкаУдаления", "ИСТИНА")).
Такие метки не "слетают" при редактировании конструктором. имхо, их то как раз можно более-менее безобидно вставлять в "штатные" 1с-вские запросы.
48. Сергей Марченко (MarSeN) 11.02.13 19:06
(47) Идея хорошая, но она реализуема только для условий и полей в запросе. Но что если надо вместо одного поля в запросе вывести другое, или присоеденить к текущей таблице еще одну?
А вообще идея состоит в том чтоб вообще не вносить никаких изменений в типовой запрос.
Что касается "они не "слетают" при редактировании конструктором" то зачастую, особенно в пакетных запросах 1С описывает наименование таблиц или вставляет комментарии и при использовании конструктора Вы теряете эти комменты.
49. ivanov660 ivanov660 (ivanov660) 09.03.13 14:03
(46) aegoncharov,
думаю, только для простейших случаев.
Если же рассмотреть задачи модификации алгоритмов проведения (к примеру, в модуле менеджера УТ 11 - инициализировать документ), то такой подход только усложнит разработку и понимание. Проще вызвать переработанный текст запроса полностью.
50. nataon (nataon) 29.04.13 13:25
Статья полезная, слов нет, но много уже статей на эту тему и нет ничего нового в статье
51. Алексей Новоселов (a-novoselov) 23.05.13 17:47
(0) А зачем такой геморрой с формами? В большинстве случаев проще скопировать форму поставщика, назвать ее Измененная_ФормаДокумента, назначить ее основной и править все в ней. Правда при обновлении нужно будет руками вносить изменения поставщика в свою форму, но для сопровождения будет намного нагляднее что зачем сделано. И в 99% случаев форма будет работать без внесения изменений поставщика. А с программной привязкой обработчиков и элементов формы при неумелом обновлении (а чаще всего обновлять отдают низкоквалифицированному персоналу) форма может перестать открываться и вываливаться с ошибкой, если например поставщик переименовал один из элементов, к которому привязка устанавливается программно...
52. Сергей Марченко (MarSeN) 23.05.13 20:05
(51) a-novoselov,
А геморой именно в
... Правда при обновлении нужно будет руками вносить изменения поставщика в свою форму...

Плюс к этому нужно будет как-то сверить уже 3 формы: старую от поставщика, новую от поставщика и новую с Ващими изменениями. Не очень приятное занятие, по крайней мере для меня.
Если еще принять во внимание тот факт, что 1С, зачастую, любить изменять формы до неузнаваемость, как это происходит на УТ 11 - я Вам не завидую.
В случае днамического добавления реквизитов на форму и динамических обработчиков максимум что произойдет - это ошибки при открытии формы о не найденных элементах формы с которыми очень легко разобраться.
Надеюсь я ответил на Ваш вопрос.
53. Алексей Новоселов (a-novoselov) 24.05.13 17:43
(0)
... На программном создании элементов форм особо останавливаться не стоит, так как примеров и механизмов написано достаточно. Нужно только выбрать подходящий для себя. Я писал свой. Список добавляемых элементов хранится в макете. Вызов процедуры общего модуля происходит в процедуре ПриСозданииНаСервере(). При таком подходе я добавляю новые реквизиты в модифицируемый объект, прописываю вызов процедуры динамического создания элементов и добавляю в макет описание добавляемого реквизита. На все уходит не более 5 минут. ...

А можно для полноты в статью добавить ссылки, где есть примеры и механизмы?
54. Сергей Марченко (MarSeN) 24.05.13 17:56
(53) a-novoselov,
Да, статью буду дописывать, так сказать, закрывать "белые пятна".
по моему механизму Вы можете ознакомиться, пройдя по ссылке http://infostart.ru/public/171514/.
В ней есть демо-конфигурация описанная в статье.
Жду Вашего мнения )
a-novoselov; +1 Ответить
55. serge_focus (serge_focus) 24.08.13 20:38
Идеи в статье описаны интересные,
думаю пригодятся. ПЛЮС однозначно.
56. Максим (Maxisussr) 17.02.14 16:21
Программное редактирование форм для типовых на поддержке - возможно хорошее решение. А как быть со сложными формами, в которых 10 закладок, и на каждой таблицы, макеты, со своими полями и расположением + привязки? Это же замучаешься их описывать в коде и подгонять положение элементов формы.
57. Сергей Марченко (MarSeN) 17.02.14 21:07
(56) Maxisussr,
Что касается форм, нужно не решать проблему не в лоб, а универсальными механизмами. Для обычных форм у меня нет решения. Для УФ есть и оно опубликовано на инфостарте.
58. Роман Цованян (pfihr) 18.02.14 18:30
Самый легкий способ делать минимальные изменения - вообще не использовать типовые конфигурации :)))))
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа