Недавно менял процедуру печати накладной реализации в УТ11.
Так там вся печать одной процедурой - расширение не втиснуть.
Не пора ли 1С пересмотреть подход к написанию процедур и втыкать по возможности затычки.

Т.е. вместо:

ПодоготовитьПараметрыЗапроса
ВыполнитьЗапрос
ПолучитьМакет
ОбойтиЗапрос
ВернутьМакет

Сделать соответствующие процедуры.

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

(28) так себе логика

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

(22) >> тут не о модификации, а скорее о баго-фичах 1с.

Причина необходимости внесения изменений не имеет никакого значения.
Если их надо вносить, то делать это надо вдумчиво и осторожно.

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

(32) я больше с ларьками, прости

(2) В "нормальных" языках даже в перегруженном методе надо писать его с нуля, копируя кусок родительского метода, либо тупо вызывая его через inherited. И вы это прекрасно знаете.

Расширения отлично подходят везде.
Надо просто не лениться и запускать проверку возможности применения после обновлений.

(36) Спасибо КЭП, но перегрузка без проверки изменения кода намного стабильнее работает и требует меньше вызовов программиста

(37) Это для мистеров Мисмачей в порядке вещей замаскировать проблему. Есть шанс, что перекрытие изменений в базовом методе может создать проблем на будущее.

(38) таки вы, Карл, в расширениях используете только замещения с контролем, не так ли?

(39) Перед и После тоже, почему нет?

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

Надеятся то можно, но вот результат вряд ли будет.
О программистах партнёрах думают в последнюю очередь

не, ну если сомневаться в коде перекрываемой процедуры, то нужно при всяком обновлении все перекрытия пересматривать, если верить логике товарища Ежова. Тут или трусы сними или крестик надень.

А по поводу печати: мало того что там все в 1 процедуре, так ещё обход идёт по выборке вместо таблицы. Даже свою колонку не добавишь

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

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

(41) Ну, например, свои процедуры в
ОМ
МодификацияКонфигурацииПереопределяемый

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

(45) Во всех новых продуктах буду отказываться от ВПФ.

(47) а какая замена?

(48) Встроенное в расширение.
Просто как только в расширении покажется новая обработка "ПечатьТТНВозвратыДляИППупкин" я сразу это увижу и спрошу у автора - "А какого хрена".

(49) А что, права на справочник ВПФ нельзя так настроить, чтобы только ты мог загружать туда новые обработки?

(50) Конечно можно. Но я предпочту в составе конфигурации, чтобы и правки можно было проще вносить и проверки конфигурационные выполнять и рефакторинг.

(44) Выгрузка результата запроса в промежуточную таблицу (например, в таблицу значений) без необходимости (-1 балл)

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

(52) Вон, посмотри, как работают профессионалы (53)

(45) речь не только о печатных формах. сходи на geniy1s.ru, там я описываю свой практический опыт, в последнее время часты расширения. Вот в ЭДО приходилось тоже тянуть всю процедуру экранов на 10

(54) я думаю это он прикалывается так

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

(56) лично я так делал, чтобы подсунуть 1С свою выборку, правда, уже не вспомню где

(54) да 1С сама в типовых использует такой финт ушами, как выгрузить временную в ТЗ, доработать напильником и запихать обратно в МВТ

ТЗ = Запрос.МенеджерВременныхТаблиц.Таблицы["Какаятовременнаятаблица"].ПолучитьДанные().Выгрузить();
Для Каждого СтрокаТЗ из ТЗ Цикл
... тут какая-то магия по модификации ТЗ
КонецЦикла

МассивПолейВыборки = Новый Массив;
        Для Каждого Колонка Из ТЗ.Колонки Цикл
            МассивПолейВыборки.Добавить(Колонка.Имя);
        КонецЦикла;
        ТекстПолейВыборки = СтрСоединить(МассивПолейВыборки, ",");
        
        ТекстЗапроса = "
            |УНИЧТОЖИТЬ %1
            |;
            |ВЫБРАТЬ
            |    %2
            |ПОМЕСТИТЬ %1
            |ИЗ
            |    &Таблица КАК Таблица";
        ТекстЗапроса = СтрШаблон(ТекстЗапроса, "Какаятовременнаятаблица", ТекстПолейВыборки);
        
        Запрос.Текст = ТекстЗапроса;
        Запрос.УстановитьПараметр("Таблица", ТЗ);
        
        Запрос.Выполнить();

(59) Это не отменяет -1 балл :-)
Это как оправдывать свою ошибку, ошибкой, которую допускает твой руководитель.

Но на самом деле, ничего страшного в выгрузке в ТЗ нет.

(60) я всегда знал, что в типовых г@внокод. а что в последних платформах расширили работу с МВТ, так "это жжж неспроста"

(59) Сформировать таблицу с данными, которые неэффективно или невозможно получить в запросе это вполне распространённый метод работы.
Но вот обход выборки через ТЗ сразу режет глаз. И есть подозрение что -1 балл, не спроста и такой обход требует доп. ресурсов.

(63) это такой же идиотизм, как запрет на запросы в цикле, как реализации печати документов через запросы и прочие чудеса, придуманные Чистовым и компанией, или кто там за методологию отвечает. Гики, оторванные от реальности

(63) ну например, в ТЗ добавить колоку и заполнить значение (например произведением соседних колонок). Как по-другому будешь делать? Повторю, код из типовой пофигурации взят

(65) Я про обход результата запроса через таблицу, про передачу ТЗ через параметр в запрос написал что имеет место быть в определенных ситуациях.

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

(67) это адекватно выливается в кривые процедуры печати документов, которые мы наблюдаем.

(2) это когда исходный класс был разработан с расчетом на то, что от него будет наследование. Как правило, если сразу такой цели нет, то класс делают final, чтобы избежать "fragile base class problem".
Это же относится и к процедуре в (0).

(69) ты думаешь 1С рассчитывает какие вещи у нее будут наследовать, какие нет? Рассмешил, сказочник

(70) а как же общие модули типа ХХХ_переопределяемый?

(52) Даже если аргументируешь необходимость в данном случае такого подхода? Впрочем, экзамен на то и экзамен, что экзаменуемый должен продемонстрировать умение решить задачу при определенных ограничениях - видимо, там нет задач, когда такой подход можно аргументировать. А в реальной жизни если есть достаточные основания - это не запрещено.

(72) Если аргументируешь не будет - 1 балла, там же есть уточнение "использовать без необходимости"

Выборка из результата запроса ничем не лучше выгрузки в ТЗ. Выборка - это не курсор СУБД. Это по сути та же выгрузка, только с более убогим программным интерфейсом. И память жрет практически столько же. Можете проверить на тестовом примере..
Но непонятно почему в 1с хорошим тоном считается использовать выборку, а не выгрузку. В то время как выборка намного хуже для поддержки.

(74) Может они в 1С там думают, что выборка - это курсор? Поверье у них такое

(74) там есть короткий пик потребления памяти 2x при Выгрузить(). Изза этого. Но мне как то пофиг.

(14) "По каким-то причинам 1с сознательно затрудняет модификацию алгоритмов общих модулей в расширениях. Это делается разными способами, но все связаны с разрушением "законченности" синтаксических единиц(процедур, функций). То есть, просто подменить вход и выход у процедуры по тем или иным причинам крайне сложно, не дублируя и не переписывая код. Неоднократно с таким сталкивался."

Вот вот. Проще отказаться от расширений, снять конфу с поддержки и дорабатывать. Как же я ненавижу расширения

(77) нет, есть еще метод парсинга. Я уже писал о нем на мисте. Ищи и наслаждайся.

(77) да потому что архитектора нормального там нет, а может и вообще нет

таки устал бороться с 1С и перешел на ИзменениеСКонтролем или как оно правильно называется. экономлю много времени.

(80) К чему тогда были советы из (78)? В порядке бреда? Или коллеге решил свинью подложить?

(81) это хорошие советы. для фикси или конторы, где большой объем изменений. Они съэкономят много нервов на обновлениях

(82)  где большой объем изменений лучше вообще не надо расширения

(80) а чё не на свой велосипед?

(77) "Я гналась за Вами три дня, чтобы сказать как Вы мне безразличны!"

(85) бабушка потеряла костыль и бегала за ребенком?

(0) печатные формы лучше внешними делать, а не расширением

(87) А ИТС говорит - наоборот...

(88) (87) внешними дороже

(67) У профессионалов запросы в цикле не тормозят.

(88) расширение делается под конкретного клиента (если это не тиражная разработка).
а ВПФ один раз сделал и можно подключать и к другим клиентам.

(89) странная у тебя позиция, дороже чего ?

(92) внешними дороже чем расширениями.

(91) почему расширение нельзя многим клиентам ставить? Можно.

(93) Нунуну. Это у тебя ценник такой?

(95) это из практики.

(94) если у тебя с десяток форм, и пара ВПФ отвалилось при обновлении, по моему проще эти пару форм поправить. а если они у тебя в расширении, и расширение отвалилось. думаю дольше придется восстанавливать + все формы будут не доступны.

(97) нет, не дольше

(97) пардон, если отвалилось расширение печатной формы, с чего отвалиться форме? ;-)

(94) если делаешь расширение под конкретного клиента, кроме печ.форм там и другие вещи наверняка есть. остальным клиентам всем будешь ставить это расширение?

(98) зависит от объема изменений.

(100) религия не позволяет сделать отдельное расширение? ;-)

1 печ форма - 1 расширение?

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

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

(99) имелось ввиду если отвалится расширение, то все печ формы из расширения станут не доступны

(104) не соглашусь. в ВПФ так же можно подравнять и адрес и другие реквизиты

Геня, тебе надеяться уже давно не на что.

(102) позволяет, просто в зависимости от задачи. пользуюсь тем что лучше подходит в моем случае. где то расширение где то ВПФ

Бугыгы, это сюр какой-то, Геня, неспособный осилить пару страниц документации, называет Чистова "оторванным от реальности гиком".
Увиии...

(106) оно отвалится абсолютно одинаково. Причем, примерно с той же вероятности, что и ВПФ отвалится после обновления конфигурации.

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

Но эти все рассуждения к теме или к вопросу топика не относятся.

(111) это если делать одна форма = одно расширение. а если форм десяток в одном расширении, они станут не доступны если слетит расширение. а если сделано ВПФ, недоступны будут только часть форм, которые слетят после обновления

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

(113) При критичных изменения типовой у тебя ВСЕ впф слетят. И править придется _каждую_

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

Повторяюсь - к теме топика это оффтоп.

(0) по теме было бы удобнее, если бы разбивали на несколько процедур. так проще было бы работать с ними в расширении.

Есть слишком простое отношение к качеству сопровождения типовых. Как тут любят заявлять "широко распространенное мнение"

А давай в документе новые реквизиты вкорячим... Но если они же в расширении будут вкорячены, то отвалятся... ну тогда снимаем "замок" и прямо в ней.
Затем печформу. Удобно ее в расширение втулить? Тогда и перекуроченный типовой объект будет там же. И затем при обновлении типовой не запустится все?! Ужас-ужас-ужас.

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

Зато если слетит расширение, то это сразу будет заметно. а то что печ формы не работают можно узнать сильно потом

(117) и (118) спорить не буду, возможно расширение лучше когда работаешь с одной двумя базами, конечно проще делать все в расширении. а когда несколько баз проще сделать одну ВПФ и подключить к ним.

(119) если баз много то расширение можно скриптом обновлять, а впф нет

(120) НЕТ? Да ладно... вы не знаете, как скриптом обновить ВПФ? гггг

(119) ну вот скажем я делал недавно ВПФ Торг-12 в евро, даже учитывая, что я его с инфостарта скачал, два часа на полировку затратил.
Хотя расширением вообще бы не сделал. ;-) ВПФ тоже объемно делать, особенно учитывая, как громоздко 1С сейчас пишет печатные формы. Это раньше все в одной процедуре было.

(120) имеется ввиду не сколько разных клиентов с типовыми базами на разных естественно компьютерах и серверах. Обновлять их скриптом?

(122) так что в итоге проще, доработать готовую ВПФ с инфостарта или пилить свою (не важно в расширении или ВПФ).

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

(123) если на разных серверах, то и расширение тоже проблематично обновлять.

(125) согласен, еще один плюс ВПФ, ее можно обновить в предприятии, не перезапуская сеансы пользователей.

(90) запросы с цикле разными бывают. Например если используется какой-то конструктор отчетов, то там часто запросы в цикле идут.

(111) ВПФ можно исправить без демонического обновления.

(128) не теребите Гондурас и от него не будет беспокойства

(129) ты про это? https://apleks.livejournal.com/333043.html