Adatátviteli objektum pedig kódstrukturáláshoz, felügyelt formában 1C 8.2 környezetben.

Bevezetés

Kezdjük a „menedzselt forma” fogalmának és az 1C platform kapcsolódó fogalmainak rövid leírásával. A platform szakértői kihagyhatják ezt a részt.

2008-ban vált elérhetővé egy új verzió 1C platform: Enterprise 8.2 (a továbbiakban: felügyelt alkalmazás), amely teljesen megváltoztatja a felülettel végzett munka teljes rétegét. Ez magában foglalja a parancsfelületet, az űrlapokat és az ablakrendszert. Ez nemcsak a felhasználói felület fejlesztési modelljét változtatja meg a konfigurációban, hanem egy új architektúrát is javasol az ügyfélalkalmazás és a szerver funkcionalitásának szétválasztására.
Egy felügyelt alkalmazás a következő típusú ügyfeleket támogatja:

• Vastag kliens (normál és felügyelt indítási mód)
• Vékony kliens
• Web kliens

A felügyelt alkalmazások ráépített űrlapokat használnak új technológia. Úgy hívják Kezelt űrlapok. Az átállás megkönnyítése érdekében a régebbi űrlapok (ún. normál űrlapok) is támogatottak, de ezek funkcionalitása nincs kifejlesztve, és csak a gazdag kliens indítási módban érhetők el.
A kezelt űrlapok főbb különbségei a fejlesztő számára:

• A szerkezet deklaratív, nem "pixelenkénti" leírása. Az elemek konkrét elhelyezését a rendszer automatikusan elvégzi az űrlap megjelenésekor.
• Az űrlap minden funkciója le van írva az űrlapon részletekés parancsokat. A részletek azok az adatok, amelyekkel az űrlap működik, a parancsok pedig a végrehajtott műveletek.
• Az űrlap a szerveren és a kliensen is végrehajtódik.
• A kliens kontextusában szinte minden alkalmazástípus nem elérhető, ennek megfelelően az infobázisban lévő adatok megváltoztatása lehetetlen.
• Minden metódushoz vagy űrlapváltozóhoz meg kell adni összeállítási irányelv A, amely megadja, hogy a végrehajtási hely (ügyfél vagy szerver) és az űrlap környezetéhez való hozzáférés.

Íme az űrlapmetódusok összeállítására vonatkozó utasítások:

• &AtClient
• &A szerveren
• &OnServerWithoutContext
• &A kliensnélA kiszolgálónálKontextus nélkül

Illusztráljuk a fentieket. A képernyőkép egy felügyelt űrlapra és annak moduljára mutat példát fejlesztési módban. Keressen kijelentő leírást, kellékeket, összeállítási utasításokat stb.

Minden további megbeszélés az illusztráció jobb oldaláról fog szólni, arról, hogyan kell felépíteni a modul kódját, és milyen elvek teszik lehetővé a hatékony kliens-szerver interakció megvalósítását.

Határozzuk meg a problémát

Több év telt el azóta, hogy az 1C platform új verzióját aktívan használják, és számos megoldást (konfigurációt) adott ki az 1C és számos partnere.
Kialakítottak-e a fejlesztők ezalatt az űrlapok létrehozásakor a kliens-szerver interakció elveinek közös felfogását, és változott-e a megvalósítás megközelítése? szoftver modulokúj építészeti valóságokban?

Tekintsük a kódszerkezetet (űrlapmodult) ugyanazon tipikus konfiguráció több formájában, és próbáljunk mintákat találni.
A struktúra alatt a fejlesztő által a metódusok csoportosítására és az ezen metódusok fordítására szolgáló direktívákra kiosztott kódrészeket (leggyakrabban megjegyzésblokkokat) értjük.
1. példa:
Eseménykezelő szekció Módszer - a kliensen Módszer - a szerveren Módszer - a kliensen Szervizeljárások és funkciók szekció Bemenetvezérlés segédfunkciók
2. példa:
Szolgáltatási eljárások és funkciók Fizetési bizonylatok Értékek Rendezvénykezelők
3. példa:
Szervizeljárások a szerveren Szervizeljárások a kliensen Szolgáltatási eljárások a szerveren kontextus nélkül Fejléc eseménykezelők Parancs eseménykezelők
4. példa:
Általános célú eljárások Űrlap-eseménykezelők A „kapcsolattartási adatok” alrendszer eljárásai
Valójában a kódstruktúra hiányzik, vagy enyhén szólva hasonló a 8.1-es űrlapokhoz:

• Nem tájékoztató jellegű szavak „Általános, Szerviz, Kisegítő”.
• Félénk kísérletek a kliens és a szerver metódusainak elkülönítésére.
• A módszereket gyakran interfész-elemek szerint csoportosítják: „Munka a táblázatos résszel Termékek, Elérhetőségek”.
• Metódusok és kódcsoportok tetszőleges elrendezése. Például az Eseménykezelők az egyik formában a tetején, a másikban alul lehetnek, a harmadikban egyáltalán nincsenek kiemelve, és így tovább.
• És ne felejtsük el, hogy ez mind ugyanazon a konfiguráción belül van.
• Igen, vannak olyan konfigurációk, amelyekben az „Általános, Szerviz, Kiegészítő” szavak mindig ugyanazokon a helyeken vannak, de ...

Miért van szükség kódszerkezetre?

• A karbantartás egyszerűsítése.
• A tanulás egyszerűsítése.
• Általános/fontos/sikeres alapelvek rögzítése.
• … a te lehetőséged

Miért nem segít az 1C meglévő fejlesztési szabványa?

Nézzük meg az ITS-lemezeken és a különféle „Fejlesztői útmutatókban…” közzétett alapelveket, amelyeket a kezelt űrlap írásakor javasolnak.

• Minimalizálja a szerverhívások számát.
• Maximális számítás a szerveren.
• A nem kontextusos szerverhívások gyorsabbak, mint a kontextushívások.
• Program az ügyfél-szerver interakciót szem előtt tartva.
• stb.

Ezek teljesen igazak szlogenek, de hogyan valósíthatók meg? Hogyan lehet minimalizálni a hívások számát, mit jelent kliens-szerver módban programozni?

Tervezési minták vagy generációs bölcsesség

A kliens-szerver interakciót évtizedek óta használják a különféle szoftvertechnológiákban. Az előző részben felvázolt kérdésekre a válasz régóta ismert, és két alapelvben foglalható össze.

• Távoli homlokzat(a továbbiakban: Távoli hozzáférési felület)
• Adatátviteli objektum(a továbbiakban: adatátviteli objektum)

Szó Martin Fowlernek, leírása ezekről az elvekről:

• … minden távoli hozzáférésre szánt objektumnak rendelkeznie kell alacsony részletességű interfész, amely minimálisra csökkenti az adott eljárás végrehajtásához szükséges hívások számát. … A számla és minden pontjának külön kérése helyett a számla minden pontját egy hívásban kell elolvasni és frissíteni. Ez kihat az objektum teljes szerkezetére...Ne feledje: a távoli elérési felületet nem tartalmaz tartomány logikát.
• ... ha gondoskodó anya lennék, biztosan azt mondanám a gyerekemnek: "Soha ne írj adatátviteli objektumokat!" A legtöbb esetben az adatmigrációs objektumok nem mások, mint dagadt mezőkészlet… Ennek az undorító szörnyetegnek az értéke kizárólag a lehetőségben rejlik több információ továbbítása a hálózaton keresztül egy hívásban- elosztott rendszerekben nagy jelentőségű technika.

Példák sablonokra az 1C platformon

A felügyelt űrlap fejlesztése során a fejlesztők rendelkezésére álló API számos példát tartalmaz ezekre az elvekre.
Például az OpenForm() metódus, egy tipikus "durva" felület.
OpenParameters = New Structure("Paraméter1, Paraméter2, Paraméter 3", Érték1, Érték2, Érték3); Form = OpenForm(FormName, OpenParameters);
Hasonlítsa össze a v8.1 stílussal.
Form = GetForm(FormName); Form.Parameter1 = Érték1; Form.Parameter2 = Érték2; Form.Open();

Felügyelt űrlappal összefüggésben az „Adatátviteli objektumok” halmaza. Meg lehet különböztetni szisztémásés fejlesztő által meghatározott.
A rendszeresek egy alkalmazásobjektumot modelleznek az ügyfélen, egy vagy több űrlapadat-elem formájában. Nem hozhatók létre az űrlap részleteihez való kötődésen kívül.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

Az adatátviteli rendszer objektumainak átalakítása alkalmazástípusokká és fordítva a következő módszerekkel történik:

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

Gyakran explicit konverziót használnak egy meglévő megoldás adaptálásakor. A metódusok olyan (szolgáltatási) bemeneti paramétereket várhatnak el, mint a ValueTable, nem pedig a FormDataCollection, vagy a metódust egy alkalmazásobjektum kontextusában határozták meg, és elérhetetlenné vált az űrlapról történő közvetlen híváshoz.
Példa 1C v8.1:
// az ügyfélen a FillUsersCache(DepartmentReference) űrlap kontextusában
Példa 1C v8.2:
// a szerveren a ProcessingObject = FormAttributeToValue("Object") űrlap kontextusában; ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");

Az adatmigrációs objektumok, amelyek szerkezetét a fejlesztő határozza meg, a kliensen és a kiszolgálón egyaránt elérhető típusok egy kis részhalmaza. Leggyakrabban a "durva" interfész módszereinek paramétereiként és eredményeiként a következőket használják:

• Primitív típusok (karakterlánc, szám, logikai érték)
• Szerkezet
• Megfelelőség
• sor
• Alkalmazásobjektumokra mutató hivatkozások (egyedi azonosító és szöveges megjelenítés)

Példa: a metódus elfogadja a megbízások listáját az állapot megváltoztatására, és visszaküldi a hibák leírását az ügyfélnek.
&OnServerWithoutContext függvény SzerverChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [megrendelés][hiba leírása] Minden rendelésből rendelésből Loop StartTransaction(); DocOb kísérlet = Order.GetObject(); …. egyéb műveletek, esetleg nem csak a megrendeléssel... Kivétel CancelTransaction(); Errors.Insert(Rend, DescriptionError()); A kísérlet vége; EndCycle; Visszaküldési hiba; EndFunction // ServerChangeOrderStatus()

A kód strukturálása

A fő célok, amelyeket a kezelt űrlap modulnak tükröznie kell, és a megoldás megközelítései.

• A kliens és a szerver kód egyértelmű elkülönítése. Ne felejtsük el, hogy a végrehajtás pillanatában ez két kölcsönhatásban lévő folyamat, amelyek mindegyikében jelentősen eltér az elérhető funkcionalitás.
• A távoli elérési felület egyértelmű kiválasztása, mely szerver metódusok hívhatók a kliensből, és melyek nem? A távoli interfész metódusainak neve a "Szerver" előtaggal kezdődik. Ez lehetővé teszi, hogy azonnal láthassa a vezérlés átmenetét a kiszolgálóra a kód olvasása során, és leegyszerűsíti a kontextuális tippek használatát. Ne feledje, hogy a hivatalos ajánlás (ITS) a postfixekkel ellátott elnevezési módszereket javasolja, például a ChangeOrderStatusOnServer(). Ismétlem, nem minden szervermetódus hívható meg a klienstől, így a logikai hozzáférhetőség fontosabb, mint a fordítás helye. Ezért a „Server” előtaggal csak a kliens számára elérhető metódusokat jelöljük meg, a példametódus neve ServerChangeOrderStatus().
• Olvashatóság.Ízlés dolga, akkor fogadjuk el a sorrendet, amikor a modul elkezdődik a szerveren lévő űrlapkészítési eljárásokkal és a távoli elérési módokkal.
• Karbantarthatóság. Az új kód hozzáadásának helyét egyértelműen meg kell határozni. Fontos pont, amelyeket a metóduscsonk konfigurátor automatikusan létrehoz, a modul végére kerülnek. Mivel az űrlapelem-eseménykezelők leggyakrabban automatikusan jönnek létre, a megfelelő blokk utoljára kerül elhelyezésre, hogy ne húzza át az egyes kezelőket a modul másik helyére.

Az alábbiakban a felsorolt ​​célokat megvalósító modul alapvető felépítése látható.

• Grafikus lehetőség - egyértelműen mutatja a végrehajtás fő folyamatát.
• A szöveges változat egy példa a sablon kialakítására gyors betét struktúrákat egy új űrlapmodulba.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Dátum=""/> // <Описание> // // ////////////////////////////////////////////////// ////////////////////////////// // MODUL VÁLTOZÓI //////////////// ////////////////////////////////////////////////// // ////////////// // A SZERVEREN //******* ESEMÉNYEK A SZERVEREN ******** &A kiszolgálón A kiszolgálón való létrehozási eljárás( Failure, StandardProcessing) //A kezelő tartalmának beillesztése EndProcedure //******* TÁVOLI HOZZÁFÉRÉSI INTERFÉSZ ****** //******** ÜZLETI LOGIKA A SZERVEREN **** *** /////////////////////////////////////////////// ///////////// ///////////////////// // KÖZÖS KLIENS ÉS SZERVER MÓDSZEREK ////////////////////////////////////////////////// //////////////// //////// // AZ ÜGYFÉLEN //******* ÜZLETI LOGIKA AZ ÜGYFÉLEN ******* //******* PARANCSOK ******* //******* ESEMÉNYEK AZ ÜGYFÉLEN ****** /////////////// ////////////////////////////////////////////////// ///////////////// / / FŐ PROGRAM ÜZEMELTETŐI

Kapcsolódó kérdések

Végezetül felvázolunk néhány olyan területet, amelyekre érdemes gondolni a kliens-szerver interakció programozásakor.

• A távelérési interfész megvalósításának lehetőségei. Aszinkron, részletesség...
• gyorsítótárazás. Az 1C szerencsétlen építészeti döntést hozott, a gyorsítótárazást csak a gyakori modulok hívási módszereinek szintjén vezette be, és nem biztosított vezérlési lehetőségeket (naprakész idő, igény szerinti visszaállítás).
• Implicit szerverhívások. Ne feledkezzünk meg a technológiai jellemzőkről, az ügyfél számos „ártalmatlan” művelete provokálja a platformot a szerver elérésére.

11.12.2016

A kezelt űrlapok 1C (kezdet)

Vékony kliens

Sehol nincs vékonyabb. Most a kliens alkalmazás nem kérdezi le az adatbázist (ez a szerver dolga). Az ügyfélalkalmazás egyszerűen megjeleníti a felületet és az adatokat.

Érdemes megjegyezni, hogy az ilyen átalakítások miatt a kódstruktúra bonyolultabbá vált. A kliensen nincsenek hivatkozások, objektumok, értéktáblázat... csak primitív típusok érhetők el (karakterlánc, dátum, logikai érték, tömb, szerkezet...). Ez azt jelenti, hogy a programozónak most el kell gondolkodnia azon, hogy mit vegyen fel a szerverre, és hogyan tegye azt minimális költséggel.

Kliens-szerver interakció

A kliens és a szerver közötti interakció új megközelítése lehetővé tette a felhasználói felület új modelljének létrehozását. Most a felület deklarált(!) Az interfész tervezése adatokkal kezdődik, részletekkel és táblázatos részekkel. Egy kellék készítésénél át kell gondolni, hogyan fog kinézni a felületen, lesz-e rá igény, hogyan kapcsolódik más kellékekhez...

Nincs kontextus (állapot) a szerveren

Az 1C szerver a "stateles" (angol állapot nélküli) elvén működik. Ez azt jelenti, hogy a szerver csak a kérésekre válaszol, ugyanakkor nem tárol semmit két kérés között (erre van ideiglenes tárhely).

FormDataToValue,FormDataCollection,FormData...

A szerverhez fordultunk, mindent megtett helyettünk, törölte az adatokat és elfelejtette, hogy jöttünk. Minden "FormData" + "valami ott" nevű objektum segít abban, hogy két szerverhívás között elmentsük adatainkat.

Átmeneti tároló

Az ideiglenes tárhely egy speciális hely, ahol (az űrlap adatain kívül) állapot menthető a szerveren. A tároló olyan adatokat tárolhat, amelyek nem állnak rendelkezésre a kliensen (azaz nem helyezhetők el az űrlap részleteiben).

Az ideiglenes tároláshoz használja a MoveToTempStorage() metódusokat Szintaxis: PlaceToTempStorage(<Данные>, <Адрес>) Leírás: Egy sorozható értéket tárol az ideiglenes tárolóban. Elérhetőség: Vékony kliens, webkliens, szerver, vastag kliens, külső kapcsolat, mobil alkalmazás (kliens), mobil alkalmazás (szerver). A metódushívás hívást kezdeményez a szerver felé.<Адрес>(nem kötelező) Típus: UniqueIdentifier; Vonal. Annak az űrlapnak az egyedi azonosítója, amelynek ideiglenes tárolójába az adatokat el kell helyezni és az új címet vissza kell küldeni. Vagy az ideiglenes tárolóban lévő cím, ahol az adatokat el kell helyezni. A címet korábban meg kell szerezni ezzel a módszerrel. Ha egy űrlap egyedi azonosítót vagy egy tárhelyen lévő címet adnak át, akkor az érték az űrlap bezárása után automatikusan törlődik. Ha olyan UniqueIdentifier kerül átadásra, amely nem egyedi azonosítója az űrlapnak, akkor az érték törlődik, amikor a felhasználó munkamenete véget ér. Ha a paraméter nincs megadva, az elhelyezett érték törlődik a következő kiszolgálókérés után a megosztott modulból, kontextusos és nem kontextusos szerverhívásoknál az űrlapból, szerverhívásoknál a parancsmodulból, vagy az űrlap lekérésekor. Megjegyzés: Az egyik munkamenetben létrehozott ideiglenes tárhely nem érhető el egy másik munkamenetből. Kivételt képez az a lehetőség, hogy átmeneti tárhely használatával adatokat vihetünk át egy háttérfeladatból a háttérfeladatot kezdeményező munkamenetbe. Az ilyen átvitelhez a szülő munkamenetben helyezzen el egy üres értéket az ideiglenes tárolóba, átadva az űrlapazonosítót. Ezután adja át a kapott címet a háttérfeladatnak a háttérfeladat paraméterein keresztül. Továbbá, ha ez a cím szerepel a paraméterben<Адрес>, az eredményt a rendszer arra a munkamenetre másolja, amelyből a háttérfeladat elindult. A háttérfeladatban az ideiglenes tárhelyen elhelyezett adatok nem lesznek elérhetők a szülő munkamenettől kezdve, amíg a háttérfeladat be nem fejeződik. és GetFromTempStorage() szintaxis: GetFromTempStorage(<Адрес>) Leírás: Értéket kap az ideiglenes tárolóból. Elérhetőség: Vékony kliens, webkliens, szerver, vastag kliens, külső kapcsolat, mobil alkalmazás (kliens), mobil alkalmazás (szerver). A metódushívás hívást kezdeményez a szerver felé. Megjegyzés: A végrehajtás eredménye nem kerül gyorsítótárba, a kiszolgáló minden alkalommal meghívásra kerül a metódus meghívásakor.

Szerverkód hívása

A kiszolgáló kódjának bármely hívása mindig sorba rendezi a továbbított adatokat. Az összes paramétert egy karakterláncba csomagolják, és a hálózaton keresztül továbbítják. A munka eredménye szerializált formában is visszakerül, majd visszakerül az ismerős tárgyakká.

Moduljelzők hozzárendelése

• A zászló jelzi, hogy a modulkód hol lesz lefordítva (szerveren, kliensen, külső kapcsolaton)
• Ha egy modult több helyen fordítanak le, akkor csak a jelzőtáblák szerint lesz látható
• A kódvégrehajtás átvitele csak akkor lehetséges, ha az aktuális végrehajtási kontextusban nincs hívott modul, de máshol létezik (ha a modul csak a szerveren létezik, a kliensen nem, akkor a szerver hívódik meg)

Szerverhívás zászló

Az 1C:Enterprise 8.2 platformtól kezdve a "szerverhívás" jelző hozzáadásra került. Ami csak segít "megoldani" a másik gépre való átállás feltételeit. Ha ez a jelző van hozzárendelve a modulhoz, akkor a modul látható lesz a klienstől, ha nem, akkor a kliens hívási kísérlete hibát eredményez. A modul kódja nem lesz látható, mintha nem is létezne.

Így egy normál vastag kliensben csak akkor tudja átvinni a kódot a szerverre, ha meghív egy közös modult a klienstől, amelyhez:

• Szerver jelölőnégyzet bejelölve
• A "Szerver hívása" jelölőnégyzet be van jelölve
• Az összes "kliens" jelölőnégyzet eltávolítva

Az 1C Enterprise 8.2 platform megjelenésével a felhasználói felület fejlesztési mechanizmusa jelentősen megváltozott. Most már létrehozhat felügyelt űrlapokat és alkalmazásokat (1. ábra).

1. kép

Ezenkívül egy új rendszert javasolnak az ügyfélalkalmazás és a szerver közötti funkcionalitás elválasztására.
A felügyelt alkalmazás a következő típusú ügyfeleket támogatja:

• Vastag kliens (normál és felügyelt indítási mód),
• vékony kliens,
• Web kliens.

A kezelt űrlapok létrehozásának mechanizmusa jelentősen eltér a hagyományos űrlapoktól. Először is a kezelt űrlapok abban különböznek egymástól, hogy speciális beállítások alapján a rendszer automatikusan létrehozza őket, így a programozónak nem kell minden űrlapot részletesen megrajzolnia. Az űrlap összes funkciója részletek és parancsok formájában van leírva. A részletek azok az adatok, amelyekkel az űrlap működik, a parancsok pedig a végrehajtott műveletek. Minden metódushoz vagy űrlapváltozóhoz meg kell adni egy fordítási direktívát, amely meghatározza a végrehajtás helyét (kliens vagy szerver). A fordítási direktívák a következők lehetnek:

• &AtClient,
• &A szerveren,
• &OnServerWithoutContext,
• &A kliensnélA kiszolgálónálKontextus nélkül.

A kezelt űrlap abban is különbözik a normál űrlaptól, hogy milyen adattípusokkal dolgozik. Ha egy normál űrlap az 1C:Enterprise által biztosított legtöbb típussal működik (beleértve a DirectoryObject, DocumentObject stb. típusokat), akkor a kezelt formában a következő típuskategóriák különböztethetők meg:

• Az űrlapon közvetlenül használt típusok azok, amelyek a vékony és webes kliens oldalán léteznek (például Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
• a speciális adattípusokká konvertált típusok kezelt űrlap adattípusok. Az ilyen típusok az űrlapattribútumok listájában jelennek meg zárójelben, például (CatalogObject.Products);
• dinamikus lista.

A kezelt űrlapok működése a következő sajátosságokkal rendelkezik (2. ábra):

• Az űrlap a kliensen és a szerveren is létezik.

Kliens-szerver interakciót végez (adatátvitel, elemek tervezési tulajdonságai).

• Az űrlap nem működik alkalmazásobjektumokkal

2. ábra

Az űrlap speciális általános objektumokat használ
DataForms(3. ábra).


3. ábra

Az alkalmazásobjektumok csak a szerveren és csak bizonyos műveletek során működnek.
Űrlap megnyitásakor:

• Az objektum beolvasásra kerül az adatbázisból,
• Az objektum alakadatokká alakul,
• Az objektum eltávolításra kerül (a memóriából),
• Az űrlap adatait átadják az ügyfélnek.

Felvételkor:

• Az űrlapadatokat az ügyféltől kapják,
• Az űrlapadatok objektummá konvertálódnak,
• Az objektum be van írva az adatbázisba,
• Az objektum eltávolításra kerül (a memóriából).

Az utolsó leckében rendszeres (kövér) ügyfélre gondoltunk. Az 1C 8.2 platformverzióban. Új képernyőformákat használnak, 1C 8.2. Ezeket kezelt űrlapoknak nevezik 1C 8.2.

Felügyelt űrlapok Az 1C 8.2 az 1C jövője. Abban különböznek a közönséges 1C 8.2 űrlapoktól, hogy a rendszer automatikusan generálja őket speciális beállítások alapján (a „szokásos” űrlapokat a programozó egyszerűen megrajzolja tetszés szerint).

Az 1C 8.2 kezelt formák fejlettségi különbségei jelentősek a megszokottól. Ezért ma összegyűltünk, hogy külön megvitassuk a kezelt űrlapok 1C 8.2 létrehozását és módosítását.

Kezelt űrlapok 1C 8.2

Ha korábban fejlesztett 1C konfigurációkat, az 1C 8.2 felügyelt űrlapszerkesztő megnyitásakor azonnal megzavarodik, hogy az 1C 8.2 űrlapot egyáltalán nem lehet egérrel befolyásolni.

Az 1C 8.2 űrlapot nem módosíthatja, az elemet nem mozgathatja, még a mező tulajdonságait sem tekintheti meg, mint korábban - az 1C 8.2 űrlapon a mezőre duplán kattintva.

Most az 1C 8.2 űrlap fejlesztésének alapja nem a mezők koordinátáihoz kötése az űrlapon, hanem a speciális beállítások. A rendszer ezen beállítások alapján automatikusan létrehoz egy 1C 8.2 kezelt űrlapot.

A beállítások a szerkesztőben a bal felső sarokban található 1C 8.2 űrlapelemek listájából állnak. Az 1C 8.2 űrlap elemei a következők:

• Kellékek
• Parancsok (új koncepció, 1C 8.2, gomboknak vagy menüelemeknek tűnhetnek)
• Csoportok (részletek és parancsok kombinálásához).

Ennek megfelelően ezeknek az elemeknek a beállításai nem a mezők tulajdonságaiban vannak, hanem ezen beállítási elemek tulajdonságaiban (jobb gombos menü, Tulajdonságok pont).

Az 1C 8.2 kezelt űrlapok működése

Az 1C 8.2 kezelt űrlapokkal való munkavégzés a felhasználó számára eltérő. Több funkcióval rendelkeznek, de szokatlanok azok számára, akik régóta dolgoznak az 1C-vel.

Először is, a szokásos elemek elhelyezkedése az 1C 8.2 űrlapon eltér. A parancssor mindig felül van.

A parancssor bal oldala testreszabható. Általában olyan tipikus gombokat tartalmaz, mint a Record és a Post.

A parancspanel jobb oldalán található az 1C űrlap Minden művelet új standard menüje. Ez a menü lehetővé teszi az 1C 8.2 űrlap tetszőleges kezelését, hasonlóan ahhoz, ahogy az ACS jelentés beállításai lehetővé teszik a jelentés megjelenésének jelentős megváltoztatását.

Tetszőleges menüpontok 1C Minden művelet

Attól függően, hogy ez az 1C 8.1 űrlap egyikhez vagy másikhoz tartozik-e, a menü tele van olyan elemekkel, amelyek lehetővé teszik az objektum kezelését. Például, ha ez egy címtárlista űrlap, akkor olyan parancsok lesznek, mint a Create vagy Edit.

Elem Menülista testreszabása 1C Minden művelet

Ha van lista az 1C 8.2 űrlapon, akkor a menüben szerepel a Lista beállítása és a Lista megjelenítése parancs.
Ha az Output List parancs már ismerős az Ön számára - lehetővé teszi bármely lista 1C-ben történő mentését az Excelben / kinyomtatását, akkor a második parancs új.

Ahogy már észrevette, a listák parancssorában nincs több választógomb. Ehelyett megjelent a Keresés gomb, amelyre a munkára (valamint a kurzor immár letiltott elhelyezésére a listában gépeléskor) van panasz.

A Keresés gomb funkcionalitása természetesen össze sem hasonlítható a kijelölésekkel, de nem tűntek el sehol!
Most a Lista testreszabása menüpont alatt találhatók. A kijelölés mostantól tetszőleges mező szerint elvégezhető, ezen kívül a rendezés és a feltételes formázás ugyanúgy elvégezhető, mint az SKD jelentésekben.

Elem Menüforma módosítása 1C Minden művelet

Az Űrlap módosítása elem lehetővé teszi nemcsak az 1C 8.2 űrlapon lévő lista módosítását, hanem magát az 1C 8.2 űrlapot is.

A felhasználó önállóan engedélyezheti vagy letilthatja a mezők láthatóságát az 1C 8.2 űrlapon, szélességét és magasságát, az alapértelmezett mező aktiválását nyitáskor stb.

Az 1C 8.2 kezelt űrlapok és az 1C hagyományos űrlapok használata

Alapértelmezés szerint a rendszer a normál 1C-űrlapokat használja a vastag (szokásos) 1C-kliensek konfigurációiban, a felügyelt űrlapokat pedig a vékony és webes 1C-kliensek konfigurációiban. Az 1C mindkét formája azonban bármilyen konfigurációban használható, akár egyidejűleg is.

Ehhez a konfigurációs tulajdonságokat is meg kell adni (a konfigurációs ablak legfelső eleme).

Az 1C 8.2 konfigurációs tulajdonságaiban két új jelölőnégyzet jelent meg, amelyek lehetővé teszik az 1C űrlapok nem szabványos használatát.

Kezelt űrlapok létrehozása 8.2

Új 1C 8.2 űrlap hozzáadása ugyanúgy történik, mint korábban - a billentyűzet Ins gombjával vagy a Hozzáadás gombbal. Meglévő beírásához kattintson rá duplán az egérrel.

Alapértelmezés szerint a konfigurációban beállított űrlap (normál vagy felügyelt) jön létre (lásd a Fő indítási mód tulajdonságot a konfigurációs tulajdonságokban).

A konstruktor felkéri, hogy válassza ki az űrlap típusát - egy elem formáját, egy listát. Itt adhat hozzá vagy távolíthat el parancssorokat az űrlapon. Leggyakrabban ezek a beállítások alapértelmezés szerint változatlanok maradnak.

Megnyílik egy alapértelmezés szerint kitöltött űrlap - az 1C objektum hozzá adott összes részlete. A konstruktor második lapján kipipálhatja a kötelező mezők meghatározott listáját.

Az űrlapszerkesztő három részből áll.

• A bal felső sarokban az űrlapelemek listája található. Mezőkből, parancsokból és csoportokból áll, amelyek lehetővé teszik az elemek kombinálását. A parancsok listája külön is megtekinthető a Parancsfelület fülön.
• A jobb felső sarokban található az elérhető űrlapattribútumok és objektum attribútumok listája (nyissa ki az Object attribútum melletti keresztet).
• Az alábbiakban a kapott űrlap előnézete látható.

A rendelkezésre álló részleteket balra húzva űrlapelemmé (az űrlapon lévő mezővé) válik.

Ha hozzá kell adni egy gombot vagy menüelemet - a Parancsok lap jobb oldalán, létre kell hoznia egy új parancsot. Ez egy űrlap modulban lévő függvény burkolója. Amellett, hogy megadja, hogy melyik függvény hívja meg ténylegesen, hozzárendelhet egy reprezentációt - például egy képet, valamint a láthatóság függését egy funkcionális opciótól.

A parancsok is balra húzódnak. Ha a szülő egy parancssor, akkor az egy parancssor gomb lesz - egyébként csak egy gomb.

Az űrlapelemek (mezők) listájában nem csak húzhatja az objektum/űrlap attribútumait, hanem egyszerűen hozzáadhatja (Hozzáadás vagy Beillesztés gomb). Különösen létrehozhat egy új űrlapobjektumot - egy csoportot.

A csoport lehet parancspanel (a kurzornak az Űrlap sorban kell lennie). Aztán behúzod a parancsokat, és gombokká válnak.

A csoport lehet "rendszeres". Így a mezőket függőlegesen és vízszintesen is csoportosíthatja. A csoport neve a tulajdonságokban eltávolítható.

A csoport lehet panel (oldalak). A legfelső hozzáadott csoport egy panel, az ilyen típusú beágyazott csoportok pedig oldalak. A mezőket már húzzák az oldalakra.

A felesleges űrlapelemek eltávolítása az űrlapelemek listából való törlésével történik.
A mező pozícióját az űrlapon az elemlistában lévő sorrend (függőleges) vagy csoportok (vízszintes) határozza meg. A szélesség és magasság az űrlapelem tulajdonságaiban van beállítva.

Az űrlapelemek tulajdonságai nagymértékben kibővültek, és sok hasznos dolgot tartalmaznak – mind a megjelenés szabályozását (választó és törlés gombok), mind az alapértelmezett értékek ellenőrzését.

Magának az űrlapnak a tulajdonságait, beleértve a méreteit is, a Form azonos nevű űrlap gyökérelemében kell megadni.

Az eseménykezelőket (a felhasználói műveletekre adott válaszokat) most két típusra osztják. Régiek - mint korábban, az űrlap és a mezők tulajdonságaiban vannak megadva (például OnChange és OnOpening az űrlap). Új - parancsokká váltak, és menüelemekhez és gombokhoz használatosak.

A 8.2-es platformverziótól kezdve az 1C új elveket kezdett alkalmazni az interfész felépítésére és az adatbázissal való felhasználói interakcióra. Az új technológia neve Managed Application. Az űrlapok létrehozásának mechanizmusai és az 1C szerver felhasználója és az adatbázis közötti interakciós séma a legnagyobb feldolgozáson ment keresztül. A platform továbbra is támogatja a normál módot, de idővel az 1C összes felhasználója át fog váltani a kezelt űrlapokra.

A hétköznapi felhasználók számára az 1C dokumentum kezelt formája csak megjelenésében különbözik a szokásostól. A fejlesztő számára ez egy új mechanizmus saját szabályokkal, törvényekkel és feltételekkel. Számos területen történt változás, de a tapasztalt 1C fejlesztők körében a következő újítások kulcsfontosságúak:

• Az űrlapszerkezet és a mezők elhelyezésének független kialakítása a platform által. Ha korábban a fejlesztők pixelek megadásával írták le a mező helyzetét, most már csak a csoportosítás típusát lehet megadni;
• Az űrlap az űrlapadatokat reprezentáló attribútumokból és parancsokból - végrehajtott eljárásokból és függvényekből áll;
• Az űrlapkód a szerver és a kliens oldalon is lefut. Hiszen maga az űrlap egy konfigurációs objektum, amelyet a szerveren hoztak létre és a kliensen jelennek meg. Ez azt jelenti, hogy egyesíti a kliens és a szerver részeket;
• Kliens oldalon sokféle adat elérhetetlenné vált, és most már nincs mód az információs bázis adatainak megváltoztatására;
• Minden eljáráshoz vagy funkcióhoz meg kell adni egy speciális beállítást - egy fordítási direktívát. Felelős a kód végrehajtási helyéért, és a következő értékeket veheti fel:
  • az ügyfélen;
  • A szerveren;
  • On ServerWithoutContext;
  • OnClientOnServer;
  • Kliensen A Szerveren Kontextus nélkül.

Az utolsó pont különösen éles a kezelt formák módjában. Ha egy fejlesztő nem ismeri jól az utasításokat vagy a kliens-szerver interakciót, akkor rendkívül nehéz lesz felügyelt űrlapot létrehoznia. Az 1C:Enterprise 8.3-ban a felügyelt űrlapok létrehozására vonatkozó összes új elvet egyesíti a háromszintű architektúra általános koncepciója. Tartalmaz ügyfélszámítógépeket, 1C szervert és egy DBMS-t, ahol az adatok tárolódnak.

Más lett a felügyelt űrlap szerkesztése a konfigurátorban is. Sok szempont megváltozott, és a 7.7-es verzió fejlesztői, ahol nem voltak felügyelt űrlapok, meglepődhetnek. Még az űrlaptervező megjelenése is megváltozott, ami a konfigurációs objektum bármelyik űrlapjának megnyitásával látható. Egy objektum megnyitásakor egy több részre osztott ablakot látunk:

1. Űrlap felület elemei. A bal felső sarokban található egy ablak, amely felsorolja a kiválasztott űrlapon megjelenő összes mezőt, amely biztosítja a program interakcióját a felhasználóval;
2. Űrlap részletei. A jobb felső sarokban látható az összes adat, amellyel az űrlap működik. Ezekben tárolódnak az információk a kliens oldalon;
3. Kezelt űrlap megjelenítése. Alább láthatjuk a megjelenés előnézetét a felület elemei alapján;
4. Űrlap modul. Egy szakasz, amely az űrlap által használt eljárásokat és függvényeket tartalmazza. Itt megtalálhatja a programnak a felhasználóval és az adatbázissal való interakciójához szükséges algoritmusok kódját.

Az 1C fejlesztői arra agitálják az ügyfeleket, hogy váltsanak a felügyelt űrlapokra, így a felügyelt űrlapok fejlesztési elveinek elsajátítása idő kérdése. Ha elkezd dolgozni az ilyen típusú űrlapokkal, meg fogja érteni, hogy ez egy lépés a fejlesztés szabványosítása és az egységes szabályok betartása felé. Ezért az 1C 8.3-ban a felügyelt űrlapokkal való munkaképesség növeli az 1C fejlesztői szintjét.

Útmutató a kezelt űrlapok tervezéséhez

Először is, az 1C felügyelt mód mechanizmusának megértéséhez ne feledje, hogy az űrlap a szerveren és az ügyfélen is létezik. Ezenkívül a kliensen ez az objektum csak a programmal való felhasználói interakciós felület képe. Minden számítás, algoritmus, számítás és feldolgozás csak a szerver oldalon történhet. Ezt nem csak az a tény diktálja, hogy a kliens számos funkcióját és paraméterét nem tudja használni, hanem a teljesítményigény is.

A direktíva nevével kitalálható, hogy hol hajtják végre az eljárást, amelyet az űrlapmodulban minden egyes eljárás és funkció elé kell írni. A "Környezetkörnyezet nélkül" felirat azt jelzi, hogy a kezelt űrlapon lévő adatok nem kerülnek átadásra a szerveren lévő eljáráshoz. Így az ilyen eljárásokban nem lehet algoritmusokat írni a felhasználó által beírt értékek alapján. Ha ez a megfogalmazás nincs megadva, akkor az űrlapot teljes egészében továbbítják az összes részlettel, és Ön hozzáférhet.

Az 1C fejlesztői határozottan javasolják a nem kontextusos szerverhívások használatát, amennyire csak lehetséges, csökkentsék a számukat, és igyekezzenek nem végezni számításokat az ügyfélen. A kezdő fejlesztőknek elméleti háttér nélkül nehéz betartani ezeket a szabályokat és helyesen megváltoztatni a kódot. Mielőtt elkezdené az önálló munkát, hasznos lesz megnyitni egy felügyelt konfigurációs űrlapot, megnézni a szintaxist, valamint az ügyfél és a szerver interakcióját.

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

Az 1C űrlapok fejlesztésére vonatkozó új szabályok nagy előnyökkel járnak, ha minden fejlesztő betartja azokat. Sőt, mindenki jobbra fogja érezni a változásokat - mind a programozók, mind az 1C-ben dolgozó cégek, mind a franchise-vevők, mind az 1C-fejlesztők. A kezelt űrlapok helyes működésének fő következményei az 1C-ben:

1. Könnyű konfiguráció karbantartás és jobb kód olvashatóság. Ebből azt a következtetést vonhatjuk le, hogy az egyik fejlesztő által írt algoritmust egy másik alkalmazott mindig korrigálni tudja anélkül, hogy sok időt ráfordítana;
2. A kliensen és a szerveren futó kód szétválasztása. Tekintettel arra, hogy az egyes oldalakon elérhető funkciók mennyire eltérőek, ezek szétválasztása lenne a megfelelő lépés;
3. A fejlesztők mélyebben ismerik a platform logikáját, a kliens-szerver interakciókat és az általuk írt algoritmusokat. A 8.0-s és korábbi verziókban nagyon gyakori volt, hogy olyan dokumentumokat vagy könyvtárakat találtak, amelyeket anélkül fejlesztettek ki, hogy megértették volna a kliens-szerver részt;
4. A konfigurációk sebességének növelése és az ügyfélszámítógépek terhelésének csökkentése;
5. A munkahelyi számítógépek beszerzési költségeinek csökkentése, mivel nincs szükség nagy teljesítményű PC-k vásárlására.

A kezelt űrlap kiválasztása az 1C fő indítási módjaként sok meglepetést hozhat. De a megfelelő megközelítéssel ez a lépés nagy haszonnal jár, így Oroszország-szerte egyre több 1C-felhasználó dönt mellette. Figyelembe véve azt a tényt, hogy az 1C vállalat a jövőben a kezelt űrlapok fejlesztésével számol, kockázatos maradni az elavult hagyományos űrlapokon.