Dhe Objekt i Transferimit të të Dhënave në strukturimin e kodit, forma e menaxhuar në mjedisin 1C 8.2.

Prezantimi

Le të fillojmë me një përshkrim të shkurtër të konceptit të "formës së menaxhuar" dhe koncepteve të lidhura me platformën 1C. Ekspertët e platformës mund ta kalojnë këtë seksion.

U bë në dispozicion në 2008 një version të ri platforma 1C: Ndërmarrja 8.2 (në tekstin e mëtejmë: Aplikacioni i Menaxhuar), i cili ndryshon plotësisht të gjithë shtresën e punës me ndërfaqen. Kjo përfshin ndërfaqen e komandës, formularët dhe sistemin e dritareve. Kjo jo vetëm që ndryshon modelin e zhvillimit të ndërfaqes së përdoruesit në konfigurim, por gjithashtu propozon një arkitekturë të re për ndarjen e funksionalitetit midis aplikacionit të klientit dhe serverit.
Një aplikacion i menaxhuar mbështet llojet e mëposhtme të klientëve:

• Klient i trashë (Modaliteti i nisjes normale dhe i menaxhuar)
• Klient i hollë
• Klient në ueb

Një aplikacion i menaxhuar përdor forma të ndërtuara Teknologji e re. Ata janë quajtur Format e menaxhuara. Për lehtësinë e tranzicionit, mbështeten edhe format e vjetra (të ashtuquajturat forma të rregullta), por funksionaliteti i tyre nuk është zhvilluar dhe ato janë të disponueshme vetëm në modalitetin e nisjes së klientit të pasur.
Dallimet kryesore të formave të menaxhuara për zhvilluesin:

• Përshkrimi deklarativ, jo "me pixel" i strukturës. Vendosja specifike e elementeve bëhet automatikisht nga sistemi kur shfaqet forma.
• I gjithë funksionaliteti i formularit përshkruhet në formular detajet dhe komandat. Detajet janë të dhënat me të cilat funksionon forma dhe komandat janë veprimet e kryera.
• Formulari ekzekutohet si në server ashtu edhe në klient.
• Në kontekstin e klientit, pothuajse të gjitha llojet e aplikacioneve nuk janë të disponueshme, dhe në përputhje me rrethanat është e pamundur të ndryshohen të dhënat në bazën e informacionit.
• Për secilën metodë ose variabël të formës, ajo duhet të specifikohet direktiva e përpilimit A që specifikon nëse vendndodhjen e ekzekutimit (klient ose server) dhe aksesin në kontekstin e formularit.

Këtu janë udhëzimet për përpilimin e metodave të formularit:

• &AtClient
• &Në server
• &NëServerPa Kontekst
• &Në KlientinNë ServerinPa Kontekst

Le të ilustrojmë sa më sipër. Pamja e ekranit tregon një shembull të një forme të menaxhuar dhe modulin e saj në modalitetin e zhvillimit. Gjeni përshkrimin deklarativ, rekuizitat, direktivat e përpilimit, etj.

Të gjitha diskutimet e mëtejshme do të jenë në lidhje me anën e djathtë të ilustrimit, se si të strukturoni kodin e modulit dhe cilat parime do t'ju lejojnë të zbatoni ndërveprim efektiv klient-server.

Le të përcaktojmë problemin

Kanë kaluar disa vite që kur versioni i ri i platformës 1C është përdorur në mënyrë aktive dhe shumë zgjidhje (konfigurime) janë lëshuar si nga 1C ashtu edhe nga partnerët e saj të shumtë.
A kanë zhvilluar zhvilluesit një kuptim të përbashkët të parimeve të ndërveprimit klient-server gjatë krijimit të formularëve gjatë kësaj kohe dhe a ka ndryshuar qasja ndaj zbatimit? modulet e softuerit në realitetet e reja arkitekturore?

Konsideroni strukturën e kodit (modulin e formës) në disa forma të të njëjtit konfigurim tipik dhe përpiquni të gjeni modele.
Nën strukturën, nënkuptojmë seksione të kodit (më shpesh këto janë blloqe komentesh) të ndara nga zhvilluesi për grupimin e metodave dhe direktivave për përpilimin e këtyre metodave.
Shembulli 1:
Seksioni i trajtuesit të ngjarjeve Metoda - në klient Metoda - në server Metoda - në klient Seksioni i procedurave dhe funksioneve të shërbimit Funksionet ndihmëse të kontrollit të hyrjes
Shembulli 2:
Procedurat dhe funksionet e shërbimit Dokumentet e pagesës Vlera Mbajtësit e ngjarjeve
Shembulli 3:
Procedurat e shërbimit në server Procedurat e shërbimit në klient Procedurat e shërbimit në server pa kontekst Trajtuesit e ngjarjeve të kokës Trajtuesit e ngjarjeve të komandave
Shembulli 4:
Procedurat për qëllime të përgjithshme Trajtuesit e ngjarjeve të formularit Procedurat e nënsistemit "informacionet e kontaktit"
Në fakt, struktura e kodit mungon, ose për ta thënë butë, është e ngjashme me atë që ishte në format 8.1:

• Fjalë jo informative "Gjeneral, Shërbimi, Ndihmës".
• Përpjekje të turpshme për të ndarë metodat e klientit dhe serverit.
• Shpesh metodat grupohen sipas elementeve të ndërfaqes "Puna me pjesën tabelare Produktet, Informacioni i kontaktit".
• Rregullimi arbitrar i metodave dhe grupeve të kodeve. Për shembull, Event Handlers mund të jenë në krye në një formë, në fund në një tjetër, të mos theksohen fare në një të tretë, e kështu me radhë.
• Dhe të mos harrojmë se e gjithë kjo është brenda të njëjtit konfigurim.
• Po, ka konfigurime në të cilat fjalët "Përgjithshme, Shërbimi, Ndihmës" janë gjithmonë në të njëjtat vende, por ...

Pse keni nevojë për një strukturë kodi?

• Thjeshtimi i mirëmbajtjes.
• Thjeshtoni mësimin.
• Rregullimi i parimeve të përgjithshme/të rëndësishme/të suksesshme.
• …opsioni juaj

Pse standardi ekzistues i zhvillimit nga 1C nuk ndihmon?

Le të shohim parimet e publikuara në disqet e ITS dhe në "Udhëzuesit e Zhvilluesve ..." të ndryshme, të rekomanduara kur shkruani një formular të menaxhuar.

• Minimizoni numrin e thirrjeve të serverit.
• Llogaritja maksimale në server.
• Thirrjet e serverit pa kontekst janë më të shpejta se thirrjet e kontekstit.
• Program me ndërveprimin klient-server në mendje.
• etj.

Këto janë slogane absolutisht të vërteta, por si mund të realizohen? Si të minimizoni numrin e thirrjeve, çfarë do të thotë të programoni në modalitetin klient-server?

Modele të projektimit ose mençuri brezash

Ndërveprimi klient-server është përdorur në teknologji të ndryshme softuerike për dekada. Përgjigja e pyetjeve të përshkruara në pjesën e mëparshme ka qenë prej kohësh e njohur dhe është përmbledhur në dy parime bazë.

• Fasada në distancë(në tekstin e mëtejmë Ndërfaqja e qasjes në distancë)
• Objekti i transferimit të të dhënave(në tekstin e mëtejmë: Objekt i transferimit të të dhënave)

Fjalë për Martin Fowler, përshkrimi i tij i këtyre parimeve:

• … çdo objekt potencialisht i destinuar për qasje në distancë duhet të ketë ndërfaqe me granularitet të ulët, i cili do të minimizojë numrin e thirrjeve të nevojshme për të kryer një procedurë të caktuar. … Në vend që të kërkoni një faturë dhe të gjitha pikat e saj veçmas, është e nevojshme të lexoni dhe përditësoni të gjitha pikat e faturës në një telefonatë. Kjo ndikon në të gjithë strukturën e objektit...Mos harroni: ndërfaqen e aksesit në distancë nuk përmban logjikën e domenit.
• ... nëse do të isha një nënë e kujdesshme, patjetër do t'i thoja fëmijës tim: "Mos shkruani kurrë objekte të transferimit të të dhënave!" Në shumicën e rasteve, objektet e migrimit të të dhënave nuk janë asgjë më shumë se grup fushore i fryrë… Vlera e këtij përbindëshi të neveritshëm qëndron vetëm në mundësinë transmetojnë informacione të shumta në rrjet në një telefonatë- një teknikë që ka një rëndësi të madhe për sistemet e shpërndara.

Shembuj të shablloneve në platformën 1C

API-ja e disponueshme për një zhvillues kur zhvillon një formular të menaxhuar përmban shumë shembuj të këtyre parimeve.
Për shembull, metoda OpenForm(), një ndërfaqe tipike "e trashë".
OpenParameters = Struktura e re ("Parameter1, Parameter2, Parameter3", Vlera1, Vlera2, Vlera3); Forma = OpenForm(Emri i formularit, Parametrat e hapur);
Krahaso me stilin v8.1.
Forma = GetForm(FormName); Forma.Parametri1 = Vlera1; Forma.Parametri2 = Vlera2; Forma.Open();

Në kontekstin e një formulari të menaxhuar, një grup "Objektesh të Transferimit të të Dhënave". Mund të dallohen sistemike dhe të përcaktuara nga zhvilluesi.
Ato të sistemit modelojnë një objekt aplikacioni në klient, në formën e një ose më shumë elementeve të të dhënave të formës. Ju nuk mund t'i krijoni ato jashtë lidhjes me detajet e formularit.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

Shndërrimi i objekteve të sistemit të transferimit të të dhënave në llojet e aplikacioneve dhe anasjelltas kryhet me metodat e mëposhtme:

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

Shpesh një konvertim i qartë përdoret kur përshtatet një zgjidhje ekzistuese. Metodat mund të presin parametra hyrës (veçori) të tilla si ValueTable dhe joFormDataCollection, ose metoda u përcaktua në kontekstin e një objekti aplikacioni dhe u bë e padisponueshme për thirrje direkte nga formulari.
Shembulli 1C v8.1:
// në klient në kontekstin e formularit FillUsersCache(DepartmentReference)
Shembulli 1C v8.2:
// në server në kontekstin e formës ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(Referenca e Departamentit); ValueVFormAttribute(ProcessingObject, "Object");

Objektet e migrimit të të dhënave, struktura e të cilave përcaktohet nga zhvilluesi, janë një nëngrup i vogël i llojeve të disponueshme si në klient ashtu edhe në server. Më shpesh, si parametra dhe rezultate të metodave të një ndërfaqeje "të trashë", përdoren sa vijon:

• Llojet primitive (varg, numër, boolean)
• Struktura
• Konformiteti
• varg
• Lidhje me objektet e aplikacionit (identifikues unik dhe përfaqësim teksti)

Shembull: metoda pranon një listë porosish për të ndryshuar statusin dhe i kthen klientit një përshkrim të gabimeve.
&OnServerWithoutContext Funksioni ServerChangeOrderStatus(Orders, NewStatus) Gabime = Përputhje e re(); // [porosi][përshkrimi i gabimit] Për çdo porosi nga Orders Loop StartTransaction(); Përpjekje DocOb = Order.GetObject(); …. veprime të tjera, ndoshta jo vetëm me porosinë... Përjashtim CancelTransaction(); Gabimet.Insert(Urdhri, PërshkrimiGabim()); Fundi i Përpjekjes; Cikli i Fundit; Gabim në kthim; FundFunksioni //Statusi i ndryshimit të Serverit()

Strukturimi i kodit

Qëllimet kryesore që moduli i formës së menaxhuar duhet të pasqyrojë dhe i afrohet zgjidhjes.

• Ndarja e qartë e kodit të klientit dhe serverit. Të mos harrojmë se në momentin e ekzekutimit këto janë dy procese ndërvepruese, në secilën prej të cilave funksionaliteti i disponueshëm ndryshon ndjeshëm.
• Një përzgjedhje e qartë e ndërfaqes së qasjes në distancë, cilat metoda të serverit mund të thirren nga klienti dhe cilat jo? Emrat e metodave të ndërfaqes në distancë fillojnë me prefiksin "Server". Kjo ju lejon të shihni menjëherë kalimin e kontrollit në server kur lexoni kodin dhe thjeshton përdorimin e sugjerimeve kontekstuale. Vini re se rekomandimi zyrtar (ITS) sugjeron emërtimin e metodave me postfikse, të tilla si ChangeOrderStatusOnServer(). Megjithatë, për të përsëritur, jo të gjitha metodat e serverit mund të thirren nga klienti, dhe kështu aksesi logjik është më i rëndësishëm se vendndodhja e përpilimit. Prandaj, me prefiksin "Server" shënojmë vetëm metodat në dispozicion të klientit, metoda shembull do të quhet ServerChangeOrderStatus().
• Lexueshmëria. Një çështje shije, ne pranojmë urdhrin kur moduli fillon me procedurat për krijimin e një formulari në server dhe metodat e aksesit në distancë.
• Mirëmbajtja. Vendi për të shtuar kodin e ri duhet të përcaktohet qartë. Pika e rëndësishme, të cilat krijohen automatikisht nga konfiguruesi i cungut të metodës, shtohen në fund të modulit. Meqenëse mbajtësit e ngjarjeve të elementeve të formës më së shpeshti krijohen automatikisht, blloku përkatës vendoset i fundit në mënyrë që të mos tërhiqet çdo mbajtës në një vend tjetër në modul.

Më poshtë është struktura bazë e modulit që zbaton qëllimet e listuara.

• Opsioni grafik - tregon qartë rrjedhën kryesore të ekzekutimit.
• Versioni i tekstit është një shembull i një modeli modeli për futje e shpejtë strukturon në një modul të formës së re.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // /////////////////////////////////////////////////////////////////// / //////////////////////////// // VARIABLAT E MODULIT //////////////// / //////////////////////////////////////////////////////////////////////// // ///////////// // NË SERVER //******* NGJARJET NË SERVER ******* &Në server Procedura në krijimin në server( Dështim, përpunim standard) //Fut përmbajtjen e mbajtësit EndProcedure //******* NDËRFAQJA E QASJES REMOTE ******* //******** LOGJIA E BIZNESIT NË SERVER **** *** //////////////////////////////////////////////////////////////// //////////////////////////////// // METODAT E ZAKONSHME TË KLIENTIT DHE SERVERIT ///////// /////////////////////////////////////////////////////////////////// //////////////// //////// // MBI KLIENTIN //******* LOGJIKA E BIZNESIT MBI KLIENTIN ******* //******* KOMANDA ******* //******** NGJARJE MBI KLIENTIN ****** ////////////// /////////////////////////////////////////////////////////////////// ///////////////// / / OPERATORËT KRYESOR TË PROGRAMIT

Pyetje të lidhura

Si përfundim, ne përshkruajmë disa fusha që janë të dobishme për t'u menduar kur programoni një ndërveprim klient-server.

• Opsionet për zbatimin e ndërfaqes së qasjes në distancë. Asinkronia, grimca...
• caching. 1C mori një vendim të pafat arkitektonik, duke prezantuar caching vetëm në nivelin e metodave të thirrjes së moduleve të zakonshme dhe duke mos ofruar opsione kontrolli (koha e përditësuar, rivendosja sipas kërkesës).
• Thirrjet e nënkuptuara të serverit. Mos harroni për veçoritë teknologjike, shumë operacione "të padëmshme" në klient provokojnë platformën për të hyrë në server.

11.12.2016

Rreth formularëve të menaxhuar 1C (Fillim)

Klient i hollë

Nuk ka askund më të hollë. Tani aplikacioni i klientit nuk kërkon bazën e të dhënave (ky është biznesi i serverit). Aplikacioni i klientit thjesht shfaq ndërfaqen dhe të dhënat.

Vlen të përmendet se struktura e kodit është bërë më e ndërlikuar për shkak të transformimeve të tilla. Tek klienti nuk ka referenca, objekte, tabelë vlerash... janë të disponueshme vetëm lloje primitive (string, data, boolean, array, structure...). Kjo do të thotë që programuesi tani duhet të mendojë se çfarë të marrë në server dhe si ta bëjë atë me kosto minimale.

Ndërveprimi klient-server

Një qasje e re ndaj ndërveprimit midis klientit dhe serverit na lejoi të krijonim një model të ri të ndërfaqes së përdoruesit. Tani ndërfaqja është deklaruar(!) Dizajni i ndërfaqes fillon me të dhëna, me detaje dhe pjesë tabelare. Kur krijoni një mbështetëse, duhet të mendoni se si do të duket në ndërfaqe, nëse do të kërkohet, si lidhet me rekuizita të tjera...

Asnjë kontekst (gjendje) në server

Serveri 1C funksionon në parimin e "pa shtetësi" (anglisht pa shtet). Kjo do të thotë që serveri u përgjigjet vetëm kërkesave dhe në të njëjtën kohë nuk ruan asgjë ndërmjet dy kërkesave (ekziston ruajtje e përkohshme për këtë qëllim).

FormDataToValue,FormDataCollection,FormData...

Ne iu drejtuam serverit, ai bëri gjithçka për ne, i fshiu të dhënat dhe harroi që erdhëm. Të gjithë objektet me emrin "FormData" + "diçka atje" do të na ndihmojnë të ruajmë të dhënat tona midis dy thirrjeve të serverit.

Ruajtja e përkohshme

Ruajtja e përkohshme është një vend i veçantë ku (përveç detajeve të formularit) mund të ruani gjendjen në server. Ruajtja mund të ruajë të dhëna që nuk janë të disponueshme për klientin (d.m.th., që nuk mund të vendosen në detajet e formularit).

Për të punuar me ruajtjen e përkohshme, përdorni metodat MoveToTempStorage() Sintaksa: PlaceToTempStorage(<Данные>, <Адрес>) Përshkrimi: Ruan një vlerë të serializueshme në ruajtje të përkohshme. Disponueshmëria: Klient i hollë, klient në internet, server, klient i trashë, lidhje e jashtme, aplikacion celular (klient), aplikacion celular (server). Thirrja e metodës bën një telefonatë në server.<Адрес>(opsionale) Lloji: UniqueIdentifier; Linjë. ID-ja unike e formularit në ruajtjen e përkohshme të të cilit do të vendosen të dhënat dhe do të kthehet adresa e re. Ose adresën në ruajtje të përkohshme ku duhet të vendosen të dhënat. Adresa duhet të merret më herët duke përdorur këtë metodë. Nëse një formular UniqueIdentifier ose një adresë në ruajtje kalon, atëherë vlera do të fshihet automatikisht pasi formulari të mbyllet. Nëse kalohet një UniqueIdentifier që nuk është një identifikues unik për formularin, atëherë vlera do të fshihet kur të përfundojë sesioni i përdoruesit. Nëse parametri nuk është i specifikuar, vlera e vendosur do të fshihet pas kërkesës së serverit tjetër nga moduli i përbashkët, në thirrjet e serverit kontekstual dhe jokontekst nga formulari, në thirrjet e serverit nga moduli i komandës ose në marrjen e formularit. Shënim: Ruajtja e përkohshme e krijuar në një seancë nuk është e aksesueshme nga një sesion tjetër. Një përjashtim është aftësia për të transferuar të dhëna nga një punë në sfond në seancën që nisi punën e sfondit duke përdorur ruajtje të përkohshme. Për një transferim të tillë, në sesionin prind, vendosni një vlerë boshe në ruajtje të përkohshme, duke kaluar identifikuesin e formularit. Pastaj kaloni adresën e marrë në punën e sfondit përmes parametrave të punës së sfondit. Më tej, nëse kjo adresë përdoret në parametër<Адрес>, rezultati do të kopjohet në seancën nga e cila filloi puna e sfondit. Të dhënat e vendosura në ruajtje të përkohshme në një punë në sfond nuk do të jenë të disponueshme nga sesioni prind derisa të përfundojë puna e sfondit. dhe Sintaksa GetFromTempStorage(): GetFromTempStorage(<Адрес>) Përshkrimi: Merr një vlerë nga ruajtja e përkohshme. Disponueshmëria: Klient i hollë, klient në internet, server, klient i trashë, lidhje e jashtme, aplikacion celular (klient), aplikacion celular (server). Thirrja e metodës bën një telefonatë në server. Shënim: Rezultati i ekzekutimit nuk ruhet në memorie, serveri thirret sa herë që thirret metoda.

Telefonimi i kodit të serverit

Çdo thirrje në kodin e serverit gjithmonë serializon të dhënat e transmetuara. Të gjithë parametrat paketohen në një formë vargu dhe transmetohen përmes rrjetit. Rezultati i punës gjithashtu transferohet përsëri në një formë të serializuar, ku më pas rikthehet në objekte të njohura.

Caktimi i flamujve të modulit

• Flamuri tregon se ku do të përpilohet kodi i modulit (në server, në klient, në një lidhje të jashtme)
• Nëse një modul përpilohet në shumë vende, atëherë ai do të jetë i dukshëm vetëm sipas flamujve
• Transferimi i ekzekutimit të kodit është i mundur vetëm nëse nuk ka modul të thirrur në kontekstin aktual të ekzekutimit, por ai ekziston diku tjetër (nëse moduli ekziston vetëm në server, dhe ai nuk ekziston në klient, atëherë serveri do të thirret)

Flamuri i thirrjes së serverit

Duke filluar me platformën 1C:Enterprise 8.2, është shtuar flamuri i "thirrjes së serverit". E cila thjesht ndihmon për të "zgjidhur" kushtet për kalimin në një makinë tjetër. Nëse ky flamur i është caktuar modulit, atëherë moduli do të jetë i dukshëm nga klienti, nëse jo, atëherë një përpjekje për të thirrur nga klienti do të rezultojë në një gabim. Kodi i modulit nuk do të jetë i dukshëm, sikur të mos ekzistonte fare.

Kështu, në një klient të rregullt të trashë, mund ta transferoni kodin në server vetëm nëse telefononi një modul të përbashkët nga klienti, për të cilin:

• Kutia e kontrollit të serverit u zgjodh
• Kutia e kontrollit "Serveri i telefonatave" është zgjedhur
• U hoqën të gjitha kutitë e kontrollit "klient".

Me ardhjen e platformës 1C Enterprise 8.2, mekanizmi i zhvillimit të ndërfaqes së përdoruesit ka ndryshuar ndjeshëm. Tani mund të krijoni forma dhe aplikacione të menaxhuara (Figura 1).

Foto 1

Përveç kësaj, propozohet një sistem i ri për ndarjen e funksionalitetit ndërmjet aplikacionit të klientit dhe serverit.
Një aplikacion i menaxhuar mbështet llojet e mëposhtme të klientëve:

• Klient i trashë (modaliteti i lëshimit normal dhe i menaxhuar),
• klient i hollë,
• Klient në ueb.

Mekanizmi për krijimin e formave të menaxhuara është dukshëm i ndryshëm nga format konvencionale. Para së gjithash, format e menaxhuara ndryshojnë në atë që ato krijohen automatikisht nga sistemi bazuar në cilësime të veçanta; tani programuesi nuk ka nevojë të vizatojë secilën formë në detaje. I gjithë funksionaliteti i formularit përshkruhet në formën e detajeve dhe komandave. Detajet janë të dhënat me të cilat funksionon forma dhe komandat janë veprimet e kryera. Për çdo variabël të metodës ose formës, duhet të specifikohet një direktivë përpilimi, e cila përcakton vendin e ekzekutimit (klient ose server). Direktivat e përpilimit mund të jenë:

• &Klienti,
• &Në server,
• &NëServer Pa Kontekst,
• &Në KlientinNë ServerinPa Kontekst.

Një formë e menaxhuar gjithashtu ndryshon nga një formë e rregullt në llojet e të dhënave me të cilat punon. Nëse një formë e rregullt funksionon me shumicën e llojeve të ofruara nga 1C: Enterprise (duke përfshirë llojet DirectoryObject, DocumentObject, etj.), atëherë kategoritë e mëposhtme të llojeve mund të dallohen në një formë të menaxhuar:

• Llojet që përdoren drejtpërdrejt në formë janë ato lloje që ekzistojnë në anën e klientit të hollë dhe Web (për shembull, Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• llojet që do të konvertohen në lloje të veçanta të të dhënave menaxhohen nga llojet e të dhënave. Llojet e tilla shfaqen në listën e atributeve të formës në kllapa, për shembull (CatalogObject.Products);
• listë dinamike.

Funksionimi i formave të menaxhuara ka këto karakteristika dalluese (Figura 2):

• Formulari ekziston si në klient ashtu edhe në server.

Kryen ndërveprimin klient-server (transferimi i të dhënave dhe vetitë e projektimit të elementeve).

• Formulari nuk funksionon me objektet e aplikacionit

Figura 2

Formulari përdor objekte të veçanta gjenerike
Format e të Dhënave(Figura 3).


Figura 3

Objektet e aplikacionit punojnë vetëm në server dhe vetëm gjatë operacioneve të caktuara.
Kur hapni një formular:

• Objekti lexohet nga baza e të dhënave,
• Objekti konvertohet në të dhëna të formës,
• Objekti hiqet (nga kujtesa),
• Të dhënat e formularit i kalohen klientit.

Gjatë regjistrimit:

• Të dhënat e formularit merren nga klienti,
• Të dhënat e formularit konvertohen në një objekt,
• Objekti është shkruar në bazën e të dhënave,
• Objekti hiqet (nga kujtesa).

Në mësimin e fundit, ne konsideruam për një klient të rregullt (të shëndoshë). Në versionin e platformës 1C 8.2. Ata përdorin forma të reja të ekranit 1C 8.2. Ata quhen forma të menaxhuara 1C 8.2.

Format e menaxhuara 1C 8.2 është e ardhmja e 1C. Ato ndryshojnë nga format e zakonshme 1C 8.2 në atë që gjenerohen automatikisht nga sistemi bazuar në cilësime të veçanta (format "të rregullta" thjesht vizatohen nga programuesi sipas dëshirës).

Dallimet në zhvillimin e formave të menaxhuara 1C 8.2 nga ato të zakonshmet janë të rëndësishme. Prandaj, ne jemi mbledhur sot për të diskutuar veçmas krijimin dhe modifikimin e formularëve të menaxhuar 1C 8.2.

Format e menaxhuara 1C 8.2

Nëse keni zhvilluar konfigurime 1C më parë, kur hapni redaktuesin e formave të menaxhuara 1C 8.2, menjëherë do të hutoheni nga fakti se është e pamundur të ndikoni fare në formën 1C 8.2 me miun.

Ju nuk mund ta ndryshoni formularin 1C 8.2, nuk mund ta zhvendosni elementin, madje nuk mund t'i shikoni vetitë e fushës si më parë - duke klikuar dy herë fushën në formularin 1C 8.2.

Tani baza për zhvillimin e formularit 1C 8.2 nuk janë fusha të detyrueshme për koordinatat në formular, por cilësime të veçanta. Sistemi gjeneron automatikisht një formular të menaxhuar 1C 8.2 bazuar në këto cilësime.

Cilësimet përbëhen nga një listë e elementeve të formës 1C 8.2 të vendosura në redaktuesin në këndin e sipërm të majtë. Elementet e formularit 1C 8.2 përfshijnë:

• Kushtet
• Komandat (koncepti i ri 1C 8.2, mund të duket si butona ose artikuj të menysë)
• Grupet (për të kombinuar detaje dhe komanda).

Në përputhje me rrethanat, cilësimet e këtyre elementeve nuk janë në vetitë e fushave, por në vetitë e këtyre elementeve të cilësimeve (menyja me klikim të djathtë, artikulli Properties).

Si funksionojnë format e menaxhuara 1C 8.2

Puna me format e menaxhuara 1C 8.2 është e ndryshme për përdoruesin. Ata kanë më shumë veçori, por janë të pazakonta për ata që kanë punuar me 1C për një kohë të gjatë.

Para së gjithash, vendndodhja e elementëve të zakonshëm në formularin 1C 8.2 ndryshon. Shiriti i komandës është gjithmonë në krye.

Ana e majtë e shiritit të komandës është e personalizueshme. Zakonisht përmban butona tipikë si Regjistro dhe Post.

Ana e djathtë e panelit të komandës është menyja e re standarde e formularit 1C Të gjitha veprimet. Kjo meny ju lejon të menaxhoni formularin 1C 8.2 sipas dëshirës, ​​ngjashëm me mënyrën se si cilësimet në raportin ACS ju lejojnë të ndryshoni ndjeshëm pamjen e raportit.

Artikujt arbitrar të menysë 1C Të gjitha veprimet

Në varësi të faktit nëse kjo formë 1C 8.1 i përket njërit apo tjetrit, menyja është e mbushur me artikuj që ju lejojnë të menaxhoni këtë objekt. Për shembull, nëse është një formë e listës së drejtorive, atëherë do të ketë komanda të tilla si Krijo ose Edit.

Artikulli Personalizo listën e menyve 1C Të gjitha veprimet

Nëse ka një listë në formularin 1C 8.2, atëherë menyja ka komandën Set up list dhe Display list.
Nëse komanda Output List është tashmë e njohur për ju - ju lejon të ruani çdo listë në 1C në Excel / printoni atë, atëherë komanda e dytë është e re.

Siç e keni vënë re tashmë, nuk ka më butona përzgjedhjeje në shiritin e komandave të listave. Në vend të kësaj, u shfaq butoni Gjeni, për të cilin funksionon (si dhe pozicionimi tani i çaktivizuar i kursorit në listë kur shkruani) - ka ankesa.

Funksionaliteti i butonit Find, natyrisht, nuk është i krahasueshëm me zgjedhjet, por ato nuk janë zhdukur askund!
Tani ato janë nën artikullin e menusë Personalizo List. Përzgjedhja tani mund të bëhet nga çdo fushë, dhe përveç saj, renditja dhe formatimi i kushtëzuar mund të bëhet në të njëjtën mënyrë siç mund të bëhet në raportet SKD.

Artikulli Ndrysho formularin e menysë 1C Të gjitha veprimet

Artikulli "Ndrysho formularin" ju lejon të ndryshoni në mënyrë të ngjashme jo vetëm listën në formularin 1C 8.2, por edhe vetë formularin 1C 8.2.

Përdoruesi mund të aktivizojë ose çaktivizojë në mënyrë të pavarur dukshmërinë e fushave në formën 1C 8.2, gjerësinë dhe lartësinë, aktivizimin e fushës së paracaktuar kur hapet, etj.

Përdorimi i formave të menaxhuara 1C 8.2 dhe formave konvencionale 1C

Si parazgjedhje, format e rregullta 1C përdoren në konfigurime për një klient të trashë (të rregullt) 1C dhe format e menaxhuara përdoren në konfigurimet për një klient 1C të hollë dhe në internet. Sidoqoftë, të dyja format e 1C mund të përdoren në çdo konfigurim, duke përfshirë njëkohësisht.

Për ta bërë këtë, duhet gjithashtu të futni vetitë e konfigurimit (elementi i sipërm në dritaren e konfigurimit).

Në vetitë e konfigurimit në 1C 8.2, janë shfaqur dy kuti të reja të kontrollit që ju lejojnë të aktivizoni përdorimin jo standard të formave 1C.

Krijimi i formularëve të menaxhuar 8.2

Shtimi i një formulari të ri 1C 8.2 bëhet në të njëjtën mënyrë si më parë - duke përdorur butonin Ins në tastierë ose butonin Shto. Për të futur një ekzistues, klikoni dy herë mbi të me miun.

Si parazgjedhje, forma (e rregullt ose e menaxhuar) që është vendosur në konfigurim do të krijohet (shih veçorinë "Modaliteti kryesor i nisjes" në vetitë e konfigurimit).

Konstruktori do t'ju kërkojë të zgjidhni llojin e formës - formën e një elementi, një listë. Këtu mund të shtoni ose hiqni shiritat e komandës në formular. Më shpesh, këto cilësime lihen siç janë, si parazgjedhje.

Hapet një formular i plotësuar si parazgjedhje - të gjitha detajet e objektit 1C që i shtohen. Ju mund të shënoni një listë specifike të fushave të kërkuara në skedën e dytë të konstruktorit.

Redaktori i formularit përbëhet nga tre seksione.

• Në këndin e sipërm të majtë është një listë e elementeve të formës. Ai përbëhet nga fusha, komanda dhe grupe që ju lejojnë të kombinoni artikujt. Lista e komandave mund të shihet veçmas në skedën Command Interface.
• Në këndin e sipërm djathtas ka një listë të atributeve të disponueshme të formës dhe atributeve të objektit (hap kryqin pranë atributit Object).
• Më poshtë është një pamje paraprake e formës që rezulton.

Mund të tërhiqni detajet e disponueshme në të majtë dhe ai do të bëhet një element i formës (një fushë në formular).

Nëse keni nevojë të shtoni një buton ose artikull të menusë - në anën e djathtë të skedës Komanda, duhet të krijoni një komandë të re. Ky është një mbështjellës për një funksion në një modul formulari. Përveç specifikimit të funksionit që do të thirret në të vërtetë, mund të caktoni një paraqitje - për shembull, një foto, si dhe varësinë e dukshmërisë nga një opsion funksional.

Komandat tërhiqen gjithashtu në të majtë. Nëse prindi është një shirit komandash, atëherë do të jetë një buton i shiritit të komandës - përndryshe vetëm një buton.

Në listën e elementeve të formës (fushat), jo vetëm që mund të tërhiqni atributin e objektit/formës, por edhe thjesht ta shtoni atë (butoni Shto ose Ins). Në veçanti, ju mund të krijoni një objekt të ri të formës - një Grup.

Grupi mund të jetë një panel komandues (kursori duhet të jetë në linjën Form). Pastaj ju tërhiqni komandat në të dhe ato bëhen butona.

Grupi mund të jetë "i rregullt". Pastaj është një mënyrë për të grupuar fushat vertikalisht dhe horizontalisht. Emri i grupit mund të hiqet nga vetitë.

Grupi mund të jetë një panel (faqe). Grupi i shtuar në krye është një panel, dhe grupet e mbivendosura të këtij lloji janë faqe. Fushat tashmë po zvarriten në faqe.

Elementet e panevojshme të formës hiqen duke fshirë elementët e formularit në listë.
Pozicioni i fushës në formular përcaktohet nga renditja në listën e elementeve (vertikale) ose sipas grupeve (horizontale). Gjerësia dhe lartësia vendosen në vetitë e elementit të formës.

Karakteristikat e elementit të formës janë zgjeruar shumë dhe përmbajnë shumë gjëra të dobishme - si kontrollin e pamjes (butonat e zgjedhjes dhe fshirjes), ashtu edhe kontrollin e vlerave të paracaktuara.

Vetitë e vetë formës, duke përfshirë dimensionet e saj, vendosen në elementin rrënjësor të formularit me të njëjtin emër Forma.

Trajtuesit e ngjarjeve (përgjigjja ndaj veprimeve të përdoruesit) tani ndahen në dy lloje. Të vjetrat - si më parë, ato janë të specifikuara në vetitë e formës dhe fushave (për shembull, OnChange dhe OnOpening formularin). E re - janë bërë komanda dhe përdoren për artikujt dhe butonat e menysë.

Nga versioni 8.2 i platformës, 1C filloi të përdorë parime të reja për ndërtimin e ndërfaqes dhe ndërveprimin e përdoruesit me bazën e të dhënave. Teknologjia e re quhet aplikacion i menaxhuar. Mekanizmat për ndërtimin e formave dhe skema e ndërveprimeve midis përdoruesit të serverit 1C dhe bazës së të dhënave kanë pësuar përpunim më të madh. Modaliteti normal ende mbështetet nga platforma, por me kalimin e kohës, të gjithë përdoruesit e 1C do të kalojnë në format e menaxhuara.

Për përdoruesit e zakonshëm, forma e menaxhuar e dokumentit 1C ndryshon nga ajo e zakonshme vetëm në pamje. Për zhvilluesin, ky është një mekanizëm i ri me rregullat, ligjet dhe kushtet e veta. Shumë fusha kanë pësuar një ndryshim, por risitë e mëposhtme konsiderohen kryesore midis zhvilluesve me përvojë të 1C:

• Formimi i pavarur i strukturës së formës dhe vendosja e fushave nga platforma. Nëse zhvilluesit e mëparshëm përshkruanin pozicionin e fushës duke specifikuar piksele, tani është e mundur vetëm të specifikohet lloji i grupimit;
• Formulari përbëhet nga atributet që përfaqësojnë të dhënat e formularit, dhe komandat - procedurat dhe funksionet e kryera;
• Kodi i formës ekzekutohet si në anën e serverit ashtu edhe në anën e klientit. Në fund të fundit, forma në vetvete është një objekt konfigurimi i krijuar në server dhe shfaqet në klient. Kjo do të thotë se kombinon pjesët e klientit dhe serverit;
• Nga ana e klientit, shumë lloje të dhënash janë bërë të padisponueshme dhe tani nuk ka asnjë mënyrë për të ndryshuar të dhënat në bazën e informacionit;
• Për çdo procedurë ose funksion, duhet të specifikohet një cilësim i veçantë - një direktivë përpilimi. Ai është përgjegjës për vendin ku ekzekutohet kodi dhe mund të marrë vlerat e mëposhtme:
  • mbi klientin;
  • Në server;
  • Në ServerPa Kontekst;
  • OnClientOnServer;
  • Në klient në server pa kontekst.

Pika e fundit është veçanërisht e mprehtë në mënyrën e formave të menaxhuara. Nëse një zhvillues nuk është i përgatitur mirë në direktivat ose ndërveprimin klient-server, atëherë do të jetë jashtëzakonisht e vështirë për të që të krijojë një formë të menaxhuar. Të gjitha parimet e reja për ndërtimin e formave të menaxhuara në 1C: Enterprise 8.3 janë të bashkuara nga koncepti i përgjithshëm i një arkitekture me tre nivele. Ai përfshin kompjuterë klientë, një server 1C dhe një DBMS ku ruhen të dhënat.

Redaktimi i një formulari të menaxhuar në konfigurues është bërë gjithashtu i ndryshëm. Shumë aspekte kanë ndryshuar dhe zhvilluesit e versionit 7.7, ku nuk kishte forma të menaxhuara, mund të habiten. Edhe pamja e dizajnerit të formës ka ndryshuar, gjë që mund të shihet duke hapur ndonjë nga format e objektit të konfigurimit. Kur hapim një objekt, shohim një dritare të ndarë në disa seksione:

1. Formoni elementet e ndërfaqes. Në pjesën e sipërme majtas ka një dritare që liston të gjitha fushat e shfaqura në formularin e zgjedhur, të cilat sigurojnë ndërveprimin e programit me përdoruesin;
2. Detajet e formularit. Në krye djathtas janë të gjitha të dhënat me të cilat funksionon formulari. Është në to që informacioni ruhet në anën e klientit;
3. Shfaqja e një formulari të menaxhuar. Më poshtë shohim një pamje paraprake të pamjes bazuar në elementët e ndërfaqes;
4. Moduli i formularit. Një seksion që përmban procedurat dhe funksionet e përdorura nga ky formular. Këtu mund të gjeni kodin e algoritmeve për ndërveprimin e programit si me përdoruesin ashtu edhe me bazën e të dhënave.

Zhvilluesit e 1C po nxitin klientët të kalojnë në format e menaxhuara, kështu që mësimi i parimeve të zhvillimit të formave të menaxhuara është çështje kohe. Duke filluar të punoni me këtë lloj formulari, do të kuptoni se ky është një hap drejt standardizimit të zhvillimit dhe respektimit të rregullave uniforme. Prandaj, aftësia për të punuar me format e menaxhuara në 1C 8.3 rrit nivelin tuaj si zhvillues 1C.

Udhëzime për hartimin e formularëve të menaxhuar

Para së gjithash, për të kuptuar mekanizmin e modalitetit të menaxhuar 1C, duhet të mbani mend se formulari ekziston si në server ashtu edhe në klient. Për më tepër, tek klienti, ky objekt është vetëm një imazh i ndërfaqes së ndërveprimit të përdoruesit me programin. Të gjitha llogaritjet, algoritmet, llogaritjet dhe përpunimi duhet të ndodhin vetëm në anën e serverit. Kjo diktohet jo vetëm nga pamundësia për të përdorur shumë funksione dhe parametra te klienti, por edhe nga kërkesat e performancës.

Ju mund të kuptoni se ku kryhet procedura me emrin e direktivës, e cila duhet të shkruhet para secilës procedurë dhe të funksionojë në modulin e formularit. Formulimi "Pa kontekst" tregon se të dhënat në formularin e menaxhuar nuk do të kalojnë në këtë procedurë në server. Kështu, në procedura të tilla, nuk do të jetë e mundur të shkruhen algoritme bazuar në vlerat e futura nga përdoruesi. Nëse ky formulim nuk është i specifikuar, atëherë formulari transmetohet në tërësi me të gjitha detajet dhe ju mund t'i qaseni ato.

Zhvilluesit 1C rekomandojnë fuqimisht përdorimin e thirrjeve të serverit pa kontekst, duke zvogëluar numrin e tyre sa më shumë që të jetë e mundur dhe duke u përpjekur të mos kryejnë llogaritjet tek klienti. Është e vështirë për zhvilluesit fillestarë pa sfond teorik të respektojnë të gjitha këto rregulla dhe të ndryshojnë kodin në mënyrë korrekte. Para se të filloni të punoni vetë, do të jetë e dobishme të hapni një formular konfigurimi të menaxhuar, të shikoni sintaksën dhe mënyrën se si klienti dhe serveri ndërveprojnë.

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

Rregullat e reja për zhvillimin e formave 1C do të jenë me përfitim të madh nëse të gjithë zhvilluesit i përmbahen atyre. Për më tepër, të gjithë do t'i ndiejnë ndryshimet për mirë - si programuesit, ashtu edhe kompanitë që punojnë në 1C, dhe ekskluzivitetet dhe zhvilluesit 1C. Pasojat kryesore të funksionimit të saktë të formave të menaxhuara në 1C:

1. Lehtësia e mirëmbajtjes së konfigurimit dhe rritja e lexueshmërisë së kodit. Nga kjo mund të konkludojmë se një algoritëm i shkruar nga një zhvillues mund të korrigjohet gjithmonë nga një punonjës tjetër pa shpenzuar shumë kohë;
2. Ndarja e kodit që funksionon në klient dhe server. Duke pasur parasysh se sa i ndryshëm është funksionaliteti i disponueshëm në secilën nga këto anë, ndarja e tyre do të ishte masa e duhur;
3. Zhvilluesit kanë një kuptim më të thellë të logjikës së platformës, ndërveprimet klient-server dhe algoritmet që ata shkruajnë. Në versionet 8.0 dhe më herët, ishte shumë e zakonshme të gjeje forma të dokumenteve ose drejtorive të zhvilluara pa kuptuar pjesën klient-server;
4. Rritja e shpejtësisë së konfigurimeve dhe reduktimi i ngarkesës në kompjuterët e klientëve;
5. Ulja e kostos së blerjes së kompjuterëve për vendet e punës për shkak të mungesës së nevojës për të blerë PC të fuqishëm.

Zgjedhja e një forme të menaxhuar si mënyra kryesore e nisjes 1C mund të sjellë shumë surpriza. Por me qasjen e duhur, ky hap do të sjellë dividentë të mëdhenj, kështu që gjithnjë e më shumë përdorues të 1C në të gjithë Rusinë vendosin për të. Duke marrë parasysh faktin se kompania 1C po mbështet në zhvillimin e formave të menaxhuara në të ardhmen, është e rrezikshme të qëndrosh në ato konvencionale të vjetëruara.