Используете ли вы парсинг для обновления типовых?


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

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

Но всё это не очень эффективно и универсально и иногда всё равно приходится вносить изменения в типовой код.

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

В принципе, уже сейчас практически все, кто модифицируют типовую конфигурации, делают это через изменение текста модулей.

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

Всё, на самом деле, очень просто.

Выбирается маркер для отметки начала и кона модификации, например //+++ и //---.

Далее, есть два направления парсинга.

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

Также этим способом можно прописывать процедуры, которые будут обслуживать события добавленных Вами элементов.

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

Второе направление парсинга – это директивное вмешательство.

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

Тогда в начале  цикла мы ставим следующий код:

Для Каждого Строка ИЗ ТаблицаТоваров Цикл

//+++ :: Цикл;Начало;Из=ТаблицаТоваров
//---
КонецЦикла;

Т.е. дополнительно мы указываем, в какое место кода нужно вставить наш код.

Это может быть условный оператор, цикл, определенный запрос. Можно указывать вызов дополнительного кода в каждом цикле или запросе процедуры. А уже при самом вызове анализировать, что это за запрос/цикл.

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

1.    Выгружаются тексты модулей.

2.    Накатываются типовые тексты модулей.

3.    Автоматически анализируются указанные локации размещения добавленного кода и в них добавляется код. Также сообщается об ошибках адресации, если адрес написан неправильно или уже больше не существует.

4.    В код добавляются все однотипные шаблоны согласно схемы генерализации.

Такой подход полностью исключает ручное вмешательство в типовые тексты модулей. Это позволяет делать очень сложные вмешательства в типовой код.

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

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

Подробнее получить представление о парсинге в моей древней статье:

http://catalog.mista.ru/public/102193/

Ап

Герой вчерашних дней не нужен

>> Это и подписки на события и плагины и даже специальные вносить свои изменения.

>> Но всё это не очень эффективно и универсально и иногда всё равно приходится вносить изменения в типовой код.

А потом пришли расширения.

Это ты свой кдифф хочешь написать чтоли?

(3) и что? если нужно поменять текст процедуры? всю ее в расширение переносить? а как потом обновлять?

(4) прав, kdiff3 изи делает трехстороннее сравнение

(6) не 100% конечно, но 99.9 почти всегда

а в нем даже 7.7 обновлял

ну так в 8 все из коробки так работает

(5) Можно всю, можно перед, можно после, можно посередине. Мне пока хватает.

(10) посередине нельзя. из-за этого я сильно страдаю :(

(11) ПродолжитьВызов()? Хотя сам не пользовался.

(12) он выполнит всю немодифицированную процедуру

(12) Будет передача управления на начало замещенного метода. &Вместо превратиться в &Перед

(5) А нефиг писать в стиле "Если <5 экранов кода> Иначе"

Я со временем все меньше и меньше изъявляю желание изменять типовой код. И как-то продолжаю работать. Не знаю точно, с чем связано, хочется верить, что с опытом.
То есть конфу меняем все реже, а результат тот же.

Есть подозрения, что лопатить типовые до неузнаваемости - признак плохого тона.

(12) вот однажды пришлось ради этого:
        //Если СуммаНДС <> 0 Тогда
        Если Не СведенияОДокументе.Документ.ДокументБезНДС Тогда
тянуть в расширение всю функцию. И потом, когда эта функция в типовой обновилась, все развалилось. С kdiff3 и модификацией типовой все обновилось бы в пару кликов мышкой. И никакой "продолжить вызов" от необходимости вставить в середину типовой функции пары строк не спасает.

(15) ну это ты типовым скажи

(16) угу. согласен. но многих восьмерочников аж трясет, когда нужно что-то "нетиповое" сделать. вот мне совершенно пофиг как бюудет на 8-ке сделана нужная мне доработка - с вмешательством в типовой код или без вмешательства, "сверху/сбоку". Мне главное - чтобы делало то что мне надо и без лишних геморойных движений. если делает что надо, но с кучей лишних геморойных движений - лесом...

(18) отмазался

Да, что то тпа кдифф, только тут не обязательно иметь конфу поставщика и дубовее и проще расширений и подписок.

Вот я и спрашиваю, на практике кто юзает такой подход?

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

(22) ха, такое обновление с любым подходом нерабочее
А так, имхо, хорошо автоматизирует обновления, лучше подписок