При переходе на управляемое приложение в платформе «1С:Предприятие 8.3» разработчики часто сталкиваются с неочевидным поведением компилятора. Одной из таких классических проблем является объявление глобальных переменных модуля формы, предназначенных для работы исключительно на клиенте. Казалось бы, синтаксис предельно прост, однако попытка обратиться к объявленной переменной нередко оборачивается ошибкой компиляции: «Переменная не определена». В этой статье мы подробно разберем, почему возникает эта ошибка, как устроен препроцессор управляемых форм и какие лучшие практики существуют для хранения состояния на клиенте.
Рассмотрим стандартную ситуацию, с которой часто сталкиваются разработчики при написании кода. В начале модуля формы мы объявляем клиентскую переменную, а затем пытаемся использовать ее в одной из функций:
&НаКлиенте
Перем ФлагВвода;
&НаКлиенте
Функция ВозвратФлага()
Возврат ФлагВвода;
КонецФункции
В простейшем случае этот код успешно компилируется и работает. Однако в реальных задачах модули содержат сотни или тысячи строк кода, десятки переменных и процедур. Ошибка «Переменная не определена» возникает в тот момент, когда правила объявления нарушаются из-за невнимательности или непонимания контекста выполнения.
Давайте разберем по шагам ключевое правило платформы «1С:Предприятие 8.3»: дефолтная область компиляции для любых переменных и методов модуля управляемой формы — это сервер.
Если мы пишем несколько объявлений подряд без явного указания директив препроцессора, то поведение компилятора кардинально меняется. Проанализируем следующий пример:
&НаКлиенте
Перем ТекущийКлюч;
Перем ФлагВвода;
В данном случае директива &НаКлиенте применяется только к первой переменной (ТекущийКлюч). Вторая переменная (ФлагВвода), перед которой директива не продублирована, автоматически компилируется платформой как серверная переменная модуля.
Когда ниже по коду мы пытаемся обратиться к ней внутри клиентского метода с директивой &НаКлиенте, система выдает ошибку компиляции. Клиентский контекст просто «не видит» переменную, которая была создана на сервере. Именно эта тонкость часто вводит разработчиков в заблуждение.
Чтобы не писать директиву &НаКлиенте перед абсолютно каждой переменной (что делает код громоздким и трудночитаемым), мы можем использовать стандартный синтаксис перечисления через запятую. Это наиболее лаконичный и правильный способ объявления нескольких глобальных клиентских переменных в рамках одного модуля.
Посмотрим на пример правильного оформления начала модуля формы:
&НаКлиенте
Перем ТекущийКлюч, ФлагВвода, ДополнительныйКонтекст, ИмяПодключения;
При таком подходе абсолютно все перечисленные переменные будут инициализированы в контексте клиента. Они будут существовать и хранить свои значения на протяжении всей жизни управляемой формы (пока открыто соответствующее окно у пользователя).
У начинающих разработчиков может возникнуть логичный вопрос: а почему бы просто не объявить переменные на сервере без директив и не использовать их там? Здесь кроется важнейшее архитектурное отличие управляемых форм.
Серверный контекст управляемой формы работает по принципу Stateless (без сохранения состояния). Это означает следующее:
Неопределено.Именно поэтому хранить промежуточное состояние формы (флаги, кэшированные значения, параметры) в серверных переменных модуля бессмысленно. Для этих целей на клиенте используются клиентские переменные, а для сквозной передачи данных между клиентом и сервером — реквизиты формы.
Если в вашей форме планируется использовать большое количество клиентских переменных, то перечисление десятков имен в начале модуля может ухудшить читаемость кода. В качестве элегантной альтернативы рассмотрим паттерн создания единого структурированного контейнера.
Для этого мы объявляем всего одну клиентскую переменную-структуру, а ее инициализацию производим при открытии формы:
&НаКлиенте
Перем КонтекстФормы;
&НаКлиенте
Процедура ПриОткрытии(Отказ)
ИнициализироватьКонтекстКлиента();
КонецПроцедуры
&НаКлиенте
Процедура ИнициализироватьКонтекстКлиента()
КонтекстФормы = Новый Структура;
КонтекстФормы.Вставить("ФлагВвода", Ложь);
КонтекстФормы.Вставить("ТекущийКлюч", "");
КонтекстФормы.Вставить("ВремяПоследнейОперации", ТекущаяДата());
КонецПроцедуры
Далее в любых клиентских процедурах и функциях мы можем обращаться к свойствам нашей структуры напрямую:
&НаКлиенте
Процедура ВыполнитьДействие()
Если КонтекстФормы.ФлагВвода Тогда
// Выполняем логику
КонтекстФормы.ФлагВвода = Ложь;
КонецЕсли;
КонецПроцедуры
Этот подход не только минимизирует количество глобальных переменных в начале модуля, но и позволяет легко отлаживать состояние формы, просматривая содержимое одной структуры КонтекстФормы в табло отладчика.
Не забывайте, что если вам необходимо, чтобы переменная была доступна и на клиенте, и на сервере, а также автоматически сохраняла свое состояние при контекстных переходах «Клиент-Сервер-Клиент», самым правильным решением будет добавление Реквизита формы в редакторе управляемой формы (вкладка «Реквизиты» в правом верхнем углу конфигуратора).
Реквизиты формы (в отличие от реквизитов самого объекта базы данных) не записываются в таблицы SQL, они существуют исключительно в оперативной памяти запущенного сеанса. Платформа берет на себя всю работу по их сериализации и передаче между слоями клиент-серверной архитектуры.
В процессе обсуждения хранения состояния разработчики часто упоминают работу с COM-соединениями и внешними базами данных. Исторически существовал прием помещения COM-объектов во Временное хранилище на сервере (через передачу структуры с COM-объектом внутри).
Обратите внимание на современные ограничения платформы 1С:Предприятие 8.3! В актуальных версиях платформы (особенно при отключенном режиме совместимости) помещать во Временное хранилище объекты, которые не поддерживают сериализацию, строго запрещено. Попытка передать туда COMОбъект приведет к критическому сбою выполнения с ошибкой сериализации.
Для оптимизации работы с внешними источниками в современном мире 1С рекомендуется придерживаться следующих правил:
Таким образом, правильное распределение контекста и понимание работы компилятора в 1С 8.3 позволяет писать надежный, производительный код, избегая досадных синтаксических ошибок на этапе сборки приложения.