Andmeedastusobjekt koodi struktureerimiseks, hallatav vorm 1C 8.2 keskkonnas.

Sissejuhatus

Alustame 1C platvormi mõiste "hallatud vorm" ja sellega seotud mõistete lühikirjeldusega. Platvormi eksperdid võivad selle jaotise vahele jätta.

Saadaval 2008. aastal uus versioon platvorm 1C: Enterprise 8.2 (edaspidi hallatud rakendus), mis muudab täielikult kogu liidesega töötamise kihti. See hõlmab käsuliidest, vorme ja aknasüsteemi. See mitte ainult ei muuda kasutajaliidese arendusmudelit konfiguratsioonis, vaid pakub välja ka uue arhitektuuri kliendirakenduse ja serveri funktsionaalsuse eraldamiseks.
Hallatav rakendus toetab järgmist tüüpi kliente.

• Paks klient (tavaline ja hallatud käivitusrežiim)
• Õhuke klient
• Veebi klient

Hallatud rakendus kasutab üles ehitatud vorme uus tehnoloogia. Neid kutsutakse Hallatud vormid. Ülemineku hõlbustamiseks toetatakse ka vanemaid vorme (nn tavavorme), kuid nende funktsionaalsust ei arendata ja need on saadaval ainult rikkalikus kliendikäivitusrežiimis.
Hallatavate vormide peamised erinevused arendaja jaoks:

• Deklaratiivne, mitte "pikslite järgi" struktuuri kirjeldus. Elementide konkreetse paigutuse teeb süsteem vormi kuvamisel automaatselt.
• Vormi kõiki funktsioone kirjeldatakse vormis üksikasjad ja käske. Üksikasjad on andmed, millega vorm töötab, ja käsud on tehtud toimingud.
• Vorm täidetakse nii serveris kui ka kliendis.
• Kliendi kontekstis pole peaaegu kõik rakendustüübid saadaval ja vastavalt sellele on infobaasis olevate andmete muutmine võimatu.
• Iga meetodi või vormimuutuja puhul tuleb see täpsustada koostamise käskkiri A, mis määrab, kas täitmise asukoht (klient või server) ja juurdepääs vormi kontekstile.

Siin on juhised vormimeetodite koostamiseks:

• &AtClient
• &Serveris
• &OnServerWithoutContext
• &Kliendi juures serveris ilma kontekstita

Illustreerime ülaltoodut. Ekraanipildil on näide hallatavast vormist ja selle moodulist arendusrežiimis. Leia deklaratiivne kirjeldus, rekvisiidid, koostamise juhised jne.

Kõik edasised arutelud käsitlevad illustratsiooni paremat külge, kuidas mooduli koodi üles ehitada ja millised põhimõtted võimaldavad teil rakendada tõhusat kliendi-serveri suhtlust.

Määratleme probleemi

1C platvormi uue versiooni aktiivsest kasutamisest on möödunud mitu aastat ja nii 1C kui ka tema arvukad partnerid on välja andnud palju lahendusi (konfiguratsioone).
Kas arendajatel on selle aja jooksul vormide loomisel välja kujunenud ühine arusaam kliendi ja serveri suhtluse põhimõtetest ja kas lähenemine juurutamisele on muutunud? tarkvara moodulid uutes arhitektuurilistes reaalsustes?

Mõelge koodistruktuurile (vormimoodulile) sama tüüpilise konfiguratsiooni mitmel kujul ja proovige leida mustreid.
Struktuuri all peame silmas koodilõike (enamasti on need kommentaariplokid), mille arendaja on eraldanud meetodite rühmitamiseks ja nende meetodite koostamise juhised.
Näide 1:
Sündmuste töötleja jaotis Meetod - kliendil Meetod - serveris Meetod - kliendil Teenindusprotseduuride ja funktsioonide jaotis Sisendjuhtimise abifunktsioonid
Näide 2:
Teeninduse protseduurid ja funktsioonid Maksedokumendid Väärtesemed Sündmuste haldajad
Näide 3:
Teenindusprotseduurid serveris Teenindusprotseduurid kliendis Teenindusprotseduurid serveris ilma kontekstita Päise sündmuste töötlejad Käskude sündmuste töötlejad
Näide 4:
Üldotstarbelised protseduurid Vormi sündmuste käitlejad Kontaktteabe allsüsteemi protseduurid
Tegelikult on koodi struktuur puudu või pehmelt öeldes sarnane see, mis oli vormidel 8.1:

• Mitteinformatiivsed sõnad "General, Service, Auxiliary".
• Arglikud katsed eraldada kliendi ja serveri meetodeid.
• Sageli on meetodid rühmitatud liidese elementide järgi "Töö tabeliosaga Tooted, Kontaktandmed".
• Meetodite ja koodirühmade meelevaldne paigutus. Näiteks sündmuste käitlejad võivad ühel kujul olla ülaosas, teisel kujul allosas, kolmandas ei ole üldse esile tõstetud jne.
• Ja ärgem unustagem, et see kõik on samas konfiguratsioonis.
• Jah, on konfiguratsioone, milles sõnad “General, Service, Auxiliary” on alati samades kohtades, kuid ...

Miks on vaja koodistruktuuri?

• Hoolduse lihtsustamine.
• Õppimise lihtsustamine.
• Üldiste/oluliste/edukate põhimõtete fikseerimine.
• …teie valik

Miks 1C olemasolev arendusstandard ei aita?

Vaatame ITS-ketastel ja erinevates "Arendaja juhendites ..." avaldatud põhimõtteid, mida soovitatakse hallatava vormi kirjutamisel.

• Minimeerige serverikõnede arv.
• Maksimaalne arvutite arv serveris.
• Kontekstivälised serverikõned on kiiremad kui kontekstikõned.
• Programm, mis peab silmas kliendi ja serveri suhtlust.
• jne.

Need on loosungid, mis on täiesti tõesed, kuid kuidas neid realiseerida? Kuidas minimeerida kõnede arvu, mida tähendab programmeerimine klient-server režiimis?

Disainimustrid ehk põlvkonnatarkus

Kliendi-serveri suhtlust on erinevates tarkvaratehnoloogiates kasutatud aastakümneid. Vastus eelmises osas välja toodud küsimustele on ammu teada ja see on kokku võetud kahes põhiprintsiibis.

• Kaugfassaad(edaspidi kaugjuurdepääsu liides)
• Andmeedastusobjekt(edaspidi andmeedastusobjekt)

Sõna Martin Fowlerile, tema kirjeldus nendest põhimõtetest:

• … igal potentsiaalselt kaugjuurdepääsuks mõeldud objektil peab olema madala granulaarsusega liides, mis vähendab konkreetse protseduuri tegemiseks vajalike kõnede arvu. … Selle asemel, et arvet ja kõiki selle punkte eraldi küsida, on vaja läbi lugeda ja uuendada kõik arve punktid ühe kõnega. See mõjutab kogu objekti struktuuri...Pidage meeles: kaugjuurdepääsu liidest ei sisalda domeeniloogikat.
• ... kui ma oleksin hooliv ema, siis kindlasti ütleksin oma lapsele: “Ära kunagi kirjuta andmeedastusobjekte!” Enamasti pole andmete migratsiooniobjektid midagi muud kui ülespuhutud põllukomplekt… Selle vastiku koletise väärtus seisneb ainult võimaluses edastada ühe kõnega mitut teavet võrgu kaudu- tehnika, mis on hajutatud süsteemide jaoks väga oluline.

1C platvormi mallide näited

Arendajale hallatava vormi väljatöötamisel saadaolev API sisaldab nende põhimõtete kohta palju näiteid.
Näiteks OpenForm() meetod, tüüpiline "jäme" liides.
OpenParameters = New Structure("Parameeter1, Parameeter2, Parameeter3", Väärtus1, Väärtus2, Väärtus3); Vorm = OpenForm(Vorminimi, OpenParameters);
Võrrelge stiiliga v8.1.
Vorm = GetForm(Vorminimi); Vorm.Parameeter1 = Väärtus1; Vorm.Parameeter2 = Väärtus2; Vorm.Open();

Hallatava vormi kontekstis "Andmeedastusobjektide" komplekt. Saab eristada süsteemne ja arendaja määratletud.
Süsteemsed mudelid modelleerivad kliendil rakendusobjekti ühe või mitme vormiandmeelemendi kujul. Te ei saa neid luua väljaspool vormi üksikasjadega sidumist.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

Andmeedastussüsteemi objektide teisendamine rakendustüüpideks ja vastupidi toimub järgmiste meetoditega:

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

Sageli kasutatakse olemasoleva lahenduse kohandamisel selgesõnalist teisendust. Meetodid võivad eeldada (funktsiooni) sisendparameetreid, nagu ValueTable, mitte FormDataCollection, või meetod määratleti rakenduse objekti kontekstis ja muutus vormilt otsekutsumiseks kättesaamatuks.
Näide 1C v8.1:
// kliendil vormi FillUsersCache(DepartmentReference) kontekstis
Näide 1C v8.2:
// serveris vormi ProcessingObject = FormAttributeToValue("Object") kontekstis; ProcessingObject.FillCacheUsers(osakonna viide); ValueVFormAttribute(ProcessingObject, "Object");

Andmete migratsiooniobjektid, mille struktuuri määrab arendaja, on väike alamhulk nii kliendis kui ka serveris saadaolevatest tüüpidest. Kõige sagedamini kasutatakse "jämeda" liidese meetodite parameetrite ja tulemustena järgmist:

• Primitiivsed tüübid (string, arv, tõeväärtus)
• Struktuur
• Vastavus
• massiivi
• Lingid rakendusobjektidele (ainulaadne identifikaator ja tekstiesitus)

Näide: meetod aktsepteerib oleku muutmise korralduste loendit ja tagastab kliendile vigade kirjelduse.
&OnServerWithoutContext Funktsioon ServerChangeOrderStatus(Orders, NewStatus) Errors = Uus vaste(); // [tellimus][vea kirjeldus] Iga tellimuse kohta tellimustest Loop StartTransaction(); Katse DocOb = Order.GetObject(); …. muud toimingud, võib-olla mitte ainult tellimusega... Erand CancelTransaction(); Errors.Insert(Order, DescriptionError()); Katse lõpp; EndCycle; Tagastamise viga; EndFunction // ServerChangeOrderStatus()

Koodi struktureerimine

Peamised eesmärgid, mida hallatava vormi moodul peaks kajastama, ja lähenemisviisid lahendusele.

• Kliendi ja serveri koodi selge eraldamine.Ärgem unustagem, et täitmise ajal on tegemist kahe interakteeruva protsessiga, millest igaühe saadaolev funktsionaalsus erineb oluliselt.
• Kaugjuurdepääsu liidese selge valik, milliseid serverimeetodeid saab kliendilt kutsuda ja milliseid mitte? Kaugliidese meetodite nimed algavad eesliitega "Server". See võimaldab koodi lugemisel koheselt näha juhtimise üleminekut serverile ja lihtsustab kontekstipõhiste vihjete kasutamist. Pange tähele, et ametlik soovitus (ITS) soovitab nimetada postfixidega nimemeetodeid, näiteks ChangeOrderStatusOnServer(). Kordame aga, et kõiki serverimeetodeid ei saa kliendilt välja kutsuda ja seega on loogiline ligipääsetavus olulisem kui kompileerimiskoht. Seetõttu märgime eesliitega “Server” ainult kliendile saadaolevad meetodid, näidismeetodi nimeks saab ServerChangeOrderStatus().
• Loetavus. Maitseasi, tellimuse võtame vastu siis, kui moodul algab serveris vormi loomise protseduuride ja kaugjuurdepääsu meetoditega.
• Hooldatavus. Uue koodi lisamise koht peab olema selgelt määratletud. Oluline punkt, mis luuakse automaatselt meetodi stub konfiguraatoriga, lisatakse mooduli lõppu. Kuna vormielementide sündmuste käsitlejad luuakse enamasti automaatselt, siis asetatakse vastav plokk viimaseks, et mitte tirida iga töötlejat moodulis teise kohta.

Allpool on toodud mooduli põhistruktuur, mis rakendab loetletud eesmärke.

• Graafiline valik - näitab selgelt peamist täitmise voogu.
• Tekstiversioon on malli kujunduse näide kiire sisestus struktuurid uude vormimoodulisse.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Kuupäev=""/> // <Описание> // // /////////////////////////////////////////////////// ////////////////////////////// // MOODULI MUUTUJAD //////////////// /////////////////////////////////////////////////// // ////////////// // SERVERIS //******* SÜNDMUSED SERVERIS ******* &Serveris Protseduur Loomise kohta Serveris( Tõrge, standardtöötlus) //Sisestage töötleja sisu EndProcedure //******* KAUGJUURDE LIIDES ******** //******** ÄRILOOGIKA SERVERIS **** *** //////////////////////////////////////////////// ////////////////////////////////// // ÜHISED KLIENDI- JA SERVERIMEETODID //////////////////////////////////////////////////// //////////////// //////// // KLIENDIL //******* ÄRILOOGIKA KLIENDIL ******* //******* KÄSUD ******* //******* SÜNDMUSED KLIENDIL ****** /////////////// /////////////////////////////////////////////////// ///////////////// / / PÕHIPROGRAMMI OPERAATORID

Seotud küsimused

Kokkuvõtteks toome välja mõned valdkonnad, millele on kasulik kliendi-serveri suhtluse programmeerimisel mõelda.

• Kaugjuurdepääsu liidese juurutamise võimalused. Asünkroonsus, detailsus...
• vahemällu salvestamine. 1C tegi kahetsusväärse arhitektuurilise otsuse, võttes vahemällu kasutusele ainult tavaliste moodulite helistamismeetodite tasemel ega pakkunud juhtimisvõimalusi (ajakohane aeg, lähtestamine nõudmisel).
• Kaudsed serverikõned. Ärge unustage tehnoloogilisi funktsioone, paljud kliendi "kahjutud" toimingud provotseerivad platvormi serverile juurdepääsuks.

11.12.2016

Teave hallatud vormide 1C kohta (algus)

Õhuke klient

Peenemat pole kuskil. Nüüd ei tee klientrakendus andmebaasist päringuid (see on serveri äri). Kliendirakendus kuvab lihtsalt liidese ja andmed.

Väärib märkimist, et koodi struktuur on selliste teisenduste tõttu muutunud keerulisemaks. Kliendis pole viiteid, objekte, väärtuste tabeleid... saadaval on ainult primitiivsed tüübid (string, kuupäev, tõeväärtus, massiiv, struktuur...). See tähendab, et programmeerija peab nüüd mõtlema, mida serverisse hankida ja kuidas seda minimaalsete kuludega teha.

Kliendi-serveri interaktsioon

Uus lähenemine kliendi ja serveri vahelisele suhtlusele võimaldas meil luua uue kasutajaliidese mudeli. Nüüd on liides deklareeritud(!) Liidese disain algab andmetega, detailide ja tabeliosadega. Rekvisiidi loomisel tuleb mõelda, kuidas see liideses välja näeb, kas seda nõutakse, kuidas see on seotud teiste rekvisiitidega...

Serveris puudub kontekst (olek).

1C server töötab "kodakondsuseta" (inglise state-less) põhimõttel. See tähendab, et server vastab ainult päringutele ja samal ajal ei salvesta midagi kahe päringu vahele (selleks on ajutine salvestusruum).

FormDataToValue,FormDataCollection,FormData...

Pöördusime serveri poole, ta tegi meie eest kõik ära, kustutas andmed ja unustas, et tulime. Kõik objektid nimega "FormData" + "midagi seal" aitavad meil andmeid kahe serverikõne vahel salvestada.

Ajutine ladustamine

Ajutine salvestus on spetsiaalne koht, kuhu (lisaks vormi üksikasjadele) saate salvestada serveri oleku. Salvestusruumi saab salvestada andmeid, mis pole kliendil saadaval (st mida ei saa vormi üksikasjadesse paigutada).

Ajutise salvestusruumiga töötamiseks kasutage meetodeid MoveToTempStorage() Süntaks: PlaceToTempStorage(<Данные>, <Адрес>) Kirjeldus: salvestab jadaväärtuse ajutisele salvestusruumile. Kättesaadavus: õhuke klient, veebiklient, server, paks klient, välisühendus, mobiilirakendus (klient), mobiilirakendus (server). Meetodikutse teeb kõne serverile.<Адрес>(valikuline) Tüüp: UniqueIdentifier; Liin. Selle vormi kordumatu ID, mille ajutisele hoiule andmed paigutatakse ja uus aadress tagastatakse. Või ajutises salvestusruumis olev aadress, kuhu andmed paigutada. Seda meetodit kasutades tuleb aadress hankida varem. Kui vormi kordumatu identifikaator või laos olev aadress edastatakse, kustutatakse väärtus pärast vormi sulgemist automaatselt. Kui edastatakse kordumatu identifikaator, mis ei ole vormi kordumatu tunnus, siis väärtus kustutatakse kasutaja seansi lõppedes. Kui parameetrit ei täpsustata, kustutatakse paigutatud väärtus pärast järgmist serveripäringut jagatud moodulist, vormilt konteksti- ja mittekontekstiserveri kõnede korral, käsumooduli serverikutsete korral või vormi hankimisel. Märkus. Ühe seansi jooksul loodud ajutisele salvestusruumile ei pääse teisest seansist juurde. Erandiks on võimalus edastada andmeid taustatöölt seansile, mis taustatöö algatas, kasutades ajutist salvestusruumi. Sellise ülekande jaoks asetage vanemseansis ajutisse salvestusruumi tühi väärtus, edastades vormi identifikaatori. Seejärel edastage saadud aadress taustatöö parameetrite kaudu taustatööle. Lisaks, kui seda aadressi kasutatakse parameetris<Адрес>, kopeeritakse tulemus seansile, millest taustatöö alustati. Tausttöö ajutisele salvestusruumile paigutatud andmed ei ole alates emaseansist saadaval enne, kui tausttöö on lõppenud. ja GetFromTempStorage() süntaks: GetFromTempStorage(<Адрес>) Kirjeldus: saab väärtuse ajutisest salvestusruumist. Kättesaadavus: õhuke klient, veebiklient, server, paks klient, välisühendus, mobiilirakendus (klient), mobiilirakendus (server). Meetodikutse teeb kõne serverile. Märkus. Täitmise tulemust ei salvestata vahemällu, serverit kutsutakse iga kord, kui meetod välja kutsutakse.

Serveri koodi helistamine

Iga kõne serveri koodile järjestab edastatud andmed alati. Kõik parameetrid pakitakse stringivormi ja edastatakse üle võrgu. Töö tulemus kantakse ka serialiseeritud kujul tagasi, kus see seejärel tuttavateks objektideks taastatakse.

Mooduli lippude määramine

• Lipp näitab, kus mooduli kood kompileeritakse (serveris, kliendis, välisühenduses)
• Kui moodul on koostatud mitmes kohas, siis on see nähtav ainult lippude järgi
• Koodikäitamise ülekandmine on võimalik ainult siis, kui praeguses täitmiskontekstis pole kutsutud moodulit, kuid see on olemas mujal (kui moodul eksisteerib ainult serveris ja seda pole kliendil, siis kutsutakse serverisse)

Serveri kõne lipp

Alates 1C:Enterprise 8.2 platvormist on lisatud lipp "serveri kõne". Mis lihtsalt aitab "lahendada" teisele masinale ülemineku tingimusi. Kui see lipp on moodulile määratud, siis on moodul kliendile nähtav, kui mitte, siis kliendilt helistamise katse tulemuseks on tõrge. Mooduli koodi ei kuvata, nagu poleks seda üldse olemas.

Seega saate tavalises paksus kliendis koodi serverisse edastada ainult siis, kui helistate kliendilt ühisele moodulile, mille jaoks:

• Serveri märkeruut on märgitud
• Märkeruut "Helista serverile" on märgitud
• Eemaldati kõik märkeruudud "klient".

Platvormi 1C Enterprise 8.2 tulekuga on kasutajaliidese arendusmehhanism oluliselt muutunud. Nüüd saate luua hallatud vorme ja rakendusi (joonis 1).

1. pilt

Lisaks pakutakse välja uus süsteem funktsionaalsuse eraldamiseks klientrakenduse ja serveri vahel.
Hallatav rakendus toetab järgmist tüüpi kliente:

• Paks klient (tavaline ja hallatud käivitusrežiim),
• õhuke klient,
• Veebi klient.

Hallatavate vormide loomise mehhanism erineb oluliselt tavapärastest vormidest. Esiteks erinevad hallatavad vormid selle poolest, et süsteem loob need automaatselt spetsiaalsete sätete alusel, nüüd ei pea programmeerija iga vormi üksikasjalikult joonistama. Kõik vormi funktsioonid on kirjeldatud detailide ja käskude kujul. Üksikasjad on andmed, millega vorm töötab, ja käsud on tehtud toimingud. Iga meetodi või vormimuutuja jaoks tuleb määrata kompileerimisdirektiiv, mis määrab täitmise koha (klient või server). Koostamisjuhised võivad olla:

• &AtClient,
• &serveris,
• &OnServerWithoutContext,
• &Kliendi juures serveris ilma kontekstita.

Hallatav vorm erineb tavavormist ka andmetüüpide poolest, millega see töötab. Kui tavavorm töötab enamiku 1C:Enterprise'i pakutavate tüüpidega (sh tüübid DirectoryObject, DocumentObject jne), saab hallatud vormis eristada järgmisi tüüpide kategooriaid:

• tüübid, mida vormis otseselt kasutatakse, on need tüübid, mis eksisteerivad õhukese ja veebikliendi poolel (näiteks Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• tüübid, mis teisendatakse spetsiaalseteks andmetüüpideks, on hallatava vormi andmetüübid. Sellised tüübid kuvatakse vormiatribuutide loendis sulgudes, näiteks (CatalogObject.Products);
• dünaamiline loend.

Hallatavatel vormidel on järgmised eripärad (joonis 2):

• Vorm on olemas nii kliendis kui ka serveris.

See teostab kliendi-serveri interaktsiooni (andmete edastamine ja elementide disainiomadused).

• Vorm ei tööta rakendusobjektidega

Joonis 2

Vorm kasutab spetsiaalseid üldobjekte
Andmevormid(Joonis 3).


Joonis 3

Rakendusobjektid töötavad ainult serveris ja ainult teatud toimingute ajal.
Vormi avamisel:

• Objekti loetakse andmebaasist,
• Objekt teisendatakse vormiandmeteks,
• objekt eemaldatakse (mälust),
• Vormi andmed edastatakse kliendile.

Salvestamise ajal:

• Vormi andmed saadakse kliendilt,
• Vormi andmed teisendatakse objektiks,
• Objekt kirjutatakse andmebaasi,
• Objekt eemaldatakse (mälust).

Viimases tunnis arvestasime tava(paksu)kliendiga. Platvormi versioonis 1C 8.2. Nad kasutavad uusi ekraanivorme 1C 8.2. Neid nimetatakse hallatud vormideks 1C 8.2.

Hallatavad vormid 1C 8.2 on 1C tulevik. Need erinevad tavalistest 1C 8.2 vormidest selle poolest, et süsteem genereerib need automaatselt spetsiaalsete sätete alusel (“tavalised” vormid joonistab programmeerija lihtsalt oma äranägemise järgi).

Hallatavate vormide 1C 8.2 arengu erinevused tavapärastest on märkimisväärsed. Seetõttu oleme täna kogunenud, et arutada eraldi hallatavate vormide 1C 8.2 loomist ja muutmist.

Hallatavad vormid 1C 8.2

Kui olete varem 1C konfiguratsioone arendanud, siis 1C 8.2 hallatud vormiredaktorit avades ajab teid kohe segadusse tõsiasi, et 1C 8.2 vormi pole üldse võimalik hiirega mõjutada.

Te ei saa muuta vormi 1C 8.2, te ei saa elementi liigutada, te ei saa isegi vaadata välja omadusi nagu varem - topeltklõpsates vormi 1C 8.2 väljal.

Nüüd ei ole vormi 1C 8.2 väljatöötamise aluseks vormi koordinaatidega väljade sidumine, vaid spetsiaalsed seaded. Süsteem loob nende sätete alusel automaatselt hallatava vormi 1C 8.2.

Seadistused koosnevad 1C 8.2 vormielementide loendist, mis asuvad redaktoris vasakus ülanurgas. Vormi 1C 8.2 elemendid hõlmavad järgmist:

• Rekvisiidid
• Käsud (uus kontseptsioon 1C 8.2, võivad välja näha nagu nupud või menüüelemendid)
• Grupid (detailide ja käskude kombineerimiseks).

Vastavalt sellele ei ole nende elementide sätted väljade atribuutides, vaid nende seadete elementide atribuutides (paremklõpsu menüü, üksus Properties).

Kuidas hallatavad vormid 1C 8.2 töötavad

Hallatud vormidega 1C 8.2 töötamine on kasutaja jaoks erinev. Neil on rohkem funktsioone, kuid need on ebatavalised neile, kes on 1C-ga pikka aega töötanud.

Esiteks erineb tavaliste elementide asukoht vormil 1C 8.2. Käsuriba on alati ülaosas.

Käsuriba vasak pool on kohandatav. Tavaliselt sisaldab see selliseid tüüpilisi nuppe nagu Salvesta ja Postita.

Käsupaneeli paremal pool on vormi 1C uus standardmenüü Kõik toimingud. See menüü võimaldab hallata vormi 1C 8.2 vastavalt soovile, sarnaselt sellele, kuidas ACS-aruande sätted võimaldavad aruande välimust oluliselt muuta.

Suvalised menüüelemendid 1C Kõik toimingud

Sõltuvalt sellest, kas see vorm 1C 8.1 kuulub ühele või teisele, on menüü täidetud üksustega, mis võimaldavad teil seda objekti hallata. Näiteks kui see on kataloogiloendi vorm, siis on käsud nagu Loo või Redigeeri.

Üksus Kohanda menüüloendit 1C Kõik toimingud

Kui vormil 1C 8.2 on loend olemas, on menüüs käsk Set up list and Display list.
Kui käsk Output List on teile juba tuttav - see võimaldab teil Excelis 1C-sse salvestada / printida mis tahes loendi, siis on teine ​​käsk uus.

Nagu olete juba märganud, pole loendite käsuribal enam valikunuppe. Selle asemel ilmus nupp Otsi, mis töötab (nagu ka nüüd blokeeritud kursori positsioneerimine loendis tippimisel) - on kaebusi.

Otsi nupu funktsionaalsus pole muidugi võrreldav valikutega, aga kuhugi pole need kadunud!
Need on nüüd menüükäsu Kohanda loendi all. Valimist saab nüüd teha mis tahes välja järgi ning lisaks sellele saab sortimist ja tingimuslikku vormindamist teha samamoodi nagu SKD aruannetes.

Üksus Muuda menüüvormi 1C Kõik toimingud

Üksus Muuda vormi võimaldab teil sarnaselt muuta mitte ainult vormi 1C 8.2 loendit, vaid ka vormi 1C 8.2 ennast.

Kasutaja saab iseseisvalt lubada või keelata vormi 1C 8.2 väljade nähtavuse, laiuse ja kõrguse, avamisel vaikevälja aktiveerimise jne.

Hallatavate vormide 1C 8.2 ja tavavormide 1C kasutamine

Vaikimisi kasutatakse paksu (tavalise) 1C kliendi konfiguratsioonides tavalisi 1C vorme ja õhukese ja veebipõhise 1C kliendi konfiguratsioonides hallatud vorme. Siiski saab 1C mõlemat vormi kasutada mis tahes konfiguratsioonis, sealhulgas samaaegselt.

Selleks tuleb sisestada ka konfiguratsiooni omadused (konfiguratsiooniakna ülemine element).

1C 8.2 konfiguratsiooniatribuutides on ilmunud kaks uut märkeruutu, mis võimaldavad lubada 1C vormide mittestandardset kasutamist.

Hallatavate vormide loomine 8.2

Uue vormi 1C 8.2 lisamine toimub samamoodi nagu varem – kasutades klaviatuuril nuppu Ins või nuppu Lisa. Olemasoleva sisestamiseks topeltklõpsake sellel hiirega.

Vaikimisi luuakse konfiguratsioonis määratud vorm (tavaline või hallatav) (vt konfiguratsiooni atribuutide atribuuti Põhikäivitusrežiim).

Konstruktor palub teil valida vormi tüübi - elemendi vorm, loend. Siin saate vormi käsuribasid lisada või eemaldada. Enamasti jäetakse need sätted vaikimisi samaks.

Avaneb vaikimisi täidetud vorm - kõik sellele lisatud 1C objekti üksikasjad. Konstruktori teisel vahekaardil saate märgistada konkreetse kohustuslike väljade loendi.

Vormiredaktor koosneb kolmest jaotisest.

• Ülemises vasakus nurgas on vormielementide loend. See koosneb väljadest, käskudest ja rühmadest, mis võimaldavad teil üksusi kombineerida. Käskude loendit saab eraldi vaadata vahekaardil Käsuliides.
• Paremas ülanurgas on saadaolevate vormiatribuutide ja objektiatribuutide loend (ava rist atribuudi Object kõrval).
• Allpool on saadud vormi eelvaade.

Saate lohistada saadaolevad üksikasjad vasakule ja sellest saab vormielement (väli vormil).

Kui teil on vaja lisada nupp või menüüelement - vahekaardi Käsud paremas servas peate looma uue käsu. See on vormimooduli funktsiooni ümbris. Lisaks sellele, et määrata, millist funktsiooni tegelikult kutsutakse, saate määrata esituse – näiteks pildi, aga ka nähtavuse sõltuvuse funktsionaalsest valikust.

Ka käsklusi lohistatakse vasakule. Kui vanem on käsuriba, siis on see käsuriba nupp - muidu lihtsalt nupp.

Vormi elementide (väljade) loendis saab objekti/vormi atribuuti mitte ainult lohistada, vaid ka lihtsalt lisada (nupp Add või Ins). Eelkõige saate luua uue vormiobjekti - rühma.

Grupp võib olla käsupaneel (kursor peab asuma real Vorm). Seejärel lohistad sellesse käsud ja need muutuvad nuppudeks.

Rühm võib olla "tavaline". Siis on see viis väljade rühmitamiseks nii vertikaalselt kui ka horisontaalselt. Grupi nime saab atribuutides eemaldada.

Rühm võib olla paneel (leheküljed). Ülemine lisatud rühm on paneel ja seda tüüpi pesastatud rühmad on lehed. Väljad juba lohistatakse lehtedele.

Mittevajalikud vormielemendid eemaldatakse, kustutades loendist vormielemendid.
Välja asukoht vormil määratakse elementide loendis oleva järjekorra järgi (vertikaalne) või rühmade kaupa (horisontaalne). Laius ja kõrgus määratakse vormielemendi atribuutides.

Vormielemendi atribuute on oluliselt laiendatud ja need sisaldavad palju kasulikku – nii välimuse juhtimist (valiku- ja tühjendusnupud) kui ka vaikeväärtuste kontrollimist.

Vormi enda omadused, sealhulgas selle mõõtmed, määratakse sama nimega vormi juurelemendis Vorm.

Sündmuste töötlejad (vastus kasutaja toimingutele) on nüüd jagatud kahte tüüpi. Vanad - nagu varemgi, on need määratud vormi ja väljade atribuutides (näiteks OnChange ja OnOpening vormi). Uus - on muutunud käskudeks ja neid kasutatakse menüüüksuste ja nuppude jaoks.

Alates platvormi versioonist 8.2 hakkas 1C kasutama uusi põhimõtteid liidese ehitamiseks ja kasutaja interaktsiooniks andmebaasiga. Uus tehnoloogia kannab nime Managed Application. Kõige rohkem on töödeldud vormide koostamise mehhanismid ning 1C-serveri kasutaja ja andmebaasi vahelise suhtluse skeem. Platvorm toetab endiselt tavarežiimi, kuid aja jooksul lülituvad kõik 1C kasutajad hallatud vormidele.

Tavakasutajate jaoks erineb 1C dokumendi hallatav vorm tavalisest ainult välimuse poolest. Arendaja jaoks on see uus mehhanism, millel on oma reeglid, seadused ja tingimused. Paljud valdkonnad on muutunud, kuid kogenud 1C arendajate seas peetakse võtmetähtsusega järgmisi uuendusi:

• Vormistruktuuri iseseisev moodustamine ja väljade paigutus platvormi poolt. Kui varasemad arendajad kirjeldasid välja asukohta pikslite määramisega, siis nüüd on võimalik määrata vaid rühmituse tüüp;
• Vorm koosneb vormiandmeid esindavatest atribuutidest ja käskudest – sooritatavatest protseduuridest ja funktsioonidest;
• Vormi kood täidetakse nii serveri kui ka kliendi poolel. Vorm ise on ju serveris loodud ja kliendis kuvatav konfiguratsiooniobjekt. See tähendab, et see ühendab kliendi ja serveri osad;
• Kliendi poolel on mitut tüüpi andmed muutunud kättesaamatuks ja nüüd pole enam võimalust infobaasis andmeid muuta;
• Iga protseduuri või funktsiooni jaoks tuleb määrata spetsiaalne seadistus – kompileerimisdirektiiv. See vastutab koodi käivitamise koha eest ja võib võtta järgmisi väärtusi:
  • kliendi kohta;
  • serveris;
  • On ServerWithoutContext;
  • OnClientOnServer;
  • Kliendil serveris ilma kontekstita.

Viimane punkt on hallatavate vormide režiimis eriti terav. Kui arendaja ei tunne hästi juhiseid ega kliendi-serveri suhtlust, on tal hallatava vormi loomine äärmiselt keeruline. Kõiki uusi hallatavate vormide loomise põhimõtteid rakenduses 1C: Enterprise 8.3 ühendab kolmetasandilise arhitektuuri üldkontseptsioon. See hõlmab klientarvuteid, 1C-serverit ja DBMS-i, kus andmeid salvestatakse.

Erinevaks on muutunud ka hallatava vormi redigeerimine konfiguraatoris. Paljud aspektid on muutunud ja versiooni 7.7 arendajad, kus hallatud vorme polnud, võivad olla üllatunud. Muutunud on isegi vormikujundaja välimus, mida on näha konfiguratsiooniobjekti mis tahes vormi avades. Objekti avamisel näeme akent, mis on jagatud mitmeks osaks:

1. Vormi liidese elemendid. Üleval vasakul on aken, mis loetleb kõik valitud vormil kuvatavad väljad, mis tagavad programmi suhtluse kasutajaga;
2. Vormi üksikasjad. Paremas ülanurgas on kõik andmed, millega vorm töötab. Just neisse salvestatakse info kliendi poolel;
3. Hallatud vormi kuvamine. Allpool näeme liidese elementide põhjal välimuse eelvaadet;
4. Vormi moodul. Jaotis, mis sisaldab selles vormis kasutatavaid protseduure ja funktsioone. Siit leiate algoritmide koodi programmi interaktsiooniks nii kasutaja kui ka andmebaasiga.

1C arendajad õhutavad kliente hallatud vormidele üle minema, seega on hallatavate vormide arendamise põhimõtete õppimine aja küsimus. Seda tüüpi vormidega töötamist alustades saate aru, et see on samm arenduse standardimise ja ühtsete reeglite järgimise suunas. Seetõttu tõstab 1C 8.3 hallatavate vormidega töötamise võimalus teie taset 1C arendajana.

Juhised hallatavate vormide kujundamiseks

Esiteks, 1C hallatava režiimi mehhanismi mõistmiseks peaksite meeles pidama, et vorm on olemas nii serveris kui ka kliendis. Veelgi enam, kliendil on see objekt ainult pilt kasutajaliidesest programmiga. Kõik arvutused, algoritmid, arvutused ja töötlemine peavad toimuma ainult serveri poolel. Seda ei tingi mitte ainult suutmatus kasutada kliendil paljusid funktsioone ja parameetreid, vaid ka jõudlusnõuded.

Seda, kus protseduur sooritatakse, saad aru saada käskkirja nimetusest, mis tuleb vormimoodulis iga protseduuri ja funktsiooni ette kirjutada. Sõnastus "Kontekstita" näitab, et hallatava vormi andmeid ei edastata serveris sellele protseduurile. Seega ei ole selliste protseduuride puhul võimalik kasutaja sisestatud väärtuste põhjal algoritme kirjutada. Kui seda sõnastust pole täpsustatud, edastatakse vorm tervikuna koos kõigi üksikasjadega ja saate neile juurde pääseda.

1C arendajad soovitavad tungivalt kasutada kontekstiväliseid serverikõnesid, vähendada nende arvu nii palju kui võimalik ja püüda mitte kliendiga arvutusi teha. Ilma teoreetilise taustata algajatel arendajatel on raske kõiki neid reegleid järgida ja koodi õigesti muuta. Enne iseseisva töö alustamist on kasulik avada hallatud konfiguratsioonivorm, vaadata süntaksit ning seda, kuidas klient ja server omavahel suhtlevad.

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

1C vormide väljatöötamise uutest reeglitest on palju kasu, kui kõik arendajad neist kinni peavad. Veelgi enam, kõik tunnevad muutusi paremuse poole - nii programmeerijad ja 1C-s töötavad ettevõtted kui ka frantsiisivõtjad ja 1C arendajad. Hallatud vormide korrektse toimimise peamised tagajärjed 1C-s:

1. Konfiguratsiooni hooldamise lihtsus ja parem koodi loetavus. Sellest võime järeldada, et ühe arendaja kirjutatud algoritmi saab alati teine ​​töötaja parandada ilma palju aega kulutamata;
2. Kliendis ja serveris töötava koodi eraldamine. Arvestades, kui erinevad on mõlemal poolel saadaolevad funktsioonid, oleks nende eraldamine õige samm;
3. Arendajatel on sügavam arusaam platvormi loogikast, kliendi-serveri interaktsioonidest ja nende kirjutatud algoritmidest. Versioonides 8.0 ja varasemates versioonides oli väga levinud dokumentide või kataloogide vormide leidmine, mis töötati välja ilma klient-serveri osast aru saamata;
4. Konfigureerimise kiiruse suurendamine ja klientarvutite koormuse vähendamine;
5. Töökohtade arvutite ostmise kulude vähendamine, kuna puudub vajadus võimsate personaalarvutite ostmiseks.

Hallatud vormi valimine peamiseks 1C käivitusrežiimiks võib tuua palju üllatusi. Kuid õige lähenemisviisi korral toob see samm suuri dividende, nii et üha rohkem 1C kasutajaid kogu Venemaal otsustab selle kasuks. Arvestades asjaolu, et 1C ettevõte loodab tulevikus hallatavate vormide arendamisele, on riskantne jääda vananenud tavapäraste vormide juurde.