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

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

Казалось бы, мучайте вы модуль ОБЪЕКТА вашей внешней обработки! А в модуле формы оставьте лишь код, обслуживающий интерактивные "дела".


НО! С другой стороны, обработку ведь можно открыть в толстом клиенте. И если в модуле объекта был расчет, что код будет исполняться на серверной машине, произойдет мерзкий пшик. А вот в модуле формы пшик не произойдет, потому что в модуле формы есть директивы компиляции.

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

Спасибо всем, кого этот принципиальный теоретический вопрос не оставит равнодушным.

если это модуль формы, то 1. не надо дергать Реквизитформывзначениеиобратно и 2. меньше кнопок, чтобы добраться до кода в конфигураторе. хотя промеры обработок и для УФ и для ОФ есть, например http://catalog.mista.ru/public/197614/ или http://catalog.mista.ru/public/75941/

(0) "обработку ведь можно открыть в толстом клиенте. И если в модуле объекта был расчет, что код будет исполняться на серверной машине, произойдет мерзкий пшик."

Вот я лично вот этого не понял. Почему произойдет пшик?

(1) >>не надо дергать РеквизитФормыВзначение
ну да..  если идет обращение из интерактивной части к методам в модуле объекта, то самый распространенный способ, и чуть ли не единственный - обратиться к реквизиту формы, в котором лежит ДанныеФормыСтруктура (объект "этой" обработки),  и, преобразовав его в значение, обратиться к его методам (мама дорогая, звучит уже как извращение).  Ну и что с того? Ну дернем лишний раз. Разве вендор позиционирует это как что-то нежелательное, без чего следует по возможности обходиться? Подскажите же тогда, все-таки, где про это почитать, плз.

>>меньше кнопок, чтобы добраться до кода в конфигураторе
вот тут не понял. В смысле, во время отладки или анализа кода? Так, опять же, вендор в типовых модулях еще не такие хитросплетения устраивает, перенося зачастую выполнение одной рутинной операции между четырьмя-пятью модулями разного типа. И его не смущает, что анализ или отладка такого кода несколько усложняется.

(2) >>Почему произойдет пшик
ну как же! Если в коде идет расчет на выполнение на сервере, например обращение к серверному модулю, не имеющему флага "Вызов сервера", а код выполняется в толстом клиенте, то будет ошибка при попытке выполнения. Этим граблям уже сто лет в обед.

(3)  "Ну и что с того? Ну дернем лишний раз."
Это "дорогая" операция в плане ресурсов. И если дергаем в цикле - то можно реально сильно просадить производительность. Сталкивался. Пришлось из модуля объекта обработки перетаскивать дубликаты функций во все формы, тогда стало шустро работать.

(4) так.  дорогая операция. понял.  не зря звучит как извращение, оказывается :)   В цикле, конечно, делать не будем, но все равно.  ценная информация, спасибо.

Вот в БП появились с некоторых пор специально созданные формы-"контейнеры" с нагромождениями клиентского функционала в своих модулях. Их, вроде, и не открывают. Объект формы получил, экспортные методы выполнил - и про форму "забыл". Но это, конечно - немножко другое. Какая-то логика есть. А с серверными методами - вообще непонятно. В модуль объекта их пихать, как мы выясняем - не комильфо по целому ряду причин, и в модуле формы тонны серверного функционала лепить - тоже странно потом лицезреть такие вирши... Ну не для того изначально существует форма, механизм для вывода информации, способ реализации интерфейса машина-человек.

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

А все эти супер-пупер-обработины для, я не знаю, интеграции с яндекс-картами или там администрирования БД и программно-аппаратной связки - по сути ПРОФАНАЦИЯ!

В следующий раз когда увижу крутую обработку со всякими плюшками, буду презрительно комментировать:  "понавертел-то, понавертел..."

(3)
1. "Если в коде идет расчет на выполнение на сервере, например обращение к серверному модулю, не имеющему флага "Вызов сервера""
А что в УФ можно с клиента дергать процедуры такого модуля? Причем здесь именно толстый клиент и внешняя обработка?

2. "Получается, мощный серверный функционал во внешней обработке неуместен."
Это еще почему? На безрыбье, как известно, и рак - рыба. Никакой принципиальной разницы как определить место выполнения процедуры (на сервере или на клиенте) нет. В конце оно все равно размещается либо там либо там.

"Форма не предназначена быть на сервере" - это таки да.
"Модуль объекта более логично иметь на сервере" - и это таки да. Но чем помешало разделение процедур на клиентские и серверные в модуле формы - понять не могу. Просто представь, что форма и модуль формы есть разные сущности. И все станет на место. Конечно для снобов можно было бы и модуль формы визуально разделить на серверную часть и клиентскую. Но! Буду банален. Вам таки шашечки или таки ехать?

(6) 1. >>А что в УФ можно с клиента дергать процедуры такого модуля?
Можно дергать процедуры такого модуля из методов, написанных в модуле объекта внешней обработки. При условии, что эти методы выполняются не в толстом клиенте.
Но мы уже выяснили, что размещать в модуле объекта такой серверный функционал - не комильфо.

2.>>Это еще почему?
Вроде я все разложил по полочкам. В модуле объекта - плохо, и в модуле формы - не есть хорошо. Других модулей у внешней обработки просто нет.



>>"Форма не предназначена быть на сервере"  - такого я не писал. И форма находится на сервере регулярно.
>>"Модуль объекта более логично иметь на сервере" - такого тоже не писал. И оставляю юзеру право работать с внешней обработкой в том типе клиента, какой ему удобнее. Т.е. оставлять возможность, что модуль объекта будет выполняться в толстом клиенте со всеми вытекающими.

>>Но чем помешало разделение процедур на клиентские и серверные в модуле формы - понять не могу/
Нет-нет, тут прошу меня правильно понять. Разделение кода мне по душе (как программисту). Сабж-то не об этом.

>>для снобов можно было бы и модуль формы визуально разделить на серверную часть и клиентскую
да ну нафиг :)  и так нормально

(7) что-то вы пессимист какой-то. Напишем так: размещать серверные процедуры в модуле формы очень хорошо. Размещать в модуле объекта тоже неплохо.

Так что вы нас не запугаете.

(8) >> размещать серверные процедуры в модуле формы очень хорошо
Вот оно! Значит, в модуле объекта - тоже неплохо, только надо помнить, что возможны ситуации, когда наш код будет выполняться не на серверной машине, а на клиенте (толстом), так что здесь все что угодно из того, что можно сделать на сервере, вы уже не сделаете. Неполноценный тут "сервер".

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

Какие-то же рекомендации по этому вопросу должны быть? Мнение уважаемых форумчан - это здорово, но как же мнение вендора?

(9) про толстый клиент забудьте. Помнить про него не надо. Вот я 5 лет пишу это обработки, про толстый клиент вообще ни разу не вспомнил.

ИМХО не стоит здесь сильно теоретизировать.
(Мой) здравый смысл говорит:
если обработка внешняя и всё использование только из формы, то весь код может быть в форме;
если обработка внешняя и предполагаются разные режимы использования (УФ/ОФ/программный вызов); то общий код в модуле объекта;
для внутренних объектов код разносим по ОМ, модулям менеджеров, объектов и форм.

(10) >>Помнить про него не надо
да нет уж, только я забудусь и напишу что-то, чему место только на сервере, так либо потом метод моей обработки используют в регл. задании, где запускается сеанс в толстом, либо юзер откроет программу в толстом.
И начинают сыпаться ошибки, в первую очередь потому, что не видны общие модули "Сервер".
Так что если Вам везет - я рад, а остальным судьба не забываться и быть внимательней.

(12) >>для внутренних объектов код разносим по ОМ, модулям менеджеров, объектов и форм
тема просто случаи, когда

>>реализуя во внешней обработке какой-то функционал, которого нет в конфигурации, и который никак нельзя туда вставить


Никак нельзя туда вставить.

* (13) - для (11)

и еще для (11)

>>если обработка внешняя и предполагаются разные режимы использования (УФ/ОФ/программный вызов); то общий код в модуле объекта


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

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

(15) делайте все стопудово-серверные. Они же спокойно выполняются на толстом клиенте. ТО есть не пишите в модуль документа функции Вопрос, Предупреждение и ОткрытьФорму. А в чем смысл запуска толстого клиента? И вот это непонятно "либо юзер откроет программу в толстом". КАкого хрена вы разрешаете такие вещи юзеру?

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

>>делайте все стопудово-серверные
да как я их такими сделаю в модуле объекта внешней обработки? Директив компиляции же нету!

>>Они же спокойно выполняются на толстом клиенте
не соглашусь. Во-первых, не все методы платформы, которые доступны на сервере, доступны также и в толстом клиенте, хотя, наверное, примеры найти будет сложно, а во-вторых, бывает, что нужно выполнение кода на серверной машине просто потому, что только на этой машине есть какие-то сторонние программные ресурсы или хранилища.

>>А в чем смысл запуска толстого клиента?
да никакого там смысла, имхо, но вот, представьте, есть юзер, и у этого юзера нет прав на запуск тонкого клиента. По разным причинам. Запуск толстого клиента не запрещен в принципе. Кто угодно, использующий мою обработку, может открыть ее в толстом. Платформа же универсальна.

>>КАкого хрена вы разрешаете такие вещи юзеру?
Смеетесь?  С каких пор это табу?

(17) И потом, я не админ..  диктовать заказчику политику использования ПО и настройки не могу. Не я "какого хрена" разрешаю. Или не разрешаю. Да, я могу давать рекомендации.  И только.

(17) все должны работать в тонком клиенте. И только двое каких-нибудь гуру-администраторов, вот им надо оставить возможность в толстом. Так на всякий случай.

(19) оу.  да что Вы, я Вас умоляю. В той же УТ, ЕМНИП, некоторые визуальные редакторы работают только в толстом. При попытке обратиться к ним в тонком будет предложение перезайти в базу в толстом.

(19) ага. в УПП особенно или УТ 10.3

(21)  так, кто-то вспомнил про обычные формы.  немножко не к месту. В старых реалиях - там вообще другая ситуация. Отправить принудительно код исполняться на сервере можно было только написав его в соответствующем общем модуле. Слава Богу, "времена менялись и изменились в конец" (с)

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

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

(24) Пишите код под УФ сразу и все будет работать, есть только несколько нехороших мест, где надо учитывать клиент.

(23) >>выбрать место где будет находится код
ну так вот как раз сейчас разговариваем, где размещать серверный код.  Выбираем-с...

>>Если код будет вызываться извне - в модуль обработки.
см. (15)

>>Если не будет или не должен - в модуль формы.
т.е. предлагаете всегда, когда обработка предназначена для интерактивного использования (не для вызова "извне"), ВЕСЬ серверный код помещать в модуле формы?

(24) , (25)   бывает же, когда приходишь к заказчику - а у него УЖЕ часть конфы переписана под толстый.  Тут уж выбирать не приходится. Соглашусь.

(26) Ну что бы попасть в модуль объекта и жить в нем надо будет делать экспортный модуль. Если к нему никак кроме формы доступа быть не должно, то и этого метода быть не должно, тогда да,  все в модуль формы.
Все зависит от задачи и еще раз повторю: выбрать место где будет находится код - одна из задач разработчика.

(28)  застопорился, пытаясь осознать выражение "экспортный модуль". прошу пояснить

(29) Опечатался. Экспортную процедуру или функцию

(30) все равно не въехал в (28), сори :)

Не уходим от темы. Есть код, который следует исполнять на серверных машине(ах) (если речь идет о кластере).  Куда его поместить во внешней обработке? В модуль объекта? В модули форм? Вообще избегать серверной нагрузки во внешних обработках, пользуясь данными нам расширениями конфы?

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

Если все делать в модуле формы, то нельзя будет воспользоваться подсистемой длительных заданий

(32) и нельзя будет вызвать код извне, что является иногда требованием.
В каждом случае решается индивидуально

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

ок.  чтобы каждый раз не возвращаться к (15), может договоримся, что случаи использования внешней обработки "извне" не рассматриваем? Никаких регламентных заданий и длительных операций. Там сабж неактуален. Там код в модуле объекта внешней обработки используется стопудово на сервере, а значит, можно в этом модуле реализовывать любые хотелки.

(35) Длительные задания - всегда актуальный сабж, особенно если обработки данных делаешь

(35) В стандартах разработки вендора никаких специальных условий по празмещению кода в объекте Внешняя обработка не описано.
https://its.1c.ru/db/v8std
Соответственно - куда хочешь туда и пиши

(36)  Согласен, но сейчас речь не об этом.

Рассматриваем открытие формы внешней обработки. Форма что-то "умеет". В том числе, что-то "умеет" делать на сервере. Возможно, много чего умеет. И серверный код должен быть написан где? Написание в модуле объекта "неполноценно", я уже объяснил, почему. А написание в модуле формы, как говорят - "очень хорошо". Следовательно, когда я вижу тонны серверного кода в модулях форм, я вспоминаю уважаемых форумчан и говорю "ай, какая прелесть".

По ссылке из (37)  подходящей инфы не нашел.  Можно более точную ссылку?

(38) 100% указания где какой код хранить - не может быть. тут всегда элемент творчества

(39)  не верю. каноны, правила, хороший тон, рекомендации вендора - никто не отменял.

(38) Вот именно ее нет = на усмотрение разработчика.

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

(31) тут ты просишь пруф.
Я в (37) дал тебе пруф.
Что еще надо то?
(42) Субъективное мнение. У меня другое. И то и то ничему не противоречит, и то и то правильно.

(43) какой-никакой, а пруф.  Засчитано )  .  Спасибо. На выходных еще поковыряюсь там.  Может, и найду по теме.

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

(45) это раньше было  реквизитформывзначение(), сейчас в новых платформах всё реже и реже.

(46) ну не скажи, вот недавно смотрел примеры внешних обработок от 1С, демонстрирующих написание их для одобрения в сервисе 1С фреш, вот они там используют такие вызовы

Еще пример: есть внешний отчет, который активно использует модуль менеджера этого отчета, куда переносить его?
ответ очевиден: удобнее перенести в модуль объекта, а в модуле формы настроить перенаправление вызовов на модуль объекта.

Вернусь к (11).
(38) Не понимаю, откуда такие опции. Серверные методы не могут быть экспортными, точнее их нельзя вызвать не из формы (или я ошибаюсь?). Поэтому весь внешний серверный "интерфейс" обработки может быть только в модуле обработки. Если такой интерфейс не нужен, то весь код может быть в модуле формы.

ИМХО модуль объекта обработки - это практически артефакт, в котором почти нет смысла. Случай, когда тебе прям нужно получать объект обработки и что-то там с ним делать, довольно специфический. У объекта обработки нет событий, которые можно было бы как-то переопределить (ну, кроме обработки проверки заполнения). Так что в приватном интерфейсе модуля обработки в общем случае смысла нет, а для использования экспортного придется каждый раз создавать объект обработки. В форме находится то, что нужно только для работы формы, а для каких-то общих обработчиков существует модуль менеджера, в обоих случаях объект не дергается. Модуль объекта нужен, только если без него не обойтись, что случается нечасто.

(50) во внешней обработке не бывает модулей менеджера.

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

(52) (50) стандартная интеграция в БСП для внешних обработок для серверных вызовов естественно использует модуль объекта. Альтернатив (предоставляемых платформой) просто нет.

(49) Из другой формы можно вызвать экспортные клиентские и серверные методы этой формы.

(49) пример выгрузка регламентированной отчетности в xml

(53) Я и говорю, "модуль объекта нужен, только если без него не обойтись". Использование обработки в качестве дополнительной - это специальный случай.

(56) Использование внешней обработки в качестве "дополнительной" (подключаемой) - можно сказать уже единственно оставшийся случай, а не "специальный"

(55) в какой конфе? конкретный вызов?
(54)
экспортный серверный метод вызывается с клиента? что делать если надо с сервера?
если можно вызвать с сервера, то как туда (на сервер) попадет форма?

(57) Лишь потому, что в типовых есть БСП, и это удобная хрень. Я имею в виду сферическую обработку в сферической конфе.

(55)
БП 3.0, РегламентированныйОтчетНДС, ФормаОчтета2017Кв1

ФормаВыгрузкиРеглОтчета = ПолучитьФорму("Документ.ВыгрузкаРегламентированныхОтчетов.Форма.ФормаДокумента", , ЭтаФорма);
    
    СпДокОсн = Новый СписокЗначений;
    СпДокОсн.Добавить(СтруктураРеквизитовФормы.мСохраненныйДок);
    
    ФормаВыгрузкиРеглОтчета.Проверить(СпДокОсн);

(60) лень конфу искать. Я правильно понимаю, что метод Проверить серверный, но вызывается с клиента? И никакой возможности его вызвать с сервера (кроме контекста самой формы) нет?

(61) В данном случае Проверить это Экспортная процедура с директивой &НаКлиенте, но может быть вызвана также и экспортная процедура с директивой &НаСервере

(61) с сервера вызвать клиентскую процедуру точно нельзя, серверную точно не скажу.

(63) я так понимаю, что нельзя. Т.к. получить эту форму на сервере или передать её туда невозможно. Или ошибаюсь?

А еще говорят, что под УФ программировать легче. Да-да, вижу :)
1С даже модулем менеджера обделила внешние обработки - вот это вообще ни в какие ворота.

(60) тут вкусовщина похоже, т.к. ничто не мешало, сначала уйти в ОМ, выполнить эту проверку, и уже далее чотатама делать. Т.е. если задаться целью, этот кусок можно переписать. Хотя, если работает и чувакам пофик, то можно и не переписывать, но ТС болеет за прекрасное ж.

(64) Да, ПолучитьФорму() на сервере не сработает (т.к. на сервере метод не доступен), но можно передать Форму в Серверную процедуру выполнив внеконтекстный серверный вызов.

(66) да там много таких процедур которые лезут в форму Документ.ВыгрузкаРегламентированныхОтчетов.Форма.ФормаДокумента. Это я для примера показал.

(68) они хотят эти места легко обновлять, имхо это другая мотивация и другие ценности организации кода

(67) "можно передать Форму в Серверную процедуру выполнив внеконтекстный серверный вызов" // Что ты называешь "серверным вызовом"? Походу ты какое-то свое понятие этого словосочетания используешь.

(67) как раз "передать Форму в Серверную процедуру" по-моему невозможно, будет ошибка отображения или что-то подобное

(71) Он пади под "серверным вызовом" подразумевает просто вызов серверного метода из северного метода ))

*серверного

(0) > стоит ли страховаться в начале модуля объекта так, как страхуется вендор в модулях менеджеров (#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда)   ?

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

На форме следует размещать только код, обслуживающий работу формы (интерактив).
Код модификации, получения и обработки данных должен размещаться в модуле объекта и/или менеджера.

ИМХО.

(72) именно это невозможно: находясь на сервере вне контекста формы нельзя вызвать что-либо из формы вообще (включая экспортные серверные методы).

(75) Хз о чем ты и почему мне что-то пишешь

(76) потому что ты пишешь в (72): "просто вызов серверного метода из северного метода". Это невозможно если вызываемый серверный метод в другой форме.

Я хз что ты там видишь в написанном мною, но заявлять что "именно это невозможно" на твоем месте как-то поспешно

(78) на самом деле я об этом заявляю во всех постах в этой ветке. Но никто не пытается это опровергнуть или согласиться, все игнорируют)). Ты первый, если я не прав, то как это сделать?

Если это сделать нельзя (как я считаю), то весь вопрос (0) ниочём: при необходимости использовать обработку с сервера код придется размещать в модуле обработки и никак иначе.

Я вроде ничего не опровергал. У сообщений есть цифры-ссылки, рекомендую на них обращать внимание.

(80) пока нет)), но ты в (78) говоришь "на твоем месте как-то поспешно", я жду продолжения, но возможно зря)

Я же привел цитату. Найди это свое сообщение и разверни цепочку до самого начала (с учетом моего участия в ней)

(82) Да вижу я всю цепочку и (70). Однако хочется обсуждения сути. При этом "на твоем месте как-то поспешно" - твой посыл мне, а по сути вопроса ты не отвечаешь(я без претензий;)), только увиливаешь.

Ещё раз вопрос для всех: есть ли способ, находясь на сервере, вызвать серверный экспортный метод какой-либо формы (пусть будет форма внешней обработки)? Мой ответ: Нет.

Что значит "еще раз"? Укажи пост, где ты этот вопрос или предположение уже выскащывал.

(84)
утверждение было в (49) формулировка немного неточная, не сказано про вызов с сервера,
в (53) "альтернатив нет",
в (58) "что делать если надо с сервера?",
в (64) "получить эту форму на сервере или передать её туда невозможно. Или ошибаюсь?",
весь пост (75),
в (77): "Это невозможно если вызываемый серверный метод в другой форме."

Достаточно? По сути все посты одном (в вопросительной или утвердительной форме), в (83) "вопрос ребром"

(85) Ну вот видишь, а Я-то на (71) тебе отвечал

(70) передаешь в качестве параметра ЭтаФорма
Чтобы сделать это в рамках модуля текущей формы нужно использовать директиву НаСервереБезКонтекста

(86) Вижу, опять оправдываешься). Зачем, не пойму. Никто к тебе не "цепляется", интересно мнение.
Просто ответь на вопрос (для всех) из (83): да(как?)/нет/не знаю.

(87)Куда передаешь? Форму вроде нельзя передать на сервер.

(88) проверю ещё раз, насколько помню помогала директива НаСервереБезКонтекста при передаче формы в качестве параметра

(89) Проверь. Вообще НаСервереБезКонтекста  как раз отключает передачу контекста(=формы), НаСервере - передает текущую(!) форму на сервер. Передать на сервер (не текущую) форму вроде нельзя никак, как и создать её на сервере.

(90) Проверил, работает:

&НаСервере
Процедура Команда1НаСервере()
    // Вставить содержимое обработчика.
    ПроцНаСервереБезК(ЭтаФорма);
КонецПроцедуры

&НаКлиенте
Процедура Команда1(Команда)
    Команда1НаСервере();
КонецПроцедуры

&НаСервереБезКонтекста
Процедура ПроцНаСервереБезК(УФ)
УФ.ЭкспортнаяПроцедураНаСервере();    
КонецПроцедуры

&НаСервере
Процедура ЭкспортнаяПроцедураНаСервере() Экспорт
    Сообщить("111");
КонецПроцедуры

(91) так у тебя Команда1НаСервере() уже на сервере и в контексте текущей формы.
Найди способ вызвать ЭкспортнаяПроцедураНаСервере() с сервера вне контекста формы. Например, из другой формы но с сервера.

ПроцНаСервереБезК(УФ) без контекста текущей формы же, я в ней вызываю экспортный метод переменной УФ

Так лучше? :



&НаКлиенте
Процедура Команда1(Команда)
    
ПроцНаСервереБезК(ЭтаФорма);

КонецПроцедуры

&НаСервереБезКонтекста
Процедура ПроцНаСервереБезК(УФ)
УФ.ЭкспортнаяПроцедураНаСервере();    
КонецПроцедуры

&НаСервере
Процедура ЭкспортнаяПроцедураНаСервере() Экспорт
    Сообщить("111");
КонецПроцедуры

(94)  гораздо, то что нужно!
Только не работает:
{Обработка.Обработка2.Форма.Форма.Форма(6)}: Ошибка при вызове метода контекста (ПроцНаСервереБезК)
    ПроцНаСервереБезК(ЭтаФорма);
по причине:
Ошибка передачи данных между клиентом и сервером. Значение недопустимого типа.
по причине:
Ошибка преобразования данных XDTO:
Запись значения свойства 'param':
    форма: Элемент
    имя: {http://v8.1c.ru/8.2/managed-application/modules}param
по причине:
Ошибка отображения типов:
Отсутствует отображение для типа 'УправляемаяФорма'

Чем первый вариант не устроил, из серверной процедуры я вызвал серверную процедуру Без Контекста куда передал форму как параметр, а в ней вызвал экспортную процедуру из переданного параметра.
Это не ответ на вопрос? Что с сервера без контекста можно обращаться к экспортным процедурам переданной формы?

(96) ты взял ЭтаФорма на сервере, это можно сделать (на сервере) только изнутри формы. Извне это сделать нельзя.

(97) ок, но согласись твой вопрос не корректный, чисто формально я ответил: в каком то смысле это работает

Форму можно передать с клиента на клиент, и с сервера на сервер, а с клиента на сервер нельзя.

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

(99) Именно так. Поэтому ответ на (0) сводится к (11) без каких-либо красиво/некрасиво и рекомендаций вендора.

(88) Хз о чем ты

(87) Это не серверный вызов, это с сервера на сервер. Ну т.е. как Я и говорил ты называешь вещи не своими именами.

(0) "что разработчики сейчас,"...кто ???
- Это сама 1С ?
- Известные партнеры 1С
- просто обычные франчи
- какие-то НоНэйм программисты ?
- студенты-практиканты ?

(103) думал, тут уже все успокоились :)

>>- Это сама 1С ?
>>
>>- Известные партнеры 1С
>>- просто обычные франчи
>>
>>- какие-то НоНэйм программисты ?
>>- студенты-практиканты ?

Кажется, примеры внешних обработок с кучей серверного функционала прямо в модуле формы валяются на каждом углу. Но дабы не быть голословным, я могу сейчас скачать первую попавшуюся крутую обработину с инфостарта и возопить победоносно "а что я говорил?".

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

(105)
"создаем форму на клиенте, а затем на сервере из формы вызываем нужный метод БСП"
Вроде как пришли к выводу, что передать на сервер форму с клиента нельзя, форму можно передать с клиента на клиент и с сервера на сервер.

1. "затронули вопрос вызова экспортного серверного метода формы"
2. "на сервере из формы вызываем нужный метод БСП"

Ты что-то напутал, неужели для тебя не очевидно, что ты говоришь о каких-то разных вещах?

(106) "передать на сервер форму с клиента нельзя" // Можно если серверный вызов контекстный, т.е. в "пределах" одной и той же формы

+(107) А, не дочитал до конца, пардон.
3. "БСП ... держа переданную ч/з параметр форму под боком и пользуясь, при необходимости, её экспортными серверными методами" // Можешь показать пример код в БСП, который так делает?

(108) речь о внеконтекстном вызове и когда  форма не текущая, т.е. получена методом ПолучитьФорму() (не ЭтаФорма())

3. "БСП ... держа переданную ч/з параметр форму под боком и пользуясь, при необходимости, её экспортными серверными методами"
Есть такие примеры, но не на сервере, а передается форма с клиента в клиентский общий модуль или в экспортную клиентскую процедуру, откуда-то уже дёргаются клиентские или серверные методы экспортные текущей формы. Пример выгрузка и формирование регламентированной отчётности.

(107) 1. "затронули вопрос вызова экспортного серверного метода формы"
2. "на сервере из формы вызываем нужный метод БСП"

это разные вещи, кто ж спорит.


>>"затронули вопрос вызова экспортного серверного метода формы"
>>...  и пользуясь, при необходимости, её экспортными серверными методами

- вот вещи совсем не разные.  Прекрасный пример использования экспортных серверных методов формы.


(109) , (111) ну почему же не на сервере. Вот пример - использование на сервере экспортных методов ЗаполнитьНастройкамиПоУмолчанию() и ЗаполнитьНастройкамиПоУмолчанию() формы бухгалтерского отчета  Отчеты.АнализСубконто.ФормаОтчета:



//В модуле формы

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    БухгалтерскиеОтчетыВызовСервера.ПриСозданииНаСервере(ЭтаФорма, Отказ, СтандартнаяОбработка);
    
    <...>

КонецПроцедуры

//<...>

&НаСервере
Процедура ИзменениеСхемыКомпоновкиДанныхНаСервере() Экспорт
    
    Схема = ПолучитьИзВременногоХранилища(СхемаКомпоновкиДанных);
    
    ПараметрыОС      = Новый Структура("ИндексСубконто, ЗаголовокСубконто", 0, "");
    ПараметрыНМА     = Новый Структура("ИндексСубконто, ЗаголовокСубконто", 0, "");
    ПараметрыФизЛица = Новый Структура("ИндексСубконто, ЗаголовокСубконто", 0, "");
    
    // Изменение представления и наложения ограничения типа значения. "Отчет" - это реквизит формы
    Для Каждого ВидСубконто Из Отчет.СписокВидовСубконто Цикл
        <...>
    КонецЦикла;
    
    <...>
    
КонецПроцедуры

//<...>

&НаСервере
Процедура ЗаполнитьНастройкамиПоУмолчанию(ЗаполняемыеНастройки) Экспорт
    
    Перем ЗаполнятьКоллекцию;
    
    //<...>
    
    Если ЗаполняемыеНастройки.Свойство("Показатели", ЗаполнятьКоллекцию) И ЗаполнятьКоллекцию Тогда
        // Управление показателями.

        //<..>

    КонецЕсли;

    Если ЗаполняемыеНастройки.Свойство("Группировка", ЗаполнятьКоллекцию) И ЗаполнятьКоллекцию Тогда
        // Добавление группировок с соответствии с выбранным счетом.

        //<...>
        
    КонецЕсли;
    
    Если ЗаполняемыеНастройки.Свойство("Отбор", ЗаполнятьКоллекцию) И ЗаполнятьКоллекцию Тогда
        // Добавление неактивных отборов по субконто в соответствии с выбранным счетом.

        //<...>
        

    КонецЕсли;
    
    //<...>
    
КонецПроцедуры




//в модуле БухгалтерскиеОтчетыВызовСервера

Процедура ПриСозданииНаСервере(Форма, Отказ, СтандартнаяОбработка) Экспорт
        
    Отчет     = Форма.Отчет;
    Параметры = Форма.Параметры;
    РеквизитыФормы = РеквизитыФормы(Форма);
    
    ИнициализацияФормыОтчета(Отчет, РеквизитыФормы, Форма);
    
    Если Параметры.Свойство("ОткрытьРасшифровку") И Параметры.ОткрытьРасшифровку Тогда
        СтандартнаяОбработка = Ложь;
        ИнициализацияРасшифровкиПоНастройкам(Отчет, Параметры, РеквизитыФормы, Форма);
    ИначеЕсли Параметры.Свойство("ВидРасшифровки") Тогда
        СтандартнаяОбработка = Ложь;
        ИнициализацияРасшифровкиПоВиду(Отчет, Параметры, РеквизитыФормы, Форма);
    КонецЕсли;
    
КонецПроцедуры

//<...>

Процедура ИнициализацияРасшифровкиПоНастройкам(Отчет, Параметры, РеквизитыФормы, Форма)
    
    Отчет.РежимРасшифровки     = Истина;
    ИмяОтчета               = БухгалтерскиеОтчеты.ИмяОтчета(Форма);
    
    //<...>
    
    Если БухгалтерскиеОтчетыКлиентСервер.ОтчетПоддерживаетУниверсальныеНастройки(ИмяОтчета) Тогда
        
        Форма.ИзменениеСхемыКомпоновкиДанныхНаСервере();
        
        НастройкиКоторыеНужноЗаполнитьПоУмолчанию = БухгалтерскиеОтчетыКлиентСервер.РазделыНастроекСтандартногоОтчета();
        
        <...>
        
        Форма.ЗаполнитьНастройкамиПоУмолчанию(НастройкиКоторыеНужноЗаполнитьПоУмолчанию);
        
    КонецЕсли;

    <...>
    
КонецПроцедуры

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

(112) А, ну ясно - в самой форме, экспортные серверные методы которой хотим дергать, должна быть в серверном контекстом методе предусмотрена передача объекта формы вовне.
Универсально - т.е. "полностью" извне - нельзя вызвать любой экспортный серверный метод произвольной управляемой формы.

(113) "управление (и форма) передается на сервер, где совершаются необходимые действия, в том числе с использованием экспортных серверных методов переданной формы. Доводилось использовать такой сценарий в моих поделках. Работает."
Ну покажи пример с использованием на клиенте ПолучитьФорму() и передачи формы на сервер.

(112) с ЭтаФорма все понятно, пример без ЭтаФорма покажи

(116) Да нет такого примера, что-то ты докопался :) См. (114)

(0)[НО! С другой стороны, обработку ведь можно открыть в толстом клиенте]

Можно, но тут вопрос - а зачем так делать? Обычно, каждая конфа используется в своем режиме - УФ или по-старинке ОФ(обычные толстые формы). Соответственно, ты для конкретной конфы пишешь свою обработку. Зачем закладывать что-то общее и универсальное для, по сути, разнонаправленных решений?

(117) не ну может человек способ знает. Раньше ведь может и было можно, пока дыру не прикрыли. Сейчас пробовал форму запихать в структуру, в ней ещё структура и т.д. аналогично с массивом. Может есть какой ещё баг который не известен.

>>Универсально - т.е. "полностью" извне - нельзя вызвать любой экспортный серверный метод произвольной управляемой формы.

Серверные методы формы давно пора удалить к хренам. Только путают контекст.

Вызвать таки можно, но только если упрформа имеет обработчики и сама запустила ПодклчитьОбработчикОжидания/ПодключитьОбработчикОповещения.

В толстом клиенте кстати можно было через шаманство с событиями от оборудования.

(120) Еще к требованию "универсально" можно добавить, что изначально с сервера нельзя в принципе поиметь форму и любые ее методы, даже если в этой форме предусмотреть интерфейс для передачи самой себя куда-то вовне.
Ну т.е. если какой-то алгоритм есть _только_ в серверном метдоде формы (ЗУП таким славится?), и путь он экспортный, и пусть удалось получить форму на сервере (форма предоставляет такую возможность), а мы не имеем возможность вернуться на клиента, то ждет нас облом.

Можно я вброшу поутру :

Я  вот не могу своим разумом осилить почему Сообщить() может спокойно вызываться на сервере.

(122) ибо сообщить - это не только вывод текста на экран, то и передача между процессами

Стеснюсь спросить : а предупреждения так нельзя было сделать ?

А то приходится ваять вот такую красоту :

&НаКлиенте
Процедура ПредупреждениеОбОшибках(ТекстПредупреждения)
    Оповещение = Новый ОписаниеОповещения("ПослеЗакрытияПредупреждение",
    ЭтотОбъект);    
    
    ПоказатьПредупреждение(
    Оповещение,
    ТекстПредупреждения, // предупреждение
    0, // (необ.) таймаут в секундах
    "Это предупреждение." // (необ.) заголовок
    );
    
КонецПроцедуры    


&НаКлиенте
Процедура ЗаполнитьСводнуюСпецификацию(Команда)
    
    ЕстьОшибки = ЛОЖЬ;
    ТекстПредупреждения = "";
    
    ЧетТамНаСервере(ЕстьОшибки, ТекстПредупреждения);
    
    Если ЕстьОшибки Тогда
        ПредупреждениеОбОшибках(ТекстПредупреждения);

(124) Сообщения после серверного вызова всплывают все сплошняком и особо не мешают.
Представь что было бы если бы предупреждения все разом вываливались и пользователь жмакал бы "ОК" тыщу раз.

(125) Ну так не делай предупреждения же в цикле !

Я о том что :
если можно передавать сообщения между процессами то можно передавать и текст предупреждения с вызовом модального окна предупреждения  В КОНЦЕ серверной процедцуры на клиенте.

Еще жутко не хватает ОбработкапрыванияПользователя() циклы обработки данных крутятся на сервере.

(126) Могу только порекомендовать перечитать написнное в моем предыдущем сообщении

(128)Перечитал.

Предупреждение - это исключительная ситуация зачем
его вызывать сотни раз ?
Мы же непишем предупреждение в модуле проведения.

(124) Есть программа, есть документация. Зачем спрашивать "зачем", если ПО работает как положено?
У 1С есть реально бредовые решения. Пример? "Ошибка целостности" - почему просто не написать "нарушение условий лицензирования..."?

(129) у тебя проблемы с пониманием клиент-серверного взаимодействия.

(130) Чтобы пользователь обосрался что у него база грохнулась а не бежал искать эмулятор


(131) Я думаю врядли
Упрощенно на пальцах что придумали в УФ:

туда сюда гоняется контекст по сути в XML
На клиенте и и сервере его нужно запарсить/распарсить
пока серверная обработка процедуры - запроса не закончится на клиенте результата не получишь


НО Особенность работы 1С не в УФ.
Что нужны всякие хохряшки вызываемые в процессе обработки данных на рантайме а с этим в УФ таки проблемы.

Допустим иду я обработкой по стокам ТЗ и после обработки КАЖДОЙ строки нужно что то визуализировать и такое нужно тоже

(132) но он же в гугл побежит, а там все разжевано.
Это работало только первую неделю

(129) Хз почему ты меня об этом спрашиваешь

(133) Может запаниковать

Вы мне лучше объясни чем думали разработчики конф на УФ если открыв форму дока ты не знаешь проведен он или нет ?
или удален ?

Нет , я знаю что нужно вытащить на форму кнопку отмены проведения и если она неакитивна - то таки документ не проведен.

Но работают с доками не я а юзеры

А зачем им это знать?

(135) В БП3 вижу пиктограмму рядом с датой, а ты про какие типовые?

(137) Так это в форме списка пади. Он про форму объекта.

http://trade.demo.1c.ru/trade/#e1cib/list/Документ.ЗаказКлиента

(138) я тоже про форму документа

Ну значит разрабы БП такое сделали. В линейке ЕРП такого нет.

У меня УТ 11.4.1.261 нет не фига

Менеджер из открывает движения чтобы понять проведен или нет или в форму списка проваливается

(142) Кажется, проще и в плане отзывчивости / быстроты просто один раз нажать на "Еще"