Modulele generale 1C- un obiect al metadatelor de configurare 1C 8.3 și 8.2, care stochează codul programului care este adesea numit în configurație. O funcție/procedură poate fi apelată de oriunde în configurație (dacă este exportată).

Cum se utilizează modulul partajat

Este o bună practică să puneți o procedură sau o funcție într-un modul comun dacă este apelată în mai multe locuri. În primul rând, dacă o procedură este corectată, trebuie corectată doar într-un singur loc. În al doilea rând, obține o ordine mai mare în cod.

Un exemplu tipic de modul comun este procesarea înregistrării în funcție de un registru, obținerea sumei diferenței în zile lucrătoare, conversia cursurilor de schimb, recalcularea cantității/prețului/suma în secțiunea tabelară și alte funcții.

Proprietăți generale ale modulului

Una dintre principalele diferențe dintre modulele partajate și alte module este că nu puteți declara variabile partajate.

Obțineți 267 de lecții video 1C gratuit:

Să aruncăm o privire mai atentă la paleta de proprietăți a modulului comun:

• Global- dacă flag-ul este setat, funcțiile și procedurile din acest modul devin disponibile în context global. Acestea. ele pot fi apelate oriunde în configurație fără numele modulului comun. Cu toate acestea, se adaugă o condiție - numele procedurilor și funcțiilor din acest modul comun trebuie să fie unice în contextul global.
• Server- Procedurile și funcțiile acestui modul comun pot fi executate pe server.
• Îmbinare exterioară- codurile de program ale acestui modul comun pot fi executate atunci când sunt conectate printr-o sursă externă (de exemplu, COM).
• Client (aplicație gestionată)— Procedurile și funcțiile acestui modul comun pot fi utilizate într-un client gros în modul aplicație gestionată.
• Client (aplicație obișnuită)— codurile de program ale acestui modul comun pot fi utilizate în clientul gros în modul normal de aplicație.
• Apel pe server- un flag care permite clientului să utilizeze procedurile și funcțiile din acest modul comun.
• - dacă este setată la True, verificarea drepturilor de acces va fi dezactivată în acest modul comun.
• Reutilizați— definește setările pentru valorile returnate, dacă opțiunea este activată, apoi după prima execuție sistemul își va aminti valoarea pentru acești parametri de intrare și va returna o valoare gata făcută. Poate lua următoarele valori: nefolosit- închide, la momentul apelului- pe durata unei anumite proceduri, în timpul sesiunii- până când utilizatorul a închis sesiunea (programul).

Dacă începeți să învățați programarea 1C, vă recomandăm cursul nostru gratuit (nu uitați

1.1. Modulele comune sunt create pentru a implementa proceduri și funcții care sunt combinate în funcție de anumite criterii. De regulă, procedurile și funcțiile unui subsistem de configurare (vânzări, achiziții) sau procedurile și funcțiile cu funcționalitate similară (lucrarea cu șiruri, scop general) sunt plasate într-un singur modul comun.

1.2. Când dezvoltați module partajate, ar trebui să alegeți unul dintre cele patru contexte de execuție a codului:

2.1. Module comune pentru server sunt destinate să găzduiască proceduri și funcții de server care nu sunt disponibile pentru utilizare din codul client. Ei implementează toată logica de afaceri a serverului intern a aplicației.
Pentru ca configurația să funcționeze corect în modurile de conexiune externă, aplicațiile gestionate și obișnuite, procedurile și funcțiile serverului trebuie plasate în module comune cu următoarele caracteristici:

• Server(Caseta de bifat Apel pe server scăzut),
• Client (aplicație obișnuită),
• Îmbinare exterioară.

În acest caz, este garantat că procedurile și funcțiile serverului pot fi apelate cu parametrii de tip mutabil (de exemplu, DirectoryObject, DocumentObject etc.). De regulă, acesta este:

• handlere pentru abonamente la evenimente de documente, directoare etc., care iau ca parametru o valoare mutabilă (obiect).
• proceduri și funcții de server, la care un obiect este trecut ca parametru din module de directoare, documente etc., precum și din module cu abonamente la evenimente.

Modulele comune ale serverului sunt denumite conform regulilor generale de denumire a obiectelor de metadate.
De exemplu: Lucrul cu fișierele, Scop general

În unele cazuri, un postfix poate fi adăugat pentru a preveni conflictele de nume cu proprietățile contextului global. "Server".
De exemplu: ScheduledTasksServer, Server de schimb de date.

2.2. Modulele comune ale serverului care urmează să fie apelate de la client conțin proceduri și funcții de server disponibile pentru utilizare din codul client. Ele formează API-ul client al serverului de aplicații.
Astfel de proceduri și funcții sunt plasate în module comune cu atributul:

• Server(Caseta de bifat Apel pe server a stabilit)

Modulele comune ale serverului care urmează să fie apelate de la client sunt denumite conform regulilor generale de denumire a obiectelor de metadate și trebuie denumite cu un postfix „Apel pe server”.
De exemplu: Lucrul cu fișiereApelarea serverului

Rețineți că procedurile și funcțiile de export din astfel de module obișnuite nu trebuie să conțină parametrii de tip modificabili ( DirectoryObject, DocumentObject etc.), deoarece transferul lor de la (sau către) codul clientului este imposibil.

Vezi si:Restricții privind setarea steagului „Apel server” pentru modulele comune

2.3. Module partajate de client conţin logica de afaceri a clientului (funcţionalitate definită numai pentru client) şi au următoarele caracteristici:

• Client (aplicație gestionată)
• Client (aplicație obișnuită)

Excepția este atunci când procedurile și funcțiile client ar trebui să fie disponibile numai în modul aplicație gestionată (numai în modul aplicație obișnuită sau numai în modul de ieșire). În astfel de cazuri, o altă combinație a acestor două caracteristici este acceptabilă.

Modulele comune ale clientului sunt denumite cu un postfix "Client".
De exemplu: WorkFilesClient, Utilizare generalăClient

Vezi și: minimizarea codului client-side

2.4. În unele cazuri, este posibil să se creeze module comune client-server cu proceduri și funcții, al căror conținut este același atât pe server, cât și pe client. Astfel de proceduri și funcții sunt plasate în module comune cu caracteristici:

• Client (aplicație gestionată)
• Server(Caseta de bifat Apel pe server scăzut)
• Client (aplicație obișnuită)
• Îmbinare exterioară

Modulele comune de acest fel sunt denumite cu un postfix "Client server".
De exemplu: WorkFilesClient, General PurposeClientServer

În general, nu este recomandat să se definească module comune pentru server și client (aplicație gestionată) în același timp. Funcționalitatea definită pentru client și pentru server este recomandată a fi implementată în diferite module comune - vezi p. 2.1 și 2.3. O astfel de separare explicită a logicii de afaceri client și server este dictată de considerentele de creștere a modularității soluției aplicate, simplificarea controlului dezvoltatorului asupra interacțiunii client-server și reducerea riscului de erori din cauza diferențelor fundamentale în cerințele pentru dezvoltarea client și server. cod (necesitatea de a minimiza codul executat pe client, disponibilitate diferită a obiectelor și a tipurilor de platformă etc.). Totodata, trebuie sa tinem cont de inevitabila crestere a numarului de module comune in configuratie.

Un caz special de module mixte client-server sunt modulele de formă și comandă, care sunt concepute special pentru a implementa logica de afaceri a serverului și a clientului într-un singur modul.

3.1. Numele modulelor comune se recomandă să fie construite conform regulilor generale de denumire a obiectelor de metadate. Numele unui modul comun trebuie să se potrivească cu numele unui subsistem sau al unui mecanism separat ale cărui proceduri și funcții le implementează. Se recomandă evitarea unor astfel de cuvinte uzuale precum „Proceduri”, „Funcții”, „Handlers”, „Modul”, „Funcționalitate”, etc. în denumirile modulelor comune. și aplicați-le doar în cazuri excepționale, când dezvăluie mai pe deplin scopul modulului.

Pentru a face distincția între modulele comune ale unui subsistem, care sunt create pentru a implementa proceduri și funcții efectuate în contexte diferite, se recomandă să le acordați postfixele descrise mai devreme în paragrafe. 2.1-2.4.

În noile versiuni ale configurațiilor sistemului 1C:Enterprise, multe funcții și proceduri au fost mutate de la modulele obiect (documente, directoare etc.) la modulele manager. Să aruncăm o privire la diferențele dintre aceste două module.

Conform teoriei programării orientate pe obiecte, metodele obiectelor sunt împărțite în două grupe: statice și simple. Metodele simple au acces doar la o anumită instanță a clasei. Metodele statice nu au acces la datele obiectului, ci operează pe clasă ca întreg.

Dacă traducem toate acestea în termenii sistemului 1C: Enterprise, atunci Modul obiect conţine metode simple. Pentru a le folosi, trebuie mai întâi să obțineți un obiect anume: un element al unui director, document etc. Modulul Manager conţine metode statice. Pentru a-l folosi, nu este nevoie să obțineți separat fiecare obiect specific, vă permite să lucrați cu întreaga colecție simultan.

Modul obiect pot avea proceduri și funcții care pot fi utilizate extern. Pentru a face acest lucru, o astfel de procedură sau funcție este desemnată prin cuvânt Export.

Funcția NewFunction() Export

Pentru a utiliza o astfel de funcție dintr-un modul de obiect, trebuie mai întâi, având o referință la obiectul necesar, să-l obțineți folosind funcția GetObject().

Per= Obiect. NewFunction() ;

În mod similar, puteți crea variabile noi care pot fi utilizate din diferite obiecte de configurare.

Variabil NewVariable Export

DirectoryItem = Directoare. Nomenclatură. FindByCode("000000001");
Obiect = element director. GetObject() ;
Un obiect. NewVariable= );

Astfel, este posibilă completarea procedurilor standard, funcțiilor și proprietăților (variabilelor) obiectelor. Astfel de variabile sunt dinamice, nu sunt stocate în baza de informații și există doar în timpul lucrului cu obiectul primit.

Modulul Manager are toate aceleași caracteristici, singura diferență este că nu trebuie să obțineți un anumit obiect pentru a-l folosi, modulul de manager vă permite să lucrați cu întreaga colecție de obiecte de un anumit tip.

Procedură NewProcedure() Export

DirectoryItem = Directoare. Nomenclatură. NewProcedure() ;

Sau pentru o variabilă:

Variabil NewVariable Export

DirectoryItem = Directoare. Nomenclatură. newVariable;

Să luăm în considerare diferențele în utilizarea modulului obiect și a modulului manager pe exemplul procedurii de creare a unei forme tipărite a unui document.

Când utilizați modulul obiect, codul ar arăta astfel:

Funcția PrintDocument (Link) Export
//Această funcție trebuie să primească un link către un anumit document
Return TabDoc;
EndFunctions

Pe formularul de document, trebuie să creați o procedură care ar transmite un link către document către funcția de imprimare.

&AtClient
Imprimare procedură (comandă)
TabDoc = PrintOnServer() ;
TabDoc. Spectacol() ;
EndProcedure
&Pe server
Funcția PrintOnServer()
Doc = FormAttributeToValue("Obiect");
Întoarceți Doc. PrintDocument(Object. Link) ;
EndFunctions

Dezavantajul acestei metode este că vă permite doar să imprimați un singur obiect. Dacă trebuie să tipăriți mai multe documente simultan, atunci trebuie să obțineți fiecare dintre ele și apoi să apelați funcția din modulul obiect. Acest lucru necesită resurse semnificative de sistem, deoarece atunci când un obiect este primit, acesta se încadrează în întregime în RAM.

Din punct de vedere al performanței, este mult mai bine să utilizați modulul manager ori de câte ori este posibil. În exemplul nostru, soluția problemei va arăta astfel.
Funcția PrintOnServer()
Retur documentele. Documentul nostru. PrintDocument(ArrayReferences) ;
EndFunctions

În cazul utilizării modulului manager, procedura de tipărire poate fi apelată atât din formularul de document, cât și din formularul de listă, trecând link-uri către mai multe documente din matrice. În acest caz, sistemul nu trebuie să primească fiecare document din matrice, ceea ce economisește semnificativ resursele sistemului.

Deci, când ar trebui să utilizați modulul obiect și când ar trebui să utilizați modulul manager?

Totul depinde de sarcină. Dacă o referire la un obiect este suficientă pentru execuția acestuia (de exemplu, o sarcină de imprimare), atunci este mai bine să utilizați modulul manager. Dacă sarcina este de a schimba datele, de exemplu, completarea unui document, atunci trebuie să îl obțineți și să utilizați modulul obiect.

Modulele software conțin cod executabil în limbajul 1C, care este necesar pentru a răspunde într-un anumit mod la acțiunile sistemului sau utilizatorului atunci când instrumentele de dezvoltare vizuală nu sunt suficiente. Tot în modulele de program ne putem descrie propriile metode (proceduri și funcții).

De obicei, un modul software este format din trei secțiuni:

• zona de declarare a variabilei;
• zona de descriere a procedurii și a funcției;
• textul principal al programului.

Un exemplu de structură a unui modul de program:

//******************** AREA DE DECLARAȚIE VARIABILĂ ************************

Export Nume Rem; / /aceasta este o variabilă globală
Nume variabilă, patronimic; //aceasta este o variabilă de modul
Schimba numele; //aceasta este, de asemenea, o variabilă de modul și poate fi accesată

//din orice procedură și funcție a modulului nostru

//*************** ZONA DE DESCRIERE A PROCEDURII ȘI A FUNCȚIILOR ****************

Procedura Procedura1 ()
Variabila Total ; / /Total este o variabilă locală (variabilă de procedură)

Total = Prenume + "" + Prenume + " "+ Patronimic;

EndProcedure

Funcție Funcție 1 ()

// instrucțiuni de funcție

Return(Nume + " " + Prenume);

EndFunctions

//**************************** TEXTUL PRINCIPAL AL ​​PROGRAMULUI ******************** *

Prenume = „Ivanov”;
Nume = "Ivan";
Al doilea nume = „Ivanovici”;

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

Într-un anumit modul de program, oricare dintre zone poate fi absentă.
Domeniul de aplicare al declarației variabile este plasat de la începutul textului modulului până la prima instrucțiune a Procedurei sau a instrucțiunii Function sau a oricărei instrucțiuni executabile. Această secțiune poate conține numai declarații de variabile.

Zona de descriere a procedurilor și funcțiilor este plasat de la prima instrucțiune a unei instrucțiuni Procedure sau Function la orice instrucțiune executabilă din afara corpului unei proceduri sau declarații de funcție.

Zona principală a textului programului este plasat de la prima instrucțiune executabilă în afara corpului de proceduri sau funcții până la sfârșitul modulului. Această secțiune poate conține numai instrucțiuni executabile. Zona textului principal al programului este executată în momentul inițializării modulului. De obicei, în secțiunea principală a programului, are sens să plasați instrucțiuni pentru a inițializa variabile cu niște valori specifice care trebuie alocate înainte de primul apel la procedurile sau funcțiile modulului.

Modulele de program sunt amplasate în acele locuri din configurație care pot necesita descrierea unor algoritmi de operare specifici. Acești algoritmi ar trebui să fie concepuți ca proceduri sau funcții care vor fi apelate de sistemul însuși în situații predeterminate (de exemplu, la deschiderea unui formular de referință, la clic pe un buton dintr-o casetă de dialog, la schimbarea unui obiect etc.).

Fiecare modul de program separat este perceput de sistem ca un întreg, astfel încât toate procedurile și funcțiile modulului de program sunt executate într-un singur context.

Contextul de execuție al modulelor este împărțit în contexte client și server. În plus, unele module software pot fi compilate atât pe partea client, cât și pe partea serverului.

Modul de aplicație (gestionat sau obișnuit)

Modulul de aplicație descrie procedurile (de gestionare) a evenimentelor care sunt inițializate la începutul și la sfârșitul sistemului. De exemplu, atunci când porniți o aplicație, puteți actualiza unele date de configurare, iar când ieșiți, puteți întreba dacă ar trebui să părăsiți programul. În plus, acest modul interceptează evenimente din echipamente externe, cum ar fi echipamente de tranzacționare sau fiscale. Este de remarcat faptul că modulul aplicației este executat numai în cazul unei lansări interactive a aplicației, adică atunci când fereastra programului este lansată. Acest lucru nu se întâmplă dacă aplicația este lansată în mod conexiuni com.
Există două module de aplicație diferite în platforma 1C 8. Acestea sunt modulul Aplicație comună și modulul Aplicație gestionată. Acestea sunt declanșate atunci când sunt porniți diferiți clienți. De exemplu, modulul Aplicație gestionată este declanșat atunci când clientul web este lansat, client slabși client gros în modul aplicație gestionată. Și modulul de aplicație obișnuit este declanșat atunci când clientul gros este lansat în modul normal de aplicație. Setarea modului de lansare a aplicației este setată în proprietatea de configurare „Modul de lansare principal”.

Modulul de aplicație poate conține toate cele 3 secțiuni - declarații de variabile, descrieri de proceduri și funcții, precum și textul principal al programului. Modulul de aplicație este compilat pe partea clientului, ceea ce ne împiedică sever să folosim multe tipuri de date. Puteți extinde contextul unui modul de aplicație cu metodele modulelor partajate care au setată proprietatea Call Server. Toate variabilele și metodele modulului de program de aplicație marcate ca export vor fi disponibile în orice modul de configurare de pe partea clientului. Cu toate acestea, oricât de tentant ar fi, nu ar trebui să plasați aici un număr mare de proceduri și funcții. Cu cât există mai mult cod într-un anumit modul, cu atât timpul de compilare este mai lung și, în consecință, timpul de pornire a aplicației.

După cum sa menționat mai sus, modulul de aplicație se ocupă de evenimentele de început și de sfârșit ale aplicației. Pentru a gestiona fiecare dintre aceste evenimente în modulul de aplicație, există câțiva handlere Înainte de ... și Când ... Diferențele dintre ele sunt următoarele: atunci când codul din handler Înainte de ... este executat, acțiunea are încă nu a avut loc și putem refuza să o executăm. Pentru asta este opțiunea Refuz. În handlerele On, acțiunea a avut deja loc și nu putem refuza lansarea aplicației sau ieșirea din ea.

Modul de conectare extern

• poate conține toate cele 3 zone
• situat în secțiunea rădăcină a configurației

Scopul modulului este similar cu scopul modulului de aplicație. Se ocupă de evenimentele de început și de sfârșit ale aplicației. Modulul de conexiune externă este declanșat atunci când aplicația este lansată în modul de conectare com. Procesul de îmbinare exterioară în sine nu este un proces interactiv. În acest mod, programul funcționează cu baza de informatii iar fereastra aplicației nu se deschide, ceea ce impune anumite restricții privind utilizarea metodelor destinate lucrului interactiv. În acest mod, nu puteți utiliza apeluri la formulare de dialog, avertismente și mesaje către utilizator etc. Pur și simplu nu vor alerga.

Ca și în modulul de aplicație, toate cele trei zone sunt disponibile aici: declarații de variabile, descrieri ale procedurilor și funcțiilor, precum și textul principal al programului. Principala diferență față de modulul de aplicație este că, în modul de conectare com, toate lucrările cu baza de informații au loc pe partea serverului, astfel încât modulul de conexiune externă este compilat pe partea serverului. În consecință, variabilele de export și metodele modulelor client comune nu sunt disponibile în acesta.

modul de sesiune

• efectuate pe partea serverului
• situat în secțiunea rădăcină a configurației

Acesta este un modul foarte specializat conceput exclusiv pentru a inițializa parametrii sesiunii. De ce a trebuit să-ți faci propriul modul pentru asta? Utilizarea sa se datorează faptului că aplicația în sine poate fi lansată în diverse moduri (ceea ce duce la executarea fie a unui modul de aplicație gestionată, fie a unei aplicații obișnuite, fie a unui modul de conexiune externă), iar parametrii de sesiune trebuie inițializați indiferent de modul de lansare. Pentru a nu scrie același cod de program în toate aceste trei module, aveam nevoie modul suplimentar, care se execută indiferent de modul de pornire al aplicației.

Există un singur eveniment „SetSessionParameters” în modulul de sesiune, care este declanșat foarte întâi, chiar înainte de evenimentul PreSystemBegin al modulului de aplicație. Nu are o secțiune de declarații variabile și o secțiune principală de program. Și, de asemenea, este imposibil să declarați metode de export. Modulul este compilat pe partea serverului.

Module generale

• poate conține o zonă pentru descrierea procedurilor și funcțiilor
• executat pe server sau pe partea client (depinde de setările modulului)
• situat în ramura arborelui de obiecte de configurare „General” - „Module generale”

Modulele comune au scopul de a descrie niște algoritmi comuni care vor fi apelați din alte module de configurare. Modulul general nu conține zone de declarare variabile și corpul programului. Puteți declara în el metode de export, a căror disponibilitate va fi determinată de setările modulului (pe ce parte se execută: pe partea de server sau de client). Din cauza faptului că secțiunea de declarare a variabilelor nu este disponibilă, nu este posibilă definirea variabilelor globale în modulele partajate. Puteți utiliza modulul de aplicație pentru aceasta.

Comportamentul modulului partajat depinde de parametrii setați (globali sau nu, diferite steaguri de compilare, dacă este disponibil un apel de server etc.). Iată câteva sfaturi pentru configurarea modulelor partajate:

Este o practică bună să nu folosiți steagul „Global” peste tot. Acest lucru va reduce timpul de pornire a aplicației, precum și va îmbunătăți lizibilitatea codului (desigur, dacă modulul comun are un nume complet semnificativ);
- Nu este recomandabil să folosiți mai mult de un flag de compilare. Nu există atât de multe metode care trebuie efectuate în contexte diferite și, dacă astfel de metode sunt totuși necesare, atunci poate fi alocat un modul comun separat pentru acestea;
- flag-ul „Apel server” are sens numai dacă modulul este compilat „Pe server”. Prin urmare, toate celelalte steaguri de compilare ar trebui eliminate pentru a evita diverse probleme;
- dacă în metodele modulului există o prelucrare în masă a datelor, citirea și scrierea în baza de date, atunci pentru a crește viteza de lucru, este mai bine să dezactivați controlul accesului prin setarea steagului „Privilegiat”. Acest mod este disponibil numai pentru modulele partajate compilate pe server.

Modul formular

• poate conține toate cele 3 zone
• efectuate pe partea de server și client

Modulul formular este conceput pentru a gestiona acțiunile utilizatorului cu acest formular (manevrarea evenimentului de clic pe butonul, modificarea atributului formularului etc.). Există și evenimente legate direct de formularul în sine (de exemplu, deschiderea sau închiderea acestuia). Modulele de formulare gestionate și regulate diferă în primul rând prin faptul că modulul formă gestionată clar separate de context. Fiecare procedură sau funcție trebuie să aibă o directivă de compilare. Dacă directiva de compilare nu este specificată, atunci această procedură sau funcție este executată pe partea serverului. În forma obișnuită, tot codul este executat pe partea clientului.

Structura formularului gestionat conține o secțiune de declarații variabile, descrieri ale procedurilor și funcțiilor și corpul programului (executat când formularul este inițializat). Putem accesa evenimente de formular standard prin lista de proceduri și funcții așteptate ale formularului (Ctrl+Alt+P), sau prin paleta de proprietăți a formularului în sine.

Dacă atributul principal este atribuit formularului, atunci proprietățile și metodele obiectului aplicație utilizat ca atribut principal devin disponibile în modulul formular.

Modul obiect

• poate conține toate cele 3 zone
• efectuate pe partea serverului

Acest modul este disponibil pentru majoritatea obiectelor de configurare și este destinat, în general, procesării evenimentelor legate direct de obiect. De exemplu, evenimente de înregistrare și ștergere a obiectelor, verificarea completării detaliilor unui obiect, postarea unui document etc.

Unele evenimente din modulul obiect dublează evenimentele din modulul formular. De exemplu, evenimente legate de înregistrare. Cu toate acestea, trebuie să se înțeleagă că evenimentele modulului de formular vor fi executate numai pe forma specifică a obiectului, adică atunci când formularul specific este deschis. Și evenimentele modulului obiect vor fi apelate în orice caz, chiar și în momentul lucrului programului cu obiectul. Prin urmare, dacă aveți nevoie de metode asociate cu un obiect fără a fi legat de o formă specifică a obiectului, atunci este mai bine să utilizați modulul obiect pentru aceasta.

Modulul de gestionare a obiectelor

• poate conține toate cele 3 zone
• efectuate pe partea serverului

Modulul de gestionare a obiectelor a apărut abia începând cu versiunea 1C 8.2. Modulul manager există pentru toate obiectele aplicației și este conceput pentru a gestiona acest obiect ca obiect de configurare. Modulul manager vă permite să extindeți funcționalitatea unui obiect prin introducerea de proceduri și funcții (scriere) care nu se aplică unei anumite instanțe a obiectului bazei de date, ci obiectului de configurare însuși. Modulul de gestionare a obiectelor vă permite să plasați proceduri și funcții comune pentru un anumit obiect și să le accesați din exterior, de exemplu, din procesare (desigur, dacă această procedură sau funcție este cu cuvântul cheie Export). Ce ne dă nou asta? În general, nimic altceva decât organizarea procedurilor pe obiecte și stocarea lor în locuri separate - Module Object Manager. Putem plasa la fel de bine aceste proceduri și funcții în module comune, dar 1C recomandă plasarea procedurilor și funcțiilor comune ale obiectelor în Modulul Object Manager. Exemple de utilizare a procedurilor și funcțiilor Modulului Object Managers: completarea inițială a detaliilor individuale ale unui director sau document în anumite condiții, verificarea completării detaliilor unui director sau document în anumite condiții etc.

Modul de comandă

• poate conține o secțiune care descrie proceduri și funcții
• executate pe partea clientului

Comenzile sunt obiecte subordonate obiectelor aplicației sau configurației în ansamblu. Fiecare comandă are un modul de comandă în care puteți descrie o procedură CommandProcess() predefinită pentru executarea acelei comenzi.

Ce sunt modulele și la ce anume sunt destinate? Modulul conține codul programului. Mai mult, este de remarcat faptul că, spre deosebire de platforma 7.7, unde codul ar putea fi localizat atât în ​​proprietățile elementelor de formular, cât și în celulele tabelelor de layout, în platforma 8.x, orice linie de cod trebuie să fie localizată. într-un anumit modul. De obicei, un modul este format din trei secțiuni - o secțiune pentru descrierea variabilelor, o secțiune pentru descrierea procedurilor și funcțiilor și o secțiune pentru programul principal. Această structură este tipică pentru aproape toate modulele platformei, cu unele excepții. Unele module nu au o secțiune de declarare a variabilelor și o secțiune principală a programului. De exemplu, Modulul Sesiune și orice Modul General.

Contextul de execuție al modulelor este în general împărțit în contexte client și server. În plus, unele module pot fi compilate atât pe partea client, cât și pe partea serverului. Și unele sunt doar pe partea serverului sau pe partea clientului. Asa de:

Modul de aplicație

Modulul este conceput pentru a surprinde momentele lansării aplicației (încărcarea configurației) și finalizarea acesteia. Și în evenimentele corespunzătoare, puteți aranja procedurile de verificare. De exemplu, la începutul aplicației, actualizați orice date de referință de configurare, la sfârșitul lucrării, întrebați dacă merită să o lăsați, poate că ziua de lucru nu s-a încheiat încă. În plus, interceptează evenimente din echipamente externe, cum ar fi echipamente de tranzacționare sau fiscale. Este de remarcat faptul că modulul de aplicație interceptează evenimentele descrise doar în cazul unei lansări interactive. Acestea. atunci când fereastra programului în sine este creată. Acest lucru nu se întâmplă dacă aplicația este lansată în modul com-connection.

Există două module de aplicație diferite în platforma 8.2. Acestea sunt modulul Aplicație comună și modulul Aplicație gestionată. Acestea sunt declanșate atunci când sunt porniți diferiți clienți. Acesta este modul în care se declanșează modulul aplicației gestionate atunci când clientul web, clientul subțire și clientul gros sunt lansate în modul aplicație gestionată. Și modulul de aplicație obișnuit este declanșat atunci când clientul gros este lansat în modul normal de aplicație.

Toate secțiunile pot fi plasate în modulul de aplicație - descrieri ale variabilelor, proceduri și funcții, precum și descrieri ale programului principal. Modulul de aplicație este compilat pe partea clientului, așa că acest lucru ne limitează sever în disponibilitatea multor tipuri de date. Puteți extinde contextul unui modul de aplicație cu metodele modulelor partajate care au setată proprietatea Call Server. Toate variabilele și metodele care sunt marcate ca export vor fi disponibile în orice modul de configurare pe partea clientului. Cu toate acestea, oricât de tentant este, nu pune prea multe metode aici. Cu cât conține mai mult cod, cu atât timpul de compilare este mai lung și, în consecință, timpul de pornire a aplicației, ceea ce este foarte enervant pentru utilizatori.

După cum sa menționat mai sus, modulul de aplicație se ocupă de evenimentele de început și de sfârșit ale aplicației. Pentru a gestiona fiecare dintre aceste evenimente în modulul de aplicație, există câțiva handlere Before ... și When ... Diferența dintre ele este că atunci când codul din handler Before ... este executat, acțiunea nu a fost încă a avut loc și putem refuza să o executăm. Pentru asta este opțiunea Refuz. În handlerele On, acțiunea a avut deja loc și nu putem refuza lansarea aplicației sau ieșirea din ea.

Modul de conectare extern

Scopul modulului este similar cu scopul modulului de aplicație. Se ocupă de punctele de început și de sfârșit ale aplicației. Modulul de conexiune externă este declanșat atunci când aplicația este lansată în modul de conectare com. Procesul de îmbinare exterioară în sine nu este un proces interactiv. În acest mod, are loc munca programatică cu infobaza și fereastra aplicației nu se deschide, ceea ce impune anumite restricții privind utilizarea metodelor destinate lucrului interactiv. În acest mod, nu puteți utiliza apeluri din formulare de dialog, mesaje de avertizare etc. Pur și simplu nu vor funcționa.

Ca și în modulul de aplicație, secțiunile pentru descrierea variabilelor, metodelor și o secțiune pentru programul principal sunt disponibile aici. De asemenea, puteți declara variabile și metode de export. Diferența este că, în modul conexiune com, toate lucrările cu baza de informații au loc pe partea serverului, astfel încât modulul de conexiune externă este compilat exclusiv pe server. În consecință, variabilele de export și metodele modulelor client comune nu sunt disponibile în acesta.

modul de sesiune

Acesta este un modul foarte specializat și este destinat exclusiv inițializării parametrilor de sesiune. De ce a trebuit să-ți faci propriul modul pentru asta? Acest lucru se datorează faptului că procesul de inițializare poate necesita executarea unui cod și, în plus, aplicația poate fi lansată sub diferiți clienți (ceea ce duce la executarea diferitelor module de aplicație sau modul de conectare extern), iar parametrii de sesiune trebuie fi inițializat în orice mod de lansare. Prin urmare, a fost necesar un modul suplimentar, care se execută în orice mod de lansare a aplicației.

Există un singur eveniment „SetSessionParameters” în modulul de sesiune, care este declanșat foarte întâi, chiar înainte de evenimentul PreSystemBegin al modulului de aplicație. Nu are o secțiune de declarații variabile și o secțiune principală de program. Și, de asemenea, este imposibil să declarați metode de export. Modulul este compilat pe partea serverului.

Evitați tentația ca acest modul să fie executat de fiecare dată când pornește aplicația și plasați în el cod care nu are legătură directă cu inițializarea parametrilor de sesiune. Acest lucru se datorează faptului că handlerul SetSessionParameters poate fi apelat în mod repetat în timpul funcționării sistemului. De exemplu, acest lucru se întâmplă atunci când accesăm parametri neinițializați. Și deși este posibil să se surprindă momentul primei lansări a acestui eveniment (RequiredParameters are tipul Undefined), totuși, trebuie remarcat că acest modul este compilat în modul privilegiat, adică. nu controlează drepturile de acces. Și al doilea punct, încă nu putem fi sută la sută siguri că sistemul va fi lansat. Dintr-o dată, modulul aplicației va eșua și încercăm să efectuăm o acțiune cu baza de date.

Module generale

Modulele sunt destinate să descrie niște algoritmi comuni care vor fi apelați din alte module de configurare. Modulul general nu conține o secțiune de declarare a variabilelor și o secțiune principală a programului. În el pot fi declarate metode de export, al căror context de accesibilitate va fi determinat de steaguri de compilare. Din cauza faptului că secțiunea de declarare a variabilelor nu este disponibilă, nu este posibilă definirea variabilelor globale în modulele partajate. Pentru a face acest lucru, trebuie să utilizați funcțiile modulelor comune cu memorarea în cache a valorii returnate sau un modul de aplicație. Trebuie avut în vedere faptul că, chiar dacă proprietatea de reutilizare a modulului partajat este setată la „Pentru durata sesiunii”, atunci, în acest caz, durata de viață a valorilor stocate în cache nu depășește 20 de minute din momentul în care au fost accesate ultima dată. .
Comportamentul modulului partajat depinde de parametrii setați (globali sau nu, diferite steaguri de compilare, dacă este disponibil un apel de server etc.). În acest articol, nu vom lua în considerare toate tipurile de setări, precum și caracteristicile comportamentale și capcanele care apar atunci când semnalizatoarele de proprietate sunt setate în mod nerezonabil. Acesta este un subiect pentru un articol separat. Să ne oprim doar la câteva puncte care ar trebui urmate atunci când setați steaguri:

• Este o regulă de bază să nu folosiți steagul „Global” peste tot. Acest lucru va reduce timpul de pornire a aplicației, precum și va îmbunătăți lizibilitatea codului (desigur, dacă modulul comun are un nume complet semnificativ).
• Nu este recomandabil să folosiți mai mult de un semnal de compilare. Nu există atât de multe metode care trebuie efectuate în contexte diferite și, dacă astfel de metode sunt totuși necesare, atunci poate fi alocat un modul comun separat pentru acestea.
• Indicatorul „Call Server” are sens numai dacă modulul este compilat „Pe server”. Prin urmare, toate celelalte steaguri de compilare ar trebui eliminate pentru a evita diverse probleme.
• Dacă în metodele modulului există o prelucrare în masă a datelor, citire și scriere în baza de date, atunci pentru a crește viteza de lucru, este mai bine să dezactivați controlul accesului prin setarea steagului „Privilegiat”. Acest mod este disponibil numai pentru modulele partajate compilate pe server.

Modul formular

Este destinat procesării acțiunilor utilizatorului, de ex. diverse evenimente legate de introducerea datelor și prelucrarea corectitudinii introducerii acestora. Modul formă regulată compilat în întregime pe client. Un modul de formular gestionat, pe de altă parte, este clar delimitat de contextul de execuție, astfel încât toate variabilele și metodele trebuie să aibă o directivă de compilare. Dacă directiva nu este specificată în mod explicit, atunci această variabilă sau metodă va fi compilată pe partea serverului. În modulul formular sunt disponibile secțiuni pentru descrierea variabilelor și metodelor, precum și o secțiune pentru programul principal.

Modul obiect

Acest modul este tipic pentru multe obiecte de configurare și este destinat, în general, procesării evenimentelor obiect. De exemplu, evenimentele de scriere și ștergere a obiectelor, evenimentul de postare de documente etc.

Unele evenimente din modulul obiect dublează evenimentele din modulul formular. De exemplu, evenimente legate de înregistrare. Cu toate acestea, trebuie înțeles că evenimentele modulului formular vor fi executate numai pe un anumit obiect formular. În general, pot exista mai multe dintre aceste forme. Și evenimentele modulului obiect vor fi apelate în orice caz, chiar și în momentul lucrului programului cu obiectul. Prin urmare, dacă este necesar să executați un cod în toate cazurile, atunci este mai bine să utilizați un eveniment de modul obiect pentru aceasta.

Modulul obiect este compilat exclusiv pe server. În acesta, puteți defini variabilele de export și metodele care vor fi disponibile în alte module de configurare. Cu ajutorul acestor proprietăți și metode, putem extinde semnificativ funcționalitatea obiectului.

Modulul de gestionare a obiectelor

Acest modul există pentru multe obiecte de configurare. Scopul principal al acestui modul este de a redefini evenimentul de selecție standard care are loc în momentul introducerii prin linie și de a extinde funcționalitatea managerului. Modulul este compilat pe partea serverului. Este posibil să se definească proprietăți și metode de export. Apelarea metodelor de export ale managerului nu necesită crearea obiectului în sine.

La toate cele de mai sus, puteți adăuga o imagine a unor module de configurare și metode de apeluri reciproce de metodă în modul aplicație gestionată. Săgeata indică direcția în care puteți merge pentru a apela metoda corespunzătoare. După cum se poate vedea din diagramă, contextul serverului este complet închis. Dar din contextul clientului, este posibil să accesezi metode de server.

Simboluri pe schema: O.M. Client - Modul comun Client; O.M. Server - Modul comun server; M.F. Client - Proceduri client ale modulului formular; M.F. Server - Proceduri server ale modulului formular.