Formulare gestionate 1s 8.3. Sub capotă sunt forme controlate. Conectarea unui formular la date

Formeîn 1C:Enterprise sunt destinate pentru afișarea și editarea informațiilor conținute în baza de date. Formularele pot aparține unor obiecte de configurare specifice sau pot exista separat de acestea și sunt utilizate de întreaga soluție de aplicație.

De exemplu, un director Nomenclatură poate avea mai multe forme care vor fi folosite în scopuri specifice - editarea unui element de director, afișarea unei liste etc.:

Alături de 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, pentru orice director, poate fi necesar să afișați o listă a elementelor acestuia, să afișați elemente individuale ale directorului, să afișați un grup din director, să selectați elemente și grupuri de elemente din director. 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 se asigura că astfel de acțiuni standard sunt efectuate cu datele obiectelor soluției aplicației, pentru fiecare dintre ele există un set de formulare de bază care vor fi utilizate la efectuarea acțiunilor corespunzătoare. Oricare dintre formele subordonate acestui obiect poate fi atribuită ca fiind cea principală. De exemplu, în director Nomenclatură Pot exista următoarele forme de bază:

Și documentul Recepția de bunuri și servicii compoziția principalelor forme va fi diferită:

Astfel, dacă utilizatorul dorește să vizualizeze lista de directoare Nomenclatură sau lista de documente Recepția de bunuri și servicii, sistemul va deschide formularul corespunzător desemnat ca formular de listă pentru aceste obiecte.

Formulare generate automat

O caracteristică importantă a sistemului 1C:Enterprise 8 este mecanismul formularelor autogenerate. Acest mecanism eliberează dezvoltatorul de a crea toate formularele posibile pentru fiecare obiect de configurare. Dezvoltatorul trebuie doar să adauge un nou obiect de configurare, iar sistemul însuși va genera formularele necesare în momentele potrivite ale lucrului utilizatorului pentru a afișa informațiile conținute în acest obiect.

Astfel, dezvoltatorul trebuie să-și creeze propriile forme de obiecte soluție de aplicație numai dacă acestea trebuie să aibă diferențe (design diferit sau comportament specific) față de formularele generate automat de sistem.

Conectarea unui formular la date

Dacă un formular aparține unui anumit obiect de configurare nu determină compoziția datelor care sunt afișate în formular. Faptul că formularul aparține, de exemplu, unui director Nomenclatură, vă permite să îl atribuiți ca unul dintre formele principale pentru acest director, dar nu determină în niciun fel ce date va afișa acest formular și care va fi comportamentul său.

Pentru a asocia un formular cu date se folosesc detalii de formular, care indică lista de date afișată de formular. Toate formularele, în sine, au același comportament, indiferent de datele pe care le afișează. Cu toate acestea, unul dintre atributele formularului poate fi desemnat ca atribut principal pentru acesta (este evidențiat cu caractere aldine), caz în care comportamentul standard al formularului și proprietățile sale vor fi suplimentate în funcție de tipul atributului principal al formularului:

De exemplu, dacă un document este atribuit ca atribut principal al formularului Recepția de bunuri și servicii, apoi la închiderea formularului, sistemul va solicita confirmarea înregistrării și postării acestui document. Dacă atribuiți, de exemplu, un director ca atribut principal al formularului Nomenclatură, atunci o astfel de cerere de confirmare nu va apărea la închiderea formularului.

Structura formei

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

Partea afișată a formularului (vizibilă pentru utilizator) este descrisă ca un arbore care conține elemente de formular.

Elementele pot fi câmpuri de introducere, casete de selectare, butoane radio, butoane etc. În plus, un element 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 sau un panou de comandă. În plus, elementul poate fi un tabel, care include și elemente (coloane). Structura elementului descrie modul în care va arăta formularul.

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 care trebuie efectuate. Astfel, dezvoltatorul în editorul de formulare trebuie să includă detaliile ș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 aspectul formularului pentru a fi afișat utilizatorului. În acest caz, sistemul ia în considerare diverse proprietăți ale datelor afișate (de exemplu, tip) pentru a aranja elementele de formular cât mai convenabil pentru utilizator.

Dezvoltatorul poate influența aranjarea elementelor cu diverse setări. Poate determina ordinea elementelor, poate specifica lățimea și înălțimea dorite. Totuși, acestea sunt doar câteva informații suplimentare pentru a ajuta sistemul să afișeze formularul.

În formulare, dezvoltatorul poate folosi nu numai comenzile formularului în sine, ci și comenzile globale utilizate în interfața de comandă a întregii configurații. În plus, este posibil să se creeze comenzi parametrizabile care vor deschide alte formulare ținând cont de datele specifice formularului curent. De exemplu, aceasta ar putea fi apelarea unui raport privind soldurile la depozit care este selectat în prezent în formularul de factură.

Problema principală este că peste 10-15 ani a fost deja compilat o mulțime de cod pentru forme obișnuite. Nimeni nu vrea să rescrie toate acestea pe client-server + mulți oameni sunt instruiți să lucreze cu interfața. Tranziția obligatorie la BP 3.0 începând de anul viitor creează panică în mintea dezvoltatorilor și contabililor. Feedback-ul va fi foarte neplăcut. În plus, ștacheta de intrare în profesie crește, programarea este mai dificilă, iar cele standard au devenit și mai dificile. Care este costul noului algoritm în documentele standard? UV arată grozav când ai 2-3 butoane pe documente, UV este grozav pentru a lucra pe dispozitive mobile, dar 0,01% dintre companii îl folosesc. Va trebui să schimbați dacă 1C nu vine cu ceva nou, dar va fi lung și dureros pentru toată lumea. Și companiile însele vor trebui să plătească banii.

Și eu, până acum, am experimentat doar lucruri negative din forme controlate, iată mai multe dezavantaje ale inovației:

• Nimic? Ei bine, am întâlnit de câteva ori, de exemplu, scriind și atașând un formular de tipărire extern la conf. ZUP, procesarea este o întreagă epopee, plină de instrucțiuni pe Internet și pagini de cod ar trebui.
  pe un client gros există o procedură cu parametri, adică dezvoltarea este o chestiune de câteva minute.
  iar frânele sunt subțiri vizibile cu ochiul liber
• Cât despre posibilitatea de a pregăti forme gestionabile - aceasta este artă de dragul artei, dar care este punctul practic, mai ales pentru versiunea fișierului?
• Am sculptat în UV timp de 3 ani, dar acum am revenit la forme simple și credeți-mă, această tranziție a fost destul de dificil de făcut din punct de vedere psihologic, dar aceasta este alegerea mea conștientă pentru că ceea ce oferă 1c în UV este complet UG.... poate că peste câțiva ani 1c va face o descoperire, dar acum ea caută doar locul unde să facă această descoperire...
• UV-urile din configurator durează mult mai mult să se deschidă.
  După aceea, deschiderea formularelor în 8.1 este ca transferul de la un camion la un avion!
• Sunt mai mulți hemoroizi pentru toată lumea, utilizatorii sunt șocați de noua interfață (nu toți recunosc, dar sunt mult mai proști în privința lucrurilor mai mici), jumătate dintre programatori au devenit nepotriviți pentru profesionalism, a devenit mai dificil pentru specialistul obișnuit. de a găsi un loc de muncă și de a produce un produs de calitate. Iar cea mai tare temă de marketing a UV este că se ridică peste tot, încât tranziția are loc cu o simplă actualizare, dar toată lumea uită că de la început trebuie să ajungi din urmă cu cele mai recente lansări! Dar in principiu imi place ideea!
• Nu știu, experiența mea arată contrariul. Acolo unde boom-urile în forme stricte se lovesc automat de câțiva ani, în noile standard UV în fiecare lună începe „de ce, unde este 1C acum după actualizarea acestui buton și de ce acum nu funcționează”, ceea ce, vezi tu , nu adaugă viteză.
• - există mai mult cod
  - codul a devenit mai complex
  — modificarea celor standard este mult mai dificilă
  - utilizatorii cărora le-am dat UT11 nu au găsit avantaje față de 10.x
  — dar au găsit unele încetiniri și o lipsă a unor funcții, cum ar fi căutarea (din anumite motive au vrut căutare înainte-înapoi și nu selecție)
  Părerea mea este că sacrificiile sunt prea mari de dragul clientului web și al tabletelor. Mai mult decât atât, personal, nu am văzut încă deloc lucru real cu un client web, care trebuie să folosească cu succes accesul de la distanță
• Bedlam client-server ar trebui să ofere o creștere a performanței și scalabilității, în timp ce, în același timp, costurile includ o creștere a codării.
  Cu toate acestea, nu toată lumea a cunoscut o creștere, de unde și dezamăgirea. Și, în același timp, toată lumea era aplecată pe costurile de codare.
  P.S. De fapt, îmi plac cele controlate, desenez calm pe ele. Dar cele tipice au devenit pervertite.
• Acasă (computer normal) îmi conduc băutura în funcție de antreprenori individuali.
  8.3, BP3, în carouri. Impresia principală este că nu lucrez, dar aștept tot timpul. răspunsul hemoroidal. SALT pentru cont se formează la fel de simplu - pare un card de cont pentru anul într-un mega-holding.
• UT11 este o frână sălbatică, groază și, în general, un coșmar.
  UT10 zboară în comparație cu UT11.
  În ceea ce privește UV - bug-urile sunt infestate de ani de zile, totul este strâmb, coloanele nu încap niciodată pe un ecran, întinderea este groaznică în multe cazuri.
  Și încă pot enumera o mulțime de minusuri, dar probabil că nu voi spune nimic despre plusuri. Pur și simplu nu există.
  Firmele au ajuns în mod special cu aceste forme, pentru că dezvoltarea costă mai mult, nu existau speciale și nu există normale.

Sunt puține avantaje, dar desigur că există...

Pro:

Răspunsul a fost acolo de mult timp, ceea ce a dat UP:

client multiplatform

• lucrând pe linii de comunicare proaste
• capacitatea de a lucra printr-un browser (fără a instala un client)

Să presupunem că există procesare externă scrisă pentru versiunea 8.1. Este posibil să-l rulați în 8.2, astfel încât să funcționeze cu forma sa mai veche, neadministrată? Procesarea este necesară o singură dată, pentru a transfera date și nu doriți să creați un formular gestionat pentru aceasta doar o dată...

Pentru procesarea externă (deschisă dintr-un fișier separat) în modul gestionat, utilizarea formularelor obișnuite nu este acceptată. Prin urmare, dacă într-o configurație care funcționează în modul gestionat, este necesar să începeți procesarea cu un formular negestionat și nu doriți să creați un formular nou, gestionat pentru această procesare, atunci o astfel de procesare trebuie mai întâi inclusă în configurație.

Formularele obișnuite (negestionate) pot funcționa numai în clientul gros. Clienții subțiri și web acceptă numai formulare gestionate.

Prin urmare, dacă trebuie să deschideți un formular de procesare obișnuit în interfața aplicației gestionate, atunci acest lucru este posibil numai într-un client gros care rulează în modul aplicație gestionată.

Cel mai simplu mod este lansarea clientului gros în modul aplicație gestionată din configurator, specificând acest lucru în parametri: Serviciu - Opțiuni - Lansare 1C:Enterprise - De bază - Client gros (aplicație gestionată).

Cu toate acestea, trebuie să rețineți că lansarea clienților în modul gestionat este posibilă numai dacă configurația are compatibilitatea cu versiunea 8.1 dezactivată (proprietate Modul de compatibilitate).

Cu toate acestea, acest lucru nu este suficient pentru ca platforma să deschidă forma veche, negestionată de procesare.

Capacitatea de a utiliza forme obișnuite într-un mod controlat este reglementată de o proprietate specială de configurare - Utilizați formulare normale într-o aplicație gestionată. Această proprietate trebuie setată.

În paleta de proprietăți de configurare, această proprietate nu este întotdeauna afișată, ci numai dacă în parametrii configuratorului este selectat modul de editare a configurației Aplicație gestionată și aplicație obișnuită ( Service - Opțiuni - General).

Și, în sfârșit, obiectul a cărui formă normală doriți să o vedeți în modul gestionat trebuie să aibă o singură formă de obiect principal, iar această formă trebuie să fie normală, neadministrată.

În alte cazuri (dacă obiectul nu are nicio formă principală sau obiectul are un formular principal gestionat), platforma va genera sau deschide (dacă are unul) formularul gestionat în mod implicit.

Știm cu toții că compania 1C a avut multe versiuni diferite ale platformei 1C, acum vom fi interesați de una dintre cele mai recente versiuni la momentul scrierii acestui articol, acestea sunt versiunile 1C 8.2 și 1C 8.3. Dacă ați trebuit să lucrați în ambele versiuni, atunci cel mai probabil a observat diferențe în interfețele acestor versiuni, pentru utilizatori diferă doar ca aspect. În esență, o alegere aplicație obișnuită sau gestionată spune sistemului ce formulare să afișeze să ruleze, regulat sau controlat, precum și ce client de aplicație va fi utilizat implicit, gros sau subțire. Pentru informații mai detaliate despre clienți, citiți articolul „Ce sunt clienții grosi și subțiri în 1C, precum și diferențele lor.”

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

În 1C 8.2 este posibil să funcționeze numai cu forme obișnuite, în modul obișnuit de aplicare. Imaginea de mai jos prezintă baza de date în modul de operare „aplicație obișnuită 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 forme obișnuite (în modul de compatibilitate), cât și cu cele gestionate. În plus formularele gestionate au două tipuri de afișare, acesta este standard și taxi. Un exemplu de configurație 1C 8.3 cu formulare standard gestionate este prezentat mai jos, iar după acesta este afișată 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 obișnuită sau gestionată), o interfață specifică va fi încărcată implicit ( forme regulate sau gestionate), prin urmare, există atât de multe sinonime pentru acest concept. Dorim să remarcăm că diferențele dintre 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 efectuată în 1C 8.3, și nu în 1C 8.2, de aici toate consecințele care decurg. Codul trebuie, de asemenea, împărțit în client și server, acest lucru este indicat folosind directivele corespunzătoare din configurator.

Cu versiunea 8.2 a platformei în 1C, au început să fie utilizate 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 diagrama de interacțiune dintre 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 unui document 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 modificări, 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 descriau poziția unui câmp prin specificarea pixelilor, acum este posibil doar specificarea tipului de grupare;
• Formularul constă în detalii reprezentând datele formularului, și comenzi - proceduri și funcții de efectuat;
• 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;
• Din partea clientului, multe tipuri de date au devenit indisponibile și acum nu există posibilitatea de a schimba datele în 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:
  • Naklient;
  • OnServer;
  • OnServerWithoutContext;
  • OnClientOnServer;
  • Pe client Pe server fără context.

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

Editarea unui formular gestionat în configurator a devenit, de asemenea, diferită. S-au schimbat multe aspecte, iar dezvoltatorii versiunii 7.7, care nu aveau formulare gestionate, pot fi surprinși. Chiar și aspectul designerului de formulare s-a schimbat, ceea ce poate fi văzut prin deschiderea oricăruia 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 este 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. Acestea sunt locul în care informațiile sunt stocate pe partea clientului;
3. Afișează un formular gestionat. Mai jos vedem o privire preliminară bazată pe elementele interfeței;
4. Modul formular. Secțiunea care conține procedurile și funcțiile utilizate de acest formular. Aici puteți găsi codul pentru algoritmii de interacțiune a programului atât cu utilizatorul, cât și cu baza de date.

Dezvoltatorii 1C încurajează clienții să treacă la formulare gestionate, așa că învățarea principiilor dezvoltării formularelor gestionate este o chestiune de timp. Odată ce începeți să lucrați cu acest tip de formular, vă veți da seama că acesta este un pas către standardizarea dezvoltării și respectarea unor reguli uniforme. Prin urmare, capacitatea de a lucra cu formulare gestionate în 1C 8.3 vă crește nivelul de dezvoltator 1C.

Principii de proiectare a 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 pentru interacțiunea 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 executată 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 din 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, iar tu le vei putea accesa.

Dezvoltatorii 1C recomandă cu tărie folosirea apelurilor server non-contextuale, 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ă pregătire 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 formularul de configurare gestionată și 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. Mai mult, toată lumea va simți schimbările în bine - programatori, companii care lucrează în 1C, francizați și dezvoltatori 1C. Principalele consecințe ale utiliză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. Înțelegerea mai profundă de către dezvoltatori 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 cărți de referință dezvoltate fără a înțelege partea client-server;
4. Creșterea performanței configurațiilor și reducerea încărcării pe computerele client;
5. Costuri reduse pentru achiziționarea de computere 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 prezenta multe surprize. Dar, cu abordarea corectă, acest pas va aduce dividende mari, motiv pentru care tot mai mulți utilizatori 1C din toată Rusia decid să o ia. Ținând cont de faptul că compania 1C mizează pe dezvoltarea formularelor gestionate în viitor, este riscant să rămânem pe cele convenționale învechite.