О расширениях замолвите слово...

30.05.19

Разработка - Механизмы платформы 1С

О чём стоит задуматься при принятии решения о создании расширения конфигурации…

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

Мы сделали выводы из своих ошибок и в итоге появился ряд рекомендаций, которыми руководствуемся при разработке расширений:

  1. Не дробить расширения для одного и того же объекта конфигурации
  2. Изменения расширяемых форм делать программно, а не через редактор форм
  3. Минимизировать использование аннотации &Вместо (&ИзменениеИКонтроль?)
  4. Делать независимые друг от друга расширения
  5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
  6. Вести реестр расширений

Рассмотрим подробнее каждый пункт

1. Не дробить расширения для одного и того же объекта конфигурации.

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

Как вариант, можно объединять расширения по функциональности, а не только по определенным объектам, хотя здесь может возникнуть "конфликт объединений" и решить, каким образом лучше объединять, возможно, стоит в самом начале доработок. Например, нужно добавить определенный (схожий) функционал к нескольким объектам, что лучше: добавлять его в каждое расширение, относящееся к определенному объекту, или же сделать одно расширение, но зато придется сослаться на эти объекты в этом одном расширении? Вопрос на самом деле довольно сложный и порой заставляет отступить от принципа "один объект - одно расширение", ради объединение функционала в одном месте.

 

2. Изменения расширяемых форм делать программно.

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

Давайте возьмем самый банальный пример: сделать определенное поле на форме нередактируемым, т.е. установить ему свойство "ТолькоПросмотр".

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

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

А вдруг случается страшное ("Всё пропало, шеф!"): после очередного релиза автообновление формы не срабатывает (часть элементов с формы вообще исчезает, а новые не появляются, как было в нашем случае пару раз) и Вам нужно повторить установку всех этих галок и свойств, воссоздавая расширение с нуля (а Вы еще к тому же забыли записать, с какими элементами, что делали, и было это полгода назад…). (Например, у нас в типовой конфигурации есть такая сложная форма, расширение которой приходится переделывать при каждом обновлении)

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

Ну и самый плачевный случай - делали это может быть вообще не Вы, а тот, кто делал уже давно уволился. Тогда рекомендуется переделать расширение так, чтобы потом не было каждый раз мучительно больно при обновлении.

Так что же делать? Всё просто! Любые изменения, связанные с элементами формы делайте программно, вообще старайтесь не трогать редактор форм, как бы соблазнительно это не было. Либо альтернативный вариант решения: к каждому расширению прикладывать подробное описание: что и с каким элементом Вы сделали, какое свойство поменяли, какой элемент добавили и т.п.

Не рекомендуется делать так:

Рекомендуется: добавить процедуру с аннотацией &После для события формы "ПриОткрытии" примерно с таким кодом:

&НаКлиенте
Процедура АТБ_ПриОткрытииПосле(Отказ)
   Элементы.Ответственный.ТолькоПросмотр = Истина;
   // и все другие изменения элементов формы
КонецПроцедуры

В этом случае, если Вам придется воспроизводить расширение с нуля, достаточно будет просто перенести данный код в воспроизводимое расширение и всё.

В случае затруднений при программном изменении элементов форм можно воспользоваться бесплатным инструментарием декомпиляции формы, который публиковался здесь на Инфорстарте Евгенией Карук - Генерация кода управляемой формы (т.е. сначала делаем форму в редакторе, указанным инструментом декомпилируем ее и смотрим, как делаются элементы формы программно).

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

 

3. Минимизировать использование аннотации &Вместо.

Старайтесь при любой возможности избегать использования аннотации &Вместо. Если логика позволяет, используем &Перед или &После.

Главная цель в этом случае - избежать проблем при изменении кода исходной процедуры в типовой конфигурации (ведь аннотацией &Вместо мы перехватываем исполнение процедуры полностью на расширение, заменяя исходную).

Однако бывают ситуации, когда нужно поменять несколько строк кода именно внутри процедуры и никак аннотациями &Перед и &После сделать этого не получается.

Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль, в какой-то степени она решит многие проблемы, связанные с тем, что Вам нужно подправить лишь пару строк в заимствованной функции/процедуре модуля, но Вы не хотели бы перехватывать его полностью, с риском в дальнейшем постоянно отслеживать изменения данного модуля (хотя даже при использовании &ИзменениеИКонтроль риски остаются).

Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)

Например, раньше (т.е. сейчас, пока не обновили платформу) нам приходилось писать так:

 
 Пример с &Вместо

 

Теперь можно написать так.

 
 Пример с &ИзменениеИКонтроль

 

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

 

4. Делать независимые друг от друга расширения.

Можно ли из одного расширения вызвать функцию в другом расширении? Можно, но может не нужно?

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

Скажу честно, мы так сделали, и оно действительно работает, работает не плохо, но…

Есть риск "зависимости". Что-то измените в таком шаред-расширении и могут "полететь" все остальные… Но если Вы держите это под своим контролем, то в принципе использовать такой механизм вполне возможно.

 

5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию.

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

Можно вынести в хранение в расширении, например настроек, логов - т.е. того, что при случае не сильно жалко потерять.

 

6. Вести реестр расширений.

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

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

В нашем случае ведем реестр в общей записной книге OneNote. Пример фрагмента таблицы такого реестра (в некоторых названиях добавлены пробелы, т.к. иначе таблица здесь не поместится в ширину страницы):

 
Пример фрагмента таблицы реестра расширений

 

На каждом элементе есть ссылка на другую OneNote-страницу с ТЗ (с полным описанием задачи, для чего делалось расширение, какие доработки в него вносились со временем, а также ссылка на GIT-хранилище).

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

 

В итоге немного о том "Почему именно расширения?":

1) Отвечая на вопрос: "Зачем столько мучений, ведь можно просто внести изменения в конфигурацию?" - зачастую это безвыходная ситуация, когда Вам запретили изменять типовую конфигурацию, а что-то добавить очень хочется.

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

3) Удобство при работе с Git (см. Git-репозитории при небольших проектах

 

В конце хотелось бы задать вопрос сообществу: Используете ли Вы расширения в своей работе?

1) Если да, то с какими трудностями Вы сталкивались (а может не сталкивались)?

2) Если не используете, то почему?

 

Другие статьи на эту тему:

расширение 1С8

См. также

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024    4512    dsdred    53    

71

Как готовить и есть массивы

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

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

24.01.2024    5288    YA_418728146    25    

63

Планы обмена VS История данных

Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    6408    dsdred    36    

111

1С-ная магия

Механизмы платформы 1С Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    18473    SeiOkami    46    

118

Дефрагментация и реиндексация после перехода на платформу 8.3.22

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023    12087    human_new    27    

74

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.08.2023    8819    YA_418728146    6    

141

Внешние компоненты Native API на языке Rust - Просто!

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Внешние компоненты для 1С можно разработывать очень просто, пользуясь всеми преимуществами языка Rust - от безопасности и кроссплатформенности до удобного менеджера библиотек.

20.08.2023    6279    sebekerga    54    

94

Все скопируем и вставим! (Буфер обмена в 1С 8.3.24)

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим новую возможность 8.3.24 и как её можно эффективно использовать

27.06.2023    15984    SeiOkami    31    

103
Вознаграждение за ответ
Показать полностью
Отзывы
37. Darklight 32 08.04.19 11:53 Сейчас в теме
За статью спасибо. Но, напишу свои замечания к Вашим предложениям:

1. Не дробить расширения для одного и того же объекта конфигурации
Дельный совет. Но я бы пошёл бы ещё дальше - ВООБЩЕ НЕ ДРОБИТЬ расширения - т.е. если какую-то конфигурацию. поддерживает команда разработчиков с разными проектами - они могут вести их в отдельных расширениях в своих тестовых базах и отдельных хранилищах конфигураций расширений (но это тоже не обязательно - можно вести всё в одном расширении/хранилище)
А перед установкой в рабочую базу (вернее в продакшен-конфигурацию, возможно так же имеющую своё отдельное хранилище) переносить изменения из разных конфигураций-расширений - в одну (дабы сравнение-объединение для конфигураций-расширений вполне нормально работает) - если их несколько или так и подключать к продуктивным базам единое расширение (если оно сразу был одно). То есть - сводить все свои доработки, в итоге, к одной конфигурации-расширения (ну, максимум к 2-3 - если уже очень приспичит) и подключать ко всем ИБ.

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

2. Изменения расширяемых форм делать программно
Тоже дельный совет. Он касается не только расширений. Увы, даже в управляемых формах и без расширений надёжнее все изменения вносить программно. Эх... жаль-только, что нет возможности писать программные макросы, которые отработают ещё на стадии компиляции в конфигураторе - один раз внеся изменения в форму - а не каждый раз при её создании в runtime.
Ну и фреймов не хватает - ведь один раз так перенести элементы в программный код это не страшно. А если их постоянно приходится модифицировать - это дальше чаще придётся уже работать исключительно с программным текстом, а нес формой.
И ещё есть сложности - порой при добавлении новых элементов на форму приходится перемещать имеющиеся - это самое неприятное. Впрочем это может быть чревато большими проблемами при любом подходе: и программном и при изменении на самой форме.

3. Минимизировать использование аннотации &Вместо
Конечно, с приходом аннотации "&ИзменениеИКонтроль" использование "&Вместо" должно существенно сократиться, но 15- релиза ещё нет даже в бете. Ну а далее - боюсь всё-равно будет куча проблем с сопровождением - там время покажет, пока ещё нечего даже пощупать.
Но, сам формат данной аннотации - мне уже сейчас не нравится - идея хорошая - исполнение отвратительное (Увы это норма для 1С).
Лучше бы парадигму аспектного программирования в 1С привнесли - вот это был бы прорыв.

4. Делать независимые друг от друга расширения
Совет был бы дельным. Но, я уже написал, в самом начале, что лучше вообще делать одно расширение (или пару - полностью независимых друг от друга). Иначе - будут проблемы другого рода - если разные расширения имеют общую основу (как общие модули, так и другие метаданные) - то если их делать полностью автономными - то - эти общие элементы будут в них дублироваться от того сразу ряд проблем:
а. Дублирование кода и метаданных - нужно будет во всех расширениях вручную поддерживать его актуальность - особенно сложно, когда его будут менять в разных проектах и разные команды.
б. Дублирование метаданных так же вызовет конфликт дублирования имён - при установки таких автономных расширений в одну ИБ. Да, конечно же - придётся
разграничивать их все префиксами разными расширений
в. Дублирование метаданных, сохраняемых в СУБД - вообще, можно сказать, невозможно, в большинстве случаев
г. Дублирование да даже не сохраняемых в СУБД метаданных - может быть проблемным - когда, скажем, нужно будет иметь расшаренные глобальные перенные
(параметры сеанса пока расширения вообще не поддерживают - в 14 релизе).
д. Дублирование метаданных приведёт ещё и к дублирование прав доступа к ним (ролей) - настройка прав превратится в хаос.
е. Дублирование перехватчиков событимй (да и просто вызовов функций), реализующих одну и ту же логику - создаст ещё больший хаос.
ж. И отдельно упомяну о том, что многие алгоритмы нуждаются в настройках - их где-то надо хранить - плрохая идея дублировать один и тотжемеханизм работы
с настройками для каждого расширения - ведь его ещё и настраивать придётся в отдельных автономных формах.
В общем, проблем много. Лучше всё-таки все свои изменения вести в одном расширении. Как я написал выше - можно сначала вести отдельные расширения, в и т.ч. создавать общие-расшаренные (ну тут тоже желательно не плодить много таких общий расширений) - а потом всё переносить в одно (сравнением/объединением), без дублей - его уже ставить в продакшен-базы.

5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
Может и дельный совет. Пока расширения не поддерживают всех объектов метаданных. Но тут главная проблема именно в том, что приходится разделять проекты на части - что будет размещено в расширениях, что в нужно будет разместить в основной конфигурации. Жить с этим вполне можно - но очень неудобно. Но, пока без этого вообще не обойтись. Самое неприятное, что нельзя предопределённые элементы вот так нормально добавить, и не бояться их потерять. И с расширением составным типов всё тоже не очень гладко.

6. Вести реестр расширений
Совет дельный, но делать это очень не удобно. Увы - с документированием конфигураций в 1С Предприятие 8 всё очень печально. А вести в отдельном приложении - не очень удобно. Разве что только настраивать GIT и подключать сторонние приложения для решения вопросов документирования уже к GIT-депозитарию -- но это очень не простой путь для 1С разработчиков.
Вести в OneNote - тоже как-то не очень удобно (лично сколько раз порывался - но так и не смог полюбить OneNote - мне не удобно, но, возможно, я просто не научился его готовить).
Ввёл, как-то в отдельной кустарной конфигурации (ещё до появления расширений - для фиксации доработок обычных конфигураций) - это даже как-то удобнее было (метаданные автоматически туда подтягивались фоновым процессом - та же был учет задач и проектов - нужно было только подцепить метаданные к уже имеющимся там задача и всё) - но такую конфигурацию нужно разрабатывать себе самостоятельно - под свои предпочтения и свой учет планирования работа ИТ-отдела.
VyacheslavShilov; papche; plus1s_a; Drivingblind; Риник; Mi4man; jif; davdykin; kostas; dvpk1c; user1183297; VladC#; YPermitin; Il; Vladimir Litvinenko; +15 Ответить
79. 77dream77 421 10.04.19 12:59 Сейчас в теме
использую расширения на проектах давно (более 2 лет), даже читал курсы по ним 😊
Из последнего проекта перехода с КА 1.1 на КА 2.4 - там все изменения сделаны через расширения (41 расширение), в конфигурации только новые объекты/реквизиты и одно изменение кода из-за нежелательности применения расширения в данном случае. Было 3 обновления с начала года - никаких проблем
много расширений настраивал для типовых ЗУП, БП, Итилиума, КА, ДО
Много расширений приходится переделывать после других, если неправильно настроены – то они валятся после очередного обновления.
при правильной настройке расширения - очень удобный и стабильный механизм, нужно просто понимать что можно делать через расширение, а что нет

к статье я бы добавил следующее:
1. полностью согласен, для одного объекта/формы отдельное расширение.
одно расширение опасно тем, что при ошибке подключения теряется весь функционал, который заложен в нем
а при отдельных расширениях только небольшая часть отключается и его можно будет легко поправить
2. да, лучше делать программные изменения
но новые элементы формы я обычно добавляю на форму в редакторе. Для них обязательно использую префиксы, новые группы с префиксами и никогда не изменяю типовые реквизиты на форме, только программно
проблем пока не было
3. согласен, аннотация Вместо - это крайний случай и часто бывают проблемы с расширением после обновления, но есть и плюсы…
Последний раз ее применял для доработки печати ТТН и УПД.
Вместо вызывает типовую процедуру получения данных, которая возвращает результат запроса
Этот результат выгружается в ТЗ, обрабатывается, добавляются новые колонки с данными при необходимости и помещаются обратно в результат.
Таким образом при изменении типовой процедуры ничего не сломается даже при изменении запроса или колонок результата, а дальше в коде я ориентируюсь на свои добавленные колонки, которые тоже останутся и не мешают работе типовой.

4. согласен, но если функционал как-то пересекается, то можно общий функционал вынести в отдельный общий модуль конфигурации, например.
Здесь все зависит от решаемой задачи.
5. да, я пока тоже не доверяю хранение важных данных расширению, добавляю новые объекты в конфигурацию.
6. отдельного реестра не веду, все описание в комментариях в расширении или в отдельном макете.
Но для удобства анализа версии расширений – использую реквизит Версия, в него записываю последнюю дату редактирования расширения, например, 10.04.2019
Таким образом при большом количестве расширений очень удобно понимать в какой базе какая версия и переносить изменения, например, из копии в рабочую. Присваивать просто номер версии типа 1.1 неудобно, потому что не известно какая версия последняя, а с датой всегда понятно.

Также после окончательной готовности расширения удаляю все не используемые реквизиты/объекты, отключаю все не нужные для меня зависимости и контроли, добиваюсь, чтобы проверка конфигурации расширения не выдавала ошибок.
Таким образом в расширении остается только измененные и важные для расширения объекты с отключенными контролями и т.п.
При обновление обязательно проверяю все расширения на применимость и еще раз запускаю проверку конфигурации, если она выдает ошибку – ищу причину и устраняю. Таким образом после обновления можно быт спокойным, что на следующий день рабочая будет стабильна и тебя не засыпят ошибками пользователи.
Из недавнего – в КА 2.4 изменилось название документов с ПоступлениеТоваров на Поступление товаровНаСклад, а оно использовалось в двух расширениях в проверке типа и в запросе. Проверка конфигурации естественно выдало эту ошибку, и я ее исправил сразу после обновления до наката на рабочую. Если бы не делал такую проверку, то на следующий день два важных функционала отвалилось бы с ошибкой и утро началось бы не с кофе…
VyacheslavShilov; mvxyz; bazelyukandrei; Angealtor; AllexSoft; o.nikolaev; Krio2; worker1c; ellavs; +9 Ответить
73. rpgshnik 3631 10.04.19 07:23 Сейчас в теме
Хорошая публикация. Расширения использую. Фактически самостоятельно пришел к тем же рекомендациям/правилам:
1. Не дробить расширения, где-то слышал сплетни, что несколько расширений - тормозят базу, а одно нет. По этому одно расширение на одну конфигурацию, желательно конечно!
2. Изменять свойства элементов форм программно, согласен.
3. Минимизация использования директивы &Вместо это вообще святое, уже не однократно черпнул горя. Надеюсь директива &ИзменениеИКонтроль поможет в этом, но практика показывает, режим совместимости на типовых конфигурациях очень сильно не успевает за актуальной рабочей версией платформы. Когда она будет? Через год, минимум наверное :)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)
5. Все новые объекты строго в основной конфигурации, удаление расширения явно приведёт к потере данных. Тем более создание новых объектов ни как не повлияет на обновление. А уже обработка их на форме и т.п. строго в расширение. Так же слышал по сплетням, что общие модули так же лучше создавать в основной конфигурации и якобы длительные операции значительно быстрее отрабатывают в основной конфигурации, а не в расширении.
6. Реестры доработок в целом для всего это плюс.
9576836; ids79; kostas; Interrupted; lefthander; ellavs; +6 Ответить
90. e-tixom 10.04.19 21:13 Сейчас в теме
(0) (86) Хорошая статья. Спасибо.
У нас Бухгалтерия 3.0. На расширении сделана целая подсистема со своими справочниками и документами. https://infostart.ru/public/956446/ Сначала были опасения о потере данных, но было условие не менять конфигурацию. Рискнули. Пока все нормально. Были глюки с установкой обновлений, кажется февральских. Приходилось отключать расширения и после загрузки конфигурации закрывать конфигуратор и продолжать обновлять уже в пользовательском режиме. Но сейчас проблема ушла. В принципе, расширения - довольно хороший инструмент. Среди плюсов также можно также отметить возможность использования его для отладки, например, новых печатных форм или отчетов.

Из проблемных ситуаций могу отметить:
1. никогда не получалось динамическое обновление расширений и подключение новых при работающих пользователях. Возможно это был глюк платформы или релиза, но я больше не рискую: быстрота не стоит возможной потери данных. Лучше как положено: архив и т.д. ...
2. В формах списков добавленных справочников и документов отсутствует стандартная команда "вывести список". Создавала даже тему на форуме https://forum.infostart.ru/forum29/topic204577/ . Но решение не известно (по крайней мере мне).
3. В добавленных документах нет стандартных кнопок "Дт Кт" и "Структура подчиненности" (соответственно они не отображаются в структуре подчиненности объектов основной конфигурации). Допилить, конечно, можно, но уже с помощью своих кнопок.
Yashazz; ellavs; acanta; +3 Ответить
92. dsdred 3251 12.04.19 11:28 Сейчас в теме
45. nagimo 7 08.04.19 13:19 Сейчас в теме
Спасибо.
Очень полезная статья!

насчет Используете ли Вы расширения в своей работе?
Использую. Я их фанат! )) Очень доволен. Но в основном использую в небольших организациях.

Из проблем:
1. Действительно, после каждого обновления приходится пока актуализировать заимствованные формы. Думаю воспользоваться советом и формировать их программно. Хотя в большинстве случаев обхожусь дополнительными реквизитами формы без изменения самой формы.
2. Так и не связал их с хранилищем 1С.
3. Постоянно забываю про проблему с конструктором запроса - сначала ступор - почему нет большинства объектов конфигурации, и только потом доходит, что это же расширение. Приходится делать лишние движения с вызовом конструктора из обработки или кода основной конфигурации.
4. Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо.
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 67 07.04.19 00:29 Сейчас в теме
5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию.

Это совет для какой платформы 1С?
8.3.13 кажется всё хорошо с этим. К тому же, должны быть бэкапы, если переживаете за сохранность данных.

Второй момент, получится ли обновить конфигурацию снятую с поддержки с возможностью изменений - скриптом, когда баз много?
Чтобы не программист 1с нажимал кнопки?
11. ellavs 1022 07.04.19 10:26 Сейчас в теме
(1) да, разработчики сделали многое в направлении безопасного хранения данных в расширениях, у нас пока побаиваются, поэтому в нашем случае - всё хранение только в конфигурации. Я честно предлагала попробовать, но руководство отказывается.
31. A_kryl 161 08.04.19 08:25 Сейчас в теме
(1) А пробовали запросы например писать из основной конфы к реквизиту расширения, или код какой? или внешний отчет/обработку? Мне показалось крайне неудобно, может какой то фокус есть с настройкой? пока вижу новые объекты только для полностью независимого от основной конфы расширения.
32. dock 44 08.04.19 08:43 Сейчас в теме
(1)
Второй момент, получится ли обновить конфигурацию снятую с поддержки с возможностью изменений - скриптом, когда баз много?
Чтобы не программист 1с нажимал кнопки?


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

Второй вариант - обновление из хранилища.Но обновлять из хранилища рабочие базы... Ну это если один разработчик держит все эти базы :)

З.Ы. не все комменты внимательно прочитал, но при беглом просмотре не увидел ответа на данный вопрос :)
33. acanta 08.04.19 08:50 Сейчас в теме
(32) На рабочей базе без возможности изменения? А если придет другой разработчик, он сможет включить возможность и выполнить доработки?
2. Dream_kz 129 07.04.19 05:38 Сейчас в теме
0. Не использовать расширения, так как это кривой механизм, который работает неизвестно как
belyakooov; maksa2005; dnikolaev; Mi4man; Vasvas05; sergathome; paybaseme; AnddnA; frkbvfnjh; Evg-Lylyk; asupsam; triviumfan; Soloist; Vladimir Litvinenko; +14 10 Ответить
3. peterxx 21 07.04.19 07:19 Сейчас в теме
(2)
так как это кривой механизм, который работает неизвестно как

Да бросьте уже нагнетать обстановку, ну или примеры кривизны в студию. Я, признаться, побаиваюсь еще добавлять данные в расширения, но что касается кода, особых претензий к механизму нет.
Рамзес; DolPew; OlgaKonyakhina; ellavs; +4 1 Ответить
12. Vladimir Litvinenko 2869 07.04.19 11:01 Сейчас в теме
(3)

Пример 1: https://t.me/ssl1c/18325
Пример 2: https://t.me/ssl1c/18731

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

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


Но когда модификации типовой конфигурации действительно требуют адаптации под новый релиз конфигурации поставщика, расширения перестают выполнять свою функцию "упрощения обновления" и только скрывают от глаз проблему, которую должен решить релиз-инженер. О ней узнают по факту накатки обновления или от пользователей.

Совет из этой публикации менять формы только программно - из той же области.


P.S.: Для Бухгалтерий и ЗУП-ов расширения хороши. Постоянная надёжность конфигурации не нужна, на исправление багов времени всегда достаточно. Ценность замочка на объектах метаданных высока по психологическим причинам )) Почему бы и нет )) Проблема только в том, что набив руку на нетребовательных к надёжности конфигурациях специалисты потом эти приёмы переносят на конфигурации, требующие больших модификаций и высокой надёжности, в том числе отсутствия косяков сразу после операции обновления, а не через неделю после вала сообщений от пользователей.
monkbest; frying; dnikolaev; o.nikolaev; Danil.Potapov; kostas; AnddnA; sergathome; Dream_kz; +9 Ответить
42. triviumfan 92 08.04.19 12:30 Сейчас в теме
Поддерживаю.
(12)
особенно для нечётных релизов 8.3.11, 8.3.13 на которых обкатываются нововведения

Откуда инфа? Сторонник теории заговора релизов или офф. источник?
53. Vladimir Litvinenko 2869 08.04.19 14:23 Сейчас в теме
(42) Достаточно наблюдений за режимом совместимости ERP и сообщений о "детских" ошибках платформы на форумах, которых значительно меньше в четных релизах. На 8.3.11 багов и в конфигураторе было достаточно с незакрывающимися окнами и нераскрывающимися объектами в дереве метаданных ))


ERP 2.0 была в режиме совместимости 8.3.6, ERP 2.1 и 2.2 - 8.3.8 и 8.3.10, ERP 2.4 - 8.3.12. Аналогично конфигурации КА 2 и УТ 11. За бухгалтериями не следил, но подозреваю, что там аналогичная ситуация.

Официально заявлений о том, что функционал нечетных релизов "сырой" мы конечно нигде не увидим, да и вообще всё это неправда, и, как Вы написали, несостоятельная теория заговора )) Может быть там внутри 1С другие причины так между релизами переключаться. Но наиболее вероятно, что ERP на 8.3.15 с директивой в расширениях &ИзменениеИКонтроль мы не увидим. Надо будет ждать режима совместимости с 8.3.16.
AllexSoft; gregoryz; +2 Ответить
56. triviumfan 92 08.04.19 16:08 Сейчас в теме
(53) Ясно, тогда это всего лишь стечение обстоятельств и некий "пук", услышанный на сарафанном радио/ОБС.
58. Vladimir Litvinenko 2869 08.04.19 18:13 Сейчас в теме
(56) При отсутствии официальной информации нужно полагаться на наблюдения и практику и находить чёткие закономерности. Потом можно к удивлению обнаружить подтверждение того, что это не просто наблюдение, а "политика партии", где-нибудь на партнерском форуме или в презентациях 1С ))
kostas; sergathome; +2 Ответить
104. Vasvas05 22 18.07.19 19:05 Сейчас в теме
(42)Разработчики 1с на конференции так говорят, что нечетные номера - это тест версии
26. Dream_kz 129 08.04.19 07:54 Сейчас в теме
(3) Ну вот, данные не добавляете, а просите примеров. Лезем на партнерский форум, либо на багбоард, и смотрим ошибки по расширениям.
Понятно, что для простых изменений (форму подправить и т.п.), все нормально работает, а вот что-то сложное, ну такое.
sergathome; +1 Ответить
106. Crazy_kz 25 19.07.19 08:40 Сейчас в теме
(3) УТ 11, добавил в расширение документ "Реализация товаров услуг" перестала формироваться структура подчиненности документов.
6. insurgut 207 07.04.19 09:27 Сейчас в теме
(2) Может вы просто не умеете их готовить? С переходом на расширения я уже и забыл, когда снимал с поддержки типовые конфигурации. Много чего снятого с поддержки поставил обратно на поддержку, перенеся доработки в расширение. Полет нормальный :)
o.nikolaev; kit; elvira17; Jeka44; Риник; ids79; mvxyz; ellavs; +8 Ответить
19. vcv 89 07.04.19 13:25 Сейчас в теме
(6) Или готовить не умеем, или у вас изменения мелкие. У меня сейчас проект по ЕРП. От расширений отказались, проблем много было. Хотя изменений типовой конфы не так много - десяток документов, десяток справочников, пара десятков общих модулей...
o.nikolaev; kostas; sergathome; AnddnA; triviumfan; Vladimir Litvinenko; +6 Ответить
21. noprogrammer 236 07.04.19 14:16 Сейчас в теме
(19) Можно озвучить проблемы с которыми столкнулись при использовании расширений? интересны именно проблемы (причины отказы от расширений). У нас в расширения вынесены следующие контуры (меркурий,егаис,онлайн-кассы и много чего еще)

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

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

Другая не менее важная проблема это невозможность использовать в расширениях механизм доп.атрибутов, точнее невозможно использование объектов расширения (все так же из-за типизации)

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

Работа с таблицей невозможна. Структура таблицы несовместима с текущими расширениями конфигурации.
27. Dream_kz 129 08.04.19 07:58 Сейчас в теме
(6) Возможно, но какие доработки у вас перешли в расширения? Добавьте справочник, регистр, а потом с радостью узнайте что при обновлении потеряются данные.
При обновлении доработанных конфигураций у меня тоже проблем не наблюдается, движения делаются по подпискам, формы меняются программно через переопределяемые модули, отчеты/обработки через механизмы БСП.
kostas; sergathome; +2 Ответить
103. Vasvas05 22 18.07.19 19:04 Сейчас в теме
(2)+++ , при грамотной доработке, намного лучше, чем расширения
4. МимохожийОднако 141 07.04.19 08:13 Сейчас в теме
По поводу документирования. В расширения можно добавить объект, хранящий историю изменений и документацию.Например, в виде макета.
Это не исключает копирование этой информации в отдельное место, но позволяет при работе с расширением сразу же получать нужную информацию. Я такое использую во внешних обработках и отчетах, добавляя текстовый макет История.
Для сложных случаев там же храню описание задачи (ТЗ), которая решалась в данной разработке
AllexSoft; o.nikolaev; Deslime; AndrewKop; _Farsh_; Doom2w; mondordom; Aleskey_K; Jeka44; nagimo; lefthander; A_Max; cherptat; NightAngel; ids79; frkbvfnjh; Leon29; PowerBoy; Dmitrij-2; andreich_ru; mvxyz; tormozit; ellavs; +23 Ответить
8. ellavs 1022 07.04.19 10:21 Сейчас в теме
(4) Хорошая идея, спасибо.
105. Vasvas05 22 18.07.19 19:06 Сейчас в теме
(4)а просто хранить документацию к нас не умеют, это все печально.
5. insurgut 207 07.04.19 09:26 Сейчас в теме
Все по делу. Жаль только конструкцию &Вместо все-таки приходится использовать :(

По п.5 можно ещё максимально продумать структуру дополнительных данных - может можно обойтись дополнительными и реквизитами и сведениями? Хранение их так же безопасно и не требует снятия конфигурации с поддержки.
o.nikolaev; ellavs; +2 Ответить
9. ellavs 1022 07.04.19 10:23 Сейчас в теме
(5)
Жаль только конструкцию &Вместо все-таки приходится использовать

Новая аннотация &ИзменениеИКонтроль частично должна решить этот вопрос...
7. vcv 89 07.04.19 10:09 Сейчас в теме
Главная проблема расширений - это режим совместимости в типовых. В Документообороте, например, 8.3.8 :(
Aleskey_K; Jeka44; Kamali; dsdred; ellavs; +5 Ответить
10. ellavs 1022 07.04.19 10:24 Сейчас в теме
(7) Да, есть такое. Очень хочется использовать новшества платформы в области расширений, а не получается (
13. Vladimir Litvinenko 2869 07.04.19 11:31 Сейчас в теме
(7) Главная проблема - это отсутствие трехстороннего сравнения/объединения и сокрытие от релиз-инженера информации о том, что наши алгоритмы требуют адаптации к новому релизу типовой конфигурации. Возможность завершить объединение не зная о том, что надо изменить наши алгоритмы.
Артано; AllexSoft; +2 Ответить
14. ellavs 1022 07.04.19 11:47 Сейчас в теме
(13) как вариант новая аннотация &ИзменениеИКонтроль частично может помочь (естественно, если есть возможность использовать платформу 8.3.15). Там автоматически происходит проверка на изменение кода заимствованных модулей и оповещение, если произошли изменения.
15. Vladimir Litvinenko 2869 07.04.19 12:08 Сейчас в теме
(14) Да, это поможет выявить проблему. Но:

1) Система сообщит "ваш метод требует адаптации", но что именно адаптировать нам придётся узнавать самим. Трехстороннее сравнение/объединение придётся организовывать самим, например выгружая все версии кода в файл и применяя внешние инструменты или делая попарное сравнение файлов в 1С. Кто будет с этим заморачиваться? Скорее глазами по тексту пробегать будут, что повышает риск ошибки. На небольших примерах в "Зазеркалье" всё выглядит красиво. А если метод на 300-500 строк и код разделён большими блоками запросов? Так часто бывает в типовых.

2) &ИзменениеИКонтроль появится в 8.3.15. А значит для того же семейства конфигураций ERP/КА/УТ станет доступно только в 8.3.16 где-то через год. На "пробную" нечетную платформу их переводить не будут. Ждать ещё долго. А расширения массово лепятся как снежки уже сейчас, без всяких аннотаций &ИзменениеИКонтроль.


Не говоря уже о ставших популярными шутках на счёт необходимости применять беспощадные аннотации &КонецУдалить и &КонецВставить совместно с &ИзменениеИКонтроль ))
AllexSoft; sergathome; ellavs; +3 Ответить
17. ellavs 1022 07.04.19 12:46 Сейчас в теме
(15) тут соглашусь. Как в том анекдоте про пожарных. Как обновление, так хоть увольняйся )) приходится брать из реестра все блоки модулей, помеченные как наследуемые &Вместо, и ручками каждый проверять. Хорошо хоть в конфигурации, с которой чаще всего работаю, подняли совместимость до 8.3.12. Так и до 8.3.15 недалеко, может &ИзменениеИКонтроль хоть немного облегчит труд.
36. Darklight 32 08.04.19 10:48 Сейчас в теме
(7)Режим совместимости можно повышать вручную (не дожидаюсь когда он повысится вендором конфигурации):
1. Обычно это не вызывает больших проблем - всё быстро можно урегулировать
2. Но возникают некоторые дополнительные сложности при установке апдейт-обновлений - но, обычно, тоже нет больших сложностей
3. Главное при апдейте обновления от вендора не забыть о том, что режим совместимости надо поправить снова (у корня конфигурации)
4. Ну, и сначала надо на копии тестировать - выявить косяки, поправить и переходить потом к рабой базе (бэкап обязателен)

Мы так повышали уровень совместимости и для документооборота и даже для УПП - где без повышения уровня совместимости, например, расширения вообще не будут доступны. Ничего страшного в этом нет - но проблемы всё-равно решать придётся.
123. TerveRus 05.11.19 12:04 Сейчас в теме
(36) а можно озвучить с какими примерно проблемами придется столкнуться и сколько по времени у вас уходит на адаптацию?
124. Darklight 32 05.11.19 12:28 Сейчас в теме
(123)Давно это было, уже не помню, при обновлении уже сейчас нет больших проблем (разве что много изменений показывает - которых либо вовсе нет, либо какая-то ерунда и надо просто взять версию поставщика), только при переходе были проблемы.
В основном проблемы были с именами полей метаданных и функций - в новых версиях конфигураций появляются новые встроенные или появляются просто запрет какого-то имени - и возникает конфликт, когда в конфигурации это имя использется -чаще все го нужно просто везде переименовать (дабы платформа сейчас это легко позволяет автоматизировать).
Вроде как с регистрами (вроде сведений_ были какие-то траблы - не реструктуризировались (парочка - но это индивидуально) - пришлось их выгружать, очищать и потом загружать.

Не бойтесь сами посмотреть - сделайте копию и на ней проверьте. Рекомендую только делать всё на серверной базе и менять режим совместимости поэтапно (по одной версии) - делать реструктуризацию - как при обновлении.
А в конце на копии запустить перепроведение всех документов. Ну и РИБ перенастроить заново и проверит (конфигурацию придётся так же по частям переносить в другой узел, возможно через РИБ не пройдёт - придётся вручную переносить) - если используете.

Поищите на инфорстарте - тут вроде были статьи на то как перейти на версию совместимости с поддержкой расширений для старых конфигураций
TerveRus; +1 Ответить
16. пользователь 07.04.19 12:13
(0) хорошая статья.

Иногда вижу применение расширений необдуманно на столько, что они напоминают оператор GOTO.

Но сам механизм хороший, если разумно подходить.
18. ellavs 1022 07.04.19 12:47 Сейчас в теме
(16) Спасибо. Сложно всё обдумать наперед. Столько на грабли наступили уже, пока более-менее пришло какое-то понимание.
20. andryandry 94 07.04.19 14:12 Сейчас в теме
Поделитесь опытом кто как борется с такой проблемой - в конструкторе запросов в расширении не доступны системные ревизиты добавленных в расширение справочников - например "Владелец" или "родитель".
Сам ставлю времмено реквизит "ссылка", потом меняю руками в тексте модуля.
22. ellavs 1022 07.04.19 15:49 Сейчас в теме
(20) честно говоря, даже не задумывалась об этом, т.к. не пользовалась конструктором в расширениях...
28. agent00mouse 253 08.04.19 08:09 Сейчас в теме
(20)
например "Владелец" или "родитель".

!!!Для этого нужно захватить форму списка.!!!

А теперь вопрос! ДЛЯ ЗАЧЕМ??!?!?! Если Я и так уже справочник захватил и его родителя или владельца!

А ещё, захватив форму списка, тянем за собой в расширение все реквизиты и все связанные с ними перечисления, справочники, документы из основной конфигурации. Оно нам надо?

По моему расширения годны пока только для модификации или замены чистого кода, не более.
34. andryandry 94 08.04.19 09:08 Сейчас в теме
(28) Да, спасибо за совет. действительно после захвата формы списка справочника в конструкторе запроса появляется родитель.

Я не сохраняю захваченные для построения запросов объекты в расширении ))) не переживайте.
43. lefthander 08.04.19 12:39 Сейчас в теме
(20)Я необходимый реквизит просто добавляю в объект. Потом можно будет его удалить из расширения.
57. andryandry 94 08.04.19 16:52 Сейчас в теме
(43) с родителем и владельцем такое не прокатывает
23. dsdred 3251 07.04.19 22:31 Сейчас в теме
Статья хорошая.
Из неудобств можно отметить работу с СКД и прочие запросы, но выход простой писать запрос либо в обработке, либо другим способом.
Раньше много было косяков в конфигурациях 8.3.8 например, отладку надо было с ключем "РежимОтладки" запускать, но сейчас с этим все хорошо.
Из последних Косяков, при переходе на платформу 8.3.12.1469 напарывался на описанное в данной теме https://forum.infostart.ru/forum9/topic191359/
24. oldcopy 173 08.04.19 01:33 Сейчас в теме
Из реальных косяков с расширениями мы столкнулись только в РИБ, когда расширение распространившись в базы фактически обрушило их работу. Это было крайне неприятно, хорошо что изменения уехали в ночь и хватились утром, успели все исправить до наплыва покупателей.
44. ildary 21 08.04.19 12:59 Сейчас в теме
(24) Не могли бы Вы подробнее сказать, что именно сломало расширение в РИБ? Мы сейчас планируем создавать расширения, распространяемые по РИБ и хотелось бы избежать проблемы как у Вас.
46. oldcopy 173 08.04.19 13:42 Сейчас в теме
(44)
Не могли бы Вы подробнее сказать, что именно сломало расширение в РИБ? Мы сейчас планируем создавать расширения, распространяемые по РИБ и хотелось бы избежать проблемы как у Вас.


Сломало полностью все, начиная от механизма обмена, заканчивая нормальной работой распределенных баз. Практически на любое действие: Ошибка исключительной блокировки информационной базы. При том, что в самом расширении ничего такого не было. Расширили табличную часть Товары документа Поступление, добавив туда две колонки Дата изготовления и Срок годности (дата и число) и добавили обработку выгрузки на весы CAS для работы с бесплатным драйвером. Причем все это давно уже работало, но для нового клиента решили не трогать конфигурацию и вынести в расширение. Вынесли...

Самое гадкое в этом то, что расширение сломало типовой механизм обмена и "починить" базы РИБ просто удалив расширение из центрального узла не получится. Нам пришлось отвязывать базы от центрального узла, удалять в них расширение руками и привязывать заново. Хорошо что заметили это рано утром и магазинов было всего три.

Конфигурация: Розница 2.2.1.24, платформа 8.3.13.1690
Прикрепленные файлы:
47. ildary 21 08.04.19 13:46 Сейчас в теме
(46) то есть главная особенность Вашего расширения - добавление данных (а не только изменение текущих)? Мы пока не планируем добавлять что-то новое в расширение, а в первую очередь только для оперативных патчей (очень много баз и цикл обновления довольно тяжелый из-за выгоняния пользователей).
TerveRus; +1 Ответить
25. krollzlat 08.04.19 07:54 Сейчас в теме
У нас одно расширение, и плодить не хочется. Как писали выше уже и забыли когда конфигурацию трогали...Более 100 новых объектов методанных, с данными проблем нет. Была недавно забавная проблема, сняли совместимость, добавили в расширение план обмена и изменили состав типового.Но потом пришлось откатить совместимость, из расширения удалили изменения по планам обмена, но оно все равно ругалась что такие объекты есть.Решили какими то танцами.
107. s22 19 19.07.19 11:34 Сейчас в теме
(25)
план обмена
а как решили? использовали типовую синхранизацию?
и как создавать Регламентированные задания?
29. oberonm 9 08.04.19 08:18 Сейчас в теме
Были косяки на первых расширениях, Доработки в ДО. более 150 пользователей онлайн.
1. в локальной сети всё работало стабильно
2. Тонкий клиент и web с удаленными пользователями происходили ошибки из серии "Ошибка разбора XML" при открытии формы с расширением. Ошибки происходили нерегулярно. раз-два в день. у некоторых пользователей.

в итоге, пока побаиваюсь работать с расширением когда пользователей более 100 пользователей и не все работают в одной локальной сети
30. ids79 8291 08.04.19 08:18 Сейчас в теме
Спасибо, хорошая статья.
"Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль,"
Не знал об этом.
38. Darklight 32 08.04.19 11:54 Сейчас в теме
(35)15-релиз пока ещё не вышел даже для ознакомоления
39. dsdred 3251 08.04.19 12:06 Сейчас в теме
(38)Знаю.
В статье упоминается особенность 8.3.15.

Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль, в какой-то степени она решит многие проблемы, связанные с тем, что Вам нужно подправить лишь пару строк в заимствованной функции/процедуре модуля, но Вы не хотели бы перехватывать его полностью, с риском в дальнейшем постоянно отслеживать изменения данного модуля (хотя даже при использовании &ИзменениеИКонтроль риски остаются).

Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)
40. Darklight 32 08.04.19 12:13 Сейчас в теме
(39)Я знаю, что Вы знаете. Но большинство не знает - т.к. данного релиза ещё нет в "свободном" доступе. От того и такие удивления.
92. dsdred 3251 12.04.19 11:28 Сейчас в теме
93. ellavs 1022 12.04.19 11:44 Сейчас в теме
97. rpgshnik 3631 17.04.19 12:22 Сейчас в теме
(92) я ещё к 12...13... 14... не успел привыкнуть :))) ждём 8.4 чтоли уже :))
98. dsdred 3251 17.04.19 12:45 Сейчас в теме
(97)
ждём 8.4 чтоли уже

Дождемся ли? ;))
99. rpgshnik 3631 17.04.19 13:22 Сейчас в теме
(98) дождемся... дождемся и версию Х :)
37. Darklight 32 08.04.19 11:53 Сейчас в теме
За статью спасибо. Но, напишу свои замечания к Вашим предложениям:

1. Не дробить расширения для одного и того же объекта конфигурации
Дельный совет. Но я бы пошёл бы ещё дальше - ВООБЩЕ НЕ ДРОБИТЬ расширения - т.е. если какую-то конфигурацию. поддерживает команда разработчиков с разными проектами - они могут вести их в отдельных расширениях в своих тестовых базах и отдельных хранилищах конфигураций расширений (но это тоже не обязательно - можно вести всё в одном расширении/хранилище)
А перед установкой в рабочую базу (вернее в продакшен-конфигурацию, возможно так же имеющую своё отдельное хранилище) переносить изменения из разных конфигураций-расширений - в одну (дабы сравнение-объединение для конфигураций-расширений вполне нормально работает) - если их несколько или так и подключать к продуктивным базам единое расширение (если оно сразу был одно). То есть - сводить все свои доработки, в итоге, к одной конфигурации-расширения (ну, максимум к 2-3 - если уже очень приспичит) и подключать ко всем ИБ.

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

2. Изменения расширяемых форм делать программно
Тоже дельный совет. Он касается не только расширений. Увы, даже в управляемых формах и без расширений надёжнее все изменения вносить программно. Эх... жаль-только, что нет возможности писать программные макросы, которые отработают ещё на стадии компиляции в конфигураторе - один раз внеся изменения в форму - а не каждый раз при её создании в runtime.
Ну и фреймов не хватает - ведь один раз так перенести элементы в программный код это не страшно. А если их постоянно приходится модифицировать - это дальше чаще придётся уже работать исключительно с программным текстом, а нес формой.
И ещё есть сложности - порой при добавлении новых элементов на форму приходится перемещать имеющиеся - это самое неприятное. Впрочем это может быть чревато большими проблемами при любом подходе: и программном и при изменении на самой форме.

3. Минимизировать использование аннотации &Вместо
Конечно, с приходом аннотации "&ИзменениеИКонтроль" использование "&Вместо" должно существенно сократиться, но 15- релиза ещё нет даже в бете. Ну а далее - боюсь всё-равно будет куча проблем с сопровождением - там время покажет, пока ещё нечего даже пощупать.
Но, сам формат данной аннотации - мне уже сейчас не нравится - идея хорошая - исполнение отвратительное (Увы это норма для 1С).
Лучше бы парадигму аспектного программирования в 1С привнесли - вот это был бы прорыв.

4. Делать независимые друг от друга расширения
Совет был бы дельным. Но, я уже написал, в самом начале, что лучше вообще делать одно расширение (или пару - полностью независимых друг от друга). Иначе - будут проблемы другого рода - если разные расширения имеют общую основу (как общие модули, так и другие метаданные) - то если их делать полностью автономными - то - эти общие элементы будут в них дублироваться от того сразу ряд проблем:
а. Дублирование кода и метаданных - нужно будет во всех расширениях вручную поддерживать его актуальность - особенно сложно, когда его будут менять в разных проектах и разные команды.
б. Дублирование метаданных так же вызовет конфликт дублирования имён - при установки таких автономных расширений в одну ИБ. Да, конечно же - придётся
разграничивать их все префиксами разными расширений
в. Дублирование метаданных, сохраняемых в СУБД - вообще, можно сказать, невозможно, в большинстве случаев
г. Дублирование да даже не сохраняемых в СУБД метаданных - может быть проблемным - когда, скажем, нужно будет иметь расшаренные глобальные перенные
(параметры сеанса пока расширения вообще не поддерживают - в 14 релизе).
д. Дублирование метаданных приведёт ещё и к дублирование прав доступа к ним (ролей) - настройка прав превратится в хаос.
е. Дублирование перехватчиков событимй (да и просто вызовов функций), реализующих одну и ту же логику - создаст ещё больший хаос.
ж. И отдельно упомяну о том, что многие алгоритмы нуждаются в настройках - их где-то надо хранить - плрохая идея дублировать один и тотжемеханизм работы
с настройками для каждого расширения - ведь его ещё и настраивать придётся в отдельных автономных формах.
В общем, проблем много. Лучше всё-таки все свои изменения вести в одном расширении. Как я написал выше - можно сначала вести отдельные расширения, в и т.ч. создавать общие-расшаренные (ну тут тоже желательно не плодить много таких общий расширений) - а потом всё переносить в одно (сравнением/объединением), без дублей - его уже ставить в продакшен-базы.

5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
Может и дельный совет. Пока расширения не поддерживают всех объектов метаданных. Но тут главная проблема именно в том, что приходится разделять проекты на части - что будет размещено в расширениях, что в нужно будет разместить в основной конфигурации. Жить с этим вполне можно - но очень неудобно. Но, пока без этого вообще не обойтись. Самое неприятное, что нельзя предопределённые элементы вот так нормально добавить, и не бояться их потерять. И с расширением составным типов всё тоже не очень гладко.

6. Вести реестр расширений
Совет дельный, но делать это очень не удобно. Увы - с документированием конфигураций в 1С Предприятие 8 всё очень печально. А вести в отдельном приложении - не очень удобно. Разве что только настраивать GIT и подключать сторонние приложения для решения вопросов документирования уже к GIT-депозитарию -- но это очень не простой путь для 1С разработчиков.
Вести в OneNote - тоже как-то не очень удобно (лично сколько раз порывался - но так и не смог полюбить OneNote - мне не удобно, но, возможно, я просто не научился его готовить).
Ввёл, как-то в отдельной кустарной конфигурации (ещё до появления расширений - для фиксации доработок обычных конфигураций) - это даже как-то удобнее было (метаданные автоматически туда подтягивались фоновым процессом - та же был учет задач и проектов - нужно было только подцепить метаданные к уже имеющимся там задача и всё) - но такую конфигурацию нужно разрабатывать себе самостоятельно - под свои предпочтения и свой учет планирования работа ИТ-отдела.
VyacheslavShilov; papche; plus1s_a; Drivingblind; Риник; Mi4man; jif; davdykin; kostas; dvpk1c; user1183297; VladC#; YPermitin; Il; Vladimir Litvinenko; +15 Ответить
60. ellavs 1022 08.04.19 22:26 Сейчас в теме
(37)
переносить изменения из разных конфигураций-расширений - в одну

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

так и не смог полюбить OneNote

Просто это один из моих любимых программных продуктов, поэтому не смогла удержаться и не упомянуть его ;)

По остальным пунктам во многом соглашусь.
63. Darklight 32 09.04.19 09:48 Сейчас в теме
(60)хорошее предложение, но не всегда можно применять. Например, некоторые расширения у нас носят "сезонный" характер (например, используются только летом) и периодически "вырезать" их из одного большого расширения было бы не очень удобно.

а. Как я написал - при ОЧЕНЬ БОЛЬШОЙ и ОБОСНОВАННОЙ ПОТРЕБНОСТИ - можно иметь 2 ну максимум 3 консолидированных расширения, реально мало связанных друг с другом (или одно общее-основное - и несколько дополняющих). Но это скорее исключение - когда это реально удобнее, чем всё в одномю

б. Для Вашего же примера - идеально подходя, как раз таки, опции настройки - которыми Вы будете включать/выключать функционал в ИБ по потребности (если его реально нужно выключать, т.е. он будет мешать не в своё время).
Для опций - просто заводите регистр сведений (лучше не периодический) и ПВХ (будут едины для всех расширений; константы расширения пока не поддерживают). И коде, через модуль повторного использования получаете и проверяете эти опции - и выбираете использовать или не использовать те или иные алгоритмы; отображать или нет те или иные элементы формы.
При желании - подключаете к этим регистрам - функциональные опции (но их расширения пока тоже не поддерживают - поэтому их придётся добавлять в основу. конфигурацию) - но я не вижу большой потребности в их использовании.

По поводу "OneNote"
Мне кажется настоящий разработчик на 1С в короткие сроки сделает куда более удобный инструмент документирования, чем "OneNote". Особенно, если уже возьмёт за основу какую-нибудь готовую конфигурации класса ITIL или класса ITSM, с поддержкой работы через WEB.
А потом ещё и с GIT её интегрирует или с другими WEB-ориентированными специализированными продуктами.
Но это просто моё мнение ;-)
41. Pr-Mex 136 08.04.19 12:24 Сейчас в теме
Разрабатываем и тестируем типовые конфигурации.
Расширения очень сильно помогают.
Иногда надо поле своё на форму добавить.
Иногда колонку вывести в форме списка.
Очень сильно выручают.
45. nagimo 7 08.04.19 13:19 Сейчас в теме
Спасибо.
Очень полезная статья!

насчет Используете ли Вы расширения в своей работе?
Использую. Я их фанат! )) Очень доволен. Но в основном использую в небольших организациях.

Из проблем:
1. Действительно, после каждого обновления приходится пока актуализировать заимствованные формы. Думаю воспользоваться советом и формировать их программно. Хотя в большинстве случаев обхожусь дополнительными реквизитами формы без изменения самой формы.
2. Так и не связал их с хранилищем 1С.
3. Постоянно забываю про проблему с конструктором запроса - сначала ступор - почему нет большинства объектов конфигурации, и только потом доходит, что это же расширение. Приходится делать лишние движения с вызовом конструктора из обработки или кода основной конфигурации.
4. Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо.
54. lefthander 08.04.19 15:25 Сейчас в теме
(45)Тоже использую в работе. На закрытых конфигурациях небольшие доработки кода.
Из проблем
1. Сам столкнулся когда изменилась форма документа и перестала нормально работать. Обновил в расширении и потерял то что добавлял... Вот тогда на собственном опыте дошел что надо программно добавлять элементы в форму расширения. Пришлось переписать процедуры для большей структурности добавления, и в последующем уже именно туда вписывал необходимые элементы для модификации. Благо таких форм не так много.

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

4 Наследованные в таком случае всегда видны, а вот с оператором &Вместо - это действительно скоро будет засада, ну когда их будет много. Тоже стараюсь их избегать, но не всегда это возможно.
59. ellavs 1022 08.04.19 22:17 Сейчас в теме
(45)
Так и не связал их с хранилищем 1С.

Да, у меня тоже что-то не особо хорошо это выходит, поэтому предпочитаю работать с ними через git.
64. Darklight 32 09.04.19 09:52 Сейчас в теме
(45)
Периодически (но вообще не часто) приходится переписывать некоторые наследованные процедуры - когда меняется состав аргументов. И это не только для процедур с оператором &Вместо
.
Насколько мне известно с 12 релиза (или чуть позже, не помню точно) эта проблема частично решилась. То есть, теперь если в исходной процедуре после обновления появится новый аргумент (со значением по умолчанию) - то это не вызовет ошибки в расширении. Главное, чтобы не в середину вклеили новый аргумент - а то логика может нарушиться.
48. oldcopy 173 08.04.19 13:49 Сейчас в теме
Ну попробуйте, только перед продакшеном обязательно потренируйтесь на кошках, чтобы не было потом мучительно больно.
49. Petr54-ru 90 08.04.19 13:54 Сейчас в теме
Месяц назад впервые сделал расширение для УТ11. История такая, где то пару лет назад делал клиентам доработку УТ11 для работы с кассовой программой Frontol. Часть функционала касающееся маркетинга получилось сделать при помощи дополнительной внешней обработки, а часть функционала касающегося получения данных с кассы пришлось допиливать конфигурацию.

Тогда чесались руки это сделать в виде расширения, но были отзывы, что этот механизм пока сырой и не хотелось пускать под это своих клиентов. А тут недавно УТ глобально обновилось и Библиотека подключаемого оборудования поменялась кардинально. Обрадовался, что теперь наконец то можно будет поработать с расширениями. Я в восторге.
50. vadim1011985 99 08.04.19 13:55 Сейчас в теме
Стоило еще упомянуть о свойстве расширения "Назначение расширения конфигурации" , так как правильное его использование позволяет правильно идентифицировать для чего предназначено расширение , плюс есть особенности с порядком выполнения расширения в зависимости от указанного значения в данном свойстве.
51. kembrik 10 08.04.19 13:57 Сейчас в теме
По первому пункту, как говорится, есть нюансы.

Очередностью расширений прекрасно можно управлять (Утверждение справедливо для платформы 8.3.13.1644 и режиму совместимости Версия 8.3.12)

Для этого открываем свойство расширения и меняем назначение расширения конфигурации. Сначала выполняется Исправление, потом Адаптация а потом Дополнение
Прикрепленные файлы:
VyacheslavShilov; TerveRus; +2 Ответить
52. vadim1011985 99 08.04.19 14:06 Сейчас в теме
С its.1c.ru

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

● Исправление ‑ такое расширение предназначено для исправления ошибок в прикладном решении. В таких расширениях предполагается использование потенциально «опасных» возможностей расширений, например, применение расширения метода с помощью аннотации Вместо. Исправления предназначено для определенной версии прикладного решения. При выходе следующей версии этого решения автор расширения должен проводить анализ применимости созданных расширений в новой версии. Допускается наличие нескольких расширений с таким назначением, но необходимо обеспечить отсутствие конфликтов между такими расширениями, например, несколько таких расширений не должны расширять один и тот же метод с разными целями. Такие расширения могут не учитывать наличия расширений другого назначения.

● Адаптация ‑ такое расширение предназначено для адаптации прикладного решения под условия конкретного клиента. В таких расширениях рекомендуется не использовать потенциально «опасных» возможностей, т. е. тех возможностей, которые могут привести к конфликту расширений при их совместной работе или которые зависят от порядка подключения расширений. Тем не менее, допускается аккуратное использование «опасных» возможностей, при условии, что автор расширения берет на себя полную ответственность за обеспечение корректного функционирования результирующей конфигурации в новых версиях прикладных решений, и с учетом расширений, имеющих назначение Исправление. Предполагается, что в каждый момент времени в информационной базе существует минимальное количество таких расширений. Если в одно расширение невозможно включить весь набор изменений, то рекомендуется расширения с назначением Адаптация разбивать по максимально крупным блокам расширяемого прикладного решения.

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


И вот тут еще был вопрос по взаимодействию расширений в зависимости от назначения расширения
VyacheslavShilov; +1 Ответить
55. lefthander 08.04.19 15:32 Сейчас в теме
(52)Самое смешное что все выше описанное не обязательно, кроме порядка исполнения. А какой порядок будет у 6 исправлений? или трех адаптаций?
Так что предпочитаю если есть возможность все делать в одном расширении определенного типа.
61. ellavs 1022 09.04.19 08:33 Сейчас в теме
(52) да, если всего три расширения, то можно им назначить разные назначения и регулировать последовательность, при большем количестве - это уже сложно регулировать.
62. TimurD 6 09.04.19 08:41 Сейчас в теме
Вообще все вот эти возмущения по поводу расширений, это такие же предъявы к 1С со стороны классических программерах / пользователей, работавших в похожих системах учета. А основная предъява такая: О, это у вас не работет, а это работает, но не так. ООП нет (как у некоторых). Т.е. при оценке нового (особенного отечественного) продукта сводиться только к его минусам. Человек толком не разобрался, но уже отвергает. Хотя, при этом, в его старой системе (текущей) таких функций (не платформы, а системы учета) нет, какие он хочет сразу увидеть в новой программе. И его это устраивает. Ну это же SAP (или как его там). Надо вызывать этаж аналитиков и 2 этажа программистов, чтобы пару полей и кнопку на форму добавить и отвалить кучу бабла.
ЛИЦИМЕРы.
А вот, что касается расширений, то использовать их можно и нужно. Здесь, да и в других делах, главное без фанатизма. + 100 к карме)
65. Darklight 32 09.04.19 10:13 Сейчас в теме
(62)На безрыбье и расширения сгодятся, ну, по крайней мере, после режима совместимости 12 (хотя, вот, возможность добавление в расширение параметров сеанса появилось только в 14 релизе) , а своих констант, определяемых типов, подписок на события, и регламентных заданий, функциональных опций, БП и задач - в расширениях нет до сих пор. Так что они пока ещё обрезки, но определённые задачи ими решать уже можно. Главное, чтобы режим совместимости был не ниже 12 (минимум), а лучше не ниже 14.

Но всё равно - недостатков у архитектуры расширений - море! Хоть те же конфликты дублирования одинаковых метаданных. И невозможность делать приватные (изолированные) метаданные (доступные только внутри расширения). Нет возможностей указывать зависимости (от других расширений, подсистем, версий конфигураций; уж про желание указывать ветвление состава метаданных и реализацию алгоритмов в рамках одного расширения в зависимости от версии конфигурации/платформы куда оно устанавливается), и просто требовать наличие определённых метаданных (хотя бы функциональных опций и привязывать свой функционал к ним, или, в случае отсутсвия некоторых метаданных - автоматически их добавлять - так сказать "в минимально требуемом объёме"). И нет возможности в расширениях добавлять предопределённые данные. Ну уж про отсутсиве возможности расширять расширения - я вообще молчу.


Ещё -до сих пор было нельзя конвертировать проекты расширений и обычных конфигураций друг в друга (хотя бы сравнением объединением) - что очень неудобно в ряде случаев.

Из достоинств - это конечно перехват любых функций и динамическое подключение (и разделение по разделителям), добавление реквизитов к существующим метаданными, расширение их типов и создание некоторых своих метаданных.

Лично я считаю расширения любопытной - но тупиковой ветвью развития.

Но никакой классический ООП тут бы ничего лучше бы тоже не предложил.

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

А ещё должны быть опции интеграции - типа функциональных опций - но определяемых значениями на уровне конфигуратора (в т.ч. по различным условиям - например проверка на наличие тех или иных версий требуемых модулей или версию платформы сборки; ну или задаваемым в ручную - как настройка) - и уже по этим опциям различные части кода и метаданных включаются или выключаются для использования в ИБ. Всё лишнее и несовместимое можно было бы сразу отключить - чтобы оно не загружало ИБ лишним содержимым и не снижало её эффективность (расход памяти, скорость алгоритмов и эффективность запросов к СУБД).
Вот такое моё мнение! А расширения - это лишь жалкая пародия на модульную схему.
sergathome; triviumfan; +2 Ответить
67. TimurD 6 09.04.19 10:37 Сейчас в теме
(65) Вот. Адекватная критика (не меня... расширений). Если бы разработчики 1С (те самые на С) сразу сделали все хорошо, то ни у нас ни у них работы бы не осталось. С другой стороны: есть идея. Для ее воплощения нужно много ресурсов (времени, деньги и т.д.). Но можно сделать более менее рабочий вариант. Да обрезанный, да глючный. А дальше по Скраму.
Это я к тому, что пока мы (или они) будут делать идеальный продукт (типа водопадной модели), к релизу он станет уже не идеальный (в той или иной степени), т.к. время снятие показаний и их реализация самый главный наш враг.
Аминь.
69. lefthander 09.04.19 15:07 Сейчас в теме
(65)
а своих констант, определяемых типов, подписок на события, и регламентных заданий, функциональных опций, БП и задач - в расширениях нет до сих пор.

Что то мне интуиция шепчет а их и не будет. ;) и даже намекает почему... Посудите сами - идея расширений дополнение типовых решений. В идеале не снимая с замка. Но идеал не достижим, а раз так то: подписки - добавление своих в основную конфигурацию типовой функционал не пересекают, а значит при обновлениях никаким образом не мешают.
Остальные объекты аналогично. То есть, все то что можно добавить не используя типовой функционал вполне можно, и я для себя решил, вполне нужно, реализовать в основной конфигурации.

(65)
А расширения - это лишь жалкая пародия на модульную схему.

Пародия, не пародия, но жизнь по доработке на текущий момент существенно облегчает. Учитывая что модульность в принципе не заложена, то это можно считать началом будущей модульности. Во всяком случае я на это сильно рассчитываю....
70. Darklight 32 09.04.19 16:44 Сейчас в теме
(69)У подписок есть два важных положительных отличия:
1. Можно сделать одну подписку сразу на несколько источников, в т.ч. на обобщённые - типа ДокументОбъект - без этого просто невозможно делать универсальные подписчики, которые, скажем, должны срабатывать при записи любого ссылочного объекта (в т.ч. которые появятся в будущем), при необходимости проверяя источник уже в самом обработчке на любые условия.
2. В рамках одной конфингурации можно делать несколько подписчиков на одно событие - когда они не пересекаются друг с другом и относятся к решению разных задач, и могут разрабатываться параллельно разными разработчиками, не мешая друг другу. Заодно можно проверить в одном месте всех подписчиков (особенно в EDT где наконец-то их можно группировать по источникам - хоть и всё-равно через жопу).

Конечно, наиболее важным тут является пункт 1.

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

Добавлять в прямо конфигурацию - это же кошмар - как я написал делить проект на части и по разному размещать его в ИБ - это БРЕД! Особенно если думать о расширениях - именно как о шаге к модульным поставкам решений - когда поставщик поставляет дополнительный функционал к основной конфигурации в самостоятельном расширении. И через него осуществляет обновления.

Даже для внутренней разработки расширения, содержащие именно внутри новые метаданные, могут быть очень полезны - вот, к примеру у меня в группе компаний сотни баз, несколько десятков разных конфигураций, нескольких базовых типовых видов. У меня есть функционал - который мне нужно в них все поставить (на 80% он общий для всех баз), который мне потом нужно будет сопровождать и поддерживать. Что мне проще - заморачиваться с отдельной поставкой конфигурации поставщиком (старый проблемный подход) - или завести расширение в хранилище - и подключить его сразу ко всем базам (и обновлять потом через единое хранилище, а оставшимся 20% различий в функционале управлять через встроенные в расширение функциональные опции на базе встроенных же констант)?

Так что пока расширения выглядят больше как издёвка - но я не буду спорить - даже в таком виде (не ниже 12 релиза совместимости) они могут быть вполне полезны - но только как суррогат - т.к. как по-другому выходит не лучше!
sergathome; +1 Ответить
71. lefthander 09.04.19 17:55 Сейчас в теме
(70)Резюмирую - для основной массы текущих потребителей типовых продуктов 1С функционала расширений вполне хватает. Вполне допускаю что есть проекты которым расширение все равно что припарка, но так это уже и не типовые решения.
76. Darklight 32 10.04.19 09:22 Сейчас в теме
(71)Думаю, что основная масса потребителей расширений как раз таки обходит их стороной. А кто действительно был бы готов активно использовать расширения - недовольны их урезанностью. Впрочем, с 14 релиза платформы, даже с этой урезанностью, "проливая крокодильи слёзы", ограниченно применять расширения можно, всё-равно чередуя их с необходимостью менять основную конфигурацию для отдельных случаев. Вот только режим совместимости платформы 8.3.14 ещё ни у одной типовой конфигурации не стоит - ждёмс....
А про конфигурации на на обычных формах я вообще молчу - они без "танцов в бубном" вообще расширения не поддерживают. И не говорите, что их инсталлировано меньше, чем на управляемом приложении.
sergathome; +1 Ответить
81. lefthander 10.04.19 15:49 Сейчас в теме
(76)Не хочу и не буду с Вами спорить. У нас разный круг решаемых задач. Сказу за себя - ЕРП 2.4.6 вполне доработана под специфику задач, режим совместимости - НЕ ИСПОЛЬЗОВАТЬ и на 12 платформе вполне все работает. Раньше была отключена от конфы поставщика, сейчас практически полностью поставлена на поддержку. ;)
avk72; acanta; +2 Ответить
85. Darklight 32 10.04.19 16:39 Сейчас в теме
(81)Я с Вами и не спорю. При сопровождении ERP 2.4 применять расширения вполне можно и это вполне эффективно (чем без них). Но это капля в море возможностей, где можно было бы применить расширения; и очень скромный ареал программистов, кому они тут интересны (не как эксперимент или мелочная доработка), а как основная стратегия сопровождения типовой конфигурации.
66. kembrik 10 09.04.19 10:30 Сейчас в теме
(62)
А основная предъява такая: О, это у вас не работет, а это работает, но не так. ООП нет (как у некоторых). Т.е. при оценке нового (особенного отечественного) продукта сводиться только к его минусам. Человек толком не разобрался, но уже отвергает. Хотя, при этом, в его старой системе (текущей) таких функций (не платформы, а системы учета) нет, какие он хочет сразу увидеть в новой программе. И его это устраивает.


Про слои в Axapta я читал, открыв рот, году так в 2007, и уже тогда приходил в восторг от имеющихся возможностей у "вражеского лагеря". А в 1С прям открытие сделали, с худшей, чем у конкурентов, реализацией
Darklight; +1 Ответить
68. baracuda 2 09.04.19 14:41 Сейчас в теме
спасибо за статью, узнал много чего нового для себя
72. alexsey777 10.04.19 04:16 Сейчас в теме
Работаю с расширениями немного. Но на практике понял, что на расширениях делать удобно внешние механизмы, работающие с данными. Например, очень удобно делать HTTP и WEB сервисы. Какие-нибудь сервисы обработки данных.
Что-то связанное с хранением данных пока тоже не рискую делать. Хотя в этом направлении наверное тоже идет развитие. Поэтому когда-нибудь мнение свое изменю.
Иногда расширения используем для исправления ошибок при обновлении. Для критических исправлений.
74. ellavs 1022 10.04.19 08:38 Сейчас в теме
(72) кстати да, мы тоже активно используем расширение для HTTP-сервиса, на основную конфигурацию вообще никак не влияет, зато разрабатывать маленькое решение (а именно разбор в git) гораздо удобнее, чем ворошить всю конфигурацию.
73. rpgshnik 3631 10.04.19 07:23 Сейчас в теме
Хорошая публикация. Расширения использую. Фактически самостоятельно пришел к тем же рекомендациям/правилам:
1. Не дробить расширения, где-то слышал сплетни, что несколько расширений - тормозят базу, а одно нет. По этому одно расширение на одну конфигурацию, желательно конечно!
2. Изменять свойства элементов форм программно, согласен.
3. Минимизация использования директивы &Вместо это вообще святое, уже не однократно черпнул горя. Надеюсь директива &ИзменениеИКонтроль поможет в этом, но практика показывает, режим совместимости на типовых конфигурациях очень сильно не успевает за актуальной рабочей версией платформы. Когда она будет? Через год, минимум наверное :)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)
5. Все новые объекты строго в основной конфигурации, удаление расширения явно приведёт к потере данных. Тем более создание новых объектов ни как не повлияет на обновление. А уже обработка их на форме и т.п. строго в расширение. Так же слышал по сплетням, что общие модули так же лучше создавать в основной конфигурации и якобы длительные операции значительно быстрее отрабатывают в основной конфигурации, а не в расширении.
6. Реестры доработок в целом для всего это плюс.
9576836; ids79; kostas; Interrupted; lefthander; ellavs; +6 Ответить
75. ellavs 1022 10.04.19 08:41 Сейчас в теме
(73)
4. Независимые расширения, это наверное правило а не рекомендация. Да и вообще пункта 4 не должно быть, учитывая пункт 1 :)

Вы будете смеяться, но рекомендации разработаны, а подогнать под них уже созданные ранее решения всё никак руки не доходят, поэтому пункт 4 у нас существует в проекте (т.е. есть расширение, которое используют другие расширения, по хорошему либо переносить код в общий модуль в конфигурации, либо объединять расширения в одно).
94. Angry 11 12.04.19 12:39 Сейчас в теме
(73)
несколько расширений - тормозят базу, а одно нет

Расскажите: откуда информация? Замеров нигде не видел, на глаз разницы не увидел (версия 8.3.7 и ниже не в счет). Лично общался с разработчиками функционала расширений, уверяли, что на производительность работы количество расширений не влияет и у них это контролируется.

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

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

Отсюда с тем что для 1 базы использовать одно расширение - не соглашусь. Если в базе много доработок, разного времени и разного назначения, то под каждую задачу нужно отдельное расширение. Естественно, пересекающиеся задачи, которые используют одни объекты (например несколько раз доработали форму заказа, под разные хотелки) - по сути 1 задача и расширение одно. К этому пришел после неоднократных, не очень удачных обновлений, когда 1С переработают конфигурацию на столько, что не работает почти ни чего. Когда расширение одно - оно отвалилось и пока весь функционал не пройдем, в продакшине ни чего не работает. А на это не всегда есть время, лучше все же если обновление поджимает - его сделать и функционал доработок запустить по очереди в порядке приоритета. Бывают же функции которые раз в квартал используют, а из-за этого мы не можем первичку оперативную печатать - не хорошо.
77. tolstyak_2000 10.04.19 10:37 Сейчас в теме
"В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль"

Ошибка номера платформы - поправьте.
78. ellavs 1022 10.04.19 11:19 Сейчас в теме
(77) уточните где, что-то никак не найду, где написала не 8.3.15...
87. tolstyak_2000 10.04.19 18:11 Сейчас в теме
(78)

В тексте статьи есть фраза: "В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль"
88. tolstyak_2000 10.04.19 18:15 Сейчас в теме
(78)

Сейчас последняя платформа 8.3.14
89. ellavs 1022 10.04.19 20:07 Сейчас в теме
(88)
8.3.14

В 8.3.14 этой аннотации еще нет. Только в 8.3.15.
79. 77dream77 421 10.04.19 12:59 Сейчас в теме
использую расширения на проектах давно (более 2 лет), даже читал курсы по ним 😊
Из последнего проекта перехода с КА 1.1 на КА 2.4 - там все изменения сделаны через расширения (41 расширение), в конфигурации только новые объекты/реквизиты и одно изменение кода из-за нежелательности применения расширения в данном случае. Было 3 обновления с начала года - никаких проблем
много расширений настраивал для типовых ЗУП, БП, Итилиума, КА, ДО
Много расширений приходится переделывать после других, если неправильно настроены – то они валятся после очередного обновления.
при правильной настройке расширения - очень удобный и стабильный механизм, нужно просто понимать что можно делать через расширение, а что нет

к статье я бы добавил следующее:
1. полностью согласен, для одного объекта/формы отдельное расширение.
одно расширение опасно тем, что при ошибке подключения теряется весь функционал, который заложен в нем
а при отдельных расширениях только небольшая часть отключается и его можно будет легко поправить
2. да, лучше делать программные изменения
но новые элементы формы я обычно добавляю на форму в редакторе. Для них обязательно использую префиксы, новые группы с префиксами и никогда не изменяю типовые реквизиты на форме, только программно
проблем пока не было
3. согласен, аннотация Вместо - это крайний случай и часто бывают проблемы с расширением после обновления, но есть и плюсы…
Последний раз ее применял для доработки печати ТТН и УПД.
Вместо вызывает типовую процедуру получения данных, которая возвращает результат запроса
Этот результат выгружается в ТЗ, обрабатывается, добавляются новые колонки с данными при необходимости и помещаются обратно в результат.
Таким образом при изменении типовой процедуры ничего не сломается даже при изменении запроса или колонок результата, а дальше в коде я ориентируюсь на свои добавленные колонки, которые тоже останутся и не мешают работе типовой.

4. согласен, но если функционал как-то пересекается, то можно общий функционал вынести в отдельный общий модуль конфигурации, например.
Здесь все зависит от решаемой задачи.
5. да, я пока тоже не доверяю хранение важных данных расширению, добавляю новые объекты в конфигурацию.
6. отдельного реестра не веду, все описание в комментариях в расширении или в отдельном макете.
Но для удобства анализа версии расширений – использую реквизит Версия, в него записываю последнюю дату редактирования расширения, например, 10.04.2019
Таким образом при большом количестве расширений очень удобно понимать в какой базе какая версия и переносить изменения, например, из копии в рабочую. Присваивать просто номер версии типа 1.1 неудобно, потому что не известно какая версия последняя, а с датой всегда понятно.

Также после окончательной готовности расширения удаляю все не используемые реквизиты/объекты, отключаю все не нужные для меня зависимости и контроли, добиваюсь, чтобы проверка конфигурации расширения не выдавала ошибок.
Таким образом в расширении остается только измененные и важные для расширения объекты с отключенными контролями и т.п.
При обновление обязательно проверяю все расширения на применимость и еще раз запускаю проверку конфигурации, если она выдает ошибку – ищу причину и устраняю. Таким образом после обновления можно быт спокойным, что на следующий день рабочая будет стабильна и тебя не засыпят ошибками пользователи.
Из недавнего – в КА 2.4 изменилось название документов с ПоступлениеТоваров на Поступление товаровНаСклад, а оно использовалось в двух расширениях в проверке типа и в запросе. Проверка конфигурации естественно выдало эту ошибку, и я ее исправил сразу после обновления до наката на рабочую. Если бы не делал такую проверку, то на следующий день два важных функционала отвалилось бы с ошибкой и утро началось бы не с кофе…
VyacheslavShilov; mvxyz; bazelyukandrei; Angealtor; AllexSoft; o.nikolaev; Krio2; worker1c; ellavs; +9 Ответить
80. ellavs 1022 10.04.19 13:40 Сейчас в теме
(79) да, тоже вместо версии пишем дату (и время, если изменений было несколько в течении дня), и это не только в расширениях, но и отчетах и обработках.
AllexSoft; o.nikolaev; +2 Ответить
82. lefthander 10.04.19 15:52 Сейчас в теме
(80)Я в расширениях для БП писал версию такую же как и БП.
Оставьте свое сообщение