Использование механизма расширений для разработки большого блока функциональности
Подскажите пожалуйста, есть ли какие-то примеры реализации большого блока функциональности полностью на расширениях? Ранее в из "Зазеркалья" сообщалось что:
Актуален совет по прежнему и для платформы 8.3.12? Может есть примеры разработки полноценных "тиражных" решений с использованием только механизма расширений?
Есть соблазн использовать расширения для создания тиражных прикладных решений, однако делать этого не стоит. Во-первых, потому, что расширения не проектировались под такие задачи. А во-вторых, потому, что другие механизмы платформы, например механизмы поставки и поддержки, ничего не знают о расширениях.
Актуален совет по прежнему и для платформы 8.3.12? Может есть примеры разработки полноценных "тиражных" решений с использованием только механизма расширений?
По теме из базы знаний
- Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария
- Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика
- Быстрый фронт в базе размером 8.8 терабайт – наши стандарты при разработке компонентов системы
- Технологии и преимущества разработки решений на общем коде. Как разрабатывается 1С:РМК, 1C:Розница и 1С:УНФ
- 1С в «Газпром нефти»: технологии разработки и внедрения
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Наверняка есть, но многие по прежнему обходят стороной расширения.
А некоторые добавляют реквизиты в основную конфигурацию, а код выносят в расширения.
Тут вопрос, что за функциональность вы решил разработать, так как по прежнему в расширениях есть множество ограничений (хотя и многое сделано в этом направление).
Если вы хотите внести блок, который ни коим образом не взаимодействует с основной конфигурацией, а является полностью самостоятельный дополненным функционалом, то можно попробовать реализовать через расширения.
А некоторые добавляют реквизиты в основную конфигурацию, а код выносят в расширения.
Тут вопрос, что за функциональность вы решил разработать, так как по прежнему в расширениях есть множество ограничений (хотя и многое сделано в этом направление).
Если вы хотите внести блок, который ни коим образом не взаимодействует с основной конфигурацией, а является полностью самостоятельный дополненным функционалом, то можно попробовать реализовать через расширения.
(1) Можете смело использовать механизм расширений для создания своих решений (в том числе и тиражных). В расширениях есть конечно свои "подводные камни", но в большинстве случаев их можно обойти.
Весь функционал (егаис,ветис,регл.отчетность,бпо и т.д.) вынес в расширения - очень удобно, проблемы конечно бывают, но все они решаемы.
Весь функционал (егаис,ветис,регл.отчетность,бпо и т.д.) вынес в расширения - очень удобно, проблемы конечно бывают, но все они решаемы.
В расширениях расстраивает то, что после обновления конфигурации оно если отваливается, то целиком. Фактически, надо следить за каждым релизом расширяемой конфигурации и тестировать расширение на совместимость.
(9) Тогда начинайте делать, там также есть всякие контроли типов реквизитов, на случай, если при обновление добавится/убавится или вовсе сменится тип реквизита.
Вообщем пока не начнете, не поймете с чем придется столкнутся.
(11) Хм, а вы снимали совместимость со своей конфигурации? А то сейчас как раз этим занимаюсь, но для других целей.
Вообщем пока не начнете, не поймете с чем придется столкнутся.
(11) Хм, а вы снимали совместимость со своей конфигурации? А то сейчас как раз этим занимаюсь, но для других целей.
(12)
Вообщем пока не начнете, не поймете с чем придется столкнутся.
Увы, это не тот случай. Хочется как можно лучше разобраться в вопросе. Т.к. если, после нескольких месяцев плотной работы вдруг выяснится какая-то критическая проблема механизма, которая не позволит двигаться разработке, то это будет катастрофа.
(14) Тогда опишите подробнее разрабатываемый механизм.
Из того, с чем я столкнулся, это добавленные реквизиты через расширение, не доступны в запросе через ссылку.
То есть:
1) Добавил реквизит в документ.
2) Захотел вывести в журнал документов, графу добавить нельзя, но есть выход, вытащить через ссылку в динамическом списке.
И тут облом, в запросе через ссылку этих реквизитов нет.
И еще одно ограничение (но оно понятно), это функции, то есть, если надо изменить поведение стандартной функции, то придется её дублировать в расширение и переписывать. Так как функцию можно только заменить, а не вызвать свою после или до.
Из того, с чем я столкнулся, это добавленные реквизиты через расширение, не доступны в запросе через ссылку.
То есть:
1) Добавил реквизит в документ.
2) Захотел вывести в журнал документов, графу добавить нельзя, но есть выход, вытащить через ссылку в динамическом списке.
И тут облом, в запросе через ссылку этих реквизитов нет.
И еще одно ограничение (но оно понятно), это функции, то есть, если надо изменить поведение стандартной функции, то придется её дублировать в расширение и переписывать. Так как функцию можно только заменить, а не вызвать свою после или до.
Есть поставки у многих франчей, включающие два варианта продажи - или как отдельную базу данных + обмен с центральной, или как модули/доработки, встраиваемые с разной степенью кривизны и совместимости в типовые (и не очень) конфигурации. Логично что может возникнуть желание эти модули оформить как расширение, а отдельную базу в виде какой-то каркасной конфигурации+то же самое расширение.
Таких модулей много. Диадок, практически все отраслевые решения.
Это превратит процесс доработки доработанной (или переработанной) конфигурации клиента в продажу расширения без вмешательства в саму конфигурацию (и снизит риск ответственности за то, что франч что-то не так сделал (например из-за непонимания снес нечто нужное, за что были в свое время уплачены большие деньги) и переложит основную работу по интеграции на плечи специалистов, ведущих заказчика (клиента) - фикси, фри, или внедренцев франчей с большей степенью ответственности и (как мы надеемся) с более качественным внедрением.
Таких модулей много. Диадок, практически все отраслевые решения.
Это превратит процесс доработки доработанной (или переработанной) конфигурации клиента в продажу расширения без вмешательства в саму конфигурацию (и снизит риск ответственности за то, что франч что-то не так сделал (например из-за непонимания снес нечто нужное, за что были в свое время уплачены большие деньги) и переложит основную работу по интеграции на плечи специалистов, ведущих заказчика (клиента) - фикси, фри, или внедренцев франчей с большей степенью ответственности и (как мы надеемся) с более качественным внедрением.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот