Добрый день дорогие форумчане, Попалась мне в руки очень занятная книжка Хрусталёвой "Расширения конфигураций. Адаптация прикладных решений с сохранением поддержки в облаках и на земле. Разработка в системе 1С:Предприятие 8.3" собственно прочитал ещё не до конца но вот загорелся желанием перенести пару своих проблемных клиентов на работу с расширениями а не на настроенных конфигурациях, что думаете. ваши за и против?

Одобряю )

Я бы пока не стал.

Расширения ещё сырые

(3) как 1с -)

ИМХО
https://im0-tub-ru.yandex.net/i?id=a82aaaaa434d94fe6f7143a4ea5a6183&n=13

(0) Так попробуй на одном и реши для себя.  лично я нейтрален.

(0) Лучше жди 8.3.11.

(0) Может и слететь расширение при обновлении.

я не против

(7) версия же вышла уже

(0) У нас одна база работает с доработками в расширении. Не всё удобно в плане разработки, но в целом, работать можно...
8.3.9.2233

(11) БП 3.0 вроде бы уже на 8.3.10. А там уже добрую половину доработок-руюшичек можно оформить.

осталось дождаться 8.3.11.

Но как правильно заметили выше расширение может слететь. поэтому после обновления конфы обязательно надо проверять

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

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

(10) На ней нельзя работать.

(13) так при установке расширений подразумевается, что типовая на замках

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

в самом управлении расширениями можно устанавливать галку "проверять применимость... " Если обновление типовой спровоцирует проблему в расширении, то оно прост не загрузится.

на возможные ошибки протестить еще не успел. Есть предположение, что там синтаксический анализ модулей и процедур в проверку включен, но насколько точно анализ работает в автоматическом режиме - не видел еще.

(18) Того что оно не загрузится - мало, надо дать понять программисту - вот в этом объекте, в этом модуле - конфликт!

(17) Ты задаешь неудобные вопросы. Может, ещё хочешь возможности работы расширения с хранилищем? )))

>Того что оно не загрузится - мало, надо дать понять программисту - вот в этом объекте, в этом модуле - конфликт!

для этого надо формировать и проверять hash от текста перекрываемой "типовой" функции

а в 1с решили не заморачиваться

доступно и всерьез

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

(22) хэш откуда возьмется в существующем уже расширении, если на запускаемую базу новое CFU прилетело? Конечно слетят любые хэши, даже если и тем более если их сформировали заранее.

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

(0) Использую только у тех клиентов, у которых нет смысла снимкать "замок" ради пары-тройки интерфейсных изменений БП.
При каждом обновлении слетает, заново делаю его.

>А какие именно объекты/процедуры были заимствованы в расширение - это все там и так видно. Может оно и не слишком удобно выглядит, но рассмотреть возможно.

у меня таких точек где меняется код типовых функций измеряется десятками - замумукаешься рассматривать

>хэш откуда возьмется в существующем уже расширении, если на запускаемую базу новое CFU прилетело?

сформируется при обновлении

сейчас кастомизации вставляются в текст модулей анализируя уникальные куски кода - соответственно есть кусок "пропал" - надо анализировать что изменилось

а с расширениями этого не узнать до запуска в рантайме по сути

(28) да, похоже, что все пока только так и есть.

// у меня таких точек где меняется код типовых функций
// измеряется десятками

Тогда вероятно, что путь расширений не для твоего случая
У меня пока тоже не вкладывается в голову, как что-то громоздкое может быть заложено в расширение. Скорей всего, что слишком громоздкое должно уходить куда-то в обособленную сторону, а не врастать в типовую. Если врастать в нее намертво ... хоть сбоку, хоть с любой стороны ... , то эффект будет такой же, как модифицировать конфигу посбивавши все замки.

все как обычно - 1с хреново реализовала неплохую задумку. очередной чемодан без ручки. который можно будет пользовать лет через 5

(20) представим себе форму документа ЗаказКлиента. В ней  пусть 50 процедур, из них 3 процедуры я заменил. Пришло обновление, которое меняет 10 процедур в ЗаказКлиента, при этом только одну замененную мной. Хочется видеть, какие замененные (или измененные) моим расширением процедуры меняются обновлением. Фантастику аля "Обновление аккуратно наложило новые изменения в моё расширение" я не рассматриваю, жизнь одинэсника - боль.

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

Просто что-то мне подсказывает, что в обновлении выкладываются не какие-то 10 процедур из 50 существующих модуле формы ЗаказКлиента, а сразу вся форма и ее модуль полностью.

(0) >> ваши за и против?

За:

Расширения идеально подходят для следующих случаев:
- основная (расширяемая) конфигурация не меняется или очень мало меняется поставщиком.
- если в конфе есть БСП версии 2.3.5 и старше, то всё что раньше пихалось в дополнительные отчеты, обработки и печатные формы можно теперь пихать в расширения. Это гораздо удобнее т.к. у объектов появляется модуль менеджера (обработка дополнительной печатной формы пишется теперь точно так же как если печать реализовывалась внутри самого печатаемого объекта), появляется возможность нормальной (а не ректальной) отладки. Добавленные отчеты и обработки интегрируются в подсистемы (интерфейс), на  них можно строгать роли. Отчеты и обработки в расширении можно привязывать к контексту объектов.
- изменения объектов основной (расширяемой) конфигурации подразумевают по большей части небольшую косметику - вывести парочку реквизитиков на форму или наоборот - скрыть, добавить свою команду и т.п.

Против:
- расширение динамически и сильно меняющихся поставщиком конфигураций. Ибо зае..шься анализировать что там наменял поставщик в расширенной тобою форме. Никаких инструментов для этого нет. И понять будет ли работать корректно расширение с новой версией зачастую можно только запустив конфу.
- расширение данных (с 8.3.11) - пока не до конца понятно как это будет работать и что будет если поставщик изменил расширяемый объект (как будет разруливаться конфликт), или (что еще хуже) связанные зависимые объекты (о которых расширение может ничего не  знать).
- значительное изменение форм опасно так как может привести к конфликту после обновления когда поставщик наменял что-нибудь в расширяемой форме или например в каком-нибудь общем модуле, процедуры и функции которого вызываются из этого модуля. Об ошибке узнаем только постфактум.
- обязательно требуется тестирование (ручное или автоматизированное) после каждого обновления.
- отсутствие возможности использования хранилища. Как следствие - нет версионирования и нет групповой разработки. Вроде как, 1С обещает подумать на эту тему, но когда и как - неизвестно. Проблема версионирования решается использованием EDT и GitHub.
- отсутствие какой-либо возможности сравнения/объединения расширения с основной конфой. Хрен поймешь что именно и как расширяли. А ведь в расширении прилетает огромное количество объектов, которые никак не меняются в расширении (связанные с расширяемыми). И только один единственный фильтр - "измененные/добавленные в расширении".

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

(33) а еще расширения идеально подходят для исправления ошибок, до выхода этих исправлений от 1с

Не все удобно (не все переносится в 8.3.10), но в целом идея нормальная.
Переношу в Бухии. Когда формы доделываешь удобно. Глюки бывают, но думаю в 11 исправят.

(33) Опровергнуть некоторые "Против"
"Ибо зае..шься анализировать что там наменял поставщик в расширенной тобою форме"
Ошибочное мнение. Что бы не наменял поставщик в заимствований форме, ваши изменения (элементы формы, ТЧ и т.п.) все останутся.
" значительное изменение форм опасно так как может привести к конфликту после обновления когда поставщик наменял что-нибудь в расширяемой форме "
  К конфликту приводит интерфейсные изменения одной формы в разных расширениях, значительные изменения - вряд ли. Если конечно это не изменения тянущие на практически полную замену формы стандартной на свою форму
  Изменения поставщика в процедурах не заденут расширение, если стараться не использовать &Вместо. &Перед и &После в большинстве случаях никак не зависят от изменений поставщика.
  Про 8.3.11 пока рано говорить. Слишком сырая, работать невозможно.
"А ведь в расширении прилетает огромное количество объектов, которые никак не меняются в расширении (связанные с расширяемыми). " Просто удаляйте эти об'екты из расширения, все на что не ругается удаление - стереть. Удивитесь как уменьшится количество таких об' ектов, а на работу расширения это никак не повлияет.
  
  Свой итог: Не надо надеяться, что с помощью расширений можно создать целое прикладное решение. Да и не для того оно создавалось. Но большинство задач по доработке конфигураций под клиента можно (а по мне так и нужно) делать в расширении

(36) "&Перед и &После в большинстве случаях никак не зависят от изменений поставщика"

ну да, поменяли сигнатуру метода и приплыли
а так как язык нетипизированный, то очень интересно может получиться

(37) И часто такое бывает? В таком случае и код добавленный в конфигурацию тоже надо перелопачивать и адаптировать под нововведения поставщика.

&Перед и &После это всего лишь частные случаи &Вместо

(39) а оно как раз вменяемо не реализовано. что ставит крест на широком применении

(40) а мне кажется это обычный override +base(super) вызов родительского класса

(41) по сути - да.

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

чаще всего нужен не override, а например "инъекция" в код запроса. которая должна точно встать в "свое" место

код запррса потом меняется,и код расширения переделывать,но,и без расширения всё равно переделывать

(44) так вот и надо увидеть на этапе обновления что сигнатура места куда будет сделана вставка изменилась

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

(45) LINQ_to_1С )))