Общие модули 1С — объект метаданных конфигурации 1С 8.3 и 8.2, который хранит в себе программный код, который часто вызывается в конфигурации. Функцию/процедуру можно вызвать из любого места конфигурации (если она экспортная).

Как использовать общий модуль

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

Типичный пример общего модуля — обработка проведения по какому-то регистру, получение количества разницы рабочих дней, пересчет курсов валют, пересчет количества/цены/суммы в табличной части и другие функции.

Свойства общих модулей

Одно из основных особенностей общих модулей от других модулей — нельзя объявлять общие переменные.

Получите 267 видеоуроков по 1С бесплатно:

Рассмотрим подробнее палитру свойств общего модуля:

• Глобальный — если флаг установлен, функции и процедуры из этого модуля становятся доступны в глобальном контексте. Т.е. их можно вызвать в любом месте конфигурации, обращаясь без названия общего модуля. Однако добавляется условие — название процедур и функций в этом общем модуле должны быть уникальны в рамках глобального контекста.
• Сервер — процедуры и функции данного общего модуля могут быть выполнены на сервере.
• Внешнее соединение — программные коды данного общего модуля могут быть выполнены при подключении внешним источником (например, COM).
• Клиент (управляемое приложение) — процедуры и функции данного общего модуля могут быть использованы в толстом клиенте в режиме управляемого приложения.
• Клиент (обычное приложение) — программные коды данного общего модуля могут быть использованы в толстом клиенте в режиме обычного приложения.
• Вызов сервера — флаг, разрешающий на клиенте использовать процедуры и функции из этого общего модуля.
• — если установлена Истина, в этом общем модуле будет отключена проверка прав доступа.
• Повторное использование — определяет настройки возвращаемых значений, если опция включена, то после первого выполнения система запомнит значение для данных входных параметров и будет возвращать уже готовое значение. Может принимать следующие значения: не используется — отключение, на время вызова — на время выполнения определенной процедуры, на время сеанса — пока пользователь не закрыл сеанс (программу).

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте

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

1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:

2.1. Серверные общие модули предназначены для размещения серверных процедур и функций, не доступных для использования из клиентского кода. В них реализуется вся внутренняя серверная бизнес-логика приложения.
Для корректной работы конфигурации в режимах внешнего соединения, управляемого и обычного приложений, серверные процедуры и функции следует размещать в общих модулях с признаками:

• Сервер (флажок Вызов сервера сброшен),
• Клиент (обычное приложение) ,
• Внешнее соединение .

В таком случае гарантируется возможность вызова серверных процедур и функций с параметрами мутабельных типов (например, СправочникОбъект , ДокументОбъект и т.п.). Как правило, это:

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

Серверные общие модули называются по общим правилам именования объектов метаданных.
Например: РаботаСФайлами , ОбщегоНазначения

В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс «Сервер» .
Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер .

2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
Такие процедуры и функции размещаются в общих модулях с признаком:

• Сервер (флажок Вызов сервера установлен)

Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом «ВызовСервера» .
Например: РаботаСФайламиВызовСервера

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

См. также: Ограничение на установку признака «Вызов сервера» у общих модулей

2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность , определенную только для клиента) и имеют признаки:

• Клиент (управляемое приложение )
• Клиент (обычное приложение)

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

Клиентские общие модули именуются с постфиксом «Клиент» .
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент

См. также: минимизация кода, выполняемого на клиенте

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

• Клиент (управляемое приложение)
• Сервер (флажок Вызов сервера сброшен)
• Клиент (обычное приложение)
• Внешнее соединение

Общие модули этого вида именуются с постфиксом «КлиентСервер» .
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиентСервер

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

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

3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.

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

В новых версиях конфигураций системы 1С:Предприятие многие функции и процедуры переместились из модулей объектов (документов, справочников и т.д.) в модули менеджера. Рассмотрим различия между этими двумя модулями.

Согласно теории объектно-ориентированного программирования, методы объектов делятся на две группы: статические и простые. Простые методы имеют доступ только к конкретному экземпляру класса. Статические методы не имеют доступа к данным объектов, а работают с классом в целом.

Если перевести все это в термины системы 1С:Предприятие, то Модуль объекта содержит простые методы. Для их использования необходимо сначала получить конкретный объект: элемент справочника, документа и т.п. Модуль менеджера содержит статические методы. Для его использования нет необходимости отдельно получать каждый конкретный объект, он позволяет работать со всей коллекцией сразу.

Модуль объекта может иметь процедуры и функции, которые можно использовать извне. Для этого такая процедура или функция обозначается словом Экспорт.

Функция НоваяФункция () Экспорт

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

Пер= Объект. НоваяФункция() ;

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

Перем НоваяПеременная Экспорт

ЭлементСправочника= Справочники. Номенклатура. НайтиПоКоду("000000001" ) ;
Объект= ЭлементСправочника. ПолучитьОбъект() ;
Объект. НоваяПеременная= ) ;

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

Модуль менеджера имеет все те же возможности, разница лишь в том, что для его использования не нужно получать конкретный объект, модуль менеджера позволяет работать со всей коллекцией объектов определенного типа.

Процедура НоваяПроцедура () Экспорт

ЭлементСправочника= Справочники. Номенклатура. НоваяПроцедура() ;

Или для переменной:

Перем НоваяПеременная Экспорт

ЭлементСправочника= Справочники. Номенклатура. НоваяПеременная;

Рассмотрим отличия в применении модуля объекта и модуля менеджера на примере процедуры создания печатной формы документа.

При использовании модуля объекта код будет выглядеть следующим образом:

Функция ПечатьДокумента (Ссылка) Экспорт
//В эту функцию необходимо передать ссылку на конкретный документ
Возврат ТабДок;
КонецФункции

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

&НаКлиенте
Процедура Печать(Команда)
ТабДок = ПечатьНаСервере() ;
ТабДок. Показать() ;
КонецПроцедуры
&НаСервере
Функция ПечатьНаСервере()
Док = РеквизитФормыВЗначение("Объект" ) ;
Возврат Док. ПечатьДокумента(Объект. Ссылка) ;
КонецФункции

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

С точки зрения производительности гораздо лучше использовать модуль менеджера, когда это возможно. В нашем примере решение задачи будет выглядеть следующим образом.
Функция ПечатьНаСервере()
Возврат Документы. НашДокумент. ПечатьДокумента(МассивСсылок) ;
КонецФункции

В случае использования модуля менеджера, процедуру печати можно вызывать как из формы документа, так и из формы списка, передавая в массиве ссылки на несколько документов. При этом системе не нужно получать каждый документ из массива, что значительно экономит системные ресурсы.

Так когда же использовать модуль объекта, а когда модуль менеджера?

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

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

Обычно программный модуль состоит из трех разделов:

• область объявления переменных ;
• область описания процедур и функций ;
• основной текст программы .

Пример структуры программного модуля:

//***************** ОБЛАСТЬ ОБЪЯВЛЕНИЯ ПЕРЕМЕННЫХ **********************

Перем Фамилия Экспорт; //это глобальная переменная
Перем Имя , Отчество ; //это переменная модуля
Перем ФИО ; //это тоже переменная модуля и к ней можно обращаться

//из любой процедуры и функции нашего модуля

//*************** ОБЛАСТЬ ОПИСАНИЯ ПРОЦЕДУР И ФУНКЦИЙ ****************

Процедура Процедура1 ()
Перем Итог ; //Итог это локальная переменная (переменная процедуры)

Итог = Фамилия + " "+ Имя + " "+ Отчество ;

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

Функция Функция1 ()

// операторы функции

Возврат(Фамилия + " "+ Имя );

КонецФункции

//******************* ОСНОВНОЙ ТЕКСТ ПРОГРАММЫ ***********************

Фамилия = "Иванов";
Имя = "Иван";
Отчество = "Иванович";

//******************************************************************************

В конкретном программном модуле любая из областей может отсутствовать.
Область объявления переменных размещается от начала текста модуля до первого оператора Процедура или оператора Функция или любого исполняемого оператора. В этом разделе могут находиться только операторы объявления переменных Перем .

Область описания процедур и функций размещается от первого оператора Процедура или оператора Функция до любого исполняемого оператора вне тела описания процедур или функций.

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

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

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

Контекст выполнения модулей делится на клиентский и серверный. Кроме того, некоторые программные модули могут быть скомпилированы как на стороне клиента, так и на стороне сервера.

Модуль приложения (управляемого или обычного)

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

В модуле приложения могут располагаться все 3 раздела – объявления переменных, описания процедур и функций, а так же основной текст программы. Модуль приложения компилируется на стороне клиента, что сильно ограничивает нас в использовании многих типов данных. Расширить контекст модуля приложения можно за счет методов общих модулей, для которых установлено свойство «Вызов сервера». Все переменные и методы программного модуля приложения, помеченные как экспортные, будут доступны в любом модуле конфигурации, работающем на стороне клиента. Однако, как бы ни было это заманчиво, не следует размещать здесь большое количество процедур и функций. Чем больше в данном модуле находится кода, тем длительнее время компиляции, а, следовательно, и время запуска приложения.

Как уже отмечалось выше, модуль приложения обрабатывает события запуска и завершения приложения. Для обработки каждого из этих событий в модуле приложения существует пара обработчиков Перед… и При… Отличия между заключается в следующем: при выполнении кода в обработчике Перед… действие еще не свершилось и мы можем отказаться от его выполнения. Для этого предназначен параметр Отказ. В обработчиках При.. действие уже свершилось, и отказаться от запуска приложения или выхода из него мы не можем.

Модуль внешнего соединения

• может содержать все 3 области
• располагается в корневом разделе конфигурации

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

Как и в модуле приложения, здесь доступны все три области: объявления переменных, описания процедур и функций, а так же основной текст программы. Главное отличие от модуля приложения заключается в том, что в режиме com- соединения вся работа с информационной базой происходит на стороне сервера, поэтому модуль внешнего соединения компилируется на стороне сервере. Соответственно в нем не доступны экспортные переменные и методы общих клиентских модулей.

Модуль сеанса

• выполняется на стороне сервера
• располагается в корневом разделе конфигурации

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

В модуле сеанса существует одно единственное событие «УстановкаПараметровСеанса», которое выполняется самым первым, даже раньше события модуля приложения ПередНачаломРаботыСистемы. В нем не доступны раздел объявления переменных и раздел основной программы. А так же нельзя объявлять экспортные методы. Модуль компилируется на стороне сервера.

Общие модули

• может содержать область описания процедур и функций
• выполняется на стороне сервера или клиента (зависит от настроек модуля)
• располагается в ветке дерева объектов конфигурации «Общие» - «Общие модули»

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

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

Хорошим тоном будет не использовать флаг «Глобальный» повсеместно. Это сократит время запуска приложения, а также улучшит читаемость кода (конечно если общий модуль имеет вполне осмысленное название);
- не желательно использовать больше одного флага компиляции. Методов, которые необходимо выполнять в разных контекстах не так много, и если все же такие методы потребуются, то для них можно выделить отдельный общий модуль;
- флаг «Вызов сервера» имеет смысл, только если модуль компилируется «На сервере». Поэтому все остальные флаги компиляции стоит снять во избежание различных проблем;
- если в методах модуля происходит массовая обработка данных, чтение и запись в базу данных, то для увеличения скорости работы лучше отключить контроль прав доступа, выставив флаг «Привилегированный». Этот режим доступен только для общих модулей, компилируемых на сервере.

Модуль формы

• может содержать все 3 области
• выполняется на стороне сервера и клиента

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

Структура управляемой формы содержит раздел объявления переменных, описания процедур и функций и основной текст программы (выполняется в момент инициализации формы). К стандартным событиям формы можем обратиться через список ожидаемых процедур и функций формы (Ctrl+Alt+P) , либо через палитру свойств самой формы.

Если у формы назначен основной реквизит, то в модуле формы становятся доступны свойства и методы прикладного объекта, используемого в качестве основного реквизита.

Модуль объекта

• может содержать все 3 области
• выполняется на стороне сервера

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

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

Модуль менеджера объекта

• может содержать все 3 области
• выполняется на стороне сервера

Модуль менеджера объектов появился только начиная с версии 1С 8.2. Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность объекта за счет введения (написания) процедур и функций, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации. Модуль менеджера объектов позволяет размещать общие процедуры и функции для данного объекта и обращаться к ним из вне, например, из обработки (конечно, если эта процедура или функция будет с ключевым словом Экспорт). Что это нам дает нового? В общем-то, ничего, кроме упорядочивания процедур по объектам и хранения их в отдельных местах - Модулях менеджеров объектов. Мы можем с таким же успехом эти процедуры и функции помещать в общих модулях, но 1С советует общие процедуры и функции объектов размещать в Модуле менеджера объектов. Примеры использования процедур и функций Модуля менеджеров объектов: первоначальное заполнение отдельных реквизитов справочника или документа по определенным условиям, проверка заполнения реквизитов справочника или документа по определенным условиям и т.д.

Модуль команды

• может содержать раздел описания процедур и функций
• выполняется на стороне клиента

Команды – это объекты, подчиненные прикладным объектам или конфигурации в целом. У каждой команды есть модуль команды, в котором можно описать предопределенную процедуру ОбработкаКоманды() для выполнения этой команды.

Что такое модули и для чего собственно они предназначены? В модуле располагается программный код. Причем, стоит отметить, что в отличие от платформы 7.7, где код мог располагаться и в свойствах элементов формы и в ячейках таблиц макета, в платформе 8.х любая строчка кода должна располагаться в каком-либо модуле. Обычно модуль состоит из трех разделов - это раздел описания переменных, раздел описания процедур и функций, а так же раздел основной программы. Такая структура характерна практически для всех модулей платформы, за некоторым исключением. В некоторых модулях нет раздела описания переменных и раздела основной программы. Например, Модуль сеанса и любой Общий модуль.

Контекст выполнения модулей, в общем случае, делится на клиентский и серверный. Кроме того некоторые модули могут быть скомпилированы как на стороне клиента, так и на стороне сервера. А некоторые исключительно на стороне сервера или на стороне клиента. Итак:

Модуль приложения

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

В платформе 8.2 существует два различных модуля приложения. Это модуль Обычного приложения и модуль Управляемого приложения. Они срабатывают при запуске различных клиентов. Так модуль управляемого приложения срабатывает при запуске веб-клиента, тонкого клиента и толстого клиента в режиме управляемого приложения. А модуль обычного приложения срабатывает при запуске толстого клиента в режиме обычного приложения.

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

Как уже отмечалось выше, модуль приложения обрабатывает события запуска и завершения приложения. Для обработки каждого из этих событий в модуле приложения существует пара обработчиков Перед… и При… Отличия между ними таково, что при выполнении кода в обработчике Перед… действие еще не свершилось и мы можем отказаться от его выполнения. Для этого предназначен параметр Отказ. В обработчиках При.. действие уже свершилось, и отказаться от запуска приложения или выхода из него мы не можем.

Модуль внешнего соединения

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

Как и в модуле приложения, здесь доступны разделы описания переменных, методов и раздел основной программы. Так же можно объявлять экспортные переменные и методы. Отличие заключается в том, что в режиме com- соединения вся работа с информационной базой происходит на стороне сервера, поэтому модуль внешнего соединения компилируется исключительно на сервере. Соответственно в нем не доступны экспортные переменные и методы общих клиентских модулей.

Модуль сеанса

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

В модуле сеанса существует единственное событие «УстановкаПараметровСеанса», которое выполняется самым первым, даже раньше события модуля приложения ПередНачаломРаботыСистемы. В нем не доступны раздел объявления переменных и раздел основной программы. А так же нельзя объявлять экспортные методы. Модуль компилируется на стороне сервера.

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

Общие модули

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

• Хорошим правилом будет не использовать флаг «Глобальный» повсеместно. Это сократит время запуска приложения, а также улучшит читаемость кода (конечно если общий модуль имеет вполне осмысленное название).
• Не желательно использовать больше одного флага компиляции. Методов, которые необходимо выполнять в разных контекстах не так много, и если все же такие методы потребуются, то для них можно выделить отдельный общий модуль.
• Флаг «Вызов сервера» имеет смысл, только если модуль компилируется «На сервере». Поэтому все остальные флаги компиляции стоит снять во избежание различных проблем.
• Если в методах модуля происходит массовая обработка данных, чтение и запись в базу данных, то для увеличения скорости работы лучше отключить контроль прав доступа, выставив флаг «Привилегированный». Этот режим доступен только для общих модулей, компилируемых на сервере.

Модуль формы

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

Модуль объекта

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

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

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

Модуль менеджера объекта

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

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

Условные обозначения на схеме: О.М. Клиент - Клиентский общий модуль; О.М. Сервер - Серверный общий модуль; М.Ф. Клиент - Клиентские процедуры модуля формы; М.Ф. Сервер - Серверные процедуры модуля формы.