Az űrlap alapvető részletei. Felügyelt űrlap részletei (1Cv8) Az 1c felügyelt űrlapok programozottan adják hozzá a részleteket

Űrlap részletei

Az űrlaprészletek halmaza leírja az űrlapon megjelenített, szerkesztett vagy tárolt adatok összetételét. Ugyanakkor maguk az űrlap részletei nem teszik lehetővé az adatok megjelenítését és szerkesztését. Az űrlap részleteivel társított űrlapelemek (lásd e fejezet „Űrlapelemek” című részét) megjelenítésre és szerkesztésre szolgálnak. Az összes űrlaprészletet űrlapadatoknak nevezzük.

Fontos! Nem szabad megfeledkezni arról, hogy a normál űrlapokkal ellentétben a kezelt formában lévő összes adatot részletek formájában kell leírni. Az űrlapelemek adatforrásaként nem használhatók űrlapmodul-változók.

Lehetőség van hozzárendelésre Alapvető űrlaprészletek, azaz olyan attribútumok, amelyek meghatározzák az űrlap szabványos funkcionalitását (űrlapkiterjesztés). Nem szabad elfelejteni, hogy egy űrlapnak csak egy fő attribútuma lehet.

Űrlapkiterjesztés– ezek a ManagedForm objektum további tulajdonságai, metódusai és űrlapparaméterei, amelyek az űrlap fő elemét képező objektumra jellemzőek.

Az űrlapfejlesztési folyamat során kifejezetten beállíthatja, hogy a Nézet és Szerkesztés tulajdonságok segítségével megtekinthesse és szerkeszthesse az űrlap egyes részleteit a szerepek tekintetében (további részletekért lásd a Szerkesztők „Szerepkör alapú űrlapbeállítások” című részét. ” fejezet). Ezenkívül egy adott attribútum elérhetősége magában az űrlapon funkcionális opciókkal konfigurálható (a funkcionális opciókról további részletek a „Konfigurációs felületkezelés” fejezetben találhatók).

Form attribútum tulajdonság Mentett adatok annak a jele, hogy a részletek interaktív megváltoztatása az űrlapadatok szerkesztési blokkolására, valamint az űrlapmódosítás jelzőjének automatikus beállításához vezet.

Kezelt formában elérhető adattípusok

A kezelt űrlap abban is különbözik a normál űrlaptól, hogy milyen adattípusokkal dolgozik. Ha a 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ákat lehet megkülönböztetni:

  • 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, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • típusok, amelyek speciális adattípusokká lesznek átalakítva – felügyelt űrlap adattípusok. Az ilyen típusok az űrlaprészletek listájában jelennek meg zárójelben, például (DirectoryObject.Products);
  • dinamikus lista (további részletekért lásd e fejezet „Dinamikus lista” című részét).

Alkalmazásobjektumok átalakítása űrlapadatokká

Egyes alkalmazástípusok (például DirectoryObject stb.) nem léteznek vékony és webes kliens oldalon (további részletekért lásd a Felügyelt alkalmazás koncepcióját). Ezért az ilyen alkalmazástípusok űrlapon való megjelenítéséhez a platform speciális adattípusokat vezetett be, amelyeket a kezelt űrlapokon való használatra terveztek. A felügyelt alkalmazások ezen funkciója szükségessé teszi az alkalmazásobjektumok adatformátummá alakítását (és fordítva).

A következő adattípusok használatosak:

  • Form DataStructure – tetszőleges típusú tulajdonságok halmazát tartalmazza. A tulajdonságok lehetnek más struktúrák, gyűjtemények vagy gyűjteményekkel rendelkező struktúrák. Ezt a típust például DirectoryObject formában ábrázoljuk.
  • A FormDataCollection beírt értékek listája, hasonlóan egy tömbhöz. A gyűjtemény elemei index vagy azonosító segítségével érhetők el. Előfordulhat, hogy bizonyos esetekben nem érhető el azonosítóval történő hozzáférés. Ez a gyűjtemény által képviselt alkalmazásobjektum típusának köszönhető. Az azonosító bármilyen egész szám lehet. Ezt a típust például táblázatos rész formájában ábrázoljuk.
  • A Form DataStructureWithCollection egy olyan objektum, amely egyszerre jelenik meg struktúraként és gyűjteményként. Úgy kezelhető, mint ezen entitások bármelyike. Ez a típus például egy űrlapon lévő rekordok halmazát jelöli.
  • Form DataTree – hierarchikus adatok tárolására tervezett objektum.

Egy alkalmazásobjektumot egy vagy több űrlapadat-elem képvisel. Általánosságban elmondható, hogy az űrlapadatok hierarchiája és összetétele a kezelt űrlap alkalmazásobjektumainak összetettségétől és összekapcsolódásától függ.

Például egy táblázatos részt tartalmazó dokumentumot egy FormDataStructure típusú objektum (maga a dokumentum) ábrázol, amelynek egy FormDataCollection típusú objektum (a dokumentum táblázatos része) van alárendelve.

Fontos! Konfiguráció kidolgozásakor fontos megjegyezni, hogy az alkalmazásobjektumok csak a szerveren érhetők el, míg az űrlapadat-objektumok a szerveren és a kliensen is használhatók.

Adattovábbítás a kezelt űrlap kliens és szerver részei között

Valójában azt mondhatjuk, hogy az űrlapadatok a különböző alkalmazásobjektumokból származó adatok egységes reprezentációja, amelyekkel az űrlap egységesen működik, és amelyek mind a szerveren, mind a kliensen jelen vannak. Ez azt jelenti, hogy az űrlap saját adattípusok formájában tartalmazza az alkalmazásobjektum adatok valamilyen „kivetítését”, és szükség esetén konverziót hajt végre közöttük. Ha azonban a konfigurációfejlesztő saját adatfeldolgozási algoritmust valósít meg, akkor az adatkonverziót (specializált típusokból alkalmazástípusokba és fordítva) önállóan kell végrehajtania.

Űrlapadatok speciális szerkesztőben történő szerkesztése során (további részletekért lásd a "Szerkesztők" fejezet "Űrlap részletei" című részét) lehetőség van az adatátvitel befolyásolására a kliens és a szerver között az űrlap futása közben. Ehhez a részletszerkesztő oszlopa szolgál. Mindig használd. Ennek a tulajdonságnak a hatása háromféle attribútum esetében különbözik:

  • Egy dinamikus listának (dinamikus listaoszlop) alárendelt attribútum esetén:
    • tulajdonság engedélyezve – az attribútum mindig beolvasásra kerül az adatbázisból és szerepel az űrlapadatokban;
    • tulajdonság le van tiltva - az attribútum beolvasása az adatbázisból és csak akkor kerül be az űrlapadatok közé, ha az attribútumhoz vagy annak alárendelt attribútumához van egy pillanatnyilag látható űrlapelem.
  • A tételgyűjtemény alá tartozó kellékekhez:
    • tulajdonság engedélyezve van – a dokumentummozgások kiolvashatók az adatbázisból, és jelen lesznek az űrlapadatokban;
    • tulajdonság le van tiltva - a dokumentummozgások nem kerülnek kiolvasásra az adatbázisból, és nem szerepelnek az űrlapadatokban (ha nincs dokumentummozgatásokra hivatkozó űrlapelem).
  • Egyéb űrlapadatok:
    • tulajdonság engedélyezve van – az attribútum jelen lesz az űrlapadatokban, függetlenül attól, hogy van-e legalább egy űrlapelem, amely az attribútumhoz vagy annak alárendelt attribútumához van társítva;
    • tulajdonság le van tiltva - az attribútum csak akkor lesz jelen az űrlapadatokban, ha az attribútumhoz vagy annak alárendelt attribútumához van egy űrlapelem társítva. A dinamikus listaattribútumokkal ellentétben itt nem számít az attribútumhoz társított elem láthatósága.

Jegyzet. Ne feledje, hogy a szülőattribútumban beállított tulajdonság minden alárendelt attribútumra hatással van. Például, ha a Használat tulajdonság mindig törlésre kerül a dokumentum táblázatos részénél, akkor a rendszer úgy véli, hogy ez a tulajdonság minden alárendelt részletnél is törlődik (a tulajdonság tényleges állapota ellenére).

Alkalmazásobjektum-adatok űrlapadatokká alakításának módszerei

Az alkalmazásobjektumok űrlapadatokká és vissza konvertálásához globális metódusok állnak rendelkezésre:

  • ValueInFormData(),
  • FormDataInValue(),
  • CopyFormData().

Fontos! Az alkalmazásobjektumokkal működő módszerek csak a szervereljárásokban érhetők el. Az űrlapadatok közötti értékek másolásának módja elérhető a szerveren és a kliensen, mivel nem igényel alkalmazásobjektumokat paraméterként.

Amikor az űrlapadatokat alkalmazásobjektummá konvertálja, figyelembe kell vennie azok kompatibilitását.

  • ValueInFormData() – egy alkalmazás típusú objektumot űrlapadatokká alakít;
  • FormDataInValue() – az űrlapadatokat alkalmazás típusú objektummá alakítja;
  • CopyFormData() – olyan űrlapadatokat másol, amelyek kompatibilis szerkezettel rendelkeznek. Igazat ad vissza, ha a másolás sikeres volt, vagy False értéket, ha az objektumstruktúra nem kompatibilis.

Jegyzet. A főbb részleteket tartalmazó űrlap szabványos műveletei (űrlap megnyitása, szabványos írási parancs végrehajtása stb.) végrehajtásakor az átalakítás automatikusan megtörténik.

Mutassunk példát arra, hogyan használhatunk adatátalakítást saját algoritmusainkban.

&OnServerProcedure a CreateOnServer során (hiba, szabványos feldolgozás)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

Az eljárás vége

&OnClient eljárás Write()

WriteOnServer();

Az eljárás vége

&OnServer eljárás WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Az eljárás vége

A ManagedForm objektum metódusai is elérhetők a szerveren:

  • ValueВFormAttribute() – egy alkalmazás típusú objektumot a megadott űrlapattribútummá alakít.
  • FormAttributeVValue() – az űrlapadat attribútumot egy alkalmazástípusú objektummá alakítja.

Ezeknek a módszereknek a használata általában kényelmesebb, mivel például információval rendelkeznek az űrlaprészletek típusáról. Ezenkívül a Form AttributesValue() metódus beállítja az űrlapadatok és az objektum közötti megfelelést, amelyet az üzenetek generálásakor használnak. Erről bővebben a „Szolgáltatásnavigációs képességek” című fejezetben olvashat.

Nézzünk egy példát ezeknek a módszereknek a használatára.

&OnServer eljárás RecalculateOnServer()

// Alkalmazásobjektummá alakítja az Object attribútumot. Dokumentum = Form AttributesValue("Object"); // Újraszámítást hajt végre a dokumentum modulban meghatározott módszerrel. Document.Recalculate(); // Az alkalmazásobjektumot visszaalakítja prop-má. ValueВFormAttributes(Dokumentum, „Objektum”);

Az eljárás vége

Szoftver interfész

FormDataTree

  • FindById
  • GetItems

Leírás:

Egy fa modellezésére tervezték kezelt űrlapadatokban.

Ez az objektum szerializálható XDTO-ba/XDTO-ból. Az objektumnak megfelelő XDTO típus a névtérben van definiálva. XDTO típusnév:

GetItems

Szintaxis:

Get Items()

Visszatérési érték:

Típus: Form DataCollection of Fa Elements.

Leírás:

Legfelső szintű faelemek gyűjteményét kapja.

Elérhetőség: kliens, szerver, vékony kliens, webkliens.

FindById

Szintaxis:

FindById(<Идентификатор>)

Lehetőségek:

<Идентификатор>(kívánt)

Típus: Szám. Fa elem azonosítója.

Visszatérési érték:

Típus: FormDataTreeElement.

Leírás:

Gyűjteményelemet kap azonosító alapján.

Elérhetőség: kliens, szerver, vékony kliens, webkliens.

FormDataTreeItem

Tulajdonságok:

<Имя свойства> (<Имя свойства>)

  • GetId (GetId)
  • GetParent
  • GetItems
  • Ingatlan

Leírás:

Űrlap adatfa elem.

FormDataTreeItemCollection

Gyűjtemény elemei: DataFormTreeElement

Egy objektum esetében lehetőség van a gyűjtemény bejárására a For every... From... Loop operátor segítségével. A bejárás a gyűjtemény elemeit választja ki. Egy gyűjtőelem elérése a [...] operátor segítségével lehetséges. Az elem indexe argumentumként kerül átadásra.

  • Beszúrás
  • Hozzáadás
  • Index (IndexOf)
  • Számol
  • Egyértelmű
  • Kap
  • Mozog
  • Töröl

Leírás:

Fa elemek gyűjteménye.

Elérhetőség: kliens, szerver, vékony kliens, webkliens.

Lásd még:

  • FormDataTreeElement, GetElements metódus
  • DataFormTree, GetItems metódus

Az értékfával való munka jellemzői

Fa frissítés

Van egy probléma esik platformokon a fa frissítésekor.

Ha a fa bármely csomópontja ki lett bontva és egy alárendelt csomópont van kiválasztva, akkor a fa frissítésekor a függvény ValueInFormData leesik az emelvény.

Megoldás: Frissítés előtt törölnie kell a fát.

Például:

&A kiszolgáló eljáráson ClearTree(elements) Minden elemhez az elemekből Loop ClearTree(element.GetElements()); EndCycle; elemek.Clear(); Az eljárás vége

&A kiszolgálói eljáráson Kitöltési fogalomfán() dConcepts = srProperties.Koncepciófa felépítése(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, Concept Tree); Az eljárás vége

&OnClient eljárás OnDateOnChange(Element) Kitöltés ConceptTree(); Az eljárás vége

Az 1C:Enterprise platform lehetővé teszi egy felügyelt űrlap elemeinek programozott hozzáadását és módosítását. Nézzük meg, miért lehet erre szükség.

Az űrlap szoftveres módosítására több esetben is szükség lehet:

  • A szabványos konfigurációk véglegesítésekor a későbbi frissítési eljárás megkönnyítése érdekében. Ebben az esetben csak az űrlapmodul módosul. A modulokat sokkal könnyebb frissíteni, mint az űrlapokat.
  • Néhány gyakori algoritmus implementálásakor. Például az „Objektumrészletek szerkesztésének tilalma” alrendszerben programozottan létrehozható egy gomb az alrendszerhez kapcsolódó összes objektumhoz, amely lehetővé teszi a részletek szerkesztését.
  • Egyes konkrét algoritmusok implementálásakor. Például a Nomenclature könyvtárban mezők jönnek létre további részletek szerkesztéséhez.

A kezelt űrlapon programozottan hozzáadhat, módosíthat és törölhet:

  • kellékek;
  • helyi csapatok;
  • elemeket.

Mindezek a műveletek csak a szerveren lehetségesek.

Az automatizált átalakításnak vannak korlátai:

  • Csak a programozottan hozzáadott részleteket/parancsokat/elemeket törölheti. A konfigurátorban létrehozott objektumok programozottan nem törölhetők.
  • Nem rendelhet hozzá attribútumot főként.

Űrlapparancsok módosítása

Egy objektum parancsainak összetételének kezelése ManagedForm van egy gyűjtemény Csapatok

    Hozzáadás (< ИмяКоманды >)

    Mennyiség ()

    megtalálja (< ИмяКоманды >)

    Töröl (< Команда >)

A Teams gyűjtemény a kliensen és a szerveren is elérhető. A gyűjteményt (Add() és Delete() metódusok) csak a szerveren módosíthatja. A kliensen és a szerveren is megkeresheti és lekérheti az elemek számát (a Find () és a Count () metódusokat.

Példaként az űrlapparancsokkal való munkavégzésre, hozzunk létre egy új ChangeHistory parancsot „ChangeHistory...” fejléccel, amely meghívja a kezelőt. DisplayHistory(). A létrehozás az űrlap megnyitásakor történik.

&A szerveren
Eljárás WhenCreatingOnServer (hiba, szabványos feldolgozás)
Csapat = Csapatok. Add( "A változások története");
Csapat . Akció = ;
Csapat . Cím = "A változások története...";
Az eljárás vége
&OnClient
Eljárás Connectable_DisplayHistory(Command)
// parancs műveletek
Az eljárás vége

A parancskezelőnek egy űrlapon kell elhelyezkednie, és rendelkeznie kell egy &OnClient fordítási direktívával.

Az űrlap részleteinek módosítása

Az űrlaprészletek összetételének beolvasását a funkció végzi Részletek(< Путь >) FormAttributes típusú tömböt ad vissza. A függvény paraméter adja meg a szülőattribútum elérési útját (karakterláncként). Ha a paramétert kihagyjuk, vagy üres karakterláncot adunk meg, a rendszer a legfelső szintű részleteket adja vissza.

A részletek módosítása a módszerrel történik Részletek módosítása(<Hozzáadott részletek>, <Kivehető részletek>) tárgy ManagedForm. A paraméterekhez Hozzáadott részletekÉs Kivehető részletek A Form Attributes típusú elemekkel rendelkező tömbök továbbítása történik.

Figyelem!

A részletek összetételének megváltoztatásának folyamata meglehetősen erőforrás-igényes. Az űrlap valójában újbóli létrehozás alatt áll. Ebben a tekintetben az űrlap részleteivel való munka kötegelt módban történik.

Hozzunk létre egy új űrlapattribútumot Vevő néven:


AddedDetails = Új tömb;
Hozzáadott részletek. Add(Új űrlapattribútumok(„Vevő”, Új típusleírás („DirectoryLink. Partnerek”), „Ügyfél”));

// Változások a részletek összetételében
);

Formaelemek megváltoztatása

Egy objektum elemeinek összetételének szabályozása ManagedForm van egy gyűjtemény Elemek. A gyűjtésnek több módja van:

    Beszúrás (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

    Hozzáadás (< Имя>, < ТипЭлемента>, < Родитель >)

    Mennyiség ()

    megtalálja (< Имя >)

    Mozog(< Элемент>, < Родитель>, < МестоРасположения >)

    Töröl (< Элемент >)

A tételgyűjtemény a kliensen és a szerveren is elérhető. Gyűjtemény módosítása (Módszerek beszúrása () , Hozzáadás () , Áthelyezés () és Törlés () ) csak a szerveren érhetők el. A kliensen és a szerveren is megkeresheti és lekérheti az elemek számát (a Find () és a Count () metódusokat. A gyűjtemény elemei lehetnek:

  • FormGroup;
  • FormTable;
  • FormField;
  • Űrlap gomb.

Programozottan hozzárendelhet eseménykezelőket az űrlapelemekhez. A módszer erre a célra készült SetAction(< ИмяСобытия>, < Действие >) .

Nézzünk meg néhány példát a parancsokkal, részletekkel és űrlapelemekkel való munkavégzésre.

Parancs és a hozzá tartozó gomb hozzáadása:

// Hozzon létre egy parancsot
Csapat = Csapatok. Add( "A változások története");
Csapat . Akció = "Plug-in_DisplayHistory"; // Az űrlapnak tartalmaznia kell egy eljárást a megadott névvel
Csapat . Cím = "A változások története...";
// Hozzon létre egy gombot, és társítsa egy parancshoz
Elem = Tételek. Add( "A változások története", Type("FormButton" ));
Element.CommandName = "A változások története";

Attribútum és a hozzá tartozó beviteli mező hozzáadása:

// A hozzáadott részletek leírása
AddedDetails = Új tömb;
Hozzáadott részletek. Hozzáadás(Új űrlap kellékek ("Vevő", új típusleírás ( "DirectoryLink. Partnerek"), "Ügyfél" ));
// A részletek összetételének megváltoztatása
ChangeDetails (Részletek hozzáadva);
// Beviteli mező létrehozása és csatlakozás az attribútumhoz
Elem = Tételek. Add("Vevő" , Type("Űrlapmező" ));
Elem . Nézet = FormFieldView. beviteli mező;
Elem . PathToData= "Vevő" ;

Eseménykezelő hozzárendelése egy űrlapelemhez:

ItemCustomer. SetAction("Amikor megváltozik" , "Connected_BuyerOnChange");

&OnClient
Eljárás Connected_BuyerOnChange(Elem)
// Eseményműveletek
Az eljárás vége

Figyelem!

A metódus használatával kódból eseménykezelőként beállított eljárások SetAction(), ajánlott a Connectable_ előtagot beállítani.

Figyelem!

Letöltheti a feldolgozást példákkal a programozott keresésre és a kezelt űrlap részleteinek, parancsainak és elemeinek módosítására.

Az űrlap adatai biztosítják az adatokkal való kapcsolatát. Ebben az esetben a részletek közül egy (és csak egy) jelölhető ki főként; nem feltétlenül az az adattípus, amelyre az űrlapot rajzoljuk. Az űrlap viselkedése azonban a fő attribútum adattípusától függ. Az űrlap viselkedésének megváltoztatása mellett az űrlapmodul kontextusa is megváltozik. Az űrlap metódusaival és tulajdonságaival együtt elérhetővé válnak benne az objektum metódusai és tulajdonságai, amely a fő attribútum értéke. Fontos, hogy a Free Form típusú űrlapokon ne legyenek alapvető részletek. Ebben az esetben az űrlap viselkedését csak a felhasználó beállításai határozzák meg. Nézzük meg az alapvető részletekkel kapcsolatos kérdéseket.

Az 1C vizsga 10.05 kérdése: Platform Professional. Mire használják a fő forma attribútumot?

  1. Meghatározza az adatforrást az űrlap egészéhez
  2. Meghatározza a platform szabványos képességeit a fő attribútumban megadott típusú adatokkal rendelkező űrlappal való munkavégzéshez
  3. Lehetővé teszi az objektum részleteinek programozott elérését a helyi űrlapkontextusból
  4. Megjeleníti az objektum részleteit az űrlap párbeszédpanelen
  5. 2 és 3 helyes
  6. 1 és 2 helyes

A helyes válasz a hatos szám, lásd fent.


Az 1C vizsga 10.06. kérdése: Platform Professional. Mire van szükség az űrlap adataira?
  1. Az űrlapon megjelenített, szerkesztett vagy tárolt adatok tartalmának leírása
  2. Adatok megjelenítése és szerkesztése űrlapon
  3. 1 és 2 helyes

A helyes válasz a harmadik – mindkettő.

Az 1C vizsga 10.07 kérdése: Platform Professional. Alapvető attribútumok hozzárendelése egy tetszőleges vezérelt űrlaphoz...

  1. Az űrlapattribútumok tulajdonságainál be kell jelölnie az "Alapadatok" jelölőnégyzetet
  2. ki kell töltenie az űrlap „Adatok” tulajdonságát a szükséges form attribútum kiválasztásával

A helyes válasz a második:

Az 1C vizsga 10.08. kérdése: Platform Professional. A fő részletek hozzárendelése egy tetszőleges szabályos űrlaphoz...
  1. az űrlapot kell fővé tenni, a fő részleteket a rendszer automatikusan határozza meg
  2. Az űrlapattribútumok tulajdonságainál be kell jelölnie az "Alapadatok" jelölőnégyzetet
  3. be kell lépnie a "Szerkesztés" menübe, az "Alapadatok" menüpontba, és ki kell választania a kívánt értéket
  4. ki kell töltenie az űrlap „Adatok” tulajdonságát a szükséges form attribútum kiválasztásával

A negyedik helyes válasz:

A főbb részletek félkövérrel vannak kiemelve:

Az 1C vizsga 10.09 kérdése: Platform Professional. Ha van egy fő forma attribútum, lehetséges-e hozzáadni egy másik fő attribútumot?
  1. Ez lehetetlen
  2. Ez úgy lehetséges, hogy a form attribútum tulajdonsághoz a megfelelő értéket rendeli
  3. Ez csak programozottan lehetséges, az "Űrlap" objektum elérésekor
  4. Ez úgy lehetséges, hogy egy másik értéket ad hozzá a megfelelő form tulajdonsághoz

A helyes válasz az első, ennek szigorúan egy fő feltétele van, mert a tárggyal való kapcsolatnak egyértelműnek kell lennie.

Az 1C vizsga 10.113. kérdése: Platform Professional. Az ábrán bemutatott űrlap részletei közül melyik a fő?

  1. Devizaárfolyamok listája
  2. DirectoryObject
  3. A címtárűrlapoknak nincsenek alapvető adatai
  4. A címtárűrlapokon minden alapvető adat megtalálható
A második helyes válasz a vastagon szedett.

Az űrlap vezérlése különböző űrlapelemeken keresztül történik, amelyek hierarchikusan helyezkednek el a lapon Elemek formatervező. A legfontosabb elem maga a forma, amely az elemhierarchia tetején helyezkedik el, a többi elem pedig alárendeltje.

Minden formaelem öt csoportra osztható: mezők, csoportosító elemek, gombok, dekorációk és asztalok. Cikkeimben az egyes csoportokat elemzem. Ebben a cikkben elkezdjük tanulmányozni a mezőelemek egyik típusát - beviteli mező, de előtte megtanuljuk, hogyan adhatunk hozzá egy elemet az űrlaphoz.

Elemek hozzáadása egy űrlaphoz

Ez egészen egyszerűen megtörténik: ki kell választani az elemet Forma az Űrlaptervező elemek ablakban, és kattintson a „Hozzáadás” gombra. Ezt követően megnyílik egy ablak, amelyben ki kell választani a kívánt elemtípust

Kiválasztás után a kívánt elem megjelenik az ablakban Elemek.

Felügyelt űrlapelem Terület

Nézzünk egy kezelt űrlapelemet Terület. Ez az elem szükséges információk megadásához az űrlapon. És bármilyen információ megjelenítésére is. Miután hozzáadta ezt az elemet az űrlaphoz, a jobb oldalon megnyílik az űrlapelem tulajdonságainak palettája. Egyelőre két tulajdonság érdekelheti – a DataPath és a View.

A DataPath tulajdonságban a fejlesztő egy űrlapelemet társíthat a kívánt form attribútumhoz. Kérjük, vegye figyelembe, hogy az elem hozzáadása után Belépés mező az űrlapon magán az űrlapon nem jelent meg. Ez azért történt, mert az új elemünk nincs társítva a következővel: . Például létrehoztam több attribútumot a feldolgozó űrlapon különböző primitív típusokkal és egy attribútumot referenciatípussal.

Most kössük össze a nemrég hozzáadott űrlapelemünket az egyik részlettel, ehhez válassza ki a kívánt attribútumot az elem PathKData tulajdonságából.

Ezt követően a DataPath és View tulajdonságok kitöltésre kerülnek, és maga az elem jelenik meg az űrlapnézetben.

Ügyeljen az elem tulajdonságaira Kilátás. Ez a tulajdonság határozza meg a beviteli mező működését. Különböző értékeket választhat ehhez az ingatlanhoz.

A kiválasztott értéktől függően a funkció meghatározásra kerül. A fenti ábrákon a kiválasztott érték: beviteli mező, azaz ebben a beviteli mezőben bármilyen értéket megadhatunk, és ha kiválasztunk egy értéket címke mezőben, akkor nem fogunk tudni beírni semmit.

Ez az ingatlan értéke Kilátás A beviteli mezők kényelmesen kiválaszthatók, ha csak súgóinformációkat kell megjeleníteni a felhasználónak.

Most adjunk hozzá egy új űrlapelemet típussal Belépés mezőés kösd össze a kellékekkel RészletekDátum a számunkra már ismert DataPath tulajdonságon keresztül

Mint látható, a beviteli mező megjelenése megváltozott, és a Nézet tulajdonság értékeinek lehetséges kiválasztása is megváltozik.

Így arra a következtetésre jutunk, hogy a beviteli mező funkcionalitása az attribútum típusától függ.

Típusú kellékekhez Boolean A következő Nézet tulajdonságértékek lesznek elérhetők.

A referenciatípusú attribútumok esetében pedig a Nézet tulajdonság egyéb értékei is elérhetők lesznek.

Részletesebb munka az űrlapelemekkel gyakorlati példákon keresztül a „Fejlesztési alapok az 1C-ben: Taxi” című könyvben található. Felügyelt alkalmazásfejlesztés 12 lépésben".

Néha úgy tűnik, hogy a programozási nyelv megtanulása az 1C-ben bonyolult és nehéz. Valójában 1C-ben könnyű programozni. Könyveim segítenek gyorsan és egyszerűen elsajátítani a programozást 1C: és „A fejlesztés alapjai az 1C: Taxiban” programozásban.

Tanuljon programozni 1C-ben a „Programozás 1C-ben 11 lépésben” című könyvem segítségével.

  1. Nincsenek bonyolult szakkifejezések.
  2. Több mint 700 oldal gyakorlati anyag.
  3. Minden feladathoz tartozik egy rajz (screenshot).
  4. Feladatok gyűjteménye házi feladathoz.
  5. A könyv világos és egyszerű nyelven íródott - kezdőknek.

Ez a könyv azoknak szól, akik már elkezdtek programozni, és bizonyos nehézségekkel küzdenek ezzel a témával, valamint azoknak, akik már régóta programoznak, de soha nem dolgoztak 1C kezelt űrlapokkal.

  1. Összetett szakkifejezések nélkül;
  2. Több mint 600 oldal gyakorlati anyag;
  3. Minden példához rajz (screenshot) tartozik;
  4. A könyvet e-mailben küldjük el PDF formátumban. Bármilyen eszközön kinyitható!

Promóciós kód 15% kedvezményért - 48PVXHeYu


Ha ez a lecke segített valamilyen probléma megoldásában, tetszett vagy hasznosnak találta, akkor tetszőleges összeggel támogathatja projektemet:

Fizethet kézzel:

Yandex.Money - 410012882996301
Web Money - R955262494655

Csatlakozz a csoportjaimhoz.

És adatátviteli objektum a kód strukturálásához, vezérelt formában az 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 ínyencei érdemes kihagyni ezt a részt.

2008-ban elérhetővé vált az 1C platform új verziója: 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. Ugyanakkor nemcsak a konfigurációs felhasználói felület fejlesztésének modellje változik meg, hanem egy új architektúra is javasolt a kliens alkalmazá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 felügyelt alkalmazás új technológiára épülő űrlapokat használ. Úgy hívják Kezelt űrlapok. Az átállás megkönnyítése érdekében a korábbi űrlapok (az ún. reguláris űrlapok) is támogatottak, de ezek funkcionalitása nincs kifejlesztve, és csak vastag kliens indító módban érhetők el.
A kezelt űrlapok fő különbségei a fejlesztők számára:
  • A szerkezet deklaratív, nem „pixelről pixelre” leírása. Az elemek konkrét elhelyezését a rendszer automatikusan elvégzi az űrlap megjelenítésekor.
  • Az űrlap összes funkciója a következőképpen van leírva részletekÉs csapatok. A részletek azok az adatok, amelyekkel az űrlap működik, a parancsok pedig a végrehajtandó műveletek.
  • Az űrlap a szerveren és a kliensen is fut.
  • Kliens környezetben szinte minden alkalmazástípus nem érhető el, ennek megfelelően az infobázisban lévő adatok megváltoztatása nem lehetséges.
  • Minden metódushoz vagy űrlapváltozóhoz meg kell adni összeállítási irányelv, amely meghatározza a végrehajtási helyet (kliens vagy szerver) és az űrlapkontextushoz való hozzáférést.
Soroljuk fel az űrlapmetódusok összeállítására vonatkozó direktívákat:
  • &OnClient
  • &A szerveren
  • &OnServerContext nélkül
  • &OnClientOnServerKontextus 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. Keresse meg a deklaratív 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.
Ezalatt az idő alatt kialakult-e a fejlesztők közös értelmezése a kliens-szerver interakció elveiről az űrlapok létrehozásakor, és megváltozott-e a szoftvermodulok megvalósításának megközelítése az új építészeti valóságban?

Nézzük meg a kódszerkezetet (űrlapmodult) ugyanazon szabványos konfiguráció több alakjában, és próbáljunk mintákat találni.
Struktúrán a kód szakaszait értjük (leggyakrabban ezek megjegyzésblokkok), amelyeket a fejlesztő a metódusok csoportosítására és az ezekhez a metódusokhoz tartozó fordítási direktívákhoz rendel hozzá.
1. példa:
Eseménykezelők szekciója Módszer - a kliensen Módszer - a szerveren Módszer - a kliensen Szervizeljárások és -funkciók szekció Kiegészítő bemenetvezérlő funkciók
2. példa:
Szolgáltatási eljárások és funkciók Fizetési bizonylatok Értékek Esemé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 „kapcsolati adatok” alrendszer eljárásai
Lényegében hiányzik a kódstruktúra, vagy enyhén szólva hasonló a Forms 8.1-hez:

  • Nem tájékoztató jellegű „Általános, Szerviz, Kisegítő” szavak.
  • 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 előfordulhat, hogy az eseménykezelők egyik formában felül vannak, egy másikban alul, harmadikban egyáltalán nincsenek kiemelve stb.
  • És ne felejtsük el, hogy mindez egyetlen konfiguráción belül van.
  • Igen, vannak olyan konfigurációk, amelyekben az „Általános, Szerviz, Kisegí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 választásod
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, amelyek a kezelt űrlap megírásakor ajánlottak.
  • Minimalizálja a szerverhívások számát.
  • Maximális számítás a szerveren.
  • A nem kontextuális szerverhívások gyorsabbak, mint a kontextus szerintiek.
  • Program az ügyfél-szerver kommunikációt szem előtt tartva.
  • stb.
Ezek teljesen igazak szlogenek, de hogyan valósítsuk meg őket? 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 interfész)
  • Adatátviteli objektum(a továbbiakban: adatátviteli objektum)
Egy szó Martin Fowlertől, 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ámlát és az összes tételét külön kéri, hanem az összes számlatételt egy kérelemben kell elolvasnia és frissítenie. Ez kihat az objektum teljes szerkezetére...Ne feledje: távoli elérési felület 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 adatátviteli objektumok nem mások, mint dagadt mezei 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ás során- elosztott rendszerekben nagy jelentőségű technika.
Példák sablonokra az 1C platformon
A felügyelt űrlap fejlesztése során a fejlesztő rendelkezésére álló alkalmazásprogramozási felület számos példát tartalmaz ezekre az elvekre.
Például az OpenForm() metódus, egy tipikus „durva” felület.
OpeningParameters = New Structure("Paraméter1, Paraméter2, Paraméter 3", Érték1, Érték2, Érték3); Form = OpenForm(FormName, OpeningParameters);
Hasonlítsa össze a v8.1-ben elfogadott stílussal.
Form = GetForm(FormName); Form.Parameter1 = Érték1; Form.Parameter2 = Érték2; Form.Open();

A kezelt űrlap kontextusában sok „adatátviteli objektum” létezik. Választhat 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. Lehetetlen létrehozni őket az űrlap részleteire való hivatkozás nélkül.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
A rendszeradatátviteli objektumok alkalmazástípusokká konvertálása és fordítva a következő módszerekkel történik:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Gyakran explicit konverziót használnak egy meglévő megoldás adaptálásakor. A metódusok bemeneti paramétereket várhatnak (funkciókat használhatnak), például a ValueTable-t a FormDataCollection helyett, vagy a metódust egy alkalmazásobjektum kontextusában határozták meg, és nem elérhető az űrlapról történő közvetlen meghíváshoz.
Példa 1C v8.1:
// az ügyfélen a FillUserCache(DepartmentLink) űrlap kontextusában
Példa 1C v8.2:
// a szerveren a ProcessingObject = Form AttributesValue("Object") űrlap kontextusában; ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Az adatátviteli objektumok, amelyek szerkezetét a fejlesztő határozza meg, a kliensen és a szerveren egyaránt elérhető típusok egy kis részhalmazát alkotják. Leggyakrabban a következőket használják a „durvított” interfész metódusainak paramétereiként és eredményeiként:

  • Primitív típusok (karakterlánc, szám, logikai érték)
  • Szerkezet
  • Levelezés
  • 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 módosítá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 Megbízás Cycle StartTransaction(); Próbáld ki a DocOb = Order.GetObject(); …. egyéb műveletek, amelyek nem csak a megrendeléssel lehetségesek... Kivétel CancelTransaction(); Errors.Insert(Rendelés, Hibaleírás()); EndAttempt; 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 időpontjában ez két kölcsönhatásban lévő folyamat, amelyek mindegyike jelentősen eltérő elérhető funkciókkal rendelkezik.
  • A távelérési felület egyértelmű azonosítá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 a kód olvasása közben azonnal láthassa az irányítás átadását a szerverre, és leegyszerűsíti a kontextus súgó használatát. Ne feledje, hogy a hivatalos ajánlás (ITS) a postfixekkel ellátott elnevezési módszereket javasolja, például ChangeOrderStatusOnServer(). Megismételjük azonban, hogy nem minden szervermetódus hívható meg a klienstől, ezért a logikai hozzáférhetőség fontosabb, mint a fordítási hely. Ezért a „Server” előtaggal csak a kliens számára elérhető metódusokat jelöljük, nevezzük a példametódusnak 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ához egyértelmű helyet kell biztosítani. Fontos szempont, hogy a konfigurátor által automatikusan létrehozott metódusablonok a modul végére kerülnek. Mivel az űrlapelemek eseménykezelői leggyakrabban automatikusan jönnek létre, a megfelelő blokk az utolsó helyen található, 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 opció – világosan mutatja a végrehajtás fő folyamatát.
  • A szöveg opció egy példa egy sablontervre, amellyel gyorsan beszúrhat egy szerkezetet egy új űrlapmodulba.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Dátum=""/> // <Описание> // // //////////////////////////////////////////////// /////////////////////////// // MODUL VÁLTOZÓI ////////////////// ////////////////////////////////////////////////// ////////// // A SZERVEREN //******* ESEMÉNYEK A SZERVEREN ******** &A kiszolgálói eljárásról a szerveren történő létrehozáskor (hiba, szabványos feldolgozás) / /A kezelő tartalmának beillesztése Eljárás vége //******* TÁVELÉRÉSI INTERFÉSZ ****** //******** ÜZLETI LOGIKA A SZERVEREN ******* ////////////////////////////////////////////////// /////// //////////////////// // AZ ÜGYFÉL ÉS A SZERVER KÖZÖS MÓDSZEREI //////////////// /////// /////////////////////////////////////////// ///// //////// // AZ ÜGYFÉLEN //******* ÜZLETI LOGIKA AZ ÜGYFÉLEN ******** //******** CSAPAT * ****** //******** CLIENT ESEMÉNYEK ******* /////////////////////////// ///// ///////////////////////////////////////////// // / / FŐ PROGRAM ÜZEMELTETEŐ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ása során.
  • A távelérési interfész megvalósítási lehetőségei. Aszinkron, részletesség...
  • Gyorsítótárazás. Az 1C sikertelen építészeti döntést hozott, a gyorsítótárazást csak a közös modulok hívási módszereinek szintjén vezette be, és nem biztosított vezérlési képességeket (relevanciaidő, 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 arra készteti a platformot, hogy kapcsolatba lépjen a szerverrel.


Kapcsolódó kiadványok