Расширения 1С — удобный и адекватный механизм при работе с типовыми конфигурациями. Я использую его регулярно, и за все время работы с этим механизмом накопил некоторый опыт по его разработке, а именно, необязательно все доработки создавать и использовать в расширении, удобней применять другой инструмент типовых конфигураций на базе БСП: Дополнительные отчеты и обработки.
К примеру, нужно создать свою альтернативную форму подбора Быстрые товары списком в РМК 1С: Розница, или форму списка справочника Справочник номенклатуры расширенный.
Для этого создаем внешнюю обработку, в которой реализуем всю необходимую логику работы и сохраняем в справочнике Дополнительные отчеты и обработки. А в расширении делаем вызов формы допобработки из справочника и в случае необходимости (к примеру подбор) обрабатываем через оповещения данные.
Пример кода в расширении: Быстрые товары списком
Пример кода в расширении: Справочник номенклатуры расширенный
Преимущества использования такой связки:
1. Во внешней обработке нам доступны все объекты конфигурации, в отличие от расширения, например при использовании Конструктора запросов или создания реквизитов ссылочного типа на форме.
2. Закрытие и открытие внешней обработки для отладки не требуют перезапуска 1С Предприятия, экономия времени налицо
3. Если нужно что-то изменить в работающей системе, то обновление допобработки в справочнике, не потребует от работающих пользователей перезапуска 1С Предприятия
Вывод: Связка Расширения конфигурации + Дополнительные отчеты и обработки делают для разработку более эргономичной и удобной
Всем Спасибо.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А можно поподробнее про отладку.
>2. Закрытие и открытие внешней обработки для отладки не требуют перезапуска 1С Предприятия, экономия времени >налицо
(1) это типовой механизм, вроде. Тоже часто этим пользуюсь. В конфигураторе открываете на редактирование обработку. Её же открываете в режиме предприятия (запущенном в режиме отладки) через Файл — открыть. Всё, точки останова работают и т.п. функционал отладки…
(2) Тут речь идет о подключенной внешней обработке.
Действительно, так можно облегчить разработку. Есть определенные сомнения в вопросе производительности, если дорабатываемая часть функционала часто используемая. Но это чисто ИМХО. Ведь обращение к обработке (ПодключитьВнешнююОбработку) по факту производит каждый раз запись обработки во временное хранилище (хотя возможно механизм платформы делает определенное кэширование и повторное обращение уже будет менее ресурсозатратным). Хотелось бы знать, конечно, это момент более подробно.
(4) Я не чистый разработчик, а практик с опытом (программирование это примерно 10% моей работы, основное техподдержка и администрирование), и клиенты у меня небольшие. Поэтому что-то сказать про производительность мне трудно. Но удобство разработки для меня — это важно, поэтому все что можно и нужно добавить/изменить стараюсь делать во внешних файлах обработок, а в расширениях — минимум кода и интерфейса, так что если есть просадка по производительности, она не очень заметна. И еще — много клиентов на базовых версиях, здесь расширения не работают, а открыть к примеру альтернативную форму справочника номенклатуры в пару кликов — вполне приемлемо.
(6) вы имеете в виду работу конфигураторе с расширением? Можно и так, но есть важный момент: если это делать в рабочем режиме, то при сохранении расширения в конфигураторе через некоторое время у работающих пользователей будет выведено сообщение о необходимости перезапуска, что не есть хорошо, например на кассах продаж с приличным клиентопотоком. А так обновил внешнюю обработку в справочнике Допообработки и никто ничего и не заметил, и если есть ошибки, то исправление и перезапись внешнего файла менее чувствительна, болезненна для активно работающих пользователей в рабочем режиме, чем редактирование и пересохранение работающего расширения, требующего рестарта приложения.
Мое мнение, чем меньше объектов и кода в расширениях тем лучше.
Хорошая мысль. Спасибо. Удобно тем, что не нужно добавлять массу объектов в расширение, например, для того, чтобы отладить запрос. Кроме того, чем меньше объектов в расширении, тем меньше проблем при обновлении.
Я как раз все свои ранние наработки например переделываю под этот механизм: одна внешняя обработка с несколькими диалоговыми формами.
Вы по факту рассказываете, что вы свои доработки делаете в продуктивных базах без какого- либо тестирования.
Для вас очень удобно, бесспорно.
Добрый день!
«От чего можно отказаться при разработке расширений 1С» — расширения 1С;
«Расширения 1С — удобный и адекватный механизм при работе с типовыми конфигурациями.» — аж глаз задергался.
Статья весьма в правильном направлении, есть масса способов обойти это проклятое место стороной!
Имел ряд негативных опытов в работе с сеим детищем и могу выделить два момента. Первое — это обновление платформы, ты никогда не знаешь, что на этот раз появится или от чего откажутся, а перелопачивать уйму. Второе — поддержка. Если где-то будет получаться не то, что хотелось бы, то с первого раза можно и не догадаться, что кто-то делал это в расширении и времязатраты будут колоссальными. Расширения хороши когда нужно срочно, буквально вчера, поправить ошибку, а монопольный доступ к базе не получить.
Не согласен со статьей. Так как описано — делать не нужно. Может это и удобно, но в один прекрасный день внешняя обработка исчезнет. И все, приплыли.
Не нужно хранить яйца в одной корзине, что-то во внешних обработках, что-то в расширении, иногда надо приходится менять саму конфигурацию
Разные варианты и решения — это хорошо и правильно
(11) Вот да, насчёт «удобного и адекватного» — это очень суровое преувеличение. Не к ночи будь помянута сия кривая поделка. И совершенно верно замечено — никогда не знаешь, что где накроется и сломается.
Как контролировать что ничего не сломалось при обновлении ? Как вести версионирование доработок ? Очень спорное предложение.
«Если в машине нет какой-то опции, значит она не сломается (опция)», дословная цитата от Генри Форда. Так и с расширениями, если чего-то избыточного нет, то и надежность расширения выше. А внешнюю обработку, которая лежит в справочнике, сломать сложно, и наличие этой обработки вряд ли влияет к примеру на процесс обновления конфигурации.
Уберите в конце «.Ссылка», глаз режет )
А если ее переименуют, иди собирай по коду где она искалась…
(17) Вы правы, исправил
в расширениях есть свои плюсы и минусы. Тут как везде: нужно уметь правильно их готовить
(11)Автор же пишет, что в основном поддержкой занимается. И компании не большие, значит и доработок мало. В его случае, я думаю, такой вариант будет удобным.
Если доработок много, то, как ни крути, удобнее в основной конфигурации дорабатывать. Тут и версионирование, отладка удобнее, ну про обновление уже много говорили.
(4)
Влияние внешних обработок на производительность:
«Важным отличием внешних обработок от обработок, встроенных в конфигурацию, является то, что компиляция модулей, встроенных в конфигурацию, выполняется однократно в процессе инициализации, тогда как для внешних обработок компиляция будет выполняться многократно отдельно для каждого пользователя. Это приводит как к снижению производительности (компиляция модуля требует времени), так и существенному повышению нагрузки на CPU (компиляция модуля требует ресурсов процессора).»
В этой статье есть результаты нагрузочного тестирования для расширения, внеш. обработки и встроенной обработки. Выводы: нужно обновлять платформу и расширение по производительности на новой платформе не уступает встроенной обработке.
Вариант сто пудов рабочий.