1c probleme cu formularele gestionate. Adăugați și modificați elemente de formular gestionate programatic

În acest articol, vom cunoaște principalele aspecte ale lucrului cu un formular gestionat în 1C 8.3. Ce este o formă și la ce servește? Formularul este obiectul principal prin care utilizatorul interacționează cu programul. Adică, cu ajutorul formularului, utilizatorul introduce informații în program, precum și informațiile necesare pentru utilizator sunt afișate pe formular.

Sarcina principală a dezvoltatorului de orice formă (gestionată sau convențională) este de a oferi utilizatorului un mecanism convenabil de interacțiune cu programul.

Platforma 1C are capacitatea de a genera orice formă de obiect, dar de obicei, atunci când dezvoltă soluții de aplicații, programatorii configurează formularele pe cont propriu.

Problemele de lucru cu formularele gestionate în special și cu o aplicație gestionată în general sunt discutate în detaliu în cartea „Noțiuni de bază de dezvoltare în 1C: Taxi. Dezvoltarea unei aplicații gestionate în 12 pași ”. Această carte va fi de un real ajutor pentru cei care abia încep să dezvolte o aplicație gestionată.

Cartea „Fundamentele dezvoltării în 1C: Taxi” este perfectă pentru cei care au început deja programarea și se confruntă cu anumite dificultăți cu acest subiect și pentru cei care programează de mult timp, dar nu au lucrat niciodată cu formularele gestionate 1C.

1. Fără termeni tehnici complicați;
2. Peste 600 de pagini de material practic;
3. Fiecare exemplu este însoțit de o imagine (captură de ecran);

15% cod promoțional de reducere - 48PVXHeYu

Uneori se pare că învățarea unui limbaj de programare în 1C este dificilă și dificilă. De fapt, programarea în 1C este ușoară. Cărțile mele vă vor ajuta să masterizați cu ușurință și rapid programarea în 1C: și „Fundamentele dezvoltării în 1C: Taxi”

Aflați programarea în 1C cu ajutorul cărții mele „Program în 1C în 11 pași”

1. Fără termeni tehnici complicați.
2. Peste 700 de pagini de material practic.
3. Fiecare sarcină este însoțită de o imagine (captură de ecran).
4. O colecție de sarcini pentru teme.
5. Cartea este scrisă într-un limbaj clar și simplu - pentru un începător.
6. Cartea este trimisă la e-mail în format PDF. Poate fi deschis pe orice dispozitiv!

Dacă această lecție v-a ajutat să rezolvați orice problemă, v-a plăcut sau s-a dovedit a fi util, atunci puteți susține proiectul meu transferând orice sumă:

puteți plăti manual:

Yandex.Money - 410012882996301
Web Money - R955262494655

Alătură-te grupurilor mele.

Știm cu toții că 1C avea multe versiuni diferite ale platformei 1C, acum vom fi interesați de unele dintre cele mai recente versiuni la momentul scrierii acestui articol, acestea sunt versiunile 1C 8.2 și 1C 8.3. Dacă trebuia să lucrați în ambele versiuni, atunci cel mai probabil am observat diferențe în interfețele acestor versiuni, pentru utilizatori diferă doar extern. În esență, alegerea aplicație regulată sau gestionată spune sistemului ce forme de afișat să ruleze, convenționale sau gestionateși care client al aplicației va fi utilizat în mod implicit, gros sau subțire. Pentru mai multe informații despre clienți, consultați articolul „Ce este un client gros și subțire în 1C, precum și diferențele lor”.

Aplicație obișnuită 1C (formulare obișnuite, interfață obișnuită, versiunea 1C 8.2)

În 1C 8.2 este posibilă doar munca cu formulare obișnuite, în modul normal de aplicare... Imaginea de mai jos arată baza în modul de operare „aplicație normală 1C” (formulare obișnuite).

Aplicație gestionată 1C (formulare gestionate, interfață gestionată, versiunea 1C 8.3)

Pe platforma 1C 8.3, putem lucra atât cu formulare obișnuite (în modul de compatibilitate), cât și cu cele gestionate. în plus formularele gestionate au două vizualizări, standard și taxi... Un exemplu de configurație 1C 8.3 cu formulare gestionate standard este prezentat mai jos, urmat de interfața „Taxi”.

Care este diferența dintre o aplicație 1C obișnuită și gestionată?

După cum am aflat deja o aplicație obișnuită și o aplicație gestionată sunt aceste tipuri de lansare a unui program 1C... Mai mult, în funcție de valoarea tipului de lansare 1C ( aplicație regulată sau gestionată), implicit va fi încărcată o interfață specifică ( formulare regulate sau gestionate), deci există atât de multe sinonime pentru acest concept. Am dori să menționăm că diferențele în interfețe sunt destul de semnificative, interfața gestionată a fost complet reproiectată. În principiu, acestea sunt toate diferențele pe care le văd utilizatorii obișnuiți ai programului 1C. În ceea ce privește programatorii, interfața gestionată necesită scrierea codului modificat, deoarece dezvoltarea este deja în desfășurare în 1C 8.3 și nu în 1C 8.2, de unde toate consecințele care rezultă. Codul ar trebui, de asemenea, să fie împărțit în client și server, acest lucru este indicat folosind directivele corespunzătoare din configurator.

Platforma 1C: Enterprise vă permite să adăugați și să modificați programatic elemente ale unui formular gestionat. Să ne dăm seama pentru ce ar putea fi necesar acest lucru.

Modificarea programului formularului poate fi necesară în mai multe cazuri:

• La revizuirea configurațiilor tipice pentru a facilita actualizările ulterioare. În acest caz, doar modulul formular va fi schimbat. Modulele sunt mult mai ușor de actualizat decât un formular.
• La implementarea unor algoritmi generali. De exemplu, în subsistemul „Interzice editarea atributelor de obiect” pentru toate obiectele conectate la subsistem, crearea de software butoane pentru a activa posibilitatea de a edita detalii.
• La implementarea unor algoritmi specifici. De exemplu, în directorul Nomenclatură, sunt create câmpuri pentru editarea detaliilor suplimentare.

Într-un formular gestionat, puteți adăuga, modifica și elimina programatic:

• rechizite;
• comenzi locale;
• elemente.

Toate aceste operațiuni sunt posibile numai pe server.

Schimbarea formei programat are limitări:

• Puteți șterge numai atributele / comenzile / elementele adăugate programatic. Nu puteți șterge programat obiectele create în configurator.
• Nu puteți atribui atributul principal.

Modificarea comenzilor de formular

Pentru a gestiona componența echipelor la instalație ManagedForm există o colecție Comenzi

Adauga la (< ИмяКоманды >)

Număr ()

A găsi (< ИмяКоманды >)

Șterge (< Команда >)

Colecția Teams este disponibilă atât pe client, cât și pe server. Modificarea colecției (metodele Add () și Delete ()) se poate face numai pe server. Puteți căuta și obține numărul de elemente (metodele Find () și Count ()) atât pe client, cât și pe server.

Ca exemplu de lucru cu comenzile de formular, să creăm o nouă comandă ChangeHistory cu titlul „Istoricul modificărilor ...”, care va apela handler-ul Afișați istoricul(). Creația se realizează atunci când formularul este deschis.

& Pe server
Procedură OnCreateAtServer (Eșec, procesare standard)
Echipă \u003d Comenzi. Adăuga ( „Istoricul modificărilor”);
Echipă ... Acțiune \u003d;
Echipă ... Titlu \u003d „Istoricul modificărilor ...”;
Sfârșitul procedurii
& Pentru client
Procedură Connectable_DisplayHistory (Command)
// comanda acțiuni
Sfârșitul procedurii

Handlerul de comandă trebuie să fie localizat în formular și să aibă directiva de compilare & OnClient.

Modificarea detaliilor formularului

Citirea compoziției atributelor formularului este efectuată de funcție Obține detalii(< Путь >) care returnează o matrice de tip Attribute Form. Parametrul funcției specifică calea către recuzita părinte (ca un șir). Dacă parametrul este omis sau este specificat un șir gol, elementele de recuzită de nivel superior sunt returnate.

Schimbarea detaliilor se efectuează prin metodă Modificați detaliile(<Detalii adăugate>, <Atribute amovibile>) obiect ManagedForm... În parametri Detalii adăugate și Atribute amovibile sunt transferate matrici cu elemente de tipul Attribute Form.

Atenţie!

Procesul de modificare a compoziției detaliilor este destul de intensiv în resurse. Recreația formularului este de fapt efectuată. În acest sens, lucrul cu atributele de formular se efectuează în modul batch.

Să creăm un nou atribut formular numit Client:

AddedAttributes \u003d Matrice nouă;
Atribute de adăugat. Adăugați (Obiecte de formular nou(„Cumpărător”, nouă descriere a tipurilor („DirectoryLink.Contractors”), „Client”));

// Modificări în compoziția detaliilor
);

Modificarea elementelor formularului

Pentru a controla compoziția elementelor unui obiect ManagedForm există o colecție Elementele ... Colecția are mai multe metode:

Pastă (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Adauga la (< Имя>, < ТипЭлемента>, < Родитель >)

Număr ()

A găsi (< Имя >)

Mișcare (< Элемент>, < Родитель>, < МестоРасположения >)

Șterge (< Элемент >)

Colecția Elements este disponibilă atât pe client, cât și pe server. Modificați colecția (metode Insert () , Add (), Move () și Delete ()) se pot face numai pe server. Puteți căuta și obține numărul de elemente (metodele Find () și Count ()) atât pe client, cât și pe server. Elementele colecției pot fi:

• Grup de forme;
• Tabel formular;
• Câmp formular;
• Buton formular.

Puteți atribui programat gestionare de evenimente pentru a forma elemente. În aceste scopuri, se intenționează metoda Setare acțiune (< ИмяСобытия>, < Действие >) .

Să luăm în considerare câteva dintre cele mai frecvente exemple de lucru cu comenzi, elemente de recuzită și elemente de formă.

Adăugarea unei comenzi și a butonului său asociat:

// Creați o comandă
Echipă \u003d Comenzi. Adăuga ( „Istoricul modificărilor”);
Echipă ... Acțiune \u003d „Connectable_DisplayHistory”; // Formularul trebuie să aibă o procedură cu numele specificat
Echipă ... Titlu = „Istoricul modificărilor ...”;
// Creați un buton și conectați-l la o comandă
Element \u003d Elemente. Adăuga ( „Istoricul modificărilor”, Tastați („Butonul Formular”));
Element.CommandName = „Istoricul modificărilor”;

Adăugarea unui recuzită și a unui câmp de intrare asociat:

// Descrierea detaliilor adăugate
AddedAttributes \u003d Matrice nouă;
Atribute de adăugat. Adauga la(Accesorii pentru noi forme („Cumpărător”, nouă descriere a tipurilor) "DirectoryLink. Contractori"), „Client”));
// Schimbați compoziția detaliilor
Modificați atributele (atribute adăugate);
// Creați un câmp de intrare și conectați-vă la recuzită
Element \u003d Elemente. Adăugați („Cumpărător”, Tastați („FormField”));
Element ... Vizualizare \u003d FormFieldKind. Câmp de intrare;
Element ... Calea datelor \u003d "Cumpărător";

Atribuirea unui gestionar de evenimente unui element de formular:

Cumpărător de articole. Setați acțiunea(„Când se schimbă”, „Plugin_BuyerOnChange”);

& Pentru client
Procedură Plugin_BuyerOnChange(Articol)
// Acțiuni de eveniment
Sfârșitul procedurii

Atenţie!

Proceduri care sunt setate ca gestionare de evenimente din cod folosind metoda SetAction (), se recomandă setarea prefixului Connect_.

Atenţie!

Puteți descărca procesarea cu exemple de căutare programatică și schimbarea atributelor, comenzilor și elementelor unui formular gestionat.

Formulare în 1C: Enterprise sunt concepute pentru a afișa și edita informațiile conținute în baza de date. Formularele pot aparține unor obiecte de configurare specifice sau pot exista separat de ele și pot fi utilizate de întreaga soluție a aplicației în ansamblu.

De exemplu, referința Nomenclatură poate avea mai multe forme care vor fi utilizate în scopuri specifice - editarea unui articol din catalog, afișarea unei liste etc.:

Odată cu aceasta, pot exista forme generale care nu aparțin unor obiecte de configurare specifice - forme generale.

Forme de bază

Fiecare obiect de configurare poate fi folosit pentru a efectua unele acțiuni standard. De exemplu, orice catalog poate avea nevoie să afișeze o listă a elementelor sale, să afișeze elemente individuale ale catalogului, să afișeze un grup de catalog, să selecteze elemente și grupuri de elemente din catalog. Pentru orice document, lista acestor acțiuni va fi mult mai mică: vizualizarea unei liste de documente, selectarea dintr-o listă de documente și vizualizarea unui document separat.

Pentru a asigura executarea unor astfel de acțiuni standard cu datele obiectelor soluției aplicate, pentru fiecare dintre ele există un set de forme de bază care vor fi utilizate la efectuarea acțiunilor corespunzătoare. Oricare dintre formele subordonate acestui obiect pot fi atribuite celei principale. De exemplu, referința Nomenclaturăpot exista următoarele forme de bază:

Și la document Primirea de bunuri și serviciicompoziția principalelor forme va fi diferită:

Astfel, dacă utilizatorul dorește să vadă lista de directoare Nomenclatură sau lista documentelor Primirea de bunuri și servicii, sistemul va deschide formularul corespunzător atribuit ca formular de listă pentru aceste obiecte.

Forme generate automat

O caracteristică importantă a sistemului 1C: Enterprise 8 este mecanismul formelor generate automat. Acest mecanism eliberează dezvoltatorul de a crea toate formularele posibile pentru fiecare dintre obiectele de configurare. Este suficient ca dezvoltatorul să adauge un nou obiect de configurare, iar sistemul în sine va genera formularele necesare pentru afișarea informațiilor conținute în acest obiect în momentele necesare lucrării utilizatorului.

Astfel, dezvoltatorul trebuie să își creeze propriile forme de obiecte ale soluției aplicate numai dacă acestea ar trebui să aibă diferențe (design diferit sau comportament specific) față de formele generate automat de sistem.

Conectarea unui formular la date

Apartenența unui formular la unul sau alt obiect de configurare nu determină compoziția datelor care sunt afișate în formular. Că formularul aparține, de exemplu, unui director Nomenclatură, vă permite să îl alocați unuia dintre formularele principale pentru acest director, dar nu determină în niciun fel ce fel de date va afișa acest formular și care va fi comportamentul acestuia.

Pentru a asocia formularul cu datele, sunt utilizate detaliile formularului, care indică lista datelor afișate de formular. Toate formularele, de la sine, au același comportament, indiferent de datele pe care le afișează. Cu toate acestea, unul dintre atributele de formular îi poate fi atribuit ca principal (este evidențiat cu caractere aldine), caz în care comportamentul standard al formularului și proprietățile acestuia vor fi completate în funcție de tipul pe care îl are atributul de formular principal:

De exemplu, dacă un document este atribuit ca atribut de formular principal Primirea de bunuri și servicii, atunci când închideți formularul, sistemul vă va cere să confirmați înregistrarea și postarea acestui document. Dacă atribuim, să zicem, o carte de referință ca atribut principal al formularului Nomenclatură, nu va exista o astfel de cerere de confirmare la închiderea formularului.

Structura formei

Principala caracteristică a formularelor este că acestea nu sunt desenate în detaliu de către dezvoltator, „pixel cu pixel”. Un formular în configurație este o descriere logică a compoziției unui formular. Iar plasarea specifică a elementelor este efectuată automat de sistem atunci când este afișat formularul.

Partea afișată a formularului (vizibilă utilizatorului) este descrisă ca un arbore care conține elemente ale formularului.

Elementele pot fi câmpuri de introducere, casete de selectare, butoane radio, butoane și așa mai departe. În plus, un articol poate fi un grup care include alte elemente. Un grup poate fi reprezentat ca un panou cu un cadru, un panou cu pagini (marcaje), o pagină în sine, un panou de comandă. În plus, un element poate fi un tabel, care include și elemente (coloane). Structura elementului descrie cum va arăta formularul.

Toate funcționalitățile formularului sunt descrise sub formă de atribute și comenzi. Cerințele sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile efectuate. Astfel, dezvoltatorul din editorul de formulare trebuie să includă atributele și comenzile necesare în formular, să creeze elemente de formular care să le afișeze și, dacă este necesar, să aranjeze elementele în grupuri.

Pe baza acestei descrieri logice, sistemul generează automat aspect formulare de afișat utilizatorului. În acest caz, sistemul ia în considerare diferite proprietăți ale datelor afișate (de exemplu, tip) pentru a aranja elementele formularului cât mai convenabil pentru utilizator.

Dezvoltatorul poate influența dispunerea elementelor cu setări diferite. Poate determina ordinea elementelor, poate specifica lățimea și înălțimea dorite. Cu toate acestea, acestea sunt doar câteva informatii suplimentareajutând sistemul să afișeze formularul.

În formulare, dezvoltatorul poate utiliza nu numai comenzile formularului în sine, ci și comenzile globale utilizate în interfața de comandă a întregii configurații. În plus, a fost implementată posibilitatea de a crea comenzi parametrizabile care vor deschide alte formulare pe baza datelor specifice ale formularului curent. De exemplu, poate fi un apel al unui raport privind soldurile din depozit care este selectat în prezent sub forma unei facturi.

Și Obiect de transfer de date pentru structurarea codului, formă gestionată în mediul 1C 8.2.

Introducere

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

În 2008 a devenit disponibil 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ă modifică modelul de design al interfeței cu utilizatorul din configurație, ci 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 (modul de pornire normal și gestionat)
• Client slab
• Client web

ÎN aplicație gestionată se folosesc formulare bazate pe tehnologie nouă. Sunt chemați Formulare gestionate... Pentru a facilita tranziția, sunt acceptate și formele vechi (așa-numitele formulare obișnuite), dar funcționalitatea lor nu evoluează și sunt disponibile doar în modul de lansare a clientului gros.
Principalele diferențe între formularele gestionate pentru un dezvoltator sunt:

• Declarație, nu pixel cu pixel, descrierea structurii. Amplasarea specifică a elementelor este efectuată automat de sistem atunci când este afișat formularul.
• Toate funcționalitățile formularului sunt descrise ca rechizite și echipe... Cerințele sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile efectuate.
• Formularul este executat atât pe server, cât și pe client.
• În contextul clientului, aproape toate tipurile de aplicații sunt inaccesibile și, prin urmare, este imposibil să se schimbe datele din baza de date.
• Pentru fiecare metodă sau variabilă a formularului trebuie specificată directivă de compilarecare determină unde se execută (client sau server) și accesul la contextul formularului.

Să enumerăm directivele pentru compilarea metodelor de formular:

• & Pentru client
• & Pe server
• & OnServerWithoutContext
• & OnClientOnServerWithout Context

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

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

Să definim problema

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

Luați în considerare structura codului (modulul formular) în mai multe forme ale unuia configurație tipică și încercați să găsiți modele.
Prin structură înțelegem secțiunile de cod (cel mai adesea acestea sunt blocuri de comentarii) alocate de dezvoltator pentru gruparea metodelor și directivelor pentru compilarea acestor metode.
Exemplul 1:
Secțiunea de gestionare a evenimentelor Metodă - pe client Metodă - pe server Metodă - pe client Secțiunea de proceduri și funcții de serviciu Control funcții auxiliare de intrare
Exemplul 2:
Proceduri și funcții de service Documente de plată Valori Manipulatori de evenimente
Exemplul 3:
Proceduri de service pe server Proceduri de service pe client Proceduri de service pe server fără context Handlers de evenimente antet Handlers de evenimente de comandă
Exemplul 4:
Proceduri de uz general Formular de gestionare a evenimentelor Proceduri pentru subsistemul „informații de contact”
De fapt, structura codului lipsește sau, pentru a o spune ușor, este similară cu ceea ce era în formularele 8.1:

• Cuvinte neinformative „General, Serviciu, Auxiliar”.
• Încercări timide de a separa metodele client și server.
• Metodele sunt adesea grupate pe elemente de interfață „Lucrul cu secțiunea tabelară Produse, informații de contact”.
• Aranjamentul arbitrar al metodelor și grupurilor de coduri. De exemplu, Event Handlers pot fi într-o formă în partea de sus, în alta în partea de jos, într-o treime deloc alocată etc.
• Și să nu uităm că toate acestea se află în aceeași configurație.
• Da, există configurații în care cuvintele „General, serviciu, auxiliar” sunt întotdeauna în aceleași locuri, dar ...

De ce ai nevoie de structura codului?

• Simplificarea întreținerii.
• Simplificarea învățării.
• Fixarea principiilor generale / importante / bune.
• ... opțiunea ta

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

Să ne uităm la principiile publicate pe discurile ITS și în diferite „Ghiduri pentru dezvoltatori ...” care sunt recomandate atunci când scrieți un formular gestionat.

• Minimizați numărul de apeluri de server.
• Calcule maxime pe server.
• Apelurile de server necontextuale sunt mai rapide decât apelurile contextuale.
• Programați având în vedere interacțiunea client-server.
• etc.

Acestea sunt lozinci absolut corecte, dar cum pot fi puse în aplicare? Cum să minimizați numărul de apeluri, ce înseamnă programarea în modul client-server?

Modelele de design sau înțelepciunea generațiilor

Interacțiunea client-server a fost utilizată în diverse tehnologii software de mai bine de o duzină de ani. Răspunsul la întrebările prezentate în secțiunea anterioară a fost mult timp cunoscut și rezumat în două principii de bază.

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

Un cuvânt pentru Martin Fowler, descrierea sa de aceste principii:

• … trebuie să aibă fiecare obiect potențial destinat accesului la distanță interfață cu detalii redusepentru a minimiza numărul de apeluri necesare pentru a finaliza o anumită procedură. ... În loc să solicitați o factură și toate articolele sale separat, trebuie să citiți și să actualizați toate articolele facturii într-un singur apel. Acest lucru afectează întreaga structură a obiectului ... Rețineți: interfața de acces la distanță nu conține logică de domeniu.
• ... dacă aș fi o mamă grijulie, aș spune cu siguranță copilului meu: „Nu scrie niciodată obiecte de transfer de date!” În majoritatea cazurilor, obiectele de transfer de date nu sunt altceva decât set balonat de câmpuri ... Valoarea acestui monstru dezgustător constă doar în abilitate transmite mai multe informații prin rețea într-un singur apel - recepția pe care o are mare importanță pentru sisteme 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ă „grosieră”.
Open Parameters \u003d Structură nouă ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form \u003d OpenForm (FormName, OpenParameters);
Comparați cu stilul adoptat în v8.1.
Form \u003d GetForm (FormName); Form.Parameter1 \u003d Value1; Form.Parameter2 \u003d Value2; Form.Open ();

În contextul unui formular gestionat, există multe obiecte de migrare a datelor. Se poate distinge sistemic și dezvoltator definit.
Obiectele de sistem modelează pe client un obiect de aplicație sub forma unuia sau mai multor elemente de date de formular. Nu le puteți crea în afara legării la atributele de formular.

• DataFormsStructure
• DataFormsCollection
• DataShapesStructureCollection
• DataShapeTree

Conversia obiectelor de sistem ale transferului de date la tipurile aplicate și invers se realizează prin metode:

• Date ValueInForm ()
• FormDataValue ()
• CopyForm Data ()
• ValueBForm Attribute ()
• PropsFormVValue ()

Adesea, se utilizează o transformare explicită atunci când se adaptează o soluție existentă. Metodele se pot aștepta (utilizează caracteristici) parametrii de intrare, precum ValueTable, mai degrabă decât FormDataCollection, sau metoda a fost definită în contextul unui obiect de aplicație și nu mai este disponibilă pentru apel direct de la un formular.
Exemplul 1C v8.1:
// pe client în contextul formularului FillUserCache (OULink)
Exemplul 1C v8.2:
// pe server în contextul formularului ProcessingObject \u003d Form AttributeValue ("Obiect"); ProcessingObject.FillUserCache (DepartmentLink); ValueVFormAttribute (ProcessingObject, "Object");

Obiectele de transfer de date definite de dezvoltator sunt un mic subset al tipurilor disponibile atât pe client, cât și pe server. Parametrii și rezultatele cele mai frecvent utilizate ale metodelor de interfață „grosieră” sunt:

• Tipuri primitive (șir, număr, boolean)
• Structura
• Conformitate
• Matrice
• Referințele obiectelor aplicației (identificator unic și reprezentare textuală)

Exemplu: metoda ia o listă de comenzi pentru a schimba starea și returnează clientului o descriere a erorilor.
& OnServerWithoutContext ServerFunctionChangeOrderStatus (Comenzi, NewStatus) Erori \u003d Noua conformitate(); // [comanda] [descrierea erorii] Pentru fiecare comandă din ciclul comenzilor Începeți tranzacția (); Tentează DocOb \u003d Order.GetObject (); …. alte acțiuni, poate nu numai cu comanda ... Excepție CancelTransaction (); Errors.Insert (Order, DescriptionErrors ()); Sfârșitul încercărilor; Sfârșitul ciclului; Returnarea erorilor; EndFunction // ServerChangeOrderStatus ()

Structurarea codului

Principalele obiective pe care trebuie să le reflecte modulul de formular gestionat și abordarea soluției.

• Separați clar codul clientului și serverului. Să nu uităm că, în momentul execuției, acestea sunt două procese interacționale, în fiecare dintre care funcționalitatea disponibilă este semnificativ diferită.
• Identificarea clară a interfeței de acces la distanță, ce metode de server pot fi apelate de la client și care nu? Numele metodei interfeței la distanță încep cu prefixul Server. Acest lucru permite, atunci când citiți codul, să vedeți imediat trecerea controlului la server și simplifică utilizarea indicilor contextuale. Rețineți că recomandarea oficială (ITS) sugerează metode de numire cu postfixe, de exemplu, ca ChangeOrderStatusOnServer (). Cu toate acestea, pentru a recapitula, nu toate metodele de pe 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” marcăm doar metodele disponibile pentru client, metoda de exemplu se va numi ServerChangeOrdersStatus ().
• Citibilitate. O chestiune de gust, acceptăm comanda când modulul începe cu proceduri pentru crearea unui formular pe server și metode de acces la distanță.
• Întreținere. Locul pentru adăugarea unui nou cod trebuie să fie clar definit. Un punct important, șabloanele de metodă create automat de configurator sunt adăugate la sfârșitul modulului. Deoarece cel mai adesea, gestionarele de evenimente pentru elementele formularului sunt create automat, blocul corespunzător este situat ultimul, astfel încât să nu trageți fiecare handler într-un alt loc din modul.

Mai jos este structură de bază modul care implementează obiectivele enumerate.

• Opțiune grafică - arată clar fluxul principal de execuție.
• Varianta text este un exemplu de design de șablon pentru inserarea rapidă a unei structuri într-un nou modul de formular.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="„Data \u003d”"/> // <Описание> // // //////////////////////////////////////////////////// //////////////////////////////// // VARIABILE MODULULUI //////////////// //////////////////////////////////////////////////// ////////////// // PE SERVER // ******* EVENIMENTE PE SERVER ******* & Procedura AtServer OnCreateAtServer (Anulare, StandardProcessing) // Introduceți conținutul handlerului EndProcedure // ******* INTERFATA DE ACCES LA DISTANȚĂ ******* // ******* LOGICA AFACERILOR PE ******* SERVER ///////// //////////////////////////////////////////////////// ///////////////////// // METODE GENERALE DE CLIENT ȘI SERVER ////////////////////// //////////////////////////////////////////////////// //////// // PE CLIENT // ******* LOGICA AFACERILOR PE CLIENT ******* // ******* ECHIPE ******* // ******* EVENIMENTE PE CLIENT ******* ///////////////////////////// /////////////////////////////////////////////////// / OPERATORII PROGRAMULUI PRINCIPAL

Întrebări conexe

În concluzie, schițăm mai multe domenii la care sunt utile să ne gândim la programarea interacțiunii client-server.

• Opțiuni de implementare a interfeței de acces la distanță... Asincronie, granularitate ...
• Caching. În 1C, au luat o decizie arhitecturală nereușită, introducând cache-ul doar la nivelul metodelor de apelare a modulelor comune și neavând capacități de control (timp de relevanță, resetare la cerere).
• Apeluri implicite ale serverului... Nu uitați de caracteristicile tehnologice, multe operațiuni „inofensive” pe client provoacă platforma să contacteze serverul.