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

Как да използвате споделения модул

Добра практика е процедура или функция да се постави в общ модул, ако се извиква на повече от едно място. Първо, ако дадена процедура е коригирана, тя трябва да бъде коригирана само на едно място. Второ, постига по-голям ред в кода.

Типичен пример за често срещан модул е ​​обработката на осчетоводяване по някакъв регистър, получаване на размера на разликата в работни дни, преобразуване на валутни курсове, преизчисляване на количество/цена/сума в табличен раздел и други функции.

Общи свойства на модула

Една от основните разлики между споделените модули и другите модули е, че не можете да декларирате споделени променливи.

Вземете 267 1C видео уроци безплатно:

Нека разгледаме по-отблизо палитрата със свойства на общия модул:

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

Ако започвате да изучавате 1C програмиране, препоръчваме нашия безплатен курс (не забравяйте

1.1. Създават се общи модули за изпълнение на процедури и функции, които се комбинират по определени критерии. По правило процедурите и функциите на една конфигурационна подсистема (продажби, покупки) или процедури и функции с подобна функционалност (работа с низове, общо предназначение) се поставят в един общ модул.

1.2. Когато разработвате споделени модули, трябва да изберете един от четирите контекста за изпълнение на код:

2.1. Общи модули на сървъраса предназначени за хостване на сървърни процедури и функции, които не са достъпни за използване от клиентски код. Те изпълняват цялата вътрешна сървърна бизнес логика на приложението.
За да работи конфигурацията правилно във външна връзка, управляваните и редовни режими на приложение, сървърните процедури и функции трябва да бъдат поставени в общи модули със следните характеристики:

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

В този случай се гарантира, че сървърните процедури и функции могат да бъдат извикани с променливи параметри на тип (напр. DirectoryObject, DocumentObjectи др.). Като правило това е:

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

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

В някои случаи може да се добави постфикс, за да се предотвратят конфликти на имена със свойства на глобалния контекст. "сървър".
Например: ScheduledTasksServer, Сървър за обмен на данни.

2.2. Общи модули на сървъра, които да бъдат извикани от клиентасъдържа сървърни процедури и функции, достъпни за използване от клиентски код. Те съставляват клиентския API на сървъра на приложения.
Такива процедури и функции се поставят в общи модули с атрибута:

• Сървър(клетка за отметка Обаждане до сървъракомплект)

Общите модули на сървъра, които трябва да бъдат извиквани от клиента, се именуват според общите правила за именуване на обекти с метаданни и трябва да бъдат именувани с постфикс "Сървърно обаждане".
Например: Работа с файлове Извикване на сървъра

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

Вижте също:Ограничение за задаване на флага "Server call" за общи модули

2.3. Клиентски споделени модулисъдържат клиентска бизнес логика (функционалност, дефинирана само за клиента) и имат следните характеристики:

• Клиент (управлявано приложение)
• Клиент (редовно приложение)

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

Общите модули на клиента се именуват с постфикс "клиент".
Например: WorkFilesClient, Клиент с общо предназначение

Вижте също: минимизиране на кода от страна на клиента

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

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

Често срещаните модули от този вид се именуват с постфикс "Клиентски сървър".
Например: WorkFilesClient, ClientServer с общо предназначение

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

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

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

За да се направи разлика между общите модули на една подсистема, които са създадени за изпълнение на процедури и функции, изпълнявани в различни контексти, се препоръчва да им се дадат постфикси, описани по-рано в параграфи. 2.1-2.4.

В новите версии на системните конфигурации на 1C:Enterprise много функции и процедури са преместени от обектни модули (документи, директории и т.н.) към модули на мениджър. Нека да разгледаме разликите между тези два модула.

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

Ако преведем всичко това в термините на системата 1C: Enterprise, тогава Обектен модулсъдържа прости методи. За да ги използвате, първо трябва да получите конкретен обект: елемент от директория, документ и т.н. Мениджър модулсъдържа статични методи. За да го използвате, не е необходимо да получавате отделно всеки конкретен обект, той ви позволява да работите с цялата колекция наведнъж.

Обектен модулможе да има процедури и функции, които могат да се използват външно. За да направите това, такава процедура или функция се обозначава с думата Експортиране.

Функция NewFunction() Експортиране

За да използвате такава функция от обектен модул, първо трябва, като имате препратка към необходимия обект, да го получите с помощта на функцията GetObject().

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

По същия начин можете да създавате нови променливи, които могат да се използват от различни конфигурационни обекти.

Променлива Нова Променлива Експортиране

DirectoryItem = Директории. Номенклатура. FindByCode("000000001" ) ;
Обект = Елемент на директория. GetObject() ;
Предмет. Нова променлива=) ;

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

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

Процедура NewProcedure() Експортиране

DirectoryItem = Директории. Номенклатура. НоваПроцедура() ;

Или за променлива:

Променлива Нова Променлива Експортиране

DirectoryItem = Директории. Номенклатура. новаПроменлива;

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

Когато използвате обектния модул, кодът ще изглежда така:

Функция PrintDocument (Link) Export
// Тази функция трябва да бъде предадена връзка към конкретен документ
Върнете TabDoc;
Крайни функции

Във формуляра на документа трябва да създадете процедура, която да предаде връзка към документа към функцията за печат.

&AtClient
Процедура Печат (команда)
TabDoc = PrintOnServer() ;
TabDoc. Покажи() ;
EndProcedure
&На сървъра
Функция PrintOnServer()
Doc = FormAttributeToValue("Object") ;
Върнете Док. PrintDocument(Object. Link) ;
Крайни функции

Недостатъкът на този метод е, че ви позволява да отпечатате само един обект. Ако трябва да отпечатате няколко документа наведнъж, тогава трябва да получите всеки от тях и след това да извикате функцията от обектния модул. Това изисква значителни системни ресурси, тъй като при получаване на обект той се вписва изцяло в RAM паметта.

От гледна точка на производителността е много по-добре да използвате мениджърския модул, когато е възможно. В нашия пример решението на проблема ще изглежда така.
Функция PrintOnServer()
Документи за връщане. Нашият документ. PrintDocument(ArrayReferences) ;
Крайни функции

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

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

Всичко зависи от задачата. Ако препратка към обект е достатъчна за неговото изпълнение (например задача за печат), тогава е по-добре да използвате модула на мениджъра. Ако задачата е да промените данните, например попълване на документ, тогава трябва да го получите и да използвате обектния модул.

Програмните модули съдържат изпълним код на езика 1C, който е необходим, за да се отговори по определен начин на действията на системата или потребителя, когато инструментите за визуално развитие не са достатъчни. Също така в програмните модули можем да опишем нашите собствени методи (процедури и функции).

Обикновено софтуерният модул се състои от три секции:

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

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

//******************** ОБЛАСТ НА ДЕКЛАРАЦИЯ НА ПРОМЕНИ *************************

Рем Експорт на фамилно име; / /това е глобална променлива
Име на променлива, отчество; // това е модулна променлива
Промяна на името; // това също е модулна променлива и може да бъде достъпна

//от всяка процедура и функция на нашия модул

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

Процедура Процедура1 ()
Променлива Общо ; / /Total е локална променлива (променлива на процедурата)

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

EndProcedure

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

// Функционални изрази

Връщане(Фамилия + " " + Име );

Крайни функции

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

Фамилия = "Иванов";
Име = "Иван";
Средно име = "Иванович";

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

В конкретен програмен модул може да липсва някоя от областите.
Обхват на декларацията на променливасе поставя от началото на текста на модула до първия оператор на процедурата или оператора на функцията или който и да е изпълним оператор. Този раздел може да съдържа само изрази за декларация на променливи.

Област на описание на процедурите и функциитесе поставя от първия оператор на процедура или оператор на функция към всеки изпълним оператор извън тялото на декларация на процедура или функция.

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

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

Всеки отделен програмен модул се възприема от системата като цяло, така че всички процедури и функции на програмния модул се изпълняват в един контекст.

Контекстът на изпълнение на модулите е разделен на клиентски и сървърен контексти. Освен това някои софтуерни модули могат да бъдат компилирани както от страна на клиента, така и от страна на сървъра.

Приложен модул (управляван или обикновен)

Приложният модул описва процедурите (обработващите) на събития, които се инициализират в началото и в края на системата. Например, когато стартирате приложение, можете да актуализирате някои конфигурационни данни и когато излезете, можете да попитате дали изобщо трябва да излезете от програмата. В допълнение, този модул прихваща събития от външно оборудване, като търговско или фискално оборудване. Струва си да се отбележи, че модулът на приложението се изпълнява само в случай на интерактивно стартиране на приложението, тоест когато се стартира прозорецът на програмата. Това не се случва, ако приложението се стартира в режим com връзки.
В платформата 1C 8 има два различни модула за приложение. Това са модулът за общо приложение и модулът за управлявано приложение. Те се задействат при стартиране на различни клиенти. Например, модулът за управлявано приложение се задейства при стартиране на уеб клиента, тънък клиенти дебел клиент в режим на управлявано приложение. И обикновеният модул за приложение се задейства, когато дебелият клиент се стартира в нормален режим на приложение. Настройката за режим на стартиране на приложението е зададена в конфигурационното свойство "Основен режим на стартиране".

Приложният модул може да съдържа всичките 3 раздела - декларации на променливи, описания на процедури и функции, както и основния текст на програмата. Модулът на приложението се компилира от страна на клиента, което силно ни ограничава да използваме много видове данни. Можете да разширите контекста на модул на приложение с методите на споделените модули, които имат зададено свойство Call Server. Всички променливи и методи на модула на приложната програма, маркирани като експортиране, ще бъдат налични във всеки конфигурационен модул от страна на клиента. Въпреки това, колкото и примамливо да е, не бива да поставяте голям брой процедури и функции тук. Колкото повече код има в даден модул, толкова по-дълго е времето за компилация и, следователно, времето за стартиране на приложението.

Както бе отбелязано по-горе, модулът на приложението обработва началните и крайните събития на приложението. За обработка на всяко от тези събития в модула на приложението има няколко манипулатора Преди ... и Когато ... Разликите между тях са както следва: когато кодът в манипулатора Преди ... се изпълни, действието има все още не е проведено и можем да откажем да го изпълним. За това е опцията Отказ. В On манипулаторите действието вече е извършено и не можем да откажем да стартираме приложението или да излезем от него.

Модул за външна връзка

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

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

Както в модула на приложението, тук са достъпни и трите области: декларации на променливи, описания на процедури и функции, както и основният текст на програмата. Основната разлика от модула на приложението е, че в режим на комуникационна връзка цялата работа с информационната база се извършва от страна на сървъра, така че модулът за външна връзка се компилира от страна на сървъра. Съответно в него не са налични експортни променливи и методи на общи клиентски модули.

сесиен модул

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

Това е високоспециализиран модул, предназначен единствено за инициализиране на параметрите на сесията. Защо трябваше да направите свой собствен модул за това? Използването му се дължи на факта, че самото приложение може да се стартира в различни режими (което води до изпълнение или на управляван модул на приложението, или на редовно приложение, или на външен модул за връзка), а параметрите на сесията трябва да бъдат инициализирани независимо от режима на стартиране. За да не пишем един и същ програмен код и в трите модула, ни трябваше допълнителен модул, който се изпълнява независимо от режима на стартиране на приложението.

Има едно единствено събитие "SetSessionParameters" в модула на сесията, което се задейства много първо, дори преди събитието PreSystemBegin на модула на приложението. Той няма раздел за декларация на променлива и главен програмен раздел. Освен това е невъзможно да се декларират методи за износ. Модулът се компилира от страна на сървъра.

Общи модули

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

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

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

Добра практика е флагът „Глобално“ да не се използва навсякъде. Това ще намали времето за стартиране на приложението, както и ще подобри четливостта на кода (разбира се, ако общият модул има напълно смислено име);
- Не е препоръчително да използвате повече от един флаг за компилация. Няма толкова много методи, които трябва да се изпълняват в различни контексти и ако все пак такива методи са необходими, тогава за тях може да се разпредели отделен общ модул;
- флагът "Server call" има смисъл само ако модулът е компилиран "On the server". Следователно всички други флагове за компилация трябва да бъдат премахнати, за да се избегнат различни проблеми;
- ако в методите на модула има масова обработка на данни, четене и запис в базата данни, тогава за увеличаване на скоростта на работа е по-добре да деактивирате контрола на достъпа, като зададете флага "Привилегирован". Този режим е достъпен само за споделени модули, компилирани на сървъра.

Модул за формуляри

• може да съдържа всичките 3 области
• извършва от страна на сървъра и клиента

Модулът на формуляра е предназначен да обработва действията на потребителя с този формуляр (обработване на събитието за щракване върху бутона, промяна на атрибута на формуляра и т.н.). Има и събития, свързани директно със самата форма (например нейното отваряне или затваряне). Модулите на управлявани и редовни форми се различават основно по това, че модулът управлявана формаясно разделени по контекст. Всяка процедура или функция трябва да има директива за компилиране. Ако директивата за компилиране не е посочена, тогава тази процедура или функция се изпълнява от страна на сървъра. В обичайната форма целият код се изпълнява от страна на клиента.

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

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

Обектен модул

• може да съдържа всичките 3 области
• извършва от страна на сървъра

Този модул е ​​наличен за повечето конфигурационни обекти и е предназначен като цяло за обработка на събития, пряко свързани с обекта. Например събития на запис и изтриване на обекти, проверка дали са попълнени детайлите на обект, публикуване на документ и т.н.

Някои събития на обектния модул дублират събития от модул на формата. Например събития, свързани със записа. Трябва обаче да се разбере, че събитията от модула на формата ще се изпълняват само върху конкретната форма на обекта, тоест когато се отвори конкретната форма. И събитията на обектния модул ще бъдат извикани във всеки случай, дори по време на работата на програмата с обекта. Следователно, ако имате нужда от методи, свързани с обект, без да сте обвързани с конкретна форма на обекта, тогава е по-добре да използвате обектния модул за това.

Модул за управление на обекти

• може да съдържа всичките 3 области
• извършва от страна на сървъра

Модулът за управление на обекти се появи само от версия 1C 8.2. Мениджърският модул съществува за всички обекти на приложението и е предназначен да управлява този обект като конфигурационен обект. Мениджърският модул ви позволява да разширите функционалността на обект чрез въвеждане (записване) на процедури и функции, които не се отнасят до специфичен екземпляр на обекта на базата данни, а до самия конфигурационен обект. Модулът за управление на обекти ви позволява да поставите общи процедури и функции за даден обект и да получите достъп до тях отвън, например от обработка (разбира се, ако тази процедура или функция е с ключовата дума Export). Какво ново ни дава това? Общо взето нищо друго освен организиране на процедури по обекти и съхраняването им на отделни места - модули за управление на обекти. Ние също можем да поставим тези процедури и функции в общи модули, но 1C съветва да поставите общи процедури и функции на обекти в модула за управление на обекти. Примери за използване на процедурите и функциите на модула за управление на обекти: първоначално попълване на отделни детайли на директория или документ при определени условия, проверка на попълването на детайли на директория или документ при определени условия и др.

Команден модул

• може да съдържа раздел, описващ процедури и функции
• изпълнява се от страна на клиента

Командите са обекти, подчинени на обектите на приложението или конфигурацията като цяло. Всяка команда има команден модул, в който можете да опишете предварително дефинирана процедура CommandProcess() за изпълнение на тази команда.

Какво представляват модулите и за какво точно са предназначени? Модулът съдържа програмния код. Освен това, заслужава да се отбележи, че за разлика от платформата 7.7, където кодът може да бъде разположен както в свойствата на елементите на формуляра, така и в клетките на таблиците за оформление, в платформата 8.x всеки ред от код трябва да бъде разположен в някакъв модул. Обикновено модулът се състои от три раздела - раздел за описание на променливи, раздел за описание на процедури и функции и раздел за основната програма. Тази структура е типична за почти всички платформени модули, с някои изключения. Някои модули нямат раздел за декларация на променлива и основна секция на програмата. Например модул за сесия и всеки общ модул.

Контекстът на изпълнение на модулите обикновено се разделя на клиентски и сървърни контексти. Освен това някои модули могат да бъдат компилирани както от страна на клиента, така и от страна на сървъра. А някои са чисто от страна на сървъра или от страна на клиента. Така:

Приложен модул

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

В платформата 8.2 има два различни модула за приложение. Това са модулът за общо приложение и модулът за управлявано приложение. Те се задействат при стартиране на различни клиенти. Ето как модулът за управлявано приложение се задейства, когато уеб клиентът, тънкият клиент и дебелият клиент се стартират в режим на управлявано приложение. И обикновеният модул за приложение се задейства, когато дебелият клиент се стартира в нормален режим на приложение.

В модула на приложението могат да се поставят всички раздели - описания на променливи, процедури и функции, както и описания на основната програма. Модулът на приложението се компилира от страна на клиента, така че това силно ни ограничава в наличността на много видове данни. Можете да разширите контекста на модул на приложение с методите на споделените модули, които имат зададено свойство Call Server. Всички променливи и методи, които са маркирани като експортиране, ще бъдат налични във всеки конфигурационен модул от страна на клиента. Въпреки това, колкото и изкушаващо да е, не поставяйте твърде много методи тук. Колкото повече код съдържа, толкова по-дълго е времето за компилация и, следователно, времето за стартиране на приложението, което е много досадно за потребителите.

Както бе отбелязано по-горе, модулът на приложението обработва началните и крайните събития на приложението. За обработка на всяко от тези събития в модула на приложението има няколко манипулатора Преди ... и Когато ... Разликата между тях е, че когато кодът в манипулатора Преди ... се изпълни, действието все още не е се случи и можем да откажем да го изпълним. За това е опцията Отказ. В On манипулаторите действието вече е извършено и не можем да откажем да стартираме приложението или да излезем от него.

Модул за външна връзка

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

Както в модула на приложението, тук са достъпни секции за описание на променливи, методи и раздел за основната програма. Можете също да декларирате експортни променливи и методи. Разликата е, че в режима на com-връзка цялата работа с информационната база се извършва от страна на сървъра, така че модулът за външна връзка се компилира изключително на сървъра. Съответно в него не са налични експортни променливи и методи на общи клиентски модули.

сесиен модул

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

В модула на сесията има едно събитие „SetSessionParameters“, което се задейства много първо, дори преди събитието PreSystemBegin на модула на приложението. Той няма раздел за декларация на променлива и главен програмен раздел. Освен това е невъзможно да се декларират методи за износ. Модулът се компилира от страна на сървъра.

Избягвайте изкушението този модул да се изпълнява всеки път, когато приложението стартира, и поставете в него код, който не е пряко свързан с инициализацията на параметрите на сесията. Това се дължи на факта, че манипулаторът на SetSessionParameters може да бъде извикан многократно по време на работа на системата. Например, това се случва, когато имаме достъп до неинициализирани параметри. И въпреки че е възможно да се хване момента на първото стартиране на това събитие (RequiredParameters има тип Undefined), трябва да се отбележи, че този модул е ​​компилиран в привилегирован режим, т.е. той не контролира правата за достъп. И вторият момент, все още не можем да бъдем сто процента сигурни, че системата ще бъде стартирана. Изведнъж модулът на приложението ще се провали и ние се опитваме да извършим някакво действие с базата данни.

Общи модули

Модулите са предназначени да опишат някои общи алгоритми, които ще бъдат извиквани от други конфигурационни модули. Общият модул не съдържа раздел за декларация на променлива и главен програмен раздел. Можете да декларирате методи за експортиране в него, чийто контекст за достъпност ще бъде определен от флаговете за компилация. Поради факта, че разделът за деклариране на променливи не е наличен, не е възможно да се дефинират глобални променливи в споделените модули. За да направите това, трябва да използвате функциите на общите модули с кеширане на връщана стойност или модул на приложение. Трябва да се има предвид, че дори ако свойството повторно използване на споделения модул е ​​настроено на „За продължителността на сесията“, тогава в този случай животът на кешираните стойности не надвишава 20 минути от момента на последния им достъп .
Поведението на споделения модул зависи от зададените параметри (глобални или не, различни флагове за компилация, дали е налично извикване на сървъра и т.н.). В тази статия няма да разглеждаме всички видове настройки, както и поведенчески характеристики и клопки, които възникват, когато флаговете на свойствата са зададени неразумно. Това е тема за отделна статия. Нека се спрем само на няколко точки, които трябва да се спазват при задаване на флагове:

• Добро правило е да не използвате знамето „Глобално“ навсякъде. Това ще намали времето за стартиране на приложението, както и ще подобри четливостта на кода (разбира се, ако общият модул има напълно смислено име).
• Не е препоръчително да използвате повече от един флаг за компилация. Няма толкова много методи, които трябва да се изпълняват в различни контексти и ако все пак такива методи са необходими, тогава за тях може да се разпредели отделен общ модул.
• Флагът "Call Server" има значение само ако модулът е компилиран "На сървъра". Следователно всички други флагове за компилация трябва да бъдат премахнати, за да се избегнат различни проблеми.
• Ако в методите на модула има масова обработка на данни, четене и запис в базата данни, тогава, за да увеличите скоростта на работа, е по-добре да деактивирате контрола на достъпа, като зададете флага "Привилегирован". Този режим е достъпен само за споделени модули, компилирани на сървъра.

Модул за формуляри

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

Обектен модул

Този модул е ​​типичен за много конфигурационни обекти и е предназначен по принцип за обработка на събития от обект. Например събитията на писане и изтриване на обекти, събитието на публикуване на документи и т.н.

Някои събития на обектния модул дублират събития от модул на формата. Например събития, свързани със записа. Трябва обаче да се разбере, че събитията от модула на формуляра ще се изпълняват само върху конкретен обект на формуляр. Като цяло може да има няколко от тези форми. И събитията на обектния модул ще бъдат извикани във всеки случай, дори по време на работата на програмата с обекта. Следователно, ако е необходимо да се изпълни някакъв код във всички случаи, тогава е по-добре да използвате събитие на обектен модул за това.

Обектният модул се компилира изключително на сървъра. В него можете да дефинирате експортни променливи и методи, които ще бъдат налични в други конфигурационни модули. С помощта на тези свойства и методи можем значително да разширим функционалността на обекта.

Модул за управление на обекти

Този модул съществува за много конфигурационни обекти. Основната цел на този модул е ​​да предефинира стандартното събитие за избор, което се случва в момента на въвеждане по ред и да разшири функционалността на мениджъра. Модулът се компилира от страна на сървъра. Възможно е да се дефинират експортни свойства и методи. Извикването на експортните методи на мениджъра не изисква създаването на самия обект.

Към всичко изброено по-горе можете да добавите снимка на някои конфигурационни модули и методи за взаимни извиквания на методи в режим на управлявано приложение. Стрелката показва посоката, в която можете да отидете, за да извикате съответния метод. Както се вижда от диаграмата, контекстът на сървъра е напълно затворен. Но от контекста на клиента е възможен достъп до сървърните методи.

Символи на схемата: O.M. Клиент - общ модул на клиента; O.M. Сървър - общ модул на сървъра; М.Ф. Клиент - Клиентски процедури на модула за формуляр; М.Ф. Сървър - Сървърни процедури на модула за формуляри.