Se așteaptă definirea unei proceduri de funcționare înainte. Extinderea modulului. Ok, să facem și acest weekend util
Principala problemă a lucrului cu extensii este evaluarea părtinitoare a numărului de îmbunătățiri viitoare de către dezvoltatori/implementatori. Pe baza premisei „trebuie să schimbăm doar câteva butoane de pe formular”, începe lucrul cu extensii. Numărul de îmbunătățiri este în creștere, extensiile continuă să fie folosite pe baza mesajului „folosim deja extensii, haideți să le folosim în continuare”.
Apoi, este nevoie de a adăuga noi entități la baza de date și de a extinde structura celor existente. Sau schimbați principiul de funcționare al oricărui subsistem tipic. Lucrul cu extensii devine din ce în ce mai dificil sau chiar imposibil. Configurația permite modificarea și începe modificarea „soft” sau „hard” a configurației standard, în funcție de calificările dezvoltatorilor.
Acesta este momentul în care tehnologia ajunge în grădina zoologică. Eterogenitatea, care trăiește deja în sistemul corporativ, își freacă bucuros mâinile, realizând că a câștigat o bună trambulină din claritate și simplitate.
Desigur, în acest moment puteți scăpa de unul dintre animalele din grădina zoologică tehnologică și puteți transfera corect toate modificările configurației. La urma urmei, va trebui să „ai grijă” de două fiare - atât expansiuni, cât și modificări în cea mai standard configurație. Curățați după ei, hrăniți-i, faceți cumva pace unul cu celălalt, astfel încât să nu rupă nimic în procesul de lucru împreună, adăugați încă o linie la lista de cerințe pentru dezvoltatori în posturile vacante Headhunter.
Dintr-un motiv întemeiat, acesta este ceea ce trebuie făcut. Dar Heterogeneity știe că oamenii sunt leneși, le este frică să atingă ceva care măcar cumva funcționează, întotdeauna „nu au timp”, iar conducerea nu este capabilă să evalueze necesitatea refactorizării în acest moment critic pentru abandonarea tehnologiei inutile. Îmbunătățirile aduse modificărilor efectuate prin extensii continuă să fie făcute prin extensii. Îmbunătățirile aduse în configurație continuă să fie făcute în configurație. Principalul inamic al arhitecturii software de întreprindere este ferm înrădăcinat în capul de pont capturat.
În general, este mai bine să vă gândiți cu atenție înainte de a începe să utilizați tehnologie înalt specializată. Dacă există riscul ca structura obiectelor să fie schimbată sau să fie adăugate noi obiecte de bază de date, este nevoie să rulați depanarea frecvent și fără probleme, există oameni care înțeleg cum să modifice inițial configurația fără probleme pentru actualizările ulterioare, atunci este mai bine să decideți imediat să nu creați o grădină zoologică. Nimeni nu a luat module redefinite, modificarea programatică a formularelor și abonamente la evenimente. Dacă compania este mică și este important pentru angajați ca configurația să fie actualizată cu un singur buton acum și întotdeauna în viitor, cu siguranță nu vor fi schimbări majore (chiar sigur?), atunci nu va exista nicio grădină zoologică chiar și cu extensii.
Și, desigur, extensiile sunt bune pentru pluginurile mici. Există exemple de utilizare bună pe IP, când extensiile sunt publicate în locul unui fișier cf cu instrucțiuni pentru comparare și îmbinare. Dar aceasta este din nou o zonă specifică și pentru o utilizare constantă convenabilă este mai bine să transferați funcționalitatea în configurație, astfel încât lansarea în modul întreprindere să nu fie încetinită.
Astăzi vrem să vă spunem despre utilizarea rapoartelor și procesării suplimentare, și în special a extensiilor de configurare în modelul de serviciu. Tehnologiile nu stau pe loc; deservirea bazelor de date 1C în cloud devine un serviciu din ce în ce mai atractiv. Ce trebuie să știți pentru ca funcționalitatea necesară companiei dvs. să fie implementată într-o bază de date închiriată și cum arată acest proces din partea furnizorului de servicii - puteți afla despre acest lucru sub tăietură.
Ce sunt rapoartele externe și procesarea
Tratamentele 1C sunt diferite, dar în orice caz extind funcționalitatea configurației și vă permit să accesați rapid informațiile stocate în baza de date fără a modifica configurația și fără a elimina suportul. Ele pot fi încorporate direct în configurație, adăugate ca extensie de configurare sau pot fi fișiere externe. Pe baza funcționalității, procesarea este împărțită în cele care pot modifica datele și cele care pur și simplu analizează informațiile și afișează rezultatul într-o formă ușor de utilizat (rapoarte). Pentru a nu modifica aspectul standard de tipărire a documentelor, sunt dezvoltate formulare de tipărire externe. De asemenea, procesarea externă poate fi efectuată conform unui program dat pe serverul de aplicații 1C - acestea sunt sarcini de rutină.
Câteva zeci de soluții de procesare au fost dezvoltate în Button, care le permit contabililor noștri să folosească „magie practică”. De exemplu, pentru a analiza corectitudinea contabilității în Buton, se folosește raportul extern „Audit automat al bazei de date”. Tabelele ușor de citit oferă o analiză a 120 de criterii pentru soldurile conturilor și cifra de afaceri, conformitatea datelor din declarațiile fiscale și informațiile contabile, analiza mijloacelor fixe etc.
Un exemplu de formular tipărit extern „contract de împrumut” conform formularului elaborat de avocații noștri. Există cazuri în care un antreprenor ia un împrumut fără dobândă de la compania sa ca persoană fizică sau invers, își transferă fondurile proprii către companie, atunci este posibil să imprime imediat acordul.
Se deschide un formular pentru a completa detaliile necesare:
Și se afișează forma tipărită a contractului:
Folosim procesarea programată (sarcini de rutină), de exemplu, pentru a corecta declarațiile. Butoanele au configurat integrări cu băncile majore și roboții speciali încarcă extrasele direct în 1C. Datorită tehnologiei de învățare automată, procentul de erori în timpul descărcării a fost redus la 3%. Dar, ca întotdeauna, există excepții, de exemplu, clienții care folosesc o schemă de agenție pentru vânzarea de bunuri, în acest caz, regulile pentru efectuarea unui extras bancar sunt individuale; Pentru a nu reprograma robotul pentru un anumit caz, înainte de apariția extensiilor de configurare, a fost folosită o sarcină de rutină pentru a corecta declarația robotului la fiecare 10 minute.
Ce sunt extensiile de configurare
O extensie este o mini-configurație care moștenește obiecte din configurația principală a bazei de date și conține cod cu adăugiri sau corecții la obiecte și module. În acest caz, configurația principală rămâne acceptată, nu este nevoie să activați editarea, ceea ce simplifică foarte mult procesul de actualizare. Mecanismul presupune trei tipuri de utilizare, care, de fapt, sunt indicate în câmpul „Scop” atunci când se creează o extensie:
Componenta centrală a tehnologiei este Manager de servicii, stochează toate informațiile despre abonați, utilizatori, aplicații, baze de informații și conexiunile dintre aceștia, iar cu ajutorul său sunt gestionate procesările externe și extensiile de configurare.
Toate fișierele cu procesare sunt încărcate într-un director special al managerului de servicii. Dar înainte de a încărca un fișier în director, cu alte cuvinte, „publicați-l în serviciu”, acesta trebuie pregătit într-un mod special.
Intocmirea rapoartelor externe si prelucrarea pentru publicare in modelul de serviciu
Un raport sau o procesare suplimentară este creat în configuratorul 1C: Enterprise 8 ca rapoarte și procesare externe standard și salvat într-un fișier cu extensia - .epf (pentru procesare suplimentară) sau .erf (pentru rapoarte suplimentare). Modulul obiect trebuie să aibă proceduri și funcții pentru definirea parametrilor de înregistrare.
Vă rugăm să rețineți că parametrul important este „Versiune”. Dacă ați făcut modificări la o procesare care a fost încărcată anterior în directorul managerului de servicii, asigurați-vă că ați schimbat numărul versiunii, altfel managerul de servicii va refuza încărcarea fișierului. Atunci când elaborați un raport sau o prelucrare, trebuie să țineți cont de faptul că utilizatorii lucrează într-un model de serviciu prin intermediul unui client web (articol bun de pe blogul 1C). Dacă procesarea conține formulare, atunci acestea trebuie să funcționeze în clientul web sub toate browserele web care sunt acceptate de platforma tehnologică 1C: Enterprise 8.
Conform standardelor serviciului 1cfresh.com, un raport sau o procesare suplimentară trebuie să fie pe deplin funcțional atunci când este executat în modul sigur, adică să funcționeze fără accesarea obiectelor externe configurației.
Trebuie pregătit un raport sau o procesare suplimentară pentru a fi încărcat în serviciu ca kit de livrare. Setul de livrare este o arhivă (fișier zip) care conține:
- raport suplimentar sau dosar de procesare;
- fișier manifest xml, care conține metainformații suplimentare necesare managerului de servicii pentru a publica un raport suplimentar sau a-l procesa în serviciu.
Instalarea rapoartelor suplimentare și procesarea în modelul de serviciu
O caracteristică distinctivă a tehnologiei 1C Fresh este că un raport sau o procesare externă nu poate fi încărcat direct în zona de date. Adăugarea poate fi făcută numai de administratorul serviciului prin intermediul managerului de servicii. După ce arhiva zip cu fișierul de procesare este pregătită, aceasta trebuie să fie încărcată în directorul managerului de servicii și instalată pentru un anumit abonat al serviciului. Un abonat la serviciu este un grup de utilizatori uniți după un anumit principiu. În consecință, bazele de informații disponibile unui anumit grup de utilizatori se numesc aplicații pentru abonați.
Aplicațiile pot avea diferite configurații 1C (Contabilitatea Întreprinderii, Managementul Salariilor și Personalului, Managementul companiei noastre etc.), pentru care este posibilă utilizarea în modelul de servicii. Raportarea sau procesarea suplimentară poate fi instalată numai în aplicațiile abonatului care sunt specificate la descărcarea fișierului.
Așa arată formularul de proprietăți pentru un raport suplimentar cu versiuni. Folosind hyperlinkul „Instalare/Eliminare”, ajungem la lista de aplicații și selectăm bazele de date necesare.
După ce procesarea este încărcată și aplicația este selectată, managerul de servicii contactează adresa aplicației și dă comanda de instalare în baza de informații.
Lansăm procesarea conform programului
Când lucrați cu un număr mare de baze de date contabile, unele procesări trebuie efectuate periodic. De exemplu, o dată pe lună sau o dată la câteva minute. De asemenea, este important să se automatizeze operațiunile manuale și de rutină ale utilizatorului. Pentru a face acest lucru, folosim în mod activ sarcinile de rutină.Prelucrarea care se va efectua conform programului nu are formular. Toată logica este scrisă în modulul obiect și arată astfel.
La pregătirea setului de livrare, stabilim un program. Acum procesarea noastră va fi efectuată la fiecare oră.
Mai multe despre extensiile de configurare
În paralel cu rapoartele externe și procesarea care trebuie pregătite și administrate „mod vechi”, am început să folosim în mod activ mecanismul de extindere a configurației. Începând cu platforma 1C Enterprise 8.3.10, acest mecanism ne-a făcut viața destul de ușoară și a făcut posibilă simplificarea adaptării configurațiilor la caracteristicile Buttonului. De exemplu, am scris mai sus despre operațiunile de rutină pentru corectarea documentelor de către roboți care erau lansate o dată la 10 minute. Acum puteți folosi extensia pentru a redefini funcționarea modulelor. Astfel, putem efectua imediat acțiunile necesare atunci când înregistrăm sau postăm un document. Acest lucru este mult mai optim, deoarece coada de sarcini din baza de date nu este înfundată cu acțiuni efectuate la fiecare 10 minute și este mai eficient, deoarece modificările se fac imediat.
Este destul de ușor să pregătiți o nouă extensie. Să ne uităm la procesul de creare a extensiilor folosind exemple specifice.
Pe baza experienței de muncă, liderul în cererile de ajustări este formularul tipărit TORG-12. De exemplu, trebuie să facem o extensie pentru a putea tipări un bon de livrare în valută (în mod implicit poate fi generat doar în ruble).
Deschideți Meniu → Configurare → Extensii de configurare
Creăm o nouă extensie cu scopul „Adaptare”.
Extensia arată ca un arbore de configurare familiar, dar încă fără obiecte. Mai întâi de toate, să adăugăm un nou layout TORG-12, în care am inserat coloane cu sume în valută.
Deoarece factura este tipărită din documentul „Vânzări de bunuri și servicii”, vom adăuga acest document la extensia noastră din configurația principală și vom face modificările de care avem nevoie în modulul manager. Pentru a face acest lucru, selectați „adăugați la extensie” în meniul contextual al implementării.
Acum puteți modifica modulul manager de implementare. Trebuie să adăugăm un nou formular la lista de formulare imprimabile și să completăm sumele valutare.
Pentru a schimba procedurile standard, folosim adnotarea &After, avem nevoie și de câteva funcții proprii și de o procedură.
Să aruncăm o privire mai atentă asupra adnotărilor. În extensii puteți folosi: &Înainte, &După, &În loc (foarte atent). Principiul de funcționare este simplu: vrem ca algoritmii noștri din extensie să fie executați mai întâi, punem adnotarea &Before și indicăm în paranteze numele procedurii din configurația standard. Dacă un modul standard este procesat mai întâi, și apoi al nostru, folosim &After.
Adnotările &Înainte și &După nu pot fi folosite pentru funcții. Prin urmare, dacă trebuie să schimbăm algoritmul unei funcții din configurația principală, folosim adnotarea &În schimb.
Adnotarea &Instead ar trebui folosită cât mai rar posibil, deoarece înlocuiește complet execuția unei proceduri și funcție din configurația principală cu o procedură/funcție de extensie. Cu această metodă de interceptare, procedura/funcția din configurația principală va înceta deloc să fie executată în timp ce extensia este instalată, chiar și actualizarea versiunilor nu va ajuta.
Concluzie
Există multe opinii diferite despre utilizarea extensiilor și a rapoartelor/prelucrărilor externe. Pe baza experienței noastre, amândoi suntem în favoarea extinderii. Aceasta este o tehnologie modernă și mai adaptabilă, are mult mai multe capabilități, iar publicarea lor este mult mai ușoară. Doar partea necesară a codului este plasată în extensie, de asemenea, nu este nevoie să scrieți proceduri și funcții suplimentare pentru a determina parametrii de înregistrare, a urmări versiunile și a crea un kit de livrare.Puteți utiliza mai multe extensii pentru o zonă de date.
Pentru specificul lucrului 1C Fresh în modul de separare a datelor (o configurație, multe zone independente), metoda de extindere este o soluție excelentă.
S-a dovedit a fi destul de relevant :)
Ok, să facem și acest weekend util.
Deci, astăzi este un alt subiect de „operare aplicată a 1C”:
Mecanism de extindere în platformă 8.3.6
Despre ce vorbim?
În platforma 8.3.6, a fost implementat un nou mecanism - un mecanism de extensie care facilitează adaptarea unei soluții de aplicație la un anumit client.
Când utilizați extensii modificarea configurației se realizează într-o nouă entitate- extinderea configurației:
- O extensie este în esență și o configurație, dar cu unele limitări
- Extensia pregătită poate fi conectată la baza de date de lucru a clientului în modul utilizator
- Cel mai important - configurația care se modifică nu trebuie eliminată din suport, adică rămâne tipic, fără modificări
- Actualizarea configurației modificate poate fi efectuată automat de către utilizator
Astfel, clientul primește drept rezultat posibilitate de ameliorare configurații și în același timp - actualizare automată simplă.
Pentru a putea înțelege acest lucru mai în detaliu, publicăm mai multe videoclipuri + PDF pe extensii.
Deci, iată-ne:
Scopul extensiilor de configurare
Videoclipul discută noul mecanism de extindere a configurației care a apărut în platforma 8.3.6. Este destinat perfecționării și adaptării soluțiilor în timpul implementării. În acest caz, clientul primește o simplă actualizare automată a configurației și posibilitatea de a face modificări.
Obiecte care pot fi modificate în extensie
Acest videoclip discută limitările actuale ale mecanismului de extensii. În prezent, doar un număr limitat de obiecte pot fi folosite în extensii.
Lucrul cu extensii în configurator
Acest videoclip discută despre dezvoltarea extensiilor în configurator. Extensia este o configurație, deși oarecum limitată. Lucrul cu extensia se efectuează și în arborele de obiecte metadate. Extensia rezultată poate fi salvată într-un fișier de pe disc.
Împrumut de obiecte
Acest videoclip analizează împrumutarea obiectelor de configurare de bază într-o extensie. Acesta este mecanismul principal necesar pentru a realiza dezvoltarea extensiei în sine. De asemenea, vorbește despre proprietăți controlate, a căror valoare este verificată atunci când extensia este conectată.
Crearea propriilor obiecte într-o extensie de configurare
Acest videoclip explică cum vă puteți crea propriile obiecte în extensie. Lista acestor obiecte este încă limitată - acestea sunt rapoarte, procesare și subsisteme. Dezvoltarea unor astfel de obiecte în extensie se realizează prin analogie cu configurația principală.
Lucrul cu extensii în modul utilizator
Acest videoclip discută cum să conectați o extensie pregătită la baza de date de lucru a unui client. În acest caz, conexiunea se poate face din modul utilizator fără accesarea configuratorului.
Lucrul cu formulare gestionate în extensiile de configurare
Acest videoclip arată cum să lucrați cu formulare gestionate în extensie. Vă rugăm să rețineți că formularul sursă nu se sincronizează automat cu extensia. Explică modul în care sistemul generează aspectul de formular rezultat atunci când este prezentă o extensie.
Modulul de formulare gestionat și manipulatorii de evenimente în extensiile de configurare
Acest videoclip tratează cum să lucrați cu gestionanții de evenimente în formularele de extensie de configurare gestionată.
Este demonstrată ordinea de execuție a handlerelor de evenimente în configurația principală și în extensie.
Implementat în versiunea 8.3.9.1818.
Pe scurt, acum cu ajutorul extensiilor puteți schimba modulele de configurare standard și puteți adăuga propriile module.
Și mai detaliat, puteți schimba orice module, cu excepția modulelor de forme obișnuite:
- module generale;
- Module obiect (modul obiect, modul manager etc.) pentru toate tipurile de obiecte;
- Modul de sesiune;
- Modul de aplicație gestionat;
- Modul de conectare extern;
- module de comandă;
- Module de formulare;
- etc.
Trebuie remarcat faptul că ați putea schimba modulele de formulare gestionate înainte, dar acum am făcut câteva modificări acestui proces.
Interceptare
Puteți intercepta orice metodă standard de configurare, încadrându-le cu propriile metode sau chiar înlocuindu-le în întregime.Manipulatori proprii
Puteți adăuga propriile dvs. de gestionare a evenimentelor de configurare personalizate. Dacă, de exemplu, acestea nu sunt alocate într-o configurație tipică.Module proprii
Vă puteți crea propriile module comune în extensie.Apel
Și, în sfârșit, puteți apela orice metodă de configurare standard din extensia dvs.
Când împrumutați și extindeți un modul de configurare standard, modulul dvs. de extindere va fi în același spațiu de nume ca și modulul standard. Prin urmare, în timp ce vă aflați într-un modul de extensie, puteți accesa direct orice variabile și metode ale modulului generic.
Dacă vă aflați într-un alt modul care există în extensie, atunci propriile dvs. variabile exportate și metode ale modulului de extensie vă vor fi disponibile. Deoarece sunt adăugate la contextul public rezultat al modulului de tip.
Interceptarea apelurilor prin metoda
Scopul interceptării apelurilor, în marea majoritate a cazurilor, este de a înconjura un apel de metodă generică cu unele acțiuni pre- și/sau post. În același timp, nu am exclus opțiunea de a anula complet apelul la o metodă standard și am implementat această posibilitate.
Descrieți pe deplin necesitatea de a intercepta una sau alta metodă standard în modulul de extensie. Pentru a face acest lucru, am introdus un nou element structural în limbajul încorporat - adnotarea. Cu ajutorul unei adnotări situate înainte de definirea metodei, specificați ce metodă generică interceptează procedura/funcția și exact cum. De exemplu:
Adnotarea &Before(„Procedura1”) înseamnă că o procedură generică numită Procedura1 este interceptată. Numele de adnotare Înainte înseamnă că procedura dvs. de interceptoare Ext_Proc1() va fi executată mai întâi, iar apoi genericul Procedure1().
Rezumat &Înainte
O adnotare cu acest nume înseamnă că interceptorul dvs. va fi executat înainte ca metoda generică să înceapă executarea.
În diagramă, modulele standard și de extensie sunt afișate ca dreptunghiuri, iar săgeata arată secvența de execuție a limbajului încorporat.
Abstract și După
Această adnotare înseamnă că interceptorul dvs. va fi executat după ce metoda generică a fost executată.
Abstract &În schimb
Această adnotare implementează cu precizie posibilitatea de a suprapune complet o metodă standard. Adică metoda standard nu va fi executată deloc. În schimb, doar interceptorul tău va fi executat.
Pentru aceeași procedură standard, puteți instala una dintre următoarele combinații de interceptoare în extensia dvs.:
- &Inainte de;
- &După;
- &În loc de;
- &Inainte si dupa.
Ultima combinație de interceptori (&Before și &After) va fi executată după cum urmează:
Dacă interceptați o funcție generică mai degrabă decât o procedură, atunci puteți utiliza doar & în loc de interceptor.
Apelarea unei metode suprascrise de &În loc de
Se dovedește a fi o nedreptate. Puteți acoperi sau încadra procedura. Și funcția trebuie să fie complet blocată.
Pentru a scăpa de această nedreptate, am implementat o nouă metodă în limbajul încorporat - ContinueCall(). Dacă apelați această metodă în interiorul funcției dvs. de interceptor, funcția pe care ați înlocuit-o va fi executată, după care executarea codului va reveni la interceptor:
Într-un limbaj încorporat, o astfel de funcție de interceptor ar putea arăta astfel:
Deci funcția ta de interceptor este împărțită în două părți. Partea care este executată înainte de execuția funcției standard și partea care este executată după funcția standard.
Puteți utiliza metoda ContinueCall() nu numai atunci când suprapuneți funcții, ci și când suprapuneți proceduri. În acest caz, rezultatul utilizării sale va avea același sens ca atunci când se utilizează o pereche de interceptoare &Înainte și &După. Singura diferență va fi că în acest caz partea ta „înainte” și partea ta „după” vor exista în același context. Acest lucru poate fi convenabil în unele situații. Într-un limbaj încorporat, o astfel de procedură de interceptor ar putea arăta astfel:
Care este mai bine, &Înainte, &După sau &În loc?
Când interceptați metode de configurare generice, este întotdeauna util să aveți în vedere două lucruri:
- După ce ați scris extensia, configurația tipică se va schimba;
- Scopul tău este să adaugi propria ta funcționalitate și să nu renunți pentru totdeauna la ceea ce este și ce va fi în configurația standard.
Din acest punct de vedere, cel mai de preferat este să folosiți interceptoarele &Before și &After. Pentru că cu ele metoda standard interceptată va fi întotdeauna executată, fără nicio condiție. Și dacă dezvoltatorii configurației standard fac mai târziu modificări acestei metode, aceste modificări vor funcționa cu siguranță atunci când utilizați extensia dvs.
De asemenea, este perfect acceptabil să folosiți &În loc de interceptor și metoda ContinueCall(). Totuși, aici aveți ocazia și tentația de a apela la o metodă standard nu întotdeauna, ci în funcție de unele dintre propriile condiții. Trebuie să abordați acest lucru cu atenție și să vă amintiți că în momentul în care refuzați să apelați o metodă generică, refuzați să apelați nu numai metoda care se află în configurație acum, ci și toate variantele acesteia care vor apărea în viitor. Și în viitor, de exemplu, în el pot apărea modificări importante și utile.
Și, în sfârșit, cea mai „rea” opțiune este să anulați complet metoda standard cu &În loc de interceptor. În acest caz, handlerul generic cu siguranță nu va fi executat nici acum, nici în versiunile viitoare. Adică îți asumi întreaga responsabilitate pentru funcționarea versiunilor viitoare ale configurației pe tine, pe extensia ta. Există cu siguranță situații în care este necesară o astfel de acoperire completă, dar vă îndemnăm să abordați utilizarea sa cu mare atenție și atenție.
Secvența de apeluri la interceptarea metodelor
Aici, înainte de a spune, este necesar să facem o mică precizare. O caracteristică „ideologică” importantă, s-ar putea spune, a extensiilor este autonomia lor. Adică, extensiile ar trebui proiectate astfel încât să nu depindă una de alta.
Dar când aplicația rulează, în mod natural și evident, există o anumită secvență de apelare a extensiilor conectate. Această secvență este cunoscută și acum vă vom spune despre ea. Dar nu vă vom spune astfel încât pe baza ei să puteți crea extensii interdependente, sau extensii care implică o singură secvență de conexiune strict definită. Și astfel încât să puteți analiza problemele care apar și să depanați codul programului.
Când conectați extensii la o configurație tipică, se formează un „tort cu mai multe straturi”. La baza acestei plăcinte se află configurația tipică, iar în partea de sus este cea mai recentă extensie conectată.
Atât în configurator, cât și în modul 1C:Enterprise, ultima extensie conectată este ultima în listă.
Deci, în acest exemplu, cel generic este în partea de jos, Extensia2 este în partea de sus și Extension1 este între ele. Fiecare extensie ulterioară interceptează (extinde) ceea ce se află sub ea.
Atunci când cadrul întâlnește interceptori definiți în extensii, procesul de execuție a limbajului încorporat se desfășoară din partea de sus până în jos a acelei plăcinte, conform adnotărilor pe care le au interceptori. Până la nivelul pe care îl poate atinge. După aceea, revine în partea de sus, dacă există interceptori, și revine la configurația standard.
Exemplul 1
De exemplu, dacă aceeași metodă generică este interceptată (încadrată) în două extensii, atunci secvența de apelare a handler-urilor va fi următoarea:
- Interceptorul de la Extensia2 va fi apelat primul pentru că este deasupra. Acesta va fi interceptorul &Before deoarece are această adnotare;
- Interceptorul de la Extension1 va fi apoi apelat deoarece este următorul în plăcintă. Va fi din nou &Before deoarece are această adnotare;
- Metoda generică va fi apoi apelată deoarece nu mai există interceptori care să o împiedice să se execute;
- Apoi, în ordinea inversă a plăcintei, vor fi apelați interceptorul &After din Extensia1 și interceptorul &After din Extensia2.
Din acest exemplu, puteți înțelege clar următoarea caracteristică: dacă apare o excepție netratată într-unul dintre interceptori, atunci întregul lanț este întrerupt și excepția continuă să se propage.
Exemplul 2
Dacă interceptorii folosesc metoda ContinueCall(), atunci se aplică același principiu plăcintă.
- Interceptorul de la Extension3 va fi apelat primul pentru că este deasupra. Va fi un interceptor &În schimb, pentru că are această adnotare;
- Când încercați să apelați o metodă standard, „plăcinta” rămasă va fi analizată. Acesta va fi analizat exact în același mod ca cel descris în exemplul anterior;
- Ca rezultat, execuția codului va reveni la &În loc de interceptor și, la finalizarea acestuia, la configurația standard.
Exemplul 3
Un punct important de înțeles este faptul că, atunci când se suprascrie folosind adnotarea &Instead, de fapt, nu numai apelul la metoda principală este suprascris, ci și interceptoarele situate mai jos în „plăcintă”.
Acest exemplu va executa doar interceptorul &În loc de Extensia2. Pentru că acoperă metoda standard, adică întreaga „plăcintă” care se află sub ea.
Exemplul 4
Aceasta este, de fapt, o variație a temei celui de-al doilea exemplu, dar când sub extensia de sus există o extensie care, de asemenea, „împinge” apelul la procedura standard.
În esență, vizualizează încă o dată faptul că un apel la o metodă generică se aplică întregii „plăcinte” din extensie. De aceea, după apelarea interceptorului din Extensia2, va fi apelat interceptorul din Extensia1. Pentru că în „plăcinta” rămasă tocmai aceasta este cea care suprascrie apelul la metoda standard pe care se dorește să „atingă” Extensia2.
Interceptarea handlerelor de evenimente și a propriilor handlere în module de obiecte, manageri etc.
Interceptarea oricăror metode din aceste module se face exact în același mod ca cel descris la început. Cu toate acestea, dacă procedura interceptată este un handler de evenimente, există câteva considerații. Aceste caracteristici se datorează faptului că în aceste module toți gestionanții de evenimente au nume fixe.
În primul rând, numele metodei interceptate este numele evenimentului. De exemplu, BeforeRecord:
În al doilea rând, prezența unui handler standard pentru acest eveniment nu este obligatorie. Dacă nu există un handler generic, interceptorul dvs. va fi apelat. Datorită acestei funcții, puteți atribui propriile dvs. de gestionare evenimentelor care nu sunt procesate în configurația standard.
Deoarece handlerii de evenimente din modulele obiect au nume fixe și lista de adnotări este cunoscută, am implementat un mic „serviciu” pentru dvs. Când creați un handler în extensie, se deschide un dialog în care puteți selecta tipul de apel. După aceea, în modul este creată o procedură de interceptor șablon.
Interceptarea handlerelor de evenimente și a handlerelor personalizate în modulele de formulare
Interceptarea oricăror metode din aceste module este, de asemenea, efectuată exact în același mod ca cel descris la început. Cu toate acestea, există și caracteristici legate de interceptarea gestionatorilor de evenimente. Aceste caracteristici se datorează faptului că în aceste module toți gestionanții de evenimente sunt atribuibili și nu au nume fixe. După cum probabil știți, pentru ca platforma să înțeleagă cum să proceseze un anumit eveniment, în configurator, în panoul de proprietăți, trebuie să existe o legare a unei anumite proceduri de un anumit eveniment.
Din acest motiv, și numai atunci când interceptați manipulatorii de evenimente pe un formular, trebuie să utilizați paleta de proprietăți mai degrabă decât adnotările. Deși puteți intercepta orice alte metode de modul care nu sunt handler de evenimente folosind adnotări.
În exterior, interceptorul de evenimente din modulul formular arată astfel:
Adnotarea nu este utilizată, iar tipul de interceptor este indicat în paleta de proprietăți. Acest lucru se face destul de simplu. Când creați un handler în extensie, făcând clic pe butonul „lupă” se deschide un dialog. Vă permite, pe lângă context, să specificați tipul de interceptor (Înainte, După sau În loc).
După crearea unui șablon de procedură, în paleta de proprietăți apare o pictogramă, lângă numele interceptorului, afișând tipul de interceptare.
Dacă înlocuiți handlerul generic (În schimb), atunci va fi doar un punct.
Dacă creați un interceptor Înainte sau După, acesta va fi un punct lângă bara verticală. Locația punctului, înainte sau după linie, indică tipul de interceptor. Și pe lângă aceasta, un al doilea câmp (gol) apare în paleta de proprietăți lângă acest eveniment. Cu ajutorul acestuia, puteți specifica un interceptor asociat dacă este nevoie să încadrați un handler tipic cu o pereche Înainte - După.
Interceptorii de evenimente definiți în acest fel vor funcționa chiar dacă nu există un handler standard pentru acest eveniment. Acesta este modul în care vă puteți atribui propriile handlere acelor evenimente de formular care nu sunt procesate în configurația standard.
Vorbind despre modulele de formular, trebuie să mai facem o mică notă. Am schimbat ușor comportamentul modulelor care extind modulele de formular care existau anterior. Pentru ca acesta să fie în concordanță cu comportamentul altor module și să asigure stabilitatea codului programului.
Anterior, toate modulele care extindeau modulul de formular și modulul de formular în sine se aflau în același spațiu de nume. Astfel, a fost posibil să apelăm din extensia de sus nu numai metodele configurației standard, ci și metodele extensiilor de bază. Acum am închis această lacună, iar metodele extensiilor de bază nu mai sunt disponibile. Acum puteți accesa doar metodele conținute în modulul generic pe care îl extindeți.
Module comune
În extensie, puteți crea oricare dintre propriile module comune. Există doar două restricții:
- Nu trebuie să fie global pe partea de server;
- Nu ar trebui să fie privilegiați.
Când extindeți un modul comun al unei configurații tipice, există și restricții similare:
- Nu puteți împrumuta module globale de server;
- Codul din extensia dvs. va fi executat numai în modul neprivilegiat (dacă nu este permis altfel în profilul de securitate).
Operația de împrumut în sine a unui modul de server global nu este interzisă în arborele de configurare, dar în etapa de actualizare a configurației bazei de date veți primi o eroare și actualizarea nu va fi efectuată.
Metodele de server nu se extind întotdeauna
Faptul că extensia dvs. este conectată cu succes la o configurație standard nu înseamnă că toți interceptorii care sunt în extensia dvs. vor fi aplicați și vor începe să se execute. Există câteva funcții legate de securitate aici.
Dacă soluția aplicației funcționează într-o versiune de fișier sau într-o versiune client-server fără profiluri de securitate, atunci când vă conectați extensia:
- În modul normal de execuție al limbajului încorporat, toate metodele soluției standard, atât client, cât și server, vor fi extinse;
- În modul de execuție sigur al limbajului încorporat, vor fi extinse numai metodele client și procesoarele de formulare de server. Extensia nu va fi aplicată altor proceduri/funcții de server.
Atunci când o soluție de aplicație funcționează într-o versiune client-server și este specificat un profil de securitate specific la conectarea unei extensii sau profilurile în mod normal și sigur sunt alocate bazei de informații, atunci partea „server” a extensiei va fi utilizată așa cum este specificat în profilul corespunzător.
Cel mai simplu dintre ele este o casetă de selectare pentru a extinde toate modulele din grupul Acces total permis. „Într-o singură lovitură” permite extinderea contextului serverului.
Există, de asemenea, o setare mai precisă folosind Modulele disponibile pentru extensie și Modulele care nu sunt disponibile pentru câmpurile de extensie. Presupunem că le veți folosi după cum urmează:
- Dacă nu ați permis accesul complet la extensii, atunci în câmpul Module disponibile pentru extensie enumerați numele acelor module pentru care extensia contextului serverului este acceptabilă și nu periculoasă;
- Dacă ați permis accesul complet la extensii, atunci în câmpul Module not available for extensie enumerați câteva module în care încă nu trebuie să permiteți extensii de context de server.