Splošni moduli 1s 8.3. Pravila za ustvarjanje skupnih modulov. Kaj uporabiti

Kaj so moduli in čemu točno so namenjeni? Modul vsebuje programsko kodo. Poleg tega je treba omeniti, da za razliko od platforme 7.7, kjer se lahko koda nahaja v lastnostih elementov obrazca in v celicah tabel postavitve, mora biti v platformi 8.x katera koli vrstica kode v nekem modulu. Običajno je modul sestavljen iz treh odsekov – odseka za opis spremenljivk, odseka za opis postopkov in funkcij ter odseka za glavni program. Ta struktura je značilna za skoraj vse module platforme, z nekaterimi izjemami. Nekateri moduli nimajo odseka z opisom spremenljivk ali odseka glavnega programa. Na primer modul seje in kateri koli splošni modul.

Kontekst izvajanja modulov je na splošno razdeljen na odjemalca in strežnika. Poleg tega je mogoče nekatere module prevesti tako na strani odjemalca kot na strani strežnika. In nekateri so izključno na strani strežnika ali strani odjemalca. Torej:

Aplikacijski modul

Modul je zasnovan tako, da ujame trenutke zagona aplikacije (nalaganje konfiguracije) in prenehanja njenega delovanja. In postopke preverjanja je mogoče umestiti v ustrezne dogodke. Na primer, ko zaženete aplikacijo, posodobite nekaj referenčnih konfiguracijskih podatkov, ko končate delo, vprašajte, ali se jo sploh splača zapustiti, morda delovni dan še ni končan. Poleg tega prestreza dogodke iz zunanje opreme, na primer trgovalne ali fiskalne. Omeniti velja, da aplikacijski modul opisane dogodke prestreže le ob interaktivnem zagonu. Tisti. ko se ustvari samo okno programa. To se ne zgodi, če se aplikacija zažene v com povezave.

V platformi 8.2 sta dva različna aplikacijska modula. To sta modul Regular Application in modul Managed Application. Sprožijo se, ko se zaženejo različni odjemalci. Tako se sproži modul upravljane aplikacije, ko se spletni odjemalec, tanek odjemalec in debel odjemalec zaženejo v načinu upravljane aplikacije. Običajni aplikacijski modul se sproži, ko se debeli odjemalec zažene v običajnem aplikacijskem načinu.

Aplikacijski modul lahko vsebuje vse razdelke – opise spremenljivk, postopkov in funkcij ter opise glavnega programa. Aplikacijski modul je sestavljen na strani odjemalca, zato nas to močno omejuje pri dostopnosti številnih vrst podatkov. Kontekst aplikacijskega modula lahko razširite z uporabo metod običajnih modulov, ki imajo nastavljeno lastnost »Server Call«. Vse spremenljivke in metode, ki so označene kot izvozne, bodo na voljo v katerem koli konfiguracijskem modulu, ki se izvaja na strani odjemalca. Vendar, ne glede na to, kako mamljivo je, tega ne smete objaviti tukaj. veliko število metode. Več kode vsebuje, daljši je čas prevajanja in s tem čas zagona aplikacije, kar je za uporabnike zelo moteče.

Kot je navedeno zgoraj, aplikacijski modul obravnava dogodke zagona in zaključka aplikacije. Za obravnavo vsakega od teh dogodkov v aplikacijskem modulu obstaja par obdelovalcev Pred... in Ko... Razlike med njima so takšne, da pri izvajanju kode v obdelovalniku Pred... dejanje še ni in lahko zavrnemo njegovo izvedbo. Temu je namenjena možnost Zavrni. V obdelovalcih On.. je dejanje že izvedeno in ne moremo zavrniti zagona aplikacije ali izstopiti iz nje.

Modul za zunanjo povezavo

Namen modula je podoben namenu aplikacijskega modula. Obdeluje začetno in končno točko aplikacije. Zunanji povezovalni modul se sproži, ko se aplikacija zažene v načinu com povezave. Sam postopek zunanjega združevanja je neinteraktiven proces. V tem načinu poteka programsko delo z informacijsko bazo in okno aplikacije se ne odpre, kar nalaga določene omejitve pri uporabi metod, namenjenih interaktivnemu delu. V tem načinu ni mogoče uporabiti klicev pogovornih obrazcev, opozorilnih sporočil itd. Preprosto ne bodo delovali.

Tako kot v aplikacijskem modulu so tukaj na voljo razdelki za opis spremenljivk, metod in razdelek za glavni program. Lahko tudi deklarirate izvozne spremenljivke in metode. Razlika je v tem, da v načinu povezave com vse delo z informacijsko bazo poteka na strani strežnika, zato se zunanji povezovalni modul sestavi izključno na strežniku. V skladu s tem izvozne spremenljivke in metode običajnih odjemalskih modulov niso na voljo v njem.

Sejni modul

To je zelo specializiran modul in je namenjen izključno inicializaciji parametrov seje. Zakaj ste morali narediti svoj modul za to? To je posledica dejstva, da lahko postopek inicializacije zahteva izvedbo neke kode, poleg tega pa je lahko aplikacija zagnana pod različnimi odjemalci (kar vodi do izvajanja različnih aplikacijskih modulov ali zunanjega povezovalnega modula) in inicializacija parametre seje je treba izvesti v katerem koli načinu zagona. Zato je bil potreben dodaten modul, ki deluje v katerem koli načinu zagona aplikacije.

V modulu seje obstaja en sam dogodek »SettingSessionParameters«, ki se izvede zelo prvi, celo pred dogodkom modula aplikacije BeforeSystemStartOperation. Razdelek za deklaracijo spremenljivk in razdelek glavnega programa v njem nista na voljo. Prav tako ne morete deklarirati metod izvoza. Modul je sestavljen na strani strežnika.

Naj vas ne premami dejstvo, da se ta modul izvede vsakič, ko se aplikacija zažene, in vanj ne smete postaviti kode, ki ni neposredno povezana z inicializacijo parametrov seje. To je posledica dejstva, da se lahko upravljalnik SetSessionParameters večkrat kliče med delovanjem sistema. To se na primer zgodi v primerih, ko dostopamo do neinicializiranih parametrov. In čeprav je mogoče ujeti trenutek prvega zagona tega dogodka (Zahtevani parametri so tipa Nedefinirano), je treba upoštevati, da je ta modul sestavljen v privilegiranem načinu, tj. ne nadzoruje pravic dostopa. In drugo je, da še vedno ne moremo biti stoodstotno prepričani, da bo sistem zagnan. Nenadoma v modulu aplikacij se bo zgodilo napaka in poskušamo izvesti nekaj dejanj z bazo podatkov.

Skupni moduli

Moduli so namenjeni opisovanju nekaterih pogostih algoritmov, ki bodo klicani iz drugih konfiguracijskih modulov. Splošni modul ne vsebuje odseka z opisom spremenljivk in odseka glavnega programa. V njem lahko deklarirate metode izvoza, katerih kontekst dostopnosti bo določen z zastavicami prevajanja. Zaradi dejstva, da razdelek z opisom spremenljivk ni na voljo, globalnih spremenljivk ni mogoče definirati v skupnih modulih. Če želite to narediti, morate uporabiti funkcije običajnih modulov s predpomnjenjem vrnjenih vrednosti ali aplikacijskega modula. Upoštevati je treba, da tudi če je lastnost ponovne uporabe modula v skupni rabi nastavljena na »Za čas trajanja seje«, potem v tem primeru življenjska doba predpomnjenih vrednosti ne presega 20 minut od trenutka zadnjega dostopa do njih.
Obnašanje skupnega modula je odvisno od nastavljenih parametrov (globalni ali ne, različne zastavice prevajanja, ali je na voljo klic strežnika itd.). V tem članku ne bomo obravnavali vseh vrst nastavitev, pa tudi vedenjskih lastnosti in pasti, ki nastanejo pri nerazumni nastavitvi zastavic lastnosti. To je tema za ločen članek. Oglejmo si le nekaj točk, ki jih je treba upoštevati pri nastavljanju zastavic:

Dobro pravilo je, da globalne zastave ne uporabljate povsod. S tem se skrajša čas zagona aplikacije, izboljša pa se tudi berljivost kode (seveda, če ima skupni modul povsem smiselno ime).
Ni priporočljivo uporabljati več kot ene zastavice prevajanja. Ni veliko metod, ki jih je treba izvajati v različnih kontekstih, in če so takšne metode še vedno potrebne, se jim lahko dodeli ločen skupni modul.
Zastavica "Server Call" je smiselna le, če je modul preveden "On the server". Zato je treba vse druge zastavice prevajanja odstraniti, da se izognete različnim težavam.
Če metode modula vključujejo obsežno obdelavo podatkov, branje in pisanje v bazo podatkov, je za povečanje hitrosti dela bolje onemogočiti nadzor dostopa z nastavitvijo zastavice »Privilegirano«. Ta način je na voljo samo za module v skupni rabi, prevedene na strežniku.

Modul obrazca

Zasnovan je za obdelavo uporabniških dejanj, tj. razni dogodki v zvezi z vnosom podatkov in obdelavo pravilnosti njihovega vnosa. Modul običajne oblike je v celoti sestavljen na naročniku. Modul kontrolirani obliki je jasno razmejen s kontekstom izvajanja, zato morajo vse spremenljivke in metode imeti direktivo prevajanja. Če direktiva ni izrecno navedena, bo ta spremenljivka ali metoda prevedena na strani strežnika. Modul obrazca vsebuje razdelke za opise spremenljivk in metod ter razdelek za glavni program.

Objektni modul

Ta modul je značilen za številne konfiguracijske objekte in je na splošno namenjen obdelavi dogodkov objektov. Na primer dogodki za snemanje in brisanje predmetov, dogodki za objavo dokumentov itd.

Nekateri dogodki modula objekta podvajajo dogodke modula obrazca. Na primer dogodki, povezani s posnetkom. Vendar ne pozabite, da se bodo dogodki modula obrazca izvajali izključno na specifičnem obrazcu objekta. Na splošno je lahko teh oblik več. In dogodki objektnega modula bodo poklicani v vsakem primeru, tudi v trenutku programskega dela z objektom. Če morate torej v vseh primerih izvesti neko kodo, je za to bolje uporabiti dogodek objektnega modula.

Objektni modul se prevede izključno na strežniku. V njem lahko definirate izvozne spremenljivke in metode, ki bodo na voljo v drugih konfiguracijskih modulih. Z uporabo teh lastnosti in metod lahko znatno razširimo funkcionalnost objekta.

Modul upravljalnika objektov

Ta modul obstaja za številne konfiguracijske objekte. Glavni namen tega modula je redefinicija standardnega izbirnega dogodka, ki se zgodi ob vstopu v linijo in razširitev funkcionalnosti upravitelja. Modul je sestavljen na strani strežnika. Omogoča vam definiranje lastnosti in metod izvoza. Klicanje izvoznih metod upravitelja ne zahteva ustvarjanja samega predmeta.

Vsemu naštetemu lahko dodate sliko nekaterih konfiguracijskih modulov in načinov medsebojnega klicanja metod v načinu upravljane aplikacije. Puščica označuje smer, v katero se lahko obrnete, da pokličete ustrezno metodo. Kot je razvidno iz diagrama, je kontekst strežnika popolnoma zaprt. Toda iz konteksta odjemalca je mogoče dostopati do strežniških metod.

Simboli na diagramu: O.M. Odjemalec - Skupni modul odjemalca; O.M. Strežnik – skupni modul strežnika; M.F. Odjemalec - Odjemalski postopki modula obrazca; M.F. Strežnik - Strežniške procedure modula obrazca.

Vsak program je sestavljen iz programske kode, to je pravzaprav zaporedja dejanj, napisanih v katerem koli jeziku, ki jih je treba izvesti.

Vendar mora biti prav ta program nekje napisan, torej nekje lociran. V večini primerov je programska koda zapisana v datotekah z navadnim besedilom. Edina razlika je v tem, da končnica v njih ni .txt, temveč .cpp ali .php.

Kje je napisan program 1C?

Kaj je modul 1C?

Seveda bi lahko kodo 1C zapisali tudi v kakšno besedilno datoteko. Vendar pa obstaja koncept konfiguracije 1C - ki ne vključuje le seznama nastavitev, predlog obrazcev itd., Temveč tudi programsko kodo 1C. Zato je koda 1C shranjena v konfiguraciji.

Konfiguracija je sestavljena iz objektov 1C, kot smo že razpravljali v prejšnjih lekcijah. Vsak objekt 1C vsebuje ugnezdene predmete, na primer imenik ima več oblik.

Vsak objekt 1C, vključno z nekaterimi ugnezdenimi, ima svoj modul - določen besedilna datoteka, ki vsebuje programsko kodo.

Obstajajo tudi objektno neodvisni moduli, v katere je mogoče zapisati programsko kodo, ki je neodvisna od določenega objekta.

Tako v 1C ni "enotnega" programa. Za vsak konfiguracijski objekt 1C obstaja nabor modulov za pisanje programske kode.

Kako se uporabljajo moduli 1C?

Celoten program lahko v grobem razdelimo na dve vrsti:

Objektna metoda
Reakcija na dogodke.

Metode. Kot smo že povedali, je objekt 1C integralna struktura, ki vključuje podatke in metode za njihovo obdelavo. Te metode so niz dejanj (metod), ki jih je mogoče poklicati za obdelavo podatkov. Primer takega dejanja je DirectoryObject.Write() – zapiše element imenika v bazo podatkov.

Metode številnih objektov 1C so lahko standardne (tj. programirane v platformi 1C) in jih napiše programer v jeziku 1C. S pomočjo drugega lahko po želji razširite funkcionalnost predmetov 1C.

Dogodki. Dogodki so na voljo v številnih drugih razvojnih orodjih. Namen programa ni le, da ob zagonu nekaj izračuna, ampak tudi podpira delo uporabnika.

Uporabniški dogodek - uporabnik je pritisnil gumb. Kot odgovor se bo izvedel del kode, ki se bo odzval na dejanja uporabnika.

Sistemski dogodki - objekt 1C smo zabeležili v bazo podatkov. Prišlo je do sistemskega dogodka »Write object«. Možno je konfigurirati reakcijo, ki se bo zgodila na dogodke, ki jih ni povzročil uporabnik (ki je pritisnil gumb ali naredil kaj drugega), ampak sistem sam. Osupljiv primer takega dogodka je začetek programa.

Vrstni red izvedbe modulov 1C

Mnogi jeziki imajo tak koncept kot "vstopna točka". To je prva vrstica ali funkcija, ki bo izvedena ob zagonu programa.

V 1C obstaja več takih vstopnih točk - za vsako vrsto stranke. Se pravi, da je pri zagonu debelega odjemalca ena vstopna točka, pri zagonu tankega odjemalca druga. To vam omogoča programiranje funkcij, ki se razlikujejo glede na različne vrste stranke.

Vstopna točka v ustreznem modulu sta upravljalnika sistemskih dogodkov BeforeSystemStart() oziroma WhenSystemStart() (tj. po vrstnem redu). Te funkcije se izvedejo prve, lahko samodejno nekaj zaženejo.

Če se nič ni zagnalo samodejno, se pred uporabnikom odpre vmesnik 1C in potem je vse odvisno od njega. Pritisne gumb – izvede se upravljalnik klikov na gumb (ki lahko nato tudi nekaj samodejno zažene).

Delo z moduli 1C

Izdelano v konfiguratorju. Modul lahko odprete v oknu Konfiguracija.

Moduli programske opreme vsebujejo izvršljivo kodo v jeziku 1C, ki je potrebna, da se na določen način odzove na dejanja sistema ali uporabnika, ko vizualna razvojna orodja niso dovolj. V programskih modulih lahko opišemo tudi lastne metode (postopke in funkcije).

Običajno je programski modul sestavljen iz treh delov:

območje deklaracije spremenljivke;
področje opisa postopkov in funkcij;
glavno besedilo programa.

Primer strukture programski modul:

//***************** OBMOČJE ZA DEKLARACIJO SPREMENLJIVE ***********************

Izvoz priimka Perem; /
/to je globalna spremenljivka Spremenite ime, patronim;
//to je spremenljivka modula Perem polno ime;

//to je tudi spremenljivka modula in do nje je mogoče dostopati

//iz katerega koli postopka in funkcije našega modula

//**************** PODROČJE OPIS POSTOPKOV IN FUNKCIJ ****************
Postopek Postopek1 () Spremenljivka Skupaj ; /

/Rezultat je lokalna spremenljivka (spremenljivka postopka)

Skupaj = Priimek + " "+ Ime + " "+ Srednje ime;

Konec postopka

Funkcija Funkcija1()

// funkcijski operaterji

Return(LastName + " "+ Name);

EndFunction

//******************** GLAVNO BESEDILO PROGRAMA ***********************
Priimek = "Ivanov";
Ime = "Ivan";

//******************************************************************************

Patronim = "Ivanovič";
V določenem programskem modulu lahko katero koli področje manjka. postavljen od začetka besedila modula do prvega stavka postopka ali funkcije ali katerega koli izvršljivega stavka. Ta razdelek lahko vsebuje samo izjave o deklaraciji spremenljivk.

Območje za opisovanje postopkov in funkcij postavljen od prvega stavka postopka ali funkcije do katerega koli izvršljivega stavka zunaj telesa opisa postopka ali funkcije.

Glavno besedilno območje programa se postavi od prvega izvršljivega stavka zunaj telesa procedur ali funkcij do konca modula. Ta razdelek lahko vsebuje samo izvršljive stavke. Glavno besedilno področje programa se izvede v trenutku inicializacije modula. Običajno je v razdelku glavnega programa smiselno postaviti operaterje za inicializacijo spremenljivk s kakršnimi koli specifičnimi vrednostmi, ki jih je treba dodeliti pred prvim klicem postopkov ali funkcij modula.

Programski moduli se nahajajo na tistih mestih v konfiguraciji, ki lahko zahtevajo opis določenih algoritmov delovanja. Ti algoritmi morajo biti formalizirani v obliki procedur ali funkcij, ki jih bo poklical sistem sam v vnaprej določenih situacijah (na primer, ko odprete obrazec imenika, ko pritisnete gumb v pogovornem oknu, ko spremenite predmet itd.) .

Vsak posamezen programski modul sistem zaznava kot enotno celoto, zato se vsi postopki in funkcije programskega modula izvajajo v enem samem kontekstu.

Kontekst izvajanja modula je razdeljen na odjemalca in strežnik. Poleg tega je mogoče nekatere programske module prevesti tako na strani odjemalca kot na strani strežnika.

Aplikacijski modul (upravljan ali navaden)

Aplikacijski modul opisuje postopke (obdelovalce) dogodkov, ki se inicializirajo na začetku in koncu sistema. Na primer, ko se aplikacija zažene, lahko posodobite nekaj konfiguracijskih podatkov, ko zaprete aplikacijo, pa lahko vprašate, ali se sploh splača zapustiti program. Poleg tega ta modul prestreže dogodke iz zunanje opreme, na primer trgovalne ali fiskalne. Omeniti velja, da se aplikacijski modul izvaja le, ko se aplikacija zažene interaktivno, torej ko se zažene programsko okno. To se ne zgodi, če je aplikacija zagnana v načinu povezave com.
V platformi 1C 8 sta dva različna aplikacijska modula. To sta modul Regular Application in modul Managed Application. Sprožijo se, ko se zaženejo različni odjemalci. Tako se modul upravljane aplikacije sproži, ko se spletni odjemalec, tanek odjemalec in debel odjemalec zaženejo v načinu upravljane aplikacije. Običajni aplikacijski modul se sproži, ko se debeli odjemalec zažene v običajnem aplikacijskem načinu. Nastavitev načina zagona aplikacije je podana v konfiguracijski lastnosti "Osnovni način zagona".

Aplikacijski modul lahko vsebuje vse 3 razdelke - deklaracije spremenljivk, opise postopkov in funkcij ter glavno besedilo programa. Aplikacijski modul je sestavljen na strani odjemalca, kar močno omejuje našo uporabo številnih tipov podatkov. Kontekst aplikacijskega modula lahko razširite z uporabo metod običajnih modulov, ki imajo nastavljeno lastnost »Server Call«. Vse spremenljivke in metode aplikacijskega modula, ki so označene kot izvoz, bodo na voljo v katerem koli konfiguracijskem modulu, ki se izvaja na strani odjemalca. Ne glede na to, kako mamljivo je, sem ne bi smeli postaviti velikega števila postopkov in funkcij. Več kot je kode v določenem modulu, daljši je čas prevajanja in posledično čas zagona aplikacije.

Kot je navedeno zgoraj, aplikacijski modul obravnava dogodke zagona in zaključka aplikacije. Za obravnavo vsakega od teh dogodkov v aplikacijskem modulu obstaja par obdelovalcev Pred... in Ko... Razlike med njima so naslednje: pri izvajanju kode v obdelovalniku Pred... dejanje še ni in lahko zavrnemo njegovo izvedbo. Temu je namenjena možnost Zavrni. V obdelovalcih On.. je dejanje že izvedeno in ne moremo zavrniti zagona aplikacije ali izstopiti iz nje.

Modul za zunanjo povezavo

lahko vsebuje vsa 3 področja
ki se nahaja v korenskem delu konfiguracije

Namen modula je podoben namenu aplikacijskega modula. Obdeluje začetne in končne dogodke aplikacije. Zunanji povezovalni modul se sproži, ko se aplikacija zažene v načinu com povezave. Sam proces zunanjega združevanja ni interaktiven proces. V tem načinu poteka programsko delo z informacijsko bazo in okno aplikacije se ne odpre, kar nalaga določene omejitve pri uporabi metod, namenjenih interaktivnemu delu. V tem načinu ni mogoče uporabiti klicev pogovornih obrazcev, opozoril in sporočil uporabniku itd. Enostavno jih ne bodo usmrtili.

Tako kot v aplikacijskem modulu so tukaj na voljo vsa tri področja: deklaracije spremenljivk, opisi postopkov in funkcij ter glavno besedilo programa. Glavna razlika od aplikacijskega modula je v tem, da v načinu com-povezave vse delo z informacijsko bazo poteka na strani strežnika, zato je zunanji povezovalni modul sestavljen na strani strežnika. V skladu s tem izvozne spremenljivke in metode običajnih odjemalskih modulov niso na voljo v njem.

Sejni modul

deluje na strani strežnika
ki se nahaja v korenskem delu konfiguracije

To je visoko specializiran modul, zasnovan izključno za inicializacijo parametrov seje. Zakaj ste morali narediti svoj modul za to? Njegova uporaba je posledica dejstva, da je samo aplikacijo mogoče zagnati v različnih načinih (kar vodi do izvajanja upravljanega aplikacijskega modula, navadnega aplikacijskega modula ali zunanjega povezovalnega modula) in je treba izvesti inicializacijo parametrov seje ne glede na način zagona. Da ne bi napisali isto programsko kodo v vseh treh teh modulih smo potrebovali dodaten modul, ki deluje ne glede na način zagona aplikacije.

Skupni moduli

lahko vsebuje področje, ki opisuje postopke in funkcije
izvaja se na strani strežnika ali odjemalca (odvisno od nastavitev modula)
se nahaja v veji drevesa konfiguracijskih objektov “Splošno” - “Splošni moduli”

Skupni moduli so namenjeni opisovanju nekaterih skupnih algoritmov, ki bodo klicani iz drugih konfiguracijskih modulov. Splošni modul ne vsebuje območij za deklaracijo spremenljivk in glavnega besedila programa. V njem lahko navedete metode izvoza, katerih razpoložljivost bo določena z nastavitvami modula (na kateri strani se izvaja: na strani strežnika ali odjemalca). Zaradi dejstva, da razdelek z opisom spremenljivk ni na voljo, globalnih spremenljivk ni mogoče definirati v skupnih modulih. Za to lahko uporabite aplikacijski modul.

Obnašanje skupnega modula je odvisno od nastavljenih parametrov (globalni ali ne, različne zastavice prevajanja, ali je na voljo klic strežnika itd.). Tukaj je nekaj nasvetov za nastavitev običajnih modulov:

Dobra praksa je, da globalne zastave ne uporabljate povsod. To bo skrajšalo čas zagona aplikacije, izboljšalo pa se bo tudi berljivost kode (seveda, če ima skupni modul povsem smiselno ime);
- Ni priporočljivo uporabljati več kot ene zastavice prevajanja. Ni toliko metod, ki jih je treba izvajati v različnih kontekstih, in če so takšne metode še vedno potrebne, se jim lahko dodeli ločen skupni modul;
- zastavica “Klicni strežnik” je smiselna le, če je modul preveden “Na strežniku”. Zato je treba vse druge zastavice prevajanja odstraniti, da se izognete različnim težavam;
- če metode modula vključujejo obsežno obdelavo podatkov, branje in pisanje v bazo podatkov, je za povečanje hitrosti dela bolje onemogočiti nadzor pravic dostopa z nastavitvijo zastavice »Privilegirano«. Ta način je na voljo samo za module v skupni rabi, prevedene na strežniku.

Modul obrazca

lahko vsebuje vsa 3 področja
izvajajo na strani strežnika in odjemalca

Modul obrazca je zasnovan za obdelavo uporabniških dejanj s tem obrazcem (obdelava dogodka klika na gumb, spreminjanje atributov obrazca itd.). Obstajajo tudi dogodki, ki so neposredno povezani s samim obrazcem (na primer njegovo odpiranje ali zapiranje). Moduli upravljane in navadne oblike se razlikujejo predvsem po tem, da je modul upravljane oblike jasno razdeljen na kontekst. Vsak postopek ali funkcija mora imeti direktivo za prevajanje. Če direktiva prevajanja ni navedena, potem ta postopek ali pa se funkcija izvaja na strani strežnika. IN redna oblika vsa koda se izvaja na strani odjemalca.

Struktura upravljanega obrazca vsebuje razdelek za deklaracije spremenljivk, opise postopkov in funkcij ter glavno besedilo programa (izvedeno v času inicializacije obrazca). Do standardnih dogodkov obrazca lahko dostopamo prek seznama pričakovanih postopkov in funkcij obrazca (Ctrl+Alt+P), ali prek palete lastnosti samega obrazca.

Če ima obrazec dodeljen glavni atribut, postanejo lastnosti in metode aplikacijskega objekta, uporabljenega kot glavni atribut, na voljo v modulu obrazca.

Objektni modul

lahko vsebuje vsa 3 področja
deluje na strani strežnika

Ta modul je na voljo za večino konfiguracijskih objektov in je na splošno namenjen obdelavi dogodkov, ki so neposredno povezani z objektom. Na primer dogodki snemanja in brisanja predmetov, preverjanje izpolnitve podrobnosti objekta, objavljanje dokumenta itd.

Nekateri dogodki modula objekta podvajajo dogodke modula obrazca. Na primer dogodki, povezani s posnetkom. Vendar je treba razumeti, da se bodo dogodki modula obrazca izvajali izključno v določeni obliki predmeta, to je, ko je določena oblika odprta. In dogodki objektnega modula bodo poklicani v vsakem primeru, tudi v trenutku programskega dela z objektom. Če torej potrebujete metode, povezane z objektom, ne da bi bile vezane na določeno obliko predmeta, je za to bolje uporabiti objektni modul.

Modul upravljalnika objektov

lahko vsebuje vsa 3 področja
deluje na strani strežnika

Modul upravljalnika objektov se je pojavil šele od različice 1C 8.2. Modul upravitelja obstaja za vse objekte aplikacije in je zasnovan za upravljanje tega objekta kot konfiguracijskega objekta. Modul upravitelja vam omogoča razširitev funkcionalnosti objekta z uvedbo (pisanja) postopkov in funkcij, ki se ne nanašajo na določen primerek objekta baze podatkov, temveč na sam konfiguracijski objekt. Modul upravljalnika objektov vam omogoča, da postavite običajne postopke in funkcije za določen objekt in dostopate do njih od zunaj, na primer iz obdelave (seveda, če bo ta postopek ali funkcija z ključna beseda Izvoz). Kaj nam to prinaša novega? Na splošno nič razen organiziranja postopkov po objektih in njihovega shranjevanja na ločenih mestih - moduli upravitelja objektov. Te postopke in funkcije lahko prav tako umestimo v splošne module, vendar 1C priporoča umestitev splošnih postopkov in funkcij objektov v modul Object Manager. Primeri uporabe postopkov in funkcij modula Object Managers: začetno izpolnjevanje posameznih podrobnosti imenika ali dokumenta pod določenimi pogoji, preverjanje izpolnjevanja podrobnosti imenika ali dokumenta pod določenimi pogoji itd.

Ukazni modul

lahko vsebuje razdelek, ki opisuje postopke in funkcije
izvede na strani odjemalca

Ukazi so objekti, podrejeni objektom aplikacije ali konfiguraciji kot celoti. Vsak ukaz ima ukazni modul, v katerem je mogoče opisati vnaprej določen postopek CommandProcess() za izvedbo tega ukaza.

zdravo
V tej objavi si bomo ogledali aplikacijski modul, njegov namen in mesto prevajanja.

1C aplikacijski modul je namenjena predvsem ulovu trenutka zagona in trenutka izklopa aplikacije.
Tukaj so tudi upravljalniki, ki vam omogočajo prestrezanje zunanjega dogodka iz opreme.

Dogodki modula upravljane aplikacije se sprožijo, ko se zaženejo lahki odjemalec, spletni odjemalec in debel odjemalec upravljane aplikacije.
Modul upravljane aplikacije spremlja interaktivni zagon sistema.

Modul upravljane aplikacije vsebuje:
razdelek za deklaracijo spremenljivk
razdelek z opisom postopkov in funkcij
glavni del programa
Postopke, funkcije in spremenljivke upravljanega modula lahko opišemo kot izvoz (dostopen zunaj danega modula). Ta modul lahko vsebuje tudi posebne obdelovalce dogodkov, ki se pojavijo v določenih okoliščinah.

Oglejmo si seznam upravljavcev, ki jih lahko prikličemo s pritiskom na ( Ctrl+Alt+P).
Preden se sistem zažene - dejanje se še ni zgodilo (1C Enterprise 8.2 se zažene, vendar se sama aplikacija še ni pojavila na zaslonu). Če je parameter »Napaka« nastavljen na »True«, se aplikacija preprosto ne bo zagnala. Ko se sistem zažene - je dejanje že končano (ni parametra »napaka«). Pred zaustavitvijo sistema - aplikacija še ni izginila (obstaja parameter »napaka«).
Ob zaustavitvi sistema se je interaktivno okno že zaprlo.

Oglejte si pomočnika za sintakso in preberite več o upravljanih in rednih dogodkih aplikacij.

Aplikacijski modul je vedno v celoti sestavljen na strani odjemalca. Tisti. iz njega lahko dostopamo do strežniških procedur in funkcij običajnih modulov in ne bomo mogli dostopati do konfiguracijskih objektov, kot so dokumenti, imeniki.
Ko se sistem zažene, se upravljani aplikacijski modul prevede in več kot je v njem deklariranih izvoznih postopkov in funkcij, dlje bo trajal zagon sistema.

Redni aplikacijski modul

Običajni aplikacijski modul lahko vidite na istem mestu kot upravljani aplikacijski modul, če pa ni viden, potem v parametrih konfiguratorja na zavihku »Splošno« izberite možnost »Urejanje konfiguracije za načine zagona« na »Upravljano uporaba in običajna uporaba.
Kako to storiti, glejte članek:.

Običajni dogodki modula aplikacije se sprožijo, ko se zažene debeli odjemalec navadne aplikacije.
Vse, kar je bilo povedano za modul upravljane aplikacije, velja tudi za modul navadne aplikacije.

Dogodki pred... in med....

Razlika med postopki pred začetkom delovanja sistema (napaka) in ob začetku delovanja sistema ()

Preden sistem začne delovati (Zavrnitev) - dejanje še ni zaključeno in lahko zavrnemo njegovo izvedbo.
AtSystemStart() - dejanje je že končano in ne moremo zavrniti zagona aplikacije ali izstopa iz nje.

To je vse, hvala za vašo pozornost.

Pustite komentarje, vaše mnenje je zame pomembno.

Stražar: Registracija zdravniških potrdil v 10 minutah. Za pridobitev potrdila državnega inšpektorata za varnost prometa morate porabiti nekaj dni, vendar obstaja možnost nakupa potrdila za licenco. Možno je dostaviti potrdilo in priložiti tudi kopijo licenc

P.S. In všeč mi je Jamala - You're Made of Love

1.1. Skupni moduli so ustvarjeni za izvajanje postopkov in funkcij, združenih glede na nekatere značilnosti. Praviloma so postopki in funkcije enega konfiguracijskega podsistema (prodaja, nabava) ali postopki in funkcije podobne funkcionalnosti (delo z nizi, splošni namen) umeščeni v en skupni modul.

1.2. Ko razvijate skupne module, morate izbrati enega od štirih kontekstov izvajanja kode:

	Skupni tip modula	Primer imena	Klic strežnika	Strežnik	Zunanji spoj	Stranka (redna aplikacija)	Stranka (upravljana aplikacija)
1.	Strežnik	Splošni namen (ali strežnik za splošne namene)
2.	Strežnik za klic odjemalca	GeneralPurposeCallServer
3.	Stranka	Odjemalec za splošne namene (ali Global Purpose)
4.	Odjemalec-strežnik	Splošni namen ClientServer

2.1. Skupni moduli strežnika so namenjeni gostovanju strežniških postopkov in funkcij, ki niso na voljo za uporabo iz odjemalske kode. Izvajajo vso interno strežniško poslovno logiko aplikacije.
Za pravilno delovanje konfiguracije v zunanji povezavi, upravljani in običajni načini uporabe, strežniške procedure in funkcije je treba postaviti v skupne module z naslednjimi lastnostmi:

Strežnik(potrditveno polje Klic strežnika ponastavi),
Naročnik (redna aplikacija),
Zunanji spoj.

V tem primeru je zmožnost klicanja strežniških procedur in funkcij s parametri spremenljivih vrst (npr. DirectoryObject, DocumentObject itd.). Običajno je to:

upravljalniki za naročnine na dogodke dokumentov, imenikov ipd., ki za parameter sprejmejo spremenljivo vrednost (objekt).
strežniških procedur in funkcij, ki jim je predmet posredovan kot parameter iz modulov imenikov, dokumentov itd., kot tudi iz modulov z naročninami na dogodke.

Moduli v skupni rabi na strani strežnika so poimenovani v skladu s splošnimi pravili za poimenovanje metapodatkovnih objektov.
Na primer: Delo z datotekami, Splošni namen

V nekaterih primerih je mogoče dodati postfix, da preprečite navzkrižje imen z lastnostmi globalnega konteksta "strežnik".
Na primer: RoutineTasksServer, Data ExchangeServer.

2.2. Skupni moduli strežnika za klicanje iz odjemalca vsebujejo strežniške postopke in funkcije, ki jih je mogoče uporabiti iz odjemalske kode. Sestavljajo odjemalski programski vmesnik aplikacijskega strežnika.
Takšni postopki in funkcije so umeščeni v skupne module z naslednjo funkcijo:

Strežnik(potrditveno polje Klic strežnika nameščen)

Skupni moduli na strani strežnika za klicanje iz odjemalca so poimenovani v skladu s splošnimi pravili za poimenovanje metapodatkovnih objektov in morajo biti poimenovani s postfiksom "CallServer".
Na primer: Delo s strežnikom FilesCalling

Upoštevajte, da izvozni postopki in funkcije v takšnih skupnih modulih ne smejo vsebovati parametrov spremenljivih vrst ( DirectoryObject, DocumentObject itd.), saj je njihov prenos iz kode odjemalca (ali na) nemogoč.

Glej tudi:Omejitev nastavitve zastavice »Klic strežnika« za običajne module

2.3. Skupni moduli odjemalca vsebujejo odjemalčevo poslovno logiko (funkcionalnost definirana samo za odjemalca) in imajo naslednje značilnosti:

Odjemalec (upravljana aplikacija))
Naročnik (redna aplikacija)

Izjema je, ko morajo biti postopki in funkcije odjemalca na voljo samo v načinu upravljane aplikacije (samo v načinu navadne aplikacije ali samo v načinu zunanje povezave). V takih primerih je sprejemljiva druga kombinacija teh dveh lastnosti.

Skupni moduli odjemalca so poimenovani s postfiksom "Stranka".
Na primer: Delo z FilesClient, Odjemalec splošnega namena

Glejte tudi: minimiziranje kode, ki se izvaja na odjemalcu

2.4. V nekaterih primerih je dovoljeno ustvariti skupne module odjemalec-strežnik s postopki in funkcijami, katerih vsebina je enaka tako na strežniku kot na odjemalcu. Takšni postopki in funkcije so umeščeni v skupne module z naslednjimi značilnostmi:

Odjemalec (upravljana aplikacija)
Strežnik(potrditveno polje Klic strežnika ponastavi)
Naročnik (redna aplikacija)
Zunanji spoj

Pogosti moduli te vrste so poimenovani s postfiksom "ClientServer".
Na primer: Delo z FilesClient, Splošni namen ClientServer

Na splošno ni priporočljivo definirati skupnih modulov tako za strežnik kot za odjemalca (upravljano aplikacijo). Priporočljivo je implementirati funkcionalnost, definirano za odjemalca in strežnik v različnih skupnih modulih – glejte odstavke. 2.1 in 2.3. To eksplicitno ločevanje poslovne logike odjemalca in strežnika narekujejo razmišljanja o povečanju modularnosti aplikacijske rešitve, poenostavitvi nadzora razvijalcev nad interakcijo odjemalec-strežnik in zmanjšanju tveganja napak zaradi temeljnih razlik v zahtevah za razvoj odjemalca in strežnika. kodo (potreba po minimiziranju kode, ki se izvaja na odjemalcu, različna razpoložljivost objektov in tipov platform itd.). V tem primeru morate upoštevati neizogibno povečanje števila skupnih modulov v konfiguraciji.

Poseben primer mešanih odjemalsko-strežniških modulov so obrazec in ukazni moduli, ki so posebej zasnovani za implementacijo strežniške in odjemalske poslovne logike v enem modulu.

3.1. Priporočljivo je, da imena skupnih modulov sledijo splošnim pravilom za poimenovanje metapodatkovnih objektov. Ime splošnega modula se mora ujemati z imenom podsistema ali ločenega mehanizma, katerega postopke in funkcije izvaja. Priporočljivo je, da se v imenih običajnih modulov izogibate splošnim besedam, kot so "postopki", "funkcije", "obdelovalci", "modul", "funkcionalnost" itd. in jih uporabljajte le v izjemnih primerih, ko bolj popolno razkrivajo namen modula.

Da bi razlikovali med skupnimi moduli istega podsistema, ki so ustvarjeni za izvajanje postopkov in funkcij, ki se izvajajo v različnih kontekstih, je priporočljivo, da jim dodelite postfikse, opisane prej v odstavkih. 2.1-2.4.

Začetek