Использование переменных в программных модулях
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
Примеры некорректного использования и исключений из этого правила приведены далее. Рекомендации по оформлению переменных в коде программных модулей см. в статье Структура модуля.
2. Неоправданные примеры использования переменных в модулях объектов (справочников, документов, наборов записей, обработок, отчетов и пр.).
Перем КонвертацияФайлов Экспорт;
Если КонвертацияФайлов Тогда
.
// вызывающий код
ФайлОбъект.КонвертацияФайлов = Истина;
ФайлОбъект.Записать();
Если ДополнительныеСвойства.Свойство(«КонвертацияФайлов») Тогда
.
// вызывающий код
ФайлОбъект.ДополнительныеСвойства.Вставить(«КонвертацияФайлов», Истина);
ФайлОбъект.Записать();
В то же время, для передачи внутренних параметров между обработчиками событий модуля объекта целесообразно использовать неэкспортные переменные модуля объекта, которые недоступны из внешнего кода.
Например:
Перем ПредыдущееЗначениеОрганизации; // значение реквизита «Организация» до записи объекта в базу
Процедура ПриЗаписи(Отказ)
Если ПредыдущееЗначениеРеквизита <> Организация Тогда
// отрабатываем изменение значения реквизита при записи
.
КонецЕсли;
2.2. Для обработки кодов возврата (ошибок) в логике программного модуля рекомендуется использовать строковые константы.
Например, неправильно:
Перем НетОшибок,
Ошибка_ОбработкиПроверкиЗаполнения, // возникает, если обработка проверки заполнения вернула отказ
Ошибка_ЗаписиОбъекта, // возникает, если во время записи объекта возникло исключение
Ошибка_БлокировкиОбъекта, // возникает, при попытке блокировки объекта
НетОшибок = 1;
Ошибка_ОбработкиПроверкиЗаполнения = 2;
Ошибка_ЗаписиОбъекта = 3;
Ошибка_БлокировкиОбъекта = 4;
2.3. Для кеширования долго-вычисляемых и часто-используемых значений в процедурах и функциях рекомендуется применять модули с повторным использованием возвращаемых значений на время вызова сервера.
Исключение из этого правила составляют случаи, когда по соображениям безопасности возвращать результат вычисления в экспортной функции недопустимо. В этом случае они размещаются в локальной переменной модуля.
3. Неоправданные примеры использования переменных в модулях форм.
3.1. Для кеширования долго-вычисляемых и часто-используемых значений в процедурах и функциях рекомендуется применять модули с повторным использованием возвращаемых значений.
3.2. Для хранения и передачи промежуточных результатов вычислений между разными процедурами и функциями формы следует использовать
Исключение из этого правила составляют случаи использования клиентских переменных формы для хранения промежуточных результатов в обработчиках ожидания формы, в обработчиках внешних событий и в клиентских обработчиках событий элементов формы.
Например:
4. Переменные управляемого и обычного приложения следует использовать для хранения «клиентских параметров сеанса». Подробнее см. статью Использование параметров сеанса.
видимость переменной на сервере
Доброго времени суток,
столкнулся со следующей проблемой:
При создании на сервере переменная заполняется ПараметрыФормы = Параметры, отладчик подтверждает, наличие структуры данных.
Но при обращении к переменной из модуля формы, директива &НаСервере, она имеет статус неопределенно.
Пожалуйста подскажите, что я делаю не так?
Скорее всего проблема в самом имени: ПараметрыФормы
Сделайте, например: ПараметрыФормы1
Это имя будет доступно на клиенте и на сервере во всём модуле формы.
З.Ы. Правда с типами будут ограничения формы.
(3) к сожалению, результат прежний
(2) в моем случае это не подойдет, так как передаются ДанныеФормыСтруктура, проще тогда содержимое вставить в структуру и поместить в временное хранилище.
Но всё же вопрос почему я не вижу значение переменной, или тут проблема исключительно в неподдержиемом формате
(4) При каждом обращении к серверу переменные объявленные на сервере инициализируются заново.
Как вариант поместить код в общий модуль, у которого в свойствах установлен параметр «Повторное использование возвращаемых значений».
(6) ЗначениеВСтрокуВнутр для ДанныеФормыСтруктура, выглядит как <"#",afe4a3fc-31ab-435f-b2ab-eba881452f56>, и соответственно ЗначениеИзСтрокиВнутр = неопределенно, с этим работать врядли получится, но идея была не плохая.
(5) за подсказку благодарю, дальше двигаться нет смысла, буду использовать сериализация через переменную формы
Можно обойти через ж.
ЗначениеВСтрокуВнутр / ЗначениеИзСтрокиВнутр
Но не известно, когда 1С захочет «выпилить» данные методы.
Не вижу проблемы, как вы предлагали, создать реквизит формы с типом произвольный и сохранять туда значение с типом структура.
ДанныеФормыВЗначение() в помощь.
представьте что вы у вас не сервер, а кластер из 10 серверов, и вы заранее не знаете на какой сервер попадёт следующий серверный вызов,
соответственно вы не можете хранить контекст на сервере,
на сервере точно есть только данные из базы, на клиенте только то что на форме.
ну этот пример уж слишком высосан из пальца.
так можно прийти к тому, что повторный (и/или рекурсивный) запуск процедуры сохраняет объявленные внутри неё переменные.
или что сосед может смотреть твою почту, если запустит браузер одновременно.
ну а чо, сервер ведь не знает кто смотрит почту.
(16) Не вижу неоднозначности.
1. Да, каждая форма имеет свой контекст и значения, хранящиеся в реквизитах формы, хранятся в рамках этого контекста. И даже данные объекта формы хранятся именно в реквизите формы (Объект, Отчет, Список и т.д.).
2. Совсем другое дело модуль формы, он един для всех созданных экземпляров форм. Разделение идёт только по директиве компиляции(исполнения). И переменные объявленные в этом модуле также едины для всех экземпляров форм. В отличие от упомянутых выше реквизитов формы и по тем же упомянутым причинам.
3. Контекст (идентификатор и набор данных) формы един как для клиента так и для сервера. Различается лишь набор данных представления этого контекста (то, что нужно только для сервера только там и находится), думаю, по понятной причине попытки минимизации передачи объёма данных при вызове сервера. При вызове серверного метода данные формы вместе с идентификатором передаются на сервер, для актуализации этих данных на нём и их последующем участии в обработке.
4. И да, серверу не передается напрямую (платформой) контекст и данные формы при вызове методов, если указана соответствующая директива для вызываемого метода. Причина та же, что и в предыдущем пункте. А программист определяет нужны ли будут (актуальные) данные с клиента, для обработки данных в вызываемом (реализуемом) методе.
Подытожив, никакие данные не хранятся (дольше необходимого) в модуле формы непосредственно вне контекста этой формы. А переменные объявленные в модуле формы, не важно на клиенте или сервере, не принадлежат её контексту. Т.е. переменная модуля формы объявленная с директивой «на клиенте» существует пока существует форма (которая и может быть получена только на клиенте (и толстый клиент не в счёт)), а переменная объявленная с директивой «на сервере» существует пока существует серверный вызов, а при каждом вызове происходят инициализации таких переменных по умолчанию и прописанная в модуле формы (если таковая инициализация присутствует конечно).
Последнее, кстати, легко проверить самостоятельно, просто добавив в модуль формы строчку присвоения значения этой переменной в модуле формы вне методов и установив на неё точку останова.
Это совсем не так. Модуль формы это вообще понятие конфигурирования. В контекст будут включены переменные и методы по соответствующим контекстам. Т.е. при компиляции переменные и методы объявленные директивой компиляции &НаКлиент будут включены в клиентский контекст формы, с директивой &НаСервере будут включены в серверный контекст формы. Никакого единого модуля для всех форм не будет. У каждой формы будут свои контексты формы. И Переменные в каждой форме будут свои.
Ну, попробуйте в одной форме присвоить такой переменной значение, а в другой его прочитать.
Контексты формы серверный и клиентский это совсем разные контексты. Для понимания их взаимодействия достаточно понимать общеязыковое взаимодействие клиент-серверной архитектуры.
То, что вы воспринимаете как «Контекст (идентификатор и набор данных) формы един как для клиента так и для сервера» всего лишь сопоставление реквизитов (и т.д.) отдельно на сервере и отдельно на клиенте. С таким успехом можно говорить, что контекст данных 1С и web-сайта тоже один, если настроено соответствие имен и данных. Так что это совершенно разные контексты, со своими возможностями.
Очень расплывчатая формулировка. Что значит вне контекста этой формы. Если контекста нет, то и формы нет. Если форма есть, то и контекст есть. Вызов же вне контекста не имеет доступ к контексту.
Не путайте значения переменных и сами переменные, т.е. их имена и их же инициализация.
Попробую другую аналогию.
Переменные модуля, можно представить как те же переменные метода. Их значения существуют пока не завершится выполнение метода, в котором она объявлена.
Для «клиентской» переменной, она инициализируется, когда форма открывается, и очищается, когда форма закрывается. Т.е. первичный клиентский метод формы, в котором инициализируются объявленные «клиентские» переменные, не завершается до её закрытия, соответственно и значения переменных существуют до этого же события (в независимости от их конкретных значений).
В тоже время первичный серверный метод, в котором инициализируются «серверные» переменные, работает ровно до конца работы вызванного серверного метода и его переменные «живут» соответственно столько же.
Для наглядности, ещё так в рамках языка данного сабжа.
Для первичного события, которое возникает при вызове метода ПолучитьФорму() или любого другого способа, в том числе неявного, когда это делает сама платформа:
В таком случае эти переменные (П1, П2, ИТД) существуют до закрытия формы, неважно явного, из кода (в каком-то методе), или неявного платформой.
Теперь тоже для вызова серверного метода:
Опять же «серверные» переменные «живут» до конца вызова ВызватьМетодСервера(), который завершается почти сразу после исполнения кода вызываемого метода.
Конечно, это лишь упрощенный пример, но картину «жизни» значений переменных модуля он должен дать.
Я прошу прощения, если тут задену поучением, но контекст от латинского «связь». Нет клиентского и серверного контекста, есть контекст формы (данных формы), который связывает данные формы, хранящиеся как на клиенте, так и на сервере. Т.е. данные формы, которые всегда существуют на клиенте (по самому определению её назначения) и их отражение (возможно с дополнением) на сервере, когда это необходимо. Причем сами данные формы первично могут быть частично или полностью отражением данных объекта, хранящегося на сервере.
Соответственно, директива «без контекста» означает, что для получения результата данные связанные с формой не нужны. Иначе бы с директивой «без контекста» можно было бы получить доступ к данным формы на сервере. «Серверный контекст» по вашему же на сервере есть, так почему бы и нет?
Т.е. директива «без контекста» в первую очередь определяет, нужно ли «тащить» актуальные данные формы с клиента на сервер, а не просто возможность «достучаться» до них там, на сервере. Как я уже писал ранее, это попытка минимизировать сетевой трафик между клиентом и сервером, а не разграничения доступа.
Опять таки вы путаете область видимости с инициализацией. Инициализируются такие переменные один раз для сервера и для клиента.
Для клиента один раз при создании формы и существуют, пока существует форма. К контексту они не привязаны, просто существуют вместе с ним, и на сервер соответственно вместе с контекстом не передаются.
Для сервера же такие переменные инициализируются один раз, но при каждом вызове его метода с клиента ( пример смотреть выше ).
НЕКОТОРЫЕ ОСОБЕННОСТИ УПРАВЛЯЕМЫХ ФОРМ
Рассмотрены следующие отличительные особенности управляемых форм:
• Форма существует и на клиенте и на сервере.
Она осуществляет клиент-серверное взаимодействие
• Форма не работает с прикладными объектами
В форме используются специальные универсальные объекты ДанныеФормы
В управляемых формах на первый план выходит разделение контекста на клиентский и серверный. Для возможности работы по тонким каналам связи вся работа прикладных объектов теперь выполняется только на сервере. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий
В модуле управляемой формы возможно объявление переменных, процедур и функций. Так как у правляемая форма существует одновременно и на сервере и на клиенте, то каждая процедура и функция и объявление переменной должны предваряться директивой компиляции, определяющей среду исполнения.
Допустимы следующие директивы:
&НаКлиенте — Означает, что метод выполняется на стороне клиента, а переменная существует все время жизни клиентской части формы. Клиентская процедура исполняется в среде клиентского приложения. Доступны: Свойства и методы глобального контекста, доступные на клиенте; экспортные переменные; процедуры и функции модуля управляемого приложения, общих модулей скомпилированных на клиенте, общих модулей скомпилированных на сервере, если у них установлено свойство «Вызов Сервера»; свойства и методы расширения формы, определяемого основным реквизитом; свойства и методы объекта встроенного языка УправляемаяФорма; реквизиты формы; локальный контекст модуля.
&НаСервере — Означает, что метод выполняется на стороне сервера, а переменная существует только во время выполнения серверного вызова, при каждом серверном вызове значение переменной сбрасывается. Для серверных методов допустимы вызовы серверных, серверных внеконтекстных и клиент-серверных внеконтекстных методов. Контекст так же образуется свойствами и методами глобального контекста, экспортными процедурами и функциями общих модулей скомпилированных на сервере, свойствами и методами расширения формы, определяемого основным реквизитом, свойствами и методами объекта встроенного языка УправляемаяФорма, реквизитами формы. Клиентские процедуры, функции и переменные недоступны.
&НаСервереБезКонтекста — опреде ляет серверную процедуру, исполняемую вне контекста формы. Переменные не могут предваряться такой директивой. Серверная процедура, исполняемая вне контекста формы, (внеконтекстная) исполняется в среде серверного приложения. В такой процедуре не доступен контекст формы (включая данные формы). Допустимыми являются вызовы только других внеконтекстных процедур. При вызове этих процедур не выполняется передача данных формы на сервер и обратно. Применение внеконтекстных процедур позволяет существенно уменьшить объем передаваемых данных при вызове серверной процедуры из среды клиентского приложения.
&НаКлиентеНаСервереБезКонтекста — используется, когда к процедуре необходимо обращаться как с клиента, так и с сервера. Означает, что метод исполняется как на клиенте, так и на сервере вне контекста формы. Переменные не могут предваряться такой директивой.
Таким образом, разработчик должен понимать, что он фактически работает с двумя контекстами исполнения: серверным и клиентским, и между ними происходит обмен данными
При этом нужно учитывать, что на клиенте поддерживается лишь ограниченный набор типов данных и интерфейсные функции. На клиенте не допускается непосредственная работа с базой данных, работа непосредственно с прикладными объектами, использование запросов, таблиц значений. Доступность описана в синтакс-помошнике и ее необходимо проверять.
При разработке необходимо заботиться об оптимизации клиент-серверного взаимодействия:
Еще одна важная особенность управляемой формы состоит в том, что в ней происходит лишь отображение объекта. Основным ее реквизитом является не сам объект, а данные формы, в которые он преобразуется.
Элементами данных формы могут быть
Поэтому, для управляемой формы напрямую свойства и методы объекта недоступны. Чтобы обратиться из формы к свойствам и методам объекта нужно сначала получить объект.
Во время разработки конфигурации важно помнить, что прикладные объекты доступны только на сервере, в то время как объектами данных форм можно пользоваться и на сервере, и на клиенте.
Директивы выполнения кода в модулях управляемых форм 1С 8.3
С появлением управляемых форм в модулях форм 1С 8.3 стали активно использоваться директивы компиляции в модулях форм и объектов:
Дальше речь пойдет о том, как правильно ими пользоваться и как с их помощью можно оптимизировать работу системы.
Необходимо понимать, как работают управляемые формы в тонком режиме, проще всего представить эту модель в виде веб-сайта: сервер отдельно, клиент отдельно. В момент обращения к форме клиент делает обращение к серверу, и вся работа выполняется на сервере. Клиент (Ваша машина) лишь получает результат работы сервера.
Обратите внимание! Если директива не указана, то по умолчанию она выполняется на сервере.
Особенности компиляции этих директив управляемого приложения
&НаКлиенте
Указывает на то, что процедура или функция выполняется на стороне клиента 1C, все переменные существуют лишь на время жизни клиентской части формы. Такой метод выполняется «у Вас на компьютере», никак не затрагивая серверную часть. С клиента доступны все серверные функции.
На клиенте есть доступ к следующим объектам:
&НаСервере
Выполняется на сервере, переменные существуют только на время серверного вызова. С сервера допустим вызов практически любых процедур, кроме клиентских. Если работа происходит в режиме тонкого клиента, вся работа происходит на сервере, а клиент получает лишь результат выполнения.
&НаСервереБезКонтекста
Это процедура выполняется на сервере, вне контекста формы. Т.е. процедура не имеет доступа к реквизитам формы, выполняется на сервере и возвращает желаемый результат. Хорошо подходит для получения статичных данных. Крайне рекомендуется к использованию для оптимизации клиент-серверного взаимодействия.
&НаКлиентеНаСервереБезКонтекста
Используется, когда к процедуре нужно обращаться и с клиента, и с сервера. В остальном аналог &НаСервереБезКонтекста.
Оптимизация клиент-серверного взаимодействия
При разработке функционала необходимо учитывать следующие нехитрые правила:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
&НаКлиенте, &НаСервере, &НаСервереБезКонтекста
Немного теории о стороне выполнения кода. При работе 1С в режиме клиент-сервера, запускается несколько процессов. На компьютере пользователя запускается 1cv8.exe, на сервере 1С запускается rphost.exe, rmngr.exe и ragent.exe.
ragent.exe
Приложение ragent.exe это по сути и есть наша служба агента 1С, которую мы можем посмотреть в списке служб Windows. Данное приложение отвечает за запуск всех остальных приложений и за распределение нагрузки между рабочими rphost.
rphost.exe
Приложение rphost.exe обслуживает подключения пользователей, выполняет код, написанный в конфигурации 1С. В консоли кластера rphost отображается в блоке «Рабочие процессы»
Рабочих процессов может быть несколько. В версии платформы 8.2 их можно было создавать вручную. В версии 8.3 на их количество можно повлиять косвенно, увеличив количество сеансов или информационных баз на один рабочий процесс в свойствах рабочего сервера.
rmngr.exe
В общем случае данное приложение отвечает за выполнение регламентных заданий.
Сторона выполнения кода
После того, как мы в общих чертах описали приложения, выполняющиеся на сервере, перейдем к описанию директив препроцессора, т.е. тех самых &НаКлиенте, &НаСервере. В зависимости от того, на какой стороне выполняется код, мы имеем доступ к файлам либо пользовательского компьютера, либо к файлам на сервере. При этом очень важно понимать, что код &НаКлиенте выполняется с правами пользователя, запустившего 1С. Код &НаСервере выполняется с правами пользователя, под которым запущена служба агента 1С. Как правило, это пользователь USR1CV8, если никто этого не поменял.
&НаКлиенте
Код выполняется на том компьютере, за которым сидит пользователь и под теми правами, которые есть у пользователя. Файлы, созданные в процедурах &НаКлиенте будут созданы на пользовательском компьютере. Есть множество ограничений выполнения кода &НаКлиенте, например, здесь нельзя обращаться к СУБД. Это значит нельзя использовать как прямое создание запроса, так и косвенный запрос при обращении к ссылке через точку. Компьютер клиента может быть медленнее сервера, это следует учитывать при написании кода.
&НаСервере
Код выполняется на сервере 1С, в процессе rphost. Файлы, созданные в процедурах &НаСервере, будут сохранены на сервере и смогут быть записаны только в те папки, на которые у пользователя службы агента 1С есть доступ на запись. &НаСервере уже можно свободно писать запросы, обращаться к предопределенным данным и к реквизитам ссылки через точку.
&НаСервереБезКонтекста
Это самый интересный вариант, разберемся для начала, что такое контекст формы. Управляемая форма представляется на уровне платформы в виде XML файла описания расположения элементов и значения реквизитов формы. Соответственно, чем больше элементов на форме и чем больше данных хранится в реквизитах формы, тем больше будет контекст.
При вызове процедуры без контекста, процедура не видит реквизитов формы и не может к ним обращаться ни для чтения, ни для изменения.
Когда мы вызываем процедуру с директивой &НаСервере, то эта XML уходит с компьютера клиента на сервер. Преимущество этого подхода в том, что мы можем из этой процедуры напрямую менять значения реквизитов. Недостаток — если необходимо исправить один реквизит на форме, приходится перекидывать иногда достаточно крупную XML. Сталкивался однажды с тем, что возврат выполнения с сервера на клиент занимал около минуты.
И вот здесь нам как раз может помочь директива &НаСервереБезКонтекста.
Рассмотрим для примера такую ситуацию: у нас есть форма, в реквизитах формы есть таблица значений с 100 000 строк и реквизит с именем «Реквизит1». Нам необходимо в этот реквизит значение перечисления.
В данном примере произойдет следующее: описание формы, таблица значений с 100000 строк и реквизит1 будут преобразованы в XML, отправлены на сервер. На сервере будет выполнен небольшой неявный запрос к СУБД, в значение реквизит1 будет записан результат этого запроса, все данные опять преобразуются в XML и отправятся на сервер. Учитывая, что таблица значений очень большая, то получится, что мы большой объем данных дважды в холостую передали между клиентом и сервером. Это не оптимально.
Во втором примере мы не стали передавать контекст формы, в итоге произошла только передача ссылки на элемент перечисления с сервера на клиент.
Важно понимать, сколько данных будет передано в холостую, а сколько полезно. Например, если нам нужно заполнить нашу таблицу значения, то есть самый тяжелый элемент формы, то целесообразней будет не усложнять код обходом передачи контекста, а просто передать контекст через &НаСервере.
Пример 3, предположим, у нас есть название для перечисления, которое хранится в реквизите Реквизит2, мы можем его передать в качестве параметра функции:
Ну и напоследок еще один пример, как делать не надо:
Если мы в качестве параметра передаем ЭтаФорма, то по факту мы внеконтекстный вызов превращаем в контекстный. Если без этого не обойтись, то стоит делать контекстный вызов.