Artikeln fortsätter serien "Första stegen i utvecklingen på 1C", den diskuterar i detalj följande frågor:

• Vad är en mjukvarumodul och vilka sektioner består den av?
• Vad är applikationsmodulen till för? Varför är det två av dem? När lanseras vilken? Vilka är subtiliteterna i verket?
• Vilka händelser är förknippade med start av systemdrift, hur och var ska de behandlas?
• Vad är den externa anslutningsmodulen till för? När och hur ska man använda det?
• När används sessionsmodulen?
• Vad är vanliga moduler? Vilka är dess egenskaper och verksamhetsregler? Varför använda egenskapen "Återanvändning av returvärden"?
• När används formulärmodulen och vilka händelser kan behandlas i den?
• Vad är objektmodulen till för? Vilka avsnitt består den av? Hur kan man se tillgängliga modulhändelser?
• Vilka är finesserna i att arbeta med moduler för värdehanterare (för konstanter) och moduler för postuppsättningar (för register)?
• Vad är skillnaderna mellan en objektmodul och en managermodul? När ska du använda den senare?

Tillämplighet

Artikeln diskuterar 1C:Enterprise-plattformen 8.3.4.496. Materialet är även relevant för aktuella plattformssläpp.

Moduler i "1C:Enterprise 8.3"

Moduler är de objekt som innehåller programkod.

Det finns ett ganska stort antal typer av moduler i plattformen, som var och en har sitt eget syfte och funktioner.

Alla kodrader måste finnas i någon modul. Det finns generella moduler och objektmoduler. Vissa moduler kan kompileras på både klienten och servern, och vissa bara på servern.

En modul kan bestå av flera sektioner. Variabelbeskrivningsavsnittet beskriver lokala variabler för denna modul, som sedan kan användas i alla förfaranden.

Inom varje procedur kan du komma åt en modulvariabel. Dessutom kan det inom själva proceduren finnas en annan variabeldeklaration med samma namn. Detta kommer att vara en lokal variabel i denna procedur.

Trots samma namn är dessa två olika variabler: en används i en specifik procedur och den andra används utanför den.

I vissa moduler kan variabler ha en kompileringsplats (tillgänglighet) på servern eller klienten. Till exempel:

Avsnittet som beskriver variabler följs av ett avsnitt med procedurer och funktioner, där lokala metoder för denna modul anges. Vissa moduler måste ange var proceduren eller funktionen kommer att kompileras.

Sammanställningsdirektivet kan i princip utelämnas. I det här fallet är standardkompileringsdirektivet Server. Men för att underlätta analys av programkod, rekommenderas det att uttryckligen ange var en given procedur kommer att kompileras. Ordningen i vilken procedurerna beskrivs spelar ingen roll.

I slutet av modulen, efter att ha beskrivit alla procedurer och funktioner, finns det en sektion av huvudprogrammet, som kan innehålla några operatorer och initiera lokala variabler i formulärmodulen. Det här avsnittet körs när du kommer åt modulen.

Så, till exempel, när du öppnar ett elementformulär, exekveras huvudprogramdelen av formulärmodulen först.

Det bör noteras att sektionen för variabeldeklaration och huvudprogramsektionen inte finns för alla moduler (dvs dessa sektioner är inte giltiga i vissa moduler). En sektion för att beskriva procedurer och funktioner kan finnas i absolut vilken modul som helst.

Applikationsmodul

Den här modulen är utformad för att hantera händelser av applikationsstart och uppsägning. Till exempel, när du startar programmet kan du ladda ner valutakurser från Internet. När du avslutar en applikation kan du bekräfta med användaren att han eller hon har för avsikt att avsluta.

Även i applikationsmodulen finns det speciella hanterare som låter dig fånga upp externa händelser från utrustningen.

Dessa kan vara händelser från en magnetisk kortläsare eller skatteregistrator. Och dessa händelser kan också bearbetas på något sätt.

Observera att det är den interaktiva uppstarten av systemet som övervakas i applikationsmodulen.

Applikationsmodulen fungerar inte om 1C-programmet startas, till exempel i com-anslutningsläge. I det här fallet skapas inte programfönstret.

Det bör noteras att det i Plattform 8.3 finns två olika applikationsmoduler: modulen Managed Application och Regular Application-modulen. Händelser för hanterade applikationsmoduler bearbetas när den tunna och tjocka klienten för hanterad applikation och webbklient startas.

Modul Regelbunden tillämpning fungerar när den tjocka klienten körs i läge Regelbunden tillämpning, som innehåller det vanliga kommandogränssnittet i formuläret Huvudmeny.

Om applikationen körs in Hanterade, och i läge Regelbunden tillämpning, då är det nödvändigt att beskriva hanterarprocedurerna som för modulen Hanterad applikation, och för modulen Regelbunden tillämpning.

Modul Hanterad applikation kan väljas från snabbmenyn för rotkonfigurationsnoden.

Denna modul kan också öppnas från egenskapspaletten för rotkonfigurationselementet.

För att öppna en modul Regelbunden tillämpning, bör du se konfigurationsinställningarna (kommando alternativ på menyn Service).

Formuläret öppnas alternativ. På bokmärket Är vanliga konfigurationsredigeringsläge måste anges Hanterad applikation Och Regelbunden tillämpning.

I det här fallet modulen Regelbunden tillämpning det kommer också att vara möjligt att öppna från rotnodens egenskaper.

Lista över händelser som kan behandlas för Hanterade Och Regelbunden tillämpningär samma.

Denna modul kan innehålla en variabeldeklarationssektion, en beskrivningsdel av godtyckliga procedurer och funktioner och en huvudprogramsektion. Men förutom godtyckliga procedurer och funktioner kan speciella händelsehanterare finnas i modulen.

Listan över tillgängliga hanterare kan ses genom att anropa listan med procedurer och funktioner för den aktuella modulen när modulen är öppen.

Fönstret Procedurer och funktioner som öppnas visar alla procedurer och funktioner för denna modul, såväl som händelser för vilka hanterare ännu inte har skapats.

Det finns två händelser associerade med starten av systemet ("före" och "vid"). Två händelser associerade med systemavstängning ("före" och "vid"). Och även bearbetning av externa evenemang (till exempel evenemang med kommersiell utrustning).

När en "före"-händelsehanterare exekveras anses åtgärden inte ha ägt rum ännu. När händelsehanteraren "at" exekveras har åtgärden redan slutförts.

Händelse Innan du startar systemet inträffar i det ögonblick då Enterprise 8.3 startas, men själva applikationen har ännu inte dykt upp på skärmen. Denna händelse har följande parameter: Vägran.

Om denna parameter tar värdet Sann, då startar inte programmet. Händelse När du startar systemet antar att åtgärden redan har slutförts, fönstret har redan skapats, och i det här fallet kan vi till exempel visa någon speciell form. Det går inte längre att neka uppskjutning.

På samma sätt, innan du stänger av systemet, är applikationen fortfarande öppen och du kan vägra att stänga den. När systemet stängs av har programfönstret redan stängt. Det är bara möjligt att utföra ytterligare åtgärder, till exempel att radera vissa filer eller skicka ett e-postmeddelande.

I modulen Hanterad applikation Direktiv för kompilering av procedurer och funktioner är inte specificerade, eftersom modulen är helt kompilerad på klientsidan. Detta innebär att vi i modulens rutiner och funktioner inte kommer att kunna direkt komma åt till exempel referensböcker.

Om från modul Hanterad applikation behöver ringa ett serveranrop, då måste du skapa special för detta med en flagga .

I modulen Regelbunden tillämpning Det finns inga sådana begränsningar, eftersom denna modul kommer att kompileras när den tjocka klienten laddas. Nästan alla typer av data är tillgängliga i den tjocka klienten.

Procedurer, funktioner och variabler för en applikationsmodul kan beskrivas som exporter.

Eftersom modulen är helt kompilerad på klienten betyder det att vi i klientprocedurer kan komma åt denna metod och denna egenskap.

Du kan till exempel anropa en procedur eller funktion för en applikationsmodul från ett objekts formulärmodul. Det rekommenderas dock att använda gemensamma moduler för att beskriva allmänna algoritmer. Huvudsyftet med applikationsmodulen är att bearbeta startpunkten och slutpunkten.

I analogi med en applikationsmodul är denna modul utformad för att behandla programöppningshändelsen och avstängningshändelsen.

Till skillnad från applikationsmodulen, som initieras i ögonblicket för interaktiv start av applikationen, arbetar den externa anslutningsmodulen i COM-anslutningsläge, dvs. när ett 1C:Enterprise 8-objekt skapas och kopplas till en specifik databas.

Den här modulen har händelser: När du startar systemet Och Vid avstängning av systemet.

Den externa anslutningsmodulen kan öppnas med antingen snabbmenyn på rotkonfigurationsobjektnivån eller egenskapspaletten för rotnoden.

Själva processen med extern anslutning är en process av programmatiskt arbete med informationsbasen, och inte interaktiv. Följaktligen kan du för närvarande inte använda dialogformulär eller visa varningsmeddelanden, eftersom det inte finns något användargränssnitt.

I External Connection Module är det möjligt att beskriva exportvariabler och exportmetoder som kommer att finnas tillgängliga på den sida där det externa anropet till 1C:Enterprise 8.3 sker.

Eftersom det inte finns något användargränssnitt i en yttre anslutning, kompileras Outer Join-modulen helt på servern.

Sessionsmodul

Denna modul behövs för att initiera sessionsparametrar. Sessionsparametrar är snabba globala variabler vars värden är tillgängliga var som helst i konfigurationen.

Du kan öppna sessionsmodulen antingen via snabbmenyn eller genom egenskapspaletten för rotnoden.

Sessionsmodulen tillhandahåller en händelse SettingSessionParameters.

När applikationen startar anropas denna procedur först. Sessionsparametrar behövs för alla programoperationer: både när den startas interaktivt och när den startas i externt anslutningsläge.

Sessionsmodulen beskriver olika åtgärder för att initiera sessionsparametrar beroende på olika förhållanden.

Denna modul beskriver som regel flera procedurer som anropas från proceduren SettingSessionParameters. Därför är alla dessa procedurer uppdelade i en separat modul.

Sessionsmodulen körs alltid i privilegierat läge. Detta innebär att ingen behörighetskontroll kommer att utföras vid åtkomst till databasen. Sessionsmodulen kompileras på Servern, d.v.s. Det är möjligt att komma åt alla servermetoder (inklusive att läsa värden från databasen).

I Sessionsmodulen är det möjligt att definiera endast procedurer och funktioner, d.v.s. det finns ingen variabelbeskrivningssektion och ingen huvudprogramsektion. Du kan inte definiera exportmetoder i en sessionsmodul.

Om det vid start av systemet är nödvändigt att utföra vissa åtgärder på servern, till exempel skapa ett element i en katalog, är det som ett alternativ möjligt att använda sessionsmodulen, eftersom den kompileras på servern och exekveras alltid tillförlitligt vid systemstart. Följande punkter måste dock beaktas:

• procedur SettingSessionParameters exekveras inte bara vid systemstart, utan även vid åtkomst till oinitierade sessionsparametrar. De där. SetSessionParameters-hanteraren kan anropas upprepade gånger under applikationsdrift;
• om antalet element i sessionsparametrarnas array är noll (arrayen med nödvändiga parametrar har en datatyp av Odefinierad), då är detta ögonblicket då applikationen startas;
• eftersom sessionsmodulen fungerar i privilegierat läge och det inte kommer att ske någon kontroll av åtkomsträttigheter, bör du arbeta mycket noggrant med databasobjekt, eftersom användaren kan få tillgång till data som inte ska tillhandahållas honom;
• När systemet startar är det ännu inte säkert känt om applikationen kommer att startas. I det här fallet kan onödiga åtgärder utföras i händelsehanteraren SetSessionParameters.

Dessa moduler representerar en beskrivning av några generella algoritmer, dvs. rutiner och funktioner som kan anropas från olika ställen.

Logiskt relaterade metoder kan grupperas i olika gemensamma moduler. Dessa moduler skapas i grenen Allmänt.

Du kan lägga till valfritt antal delade moduler. För att göra Common Module-metoder tillgängliga någon annanstans i konfigurationen måste de definieras med nyckelordet Export. Klientprocedurer för vanliga moduler kommer att finnas tillgängliga på klienten och server - på servern.

I allmänna moduler är endast avsnittet som beskriver procedurer och funktioner tillgängligt. De där. i den allmänna modulen kan du inte beskriva variabler och du kan inte beskriva en del av huvudprogrammet.

Om en global variabel behövs kan du använda antingen sessionsparametrar eller.

För allmänna moduler kan du ställa in några parametrar som kommer att påverka denna moduls beteende. Om egenskapen Global är inställd för en Allmän modul, kommer exportmetoderna som deklareras i denna modul att vara tillgängliga utifrån direkt, utan några ytterligare instruktioner.

De där. de Allmän modul kommer att delta i bildandet av den globala konfigurationskontexten.

Fast egendom Global för allmänna moduler kan det vara användbart. Du bör dock inte använda den överallt för alla vanliga moduler.

De där , som är markerade med skylten Global, kommer att kompileras vid systemstart. Ju fler sådana moduler, desto långsammare startar programmet.

Om flaggan Global För Allmän modul inte specificeras, kommer kompilering av denna modul att utföras vid tidpunkten för det första anropet till den (dvs efter att systemet startar).

Dessutom påverkar användningen av globala gemensamma moduler förståelsen av koden. Metoder för en icke-global gemensam modul kallas genom namnet Allmän modul och metodnamnet, till exempel:
Cost Calculation Module.DistributeIndirectCosts();

I detta fall måste namnen på gemensamma moduler återspegla innehållet i de procedurer som beskrivs i dem. Att specificera namnet på den gemensamma modulen när du anropar en procedur hjälper till att bättre förstå koden.

För Allmän modul V Egenskaper palett du kan ställa in egenskapen Privilegierad.

Den privilegierade modulen kontrollerar inte åtkomsträttigheter. Detta är nödvändigt om Allmän modul Det krävs för att utföra massdatabehandling, hämta data från databasen.

Att kontrollera åtkomsträttigheter ökar tiden det tar att komma åt en databas, och massalgoritmer behöver ofta fungera så snabbt som möjligt.

Löne är till exempel en resurskrävande verksamhet. Det måste göras så snabbt som möjligt. För att göra detta placeras algoritmer som beräknar löner i privilegierade .

Samtidigt ligger alla rutiner som säkerställer ifyllandet av lönehandlingar utanför dessa Vanliga moduler. Det är i dessa procedurer som kontroll av åtkomsträttigheter utförs.

På så sätt kan betydande prestandaförbättringar uppnås. Detta gäller särskilt när man använder en mekanism för rad-för-rad åtkomstkontroll till tabellposter.

Om en gemensam modul är privilegierad, kan procedurerna för denna modul endast kompileras på servern.

Det finns situationer då något objekt skulle vara otillgängligt för användaren, till exempel en viss katalog. Men när du utför ett dokument är hänvisning till denna uppslagsbok nödvändig.

De där. Det finns ett behov av att tillfälligt utöka användarrättigheterna och sedan återställa dem till sitt ursprungliga tillstånd. Denna effekt kan erhållas genom att använda privilegierad Vanliga moduler.

Att göra detta i en privilegierad Allmän modul Du bör skapa en procedur som får åtkomst till de nödvändiga uppgifterna.

Denna procedur kommer att anropas från motsvarande dokument. De där. användaren beviljas faktiskt utökade rättigheter vid den tidpunkt då denna procedur anropas.

För Vanliga moduler Det är möjligt att ange kompileringsplatsen. Flaggorna används för att avgöra om den gemensamma modulen kommer att vara tillgänglig på klienten (hanterad applikation), på servern eller i läge för extern anslutning.

Dessutom, om du byter konfigurationsredigeringsläge till Hanterad applikation och vanlig applikation, kommer en annan kompileringskontext att vara möjlig - Klient (vanlig applikation).

Det finns alltså fyra alternativ för hur programmet fungerar. Beroende på den applikation som körs, beroende på arbetet på klienten eller på servern, kommer vissa gemensamma moduler att vara tillgängliga eller otillgängliga.

Förutom möjligheten att specificera kompileringsflaggor är det möjligt att specificera kompileringsdirektiv för procedurer och funktioner som finns i Common Module.

Om ett kompileringsdirektiv specificeras för en metod, så kommer, även om Common Module är tillgänglig i alla specificerade sammanhang, tillgängligheten för den specifika metoden att begränsas av kompileringsdirektivet.

I det här fallet kan proceduren inte nås i ett sammanhang som inte är tillgängligt för hela modulen.

Om du inte anger ett kompileringsdirektiv för en procedur (funktion) kommer den att kompileras i alla sammanhang som definieras för modulen.

De där. I huvudsak kommer flera kopior av proceduren att göras. Valet av en viss kompilerad instans beror på var proceduren anropas (av den närmaste anropsregeln). Det bör beaktas att koden för ett sådant förfarande måste skrivas med hänsyn till dess tillgänglighet i alla sammanhang som definieras för modulen.

Generiska moduler som samtidigt är tillgängliga i flera olika sammanhang är i första hand utformade för att skapa procedurer som är tillgängliga i flera sammanhang.

När du skapar en allmän modul anses det vara god praxis att inte specificera kompileringsdirektiv. De där. Tillgängligheten av procedurer och funktioner bör bestämmas av egenskaperna för själva modulen.

Med detta tillvägagångssätt kommer klientprocedurer att placeras i separata gemensamma moduler och serverprocedurer kommer att finnas i separata gemensamma moduler.

Moduler som har flera kompileringsflaggor används extremt sällan i praktiken. Det här är några vanliga åtgärder som är tillgängliga på både klient och server. Vanligtvis är det några enkla beräkningar.

Viktig! Det är möjligt för klienten att komma åt exportservermetoderna för en gemensam modul, men endast om denna gemensamma modul endast kompileras på servern. I detta fall tillhandahålls en speciell flagga för att ge åtkomst från klienten .

För icke-globala Common-moduler är det möjligt att cachelagra värdena som returneras av funktioner. De där. Efter det första anropet av en funktion kan systemet komma ihåg resultatet av dess exekvering. Om denna funktion anropas igen med samma parametrar kommer systemet att returnera värdet från cachen.

Syftet med denna mekanism är att påskynda upprepade samtal. För att konfigurera detta beteende måste du Egenskaper palett modul, ställ in lämpligt värde för egenskapen Återanvändning av returvärden.

Som standard är den här egenskapen inställd på Använd inte. Andra möjliga värden: cache Under samtalet, eller Under sessionens varaktighet.

Den här egenskapen är vettig att endast använda för de funktioner vars resultat enbart beror på ingångsparametrarna. Denna mekanism är endast tillgänglig för icke-globala gemensamma moduler.

Om värdet på motsvarande parameter har valts Under samtalets varaktighet kommer cachen att fungera så länge som proceduren från vilken General Module-metoden anropades körs. Om värdet Under sessionens varaktighet är valt, antas det villkorligt att cachen kommer att fungera medan användaren arbetar.

Det finns dock vissa tidsbegränsningar. Cachen rensas automatiskt 20 minuter efter att värdet kommit in i cachen.

Formulärmodul

Den här modulen är utformad för att bearbeta användaråtgärder. Beskriv till exempel algoritmen för hur ett program reagerar när en knapp trycks ned. Eller, till exempel, när du anger ett värde i ett fält, kontrollera omedelbart om det är korrekt.

Förutom händelser som är kopplade till formulärkontroller (knappar, inmatningsfält) finns det händelser direkt kopplade till själva formuläret.

Du kan till exempel hantera formulärets öppningshändelse och utföra viss initialisering. Du kan också hantera formulärstängningshändelsen och kontrollera om användaren har skrivit in allt korrekt.

Det finns kontrollerade former och vanliga former. Modulerna i dessa formulär skiljer sig främst genom att modulen för hanterade formulär är tydligt indelad i sitt sammanhang. Varje procedur (funktion) måste ha ett kompileringsdirektiv. I normal form används all kod på Klienten.

I en hanterad formulärmodul kan du deklarera procedurer och funktioner, du kan deklarera variabler och du kan beskriva en del av huvudprogrammet.

Programkoden för huvudprogrammet kommer att exekveras vid tidpunkten för initiering av formuläret, dvs. när användaren börjar öppna den. Bilden visar en lista över standardhändelser för ett hanterat formulär.

Listan över händelser för ett hanterat formulär är också synlig i listan över egenskaper direkt för själva formuläret. Den här listan anropas i redigeraren för hanterade formulär.

I ett hanterat formulär kan du hantera objektets skrivhändelse. Denna händelse är endast närvarande för objektformulär (kataloger, dokument och några andra). Om formuläret inte är bundet till ett specifikt objekt, så finns det ingen skrivhändelse.

För en modul av vanlig form är listan över standardhändelser något mindre, eftersom I en hanterad form görs många händelser för att paras (en exekveras på klienten och den andra på servern). I sin normala form exekveras all kod på klienten.

Objektmodul

Dessa moduler är typiska för kataloger, dokument, planer för typer av beräkningar, kontoplaner och många andra objekt. Objektmodulen är designad för att hantera standardhändelser. Till exempel en händelse för att gå in i ett katalogelement, en händelse för att skriva ett element, ta bort, lägga upp ett dokument, etc.

Skrivhändelsen finns i princip även i formulärmodulen. Men skrivhändelsen i formulärmodulen inträffar under den interaktiva inspelningsprocessen, när man arbetar med ett specifikt formulär.

Write-händelsen i objektmodulen kommer att exekveras på valfri skrivning från vilken form som helst av det givna objektet. Dessutom, om objektet skrivs programmatiskt, kommer objektets modulhändelse att aktiveras.

I händelse av inspelning av objektmodulen kan du bygga in alla kontroller för att data som skrivs är korrekta, eftersom denna procedur kommer att utföras vid tidpunkten för absolut all inspelning.

Modulen för detta objekt kan anropas via snabbmenyn, från paletten Objektegenskaper och från objektredigeringsfönstret.

Bilden nedan visar en lista över tillgängliga katalogmodulhändelser.

I objektmodulen kan du placera en sektion för att beskriva variabler, beskriva godtyckliga funktioner som kanske inte är associerade med en händelse, samt en sektion av huvudprogrammet.

I huvudprogramsektionen kan du till exempel initiera lokala variabler för en given modul. Denna programkod kommer att exekveras när denna objektmodul används.

Det bör noteras att alla procedurer för objektmodulen är kompilerade på servern. Följaktligen krävs inte kompileringsdirektiv för procedurer och funktioner för objektmodulen. Vissa konfigurationsobjekt har inte objektmoduler.

Detta beror på egenskaperna hos själva föremålen. Sådana föremål inkluderar Konstanter Och Register. För Konstant det finns ingen objektmodul, men det finns en mycket liknande modul som kallas Value manager modul.

I Value manager modul du kan hantera skrivhändelser Konstanter och.

Hela modulkontexten exekveras på servern.

För register finns en Recordset Module.

Denna modul har också förmågan att hantera skrivhändelser och utföra beläggningskontroller.

I Object Modules, Value Manager Modules (för konstanter) och Recordset Modules (för register) kan du beskriva metoder som kan göras exporterbara, och dessa metoder kommer att vara tillgängliga utifrån.

De där. Förutom att använda de fasta metoderna för en objektklass kan du skapa ytterligare metoder för ett objekt i objektmodulen. Denna modul ska beskriva motsvarande procedur med nyckelordet Exportera.

Då kommer det att vara möjligt att komma åt denna procedur utifrån. Dessutom kommer denna metod att visas i kontextverktygstipset. Nya metoder i sammanhangsverktygstipset är markerade med blått teckensnitt (blå ikon p() för procedurer och f() för funktioner).

På samma sätt kan du skapa en ny egenskap genom att deklarera en variabel med nyckelordet Exportera. Denna fastighet kan också nås utifrån.

På så sätt är det möjligt att utöka funktionaliteten hos objekt (för att definiera nya metoder och nya egenskaper). Egenskaperna är dock dynamiska och sparas inte i databasen.

Om du behöver använda en egenskap för ett objekt som ska lagras i databasen bör du skapa ett objektattribut.

Managermodul

Denna modul finns för många objekt (kataloger, dokument, register, etc.). Modulen öppnas antingen via snabbmenyn för objektet eller genom Egenskaper palett, eller genom redigeringsfönstret.

I Manager-modulen kan du åsidosätta vissa standardhändelser till exempel i BearbetarReceivingSelectionData, när ett element väljs från katalogen kan ytterligare filtrering eller kontroll göras.

Dessutom kan du skapa ytterligare metoder i Manager Module och ange att de är exportmetoder. I det här fallet är det möjligt att komma åt dessa metoder utifrån.

För att utföra detta samtal är det nödvändigt att erhålla datatypen Directory Manager.

Skillnaden mellan exportmetoderna för Manager Module och Object Module är att för att komma åt metoden för Object Module måste du först skaffa själva objektet (det vill säga på något sätt skaffa en länk och sedan konvertera denna länk till ett objekt) .

Efter detta kommer exportvariabler och metoder för objektmodulen att vara tillgängliga. För Manager Module är samtalet enklare, till exempel:
Kataloger.Motparter.Metodnamn

Det är två olika överklaganden. Konvertera från referens till objekt (metod GetObject) är en ganska allvarlig åtgärd för systemet, eftersom när man tar emot ett objekt läses absolut all data för detta objekt, vilket kan vara ganska långt.

Den andra skillnaden är att Objektmodul kallas i samband med ett specifikt element. Följaktligen kan vi anta att det är tillämpligt för ett givet element (i de flesta fall är det exakt den logik som används).

När det gäller Manager-modulen, beskriver den en vanlig åtgärd för en grupp eller för alla delar av en katalog eller något dokument. Om du till exempel behöver skriva ut ett katalogobjekt kan du använda objektmodulen.

Men i Manager Module är det möjligt att skapa en mer universell mekanism som skriver ut bland annat en grupp av element.

Dessutom är åtkomst till objektmodulen fortfarande en längre åtgärd. Därför är det mer att föredra att lösa detta problem i managermodulen.

Detta avslutar vår bekantskap med modulerna i 1C:Enterprise-systemkonfigurationen. Om vi ​​kort sammanfattar allt ovan, är slutsatserna följande slutsatser:

• En mjukvarumodul är en del av konfigurationen som endast kan innehålla text på det inbyggda 1C-språket
• Mjukvarumoduler klassificeras enligt de typer som vi diskuterade i den här artikeln. Varje vy bestäms av dess placering och tillgängliga programsammanhang.
• Modulens struktur består av flera sektioner, som är arrangerade i en viss sekvens. Sammansättningen av sektioner bestäms av typen av modul.

Observera också att vi medvetet har utelämnat en typ av modul, nämligen kommandomodulen. Det är inget anmärkningsvärt, och vi inbjuder dig att bekanta dig med dess funktionalitet.

Hittills har vi betraktat all vår programkod separat från applikationslösningen, och som regel har vi skrivit den i en egen liten testkonfiguration. Är du medveten om att "du kan inte bara gå" och börja redigera koden för en standardkonfiguration? Nej? Sedan i nästa artikel kommer vi att förklara allt!

1.1. Gemensamma moduler skapas för att implementera procedurer och funktioner förenade enligt någon egenskap. Som regel placeras procedurer och funktioner för ett konfigurationsdelsystem (försäljning, inköp) eller procedurer och funktioner med liknande funktionalitet (att arbeta med strängar, allmänt ändamål) i en gemensam modul.

1.2. När du utvecklar delade moduler bör du välja ett av fyra kodexekveringskontexter:

	Vanlig modultyp	Exempel på ett namn	Serversamtal	Server	Yttre sammanfogning	Klient (vanlig tillämpning)	Klient (hanterad applikation)
1.	Server	General Purpose (eller General Purpose Server)
2.	Server att ringa från klienten	GeneralPurposeCallServer
3.	Klient	General Purpose Client (eller General Purpose Global)
4.	Klient-server	General PurposeClientServer

2.1. Server gemensamma modulerär avsedda att vara värd för serverprocedurer och funktioner som inte är tillgängliga för användning från klientkod. De implementerar all den interna affärslogiken för applikationen.
För korrekt drift av konfigurationen i extern anslutning, hanterade och vanliga applikationslägen, serverprocedurer och funktioner bör placeras i vanliga moduler med följande egenskaper:

• Server(kryssruta Serversamtalåterställa),
• Klient (vanlig applikation),
• Yttre sammanfogning.

I det här fallet, möjligheten att anropa serverprocedurer och funktioner med parametrar av föränderliga typer (till exempel, DirectoryObject, DocumentObject och så vidare.). Vanligtvis är detta:

• hanterare för prenumerationer på händelser av dokument, kataloger, etc., som tar ett föränderligt värde (objekt) som en parameter.
• serverprocedurer och funktioner, till vilka ett objekt skickas som en parameter från moduler av kataloger, dokument etc., samt från moduler med händelseprenumerationer.

Delade moduler på serversidan namnges enligt allmänna regler för namngivning av metadataobjekt.
Till exempel: Arbeta med filer, Generell mening

I vissa fall kan en postfix läggas till för att förhindra namnkonflikter med globala kontextegenskaper "Server".
Till exempel: RoutineTasksServer, Data ExchangeServer.

2.2. Server gemensamma moduler för anrop från klient innehålla serverprocedurer och funktioner som kan användas från klientkod. De utgör applikationsserverns klientprogrammeringsgränssnitt.
Sådana procedurer och funktioner är placerade i vanliga moduler med följande funktion:

• Server(kryssruta Serversamtal installerad)

Server-side gemensamma moduler för anrop från en klient namnges enligt de allmänna reglerna för namngivning av metadataobjekt och måste namnges med en postfix "CallServer".
Till exempel: Arbeta med FilesCalling Server

Observera att exportprocedurer och funktioner i sådana delade moduler inte får innehålla parametrar av föränderliga typer ( DirectoryObject, DocumentObject etc.), eftersom deras överföring från (eller till) klientkod är omöjlig.

Se även:Begränsning av att ställa in flaggan "Serveranrop" för vanliga moduler

2.3. Klients gemensamma moduler innehåller klientens affärslogik (funktionalitet definierad endast för klienten) och har följande egenskaper:

• Klient (hanterad applikation))
• Klient (vanlig applikation)

Undantaget är när klientprocedurer och funktioner endast måste vara tillgängliga i hanterat applikationsläge (endast i vanligt applikationsläge eller endast i externt anslutningsläge). I sådana fall är en annan kombination av dessa två egenskaper acceptabel.

Klientens gemensamma moduler namnges med en postfix "Klient".
Till exempel: Arbeta med FilesClient, Allmänt ändamål klient

Se även: minimera kod som körs på klienten

2.4. I vissa fall är det tillåtet att skapa klient-server gemensamma moduler med procedurer och funktioner, vars innehåll är detsamma på både servern och klienten. Sådana procedurer och funktioner är placerade i vanliga moduler med följande egenskaper:

• Klient (hanterad applikation)
• Server(kryssruta Serversamtalåterställa)
• Klient (vanlig applikation)
• Yttre sammanfogning

Vanliga moduler av denna typ namnges med postfixen "Klient-server".
Till exempel: Arbeta med FilesClient, General PurposeClientServer

I allmänhet rekommenderas det inte att definiera gemensamma moduler för både servern och klienten (hanterad applikation). Det rekommenderas att implementera funktionalitet definierad för klienten och för servern i olika vanliga moduler - se stycken. 2.1 och 2.3. Denna explicita separation av klient- och serveraffärslogik dikteras av överväganden om att öka modulariteten hos applikationslösningen, förenkla utvecklarens kontroll över klient-server-interaktion och minska risken för fel på grund av grundläggande skillnader i kraven för utveckling av klient och server kod (behovet av att minimera kod som exekveras på klienten, olika tillgänglighet av objekt och typer av plattformar, etc.). I det här fallet måste du komma ihåg den oundvikliga ökningen av antalet vanliga moduler i konfigurationen.

Ett specialfall av blandade klient-servermoduler är formulär- och kommandomoduler, som är speciellt utformade för att implementera server- och klientaffärslogik i en modul.

3.1. Det rekommenderas att namn på vanliga moduler följer de allmänna reglerna för namngivning av metadataobjekt. Namnet på den allmänna modulen måste överensstämma med namnet på delsystemet eller den separata mekanismen, vars procedurer och funktioner den implementerar. Det rekommenderas att undvika sådana allmänna ord som "Procedurer", "Funktioner", "Hanterare", "Modul", "Funktionalitet" etc. i namnen på vanliga moduler. och använd dem endast i undantagsfall när de mer fullständigt avslöjar syftet med modulen.

För att skilja mellan vanliga moduler i ett delsystem, som är skapade för att implementera procedurer och funktioner som utförs i olika sammanhang, rekommenderas att ge dem de efterfixar som beskrivits tidigare i stycken. 2,1-2,4.

Vad är moduler och vad exakt är de avsedda för? Modulen innehåller programkoden. Dessutom är det värt att notera att, till skillnad från 7.7-plattformen, där koden kan placeras i egenskaperna för formulärelement och i cellerna i layouttabellerna, i 8.x-plattformen måste vilken kodrad som helst finnas i någon modul . Vanligtvis består en modul av tre sektioner - en sektion för att beskriva variabler, en sektion för att beskriva procedurer och funktioner och en sektion för huvudprogrammet. Denna struktur är typisk för nästan alla plattformsmoduler, med några undantag. Vissa moduler har inte en variabel beskrivningssektion eller en huvudprogramsektion. Till exempel sessionsmodul och valfri allmän modul.

Exekveringskontexten för moduler är i allmänhet uppdelad i klient och server. Dessutom kan vissa moduler kompileras både på klientsidan och på serversidan. Och vissa är uteslutande på serversidan eller klientsidan. Så:

Applikationsmodul

Modulen är utformad för att fånga ögonblicken för applikationsstart (konfigurationsladdning) och avbrytande av dess drift. Och verifieringsprocedurer kan placeras i motsvarande händelser. Till exempel, när du startar en applikation, uppdatera några referenskonfigurationsdata och när du avslutar arbetet, fråga om det är värt att lämna det överhuvudtaget, kanske arbetsdagen inte är över än. Dessutom avlyssnar den händelser från extern utrustning, till exempel handel eller fiskal. Det är värt att notera att applikationsmodulen fångar upp de beskrivna händelserna endast när den startas interaktivt. De där. när själva programfönstret skapas. Detta händer inte om applikationen startas i com-anslutningsläge.

Det finns två olika applikationsmoduler i 8.2-plattformen. Dessa är modulen Regular Application och Managed Application. De utlöses när olika klienter lanseras. Det är så den hanterade applikationsmodulen utlöses när webbklienten, den tunna klienten och den tjocka klienten startas i hanterat applikationsläge. Och den vanliga applikationsmodulen utlöses när den tjocka klienten startas i normalt applikationsläge.

En applikationsmodul kan innehålla alla avsnitt - beskrivningar av variabler, procedurer och funktioner, samt beskrivningar av huvudprogrammet. Applikationsmodulen är kompilerad på klientsidan, så detta begränsar oss i hög grad när det gäller tillgången på många typer av data. Du kan utöka applikationsmodulens sammanhang med metoder för vanliga moduler som har egenskapen "Serveranrop". Alla variabler och metoder som är markerade som export kommer att vara tillgängliga i alla konfigurationsmoduler som körs på klientsidan. Men hur frestande det än är bör du inte lägga upp ett stort antal metoder här. Ju mer kod den innehåller, desto längre blir kompileringstiden, och därför starttiden för applikationen, vilket är väldigt irriterande för användarna.

Som nämnts ovan hanterar applikationsmodulen applikationsstart och avslutningshändelser. För att hantera var och en av dessa händelser i applikationsmodulen finns det ett par hanterare Före... och När... Skillnaderna mellan dem är sådana att när man kör koden i Före...-hanteraren har åtgärden inte ännu ägt rum och vi kan vägra att verkställa det. Detta är vad alternativet Avvisa är till för. I On..-hanterarna har åtgärden redan ägt rum och vi kan inte vägra att starta programmet eller avsluta det.

Extern anslutningsmodul

Syftet med modulen liknar syftet med applikationsmodulen. Den bearbetar applikationens start- och slutpunkter. Den externa anslutningsmodulen utlöses när applikationen startas i com-anslutningsläge. Själva den yttre sammanfogningsprocessen är en icke-interaktiv process. I detta läge sker programmatiskt arbete med informationsbasen och applikationsfönstret öppnas inte, vilket medför vissa begränsningar för användningen av metoder avsedda för interaktivt arbete. I detta läge kan anrop till dialogformulär, varningsmeddelanden etc. inte användas. De kommer bara inte att fungera.

Liksom i applikationsmodulen finns avsnitt för beskrivning av variabler, metoder och ett avsnitt för huvudprogrammet tillgängliga här. Du kan också deklarera exportvariabler och -metoder. Skillnaden är att i com-anslutningsläge sker allt arbete med infobasen på serversidan, så den externa anslutningsmodulen kompileras uteslutande på servern. Följaktligen är exportvariabler och metoder för vanliga klientmoduler inte tillgängliga i den.

Sessionsmodul

Detta är en mycket specialiserad modul och är endast avsedd för att initiera sessionsparametrar. Varför behövde du göra din egen modul för detta? Detta beror på det faktum att initieringsprocessen kan kräva exekvering av viss kod, och dessutom kan applikationen startas under olika klienter (vilket leder till exekvering av olika applikationsmoduler eller en extern anslutningsmodul), och initiering av sessionsparametrar måste göras i valfritt startläge. Därför krävdes en extra modul som körs i valfritt programstartläge.

I sessionsmodulen finns det en enda händelse "SettingSessionParameters", som exekveras allra först, även före applikationsmodulhändelsen BeforeSystemStartOperation. Sektionen för variabeldeklaration och huvudprogramsektionen är inte tillgängliga i den. Du kan inte heller deklarera exportmetoder. Modulen kompileras på serversidan.

Du bör inte frestas av det faktum att den här modulen exekveras när applikationen startas, och du bör inte placera kod i den som inte är direkt relaterad till initieringen av sessionsparametrar. Detta beror på det faktum att SetSessionParameters-hanteraren kan anropas upprepade gånger under systemdrift. Detta händer till exempel i de fall vi kommer åt oinitierade parametrar. Och även om det är möjligt att fånga ögonblicket för den första lanseringen av denna händelse (RequiredParameters är av typen Undefined), bör man ta hänsyn till att denna modul är kompilerad i privilegierat läge, dvs. den styr inte åtkomsträttigheter. Och den andra punkten är att vi fortfarande inte kan vara hundra procent säkra på att systemet kommer att lanseras. Plötsligt uppstår ett fel i applikationsmodulen och vi försöker utföra några åtgärder med databasen.

Vanliga moduler

Moduler är avsedda att beskriva några vanliga algoritmer som kommer att anropas från andra konfigurationsmoduler. Den allmänna modulen innehåller inte en variabelbeskrivningsdel och en huvudprogramdel. Du kan deklarera exportmetoder i den, vars tillgänglighetskontext kommer att bestämmas av kompileringsflaggor. På grund av att avsnittet om variabelbeskrivning inte är tillgängligt kan inte globala variabler definieras i vanliga moduler. För att göra detta måste du använda funktionerna i vanliga moduler med cachelagring av returvärden eller en applikationsmodul. Det är värt att komma ihåg att även om den delade modulens återanvändningsegenskap är inställd på "Under sessionens varaktighet", så i detta fall överstiger inte livslängden för cachade värden 20 minuter från ögonblicket för den senaste åtkomsten till dem.
Beteendet för en gemensam modul beror på de parametrar som ställts in (global eller inte, olika kompileringsflaggor, om ett serveranrop är tillgängligt, etc.). I den här artikeln kommer vi inte att överväga alla typer av inställningar, såväl som beteendeegenskaper och fallgropar som uppstår när du sätter in egendomsflaggor på ett orimligt sätt. Detta är ett ämne för en separat artikel. Låt oss uppehålla oss vid bara några punkter som bör följas när du sätter flaggor:

• En bra tumregel är att inte använda den globala flaggan överallt. Detta kommer att minska starttiden för applikationen och även förbättra kodens läsbarhet (naturligtvis om den gemensamma modulen har ett helt meningsfullt namn).
• Det är inte tillrådligt att använda mer än en kompileringsflagga. Det finns inte många metoder som behöver exekveras i olika sammanhang, och om sådana metoder fortfarande krävs kan en separat gemensam modul allokeras för dem.
• Flaggan "Serveranrop" är bara vettig om modulen är kompilerad "På servern". Därför bör alla andra kompileringsflaggor tas bort för att undvika olika problem.
• Om modulmetoder involverar massiv databearbetning, läsning och skrivning till databasen, är det för att öka arbetshastigheten bättre att inaktivera kontroll av åtkomsträttigheter genom att ställa in flaggan "Privileged". Detta läge är endast tillgängligt för delade moduler kompilerade på servern.

Formulärmodul

Den är utformad för att bearbeta användaråtgärder, d.v.s. olika händelser relaterade till datainmatning och bearbetning av korrektheten av deras inmatning. En modul i vanlig form sammanställs helt på klienten. En hanterad formulärmodul är tydligt avgränsad av exekveringskontext, så alla variabler och metoder måste ha ett kompileringsdirektiv. Om direktivet inte är explicit specificerat kommer denna variabel eller metod att kompileras på serversidan. Formulärmodulen innehåller avsnitt för beskrivningar av variabler och metoder samt ett avsnitt för huvudprogrammet.

Objektmodul

Denna modul är typisk för många konfigurationsobjekt och är vanligtvis avsedd för att bearbeta objekthändelser. Till exempel händelser för att spela in och ta bort objekt, händelser för att lägga upp dokument osv.

Vissa objektmodulhändelser duplicerar formulärmodulhändelserna. Till exempel händelser kopplade till en inspelning. Men förstå att formulärmodulhändelser kommer att exekveras exklusivt på objektets specifika formulär. I allmänhet kan det finnas flera av dessa former. Och händelserna i objektmodulen kommer att anropas i alla fall, även i ögonblicket för programmatiskt arbete med objektet. Därför, om du behöver exekvera någon kod i alla fall, är det bättre att använda en objektmodulhändelse för detta.

Objektmodulen kompileras uteslutande på servern. I den kan du definiera exportvariabler och metoder som kommer att vara tillgängliga i andra konfigurationsmoduler. Med hjälp av dessa egenskaper och metoder kan vi avsevärt utöka objektets funktionalitet.

Objekthanterare modul

Denna modul finns för många konfigurationsobjekt. Huvudsyftet med denna modul är att omdefiniera den standardvalshändelse som inträffar när man går in på en rad och att utöka funktionaliteten hos managern. Modulen kompileras på serversidan. Det låter dig definiera exportegenskaper och metoder. Att anropa chefens exportmetoder kräver inte att man skapar själva objektet.

Till allt ovanstående kan du lägga till en bild av några konfigurationsmoduler och sätt att ömsesidigt anropa metoder i hanterat applikationsläge. Pilen indikerar i vilken riktning du kan vända dig för att anropa motsvarande metod. Som framgår av diagrammet är serverkontexten helt stängd. Men från klientkontexten är det möjligt att komma åt servermetoder.

Symboler på diagrammet: O.M. Klient - Klients gemensamma modul; O.M. Server - Server delad modul; M.F. Klient - Klientprocedurer för formulärmodulen; M.F. Server - Serverprocedurer för formulärmodulen.

Mjukvarumoduler innehåller körbar kod på 1C-språket, vilket är nödvändigt för att kunna svara på ett visst sätt på systemets eller användarens handlingar när visuella utvecklingsverktyg inte räcker. Vi kan även beskriva våra egna metoder (procedurer och funktioner) i mjukvarumoduler.

En mjukvarumodul består vanligtvis av tre sektioner:

• variabelt deklarationsområde;
• område för beskrivning av procedurer och funktioner;
• huvudtexten i programmet.

Exempel på en programmodulstruktur:

//****************** VARIABELL DEKLARATIONSOMRÅDE ***********************

Perem Efternamn Export; / /detta är en global variabel
Byt namn, patonym; //det här är en modulvariabel
Perems fullständiga namn; //detta är också en modulvariabel och kan nås

//från alla förfaranden och funktioner i vår modul

//*************** OMRÅDESBESKRIVNING AV PROCEDURER OCH FUNKTIONER ****************

Procedur Procedur1 ()
Variabel Summa ; / /Result är en lokal variabel (procedurvariabel)

Totalt = Efternamn + " "+ Förnamn + " "+ Mellannamn;

Slut på procedur

Funktion Funktion1()

// funktionsoperatorer

Return(Efternamn + " "+ Förnamn);

EndFunction

//******************* PROGRAMMETS HUVUDTEXT ***********************

Efternamn = "Ivanov";
Namn = "Ivan";
Patronymic = "Ivanovich";

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

I en viss mjukvarumodul kan något av områdena saknas.
Variabelt deklarationsområde placeras från början av modultexten till den första procedur- eller funktionssatsen eller någon körbar sats. Det här avsnittet kan bara innehålla variabelvariabeldeklarationer.

Område för beskrivning av procedurer och funktioner placeras från den första procedur- eller funktionssatsen till valfri körbar sats utanför huvuddelen av proceduren eller funktionsbeskrivningen.

Huvudprogramtextområde placeras från den första körbara satsen utanför huvuddelen av procedurer eller funktioner till slutet av modulen. Det här avsnittet kan endast innehålla körbara satser. Huvudtextområdet i programmet exekveras vid tidpunkten för modulinitiering. Vanligtvis, i en del av huvudprogrammet, är det vettigt att placera operatörer för att initiera variabler med några specifika värden som måste tilldelas före det första anropet till procedurer eller funktioner i modulen.

Mjukvarumoduler finns på de platser i konfigurationen som kan kräva en beskrivning av specifika driftsalgoritmer. Dessa algoritmer bör formaliseras i form av procedurer eller funktioner som kommer att anropas av systemet självt i förutbestämda situationer (till exempel när du öppnar ett katalogformulär, när du trycker på en knapp i en dialogruta, när du ändrar ett objekt, etc.) .

Varje enskild mjukvarumodul uppfattas av systemet som en helhet, så alla procedurer och funktioner i mjukvarumodulen utförs i ett enda sammanhang.

Modulexekveringskontexten är uppdelad i klient och server. Dessutom kan vissa programvarumoduler kompileras på både klientsidan och serversidan.

Applikationsmodul (hanterad eller vanlig)

Applikationsmodulen beskriver procedurerna (hanterare) för händelser som initieras i början och slutet av systemet. Till exempel, när applikationen börjar köras kan du uppdatera en del konfigurationsdata, och när du avslutar applikationen kan du fråga om det är värt att avsluta programmet överhuvudtaget. Dessutom avlyssnar den här modulen händelser från extern utrustning, till exempel handel eller fiskal. Det är värt att notera att applikationsmodulen exekveras endast när applikationen startas interaktivt, det vill säga när programfönstret startas. Detta händer inte om applikationen startas i com-anslutningsläge.
I 1C 8-plattformen finns två olika applikationsmoduler. Dessa är modulen Regular Application och Managed Application. De utlöses när olika klienter lanseras. Således utlöses modulen Managed Application när webbklienten, den tunna klienten och den tjocka klienten startas i hanterat applikationsläge. Och den vanliga applikationsmodulen utlöses när den tjocka klienten startas i normalt applikationsläge. Inställningen för programstartläge anges i konfigurationsegenskapen "Basic launch mode".

En applikationsmodul kan innehålla alla 3 sektioner - deklarationer av variabler, beskrivningar av procedurer och funktioner, samt programmets huvudtext. Applikationsmodulen är kompilerad på klientsidan, vilket i hög grad begränsar vår användning av många datatyper. Du kan utöka applikationsmodulens sammanhang med metoder för vanliga moduler som har egenskapen "Serveranrop". Alla applikationsmodulvariabler och metoder som är markerade som export kommer att vara tillgängliga i alla konfigurationsmoduler som körs på klientsidan. Men hur frestande det än är, bör du inte placera ett stort antal procedurer och funktioner här. Ju mer kod det finns i en given modul, desto längre blir kompileringstiden och följaktligen applikationens starttid.

Som nämnts ovan hanterar applikationsmodulen applikationsstart och avslutningshändelser. För att hantera var och en av dessa händelser i applikationsmodulen finns det ett par hanterare Före... och När... Skillnaderna mellan dem är följande: vid exekvering av kod i Före...-hanteraren har åtgärden inte ännu ägt rum och vi kan vägra att verkställa det. Detta är vad alternativet Avvisa är till för. I On..-hanterarna har åtgärden redan ägt rum och vi kan inte vägra att starta programmet eller avsluta det.

Extern anslutningsmodul

• kan innehålla alla 3 områden
• finns i rotsektionen av konfigurationen

Syftet med modulen liknar syftet med applikationsmodulen. Den behandlar start- och sluthändelserna för applikationen. Den externa anslutningsmodulen utlöses när applikationen startas i com-anslutningsläge. Den yttre sammanfogningsprocessen i sig är inte en interaktiv process. I detta läge sker programmatiskt arbete med informationsbasen och applikationsfönstret öppnas inte, vilket medför vissa begränsningar för användningen av metoder avsedda för interaktivt arbete. I detta läge kan anrop till dialogformulär, varningar och meddelanden till användaren etc. inte användas. De kommer helt enkelt inte att avrättas.

Liksom i applikationsmodulen finns alla tre områden tillgängliga här: variabeldeklarationer, beskrivningar av procedurer och funktioner samt programmets huvudtext. Huvudskillnaden mot applikationsmodulen är att i com-connection-läge sker allt arbete med infobasen på serversidan, så den externa anslutningsmodulen kompileras på serversidan. Följaktligen är exportvariabler och metoder för vanliga klientmoduler inte tillgängliga i den.

Sessionsmodul

• körs på serversidan
• finns i rotsektionen av konfigurationen

Detta är en mycket specialiserad modul som är designad exklusivt för att initiera sessionsparametrar. Varför behövde du göra din egen modul för detta? Dess användning beror på det faktum att själva applikationen kan startas i olika lägen (vilket resulterar i exekvering av antingen en hanterad applikationsmodul, en vanlig applikationsmodul eller en extern anslutningsmodul), och initiering av sessionsparametrar måste göras oavsett i startläget. För att inte skriva samma programkod i alla dessa tre moduler behövde vi ytterligare en modul som körs oavsett applikationsstartläge.

I sessionsmodulen finns det en enda händelse "SettingSessionParameters", som exekveras allra först, även före applikationsmodulhändelsen BeforeSystemStartOperation. Sektionen för variabeldeklaration och huvudprogramsektionen är inte tillgängliga i den. Du kan inte heller deklarera exportmetoder. Modulen kompileras på serversidan.

Vanliga moduler

• kan innehålla ett område som beskriver procedurer och funktioner
• körs på server- eller klientsidan (beroende på modulinställningarna)
• finns i trädgrenen av konfigurationsobjekten "Allmänt" - "Allmänna moduler"

Gemensamma moduler är avsedda att beskriva några vanliga algoritmer som kommer att anropas från andra konfigurationsmoduler. Den allmänna modulen innehåller inte variabla deklarationsområden och huvudprogramtexten. Du kan deklarera exportmetoder i den, vars tillgänglighet kommer att bestämmas av modulinställningarna (på vilken sida det körs: på server- eller klientsidan). På grund av att avsnittet om variabelbeskrivning inte är tillgängligt kan inte globala variabler definieras i vanliga moduler. Du kan använda en applikationsmodul för detta.

Beteendet för en gemensam modul beror på de parametrar som ställts in (global eller inte, olika kompileringsflaggor, om ett serveranrop är tillgängligt, etc.). Här är några tips för att ställa in vanliga moduler:

Det är bra att inte använda den globala flaggan överallt. Detta kommer att minska starttiden för applikationen och även förbättra läsbarheten för koden (naturligtvis om den gemensamma modulen har ett helt meningsfullt namn);
- Det är inte tillrådligt att använda mer än en kompileringsflagga. Det finns inte så många metoder som behöver exekveras i olika sammanhang, och om sådana metoder fortfarande krävs kan en separat gemensam modul allokeras för dem;
- Flaggan "Call server" är meningsfull endast om modulen är kompilerad "På servern". Därför bör alla andra kompileringsflaggor tas bort för att undvika olika problem;
- om modulmetoderna involverar massiv databearbetning, läsning och skrivning till databasen, är det för att öka arbetshastigheten bättre att inaktivera åtkomstkontroll genom att ställa in flaggan "Privileged". Detta läge är endast tillgängligt för delade moduler kompilerade på servern.

Formulärmodul

• kan innehålla alla 3 områden
• exekveras på server- och klientsidan

Formulärmodulen är utformad för att bearbeta användaråtgärder med detta formulär (bearbeta en knappklickshändelse, ändra formulärdetaljer, etc.). Det finns också händelser som är direkt kopplade till själva formuläret (till exempel dess öppning eller stängning). Moduler av hanterade och vanliga formulär skiljer sig först och främst genom att modulen i en hanterad form är tydligt indelad i sammanhang. Varje procedur eller funktion måste ha ett kompileringsdirektiv. Om kompileringsdirektivet inte är specificerat, exekveras denna procedur eller funktion på serversidan. I sin normala form exekveras all kod på klientsidan.

Strukturen för ett hanterat formulär innehåller en sektion för deklarationer av variabler, beskrivningar av procedurer och funktioner och programmets huvudtext (exekveras vid tidpunkten för initieringen av formuläret). Vi kan komma åt standardformulärhändelser genom listan över förväntade procedurer och funktioner i formuläret (Ctrl+Alt+P), eller genom egenskapspaletten för själva formuläret.

Om ett formulär har ett huvudattribut tilldelat, blir egenskaperna och metoderna för applikationsobjektet som används som huvudattribut tillgängliga i formulärmodulen.

Objektmodul

• kan innehålla alla 3 områden
• körs på serversidan

Denna modul är tillgänglig för de flesta konfigurationsobjekt och är i allmänhet avsedd för att bearbeta händelser som är direkt relaterade till objektet. Till exempel händelser med inspelning och borttagning av objekt, kontroll av färdigställande av objektdetaljer, postning av ett dokument, etc.

Vissa objektmodulhändelser duplicerar formulärmodulhändelserna. Till exempel händelser kopplade till en inspelning. Det bör emellertid förstås att händelserna i formulärmodulen kommer att exekveras uteslutande i den specifika formen av objektet, det vill säga när det specifika formuläret öppnas. Och händelserna i objektmodulen kommer att anropas i alla fall, även i ögonblicket för programmatiskt arbete med objektet. Därför, om du behöver metoder associerade med ett objekt utan att vara bunden till en specifik form av objektet, är det bättre att använda objektmodulen för detta.

Objekthanterare modul

• kan innehålla alla 3 områden
• körs på serversidan

Objekthanteraren dök upp först från version 1C 8.2. Managermodulen finns för alla applikationsobjekt och är utformad för att hantera detta objekt som ett konfigurationsobjekt. Managermodulen låter dig utöka funktionaliteten för ett objekt genom att introducera (skriv)procedurer och funktioner som inte relaterar till en specifik instans av ett databasobjekt, utan till själva konfigurationsobjektet. Objekthanteraren låter dig placera vanliga procedurer och funktioner för ett givet objekt och komma åt dem utifrån, till exempel från bearbetning (naturligtvis om denna procedur eller funktion har nyckelordet Exportera). Vad för nytt ger detta oss? I allmänhet ingenting förutom att organisera procedurer efter objekt och lagra dem på separata platser - Objekthanterare-moduler. Vi kan lika framgångsrikt placera dessa procedurer och funktioner i allmänna moduler, men 1C rekommenderar att du placerar allmänna procedurer och funktioner för objekt i Object Manager-modulen. Exempel på användning av procedurerna och funktionerna i modulen Objekthanterare: initial ifyllning av individuella detaljer för en katalog eller ett dokument under vissa villkor, kontroll av att detaljerna i en katalog eller ett dokument under vissa villkor är ifyllda, etc.

Kommandomodul

• kan innehålla ett avsnitt som beskriver procedurer och funktioner
• exekveras på kundsidan

Kommandon är objekt som är underordnade applikationsobjekt eller konfigurationen som helhet. Varje kommando har en kommandomodul där en fördefinierad CommandProcess()-procedur kan beskrivas för att utföra det kommandot.

I nya versioner av 1C:Enterprise-systemkonfigurationer har många funktioner och procedurer flyttats från objektmoduler (dokument, kataloger, etc.) till managermoduler. Låt oss titta på skillnaderna mellan dessa två moduler.

Enligt teorin om objektorienterad programmering delas objektmetoder in i två grupper: statiska och enkla. Enkla metoder har bara tillgång till en specifik instans av en klass. Statiska metoder har inte tillgång till objektdata utan fungerar med klassen som helhet.

Om vi ​​översätter allt detta till termer av 1C:Enterprise-systemet, då Objektmodul innehåller enkla metoder. För att använda dem måste du först skaffa ett specifikt objekt: ett element i en katalog, ett dokument, etc. Managermodul innehåller statiska metoder. För att använda det behöver du inte skaffa varje specifikt objekt separat, det låter dig arbeta med hela samlingen på en gång.

Objektmodul kan ha rutiner och funktioner som kan användas externt. För detta ändamål betecknas en sådan procedur eller funktion med ordet Exportera.

Funktion NewFunction() Export

För att kunna använda en sådan funktion från en objektmodul måste du först ha en länk till det önskade objektet och skaffa det med funktionen GetObject().

Per = Objekt. NewFunction() ;

På samma sätt kan du skapa nya variabler som kan användas från olika konfigurationsobjekt.

Variabel NyVariabel Export

Katalogelement = Kataloger. Nomenklatur. FindByCode("000000001" );
Objekt = Katalogelement. GetObject() ;
Ett objekt. NewVariable= );

På så sätt kan du komplettera standardprocedurer, funktioner och egenskaper (variabler) för objekt. Sådana variabler är dynamiska, de sparas inte i infobasen och existerar endast när man arbetar med det mottagna objektet.

Managermodul har alla samma möjligheter, den enda skillnaden är att för att använda det behöver du inte skaffa ett specifikt objekt. Managermodulen låter dig arbeta med hela samlingen av objekt av en viss typ.

Procedur NewProcedure() Export

Katalogelement = Kataloger. Nomenklatur. NewProcedure();

Eller för en variabel:

Variabel NyVariabel Export

Katalogelement = Kataloger. Nomenklatur. nyVariabel;

Låt oss titta på skillnaderna i användningen av objektmodulen och managermodulen med hjälp av exemplet på proceduren för att skapa en utskriven form av ett dokument.

När du använder objektmodulen kommer koden att se ut så här:

Funktion Skriv ut dokument (länk) Exportera
//Du måste skicka en länk till ett specifikt dokument till den här funktionen
Returnera TabDoc;
EndFunction

På dokumentformuläret måste du skapa en procedur som skulle skicka en länk till dokumentet till utskriftsfunktionen.

&OnClient
Procedur Skriv ut (kommando)
TabDoc = PrintOnServer();
TabDoc. Show() ;
Slut på procedur
&På server
Funktion PrintOnServer()
Doc = FormAttributesValue("Objekt" ) ;
Returnera dok. PrintDocument(Object.Link) ;
EndFunction

Nackdelen med denna metod är att den bara skriver ut ett objekt. Om du behöver skriva ut flera dokument samtidigt, måste du hämta vart och ett av dem och sedan anropa funktionen från objektmodulen. Detta kräver betydande systemresurser eftersom när ett objekt hämtas placeras hela objektet i RAM.

Ur prestationssynpunkt är det mycket bättre att använda managermodulen när det är möjligt. I vårt exempel kommer lösningen på problemet att se ut så här.
Funktion PrintOnServer()
Returnera dokument. Vårt dokument. PrintDocument(ArrayLinks);
EndFunction

Om du använder managermodulen kan utskriftsproceduren anropas både från dokumentformuläret och från listformuläret, och skickar länkar till flera dokument i en array. I det här fallet behöver systemet inte hämta varje dokument från arrayen, vilket avsevärt sparar systemresurser.

Så när ska man använda en objektmodul och när ska man använda en managermodul?

Allt beror på uppgiften. Om en referens till ett objekt räcker för att slutföra det (till exempel en utskriftsuppgift), är det bättre att använda managermodulen. Om uppgiften är att ändra data, till exempel att fylla i ett dokument, måste du skaffa det och använda objektmodulen.