Detalii de bază ale formularului. Detalii formulare gestionate (1Cv8) Formularele gestionate 1c adaugă detalii programatic

Detalii formular

Un set de detalii de formular descrie compoziția datelor care sunt afișate, editate sau stocate în formular. În același timp, detaliile formularului în sine nu oferă posibilitatea de a afișa și edita date. Elementele de formular (vezi secțiunea „Elemente de formular” a acestui capitol) asociate cu detaliile formularului sunt utilizate pentru afișare și editare. Setul de toate detaliile formularului va fi numit date formular.

Important! Trebuie reținut că, spre deosebire de formularele obișnuite, toate datele dintr-o formă gestionată trebuie descrise sub formă de detalii. Nu este permisă utilizarea variabilelor modulului de formular ca surse de date pentru elementele de formular.

Este posibil să se atribuie Detalii de bază ale formularului, adică atribute care vor determina funcționalitatea standard a formularului (extensia formularului). Trebuie amintit că o formă nu poate avea decât un singur atribut principal.

Extensie formular– acestea sunt proprietăți suplimentare, metode și parametri de formă ai obiectului ManagedForm, caracteristice obiectului care este elementul principal al formularului.

În timpul procesului de dezvoltare a formularului, puteți seta în mod explicit capacitatea de a vizualiza și edita detalii specifice formularului, în termeni de roluri, folosind proprietățile Vizualizare și Editare (pentru mai multe detalii, consultați secțiunea „Setări de formular bazate pe roluri” din „Editori” ” capitolul). În plus, disponibilitatea unui anumit atribut în formularul în sine poate fi configurată folosind opțiuni funcționale (mai multe detalii despre opțiunile funcționale pot fi găsite în capitolul „Gestionarea interfeței de configurare”).

Proprietatea atributului formularului Date salvate este un semn că o modificare interactivă a detaliilor va duce la încercarea de a bloca datele formularului pentru editare, precum și la setarea automată a steagului de modificare a formularului.

Tipuri de date disponibile într-o formă gestionată

De asemenea, un formular gestionat diferă de un formular obișnuit prin tipurile de date cu care lucrează. Dacă forma normală funcționează cu majoritatea tipurilor pe care 1C:Enterprise le oferă (inclusiv tipurile DirectoryObject, DocumentObject etc.), atunci în forma gestionată se pot distinge următoarele categorii de tipuri:

  • tipurile care sunt utilizate direct în formular sunt acele tipuri care există pe partea clientului subțire și Web (de exemplu, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • tipuri care vor fi convertite în tipuri speciale de date — tipuri de date de formular gestionate. Astfel de tipuri sunt afișate în lista de detalii de formular între paranteze, de exemplu (DirectoryObject.Products);
  • lista dinamică (pentru mai multe detalii, consultați secțiunea „Lista dinamică” a acestui capitol).

Conversia obiectelor aplicației în date de formular

Unele tipuri de aplicații (cum ar fi DirectoryObject, etc.) nu există pe partea de client subțire și Web (consultați capitolul Conceptul de aplicație gestionată pentru mai multe detalii). Prin urmare, pentru a reprezenta astfel de tipuri de aplicații în formular, platforma a introdus tipuri speciale de date concepute să funcționeze în formulare gestionate. Această caracteristică a unei aplicații gestionate face necesară convertirea obiectelor aplicației în date de formular (și invers).

Sunt utilizate următoarele tipuri de date:

  • Form DataStructure – conține un set de proprietăți de tip arbitrar. Proprietățile pot fi alte structuri, colecții sau structuri cu colecții. Acest tip este reprezentat, de exemplu, sub forma DirectoryObject.
  • O FormDataCollection este o listă de valori tastate, similară cu o matrice. Un element de colecție este accesat prin index sau identificator. Accesul prin ID poate să nu fie disponibil în unele cazuri. Acest lucru se datorează tipului de obiect aplicație care este reprezentat de această colecție. Identificatorul poate fi orice număr întreg. Acest tip este reprezentat, de exemplu, sub forma unei părți tabelare.
  • Formularul DataStructureWithCollection este un obiect care este reprezentat ca o structură și o colecție în același timp. Poate fi tratat ca oricare dintre aceste entități. Acest tip reprezintă, de exemplu, un set de înregistrări într-un formular.
  • Form DataTree – un obiect conceput pentru a stoca date ierarhice.

Un obiect de aplicație este reprezentat fie de unul sau mai multe elemente de date de formular. În general, ierarhia și compoziția datelor din formular depind de complexitatea și interconectarea obiectelor aplicației din formularul gestionat.

De exemplu, un document care conține o parte tabelară va fi reprezentat de un obiect de tip FormDataStructure (documentul în sine), căruia îi este subordonat un obiect de tip FormDataCollection (partea tabelară a documentului).

Important! Când se dezvoltă o configurație, este important să rețineți că obiectele aplicației sunt disponibile numai pe server, în timp ce obiectele de date din formular pot fi utilizate atât pe server, cât și pe client.

Transmiterea datelor între părțile client și server ale unui formular gestionat

De fapt, putem spune că datele formularului sunt o reprezentare unificată a datelor din diverse obiecte de aplicație cu care formularul funcționează uniform și care sunt prezente atât pe server, cât și pe client. Adică, formularul conține o „proiecție” a datelor obiect aplicației sub forma propriilor tipuri de date și efectuează conversie între ele dacă este necesar. Cu toate acestea, dacă dezvoltatorul de configurație implementează propriul algoritm de procesare a datelor, atunci trebuie să efectueze conversia datelor (de la tipuri specializate la tipuri de aplicații și invers) în mod independent.

La editarea detaliilor formularului într-un editor specializat (pentru mai multe detalii, vezi secțiunea „Detalii formular” din capitolul „Editori”), este posibil să se influențeze transferul de date între client și server în timp ce formularul rulează. Coloana editorului de detalii este folosită pentru aceasta. Utilizați întotdeauna. Efectul acestei proprietăți diferă pentru trei tipuri de atribute:

  • Pentru un atribut subordonat unei liste dinamice (coloana listă dinamică):
    • proprietate activată – atributul este întotdeauna citit din baza de date și inclus în datele formularului;
    • proprietatea este dezactivată - atributul este citit din baza de date și inclus în datele formularului numai atunci când există un element de formular vizibil asociat cu atributul sau cu atributul său subordonat.
  • Pentru recuzita subordonată colecției de mișcare:
    • proprietatea este activată – mișcările documentelor sunt citite din baza de date și vor fi prezente în datele din formular;
    • proprietatea este dezactivată - mișcările documentelor nu vor fi citite din baza de date și nu vor fi incluse în datele formularului (dacă nu există niciun element de formular care să facă referire la mișcările documentului).
  • Alte detalii formular:
    • proprietatea este activată – atributul va fi prezent în datele formularului, indiferent dacă există sau nu cel puțin un element de formular care este asociat cu atributul sau cu atributul subordonat acestuia;
    • proprietatea este dezactivată - atributul va fi prezent în datele formularului numai dacă există un element de formular asociat cu atributul sau cu atributul subordonat acestuia. Spre deosebire de atributele listelor dinamice, vizibilitatea elementului asociat cu atributul nu contează aici.

Notă. Trebuie reținut că proprietatea setată pe atributul părinte afectează toate atributele subordonate. De exemplu, dacă proprietatea Utilizare este întotdeauna ștearsă pentru partea tabelară a documentului, atunci sistemul consideră că această proprietate este ștersă și pentru toate detaliile subordonate (în ciuda stării reale a proprietății).

Metode pentru conversia datelor obiect aplicației în date de formular

Pentru a converti obiectele aplicației în date de formular și înapoi, există un set de metode globale:

  • ValueInFormData(),
  • FormDataInValue(),
  • CopyFormData().

Important! Metodele care funcționează cu obiectele aplicației sunt disponibile numai în procedurile de server. Metoda de copiere a valorilor între datele formularului este disponibilă pe server și pe client, deoarece nu necesită obiecte de aplicație ca parametri.

Când convertiți datele formularului într-un obiect de aplicație, trebuie să luați în considerare compatibilitatea acestora.

  • ValueInFormData() – convertește un obiect de tip aplicație în date de formular;
  • FormDataInValue() – convertește datele formularului într-un obiect de tip aplicație;
  • CopyFormData() – copiază datele formularului care au o structură compatibilă. Returnează True dacă copia a avut succes sau False dacă structura obiectului este incompatibilă.

Notă. La efectuarea acțiunilor standard (deschiderea unui formular, executarea unei comenzi standard Write etc.) a unui formular cu detaliile principale, conversia se realizează automat.

Să dăm un exemplu despre cum să utilizați transformarea datelor în proprii algoritmi.

&OnServerProcedure Când CreateOnServer (Eșec, Procesare standard)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

Sfârșitul procedurii

&OnClient Procedure Write()

WriteOnServer();

Sfârșitul procedurii

&OnServer Procedura WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Sfârșitul procedurii

Obiectul ManagedForm are și metode disponibile pe server:

  • ValueВFormAttribute() – convertește un obiect de tip aplicație în atributul de formular specificat.
  • FormAttributeVValue() – convertește un atribut de date de formular într-un obiect de tip aplicație.

Utilizarea acestor metode este de obicei mai convenabilă, deoarece acestea au, de exemplu, informații despre tipul de detalii ale formularului. În plus, metoda Form AttributesValue() stabilește corespondența dintre datele din formular și obiect, care este utilizată la generarea mesajelor. Puteți citi mai multe despre acest lucru în capitolul „Capacitățile de navigare a serviciului”.

Să dăm un exemplu de utilizare a acestor metode.

&OnServer Procedura RecalculateOnServer()

// Convertește atributul Object într-un obiect aplicație. Document = Form AttributesValue("Obiect"); // Efectuează recalcularea utilizând metoda definită în modulul document. Document.Recalculate(); // Convertește obiectul aplicației înapoi într-o prop. ValueВFormAttributes(Document, „Obiect”);

Sfârșitul procedurii

Interfață software

FormDataTree

  • FindById
  • GetItems

Descriere:

Proiectat pentru a modela un arbore în date de formulare gestionate.

Acest obiect poate fi serializat către/de la XDTO. Tipul XDTO corespunzător acestui obiect este definit în spațiul de nume. Nume tip XDTO:

GetItems

Sintaxă:

GetItems()

Valoare returnată:

Tip: Form DataCollection of Tree Elements.

Descriere:

Obține o colecție de elemente de arbore de nivel superior.

Disponibilitate: client, server, client subțire, client web.

FindById

Sintaxă:

FindById(<Идентификатор>)

Opțiuni:

<Идентификатор>(necesar)

Tip: Număr. Identificator de element arbore.

Valoare returnată:

Tip: FormDataTreeElement.

Descriere:

Obține un element de colecție după ID.

Disponibilitate: client, server, client subțire, client web.

FormDataTreeItem

Proprietăți:

<Имя свойства> (<Имя свойства>)

  • GetId (GetId)
  • GetParent
  • GetItems
  • Proprietate

Descriere:

Element de arbore de date din formular.

FormDataTreeItemCollection

Elemente de colecție: DataFormTreeElement

Pentru un obiect, este posibil să parcurgeți colecția folosind operatorul Pentru fiecare... Din... Buclă. Parcursul selectează elementele colecției. Este posibil să accesați un element de colecție folosind operatorul [...]. Indexul elementului este transmis ca argument.

  • Introduce
  • Adăuga
  • Index (IndexOf)
  • Numara
  • clar
  • obține
  • Mișcare
  • Șterge

Descriere:

Colectie de elemente din lemn.

Disponibilitate: client, server, client subțire, client web.

Vezi si:

  • FormDataTreeElement, metoda GetElements
  • DataFormTree, metoda GetItems

Caracteristicile lucrului cu un arbore de valori

Actualizare arbore

Există o problemă cade platforme la actualizarea arborelui.

Dacă orice nod din arbore a fost extins și a fost selectat un nod subordonat, atunci când actualizați arborele cu funcția ValueInFormData platforma cade.

Soluție: trebuie să ștergeți arborele înainte de a actualiza.

De exemplu:

&Pe server Procedura ClearTree(elements) Pentru fiecare element din elemente Loop ClearTree(element.GetElements()); EndCycle; elemente.Clear(); Sfârșitul procedurii

&Pe Procedura Server Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Sfârșitul procedurii

&OnClient Procedura OnDateOnChange(Element) Fill ConceptTree(); Sfârșitul procedurii

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

Modificarea software-ului a formularului poate fi necesară în mai multe cazuri:

  • La finalizarea configurațiilor standard pentru a facilita procedura de actualizare ulterioară. În acest caz, doar modulul formular va fi modificat. Modulele sunt mult mai ușor de actualizat decât formularele.
  • La implementarea unor algoritmi comuni. De exemplu, în subsistemul „Interzicerea editării detaliilor obiectului”, un buton poate fi creat în mod programatic pentru toate obiectele conectate la subsistem pentru a permite posibilitatea de a edita detalii.
  • La implementarea unor algoritmi specifici. De exemplu, în directorul Nomenclatură, sunt create câmpuri pentru editarea detaliilor suplimentare.

Într-o formă gestionată, puteți adăuga, modifica și șterge în mod programatic:

  • rechizite;
  • echipele locale;
  • elemente.

Toate aceste operațiuni sunt posibile numai pe server.

Remodelarea programatică are limitări:

  • Puteți șterge numai detalii/comenzi/elemente adăugate programatic. Nu puteți șterge în mod programatic obiectele create în configurator.
  • Nu puteți atribui un atribut ca principal.

Modificarea comenzilor de formular

Pentru a gestiona compoziția comenzilor pentru un obiect ManagedForm există o colecție Echipe

    Adăuga (< ИмяКоманды >)

    Cantitate ()

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

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

Colecția Teams este disponibilă atât pe client, cât și pe server. Puteți modifica colecția (metodele Add() și Delete()) 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 comenzi de formular, să creăm o nouă comandă ChangeHistory cu titlul „ChangeHistory...”, care va apela handler-ul Afișează Istoricul(). Crearea are loc atunci când formularul este deschis.

&Pe server
Procedură WhenCreatingOnServer (Eșec, Procesare standard)
Echipă = Echipe. Adăuga( „Istoria schimbărilor”);
Echipă . Acțiune = ;
Echipă . Titlu = „Istoria schimbărilor...”;
Sfârșitul procedurii
&OnClient
Procedură Connectable_DisplayHistory(Comandă)
// acțiuni de comandă
Sfârșitul procedurii

Managerul de comenzi trebuie să fie localizat pe un formular și să aibă o directivă de compilare &OnClient.

Modificarea detaliilor formularului

Citirea compoziției detaliilor formularului este efectuată de funcție Obțineți detalii(< Путь >) returnând o matrice de tip FormAttributes. Parametrul funcției specifică calea către atributul părinte (sub formă de șir). Dacă parametrul este omis sau este specificat un șir gol, sunt returnate detaliile de nivel superior.

Modificarea detaliilor se face folosind metoda Modificați detaliile(<Detalii adăugate>, <Detalii detașabile>) obiect ManagedForm. La parametri Detalii adăugateȘi Detalii detașabile Sunt transmise matrice cu elemente de tip Form Attributes.

Atenţie!

Procesul de modificare a compoziției detaliilor necesită destul de mult resurse. Forma este de fapt recreată. În acest sens, lucrul cu detaliile formularului se efectuează în modul lot.

Să creăm un nou atribut de formular cu numele Cumpărător:


AddedDetails = New Array;
Detalii adăugate. Adăugați (Atribute noi de formular(„Cumpărător”, Descriere tip nou („DirectoryLink. Contrapărți”), „Client”);

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

Schimbarea elementelor de formular

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

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

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

    Cantitate ()

    Găsi (< Имя >)

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

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

Colecția Items este disponibilă atât pe client, cât și pe server. Modificați o colecție (Insert methods () , Add () , Move () și Delete () ) sunt disponibile 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 de colectare pot fi:

  • FormGroup;
  • FormTable;
  • FormField;
  • Butonul Formular.

Puteți atribui programatic handler-uri de evenimente elementelor de formular. Metoda este destinată acestor scopuri SetAction(< ИмяСобытия>, < Действие >) .

Să ne uităm la câteva dintre cele mai comune exemple de lucru cu comenzi, detalii și elemente de formular.

Adăugarea unei comenzi și a butonului asociat:

// Creați o comandă
Echipă = Echipe. Adăuga( „Istoria schimbărilor”);
Echipă . Acțiune = „Plug-in_DisplayHistory”; // Formularul trebuie să conțină o procedură cu numele specificat
Echipă . Titlu = „Istoria schimbărilor...”;
// Creați un buton și asociați-l cu o comandă
Element = Articole. Adăuga( „Istoria schimbărilor”, Type("FormButton" ));
Element.CommandName = „Istoria schimbărilor”;

Adăugarea unui atribut și a câmpului de intrare asociat:

// Descrierea detaliilor adăugate
AddedDetails = New Array;
Detalii adăugate. Adăuga(Propoziții de formulare noi („Cumpărător”, Descriere tip nou ( „DirectoryLink. Contrapărți”), „Client” ));
// Modificarea compoziției detaliilor
Modificare detalii(Detalii adăugate);
// Crearea unui câmp de intrare și conectarea la atribut
Element = Articole. Adaugă(„Cumparator” , Tip(„FormField” ));
Element . Vizualizare = FormFieldView. Câmp de intrare;
Element . PathToData= "Cumparator";

Atribuirea unui handler de evenimente unui element de formular:

ArticolClient. SetAction("Când se schimbă", „Connected_BuyerOnChange”);

&OnClient
Procedură Connected_BuyerOnChange(Element)
// Acțiuni de eveniment
Sfârșitul procedurii

Atenţie!

Proceduri care sunt setate ca handler de evenimente din cod folosind metoda SetAction(), este recomandat să setați prefixul Connectable_.

Atenţie!

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

Detaliile formularului asigură legătura acestuia cu datele. În acest caz, unul (și doar unul) dintre detalii poate fi desemnat ca principal; poate să nu fie neapărat tipul de date la care desenăm formularul. Dar comportamentul formularului va depinde de tipul de date al atributului principal. Pe lângă schimbarea comportamentului formularului, contextul modulului formular se schimbă. Împreună cu metodele și proprietățile formei, metodele și proprietățile obiectului, care este valoarea atributului principal, devin disponibile în acesta. Este important ca formularele de tip Free Form să nu aibă detalii de bază. În acest caz, comportamentul formularului este determinat doar de setările utilizatorului. Să luăm în considerare întrebările despre detaliile de bază.

Întrebarea 10.05 a examenului 1C: Platform Professional. Pentru ce este folosit principalul atribut al formularului?

  1. Definește sursa de date pentru formular în ansamblu
  2. Definește capabilitățile standard ale platformei de lucru cu formularul cu date de tipul specificat în atributul principal
  3. Pentru a oferi posibilitatea de a accesa programatic detaliile obiectului din contextul formularului local
  4. Oferă vizualizarea detaliilor obiectului în dialogul formular
  5. 2 și 3 sunt corecte
  6. 1 și 2 sunt corecte

Răspunsul corect este numărul șase, vezi mai sus.


Întrebarea 10.06 a examenului 1C: Platform Professional. Pentru ce sunt necesare detaliile formularului?
  1. Pentru a descrie conținutul datelor care sunt afișate, editate sau stocate într-un formular
  2. Pentru a afișa și edita date într-un formular
  3. 1 și 2 sunt corecte

Răspunsul corect este al treilea - ambele.

Întrebarea 10.07 a examenului 1C: Platform Professional. Pentru a atribui atribute de bază unei forme controlate arbitrare...

  1. Trebuie să bifați caseta de selectare „Detalii de bază” din proprietățile atributelor formularului
  2. trebuie să completați proprietatea „Date” a formularului selectând atributul necesar al formularului

Răspunsul corect este al doilea:

Întrebarea 10.08 a examenului 1C: Platform Professional. Pentru a atribui detaliile principale unei forme regulate arbitrare...
  1. formularul trebuie să fie cel principal, detaliile principale sunt determinate automat
  2. Trebuie să bifați caseta de selectare „Detalii de bază” din proprietățile atributelor formularului
  3. trebuie să mergeți la meniul „Editare”, „Detalii de bază” și să selectați valoarea dorită
  4. trebuie să completați proprietatea „Date” a formularului selectând atributul necesar al formularului

Al patrulea răspuns corect este:

Detaliile principale sunt evidențiate cu caractere aldine:

Întrebarea 10.09 a examenului 1C: Platform Professional. Dacă există un atribut principal al formularului, este posibil să adăugați un alt atribut principal?
  1. Este imposibil
  2. Este posibil prin atribuirea valorii adecvate proprietății atributului formular
  3. Este posibil doar programatic, la accesarea obiectului „Form”.
  4. Acest lucru este posibil prin adăugarea unei alte valori proprietății formularului corespunzătoare

Răspunsul corect este primul, există strict o cerință principală, deoarece legătura cu obiectul trebuie să fie lipsită de ambiguitate.

Întrebarea 10.113 a examenului 1C: Platform Professional. Care dintre detaliile formularului prezentat în figură este principala?

  1. Lista cursurilor valutare
  2. DirectoryObject
  3. Formularele de director nu au detalii de bază
  4. Formularele de director au toate detaliile de bază
Al doilea răspuns corect este cel îngroșat.

Formularul este controlat prin diferite elemente de formular, care sunt situate ierarhic pe filă Elemente designer de forme. Cel mai important element este forma în sine, care se află în vârful ierarhiei elementelor, iar elementele rămase îi sunt subordonate.

Toate elementele formularului pot fi împărțite în cinci grupe: câmpuri, elemente de grupare, butoane, decorațiuni și tabele. În articolele mele voi analiza fiecare dintre grupuri. În acest articol, vom începe să studiem unul dintre tipurile de element de câmp - câmp de intrare, dar înainte de asta vom învăța cum să adăugați un element în formular.

Adăugarea de elemente într-un formular

Acest lucru se face destul de simplu: trebuie să selectați elementul Formăîn fereastra Elemente de design formular și faceți clic pe butonul „Adăugați”. După aceasta, se va deschide o fereastră în care trebuie să selectați tipul de element dorit

După selecție, elementul dorit va apărea în fereastră Elemente.

Element de formular gestionat Camp

Să ne uităm la un element de formular gestionat Camp. Acest element este necesar pentru a introduce informații în formular. Și, de asemenea, pentru a afișa orice informație. După ce adăugați acest element în formular, paleta de proprietăți a elementului de formular se va deschide în partea dreaptă. Pentru moment, ar trebui să fiți interesat de două proprietăți – DataPath și View.

În proprietatea DataPath, dezvoltatorul poate asocia un element de formular cu atributul de formular dorit. Vă rugăm să rețineți că după ce elementul a fost adăugat Câmp de intrare pe formular nu a fost afișat pe formularul propriu-zis. Acest lucru sa întâmplat deoarece noul nostru element nu este asociat cu . De exemplu, am creat mai multe atribute pe formularul de procesare cu diferite tipuri primitive și un atribut cu un tip de referință.

Acum să conectăm elementul nostru de formular recent adăugat cu unul dintre detalii. Pentru a face acest lucru, selectați atributul dorit din proprietatea PathKData a elementului.

După aceasta, proprietățile DataPath și View vor fi completate, iar elementul în sine va fi afișat în vizualizarea formularului.

Acordați atenție proprietății elementului Vedere. Această proprietate determină funcționalitatea câmpului de intrare. Puteți selecta diferite valori pentru această proprietate.

În funcție de valoarea selectată, funcționalitatea va fi determinată. În figurile de mai sus, valoarea selectată este - câmp de intrare, adică putem introduce orice valoare în acest câmp de intrare și dacă selectăm o valoare câmp de etichetă, atunci nu vom putea introduce nimic.

Această valoare a proprietății Vedere Câmpurile de introducere sunt ușor de selectat atunci când trebuie doar să afișați informații de ajutor utilizatorului.

Acum să adăugăm un nou element de formular cu tip Câmp de intrareși conectați-l cu recuzita DetaliiData prin proprietatea deja familiară pentru noi DataPath

După cum puteți vedea, aspectul câmpului de intrare s-a schimbat și posibila selecție a valorilor pentru proprietatea Vizualizare se va modifica și ea.

Astfel, concluzionăm că funcționalitatea câmpului de intrare depinde de tipul de atribut.

Pentru recuzită cu tip boolean Următoarele valori ale proprietăților de vizualizare vor fi disponibile.

Și pentru atributele cu un tip de referință, alte valori ale proprietății View vor fi disponibile.

Lucrări mai detaliate cu elemente de formular folosind exemple practice sunt prezentate în cartea „Bazele dezvoltării în 1C: Taxi. Dezvoltare gestionată de aplicații în 12 pași”.

Uneori se pare că învățarea limbajului de programare în 1C este complicată și dificilă. De fapt, programarea în 1C este ușoară. Cărțile mele vă vor ajuta să stăpâniți rapid și ușor programarea în 1C: și „Elementele de bază ale dezvoltării în 1C: Taxi”

Învață programarea în 1C cu ajutorul cărții mele „Programare în 1C în 11 pași”

  1. Fără termeni tehnici complicati.
  2. Peste 700 de pagini de material practic.
  3. Fiecare sarcină este însoțită de un desen (captură de ecran).
  4. O colecție de probleme pentru teme.
  5. Cartea este scrisă într-un limbaj clar și simplu - pentru un începător.

Această carte este potrivită pentru cei care au început deja programarea și întâmpină anumite dificultăți cu acest subiect și pentru cei care programează de mult timp, dar nu au lucrat niciodată cu formulare gestionate 1C.

  1. Fără termeni tehnici complexi;
  2. Peste 600 de pagini de material practic;
  3. Fiecare exemplu este însoțit de un desen (captură de ecran);
  4. Cartea este trimisă prin e-mail în format PDF. Poate fi deschis pe orice dispozitiv!

Cod promoțional pentru o reducere de 15% - 48PVXHeYu


Dacă această lecție te-a ajutat să rezolvi vreo problemă, ți-a plăcut sau ti-a fost utilă, atunci poți să-mi susții proiectul donând orice sumă:

Puteți plăti manual:

Yandex.Bani - 410012882996301
Web Money - R955262494655

Alăturați-vă grupurilor mele.

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

Introducere

Să începem cu o scurtă descriere a conceptului de „formă gestionată” și a conceptelor conexe ale platformei 1C. Cunoscătorii de platforme ar putea dori să omite această secțiune.

În 2008, a devenit disponibilă o nouă versiune a platformei 1C: Enterprise 8.2 (denumită în continuare Aplicația Gestionată), care schimbă complet întregul nivel de lucru cu interfața. Aceasta include interfața de comandă, formularele și sistemul de ferestre. În același timp, nu numai că se schimbă modelul de dezvoltare a interfeței cu utilizatorul în configurație, dar este propusă și o nouă arhitectură de separare a 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
Aplicația gestionată utilizează formulare construite pe tehnologie nouă. Sunt chemați Formulare gestionate. Pentru a ușura tranziția, sunt acceptate și formularele anterioare (așa-numitele formulare Regular), dar funcționalitatea lor nu este dezvoltată și sunt disponibile doar în modul de lansare a clientului gros.
Principalele diferențe ale formularelor gestionate pentru un dezvoltator:
  • Descriere declarativă, nu „pixel cu pixel” a structurii. Amplasarea specifică a elementelor este efectuată automat de către sistem atunci când formularul este afișat.
  • Toate funcționalitățile formularului sunt descrise ca DetaliiȘi echipe. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate.
  • Formularul rulează atât pe server, cât și pe client.
  • În contextul clientului, aproape toate tipurile de aplicații sunt indisponibile și, în consecință, este imposibil să se modifice datele din baza de informații.
  • Pentru fiecare metodă sau variabilă de formă, aceasta trebuie specificată directivă de compilare, definirea locației de execuție (client sau server) și accesul la contextul formularului.
Să enumerăm directivele pentru compilarea metodelor de formulare:
  • &OnClient
  • &Pe server
  • &OnServerWithout Context
  • &OnClientOnServerWithout Context
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 descrierea declarativă, elementele de recuzită, directivele 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 este utilizată în mod 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, au dezvoltat dezvoltatorii o înțelegere comună a principiilor interacțiunii client-server la crearea formularelor și s-a schimbat abordarea implementării modulelor software în noile realități arhitecturale?

Să ne uităm la structura codului (modul formular) în mai multe forme ale aceleiași configurații standard și să încercăm să găsim modele.
Prin structură înțelegem secțiuni de cod (cel mai adesea acestea sunt blocuri de comentarii) alocate de dezvoltator pentru a grupa metode și directive de compilare pentru aceste 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 Manipulatori 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 de formulare Proceduri ale subsistemului „informații de contact”.
În esență, structura codului lipsește sau, pentru a spune ușor, este similară cu ceea ce era în Forms 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 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 într-o alta, deloc evidențiate într-o a treia, etc.
  • Și să nu uităm că toate acestea sunt într-o singură 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 structură de cod?
  • Simplificarea întreținerii.
  • Simplificați învățarea.
  • Înregistrarea 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 discuri ITS și în diverse „Ghiduri pentru dezvoltatori...” care sunt recomandate atunci când scrieți un formular gestionat.
  • Minimizați numărul de apeluri pe server.
  • Calcul maxim pe server.
  • Apelurile non-contextuale ale serverului sunt mai rapide decât cele contextuale.
  • Program cu comunicarea client-server în minte.
  • și așa mai departe.
Acestea sunt sloganuri care sunt absolut adevărate, dar cum să le implementăm? 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)
Un cuvânt de la 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 articolele ei separat, trebuie să citiți și să actualizați toate elementele facturii într-o singură solicitare. 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 transfer de date nu sunt altceva decât set câmp umflat... Valoarea acestui monstru dezgustător constă numai în posibilitatea transmite mai multe informații prin rețea într-un singur apel- o tehnică de mare importanță pentru sistemele distribuite.
Exemple de șabloane în platforma 1C
Interfața de programare a aplicației disponibilă dezvoltatorului atunci când dezvoltă un formular gestionat conține multe exemple ale acestor principii.
De exemplu, metoda OpenForm(), o interfață tipică „aspră”.
Parametri de deschidere = Structură nouă(„Parametru1, Parametru2, Parametru3”, Valoare1, Valoare2, Valoare3); Form = OpenForm(FormName, OpeningParameters);
Comparați cu stilul adoptat în v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

În contextul unui formular gestionat, există multe „Obiecte de transfer de date”. Puteți selecta 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. Este imposibil să le creați fără referire la detaliile formularului.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Conversia obiectelor de transfer de date de sistem în tipuri de aplicații și invers se realizează folosind următoarele metode:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Adesea, conversia explicită este utilizată atunci când se adaptează o soluție existentă. Metodele pot aștepta (folosește caracteristici) parametri de intrare, cum ar fi ValueTable, mai degrabă decât FormDataCollection, 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 FillUserCache(DepartmentLink)
Exemplul 1C v8.2:
// pe server în contextul formularului ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueÂFormAttributes(ProcessingObject, "Object");

Obiectele de transfer de date, a căror structură este determinată de dezvoltator, sunt un mic subset al tipurilor disponibile atât pe client, cât și pe server. Cel mai adesea, următoarele sunt utilizate ca parametri și rezultate ale metodelor unei interfețe „groșate”:

  • Tipuri primitive (șir, număr, boolean)
  • Structura
  • Corespondenţă
  • Matrice
  • Legături către obiectele aplicației (identificator unic și reprezentare text)
Exemplu: metoda acceptă o listă de comenzi pentru schimbarea statutului și returnează clientului o descriere a erorilor.
&OnServerWithoutContext Funcția ServerChangeOrderStatus(Comenzi, NewStatus) Erori = Potrivire nouă(); // [comanda][descrierea erorii] Pentru fiecare comandă din ciclul comenzi StartTransaction(); Încercați DocOb = Order.GetObject(); …. alte actiuni, posibile nu numai cu comanda... Exceptie CancelTransaction(); Errors.Insert(Comandă, ErrorDescription()); EndTempt; 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ă, fiecare dintre ele având funcționalități disponibile semnificativ diferite.
  • Identificarea 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 transferul de control către server în timp ce citiți codul și simplifică utilizarea ajutorului contextual. Rețineți că recomandarea oficială (ITS) sugerează metode de denumire cu postfixe, de exemplu, ChangeOrderStatusOnServer(). Cu toate acestea, repetăm ​​că 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” marchem doar metodele disponibile pentru client; să numim metoda exemplu 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. Trebuie să existe o locație clară pentru adăugarea unui cod nou. Un punct important este că șabloanele de metodă create automat de configurator sunt adăugate la sfârșitul modulului. Deoarece manipulatorii de evenimente pentru elementele de formular sunt cel mai adesea creați automat, blocul corespunzător este situat 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.
  • Opțiunea text este un exemplu de design șablon pentru inserarea rapidă a unei structuri într-un nou modul de formular.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="„Data=""/> // <Описание> // // //////////////////////////////////////////////////////////////////// ////////////////////////////// VARIABILE DE MODUL ////////////////// // ////////////////////////////////////////////////////////////////////// ////////// // PE SERVER //******* EVENIMENTE PE SERVER ******* &Pe Procedura Server când este creată pe server (Eșec, Procesare standard) / /Inserați conținutul handler-ului Sfârșitul procedurii //******* INTERFAȚA DE ACCES LA DISTANȚĂ ******* //******* LOGICA DE AFACERI PE SERVER ****** ///////// ///////////////////////////////////////////////////////////// /////// //////////////////// // METODE COMUNE DE CLIENT ȘI SERVER //////////////// /////// /////////////////////////////////////////////////////////////// ///// //////// // PE CLIENT //******* LOGICA DE AFACERI PE CLIENT ******* //******* ECHIPA * ****** //******* EVENIMENTE CLIENȚI ******* //////////////////////////// ///// ///////////////////////////////////////////////////////////////// // / / PRINCIPALI OPERATORI DE PROGRAM

Întrebări înrudite
În concluzie, vom schița câteva domenii la care este util să ne gândim atunci când programați interacțiunea client-server.
  • Opțiuni de implementare a interfeței de acces la distanță. Asincronie, nivel de detaliu...
  • Memorarea în cache. 1C a luat o decizie arhitecturală nereușită, introducând memorarea în cache doar la nivelul metodelor de apelare a modulelor comune și neasigurând capabilități de control (timp de relevanță, resetare la cerere).
  • Apeluri implicite pe server. Nu uitați de caracteristicile tehnologice; multe operațiuni „inofensive” pe client provoacă platforma să contacteze serverul.


Publicații conexe