1с что такое контекст формы
Обновлено: 04.07.2024
Всем привет. продолжаем изучать платформу 1С: Предприятие 8.3. Это уже второй урок, в котором мы начнем изучать основные объекты платформы для возможности разработки собственного приложения. Первый объект - это константа.
Приступим к изучению!
Часть 1. Запуск созданной информационной базы ( Урок 1 )
Запустим ярлык на рабочем столе, откроется уже знакомое окно, в котором есть два режима: режим разработчика и режим пользователя. Так как в прошлом уроке мы мы создали информационную базу, нам ее еще раз создавать ненужно. Выделим нашу информационную базу "Автоматизация предприятия" и нажмем на кнопку "Конфигуратор". По нажатию на эту кнопку происходит переход в режим разработчика.
Здесь нужно понять лишь один смысл! Если мы хотим разработать что-то свое, то это только режим разработчика. Если мы хотим работать в существующей программе, то это режим пользователя. Платформа позволяет работать одному человеку сразу в двух режимах (сначала что-то разработал, потом заходишь и проверяешь).Учебная версия - она ограничена по функционалу и дает возможность работать только одному человеку. А если лицензия - то их может доходить и до 300 (все зависит от вида лицензии).
Нажимаем кнопку "Конфигуратор" (Рисунок 1).
Произошел переход в режим разработчика (Рисунок 2).
На рисунке 2 показана иконка, на которую нужно нажать и у вас откроется дерево конфигурации (Рисунок 3).
Дерево конфигурации - это дерево, которое имеет ветви, а каждая ветвь в свою очередь имеет какие-то отростки - объекты. Объекты - это константы, справочники, документы и так далее. Более подробно можно почитать нажав сюда.
Все, что сейчас находится в режиме разработчика - это инструменты, с которыми будет работать программист для создания своей программы, но это ничего не видно в режиме пользователя.
Как только разработчик создает справочник или константу, она сразу же отображается в режиме пользователя.
В прошлом уроке мы пробовали создавать справочник, но перед этим заходили в режим пользователя, чтобы убедиться в том, что там ничего нет. Добавили справочник и только после этого у пользователя появилась возможность сразу автоматизировать свою деятельность.
Ничего не создавая, перейдем в режим пользователя и еще раз убедимся в том, что там ничего нет. Для этого выполним команду: "Сервис-1С:Предприятие" (Рисунок 4).
Откроется знакомое окно и оно действительно пустое (Рисунок 5).
На рисунке 5 отображается пользовательский режим, а сверху написано имя вашей программы и называется она "Конфигурация". Давайте изменим его и назовем "Автоматизация предприятия". Закроем режим "1С: Предприятие" на крестик в верхнем правом углу и вернемся в режим разработчика.
Выделим в дереве конфигурации корень этого дерева - слово Конфигурация, правой кнопкой мыши вызовем контекстное меню (или дважды щелкнем по нему правой кнопкой мыши) и выберем пункт "Свойства" (Рисунок 6).
Откроется палитра свойств (рисунок 7)
Палитра свойств - это окно, в котором отображаются все свойства, доступные для данного объекта. В данном случае, это свойства всего дерева конфигурации.
В открывшейся палитре свойств нам сейчас важны два свойства, Имя и Синоним.
Имя - это идентификатор, который нужен для разработчика и виден от только разработчику. Он нужен программисту для того, чтобы он мог к нему с помощью кода обратиться и где-то использовать.
Синоним - это имя, которое будет отображаться в пользовательском режиме и будет видно пользователю. То есть это то свойство, которое необходимо для пользователя.
Имя и синоним могут быть одинаковыми. Правила задания свойства "Имя":
1. Должно начинаться с буквы
2. Не может содержать пробелов и других специальных символов кроме подчеркивания "_"
3. Пишется слитно, но каждое слово с большой буквы - "АвтоматизацияПредприятия". Этот способ называется - верблюжий. В этом случае платформа понимает, что ей необходимо отделить каждое слово друг от друга (Рисунок 8).
Часть 2. Изменим имя конфигурации (программы)
Изменим имя "Конфигурация" на "АвтоматизацияПредприятия" и нажмем "Tab". В этом случае (Рисунок 8) синоним автоматически заполнится и разделится на два слова (но можно и просто перенести курсор в поле синоним), а свойство Имя останется также слитно - так и должно быть.
Таким образом мы изменили нашу программу (она называется конфигурация или программное решение - это термины 1С). Посмотрите на рисунок 8, в дереве объектов изменилось название. Теперь необходимо обновить программу, внести изменения и проверить все в пользовательском режиме. Нажмем клавишу F7 или значок на панели инструментов (Рисунок 9)
После того, как нажали клавишу или на этот значок, значок обновления должен стать серым и недоступным - это значит, что пока нет никаких изменений в вашей программе.
Перейдем теперь в режим пользователя и проверим изменения. Для этого необходимо выполнить команду "сервис-1С6Предприятие". Откроется знакомое окно, в котором будет название нашей программы (рисунок 10).
Сейчас вы уже сделали первых два шага по разработке своей конфигурации и это уже совсем не плохо!
Часть 2. Создание константы
Теперь необходимо как-то дальше разработать программу, чтобы она подходила для вашего предприятия.
Что такое константа? Константа - это объект дерева конфигурации, который предназначен для хранения постоянной величины или величины, которая меняется очень редко.
Константа я языках программирования - это то, что никогда не изменяется. Тем это и отличается в платформе. В платформе 1С это величина, которая изменяется крайне редко.
Вся платформа 1С создана так, что ее смысл понятен в русском языке. Константа в жизни каждого человека, это, например, его имя. Оно вроде является постоянной величиной, но его можно изменить. Или, это фамилия, инн, адрес и так далее. все это константы в понимании 1С.
Константа нужна для хранения "постоянной" величины. В нашем случае константами будут являться: 1. ИНН организации, имя директора магазина, адрес магазина и так далее - все это константы.
Перейдем в режим разработчика, выделим константу и правой кнопкой мыши добавим новую константу (или это можно сделать иначе. Выделить константы и нажать на плюсик в верхней панели дерева объектов).
, или просто, – это набор функций, процедур, свойств, типов, объектов, методов, событий, доступный в некотором модуле, в некотором его методе. Другими словами, находясь в модуле, вы можете использовать не все то, что описано в синтакс-помощнике, а только некоторую часть синтакс-помощника. Эта часть и называется контекстом.
Наиболее крупными контекстами являются и . Причина их существования заключается в том, что в самом общем случае прикладные решения работают в клиент-серверном варианте.
В этом варианте работы пользователь взаимодействует с клиентским приложением. В клиентском приложении в определенные моменты времени (события) выполняется программный код, написанный в модулях. Этот код исполняется в клиентском контексте.
Клиентское приложение, в свою очередь, взаимодействует с кластером серверов «1С:Предприятия 8». В кластере серверов также, в определенные моменты времени (события) или в определенной ситуации (вызов серверного метода), выполняется программный код, написанный в модулях. Этот код исполняется в серверном контексте.
Так как система программ «1С:Предприятие 8» позволяет работать с прикладными решениями через Интернет, клиентское приложение и кластер серверов могут находиться и исполняться не просто на разных компьютерах, а в разных городах, странах, частях света.
Конечно, в более простых случаях клиентское приложение и кластер серверов могут находиться на одном компьютере, или кластер серверов может вообще не использоваться (в файловом варианте работы). Но это не влияет на то, как пишутся модули: они пишутся один раз и сразу для работы в самом общем, клиент-серверном варианте. А если в реальной ситуации используется более простой вариант развертывания системы, то платформа просто эмулирует нужные контексты при выполнении тех или иных модулей.
Условия, в которых исполняется код клиентских приложений, значительно отличаются от условий, в которых исполняется код кластера серверов. Например, там, где есть клиентское приложение, там есть пользователь, есть возможность интерактивного взаимодействия с ним. Для этого встроенный язык может использовать большой набор интерфейсных типов, которые входят в клиентский контекст.
С другой стороны, там, где исполняется кластер серверов, там нет пользователя. Соответственно и типы, предназначенные для взаимодействия с интерфейсом, в серверном контексте отсутствуют. В то же время кластер взаимодействует с системой управления базами данных, поэтому на сервере во встроенном языке доступны прикладные типы, позволяющие читать прикладные данные из базы и записывать их. Эти типы есть в серверном контексте, однако их нет в клиентском контексте.
Самое очевидное место, где вы можете увидеть использование клиентского и серверного контекстов – это модули форм. Эти модули могут исполняться и клиентскими приложениями и кластером серверов. Поэтому, как правило, перед каждым методом таких модулей указана директива компиляции. Она определяет, в каком контексте будет существовать этот метод в этом модуле:
Директива &НаСервере значит, что эта процедура будет существовать в модуле, когда он исполняется на сервере. Когда он исполняется на клиенте, в нем этой процедуры не будет.
Директива &НаКлиенте значит, что эта процедура будет существовать в модуле, когда он исполняется на клиенте. Когда он исполняется на сервере, в нем этой процедуры не будет.
Помимо клиентского и серверного контекстов существуют и более «узкие» контексты. Это связано с тем, что клиентских приложений существует несколько (тонкий клиент, веб-клиент, толстый клиент, мобильный клиент), а серверная часть бывает не только у «настольных» приложений, но и у мобильных. Каждое из клиентских приложений, каждая серверная часть имеют свои особенности исполнения программного кода, имеют свой контекст. Эти контексты вы можете увидеть в синтакс-помощнике, в описании всех типов, их методов, свойств и событий. Они перечисляются в разделе Доступность.
Для типа Массив указано:
Это значит, что тип Массив вы можете использовать практически во всех клиентских и серверных контекстах. В том числе и на мобильных устройствах.
Эта статья продолжает цикл «Первые шаги в разработке на 1С», в ней рассмотрены следующие вопросы:
- Что такое контекст и почему его важно определять при написании программного кода?
- Чем образуется глобальный контекст? Как научиться определять, что к нему относится?
- Чем отличаются клиентский и серверный контекст? В чем тут вся соль?
Применимость
В статье рассматривается платформа «1C:Предприятие» 8.3.4.496. Материал актуален и для текущих релизов платформы.
Понятие контекста программного кода
Т.е. это те процедуры и функции, те свойства и методы, которые доступны в данной конкретной точке.
В другой точке контекст может измениться. Даже в одном модуле в разных процедурах может быть совершенно разный контекст.
Именно поэтому важно представлять контекст данной точки, где мы ведем разработку, чтобы понимать: какие свойства и методы мы можем использовать.
Выделяют несколько видов контекста. Во-первых, контекст глобальный, который доступен в любой точке конфигурации (в принципе, нужно еще делить контекст на Сервер и на Клиент).
Глобальный контекст доступен во всех местах конфигурации.
Глобальный контекст образуется прежде всего процедурами и функциями глобального контекста Платформы.
Конечно же, в глобальный контекст также входят и встроенные функции работы со строкой, числом, датой и т.д. Все это тоже образует глобальный контекст.
Обратите внимание, что существуют не только методы глобального контекста, но и свойства. К ним можно обращаться.
Также в глобальный контекст входят системные перечисления и системные значения.
Например, перечисление ОбходРезультатаЗапроса имеет три фиксированных значения. Мы можем обращаться к этому перечислению в любой точке конфигурации.
Системные наборы имеют похожее назначение с перечислениями. Указывается набор значений и выбор одного из значений.
Кроме того, в глобальный контекст также входят экспортные методы общих модулей. Существуют модули для описания общих алгоритмов, и некоторые их методы можно делать экспортными, тогда они могут вызываться из других программных модулей.
Помимо Глобального контекста существует локальный контекст модуля. Это в конкретном модуле какие существуют переменные, процедуры и функции.
Если спуститься еще на уровень ниже, существует локальный контекст процедуры. В процедуре можно объявлять свои собственные переменные.
В модуле, например, могут существовать две переменные с одинаковым названием: одна объявлена на уровне контекста модуля, а вторая на уровне самой процедуры. Это две разные переменные.
Контекст выполнения программного кода в платформе 8.3 может делиться на Клиентский и Серверный. По сути это означает, что программный код выполняется либо на стороне клиентской машины, либо на стороне Сервера приложений.
Существуют типы данных, которые поддерживаются и на Клиенте и на Сервере (т.е. их можно спокойно использовать в любом программном коде).
Важно понимать, что программный код, который скомпилирован на Клиенте, является независимым от программного кода, который скомпилирован на Сервере. Если речь идет о Клиенте, то в основном это какие-то легкие действия.
Важно понимать, какое возможно взаимодействие между Клиентом и Сервером.
Существует возможность из процедур клиентских обращаться к процедурам серверным. Система, после обработки соответствующего серверного кода вернет управление назад на точку вызова.
Следует обратить внимание, что обратный вызов невозможен, т.е. со стороны Сервера клиентский метод мы вызвать не можем ни при каких условиях.
Клиентские процедуры могут вызывать как другие клиентские процедуры, так и серверные процедуры.
Таким образом, при разработке в Платформе 1С:Предприятие 8.3 важно понимать, где будет скомпилирована процедура: на Клиенте или на Сервере, поскольку от этого будет зависеть текущий контекст модуля.
Если в модуле могут присутствовать как те, так и другие процедуры (например, модуль управляемой формы), то при создании процедуры необходимо указывать, где она будет скомпилирована: на Сервере или на Клиенте.
Для этого есть определенные директивы, которые четко указывают, где будет использоваться данная процедура. Исходя из этого в процедуре будут доступны соответствующие типы данных.
Ниже представлены примеры клиентской и серверной процедуры модуля формы.
Когда мы описываем некую переменную, то мы также должны указывать (как для процедуры или функции место компиляции), где эта переменная будет находиться: на Клиенте или на Сервере.
Т.е. если указать, что переменная будет доступна на Сервере, то ее можно будет использовать в серверных процедурах.
Дело в том, что при втором варианте на Сервер передаются еще все данные формы.
Обратите внимание, что для каждого объекта в синтакс-помощнике указывается доступность данного свойства или метода (сервер, тонкий клиент, толстый клиент, внешнее соединение).
В заключение отметим, что уже после публикации выше представленного материала у нас появилась новая статья, которую мы, прямо настоятельно рекомендуем прочитать сейчас, пока мы не перешли к следующей теме! Маст хэв для любого, кто хочет разобраться «на пальцах» во всей этой кухне клиент-серверного взаимодействия.
Ну а мы идем дальше, и теперь, когда базовые понятия о контексте уже получены, вспоминаем, где мы писали весь наш программный код? Как правило, в одном модуле – модуле формы. А какие-то другие модули еще существуют? Конечно, существуют, и в следующей статье мы все подробно разъясним. :)
PDF-версия статьи для участников группы ВКонтакте
Статья в PDF-формате
В этой статье мы покажем, как взаимодействуют клиентская и серверная части платформы и какие есть особенности в использовании директив компиляции.
Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере.
Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.
Немного базовой теории
Перед тем, как перейти к содержательной части, договоримся о некоторых ограничениях:
Далее, освежим в памяти немного теории.
Директивы, в имени которых упоминается «Клиент», устанавливают ограничение на обращение к базе данных.
Процедуры или функции, написанные под директивой «Без контекста», не имеют доступа к контексту (данным) формы. Исходя из этой информации, легко представить ограничения директив по доступу к данным в виде следующей таблицы:
Опережая вопрос «Для чего же директива с самым длинным названием, если она ограничивает и использование контекста форм, и обращения к базе данных?», напомню: любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.
Не стоит забывать и про доступность вызова одних процедур и функций из других. Для этого стоит запомнить, что можно вызывать только те процедуры и функции, которые находятся под одноимённой (с родительским методом) директивой или под директивой, находящейся ниже (чем у родительского метода) согласно списку:
Теперь про серверный вызов
Самый первый серверный вызов инициализируется в момент начала сеанса работы 1С. То есть когда пользователь выполняет вход в информационную базу:
Всё очень просто:
Обратите внимание, что доступ к базе данных есть только на серверной части, а соединение между клиентом и сервером имеет ограниченную пропускную способность. Это и неудивительно – ведь соединение между клиентской и серверной частью может быть установлено даже по нестабильному низкоскоростному каналу связи (например, посредством мобильного интернета).
Кроме этого, передача данных между клиентом и сервером возможна только посредством серверного вызова.
Видим, что на стороне клиента у нас будут доступны процедуры и функции, написанные под двумя директивами из четырёх, а на стороне сервера – под тремя из четырёх.
Сейчас мы постараемся понять особенности работы системы при использовании директив и почему необходимо уметь правильно использовать каждую из существующих директив компиляции.
И в этом нам помогут наши новые друзья, знакомьтесь!
Это процесс клиентской части приложения «1С:Предприятие 8». Он запускается на компьютере пользователя и сожительствует в оперативной памяти с другими процессами (38 вкладок браузера, поток аудио из социальной сети, telegram и другие). Может порождать серверный вызов.Это процесс серверной части приложения «1С:Предприятие 8». Он существует на сервере 1С. Знает, какие клиентские сеансы в данный момент запущены, но самостоятельно не может инициировать взаимодействие с ними. Работает с клиентской частью только через полученный от неё серверный вызов. А это серверный вызов. Как было сказано выше, он порождается процессом клиентской части и призван «прислуживать» ему. Он передает запросы со стороны клиента на сторону сервера, а также занимается транспортировкой данных с клиента на сервер и обратно.
Итак, давайте рассмотрим несколько особенностей работы программного кода в «1С:Предприятие 8», написанного под разными директивами.
Действие 1. Открытие пользователем формы с данными.
В момент нажатия Пользователем кнопки открытия формы из интерфейса, происходит передача управления на Сервер. По переданным параметрам получаются необходимые для построения данные из БД и происходит формирование контекста формы, который затем отправляется на клиентскую часть. У пользователя на экране отображается запрошенная форма.Действие 2. Получение из открытой Пользователем формы дополнительных данных из Базы данных.
После выполнения метода на сервере, весь этот «пакет» транспортируется обратно. Таким образом, форма со всеми элементами и данными дважды проходит через самое узкое место системы.
Таким образом, серверный вызов не несёт лишней нагрузки, и для передачи данных между клиентом и сервером потребуется меньше ресурсов.
Кстати, именно поэтому до версии платформы 8.3.7.1759 на сложных формах для управления видимостью элементов рекомендовалось использовать панели со страницами, а не свойство «Видимость». Только начиная с этого релиза отработка изменения видимости элементов стала выполняться на стороне клиента.Действие 3. Обработка данных табличной части формы с получением дополнительной информации из Базы данных.
Явление 1. Построчная обработка табличной части на стороне клиента с организацией серверного вызова для получения дополнительной информации из базы данных.
При таком построении программного кода происходит множественное обращение со стороны клиента на сервер – по количеству элементов цикла, запущенного на стороне клиента.Явление 2. Предварительная обработка табличной части на стороне клиента с целью подготовки требуемых к обработке на сервере данных и «упаковки» их в набор параметров. Затем передача этого набора на сервер для получения дополнительной информации из базы данных.
В данном случае количество серверных вызовов сведено к минимуму за счёт предварительной подготовки параметров.Большое количество текущих серверных вызовов может свидетельствовать о неоптимальном программном коде.
Если цель серверного вызова, созданного внутри цикла – получить какую-либо информацию из базы данных, то данная операция включает в себя запрос в цикле. А это очень негативно влияет на производительность всей системы в целом.Действие 4. Выполнение обработки данных.
Когда предполагается выполнение одной и той же обработки данных из нескольких участков программного кода, разумно этот код поместить в самостоятельную процедуру или функцию. Остаётся только решить, под какой директивой её написать.
Та-дам!
Для копирования у нас есть ксерокс. Но куда его поставить? На сторону клиента или сервера? Под какой директивой его разместить?
Как было озвучено ранее – любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.
Но что произойдёт, если потребность в копировании возникнет на стороне сервера? Например, для подготовки данных, передаваемых на сторону клиента, потребуется сделать копию? Напомню – процесс серверной части не имеет возможности самостоятельно инициировать клиентские вызовы.
Вроде бы результат достигнут – и с сервера, и с клиента доступно копирование. Но для того, чтобы получить копию данных, используемых на клиенте, приходится делать серверный вызов. А это опять ведет к лишней нагрузке на соединение и временным затратам.
Не углубляясь в детали, отметим, что метод, описанный под данной директивой управления, создаётся в двух копиях – и на стороне клиента, и на стороне сервера. Это позволяет выполнить необходимые действия там, где появилась потребность в них (клиент/сервер), без лишних серверных вызовов.
С точки зрения выполнения программы результат будет одинаков. Но объяснение «почему так не надо делать» – это уже совершенно другая тема…
Вместо заключения
В данной статье мы на наглядных примерах рассмотрели влияние различных директив компиляции на такое явление системы «1С:Предприятие 8», как серверный вызов. Как видно, основная причина для выбора правильной директивы – производительность транспортировки данных между клиентской и серверной частью.
Придерживайтесь при разработке следующих правил:
- По возможности не передавайте контекст формы на сторону сервера
- Минимизируйте количество текущих серверных вызовов
- Длительные и ресурсоёмкие задачи запускайте на выполнение на стороне сервера (при возможности – в фоновом режиме).
Учитывайте потребность в доступности тех или иных видов данных, обоснованность передачи управления и не стесняйтесь при необходимости дробить процедуры и функции. И будет Вашему серверному вызову всегда легко, а Вы от пользователей Вашей программы получите «молчаливую благодарность»!
Так ли это важно думать об оптимизации? Тут имеет смысл вспомнить одну историю.Программист Иван при доработке 1С на своём предприятии сделал ошибку в выборе директивы компиляции. Из-за неё длительность одного из серверных вызовов была больше возможной на полсекунды.
Пользователей, применяющих этот функционал, – 25 человек, и каждый из них за рабочий день в среднем совершает 110 таких операций. Всего впустую за рабочий месяц потрачено 28875 секунд (21 рабочий день * 25 человек * 110 операций * 0,5 секунды) = 8,02 часов.
Иван, каково тебе осознавать, что за месяц ты задолжал своему предприятию целый рабочий день?
Читайте также: