Základní detaily formuláře. Podrobnosti spravovaného formuláře (1Cv8) Spravované formuláře 1c přidávají podrobnosti programově
Podrobnosti formuláře
Sada podrobností formuláře popisuje složení dat, která jsou zobrazena, upravována nebo uložena ve formuláři. Samotné detaily formuláře zároveň neposkytují možnost zobrazení a úpravy dat. Prvky formuláře (viz část „Prvky formuláře“ v této kapitole) spojené s podrobnostmi formuláře se používají k zobrazení a úpravám. Sada všech podrobností formuláře se bude nazývat data formuláře.
Důležité! Je třeba mít na paměti, že na rozdíl od běžných formulářů musí být všechna data ve spravovaném formuláři popsána ve formě detailů. Není povoleno používat proměnné modulu formuláře jako zdroje dat pro prvky formuláře.
Je možné přiřadit Základní detaily formuláře, tedy atributy, které budou určovat standardní funkčnost formuláře (přípona formuláře). Je třeba si uvědomit, že formulář může mít pouze jeden hlavní atribut.
Rozšíření formuláře– to jsou další vlastnosti, metody a parametry formuláře objektu ManagedForm, charakteristické pro objekt, který je hlavním prvkem formuláře.
Během procesu vývoje formuláře můžete explicitně nastavit možnost prohlížet a upravovat konkrétní podrobnosti formuláře, pokud jde o role, pomocí vlastností Zobrazit a Upravit (další podrobnosti naleznete v části „Nastavení formuláře na základě rolí“ v části „Editoři kapitola). Kromě toho lze dostupnost konkrétního atributu v samotném formuláři konfigurovat pomocí funkčních možností (více podrobností o funkčních možnostech naleznete v kapitole „Správa konfiguračního rozhraní“).
Vlastnost atributu formuláře Uložená data je známkou toho, že interaktivní změna detailů povede k pokusu o zablokování údajů formuláře pro editaci a také k automatickému nastavení příznaku úpravy formuláře.
Datové typy dostupné ve spravovaném formuláři
Spravovaný formulář se od běžného formuláře liší také typy dat, se kterými pracuje. Pokud normální formulář pracuje s většinou typů, které 1C:Enterprise poskytuje (včetně typů DirectoryObject, DocumentObject atd.), pak lze ve spravovaném formuláři rozlišit následující kategorie typů:
- typy, které se přímo používají ve formuláři, jsou typy, které existují na straně tenkého a webového klienta (například Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
- typy, které budou převedeny na speciální datové typy – datové typy spravovaných formulářů. Takové typy jsou zobrazeny v seznamu podrobností formuláře v závorkách, například (DirectoryObject.Products);
- dynamický seznam (další podrobnosti viz část „Dynamický seznam“ této kapitoly).
Převod aplikačních objektů na data formuláře
Některé typy aplikací (jako je DirectoryObject atd.) na straně tenkého a webového klienta neexistují (další podrobnosti viz kapitola Koncepce spravované aplikace). Pro reprezentaci takových typů aplikací ve formuláři proto platforma zavedla speciální datové typy navržené pro práci ve spravovaných formulářích. Tato funkce spravované aplikace vyžaduje převod objektů aplikace na data formuláře (a naopak).
Používají se následující datové typy:
- Form DataStructure – obsahuje sadu vlastností libovolného typu. Vlastnosti mohou být jiné struktury, kolekce nebo struktury s kolekcemi. Tento typ je reprezentován např. ve tvaru DirectoryObject.
- FormDataCollection je seznam zadaných hodnot, podobný poli. K prvku kolekce se přistupuje pomocí indexu nebo identifikátoru. Přístup pomocí ID nemusí být v některých případech k dispozici. To je způsobeno typem objektu aplikace, který je reprezentován touto kolekcí. Identifikátor může být libovolné celé číslo. Tento typ je zastoupen např. ve formě tabulkové části.
- Form DataStructureWithCollection je objekt, který je reprezentován jako struktura a kolekce zároveň. Lze s ní zacházet jako s kteroukoli z těchto entit. Tento typ představuje například sadu záznamů ve formuláři.
- Form DataTree – objekt určený k ukládání hierarchických dat.
Objekt aplikace je reprezentován jedním nebo více datovými prvky formuláře. Obecně platí, že hierarchie a složení dat formuláře závisí na složitosti a propojení aplikačních objektů spravovaného formuláře.
Například dokument obsahující tabulkovou část bude reprezentován objektem typu FormDataStructure (samotný dokument), kterému je podřízen objekt typu FormDataCollection (tabulková část dokumentu).
Důležité! Při vývoji konfigurace je důležité pamatovat na to, že aplikační objekty jsou dostupné pouze na serveru, zatímco datové objekty formuláře lze použít jak na serveru, tak na klientovi.
Předávání dat mezi klientskou a serverovou částí spravovaného formuláře
Ve skutečnosti lze říci, že data formuláře jsou jednotnou reprezentací dat z různých aplikačních objektů, se kterými formulář pracuje jednotně a které jsou přítomny na serveru i na klientovi. To znamená, že formulář obsahuje určitou „projekci“ dat objektu aplikace ve formě vlastních datových typů a v případě potřeby mezi nimi provádí konverzi. Pokud však vývojář konfigurace implementuje svůj vlastní algoritmus pro zpracování dat, musí konverzi dat (ze specializovaných typů na typy aplikací a naopak) provádět samostatně.
Při editaci detailů formuláře ve specializovaném editoru (více viz sekce „Detaily formuláře“ v kapitole „Editoři“) je možné ovlivnit přenos dat mezi klientem a serverem za běhu formuláře. K tomu slouží sloupec editoru detailů. Vždy používejte. Efekt této vlastnosti se liší pro tři typy atributů:
- Pro atribut podřízený dynamickému seznamu (sloupec dynamického seznamu):
- vlastnost povolena – atribut je vždy načten z databáze a zahrnut do dat formuláře;
- vlastnost je zakázána - atribut je načten z databáze a zahrnut do dat formuláře pouze v případě, že je k atributu nebo jeho podřízenému atributu přiřazen aktuálně viditelný prvek formuláře.
- Pro rekvizity podřízené kolekci pohybu:
- vlastnost je povolena – pohyby dokladů jsou načteny z databáze a budou přítomny v datech formuláře;
- vlastnost je zakázána - pohyby dokladů nebudou načteny z databáze a nebudou zahrnuty do dat formuláře (pokud neexistuje prvek formuláře, který odkazuje na pohyby dokladu).
- Další podrobnosti formuláře:
- vlastnost je povolena – atribut bude přítomen v datech formuláře bez ohledu na to, zda existuje nebo není alespoň jeden prvek formuláře, který je spojen s atributem nebo jeho podřízeným atributem;
- vlastnost je zakázána - atribut bude v datech formuláře přítomen pouze v případě, že je k atributu nebo jeho podřízenému atributu přidružen prvek formuláře. Na rozdíl od atributů dynamického seznamu zde nezáleží na viditelnosti prvku spojeného s atributem.
Poznámka. Je třeba si uvědomit, že vlastnost nastavená na nadřazeném atributu ovlivňuje všechny podřízené atributy. Pokud je například vlastnost Použít pro tabulkovou část dokumentu vždy vymazána, systém se domnívá, že tato vlastnost je vymazána i pro všechny podřízené podrobnosti (nehledě na skutečný stav vlastnosti).
Metody pro převod dat objektu aplikace na data formuláře
Chcete-li převést objekty aplikace na data formuláře a zpět, existuje sada globálních metod:
- ValueInFormData(),
- FormDataInValue(),
- CopyFormData().
Důležité! Metody, které pracují s aplikačními objekty, jsou dostupné pouze v procedurách serveru. Metoda pro kopírování hodnot mezi daty formuláře je dostupná na serveru a na klientovi, protože nevyžaduje jako parametry aplikační objekty.
Při převodu dat formuláře na aplikační objekt je třeba zvážit jejich kompatibilitu.
- ValueInFormData() – převede objekt typu aplikace na data formuláře;
- FormDataInValue() – převádí data formuláře na objekt typu aplikace;
- CopyFormData() – zkopíruje data formuláře, která mají kompatibilní strukturu. Vrátí True, pokud byla kopie úspěšná, nebo False, pokud je struktura objektu nekompatibilní.
Poznámka. Při provádění standardních akcí (otevření formuláře, provedení standardního příkazu Zápis atd.) formuláře s hlavními detaily se převod provede automaticky.
Uveďme příklad, jak využít transformaci dat ve vlastních algoritmech.
ObjectProduct = Directories.Products.FindByName("Kavovar").GetObject(); ValueInFormData(ObjectItem, Object);
Konec procedury
&OnClient Procedure Write()
WriteOnServer();
Konec procedury
&OnServer procedura WriteOnServer()
ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();
Konec procedury
Objekt ManagedForm má také metody dostupné na serveru:
- ValueВFormAttribute() – převede objekt typu aplikace na zadaný atribut formuláře.
- FormAttributeVValue() – převádí atribut dat formuláře na objekt typu aplikace.
Použití těchto metod je obvykle pohodlnější, protože obsahují například informace o typu podrobností formuláře. Metoda Form AttributesValue() navíc nastavuje shodu mezi daty formuláře a objektem, který se používá při generování zpráv. Více se o tom můžete dočíst v kapitole „Možnosti navigace služby“.
Uveďme si příklad použití těchto metod.
// Převede atribut Object na aplikační objekt. Dokument = Form AttributesValue("Object"); // Provede přepočet pomocí metody definované v modulu dokumentu. Document.Recalculate(); // Převede objekt aplikace zpět na prop. ValueВFormAttributes(Document, “Object”);
Konec procedury
Softwarové rozhraní
FormDataTree
- FindById
- GetItems
Popis:
Navrženo pro modelování stromu v datech spravovaného formuláře.
Tento objekt lze serializovat do/z XDTO. Typ XDTO odpovídající tomuto objektu je definován ve jmenném prostoru. Název typu XDTO:
GetItems
Syntax:
GetItems()
Návratová hodnota:
Typ: Formulář DataCollection of Tree Elements.
Popis:
Získá kolekci prvků stromu nejvyšší úrovně.
Dostupnost: klient, server, tenký klient, webový klient.
FindById
Syntax:
FindById(<Идентификатор>)
Možnosti:
<Идентификатор>(Požadované)
Typ: Číslo. Identifikátor prvku stromu.
Návratová hodnota:
Typ:FormDataTreeElement.
Popis:
Získá prvek kolekce podle ID.
Dostupnost: klient, server, tenký klient, webový klient.
FormDataTreeItem
Vlastnosti:
<Имя свойства> (<Имя свойства>)
- GetId (GetId)
- GetParent
- GetItems
- Vlastnictví
Popis:
Prvek stromu dat formuláře.
FormDataTreeItemCollection
Prvky kolekce: DataFormTreeElement
U objektu je možné procházet sběr pomocí operátoru Pro každý... Od... Smyčka. Procházení vybere prvky kolekce. K prvku kolekce je možné přistupovat pomocí operátoru [...]. Index prvku je předán jako argument.
- Vložit
- Přidat
- Index (IndexOf)
- Počet
- Průhledná
- Dostat
- Hýbat se
- Vymazat
Popis:
Kolekce dřevěných prvků.
Dostupnost: klient, server, tenký klient, webový klient.
Viz také:
- FormDataTreeElement, metoda GetElements
- DataFormTree, metoda GetItems
Funkce práce se stromem hodnot
Aktualizace stromu
Vyskytl se problém pády platformy při aktualizaci stromu.
Pokud byl některý uzel ve stromu rozšířen a byl vybrán podřízený uzel, pak při aktualizaci stromu pomocí funkce ValueInFormData plošina spadne.
Řešení: Před aktualizací musíte vymazat strom.
Například:
&Na serveru Postup ClearTree(elements) Pro každý prvek z prvků Loop ClearTree(element.GetElements()); EndCycle; elementy.Clear(); Konec procedury
&Na serveru Postup Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Konec procedury
&Procedura OnClient OnDateOnChange(Element) Fill ConceptTree(); Konec procedury
Platforma 1C:Enterprise umožňuje programově přidávat a měnit prvky spravovaného formuláře. Pojďme zjistit, proč to může být potřeba.
Softwarová úprava formuláře může být vyžadována v několika případech:
- Při dokončování standardních konfigurací pro usnadnění následného postupu aktualizace. V tomto případě se změní pouze modul formuláře. Moduly se aktualizují mnohem snadněji než formuláře.
- Při implementaci některých běžných algoritmů. Například v podsystému „Zákaz úpravy podrobností objektu“ lze programově vytvořit tlačítko pro všechny objekty připojené k podsystému, aby bylo možné upravovat podrobnosti.
- Při implementaci některých specifických algoritmů. Například v adresáři Nomenclature jsou vytvořena pole pro úpravu dalších podrobností.
Ve spravovaném formuláři můžete programově přidávat, měnit a odstraňovat:
- náležitosti;
- místní týmy;
- Prvky.
Všechny tyto operace jsou možné pouze na serveru.
Programatická změna tvaru má omezení:
- Můžete odstranit pouze programově přidané podrobnosti/příkazy/prvky. Objekty vytvořené v konfigurátoru nelze programově odstranit.
- Nemůžete přiřadit atribut jako hlavní.
Změna příkazů formuláře
Správa složení příkazů pro objekt ManagedForm existuje sbírka Týmy
Přidat (< ИмяКоманды >)
Množství ()
Nalézt (< ИмяКоманды >)
Vymazat (< Команда >)
Kolekce Teams je k dispozici na klientovi i serveru. Kolekci (metody Add() a Delete()) můžete změnit pouze na serveru. Můžete vyhledat a získat počet prvků (metody Find () a Count ()) na klientovi i na serveru.
Jako příklad práce s formulářovými příkazy si vytvořte nový příkaz ChangeHistory s nadpisem „ChangeHistory...“, který bude volat handler DisplayHistory(). K vytvoření dojde při otevření formuláře.
&Na serveru
Postup WhenCreatingOnServer(Failure, StandardProcessing)
tým = Týmy. Přidat( "Historie změn");
tým . Akce = ;
tým . Titul = "Historie změn...";
Konec procedury
&OnClient
Postup Connectable_DisplayHistory(Command)
// akce příkazů
Konec procedury
Obslužná rutina příkazu musí být umístěna ve formuláři a musí mít direktivu kompilace &OnClient.
Změna podrobností formuláře
Čtení složení detailů formuláře provádí funkce Získejte podrobnosti(< Путь >) vrací pole typu FormAttributes. Parametr funkce určuje cestu k nadřazenému atributu (jako řetězec). Pokud je parametr vynechán nebo je zadán prázdný řetězec, vrátí se podrobnosti nejvyšší úrovně.
Změna detailů se provádí pomocí metody Změnit podrobnosti(<Přidány podrobnosti>, <Odnímatelné detaily>) objekt ManagedForm. K parametrům Přidány podrobnosti A Odnímatelné detaily Jsou přenášena pole s prvky typu Form Attributes.
Pozornost!
Proces změny kompozice detailů je poměrně náročný na zdroje. Formulář se ve skutečnosti znovu vytváří. V tomto ohledu se práce s detaily formuláře provádí v dávkovém režimu.
Vytvořme nový atribut formuláře s názvem Kupující:
AddedDetails = Nové pole;
Přidány podrobnosti. Přidat(Nové atributy formuláře(„Kupující“, Popis nového typu („Odkaz na adresář. Protistrany“), „Klient“));// Změny ve složení detailů
);
Změna prvků formuláře
K ovládání kompozice prvků objektu ManagedForm existuje sbírka Elementy. Sběr má několik metod:
Vložit (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Přidat (< Имя>, < ТипЭлемента>, < Родитель >)
Množství ()
Nalézt (< Имя >)
Hýbat se(< Элемент>, < Родитель>, < МестоРасположения >)
Vymazat (< Элемент >)
Kolekce Items je dostupná na klientovi i serveru. Upravte kolekci (metody vložení () , Přidat () , Přesunout () a Odstranit () ) jsou dostupné pouze na serveru. Můžete vyhledat a získat počet prvků (metody Find () a Count ()) na klientovi i na serveru. Prvky kolekce mohou být:
- FormGroup;
- FormTable;
- FormField;
- Tlačítko formuláře.
K prvkům formuláře můžete programově přiřadit obslužné rutiny událostí. Metoda je určena pro tyto účely SetAction(< ИмяСобытия>, < Действие >) .
Podívejme se na některé z nejběžnějších příkladů práce s příkazy, detaily a prvky formuláře.
Přidání příkazu a jeho přiřazeného tlačítka:
// Vytvořte příkaz
tým = Týmy. Přidat( "Historie změn");
tým . Akce = "Plug-in_DisplayHistory"; // Formulář musí obsahovat proceduru se zadaným názvem
tým . Nadpis = "Historie změn...";
// Vytvořte tlačítko a přidružte jej k příkazu
Živel = Předměty. Přidat( "Historie změn", Type("FormButton" ));
Element.CommandName = "Historie změn";
Přidání atributu a souvisejícího vstupního pole:
// Popis přidaných detailů
AddedDetails = Nové pole;
Přidány podrobnosti. Přidat(Nové možnosti formuláře („Kupující“, Popis nového typu ( "DirectoryLink. Protistrany"), "Klient" ));
// Změna složení detailů
ChangeDetails (Přidané podrobnosti);
// Vytvoření vstupního pole a propojení s atributy
Živel = Předměty. Add("Buyer" , Type("FormField" ));
Živel . Zobrazit = FormFieldView. Vstupní pole;
Živel . PathToData= "kupující" ;
Přiřazení obslužné rutiny události k prvku formuláře:
ItemCustomer. SetAction("Když se to změní", "Connected_BuyerOnChange");
&OnClient
Postup Connected_BuyerOnChange(Živel)
// Akce událostí
Konec procedury
Pozornost!
Procedury, které jsou nastaveny jako obslužné rutiny událostí z kódu pomocí metody SetAction(), je doporučeno nastavit prefix Connectable_.
Pozornost!
Můžete si stáhnout zpracování s ukázkami programového vyhledávání a změn detailů, příkazů a prvků spravovaného formuláře.
Detaily formuláře zajišťují jeho spojení s daty. V tomto případě může být jeden (a pouze jeden) z detailů označen jako hlavní; nemusí to být nutně datový typ, do kterého formulář kreslíme. Chování formuláře však bude záviset na datovém typu hlavního atributu. Kromě změny chování formuláře se změní i kontext modulu formuláře. Spolu s metodami a vlastnostmi formuláře se v něm zpřístupňují i metody a vlastnosti objektu, který je hodnotou hlavního atributu. Je důležité, aby formuláře typu Free Form neměly základní detaily. V tomto případě je chování formuláře určeno pouze nastavením uživatele. Zvažme otázky týkající se základních detailů.
Otázka 10.05 zkoušky 1C: Platform Professional. K čemu se používá hlavní atribut formuláře?
- Definuje zdroj dat pro formulář jako celek
- Definuje standardní možnosti platformy pro práci s formulářem s daty typu uvedeného v hlavním atributu
- Poskytnout možnost programově přistupovat k podrobnostem objektu z místního kontextu formuláře
- Poskytuje vizualizaci detailů objektu v dialogovém okně formuláře
- 2 a 3 jsou správné
- 1 a 2 jsou správně
Správná odpověď je číslo šest, viz výše.
Otázka 10.06 zkoušky 1C: Platform Professional. K čemu jsou potřebné údaje formuláře?
- Popis obsahu dat, která jsou zobrazena, upravena nebo uložena ve formuláři
- Chcete-li zobrazit a upravit data ve formuláři
- 1 a 2 jsou správně
Správná odpověď je třetí – obojí.
Otázka 10.07 zkoušky 1C: Platform Professional. Chcete-li přiřadit základní atributy libovolnému řízenému formuláři...
- Musíte zaškrtnout políčko "Základní podrobnosti" ve vlastnostech atributů formuláře
- musíte vyplnit vlastnost „Data“ formuláře výběrem požadovaného atributu formuláře
Správná odpověď je druhá:
Otázka 10.08 zkoušky 1C: Platform Professional. Chcete-li přiřadit hlavní detaily libovolnému pravidelnému tvaru...- formulář musí být hlavní, hlavní podrobnosti jsou určeny automaticky
- Musíte zaškrtnout políčko "Základní podrobnosti" ve vlastnostech atributů formuláře
- musíte přejít do nabídky "Upravit", "Základní podrobnosti" a vybrat požadovanou hodnotu
- musíte vyplnit vlastnost „Data“ formuláře výběrem požadovaného atributu formuláře
Čtvrtá správná odpověď je:
Hlavní detaily jsou zvýrazněny tučně:
Otázka 10.09 zkoušky 1C: Platform Professional. Pokud existuje jeden hlavní atribut formuláře, je možné přidat další hlavní atribut?- To je nemožné
- Je to možné přiřazením příslušné hodnoty vlastnosti atributu formuláře
- Je to možné pouze programově, při přístupu k objektu "Formulář".
- To je možné přidáním další hodnoty k odpovídající vlastnosti formuláře
Správná odpověď je první, je zde striktně jeden hlavní požadavek, protože souvislost s objektem musí být jednoznačná.
Otázka 10.113 zkoušky 1C: Platform Professional. Který z detailů formuláře na obrázku je ten hlavní?
- Seznam měnových kurzů
- DirectoryObject
- Adresářové formuláře nemají základní detaily
- Adresářové formuláře mají všechny základní detaily
Formulář se ovládá prostřednictvím různých formulářových prvků, které jsou hierarchicky umístěny na kartě Elementy návrhář formulářů. Nejdůležitějším prvkem je samotný formulář, který se nachází na vrcholu hierarchie prvků a zbylé prvky jsou mu podřízeny.
Všechny prvky formuláře lze rozdělit do pěti skupin: pole, prvky seskupení, tlačítka, dekorace a tabulky. Ve svých článcích budu analyzovat každou ze skupin. V tomto článku začneme studovat jeden z typů prvků pole - vstupní pole, ale předtím se naučíme, jak přidat prvek do formuláře.
Přidávání prvků do formuláře
To se provádí zcela jednoduše: musíte vybrat prvek Formulář v okně Prvky návrhu formuláře a klikněte na tlačítko „Přidat“. Poté se otevře okno, ve kterém musíte vybrat požadovaný typ prvku
Po výběru se v okně objeví požadovaný prvek Elementy.
Spravovaný formulářový prvek Pole
Podívejme se na prvek spravovaného formuláře Pole. Tento prvek je potřebný k zadání informací do formuláře. A také k zobrazení jakýchkoli informací. Po přidání tohoto prvku do formuláře se vpravo otevře paleta vlastností prvku formuláře. Prozatím by vás měly zajímat dvě vlastnosti – DataPath a View.
Ve vlastnosti DataPath může vývojář přidružit prvek formuláře k požadovanému atributu formuláře. Vezměte prosím na vědomí, že po přidání prvku Vstupní pole na formuláři nebyl zobrazen na formuláři samotném. Stalo se to proto, že náš nový prvek není spojen s . Například jsem vytvořil několik atributů na formuláři pro zpracování s různými primitivními typy a jeden atribut s typem reference.
Nyní propojme náš nedávno přidaný formulářový prvek s jedním z detailů. Chcete-li to provést, vyberte požadovaný atribut z vlastnosti PathKData prvku.
Poté se vyplní vlastnosti DataPath a View a samotný prvek se zobrazí ve formulářovém zobrazení.
Věnujte pozornost vlastnosti prvku Pohled. Tato vlastnost určuje funkčnost vstupního pole. Pro tuto vlastnost můžete vybrat různé hodnoty.
V závislosti na zvolené hodnotě bude určena funkčnost. Na obrázcích výše je zvolená hodnota – vstupní pole, tj. do tohoto vstupního pole můžeme zadat libovolné hodnoty, a pokud vybereme hodnotu pole štítku, pak nebudeme moci nic zadat.
Hodnota této vlastnosti Pohled Vstupní pole lze pohodlně vybrat, když potřebujete uživateli zobrazit informace nápovědy.
Nyní přidáme nový formulářový prvek s typem Vstupní pole a spojte jej s rekvizitami Podrobnosti Datum prostřednictvím nám již známé vlastnosti DataPath
Jak vidíte, změnil se vzhled vstupního pole a změní se i možný výběr hodnot pro vlastnost View.
Dojdeme tedy k závěru, že funkčnost vstupního pole závisí na typu atributu.
Pro rekvizity s typem Boolean K dispozici budou následující hodnoty vlastností zobrazení.
A pro atributy s typem odkazu budou k dispozici další hodnoty vlastnosti View.
Podrobnější práce s formulářovými prvky na praktických příkladech je uvedena v knize „Základy vývoje v 1C: Taxi. Spravovaný vývoj aplikací ve 12 krocích“.
Někdy se zdá, že naučit se programovací jazyk v 1C je složité a obtížné. Ve skutečnosti je programování v 1C snadné. Moje knihy vám pomohou snadno a rychle zvládnout programování v 1C: a „Základy vývoje v 1C: Taxi“
Naučte se programovat v 1C s pomocí mé knihy „Programování v 1C v 11 krocích“
- Žádné složité technické termíny.
- Více než 700 stran praktického materiálu.
- Každý úkol je doplněn nákresem (screenshotem).
- Sbírka úloh na domácí úkol.
- Kniha je psána jasným a jednoduchým jazykem - pro začátečníka.
Tato kniha je vhodná pro ty, kteří již s programováním začali a mají s tímto tématem určité potíže, a pro ty, kteří programují delší dobu, ale nikdy nepracovali s 1C řízenými formuláři.
- Bez složitých technických termínů;
- Více než 600 stran praktického materiálu;
- Každý příklad je doplněn nákresem (snímek obrazovky);
- Kniha je zasílána e-mailem ve formátu PDF. Lze otevřít na jakémkoli zařízení!
Promo kód na 15% slevu - 48PVXHeYu
Pokud vám tato lekce pomohla vyřešit jakýkoli problém, líbila se vám nebo byla užitečná, můžete můj projekt podpořit libovolnou částkou:
Můžete platit ručně:
Yandex.Money – 410012882996301
Web Money – R955262494655
Přidejte se k mým skupinám.
A Data Transfer Object strukturování kódu, řízená forma v prostředí 1C 8.2.
Úvod
Začněme krátkým popisem konceptu „řízené formy“ a souvisejících konceptů platformy 1C. Znalci platforem mohou tuto část přeskočit.V roce 2008 byla k dispozici nová verze platformy 1C: Enterprise 8.2 (dále jen Managed Application), která kompletně mění celou vrstvu práce s rozhraním. To zahrnuje příkazové rozhraní, formuláře a systém oken. Zároveň se mění nejen model vývoje uživatelského rozhraní v konfiguraci, ale je navržena i nová architektura pro oddělení funkčnosti mezi klientskou aplikací a serverem.
Spravovaná aplikace podporuje následující typy klientů:
- Tlustý klient (normální a spravovaný režim spouštění)
- Tenký klient
- Webový klient
Hlavní rozdíly spravovaných formulářů pro vývojáře:
- Deklarativní, nikoli „pixel po pixelu“ popis struktury. Konkrétní umístění prvků provádí systém automaticky při zobrazení formuláře.
- Veškerá funkčnost formuláře je popsána jako podrobnosti A týmy. Podrobnosti jsou data, se kterými formulář pracuje, a příkazy jsou akce, které mají být provedeny.
- Formulář běží na serveru i na klientovi.
- V kontextu klienta jsou téměř všechny typy aplikací nedostupné, a proto není možné měnit data v infobázi.
- Pro každou proměnnou metody nebo formuláře musí být zadána směrnice o kompilaci, definující místo provádění (klient nebo server) a přístup ke kontextu formuláře.
- &OnClient
- &Na serveru
- &OnServerBez kontextu
- &OnClientOnServerWithout Context
Všechny další diskuse se budou týkat pravé strany obrázku, jak strukturovat kód modulu a jaké principy vám umožní implementovat efektivní interakci klient-server.
Pojďme definovat problém
Od doby, kdy se aktivně používá nová verze platformy 1C, uplynulo několik let a společnost 1C i její mnozí partneři vydali mnoho řešení (konfigurací).Vyvinuli vývojáři během této doby společné chápání principů interakce klient-server při vytváření formulářů a změnil se přístup k implementaci softwarových modulů v nové architektonické realitě?
Podívejme se na strukturu kódu (modul formuláře) v několika formách stejné standardní konfigurace a pokusíme se najít vzory.
Strukturou rozumíme části kódu (nejčastěji se jedná o bloky komentářů), které vývojář přiděluje skupinovým metodám a kompilačním direktivám pro tyto metody.
Příklad 1:
Sekce obsluhy událostí Metoda - na klientovi Metoda - na serveru Metoda - na klientovi Sekce servisních procedur a funkcí Pomocné funkce řízení vstupu
Příklad 2:
Servisní postupy a funkce Platební doklady Hodnoty Obsluhy událostí
Příklad 3:
Servisní procedury na serveru Servisní procedury na klientovi Servisní procedury na serveru bez kontextu Obslužné rutiny událostí záhlaví Příkazové obslužné rutiny událostí
Příklad 4:
Univerzální procedury Obsluha událostí formuláře Procedury subsystému „kontaktní informace“.
V podstatě chybí struktura kódu, nebo mírně řečeno, je podobná tomu, co bylo ve formulářích 8.1:
- Neinformativní slova „General, Service, Auxiliary“.
- Nesmělé pokusy oddělit metody klienta a serveru.
- Metody jsou často seskupeny podle prvků rozhraní „Práce s tabulkovou částí Produkty, Kontaktní informace“.
- Libovolné uspořádání metod a kódových skupin. Obslužné rutiny událostí mohou být například v jednom formuláři nahoře, v jiném dole, ve třetím nejsou vůbec zvýrazněny atd.
- A nezapomínejme, že to vše je v rámci jedné konfigurace.
- Ano, existují konfigurace, ve kterých jsou slova „General, Service, Auxiliary“ vždy na stejných místech, ale...
Proč potřebujete strukturu kódu?
- Zjednodušení údržby.
- Zjednodušte učení.
- Zaznamenávání obecných/důležitých/úspěšných zásad.
- ...vaše možnost
Proč nepomáhá stávající vývojový standard od 1C?
Podívejme se na zásady publikované na discích ITS a v různých „Příručkách pro vývojáře...“, které se doporučují při psaní spravovaného formuláře.- Minimalizujte počet volání serveru.
- Maximální výpočetní výkon na serveru.
- Nekontextová volání serveru jsou rychlejší než kontextová.
- Program s ohledem na komunikaci klient-server.
- a tak dále.
Designové vzory nebo generační moudrost
Interakce klient-server se v různých softwarových technologiích používá již desítky let. Odpověď na otázky nastíněné v předchozí části je již dávno známá a je shrnuta do dvou základních principů.- Vzdálená fasáda(dále jen rozhraní pro vzdálený přístup)
- Objekt přenosu dat(dále jen objekt přenosu dat)
- … Každý objekt potenciálně určený pro vzdálený přístup musí mít rozhraní s nízkou granularitou, což minimalizuje počet volání nutných k provedení určité procedury. ... Místo toho, abyste požadovali fakturu a všechny její položky samostatně, musíte číst a aktualizovat všechny položky faktury v jedné žádosti. To ovlivňuje celou strukturu objektu...Pamatujte si: rozhraní vzdáleného přístupu neobsahuje doménovou logiku.
- ...kdybych byla starostlivá matka, určitě bych svému dítěti řekla: "Nikdy nepište objekty přenosu dat!" Ve většině případů nejsou objekty přenosu dat ničím jiným než nafouklý set pole... Hodnota tohoto nechutného monstra spočívá pouze v možnosti přenášet více informací po síti v jednom hovoru- technika, která má velký význam pro distribuované systémy.
Příklady šablon na platformě 1C
Rozhraní pro programování aplikací, které má vývojář k dispozici při vývoji spravovaného formuláře, obsahuje mnoho příkladů těchto principů.Například metoda OpenForm(), typické „drsné“ rozhraní.
OpeningParameters = New Structure("Parametr1, Parametr2, Parametr3", Hodnota1, Hodnota2, Hodnota3); Form = OpenForm(FormName, OpeningParameters);
Porovnejte se stylem přijatým ve verzi 8.1.
Form = GetForm(FormName); Form.Parameter1 = Hodnota1; Form.Parameter2 = Hodnota2; Form.Open();
V kontextu spravovaného formuláře existuje mnoho „objektů přenosu dat“. Můžete si vybrat systémové A definovaný vývojářem.
Systémové modelují aplikační objekt na klientovi ve formě jednoho nebo více formulářových datových prvků. Bez odkazu na detaily formuláře je nelze vytvořit.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureWithCollection
- DataShapesTree
- ValueInFormData()
- FormDataValue()
- CopyFormData()
- ValueInFormAttributes()
- FormAttributesValue()
Příklad 1C v8.1:
// na klientovi v kontextu formuláře FillUserCache(DepartmentLink)
Příklad 1C v8.2:
// na serveru v kontextu formuláře ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");
Objekty přenosu dat, jejichž strukturu určuje vývojář, jsou malou podmnožinou typů dostupných na klientovi i serveru. Jako parametry a výsledky metod „hrubého“ rozhraní se nejčastěji používají následující:
- Primitivní typy (řetězec, číslo, boolean)
- Struktura
- Korespondence
- Pole
- Odkazy na objekty aplikace (jedinečný identifikátor a textová reprezentace)
Funkce &OnServerWithoutContext ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [objednávka][popis chyby] Pro každou objednávku z objednávek cyklus StartTransaction(); Zkuste DocOb = Order.GetObject(); …. další akce, možné nejen s objednávkou... Výjimka CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndPokus; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()
Strukturování kódu
Hlavní cíle, které by měl modul spravovaného formuláře odrážet, a přístupy k řešení.- Jasné oddělení kódu klienta a serveru. Nezapomínejme, že v okamžiku realizace se jedná o dva vzájemně se ovlivňující procesy, z nichž každý má výrazně odlišnou dostupnou funkcionalitu.
- Jasná identifikace rozhraní vzdáleného přístupu, které serverové metody lze volat z klienta a které ne? Názvy metod vzdáleného rozhraní začínají předponou "Server". To vám umožní okamžitě vidět přenos řízení na server při čtení kódu a zjednoduší použití kontextové nápovědy. Všimněte si, že oficiální doporučení (ITS) navrhuje metody pojmenování s postfixy, například ChangeOrderStatusOnServer(). Zopakujme však, že ne všechny serverové metody lze volat z klienta, a proto je důležitější logická dostupnost než umístění kompilace. Předponou „Server“ tedy označujeme pouze metody dostupné klientovi, zavolejte příkladovou metodu ServerChangeOrderStatus().
- Čitelnost. Věc vkusu, objednávku přijímáme, když modul začíná procedurami pro vytvoření formuláře na serveru a metodami vzdáleného přístupu.
- Udržitelnost. Musí existovat jasné místo pro přidání nového kódu. Důležitým bodem je, že šablony metod automaticky vytvořené konfigurátorem jsou přidány na konec modulu. Vzhledem k tomu, že obslužné rutiny událostí pro prvky formuláře jsou nejčastěji vytvářeny automaticky, je příslušný blok umístěn jako poslední, aby nedošlo k přetažení jednotlivých obslužných rutin na jiné místo v modulu.
- Grafická možnost – jasně ukazuje hlavní tok provádění.
- Možnost text je příkladem návrhu šablony pro rychlé vložení struktury do nového modulu formuláře.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datum =""/> // <Описание> // // ///////////////////////////////////////////////// ///////////////////////////// PROMĚNNÉ MODULU //////////////////// ///////////////////////////////////////////////// ////////// // NA SERVERU //******* UDÁLOSTI NA SERVERU ******* &Na serveru Postup při vytvoření na serveru (selhání, standardní zpracování) / /Vložit obsah handleru Konec procedury //******* ROZHRANÍ PRO VZDÁLENÝ PŘÍSTUP ******* //******* OBCHODNÍ LOGIKA NA SERVERU ******* ///////// ///////////////////////////////////////// /////// ///////////////////// BĚŽNÉ METODY KLIENTA A SERVERU /////////////// /////// /////////////////////////////////////////// ///// //////// // NA KLIENTOVI //******* OBCHODNÍ LOGIKA NA KLIENTOVI ******* //******* TÝM * ****** //******* KLIENTSKÉ AKCE ******* ////////////////////////// ///// ///////////////////////////////////////////// // / / HLAVNÍ OPERÁTORY PROGRAMU
Související otázky
Na závěr nastíníme několik oblastí, na které je užitečné myslet při programování interakce klient-server.- Možnosti implementace rozhraní vzdáleného přístupu. Asynchronie, úroveň detailů...
- Ukládání do mezipaměti. 1C učinil neúspěšné architektonické rozhodnutí, zavedl ukládání do mezipaměti pouze na úrovni metod volání běžných modulů a neposkytoval možnosti ovládání (čas relevance, reset na vyžádání).
- Implicitní volání serveru. Nezapomeňte na technologické vlastnosti, mnoho „neškodných“ operací na klientovi vyprovokuje platformu ke kontaktu se serverem.
