Și Data Transfer Object la structurarea codului, sub formă gestionată în mediul 1C 8.2.

Introducere

Să începem cu o scurtă descriere a conceptului de „formă gestionată” și a conceptelor conexe ale platformei 1C. Experții în platformă pot sări peste această secțiune.

A devenit disponibil în 2008 o nouă versiune platforma 1C: Enterprise 8.2 (denumită în continuare Aplicație gestionată), care schimbă complet întregul strat de lucru cu interfața. Aceasta include interfața de comandă, formularele și sistemul de ferestre. Acest lucru nu numai că schimbă modelul de dezvoltare a interfeței cu utilizatorul în configurație, dar propune și o nouă arhitectură pentru separarea funcționalității între aplicația client și server.
Aplicația gestionată acceptă următoarele tipuri de clienți:

• Client gros (mod de lansare normal și gestionat)
• Client slab
• Client web

O aplicație gestionată utilizează formulare construite pe baza tehnologie nouă. Sunt chemați Formulare gestionate. Pentru ușurința tranziției, sunt acceptate și formularele mai vechi (așa-numitele formulare obișnuite), dar funcționalitatea lor nu este dezvoltată și sunt disponibile doar în modul de lansare a clientului bogat.
Principalele diferențe ale formularelor gestionate pentru dezvoltator:

• Descriere declarativă, nu „pe pixeli” a structurii. Amplasarea specifică a elementelor se face automat de către sistem la afișarea formularului.
• Toate funcționalitățile formularului sunt descrise în formular Detaliiși comenzi. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile efectuate.
• Formularul se execută atât pe server, cât și pe client.
• În contextul clientului, aproape toate tipurile de aplicații nu sunt disponibile și, în consecință, este imposibil să se schimbe datele din baza de informații.
• Pentru fiecare metodă sau variabilă de formă, aceasta trebuie specificată directivă de compilare A care specifică dacă locația de execuție (client sau server) și accesul la contextul formularului.

Iată directivele pentru compilarea metodelor de formulare:

• &AtClient
• &Pe server
• &OnServerWithoutContext
• &La ClientLa ServerWithoutContext

Să ilustrăm cele de mai sus. Captura de ecran arată un exemplu de formular gestionat și modulul acestuia în modul de dezvoltare. Găsiți descriere declarativă, elemente de recuzită, directive de compilare etc.

Toate discuțiile ulterioare vor fi despre partea dreaptă a ilustrației, despre cum să structurați codul modulului și ce principii vă vor permite să implementați interacțiunea eficientă client-server.

Să definim problema

Au trecut câțiva ani de când noua versiune a platformei 1C a fost utilizată activ și multe soluții (configurații) au fost lansate atât de către 1C, cât și de numeroșii săi parteneri.
Au dezvoltat dezvoltatorii o înțelegere comună a principiilor interacțiunii client-server atunci când creează formulare în acest timp și s-a schimbat abordarea implementării? module softwareîn noile realități arhitecturale?

Luați în considerare structura codului (modul de formular) în mai multe forme ale aceleiași configurații tipice și încercați să găsiți modele.
Sub structură, ne referim la secțiuni de cod (cel mai adesea acestea sunt blocuri de comentarii) alocate de dezvoltator pentru metode de grupare și directive pentru compilarea acestor metode.
Exemplul 1:
Secțiunea de gestionare a evenimentelor Metoda - pe client Metoda - pe server Metoda - pe client Secțiunea proceduri și funcții de service Funcții auxiliare de control al intrărilor
Exemplul 2:
Proceduri și funcții de service Documente de plată Valori Operatori de evenimente
Exemplul 3:
Proceduri de service pe server Proceduri de service pe client Proceduri de service pe server fără context.
Exemplul 4:
Proceduri de uz general Manipulatori de evenimente formular Proceduri ale subsistemului „informații de contact”.
De fapt, structura codului lipsește sau, pentru a spune ușor, este similară cu ceea ce era în formele 8.1:

• Cuvinte neinformative „General, Serviciu, Auxiliar”.
• Încercări timide de a separa metodele client și server.
• Adesea metodele sunt grupate pe elemente de interfață „Lucrul cu partea tabelară Produse, Informații de contact”.
• Aranjamentul arbitrar al metodelor și grupurilor de coduri. De exemplu, Event Handlers pot fi în partea de sus într-o formă, în partea de jos în alta, deloc evidențiate într-o a treia și așa mai departe.
• Și să nu uităm că toate acestea sunt în aceeași configurație.
• Da, există configurații în care cuvintele „General, Service, Auxiliar” sunt întotdeauna în aceleași locuri, dar ...

De ce aveți nevoie de o structură de cod?

• Simplificarea întreținerii.
• Simplificați învățarea.
• Fixarea principiilor generale/importante/de succes.
• ...opțiunea ta

De ce nu ajută standardul de dezvoltare existent de la 1C?

Să ne uităm la principiile publicate pe discurile ITS și în diverse „Ghiduri pentru dezvoltatori...”, recomandate la scrierea unui formular gestionat.

• Minimizați numărul de apeluri pe server.
• Calcul maxim pe server.
• Apelurile de server fără context sunt mai rapide decât apelurile de context.
• Program cu interacțiunea client-server în minte.
• etc.

Acestea sunt sloganuri care sunt absolut adevărate, dar cum pot fi ele realizate? Cum să minimizezi numărul de apeluri, ce înseamnă să programezi în modul client-server?

Modele de design sau înțelepciune generațională

Interacțiunea client-server a fost folosită în diverse tehnologii software de zeci de ani. Răspunsul la întrebările prezentate în secțiunea anterioară este cunoscut de mult și este rezumat în două principii de bază.

• Fațada la distanță(denumită în continuare interfață de acces la distanță)
• Obiect de transfer de date(denumit în continuare obiect de transfer de date)

Cuvântul lui Martin Fowler, descrierea sa a acestor principii:

• … fiecare obiect potențial destinat accesului de la distanță trebuie să aibă interfață cu granularitate scăzută, care va minimiza numărul de apeluri necesare pentru a efectua o anumită procedură. … În loc să solicitați o factură și toate punctele acesteia separat, este necesar să citiți și să actualizați toate punctele facturii într-un singur apel. Acest lucru afectează întreaga structură a obiectului... Amintiți-vă: interfața de acces la distanță nu conține logica domeniului.
• ... dacă aș fi o mamă grijulie, cu siguranță i-aș spune copilului meu: „Nu scrie niciodată obiecte de transfer de date!” În cele mai multe cazuri, obiectele de migrare a datelor nu sunt altceva decât fieldset umflat… Valoarea acestui monstru dezgustător constă numai în posibilitatea transmite mai multe elemente de informații prin rețea într-un singur apel- o tehnică de mare importanță pentru sistemele distribuite.

Exemple de șabloane în platforma 1C

API-ul disponibil pentru un dezvoltator atunci când dezvoltă un formular gestionat conține multe exemple ale acestor principii.
De exemplu, metoda OpenForm(), o interfață tipică „grundă”.
OpenParameters = New Structure("Parametru1, Parametru2, Parametru3", Valoare1, Valoare2, Valoare3); Form = OpenForm(FormName, OpenParameters);
Comparați cu stilul v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

În contextul unui formular gestionat, un set de „Obiecte de transfer de date”. Poate fi distins sistemicăși definit de dezvoltator.
Cei de sistem modelează un obiect de aplicație pe client, sub forma unuia sau mai multor elemente de date de formular. Nu le puteți crea în afara caracterului obligatoriu pentru detaliile formularului.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

Conversia obiectelor sistemului de transfer de date în tipuri de aplicații și invers se realizează prin următoarele metode:

• ValueVDataForm()
• FormDataToValue()
• CopyFormData()
• ValueVFormProps()
• FormAttributeToValue()

Adesea, o conversie explicită este utilizată atunci când se adaptează o soluție existentă. Metodele se pot aștepta la parametrii de intrare (funcție) precum ValueTable, mai degrabă decâtFormDataCollection, sau metoda a fost definită în contextul unui obiect aplicație și a devenit indisponibilă pentru apelul direct din formular.
Exemplul 1C v8.1:
// pe client în contextul formularului FillUsersCache(DepartmentReference)
Exemplul 1C v8.2:
// pe server în contextul formularului ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, „Obiect”);

Obiectele de migrare a datelor, a căror structură este definită de dezvoltator, sunt un mic subset al tipurilor disponibile atât pe client, cât și pe server. Cel mai adesea, ca parametri și rezultate ale metodelor unei interfețe „grosiere”, se folosesc următoarele:

• Tipuri primitive (șir, număr, boolean)
• Structura
• Conformitate
• matrice
• Legături către obiectele aplicației (identificator unic și reprezentare text)

Exemplu: metoda acceptă o listă de comenzi pentru a schimba starea și returnează clientului o descriere a erorilor.
&OnServerWithoutContext Funcția ServerChangeOrderStatus(Comenzi, NewStatus) Erori = Potrivire nouă(); // [comanda][descrierea erorii] Pentru fiecare comandă din bucla comenzi StartTransaction(); Încercarea DocOb = Order.GetObject(); …. alte acțiuni, eventual nu numai cu comanda... Excepție CancelTransaction(); Erori.Insert(Comandă, DescriptionError()); Sfârșitul încercării; EndCycle; Eroare de returnare; EndFunction // ServerChangeOrderStatus()

Structurarea codului

Principalele obiective pe care trebuie să le reflecte modulul de formulare gestionate și abordări ale soluției.

• Separare clară a codului client și server. Să nu uităm că la momentul execuției acestea sunt două procese care interacționează, în fiecare dintre ele funcționalitatea disponibilă diferă semnificativ.
• O selecție clară a interfeței de acces la distanță, ce metode de server pot fi apelate de la client și care nu? Numele metodelor de interfață la distanță încep cu prefixul „Server”. Acest lucru vă permite să vedeți imediat trecerea controlului către server atunci când citiți codul și simplifică utilizarea indicii contextuale. Rețineți că recomandarea oficială (ITS) sugerează metode de denumire cu postfixe, cum ar fi ChangeOrderStatusOnServer(). Cu toate acestea, pentru a reitera, nu toate metodele de server pot fi apelate de la client și, prin urmare, accesibilitatea logică este mai importantă decât locația de compilare. Prin urmare, cu prefixul „Server”, se marchează doar metodele disponibile clientului, metoda exemplu se va numi ServerChangeOrderStatus().
• Lizibilitate. O chestiune de gust, acceptăm comanda atunci când modulul începe cu procedurile de creare a unui formular pe server și metodele de acces la distanță.
• Mentenabilitatea. Locul de adăugare a codului nou trebuie să fie clar definit. Punct important, care sunt create automat de configuratorul stub de metodă, sunt adăugate la sfârșitul modulului. Deoarece manipulatorii de evenimente ale elementelor de formular sunt cel mai adesea creați automat, blocul corespunzător este plasat ultimul pentru a nu trage fiecare handler în alt loc din modul.

Mai jos este structura de bază a modulului care implementează obiectivele enumerate.

• Opțiune grafică - arată clar fluxul principal de execuție.
• Versiunea text este un exemplu de design șablon pentru introducere rapidă structuri într-un nou modul de formă.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Data=""/> // <Описание> // // ////////////////////////////////////////////////////////////////////// ////////////////////////////////// VARIABILE DE MODUL //////////////// ////////////////////////////////////////////////////////////////////// // ////////////// // PE SERVER //******* EVENIMENTE PE SERVER ******* &Pe Server Procedura La CrearePe Server( Eșec, procesare standard) //Inserați conținutul handler-ului EndProcedure //******* INTERFAȚA DE ACCES LA DISTANȚĂ ******* //******* LOGICA DE AFACERI PE SERVER **** *** ///////// ////////////////////////////////////////////////////////// ///////////// ////////////////////////// METODE COMUNE DE CLIENT SI SERVER ////////// ////////////////////////////////////////////////////////////////////// //////////////// //////// // PE CLIENT //******** LOGICA DE AFACERI PE CLIENT ****** //******* COMANDI ******* //******* EVENIMENTE PE CLIENT ****** /////////////// ////////////////////////////////////////////////////////////////////// ///////////////// / / PRINCIPALI OPERATORI DE PROGRAME

Întrebări înrudite

În concluzie, schițăm câteva domenii la care este util să ne gândim atunci când programați o interacțiune client-server.

• Opțiuni pentru implementarea interfeței de acces la distanță. Asincronie, granularitate...
• stocarea în cache. 1C a luat o decizie arhitecturală nefericită, introducând caching-ul doar la nivelul metodelor de apelare a modulelor comune și neasigurând opțiuni de control (timp la zi, resetare la cerere).
• Apeluri implicite pe server. Nu uitați de caracteristicile tehnologice, multe operațiuni „inofensive” pe client provoacă platforma să acceseze serverul.

11.12.2016

Despre formularele gestionate 1C (Început)

Client slab

Nu există nicăieri mai subțire. Acum aplicația client nu interogează baza de date (aceasta este afacerea serverului). Aplicația client afișează pur și simplu interfața și datele.

Este de remarcat faptul că structura codului a devenit mai complicată din cauza unor astfel de transformări. Pe client, nu există referințe, obiecte, tabel de valori... sunt disponibile doar tipuri primitive (șir, dată, boolean, matrice, structură...). Aceasta înseamnă că programatorul trebuie să se gândească acum ce să obțină pe server și cum să o facă la un cost minim.

Interacțiunea client-server

O nouă abordare a interacțiunii dintre client și server ne-a permis să creăm un nou model de interfață cu utilizatorul. Acum interfața este declarată(!) Designul interfeței începe cu date, cu detalii și părți tabulare. Când creați o recuzită, trebuie să vă gândiți la cum va arăta în interfață, dacă va fi necesară, cum este legată de alte elemente de recuzită...

Fără context (stare) pe server

Serverul 1C funcționează pe principiul „stateless” (în engleză state-less). Aceasta înseamnă că serverul răspunde doar la solicitări și, în același timp, nu stochează nimic între două solicitări (există stocare temporară în acest scop).

FormDataToValue,FormDataCollection,FormData...

Am apelat la server, a făcut totul pentru noi, a șters datele și a uitat că am venit. Toate obiectele numite „FormData” + „ceva acolo” ne vor ajuta să ne salvăm datele între două apeluri de server.

Depozitare temporara

Stocarea temporară este un loc special în care (pe lângă detaliile formularului) puteți salva starea pe server. Stocarea poate stoca date care nu sunt disponibile pe client (adică care nu pot fi plasate în detaliile formularului).

Pentru a lucra cu stocarea temporară, utilizați metodele MoveToTempStorage() Sintaxă: PlaceToTempStorage(<Данные>, <Адрес>) Descriere: Stochează o valoare serializabilă în stocarea temporară. Disponibilitate: Thin client, client web, server, client gros, conexiune externă, aplicație mobilă (client), aplicație mobilă (server). Apelul de metodă efectuează un apel către server.<Адрес>(opțional) Tip: UniqueIdentifier; Linia. ID-ul unic al formularului în a cărui stocare temporară urmează să fie plasate datele și noua adresă urmează să fie returnată. Sau adresa din depozitul temporar unde ar trebui să fie plasate datele. Adresa trebuie obținută mai devreme folosind această metodă. Dacă se transmite un formular UniqueIdentifier sau o adresă în stocare, atunci valoarea va fi ștearsă automat după ce formularul este închis. Dacă se transmite un UniqueIdentifier care nu este un identificator unic pentru formular, atunci valoarea va fi ștearsă la sfârșitul sesiunii utilizatorului. Dacă parametrul nu este specificat, valoarea plasată va fi ștearsă după următoarea solicitare a serverului din modulul partajat, la apelurile server contextual și non-context din formular, la apelurile server din modulul de comandă sau la obținerea formularului. Notă: stocarea temporară creată într-o sesiune nu este accesibilă din altă sesiune. O excepție este capacitatea de a transfera date de la un job de fundal la sesiunea care a inițiat jobul de fundal folosind stocare temporară. Pentru un astfel de transfer, în sesiunea părinte, plasați o valoare goală în stocarea temporară, trecând identificatorul de formular. Apoi treceți adresa primită jobului de fundal prin parametrii jobului de fundal. Mai mult, dacă această adresă este utilizată în parametru<Адрес>, rezultatul va fi copiat în sesiunea de la care a fost pornit jobul de fundal. Datele plasate în stocare temporară într-o lucrare de fundal nu vor fi disponibile din sesiunea părinte până la finalizarea lucrării de fundal. și Sintaxă GetFromTempStorage(): GetFromTempStorage(<Адрес>) Descriere: Obține o valoare din stocarea temporară. Disponibilitate: Thin client, client web, server, client gros, conexiune externă, aplicație mobilă (client), aplicație mobilă (server). Apelul de metodă efectuează un apel către server. Notă: Rezultatul execuției nu este stocat în cache, serverul este apelat de fiecare dată când este apelată metoda.

Cod server de apelare

Orice apel la codul serverului serializează întotdeauna datele transmise. Toți parametrii sunt împachetati într-o formă de șir și transmisi prin rețea. Rezultatul lucrării este, de asemenea, transferat înapoi într-o formă serializată, unde este apoi restaurat în obiecte familiare.

Atribuirea steagurilor modulelor

• Steagul indică unde va fi compilat codul modulului (pe server, pe client, într-o conexiune externă)
• Dacă un modul este compilat în mai multe locuri, atunci va fi vizibil numai în funcție de steaguri
• Transferul execuției codului este posibil numai dacă nu există un modul apelat în contextul de execuție curent, dar acesta există în altă parte (dacă modulul există doar pe server și nu există pe client, atunci serverul va fi apelat)

Steagul apelului serverului

Începând cu platforma 1C:Enterprise 8.2, a fost adăugat flag „apel de server”. Ceea ce doar ajută la „rezolvarea” condițiilor pentru trecerea la o altă mașină. Dacă acest flag este atribuit modulului, atunci modulul va fi vizibil de la client, dacă nu, atunci o încercare de a apela de la client va avea ca rezultat o eroare. Codul modulului nu va fi vizibil, ca și cum nu ar exista deloc.

Astfel, într-un client gros obișnuit, puteți transfera codul pe server doar dacă apelați un modul comun de la client, pentru care:

• Caseta de selectare Server bifată
• Caseta de selectare „Apel server” este bifată
• S-au eliminat toate casetele de selectare „client”.

Odată cu apariția platformei 1C Enterprise 8.2, mecanismul de dezvoltare a interfeței cu utilizatorul s-a schimbat semnificativ. Acum puteți crea formulare și aplicații gestionate (Figura 1).

Poza 1

În plus, este propus un nou sistem de separare a funcționalității între aplicația client și server.
O aplicație gestionată acceptă următoarele tipuri de clienți:

• Client gros (mod de lansare normal și gestionat),
• client slab,
• Client web.

Mecanismul de creare a formularelor gestionate este semnificativ diferit de formularele convenționale. În primul rând, formularele gestionate diferă prin faptul că sunt create automat de sistem pe baza setărilor speciale; acum programatorul nu trebuie să deseneze fiecare formular în detaliu. Toate funcționalitățile formularului sunt descrise sub formă de detalii și comenzi. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile efectuate. Pentru fiecare metodă sau variabilă de formă trebuie specificată o directivă de compilare, care determină locul execuției (client sau server). Directivele de compilare pot fi:

• &Client,
• &Pe server,
• &OnServerWithoutContext,
• &La ClientLa ServerWithoutContext.

De asemenea, un formular gestionat diferă de un formular obișnuit prin tipurile de date cu care lucrează. Dacă un formular obișnuit funcționează cu majoritatea tipurilor furnizate de 1C:Enterprise (inclusiv tipurile DirectoryObject, DocumentObject etc.), atunci următoarele categorii de tipuri pot fi distinse într-o formă gestionată:

• tipurile care sunt utilizate direct în formular sunt acele tipuri care există pe partea clientului subțire și Web (de exemplu, Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• tipurile care vor fi convertite în tipuri speciale de date sunt tipuri de date din formulare gestionate. Astfel de tipuri sunt afișate în lista de atribute de formular între paranteze, de exemplu (CatalogObject.Products);
• lista dinamica.

Funcționarea formularelor gestionate are următoarele caracteristici distinctive (Figura 2):

• Formularul există atât pe client, cât și pe server.

Realizează interacțiunea client-server (transfer de date și proprietăți de proiectare ale elementelor).

• Formularul nu funcționează cu obiectele aplicației

Figura 2

Formularul folosește obiecte generice speciale
Formulare de date(Figura 3).


Figura 3

Obiectele aplicației funcționează numai pe server și numai în timpul anumitor operațiuni.
La deschiderea unui formular:

• Obiectul este citit din baza de date,
• Obiectul este convertit în date de formular,
• Obiectul este eliminat (din memorie),
• Datele formularului sunt transmise clientului.

La înregistrare:

• Datele formularului sunt primite de la client,
• Datele din formular sunt convertite într-un obiect,
• Obiectul este scris în baza de date,
• Obiectul este eliminat (din memorie).

În ultima lecție, am luat în considerare pentru un client obișnuit (gras). În versiunea platformei 1C 8.2. Folosesc noi forme de ecran 1C 8.2. Ele sunt numite formulare gestionate 1C 8.2.

Formele gestionate 1C 8.2 este viitorul 1C. Ele diferă de formele obișnuite 1C 8.2 prin faptul că sunt generate automat de sistem pe baza setărilor speciale (formele „regulate” sunt pur și simplu desenate de programator după bunul plac).

Diferențele în dezvoltarea formelor gestionate 1C 8.2 față de cele uzuale sunt semnificative. Prin urmare, ne-am adunat astăzi pentru a discuta separat despre crearea și modificarea formularelor gestionate 1C 8.2.

Formulare gestionate 1C 8.2

Dacă ați mai dezvoltat configurații 1C, când deschideți editorul de formulare gestionate 1C 8.2, veți fi imediat confuz de faptul că este imposibil să influențați deloc formularul 1C 8.2 cu mouse-ul.

Nu puteți modifica formularul 1C 8.2, nu puteți muta elementul, nici măcar nu puteți vizualiza proprietățile câmpului ca înainte - făcând dublu clic pe câmpul din formularul 1C 8.2.

Acum, baza pentru dezvoltarea formularului 1C 8.2 nu este legarea câmpurilor la coordonatele din formular, ci setărilor speciale. Sistemul generează automat un formular gestionat 1C 8.2 pe baza acestor setări.

Setările constau dintr-o listă de elemente de formular 1C 8.2 situate în editorul din colțul din stânga sus. Elementele formularului 1C 8.2 includ:

• Rechizite
• Comenzi (noul concept 1C 8.2, poate arăta ca butoane sau elemente de meniu)
• Grupuri (pentru a combina detalii și comenzi).

În consecință, setările acestor elemente nu se află în proprietățile câmpurilor, ci în proprietățile acestor elemente de setări (meniul clic dreapta, elementul Proprietăți).

Cum funcționează formularele gestionate 1C 8.2

Lucrul cu formularele gestionate 1C 8.2 este diferit pentru utilizator. Au mai multe funcții, dar sunt neobișnuite pentru cei care lucrează cu 1C de mult timp.

În primul rând, locația elementelor obișnuite pe formularul 1C 8.2 diferă. Bara de comandă este întotdeauna în partea de sus.

Partea stângă a barei de comandă este personalizabilă. De obicei, conține butoane tipice precum Înregistrare și Postare.

Partea dreaptă a panoului de comandă este noul meniu standard al formularului 1C Toate acțiunile. Acest meniu vă permite să gestionați formularul 1C 8.2 după cum doriți, similar cu modul în care setările din raportul ACS vă permit să schimbați în mod semnificativ aspectul raportului.

Elemente de meniu arbitrare 1C Toate acțiunile

În funcție de faptul că acest formular 1C 8.1 aparține unuia sau altuia, meniul este umplut cu elemente care vă permit să gestionați acest obiect. De exemplu, dacă este un formular de listă de directoare, atunci vor exista comenzi precum Creare sau Editare.

Element Personalizare listă de meniu 1C Toate acțiunile

Dacă există o listă în formularul 1C 8.2, atunci meniul are comanda Configurare listă și Afișare listă.
Dacă comanda Output List vă este deja familiară - vă permite să salvați orice listă în 1C în Excel / să o imprimați, atunci a doua comandă este nouă.

După cum ați observat deja, nu mai există butoane de selecție în bara de comandă a listelor. În schimb, a apărut butonul Găsiți, la care lucrează (precum și la poziționarea acum dezactivată a cursorului în listă la tastare) - există reclamații.

Funcționalitatea butonului Găsiți, desigur, nu este comparabilă cu selecțiile, dar acestea nu au dispărut nicăieri!
Acestea sunt acum sub elementul de meniu Personalizare listă. Selectarea se poate face acum prin orice câmp și, pe lângă acesta, sortarea și formatarea condiționată se pot face în același mod ca și în rapoartele SKD.

Element Modificare meniu formularul 1C Toate acțiunile

Elementul de formular Modificare vă permite să modificați în mod similar nu numai lista din formularul 1C 8.2, ci și formularul 1C 8.2 în sine.

Utilizatorul poate activa sau dezactiva independent vizibilitatea câmpurilor de pe formularul 1C 8.2, lățimea și înălțimea, activarea câmpului implicit la deschidere etc.

Utilizarea formularelor gestionate 1C 8.2 și a formularelor convenționale 1C

În mod implicit, formularele 1C obișnuite sunt utilizate în configurațiile pentru un client 1C gros (obișnuit), iar formularele gestionate sunt utilizate în configurațiile pentru un client 1C subțire și web. Cu toate acestea, ambele forme de 1C pot fi utilizate în orice configurație, inclusiv simultan.

Pentru a face acest lucru, trebuie să introduceți și proprietățile de configurare (elementul de sus din fereastra de configurare).

În proprietățile de configurare din 1C 8.2, au apărut două noi casete de selectare care vă permit să activați utilizarea non-standard a formularelor 1C.

Crearea formularelor gestionate 8.2

Adăugarea unui formular nou 1C 8.2 se face în același mod ca înainte - folosind butonul Ins de pe tastatură sau butonul Adaugă. Pentru a introduce unul existent, faceți dublu clic pe acesta cu mouse-ul.

În mod implicit, va fi creat formularul (obișnuit sau gestionat) care este setat în configurație (vezi proprietatea Mod lansare principală în proprietățile de configurare).

Constructorul vă va solicita să alegeți tipul de formă - forma unui element, o listă. Aici puteți adăuga sau elimina bare de comandă din formular. Cel mai adesea, aceste setări sunt lăsate ca atare, în mod implicit.

Se deschide un formular completat implicit - toate detaliile obiectului 1C care sunt adăugate la acesta. Puteți bifa o listă specifică de câmpuri obligatorii din a doua filă a constructorului.

Editorul de formulare este format din trei secțiuni.

• În colțul din stânga sus este o listă de elemente de formular. Este format din câmpuri, comenzi și grupuri care vă permit să combinați elemente. Lista comenzilor poate fi vizualizată separat în fila Interfață de comandă.
• În colțul din dreapta sus există o listă de atribute de formular și atribute de obiect disponibile (deschideți crucea de lângă atributul Object).
• Mai jos este o previzualizare a formularului rezultat.

Puteți trage detaliile disponibile spre stânga și va deveni un element de formular (un câmp din formular).

Dacă trebuie să adăugați un buton sau un element de meniu - în partea dreaptă a filei Comenzi, trebuie să creați o nouă comandă. Acesta este un wrapper pentru o funcție dintr-un modul de formular. Pe lângă specificarea funcției care va fi apelată efectiv, puteți atribui o reprezentare - de exemplu, o imagine, precum și dependența vizibilității de o opțiune funcțională.

Comenzile sunt, de asemenea, trase spre stânga. Dacă părintele este o bară de comandă, atunci va fi un buton din bara de comandă - altfel doar un buton.

În lista de elemente de formular (câmpuri), nu puteți doar să glisați atributul obiectului/formularului, ci și să îl adăugați pur și simplu (butonul Add sau Ins). În special, puteți crea un nou obiect formular - un Grup.

Grupul poate fi un panou de comandă (cursorul trebuie să fie pe linia Formular). Apoi trageți comenzi în el și acestea devin butoane.

Grupul poate fi „regulat”. Apoi, este o modalitate de a grupa câmpuri atât pe verticală, cât și pe orizontală. Numele grupului poate fi eliminat din proprietăți.

Grupul poate fi un panou (pagini). Grupul adăugat de sus este un panou, iar grupurile imbricate de acest tip sunt pagini. Câmpurile sunt deja trase pe pagini.

Elementele de formular inutile sunt eliminate prin ștergerea elementelor de formular din listă.
Poziția câmpului pe formular este determinată de ordinea în lista de elemente (verticală) sau pe grupuri (orizontală). Lățimea și înălțimea sunt stabilite în proprietățile elementului de formular.

Proprietățile elementului de formular au fost mult extinse și conțin multe lucruri utile - atât controlul aspectului (butoane de alegere și ștergere), cât și verificarea valorilor implicite.

Proprietățile formularului în sine, inclusiv dimensiunile sale, sunt stabilite la elementul rădăcină al formularului cu același nume Form.

Managerii de evenimente (răspuns la acțiunile utilizatorului) sunt acum împărțiți în două tipuri. Cele vechi - ca și înainte, sunt specificate în proprietățile formularului și câmpurilor (de exemplu, OnChange și OnOpening the form). Nou - au devenit comenzi și sunt folosite pentru elemente de meniu și butoane.

Din versiunea 8.2 a platformei, 1C a început să folosească noi principii pentru construirea interfeței și interacțiunea utilizatorului cu baza de date. Noua tehnologie se numește Aplicație gestionată. Mecanismele de construire a formularelor și schema de interacțiuni între utilizatorul serverului 1C și baza de date au suferit cea mai mare prelucrare. Modul normal este încă acceptat de platformă, dar în timp, toți utilizatorii 1C vor trece la formulare gestionate.

Pentru utilizatorii obișnuiți, forma gestionată a documentului 1C diferă de cea obișnuită doar ca aspect. Pentru dezvoltator, acesta este un nou mecanism cu propriile reguli, legi și condiții. Multe zone au suferit o schimbare, dar următoarele inovații sunt considerate cheie printre dezvoltatorii experimentați 1C:

• Formarea independentă a structurii formularului și plasarea câmpurilor de către platformă. Dacă dezvoltatorii anteriori au descris poziția câmpului prin specificarea pixelilor, acum este posibil doar specificarea tipului de grupare;
• Formularul este format din atribute reprezentând datele formularului, iar comenzi - proceduri și funcții efectuate;
• Codul formularului este executat atât pe partea serverului, cât și pe partea clientului. La urma urmei, formularul în sine este un obiect de configurare creat pe server și afișat pe client. Aceasta înseamnă că combină părțile client și server;
• Pe partea clientului, multe tipuri de date au devenit indisponibile și acum nu există nicio modalitate de a modifica datele din baza de informații;
• Pentru fiecare procedură sau funcție, trebuie specificată o setare specială - o directivă de compilare. Este responsabil pentru locul în care este executat codul și poate lua următoarele valori:
  • asupra clientului;
  • Pe server;
  • Pe ServerWithoutContext;
  • OnClientOnServer;
  • Pe client Pe server fără context.

Ultimul punct este deosebit de acut în modul formularelor gestionate. Dacă un dezvoltator nu este bine versat în directive sau în interacțiunea client-server, atunci îi va fi extrem de dificil să creeze un formular gestionat. Toate noile principii pentru construirea de formulare gestionate în 1C:Enterprise 8.3 sunt unite de conceptul general de arhitectură cu trei niveluri. Include computere client, un server 1C și un DBMS în care sunt stocate datele.

Editarea unui formular gestionat în configurator a devenit, de asemenea, diferită. S-au schimbat multe aspecte, iar dezvoltatorii versiunii 7.7, unde nu existau formulare gestionate, pot fi surprinși. S-a schimbat chiar și aspectul designerului de formulare, ceea ce poate fi văzut prin deschiderea oricăreia dintre formele obiectului de configurare. Când deschidem un obiect, vedem o fereastră împărțită în mai multe secțiuni:

1. Elemente de interfață de formular. În stânga sus există o fereastră care listează toate câmpurile afișate pe formularul selectat, care asigură interacțiunea programului cu utilizatorul;
2. Detalii formular. În dreapta sus sunt toate datele cu care funcționează formularul. În ele sunt stocate informațiile pe partea clientului;
3. Afișarea unui formular gestionat. Mai jos vedem o previzualizare a aspectului bazat pe elementele interfeței;
4. Modul formular. O secțiune care conține procedurile și funcțiile utilizate de acest formular. Aici puteți găsi codul algoritmilor pentru interacțiunea programului atât cu utilizatorul, cât și cu baza de date.

Dezvoltatorii 1C îi provoacă pe clienți să treacă la formulare gestionate, așa că învățarea principiilor dezvoltării formularelor gestionate este o chestiune de timp. Începând să lucrați cu acest tip de formular, veți înțelege că acesta este un pas către standardizarea dezvoltării și respectarea regulilor uniforme. Prin urmare, capacitatea de a lucra cu formulare gestionate în 1C 8.3 vă crește nivelul de dezvoltator 1C.

Ghid pentru proiectarea formularelor gestionate

În primul rând, pentru a înțelege mecanismul modului gestionat 1C, ar trebui să vă amintiți că formularul există atât pe server, cât și pe client. Mai mult, pe client, acest obiect este doar o imagine a interfeței de interacțiune a utilizatorului cu programul. Toate calculele, algoritmii, calculele și procesarea trebuie să aibă loc numai pe partea serverului. Acest lucru este dictat nu numai de incapacitatea de a utiliza multe funcții și parametri la client, ci și de cerințele de performanță.

Vă puteți da seama unde este efectuată procedura după numele directivei, care trebuie scris înainte de fiecare procedură și funcție în modulul formular. Formularea „Fără Context” indică faptul că datele de pe formularul gestionat nu vor fi transmise acestei proceduri de pe server. Astfel, în astfel de proceduri, nu se vor putea scrie algoritmi pe baza valorilor introduse de utilizator. Dacă această formulare nu este specificată, atunci formularul este transmis în întregime cu toate detaliile și le puteți accesa.

Dezvoltatorii 1C recomandă cu tărie folosirea apelurilor server non-context, reducându-le numărul cât mai mult posibil și încercând să nu efectueze calcule pe client. Este dificil pentru dezvoltatorii începători fără fundal teoretic să respecte toate aceste reguli și să schimbe corect codul. Înainte de a începe să lucrați pe cont propriu, va fi util să deschideți un formular de configurare gestionată, să priviți sintaxa și modul în care interacționează clientul și serverul.

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

Noile reguli pentru dezvoltarea formularelor 1C vor fi de mare beneficiu dacă toți dezvoltatorii le vor adera. În plus, toată lumea va simți schimbările în bine - atât programatorii, cât și companiile care lucrează în 1C, precum și francizații și dezvoltatorii 1C. Principalele consecințe ale funcționării corecte a formularelor gestionate în 1C:

1. Ușurință de întreținere a configurației și lizibilitate crescută a codului. Din aceasta putem trage concluzia că un algoritm scris de un dezvoltator poate fi întotdeauna corectat de un alt angajat fără a pierde mult timp;
2. Separarea codului care rulează pe client și pe server. Având în vedere cât de diferită este funcționalitatea disponibilă pe fiecare dintre aceste părți, separarea lor ar fi mișcarea corectă;
3. Dezvoltatorii au o înțelegere mai profundă a logicii platformei, a interacțiunilor client-server și a algoritmilor pe care îi scriu. În versiunile 8.0 și anterioare, era foarte comun să găsești forme de documente sau directoare dezvoltate fără a înțelege partea client-server;
4. Creșterea vitezei de configurare și reducerea încărcării pe computerele client;
5. Reducerea costului de achiziție a computerelor pentru locurile de muncă din cauza absenței necesității de a achiziționa computere puternice.

Alegerea unei forme gestionate ca mod principal de lansare 1C poate aduce multe surprize. Dar, cu abordarea corectă, acest pas va aduce dividende mari, așa că tot mai mulți utilizatori 1C din Rusia decid asupra acestui lucru. Ținând cont de faptul că compania 1C mizează pe dezvoltarea de formulare gestionate în viitor, este riscant să rămânem pe cele convenționale învechite.