Начиная разрабатывать расширения, не сразу задумываешься о том, а что с ними будет дальше. Вернее задумываешься, но не все последствия получается предугадать. И лишь основываясь на уже двухгодичном опыте разработки расширений, в частности для типовой отраслевой конфигурации, понимаешь, что уже лучше бы не делать, а что стоит заранее предусмотреть, чтобы в дальнейшем расширение не стало обузой для разработчика, вместо облегчения работы.
Мы сделали выводы из своих ошибок и в итоге появился ряд рекомендаций, которыми руководствуемся при разработке расширений:
- Не дробить расширения для одного и того же объекта конфигурации
- Изменения расширяемых форм делать программно, а не через редактор форм
- Минимизировать использование аннотации &Вместо (&ИзменениеИКонтроль?)
- Делать независимые друг от друга расширения
- Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию
- Вести реестр расширений
Рассмотрим подробнее каждый пункт
1. Не дробить расширения для одного и того же объекта конфигурации.
Если изменения касаются, например, одной формы, то мы делаем одно расширение, а не несколько. Если в последствии появляются еще задачи на изменение этой же формы, мы дополняем существующее расширение, вместо создания нового. Особенно, если логика в расширениях зависимая друг от друга. Поменять последовательность исполнения расширений не самая тривиальная задача. Как говорят разработчики: расширения исполняются в последовательности их добавления в конфигурацию и поменять их местами можно только через удаление/добавление (а если расширения содержали хранимые данные, то сделать это может стать невозможно).
Как вариант, можно объединять расширения по функциональности, а не только по определенным объектам, хотя здесь может возникнуть "конфликт объединений" и решить, каким образом лучше объединять, возможно, стоит в самом начале доработок. Например, нужно добавить определенный (схожий) функционал к нескольким объектам, что лучше: добавлять его в каждое расширение, относящееся к определенному объекту, или же сделать одно расширение, но зато придется сослаться на эти объекты в этом одном расширении? Вопрос на самом деле довольно сложный и порой заставляет отступить от принципа "один объект — одно расширение", ради объединение функционала в одном месте.
2. Изменения расширяемых форм делать программно.
Функция "Обновить расширение формы": не стоит всегда надеяться на этот автоматический механизм, так как иногда он может не сработать и будет нестерпимо больно от того, что нужно переделывать всё с нуля.
Давайте возьмем самый банальный пример: сделать определенное поле на форме нередактируемым, т.е. установить ему свойство "ТолькоПросмотр".
Видела много примеров в сети, в том числе на Инфостарт, где предлагалось решить такую простую задачу через редактор форм. Т.е. выбрать элемент нужного поля в редакторе и в свойствах установить "галочку" только просмотр…
Действительно, не надо так! Давайте представим, что таких элементов на форме не один, а, допустим, пятнадцать, плюс Вы еще добавили несколько новых элементов, кнопок и групп, а также перераспределили часть элементов по группам. Делать это в редакторе форм в первый раз действительно удобно. Пощелкали нужные галки, поменяли некоторые свойства элементов, и вот быстрый результат!
А вдруг случается страшное ("Всё пропало, шеф!"): после очередного релиза автообновление формы не срабатывает (часть элементов с формы вообще исчезает, а новые не появляются, как было в нашем случае пару раз) и Вам нужно повторить установку всех этих галок и свойств, воссоздавая расширение с нуля (а Вы еще к тому же забыли записать, с какими элементами, что делали, и было это полгода назад…). (Например, у нас в типовой конфигурации есть такая сложная форма, расширение которой приходится переделывать при каждом обновлении)
Тогда первичная простота во второй раз может превратиться в затратную по времени процедуру и, возможно, это будет повторяться неоднократно.
Ну и самый плачевный случай — делали это может быть вообще не Вы, а тот, кто делал уже давно уволился. Тогда рекомендуется переделать расширение так, чтобы потом не было каждый раз мучительно больно при обновлении.
Так что же делать? Всё просто! Любые изменения, связанные с элементами формы делайте программно, вообще старайтесь не трогать редактор форм, как бы соблазнительно это не было. Либо альтернативный вариант решения: к каждому расширению прикладывать подробное описание: что и с каким элементом Вы сделали, какое свойство поменяли, какой элемент добавили и т.п.
Не рекомендуется делать так:
Рекомендуется: добавить процедуру с аннотацией &После для события формы "ПриОткрытии" примерно с таким кодом:
&НаКлиенте
Процедура АТБ_ПриОткрытииПосле(Отказ)
Элементы.Ответственный.ТолькоПросмотр = Истина;
// и все другие изменения элементов формы
КонецПроцедуры
В этом случае, если Вам придется воспроизводить расширение с нуля, достаточно будет просто перенести данный код в воспроизводимое расширение и всё.
В случае затруднений при программном изменении элементов форм можно воспользоваться бесплатным инструментарием декомпиляции формы, который публиковался здесь на Инфорстарте Евгенией Карук — Генерация кода управляемой формы (т.е. сначала делаем форму в редакторе, указанным инструментом декомпилируем ее и смотрим, как делаются элементы формы программно).
В каком случае можно смело отступить от этой рекомендации? Когда Ваше расширение является временным исправлением ошибки, которую разработчики поправят в следующем релизе типовой конфигурации.
3. Минимизировать использование аннотации &Вместо.
Старайтесь при любой возможности избегать использования аннотации &Вместо. Если логика позволяет, используем &Перед или &После.
Главная цель в этом случае — избежать проблем при изменении кода исходной процедуры в типовой конфигурации (ведь аннотацией &Вместо мы перехватываем исполнение процедуры полностью на расширение, заменяя исходную).
Однако бывают ситуации, когда нужно поменять несколько строк кода именно внутри процедуры и никак аннотациями &Перед и &После сделать этого не получается.
Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль, в какой-то степени она решит многие проблемы, связанные с тем, что Вам нужно подправить лишь пару строк в заимствованной функции/процедуре модуля, но Вы не хотели бы перехватывать его полностью, с риском в дальнейшем постоянно отслеживать изменения данного модуля (хотя даже при использовании &ИзменениеИКонтроль риски остаются).
Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)
Например, раньше (т.е. сейчас, пока не обновили платформу) нам приходилось писать так:
Пример с &Вместо
Теперь можно написать так.
Пример с &ИзменениеИКонтроль
При этом в дальнейшем платформа сама отследит изменения кода расширяемой процедуры и оповестит в случае его изменения, что позволит Вам проанализировать свои дополнения.
4. Делать независимые друг от друга расширения.
Можно ли из одного расширения вызвать функцию в другом расширении? Можно, но может не нужно?
Ведь действительно удобно: сделать одно расширение с некоторым набором общих процедур и функций, которые можно использовать во всех остальных расширениях.
Скажу честно, мы так сделали, и оно действительно работает, работает не плохо, но…
Есть риск "зависимости". Что-то измените в таком шаред-расширении и могут "полететь" все остальные… Но если Вы держите это под своим контролем, то в принципе использовать такой механизм вполне возможно.
5. Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию.
Разработчики 1С сделали многое, чтобы сделать хранение данных в объектах, добавленных в расширении, более безопасным. Но мы пока не рискуем с данными, имеющими критическую важность. Т.е. новые справочники, документы и регистры стараемся добавлять в основную конфигурацию, т.к. они не сильно мешают дальнейшему обновлению типовой конфигурации.
Можно вынести в хранение в расширении, например настроек, логов — т.е. того, что при случае не сильно жалко потерять.
Вообще вести документирование по любому изменению, связанному с типовой конфигурацией — это обязательно (иначе каждое обновление будет превращаться в головную боль).
Рекомендуется также и ведение реестра всех созданных расширений с описанием функционального назначения расширения, а также перечислением процедур и функций, которые оно заимствует из конфигурации, особенно следует выделять те, что используются с аннотацией &Вместо, т.к. на них нужно будет обращаться особое внимание при обновлении.
В нашем случае ведем реестр в общей записной книге OneNote. Пример фрагмента таблицы такого реестра (в некоторых названиях добавлены пробелы, т.к. иначе таблица здесь не поместится в ширину страницы):
Пример фрагмента таблицы реестра расширений
На каждом элементе есть ссылка на другую OneNote-страницу с ТЗ (с полным описанием задачи, для чего делалось расширение, какие доработки в него вносились со временем, а также ссылка на GIT-хранилище).
Естественно, каждый сам для себя решает, в каком виде ему удобнее представлять такие сведения, главное, чтобы потом их смогли понять не только Вы, но и те, кто будет после Вас.
В итоге немного о том "Почему именно расширения?":
1) Отвечая на вопрос: "Зачем столько мучений, ведь можно просто внести изменения в конфигурацию?" — зачастую это безвыходная ситуация, когда Вам запретили изменять типовую конфигурацию, а что-то добавить очень хочется.
2) Легко распространять. Если Вы что-то изменили в конфигурации, сразу появляется проблема передачи этого изменения клиенту (отправлять целую конфигурацию для дальнейшего сравнения и объединения не всегда удобно, можно конечно сделать через выгрузку файлов и частичную их загрузку, но тоже не самый простой (для клиента) путь), а вот передача клиенту легких в установке расширений для типовых конфигураций, не требующих от пользователя изменения конфигурации, может стать выходом (но есть, конечно, риски при обновлении).
3) Удобство при работе с Git (см. Git-репозитории при небольших проектах)
В конце хотелось бы задать вопрос сообществу: Используете ли Вы расширения в своей работе?
1) Если да, то с какими трудностями Вы сталкивались (а может не сталкивались)?
2) Если не используете, то почему?
Другие статьи на эту тему:
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Это совет для какой платформы 1С?
8.3.13 кажется всё хорошо с этим. К тому же, должны быть бэкапы, если переживаете за сохранность данных.
Второй момент, получится ли обновить конфигурацию снятую с поддержки с возможностью изменений — скриптом, когда баз много?
Чтобы не программист 1с нажимал кнопки?
0. Не использовать расширения, так как это кривой механизм, который работает неизвестно как
(2)
Да бросьте уже нагнетать обстановку, ну или примеры кривизны в студию. Я, признаться, побаиваюсь еще добавлять данные в расширения, но что касается кода, особых претензий к механизму нет.
По поводу документирования. В расширения можно добавить объект, хранящий историю изменений и документацию.Например, в виде макета.
Это не исключает копирование этой информации в отдельное место, но позволяет при работе с расширением сразу же получать нужную информацию. Я такое использую во внешних обработках и отчетах, добавляя текстовый макет История.
Для сложных случаев там же храню описание задачи (ТЗ), которая решалась в данной разработке
Все по делу. Жаль только конструкцию &Вместо все-таки приходится использовать 🙁
По п.5 можно ещё максимально продумать структуру дополнительных данных — может можно обойтись дополнительными и реквизитами и сведениями? Хранение их так же безопасно и не требует снятия конфигурации с поддержки.
(2) Может вы просто не умеете их готовить? С переходом на расширения я уже и забыл, когда снимал с поддержки типовые конфигурации. Много чего снятого с поддержки поставил обратно на поддержку, перенеся доработки в расширение. Полет нормальный 🙂
Главная проблема расширений — это режим совместимости в типовых. В Документообороте, например, 8.3.8 🙁
(4) Хорошая идея, спасибо.
(5)
Новая аннотация &ИзменениеИКонтроль частично должна решить этот вопрос…
(7) Да, есть такое. Очень хочется использовать новшества платформы в области расширений, а не получается (
(1) да, разработчики сделали многое в направлении безопасного хранения данных в расширениях, у нас пока побаиваются, поэтому в нашем случае — всё хранение только в конфигурации. Я честно предлагала попробовать, но руководство отказывается.
(3)
Пример 1:
Пример 2:
Добавьте к этому необходимость создавать отдельные хранилища конфигурации для каждого расширения и авторизоваться в каждом из них отдельно. Проблем ещё много, можно на форумах ещё найти, особенно для нечётных релизов 8.3.11, 8.3.13 на которых обкатываются нововведения, прежде чем перевести типовые на чётные релизы.
Расширения хороши до тех пор, пока код, форма или объект метаданных, который они меняют, в действительности не меняется или почти не меняется в новой версии конфигурации поставщика. Так как при небольших модификациях типовых это основной случай расширения и получили такое большое распространение.
Но когда модификации типовой конфигурации действительно требуют адаптации под новый релиз конфигурации поставщика, расширения перестают выполнять свою функцию «упрощения обновления» и только скрывают от глаз проблему, которую должен решить релиз-инженер. О ней узнают по факту накатки обновления или от пользователей.
Совет из этой публикации менять формы только программно — из той же области.
P.S.: Для Бухгалтерий и ЗУП-ов расширения хороши. Постоянная надёжность конфигурации не нужна, на исправление багов времени всегда достаточно. Ценность замочка на объектах метаданных высока по психологическим причинам )) Почему бы и нет )) Проблема только в том, что набив руку на нетребовательных к надёжности конфигурациях специалисты потом эти приёмы переносят на конфигурации, требующие больших модификаций и высокой надёжности, в том числе отсутствия косяков сразу после операции обновления, а не через неделю после вала сообщений от пользователей.
(7) Главная проблема — это отсутствие трехстороннего сравнения/объединения и сокрытие от релиз-инженера информации о том, что наши алгоритмы требуют адаптации к новому релизу типовой конфигурации. Возможность завершить объединение не зная о том, что надо изменить наши алгоритмы.
(13) как вариант новая аннотация &ИзменениеИКонтроль частично может помочь (естественно, если есть возможность использовать платформу 8.3.15). Там автоматически происходит проверка на изменение кода заимствованных модулей и оповещение, если произошли изменения.
(14) Да, это поможет выявить проблему. Но:
1) Система сообщит «ваш метод требует адаптации», но что именно адаптировать нам придётся узнавать самим. Трехстороннее сравнение/объединение придётся организовывать самим, например выгружая все версии кода в файл и применяя внешние инструменты или делая попарное сравнение файлов в 1С. Кто будет с этим заморачиваться? Скорее глазами по тексту пробегать будут, что повышает риск ошибки. На небольших примерах в «Зазеркалье» всё выглядит красиво. А если метод на 300-500 строк и код разделён большими блоками запросов? Так часто бывает в типовых.
2) &ИзменениеИКонтроль появится в 8.3.15. А значит для того же семейства конфигураций ERP/КА/УТ станет доступно только в 8.3.16 где-то через год. На «пробную» нечетную платформу их переводить не будут. Ждать ещё долго. А расширения массово лепятся как снежки уже сейчас, без всяких аннотаций &ИзменениеИКонтроль.
Не говоря уже о ставших популярными шутках на счёт необходимости применять беспощадные аннотации &КонецУдалить и &КонецВставить совместно с &ИзменениеИКонтроль ))
(0) хорошая статья.
Иногда вижу применение расширений необдуманно на столько, что они напоминают оператор GOTO.
Но сам механизм хороший, если разумно подходить.
(15) тут соглашусь. Как в том анекдоте про пожарных. Как обновление, так хоть увольняйся )) приходится брать из реестра все блоки модулей, помеченные как наследуемые &Вместо, и ручками каждый проверять. Хорошо хоть в конфигурации, с которой чаще всего работаю, подняли совместимость до 8.3.12. Так и до 8.3.15 недалеко, может &ИзменениеИКонтроль хоть немного облегчит труд.
(16) Спасибо. Сложно всё обдумать наперед. Столько на грабли наступили уже, пока более-менее пришло какое-то понимание.
(6) Или готовить не умеем, или у вас изменения мелкие. У меня сейчас проект по ЕРП. От расширений отказались, проблем много было. Хотя изменений типовой конфы не так много — десяток документов, десяток справочников, пара десятков общих модулей…
Поделитесь опытом кто как борется с такой проблемой — в конструкторе запросов в расширении не доступны системные ревизиты добавленных в расширение справочников — например «Владелец» или «родитель».
Сам ставлю времмено реквизит «ссылка», потом меняю руками в тексте модуля.
(19) Можно озвучить проблемы с которыми столкнулись при использовании расширений? интересны именно проблемы (причины отказы от расширений). У нас в расширения вынесены следующие контуры (меркурий,егаис,онлайн-кассы и много чего еще)
В статье по большому счету о проблемах ни слова. А проблемы действительно есть, хотя и многие из них решаются.
Самая большая их них — расширения ничего не знают о типах расширяемой конфигурации (как впрочем и о других расширениях), как следствие невозможно в расширениях использовать тип «ЛюбаяСсылка» (так же как и типы других расширений).
Другими словами невозможно использовать «критерии отбора» т.е. структуру подчиненности через стандартных механизм критериев отбора уже не получить,
как вариант можно использовать
Другая не менее важная проблема это невозможность использовать в расширениях механизм доп.атрибутов, точнее невозможно использование объектов расширения (все так же из-за типизации)
Есть в расширениях замечательная опция «Активно», вот только отключить ее не всегда есть возможность, точнее отключить то ее можно, но вот если есть заимствованный регистр накопления и добавленный новый документ который участвует в движении по этому регистру то увы и ах провести документ не удастся ибо выйдет вот такая шибка:
Работа с таблицей невозможна. Структура таблицы несовместима с текущими расширениями конфигурации.
(20) честно говоря, даже не задумывалась об этом, т.к. не пользовалась конструктором в расширениях…
Статья хорошая.
Из неудобств можно отметить работу с СКД и прочие запросы, но выход простой писать запрос либо в обработке, либо другим способом.
Раньше много было косяков в конфигурациях 8.3.8 например, отладку надо было с ключем «РежимОтладки» запускать, но сейчас с этим все хорошо.
Из последних Косяков, при переходе на платформу 8.3.12.1469 напарывался на описанное в данной теме
Из реальных косяков с расширениями мы столкнулись только в РИБ, когда расширение распространившись в базы фактически обрушило их работу. Это было крайне неприятно, хорошо что изменения уехали в ночь и хватились утром, успели все исправить до наплыва покупателей.
(3) Ну вот, данные не добавляете, а просите примеров. Лезем на партнерский форум, либо на багбоард, и смотрим ошибки по расширениям.
Понятно, что для простых изменений (форму подправить и т.п.), все нормально работает, а вот что-то сложное, ну такое.
У нас одно расширение, и плодить не хочется. Как писали выше уже и забыли когда конфигурацию трогали…Более 100 новых объектов методанных, с данными проблем нет. Была недавно забавная проблема, сняли совместимость, добавили в расширение план обмена и изменили состав типового.Но потом пришлось откатить совместимость, из расширения удалили изменения по планам обмена, но оно все равно ругалась что такие объекты есть.Решили какими то танцами.
(6) Возможно, но какие доработки у вас перешли в расширения? Добавьте справочник, регистр, а потом с радостью узнайте что при обновлении потеряются данные.
При обновлении доработанных конфигураций у меня тоже проблем не наблюдается, движения делаются по подпискам, формы меняются программно через переопределяемые модули, отчеты/обработки через механизмы БСП.
(20)
!!!Для этого нужно захватить форму списка.!!!
А теперь вопрос! ДЛЯ ЗАЧЕМ??!?!?! Если Я и так уже справочник захватил и его родителя или владельца!
А ещё, захватив форму списка, тянем за собой в расширение все реквизиты и все связанные с ними перечисления, справочники, документы из основной конфигурации. Оно нам надо?
По моему расширения годны пока только для модификации или замены чистого кода, не более.
Были косяки на первых расширениях, Доработки в ДО. более 150 пользователей онлайн.
1. в локальной сети всё работало стабильно
2. Тонкий клиент и web с удаленными пользователями происходили ошибки из серии «Ошибка разбора XML» при открытии формы с расширением. Ошибки происходили нерегулярно. раз-два в день. у некоторых пользователей.
в итоге, пока побаиваюсь работать с расширением когда пользователей более 100 пользователей и не все работают в одной локальной сети
Спасибо, хорошая статья.
«Из этой ситуации теперь есть выход. В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль,»
Не знал об этом.
(1) А пробовали запросы например писать из основной конфы к реквизиту расширения, или код какой? или внешний отчет/обработку? Мне показалось крайне неудобно, может какой то фокус есть с настройкой? пока вижу новые объекты только для полностью независимого от основной конфы расширения.
(1)
Чтобы не программист 1с нажимал кнопки?
Поставка конфигурации: создаем файл обновления и вперед скриптом… точно так же, как и типовые обновления. Только один нюанс — на рабочей базе конфигурация получается без возможности изменения.
Второй вариант — обновление из хранилища.Но обновлять из хранилища рабочие базы… Ну это если один разработчик держит все эти базы 🙂
З.Ы. не все комменты внимательно прочитал, но при беглом просмотре не увидел ответа на данный вопрос 🙂
(32) На рабочей базе без возможности изменения? А если придет другой разработчик, он сможет включить возможность и выполнить доработки?
(28) Да, спасибо за совет. действительно после захвата формы списка справочника в конструкторе запроса появляется родитель.
Я не сохраняю захваченные для построения запросов объекты в расширении ))) не переживайте.
(30)
(7)Режим совместимости можно повышать вручную (не дожидаюсь когда он повысится вендором конфигурации):
1. Обычно это не вызывает больших проблем — всё быстро можно урегулировать
2. Но возникают некоторые дополнительные сложности при установке апдейт-обновлений — но, обычно, тоже нет больших сложностей
3. Главное при апдейте обновления от вендора не забыть о том, что режим совместимости надо поправить снова (у корня конфигурации)
4. Ну, и сначала надо на копии тестировать — выявить косяки, поправить и переходить потом к рабой базе (бэкап обязателен)
Мы так повышали уровень совместимости и для документооборота и даже для УПП — где без повышения уровня совместимости, например, расширения вообще не будут доступны. Ничего страшного в этом нет — но проблемы всё-равно решать придётся.
(35)15-релиз пока ещё не вышел даже для ознакомоления
(38)Знаю.
В статье упоминается особенность 8.3.15.
Пример использования директивы &ИзменениеИКонтроль (только с версии платформы 8.3.15)
(39)Я знаю, что Вы знаете. Но большинство не знает — т.к. данного релиза ещё нет в «свободном» доступе. От того и такие удивления.
Разрабатываем и тестируем типовые конфигурации.
Расширения очень сильно помогают.
Иногда надо поле своё на форму добавить.
Иногда колонку вывести в форме списка.
Очень сильно выручают.
Поддерживаю.
(12)
Откуда инфа? Сторонник теории заговора релизов или офф. источник?
(20)Я необходимый реквизит просто добавляю в объект. Потом можно будет его удалить из расширения.
(24) Не могли бы Вы подробнее сказать, что именно сломало расширение в РИБ? Мы сейчас планируем создавать расширения, распространяемые по РИБ и хотелось бы избежать проблемы как у Вас.
(44)
Сломало полностью все, начиная от механизма обмена, заканчивая нормальной работой распределенных баз. Практически на любое действие: Ошибка исключительной блокировки информационной базы. При том, что в самом расширении ничего такого не было. Расширили табличную часть Товары документа Поступление, добавив туда две колонки Дата изготовления и Срок годности (дата и число) и добавили обработку выгрузки на весы CAS для работы с бесплатным драйвером. Причем все это давно уже работало, но для нового клиента решили не трогать конфигурацию и вынести в расширение. Вынесли…
Самое гадкое в этом то, что расширение сломало типовой механизм обмена и «починить» базы РИБ просто удалив расширение из центрального узла не получится. Нам пришлось отвязывать базы от центрального узла, удалять в них расширение руками и привязывать заново. Хорошо что заметили это рано утром и магазинов было всего три.
Конфигурация: Розница 2.2.1.24, платформа 8.3.13.1690
(46) то есть главная особенность Вашего расширения — добавление данных (а не только изменение текущих)? Мы пока не планируем добавлять что-то новое в расширение, а в первую очередь только для оперативных патчей (очень много баз и цикл обновления довольно тяжелый из-за выгоняния пользователей).
Ну попробуйте, только перед продакшеном обязательно потренируйтесь на кошках, чтобы не было потом мучительно больно.
Месяц назад впервые сделал расширение для УТ11. История такая, где то пару лет назад делал клиентам доработку УТ11 для работы с кассовой программой Frontol. Часть функционала касающееся маркетинга получилось сделать при помощи дополнительной внешней обработки, а часть функционала касающегося получения данных с кассы пришлось допиливать конфигурацию.
Тогда чесались руки это сделать в виде расширения, но были отзывы, что этот механизм пока сырой и не хотелось пускать под это своих клиентов. А тут недавно УТ глобально обновилось и Библиотека подключаемого оборудования поменялась кардинально. Обрадовался, что теперь наконец то можно будет поработать с расширениями. Я в восторге.
Стоило еще упомянуть о свойстве расширения «Назначение расширения конфигурации» , так как правильное его использование позволяет правильно идентифицировать для чего предназначено расширение , плюс есть особенности с порядком выполнения расширения в зависимости от указанного значения в данном свойстве.
По первому пункту, как говорится, есть нюансы.
Очередностью расширений прекрасно можно управлять (Утверждение справедливо для платформы 8.3.13.1644 и режиму совместимости Версия 8.3.12)
Для этого открываем свойство расширения и меняем назначение расширения конфигурации. Сначала выполняется Исправление, потом Адаптация а потом Дополнение
С its.1c.ru
● Исправление ‑ такое расширение предназначено для исправления ошибок в прикладном решении. В таких расширениях предполагается использование потенциально «опасных» возможностей расширений, например, применение расширения метода с помощью аннотации Вместо. Исправления предназначено для определенной версии прикладного решения. При выходе следующей версии этого решения автор расширения должен проводить анализ применимости созданных расширений в новой версии. Допускается наличие нескольких расширений с таким назначением, но необходимо обеспечить отсутствие конфликтов между такими расширениями, например, несколько таких расширений не должны расширять один и тот же метод с разными целями. Такие расширения могут не учитывать наличия расширений другого назначения.
● Адаптация ‑ такое расширение предназначено для адаптации прикладного решения под условия конкретного клиента. В таких расширениях рекомендуется не использовать потенциально «опасных» возможностей, т. е. тех возможностей, которые могут привести к конфликту расширений при их совместной работе или которые зависят от порядка подключения расширений. Тем не менее, допускается аккуратное использование «опасных» возможностей, при условии, что автор расширения берет на себя полную ответственность за обеспечение корректного функционирования результирующей конфигурации в новых версиях прикладных решений, и с учетом расширений, имеющих назначение Исправление. Предполагается, что в каждый момент времени в информационной базе существует минимальное количество таких расширений. Если в одно расширение невозможно включить весь набор изменений, то рекомендуется расширения с назначением Адаптация разбивать по максимально крупным блокам расширяемого прикладного решения.
● Дополнение ‑ такое расширение предназначено для реализации новых возможностей прикладных решений, которые минимально привязаны к конкретной версии прикладного решения. Примером такого расширения может служить создание нового набора отчетов, который отсутствует в расширяемом прикладном решении. Предполагается, что такие расширения должны корректно работать в случае обновления расширяемого прикладного решения. При этом расширение с назначением Дополнение не должно учитывать в своей работе возможное наличие расширений с другим назначением. Предполагается, что таких расширений может быть произвольное количество.
И вот еще был вопрос по взаимодействию расширений в зависимости от назначения расширения
(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.
(45)Тоже использую в работе. На закрытых конфигурациях небольшие доработки кода.
Из проблем
1. Сам столкнулся когда изменилась форма документа и перестала нормально работать. Обновил в расширении и потерял то что добавлял… Вот тогда на собственном опыте дошел что надо программно добавлять элементы в форму расширения. Пришлось переписать процедуры для большей структурности добавления, и в последующем уже именно туда вписывал необходимые элементы для модификации. Благо таких форм не так много.
3. Просто в расширение заимствую необходимые реквизиты, потом их можно удалить или не обращать внимания…
4 Наследованные в таком случае всегда видны, а вот с оператором &Вместо — это действительно скоро будет засада, ну когда их будет много. Тоже стараюсь их избегать, но не всегда это возможно.
(52)Самое смешное что все выше описанное не обязательно, кроме порядка исполнения. А какой порядок будет у 6 исправлений? или трех адаптаций?
Так что предпочитаю если есть возможность все делать в одном расширении определенного типа.
(53) Ясно, тогда это всего лишь стечение обстоятельств и некий «пук», услышанный на сарафанном радио/ОБС.
(43) с родителем и владельцем такое не прокатывает
(56) При отсутствии официальной информации нужно полагаться на наблюдения и практику и находить чёткие закономерности. Потом можно к удивлению обнаружить подтверждение того, что это не просто наблюдение, а «политика партии», где-нибудь на партнерском форуме или в презентациях 1С ))
(45)
Да, у меня тоже что-то не особо хорошо это выходит, поэтому предпочитаю работать с ними через git.
(37)
хорошее предложение, но не всегда можно применять. Например, некоторые расширения у нас носят «сезонный» характер (например, используются только летом) и периодически «вырезать» их из одного большого расширения было бы не очень удобно.
Просто это один из моих любимых программных продуктов, поэтому не смогла удержаться и не упомянуть его 😉
По остальным пунктам во многом соглашусь.
(52) да, если всего три расширения, то можно им назначить разные назначения и регулировать последовательность, при большем количестве — это уже сложно регулировать.
Вообще все вот эти возмущения по поводу расширений, это такие же предъявы к 1С со стороны классических программерах / пользователей, работавших в похожих системах учета. А основная предъява такая: О, это у вас не работет, а это работает, но не так. ООП нет (как у некоторых). Т.е. при оценке нового (особенного отечественного) продукта сводиться только к его минусам. Человек толком не разобрался, но уже отвергает. Хотя, при этом, в его старой системе (текущей) таких функций (не платформы, а системы учета) нет, какие он хочет сразу увидеть в новой программе. И его это устраивает. Ну это же SAP (или как его там). Надо вызывать этаж аналитиков и 2 этажа программистов, чтобы пару полей и кнопку на форму добавить и отвалить кучу бабла.
ЛИЦИМЕРы.
А вот, что касается расширений, то использовать их можно и нужно. Здесь, да и в других делах, главное без фанатизма. + 100 к карме)
(60)хорошее предложение, но не всегда можно применять. Например, некоторые расширения у нас носят «сезонный» характер (например, используются только летом) и периодически «вырезать» их из одного большого расширения было бы не очень удобно.
а. Как я написал — при ОЧЕНЬ БОЛЬШОЙ и ОБОСНОВАННОЙ ПОТРЕБНОСТИ — можно иметь 2 ну максимум 3 консолидированных расширения, реально мало связанных друг с другом (или одно общее-основное — и несколько дополняющих). Но это скорее исключение — когда это реально удобнее, чем всё в одномю
б. Для Вашего же примера — идеально подходя, как раз таки, опции настройки — которыми Вы будете включать/выключать функционал в ИБ по потребности (если его реально нужно выключать, т.е. он будет мешать не в своё время).
Для опций — просто заводите регистр сведений (лучше не периодический) и ПВХ (будут едины для всех расширений; константы расширения пока не поддерживают). И коде, через модуль повторного использования получаете и проверяете эти опции — и выбираете использовать или не использовать те или иные алгоритмы; отображать или нет те или иные элементы формы.
При желании — подключаете к этим регистрам — функциональные опции (но их расширения пока тоже не поддерживают — поэтому их придётся добавлять в основу. конфигурацию) — но я не вижу большой потребности в их использовании.
По поводу «OneNote»
Мне кажется настоящий разработчик на 1С в короткие сроки сделает куда более удобный инструмент документирования, чем «OneNote». Особенно, если уже возьмёт за основу какую-нибудь готовую конфигурации класса ITIL или класса ITSM, с поддержкой работы через WEB.
А потом ещё и с GIT её интегрирует или с другими WEB-ориентированными специализированными продуктами.
Но это просто моё мнение 😉
(45)
.
Насколько мне известно с 12 релиза (или чуть позже, не помню точно) эта проблема частично решилась. То есть, теперь если в исходной процедуре после обновления появится новый аргумент (со значением по умолчанию) — то это не вызовет ошибки в расширении. Главное, чтобы не в середину вклеили новый аргумент — а то логика может нарушиться.
(62)
Про слои в Axapta я читал, открыв рот, году так в 2007, и уже тогда приходил в восторг от имеющихся возможностей у «вражеского лагеря». А в 1С прям открытие сделали, с худшей, чем у конкурентов, реализацией
(65) Вот. Адекватная критика (не меня… расширений). Если бы разработчики 1С (те самые на С) сразу сделали все хорошо, то ни у нас ни у них работы бы не осталось. С другой стороны: есть идея. Для ее воплощения нужно много ресурсов (времени, деньги и т.д.). Но можно сделать более менее рабочий вариант. Да обрезанный, да глючный. А дальше по Скраму.
Это я к тому, что пока мы (или они) будут делать идеальный продукт (типа водопадной модели), к релизу он станет уже не идеальный (в той или иной степени), т.к. время снятие показаний и их реализация самый главный наш враг.
Аминь.
спасибо за статью, узнал много чего нового для себя
(65)
Что то мне интуиция шепчет а их и не будет. 😉 и даже намекает почему… Посудите сами — идея расширений дополнение типовых решений. В идеале не снимая с замка. Но идеал не достижим, а раз так то: подписки — добавление своих в основную конфигурацию типовой функционал не пересекают, а значит при обновлениях никаким образом не мешают.
Остальные объекты аналогично. То есть, все то что можно добавить не используя типовой функционал вполне можно, и я для себя решил, вполне нужно, реализовать в основной конфигурации.
(65)
Пародия, не пародия, но жизнь по доработке на текущий момент существенно облегчает. Учитывая что модульность в принципе не заложена, то это можно считать началом будущей модульности. Во всяком случае я на это сильно рассчитываю….
(69)У подписок есть два важных положительных отличия:
1. Можно сделать одну подписку сразу на несколько источников, в т.ч. на обобщённые — типа ДокументОбъект — без этого просто невозможно делать универсальные подписчики, которые, скажем, должны срабатывать при записи любого ссылочного объекта (в т.ч. которые появятся в будущем), при необходимости проверяя источник уже в самом обработчке на любые условия.
2. В рамках одной конфингурации можно делать несколько подписчиков на одно событие — когда они не пересекаются друг с другом и относятся к решению разных задач, и могут разрабатываться параллельно разными разработчиками, не мешая друг другу. Заодно можно проверить в одном месте всех подписчиков (особенно в EDT где наконец-то их можно группировать по источникам — хоть и всё-равно через жопу).
Конечно, наиболее важным тут является пункт 1.
По остальным отсутствующим объектам — это больше похоже про то как сначала дают конфетку, приучают к ней — а потом её отбирают — мол довольно уже есть сладкое, жри горькую редьку — она полезнее, а с конфеткой мы погорячились!
Добавлять в прямо конфигурацию — это же кошмар — как я написал делить проект на части и по разному размещать его в ИБ — это БРЕД! Особенно если думать о расширениях — именно как о шаге к модульным поставкам решений — когда поставщик поставляет дополнительный функционал к основной конфигурации в самостоятельном расширении. И через него осуществляет обновления.
Даже для внутренней разработки расширения, содержащие именно внутри новые метаданные, могут быть очень полезны — вот, к примеру у меня в группе компаний сотни баз, несколько десятков разных конфигураций, нескольких базовых типовых видов. У меня есть функционал — который мне нужно в них все поставить (на 80% он общий для всех баз), который мне потом нужно будет сопровождать и поддерживать. Что мне проще — заморачиваться с отдельной поставкой конфигурации поставщиком (старый проблемный подход) — или завести расширение в хранилище — и подключить его сразу ко всем базам (и обновлять потом через единое хранилище, а оставшимся 20% различий в функционале управлять через встроенные в расширение функциональные опции на базе встроенных же констант)?
Так что пока расширения выглядят больше как издёвка — но я не буду спорить — даже в таком виде (не ниже 12 релиза совместимости) они могут быть вполне полезны — но только как суррогат — т.к. как по-другому выходит не лучше!
(70)Резюмирую — для основной массы текущих потребителей типовых продуктов 1С функционала расширений вполне хватает. Вполне допускаю что есть проекты которым расширение все равно что припарка, но так это уже и не типовые решения.
Работаю с расширениями немного. Но на практике понял, что на расширениях делать удобно внешние механизмы, работающие с данными. Например, очень удобно делать HTTP и WEB сервисы. Какие-нибудь сервисы обработки данных.
Что-то связанное с хранением данных пока тоже не рискую делать. Хотя в этом направлении наверное тоже идет развитие. Поэтому когда-нибудь мнение свое изменю.
Иногда расширения используем для исправления ошибок при обновлении. Для критических исправлений.
(72) кстати да, мы тоже активно используем расширение для HTTP-сервиса, на основную конфигурацию вообще никак не влияет, зато разрабатывать маленькое решение (а именно разбор в git) гораздо удобнее, чем ворошить всю конфигурацию.
(73)
Вы будете смеяться, но рекомендации разработаны, а подогнать под них уже созданные ранее решения всё никак руки не доходят, поэтому пункт 4 у нас существует в проекте (т.е. есть расширение, которое используют другие расширения, по хорошему либо переносить код в общий модуль в конфигурации, либо объединять расширения в одно).
(71)Думаю, что основная масса потребителей расширений как раз таки обходит их стороной. А кто действительно был бы готов активно использовать расширения — недовольны их урезанностью. Впрочем, с 14 релиза платформы, даже с этой урезанностью, «проливая крокодильи слёзы», ограниченно применять расширения можно, всё-равно чередуя их с необходимостью менять основную конфигурацию для отдельных случаев. Вот только режим совместимости платформы 8.3.14 ещё ни у одной типовой конфигурации не стоит — ждёмс….
А про конфигурации на на обычных формах я вообще молчу — они без «танцов в бубном» вообще расширения не поддерживают. И не говорите, что их инсталлировано меньше, чем на управляемом приложении.
«В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль»
Ошибка номера платформы — поправьте.
(77) уточните где, что-то никак не найду, где написала не 8.3.15…
(79) да, тоже вместо версии пишем дату (и время, если изменений было несколько в течении дня), и это не только в расширениях, но и отчетах и обработках.
(76)Не хочу и не буду с Вами спорить. У нас разный круг решаемых задач. Сказу за себя — ЕРП 2.4.6 вполне доработана под специфику задач, режим совместимости — НЕ ИСПОЛЬЗОВАТЬ и на 12 платформе вполне все работает. Раньше была отключена от конфы поставщика, сейчас практически полностью поставлена на поддержку. 😉
(80)Я в расширениях для БП писал версию такую же как и БП.
(81)Я с Вами и не спорю. При сопровождении ERP 2.4 применять расширения вполне можно и это вполне эффективно (чем без них). Но это капля в море возможностей, где можно было бы применить расширения; и очень скромный ареал программистов, кому они тут интересны (не как эксперимент или мелочная доработка), а как основная стратегия сопровождения типовой конфигурации.
(78)
В тексте статьи есть фраза: «В платформе 8.3.15 появилась замечательная новая аннотация &ИзменениеИКонтроль»
(78)
Сейчас последняя платформа 8.3.14
(88)
В 8.3.14 этой аннотации еще нет. Только в 8.3.15.
(92) о, отлично!
(73)
Расскажите: откуда информация? Замеров нигде не видел, на глаз разницы не увидел (версия 8.3.7 и ниже не в счет). Лично общался с разработчиками функционала расширений, уверяли, что на производительность работы количество расширений не влияет и у них это контролируется.
(73)
Так же сплетни, наверно все же в профессиональном сообществе не то, что не стоит на это полагаться, а даже озвучивать тезисы с такими источниками.
Отсюда с тем что для 1 базы использовать одно расширение — не соглашусь. Если в базе много доработок, разного времени и разного назначения, то под каждую задачу нужно отдельное расширение. Естественно, пересекающиеся задачи, которые используют одни объекты (например несколько раз доработали форму заказа, под разные хотелки) — по сути 1 задача и расширение одно. К этому пришел после неоднократных, не очень удачных обновлений, когда 1С переработают конфигурацию на столько, что не работает почти ни чего. Когда расширение одно — оно отвалилось и пока весь функционал не пройдем, в продакшине ни чего не работает. А на это не всегда есть время, лучше все же если обновление поджимает — его сделать и функционал доработок запустить по очереди в порядке приоритета. Бывают же функции которые раз в квартал используют, а из-за этого мы не можем первичку оперативную печатать — не хорошо.
(92) я ещё к 12…13… 14… не успел привыкнуть :))) ждём 8.4 чтоли уже :))
(97)
Дождемся ли? ;))
(98) дождемся… дождемся и версию Х 🙂
(2)+++ , при грамотной доработке, намного лучше, чем расширения
(42)Разработчики 1с на конференции так говорят, что нечетные номера — это тест версии
(4)а просто хранить документацию к нас не умеют, это все печально.
(3) УТ 11, добавил в расширение документ «Реализация товаров услуг» перестала формироваться структура подчиненности документов.
(25)
а как решили? использовали типовую синхранизацию?
и как создавать Регламентированные задания?
(36) а можно озвучить с какими примерно проблемами придется столкнуться и сколько по времени у вас уходит на адаптацию?
(123)Давно это было, уже не помню, при обновлении уже сейчас нет больших проблем (разве что много изменений показывает — которых либо вовсе нет, либо какая-то ерунда и надо просто взять версию поставщика), только при переходе были проблемы.
В основном проблемы были с именами полей метаданных и функций — в новых версиях конфигураций появляются новые встроенные или появляются просто запрет какого-то имени — и возникает конфликт, когда в конфигурации это имя использется -чаще все го нужно просто везде переименовать (дабы платформа сейчас это легко позволяет автоматизировать).
Вроде как с регистрами (вроде сведений_ были какие-то траблы — не реструктуризировались (парочка — но это индивидуально) — пришлось их выгружать, очищать и потом загружать.
Не бойтесь сами посмотреть — сделайте копию и на ней проверьте. Рекомендую только делать всё на серверной базе и менять режим совместимости поэтапно (по одной версии) — делать реструктуризацию — как при обновлении.
А в конце на копии запустить перепроведение всех документов. Ну и РИБ перенастроить заново и проверит (конфигурацию придётся так же по частям переносить в другой узел, возможно через РИБ не пройдёт — придётся вручную переносить) — если используете.
Поищите на инфорстарте — тут вроде были статьи на то как перейти на версию совместимости с поддержкой расширений для старых конфигураций