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 byl zpřístupněn novou verzi platforma 1C: Enterprise 8.2 (dále jen Managed Application), která zcela 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

Spravovaná aplikace používá formuláře postavené na nová technologie. Jmenují se Spravované formuláře. Pro usnadnění přechodu jsou podporovány i předchozí formuláře (tzv. Regular Forms), ale jejich funkčnost není vyvinuta a jsou dostupné pouze v režimu spouštění tlustého klienta.
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.

Uveďme si direktivy pro kompilaci formulářových metod:

• &OnClient
• &Na serveru
• &OnServerBez kontextu
• &OnClientOnServerWithout Context

Pojďme ilustrovat výše uvedené. Snímek obrazovky ukazuje příklad spravovaného formuláře a jeho modulu ve vývojovém režimu. Najděte deklarativní popis, rekvizity, pokyny pro kompilaci atd.

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í).
Vytvořili si 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ých architektonických realitách?

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.

Jsou to slogany, které jsou naprosto pravdivé, ale jak je realizovat? Jak minimalizovat počet hovorů, co to znamená programovat v režimu klient-server?

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)

Slovo Martina Fowlera, jeho popis těchto principů:

• … Každý objekt potenciálně určený pro vzdálený přístup musí mít rozhraní s nízkou granularitou, což minimalizuje počet hovorů potřebných k provedení konkrétního postupu. ... 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

Konverze objektů přenosu systémových dat na typy aplikací a naopak se provádí pomocí následujících metod:

• ValueInFormData()
• FormDataValue()
• CopyFormData()
• ValueInFormAttributes()
• FormAttributesValue()

Explicitní konverze se často používá při úpravě stávajícího řešení. Metody mohou očekávat (používat funkce) vstupní parametry, jako je ValueTable spíše než FormDataCollection, nebo byla metoda definována v kontextu objektu aplikace a stala se nedostupnou pro přímé volání z formuláře.
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)

Příklad: metoda přijme seznam příkazů ke změně stavu a vrátí klientovi popis chyb.
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(). Opakujeme 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, které má klient k dispozici, zavolejte příkladovou metodu ServerChangeOrderStatus().
• Čitelnost. Věc vkusu, objednávku přijímáme, když modul začíná s 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ý bodŠ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.

Níže je uvedena základní struktura modulu, který implementuje uvedené cíle.

• Grafická možnost – jasně ukazuje hlavní tok provádění.
• Textová verze je příkladem návrhu šablony pro rychlé vložení struktur 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.

11.12.2016

O spravovaných formulářích 1C (Start)

Tenký klient

Tenčí už to být nemůže. Klientská aplikace nyní neprovádí dotazy do databáze (toto je záležitost serveru). Klientská aplikace jednoduše zobrazí rozhraní a data.

Stojí za zmínku, že struktura kódu se díky takovým transformacím stala složitější. Na klientovi nejsou žádné reference, objekty, tabulky hodnot... k dispozici jsou pouze primitivní typy (řetězec, datum, boolean, pole, struktura...). To znamená, že programátor nyní musí přemýšlet o tom, co na server dostat a jak to udělat s minimálními náklady.

Interakce klient-server

Nový přístup k interakci mezi klientem a serverem nám umožnil vytvořit nový model uživatelského rozhraní. Nyní je rozhraní deklarováno (!) Návrh rozhraní začíná daty, detaily a tabulkovými částmi. Při vytváření rekvizity musíte myslet na to, jak bude vypadat v rozhraní, zda bude povinná, jak je propojena s dalšími detaily...

Nedostatek kontextu (stavu) na serveru

Server 1C funguje na „bezstavovém“ principu. To znamená, že server pouze odpovídá na požadavky a v intervalu mezi dvěma požadavky nic neukládá (pro tyto účely existuje dočasné úložiště).

FormDataValue, FormDataCollection, FormData...

Kontaktovali jsme server, udělal vše za nás, smazal data a zapomněl, že jsme přišli. Všechny objekty s názvem "FormData" + "cokoliv" nám pomohou uložit naše data mezi dvěma voláními serveru.

Dočasné úložiště

Dočasné úložiště je speciální místo, do kterého (kromě podrobností formuláře) můžete uložit stav na serveru. Úložiště může ukládat data, která nejsou dostupná na klientovi (tj. která nelze umístit do detailů formuláře).

Chcete-li pracovat s dočasným úložištěm, použijte metody PlaceInTemporaryStorage() Syntaxe: PlaceInTemporaryStorage(<Данные>, <Адрес>) Popis: Uloží serializovatelnou hodnotu do dočasného úložiště. Dostupnost: Tenký klient, webový klient, server, tlustý klient, externí připojení, mobilní aplikace (klient), mobilní aplikace (server). Volání metody provede volání serveru.<Адрес>(nepovinné) Typ: UniqueIdentifier; Čára. Jedinečný identifikátor formuláře, do jehož dočasného úložiště mají být data umístěna a vrácena nová adresa. Nebo adresu v dočasném úložišti, kam mají být data umístěna. Adresa musí být získána dříve pomocí této metody. Pokud je předáno jedinečné ID formuláře nebo adresa úložiště, hodnota se po zavření tohoto formuláře automaticky smaže. Pokud je předán UniqueIdentifier, který není jedinečným identifikátorem formuláře, bude hodnota po skončení relace uživatele odstraněna. Pokud parametr není zadán, umístěná hodnota bude odstraněna po dalším požadavku serveru ze společného modulu, během kontextového a nekontextového volání serveru z formuláře, během volání serveru z příkazového modulu nebo když je formulář přijaté. Poznámka: Dočasné úložiště vytvořené v jedné relaci není přístupné z jiné relace. Výjimkou je možnost přenést data z úlohy na pozadí do relace, která iniciovala úlohu na pozadí, pomocí dočasného úložiště. Chcete-li to provést, měli byste umístit prázdnou hodnotu do dočasného úložiště v nadřazené relaci a předat identifikátor formuláře. Poté předejte přijatou adresu úloze na pozadí prostřednictvím parametrů úlohy na pozadí. Dále, pokud je tato adresa použita v parametru<Адрес>, pak bude výsledek zkopírován do relace, ze které byla spuštěna úloha na pozadí. Data umístěná v dočasném úložišti v úloze na pozadí nebudou z nadřazené relace dostupná, dokud nebude úloha na pozadí dokončena. a GetFromTemporaryStorage() Syntaxe: GetFromTemporaryStorage(<Адрес>) Popis: Načte hodnotu z dočasného úložiště. Dostupnost: Tenký klient, webový klient, server, tlustý klient, externí připojení, mobilní aplikace (klient), mobilní aplikace (server). Volání metody provede volání serveru. Poznámka: Výsledek provedení se neukládá do mezipaměti, server je volán při každém volání metody.

Kód volajícího serveru

Kdykoli zavoláte kód serveru, přenášená data jsou vždy serializována. Všechny parametry jsou zabaleny ve formě řetězce a přenášeny po síti. Výsledek práce je také zaslán zpět v serializované podobě, kde je poté restaurován do známých objektů.

Účel příznaků modulu

• Příznak označuje, kde bude kód modulu zkompilován (na serveru, na klientovi, v externím připojení)
• Pokud je modul zkompilován na více místech, pak bude viditelný pouze podle příznaků
• Přenos spuštění kódu je možný pouze v případě, že v aktuálním kontextu provádění není žádný volaný modul, ale existuje na jiném místě (pokud je modul pouze na serveru a ne na klientovi, provede se volání na server)

Příznak "volání serveru".

Počínaje platformou 1C:Enterprise 8.2 byl přidán příznak „volání serveru“. Což jen pomáhá „urovnat“ podmínky pro přechod na jiný stroj. Pokud modulu přiřadíte tento příznak, modul bude viditelný z klienta, pokud ne, pokus o jeho volání z klienta bude mít za následek chybu. Kód modulu nebude viditelný, jako by vůbec neexistoval.

V běžném tlustém klientovi tedy můžete přenést kód na server pouze tehdy, když z klienta zavoláte společný modul, pro který:

• Zaškrtávací políčko serveru zaškrtnuto
• Zaškrtnuto políčko „Call server“.
• Všechna zaškrtávací políčka „klient“ jsou zrušena

S příchodem platformy 1C Enterprise 8.2 se výrazně změnil mechanismus vývoje uživatelského rozhraní. Bylo možné vytvářet spravované formuláře a aplikace (obrázek 1).

Obrázek 1

Dále je navržen nový systém pro rozdělení funkčnosti mezi klientskou aplikaci a server.
Spravovaná aplikace podporuje následující typy klientů:

• Tlustý klient (normální a spravovaný režim spouštění),
• tenký klient,
• Webový klient.

Mechanismus vytváření spravovaných formulářů se výrazně liší od konvenčních. Spravované formuláře se v první řadě vyznačují tím, že je vytváří systém automaticky na základě speciálního nastavení, programátor nyní nemusí každý formulář podrobně rozkreslovat. Veškerá funkčnost formuláře je popsána formou detailů a příkazů. Podrobnosti jsou data, se kterými formulář pracuje, a příkazy jsou akce, které mají být provedeny. Pro každou proměnnou metody nebo formuláře musí být zadána direktiva kompilace, která určuje umístění provádění (klient nebo server). Příkazy kompilace mohou být následující:

• &OnClient,
• &Na serveru,
• &OnServerWithoutContext,
• &OnClientOnServerWithoutContext.

Spravovaný formulář se od běžného formuláře liší také typy dat, se kterými pracuje. Pokud normální forma funguje s většinou typů, které 1C: Enterprise poskytuje (včetně typů DirectoryObject, DocumentObject atd.), lze ve spravované formě 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.

Fungování řízených formulářů má následující charakteristické rysy (obrázek 2):

• Formulář existuje na klientovi i na serveru.

Provádí interakci klient-server (přenos dat a návrhových vlastností prvků).

• Formulář nefunguje s objekty aplikace

Obrázek 2

Formulář využívá speciální univerzální objekty
DataForms(Obrázek 3).


Obrázek 3

Aplikační objekty fungují pouze na serveru a pouze během provádění určitých operací.
Při otevření formuláře:

• Objekt je načten z databáze,
• Objekt se převede na data formuláře,
• Objekt je odstraněn (z paměti),
• Data formuláře jsou odeslána klientovi.

Při nahrávání:

• Údaje formuláře jsou získávány od klienta,
• Data formuláře se převedou na objekt,
• Objekt je zapsán do databáze,
• Objekt je odstraněn (z paměti).

V minulé lekci jsme se na to podívali pro běžného (tlustého) klienta. Ve verzi platformy 1C 8.2. Používají nové obrazovkové formuláře 1C 8.2. Nazývají se řízené formuláře 1C 8.2.

Spravované formuláře 1C 8.2 jsou budoucností 1C. Od běžných formulářů 1C 8.2 se liší tím, že jsou generovány automaticky systémem na základě speciálního nastavení („běžné“ formuláře jednoduše nakreslí programátor podle libosti).

Rozdíly ve vývoji řízených forem 1C 8.2 od konvenčních jsou značné. Proto jsme se dnes sešli, abychom samostatně diskutovali o vytváření a úpravách spravovaných formulářů 1C 8.2.

Spravované formuláře 1C 8.2

Pokud jste již dříve vyvíjeli konfigurace 1C, při otevření editoru spravovaných formulářů 1C 8.2 vás okamžitě napadne, že formulář 1C 8.2 nelze myší vůbec ovlivnit.

Nemůžete změnit formulář 1C 8.2, nemůžete přesunout prvek, nemůžete ani zobrazit vlastnosti pole jako dříve - dvojitým kliknutím na pole ve formuláři 1C 8.2.

Nyní základem pro vývoj formuláře 1C 8.2 není vazba polí na souřadnice na formuláři, ale speciální nastavení. Systém na základě těchto nastavení automaticky vygeneruje řízený formulář 1C 8.2.

Nastavení se skládá ze seznamu prvků formuláře 1C 8.2 umístěných v editoru v levém horním rohu. Mezi prvky formuláře 1C 8.2 patří:

• Náležitosti
• Příkazy (nový koncept v 1C 8.2, může vypadat jako tlačítka nebo položky nabídky)
• Skupiny (pro kombinování detailů a příkazů).

Nastavení těchto prvků tedy není ve vlastnostech polí, ale ve vlastnostech těchto prvků nastavení (nabídka po kliknutí pravým tlačítkem, položka Vlastnosti).

Jak fungují spravované formuláře 1C 8.2

Práce se spravovanými formuláři 1C 8.2 je pro uživatele odlišná. Mají více schopností, ale jsou neobvyklé pro ty, kteří s 1C pracují dlouhou dobu.

Za prvé, uspořádání obvyklých prvků na formuláři 1C 8.2 je odlišné. Panel příkazů je vždy nahoře.

Levá strana příkazového panelu je přizpůsobitelná. Obvykle obsahuje taková standardní tlačítka jako Record a Post.

Pravá strana příkazového panelu je nová standardní nabídka formuláře 1C Všechny akce. Tato nabídka umožňuje spravovat formulář 1C 8.2 dle libosti, podobně jako v sestavě ACS umožňuje nastavení výrazně změnit vzhled sestavy.

Libovolné položky nabídky 1C Všechny akce

V závislosti na tom, zda tento formulář 1C 8.1 patří k jednomu nebo druhému, je nabídka naplněna položkami, které vám umožňují spravovat tento objekt. Pokud se například jedná o formulář seznamu adresářů, budou zde příkazy jako Vytvořit nebo Upravit.

Položka Přizpůsobit seznam nabídky 1C Všechny akce

Pokud existuje seznam ve formuláři 1C 8.2, pak nabídka obsahuje příkazy Konfigurovat seznam a Zobrazit seznam.
Pokud je vám příkaz Output list již známý - umožňuje vám uložit libovolný seznam v 1C v Excelu / vytisknout, pak je druhý příkaz nový.

Jak jste si již všimli, na panelu příkazů seznamu již nejsou žádná tlačítka pro výběr. Místo něj se objevilo tlačítko Najít, k jehož fungování (stejně jako k aktuálně zakázanému umístění kurzoru v seznamu při psaní) má určité výtky.

Funkce tlačítka Najít samozřejmě není srovnatelná s výběry, ale nezmizely!
Nyní se nacházejí v položce nabídky Přizpůsobit seznam. Výběr lze nyní provádět pomocí libovolného pole a kromě něj můžete provádět třídění a podmíněné formátování stejným způsobem, jako to děláte v sestavách ACS.

Položka Změnit tvar nabídky 1C Všechny akce

Položka Změnit formulář umožňuje podobně změnit nejen seznam na formuláři 1C 8.2, ale i samotný formulář 1C 8.2.

Uživatel může nezávisle povolit nebo zakázat viditelnost polí ve formuláři 1C 8.2, šířku a výšku, aktivaci výchozího pole při otevření atd.

Použití spravovaných formulářů 1C 8.2 a běžných formulářů 1C

Ve výchozím nastavení se běžné formuláře 1C používají v konfiguracích pro tlustého (běžného) klienta 1C a spravované formuláře se používají v konfiguracích pro tenké a webové klienty 1C. Obě formy 1C však lze použít v jakékoli konfiguraci, včetně současné.

K tomu je potřeba zadat konfigurační vlastnosti (horní prvek v konfiguračním okně).

Ve vlastnostech konfigurace v 1C 8.2 se objevila dvě nová zaškrtávací políčka, která umožňují povolit nestandardní použití formulářů 1C.

Vytváření spravovaných formulářů 8.2

Přidání nového formuláře 1C 8.2 se provádí stejným způsobem jako dříve - pomocí tlačítka Ins na klávesnici nebo tlačítka Přidat. Chcete-li zadat existující, dvakrát na něj klikněte myší.

Ve výchozím nastavení se vytvoří formulář (běžný nebo spravovaný), který je nainstalován v konfiguraci (viz vlastnost Main launch mode ve vlastnostech konfigurace. Pokud jste v konfiguraci povolili oprávnění používat oba typy formulářů - v návrháři formulářů , který se okamžitě otevře - můžete vybrat typy formulářů.

Návrhář vás vyzve k výběru typu formuláře - formulář prvku, formulář seznamu. Zde můžete přidat nebo odebrat příkazové panely ve formuláři. Nejčastěji jsou tato nastavení ve výchozím nastavení ponechána tak, jak jsou.

Otevře se formulář, ve výchozím nastavení vyplněný – byly do něj přidány všechny podrobnosti o objektu 1C, které existují. Konkrétní seznam povinných polí můžete zaškrtnout na druhé záložce návrháře.

Editor formulářů se skládá ze tří částí.

• V levém horním rohu je seznam prvků formuláře. Skládá se z polí, příkazů a skupin, které umožňují kombinovat prvky. Seznam příkazů lze zobrazit samostatně na kartě Příkazové rozhraní.
• V pravém horním rohu je seznam dostupných detailů formuláře a detailů objektu (otevřete křížek u atributu Objekt).
• Níže je náhled výsledného formuláře.

Dostupné podrobnosti můžete přetáhnout doleva a stanou se prvkem formuláře (pole ve formuláři).

Pokud potřebujete přidat tlačítko nebo položku nabídky, na pravé straně karty Příkazy musíte vytvořit nový příkaz. Toto je obal pro funkci v modulu formuláře. Kromě určení, která funkce bude volána, můžete přiřadit reprezentaci - například obrázek a také závislost viditelnosti na funkční volbě.

Příkazy se také přetahují doleva. Pokud je nadřazený panel příkazů, pak to bude tlačítko příkazového řádku - jinak jen tlačítko.

Atributy objektu/formuláře můžete do seznamu prvků formuláře (polí) nejen přetahovat, ale také jednoduše přidávat (tlačítko Přidat nebo Vložit). Zejména můžete vytvořit nový objekt formuláře – Skupina.

Skupinou může být příkazový panel (kurzor musí být na řádku formuláře). Poté do něj přetáhnete příkazy a stanou se tlačítky.

Skupina může být „běžná“. Pak se jedná o způsob seskupování polí vertikálně i horizontálně. Název skupiny lze odstranit ve vlastnostech.

Skupinou může být panel (stránka). Nejvyšší přidanou skupinou je panel a vnořené skupiny tohoto typu jsou stránky. Pole jsou již přetažena na stránky.

Nepotřebné prvky formuláře se odstraní odstraněním prvků formuláře v seznamu.
Poloha pole na formuláři je určena pořadím v seznamu prvků (vertikálně) nebo pomocí skupin (horizontální). Šířka a výška se nastavují ve vlastnostech prvku formuláře.

Vlastnosti formulářových prvků byly výrazně rozšířeny a obsahují mnoho užitečných věcí – jak ovládání vzhledu (tlačítka pro výběr a smazání), tak kontrolu výchozích hodnot.

Vlastnosti samotného formuláře včetně jeho rozměrů se nastavují v kořenovém prvku formuláře se stejnojmenným názvem Form.

Obslužné rutiny událostí (odpovědi na akce uživatele) jsou nyní rozděleny do dvou typů. Staré – stejně jako dříve jsou uvedeny ve vlastnostech formuláře a polí (například OnChange a OnOpening formuláře). Nové se staly příkazy a používají se pro položky nabídky a tlačítka.

S verzí 8.2 platformy v 1C se začaly používat nové principy pro konstrukci rozhraní a interakci uživatele s databází. Nová technologie se nazývá „Managed Application“. Největším zpracováním prošly mechanismy pro vytváření formulářů a schéma interakce mezi uživatelem serveru 1C a databází. Normální režim je platformou stále podporován, ale postupem času všichni uživatelé 1C přejdou na spravované formuláře.

Pro běžné uživatele se spravovaná podoba 1C dokumentu od běžné liší pouze vzhledem. Pro vývojáře je to nový mechanismus s vlastními pravidly, zákony a podmínkami. Mnoho oblastí prošlo změnami, ale následující inovace jsou mezi zkušenými vývojáři 1C považovány za klíčové:

• Samostatné vytváření struktury formuláře a umístění polí platformou. Jestliže dřívější vývojáři popisovali polohu pole určením pixelů, nyní je možné určit pouze typ seskupení;
• Formulář se skládá z detailů reprezentujících data formuláře a příkazů - procedur a funkcí, které mají být provedeny;
• Kód formuláře se spouští na straně serveru i klienta. Koneckonců, samotný formulář je konfigurační objekt vytvořený na serveru a zobrazený na klientovi. To znamená, že kombinuje klientskou a serverovou část;
• Na straně klienta se stalo mnoho typů dat nedostupných a nyní není možné data v infobázi měnit;
• Pro každou proceduru nebo funkci musí být specifikováno speciální nastavení - kompilační direktiva. Je zodpovědný za to, kde je kód spuštěn, a může nabývat následujících hodnot:
  • Naklient;
  • Na serveru;
  • OnServerWithoutContext;
  • OnClientOnServer;
  • Na klientovi Na serveru bez kontextu.

Poslední bod je obzvláště aktuální v režimu spravovaných formulářů. Pokud vývojář málo rozumí direktivám nebo interakcím klient-server, pak pro něj bude extrémně obtížné vytvořit spravovaný formulář. Všechny nové principy pro vytváření spravovaných formulářů v 1C:Enterprise 8.3 jsou sjednoceny obecným konceptem třívrstvé architektury. Zahrnuje klientské počítače, 1C server a DBMS, kde jsou data uložena.

Změnila se také úprava spravovaného formuláře v konfigurátoru. Mnoho aspektů se změnilo a vývojáři verze 7.7, kteří neměli spravované formuláře, mohou být překvapeni. Změnil se dokonce i vzhled návrháře formulářů, což lze vidět otevřením libovolného formuláře konfiguračního objektu. Při otevření objektu vidíme okno rozdělené do několika částí:

1. Prvky rozhraní formuláře. Vlevo nahoře je okno se seznamem všech polí zobrazených na vybraném formuláři, která zajišťují interakci programu s uživatelem;
2. Podrobnosti formuláře. Vpravo nahoře jsou všechna data, se kterými formulář pracuje. Jsou tam, kde jsou informace uloženy na straně klienta;
3. Zobrazit spravovaný formulář. Níže vidíme předběžný vzhled založený na prvcích rozhraní;
4. Modul formuláře. Část obsahující postupy a funkce používané tímto formulářem. Zde naleznete kód pro algoritmy pro interakci programu s uživatelem i databází.

Vývojáři 1C nabádají klienty, aby přešli na spravované formuláře, takže naučit se principy vývoje spravovaných formulářů je otázkou času. Jakmile s tímto typem formuláře začnete pracovat, uvědomíte si, že jde o krok ke standardizaci vývoje a dodržování jednotných pravidel. Proto schopnost pracovat se spravovanými formuláři v 1C 8.3 zvyšuje vaši úroveň vývojáře 1C.

Principy návrhu řízených formulářů

Nejprve, abyste pochopili mechanismus spravovaného režimu 1C, měli byste si uvědomit, že formulář existuje na serveru i na klientovi. Navíc na klientovi je tento objekt pouze obrazem rozhraní pro interakci uživatele s programem. Veškeré výpočty, algoritmy, výpočty a zpracování musí probíhat pouze na straně serveru. To je dáno nejen nemožností použití mnoha funkcí a parametrů na klientovi, ale také požadavky na výkon.

Kde se procedura provádí, zjistíte podle názvu direktivy, který musí být zapsán před každou procedurou a funkcí v modulu formuláře. Formulace „Bez kontextu“ znamená, že data na spravovaném formuláři nebudou předána této proceduře na serveru. V takových postupech tedy nebude možné zapisovat algoritmy založené na hodnotách zadaných uživatelem. Pokud toto znění není uvedeno, je formulář předán celý se všemi podrobnostmi a vy k nim budete mít přístup.

Vývojáři 1C důrazně doporučují používat nekontextová volání serveru, co nejvíce snížit jejich počet a snažit se neprovádět výpočty na klientovi. Pro začínající vývojáře bez teoretického vzdělání je obtížné dodržet všechna tato pravidla a správně změnit kód. Než začnete pracovat sami, bude užitečné otevřít formulář pro spravovanou konfiguraci a podívat se na syntaxi a na to, jak klient a server spolupracují.

&Na serveru Procedura Příjem dokumentů o platbě a vypořádání z úložiště (nová adresa v úložišti) &Na serveru bez kontextu Funkce je výpočty s klientem (DocumentBase) &Na serveru Bez kontextové procedury Vyplňte seznam pro výběr kontrolních bodů (Seznam výběru, Protistrana, Informace Datum) &Na proceduře klienta Vyplňte Head CounterpartyCompletion(SelectedValue, Additional Parameters) &Na serveru procedura SetText of Payment and Settlement Documents() &Na serveru Funkce IsFilledInitialDocuments()

Nová pravidla pro vývoj formulářů 1C budou velkým přínosem, pokud je budou všichni vývojáři dodržovat. Změny k lepšímu navíc pocítí všichni – programátoři, společnosti pracující v 1C, franšízanti i vývojáři 1C. Hlavní důsledky správného používání spravovaných formulářů v 1C:

1. Snadná údržba konfigurace a zvýšená čitelnost kódu. Z toho můžeme usoudit, že algoritmus napsaný jedním vývojářem může být vždy opraven jiným zaměstnancem, aniž by strávil spoustu času;
2. Oddělení kódu běžícího na klientovi a serveru. Vzhledem k tomu, jak rozdílné jsou funkce dostupné na každé z těchto stran, bylo by jejich oddělení správným krokem;
3. Hlubší pochopení logiky platformy, interakcí klient-server a algoritmů, které píší, vývojáři. Ve verzích 8.0 a dřívějších bylo velmi běžné najít formy dokumentů nebo referenčních knih vytvořených bez porozumění části klient-server;
4. Zvýšení výkonu konfigurací a snížení zatížení klientských počítačů;
5. Snížení nákladů na nákup počítačů na pracoviště díky absenci nutnosti nákupu výkonných PC.

Výběr spravovaného formuláře jako hlavního spouštěcího režimu 1C může přinést mnohá překvapení. Ale se správným přístupem tento krok přinese velké dividendy, a proto se ho stále více uživatelů 1C v celém Rusku rozhoduje. Vzhledem k tomu, že společnost 1C do budoucna počítá s vývojem řízených forem, je riskantní setrvávat u zastaralých konvenčních.