Základné detaily formulára. Podrobnosti spravovaného formulára (1Cv8) Spravované formuláre 1c pridávajú podrobnosti programovo
Podrobnosti formulára
Sada podrobností formulára popisuje zloženie údajov, ktoré sú zobrazené, upravované alebo uložené vo formulári. Samotné detaily formulára zároveň neposkytujú možnosť zobrazenia a úpravy údajov. Prvky formulára (pozri časť „Prvky formulára“ v tejto kapitole) spojené s podrobnosťami formulára sa používajú na zobrazenie a úpravu. Súbor všetkých podrobností formulára sa bude nazývať údaje formulára.
Dôležité! Je potrebné mať na pamäti, že na rozdiel od bežných formulárov musia byť všetky údaje v riadenej forme popísané vo forme podrobností. Nie je dovolené používať premenné modulu formulára ako zdroje údajov pre prvky formulára.
Je možné priradiť Základné detaily formulára, teda atribúty, ktoré budú určovať štandardnú funkčnosť formulára (rozšírenie formulára). Malo by sa pamätať na to, že formulár môže mať iba jeden hlavný atribút.
Rozšírenie formulára– ide o dodatočné vlastnosti, metódy a parametre formulára objektu ManagedForm, charakteristické pre objekt, ktorý je hlavným prvkom formulára.
Počas procesu vývoja formulára môžete explicitne nastaviť možnosť zobrazenia a úpravy konkrétnych podrobností formulára, pokiaľ ide o roly, pomocou vlastností Zobraziť a Upraviť (ďalšie podrobnosti nájdete v časti „Nastavenia formulára na základe rolí“ v časti „Editory kapitola). Dostupnosť konkrétneho atribútu v samotnom formulári je navyše možné konfigurovať pomocou funkčných možností (viac podrobností o funkčných možnostiach nájdete v kapitole „Správa konfiguračného rozhrania“).
Vlastnosť atribútu formulára Uložené dáta je znakom toho, že interaktívna zmena detailov povedie k pokusu o zablokovanie údajov formulára na úpravu, ako aj k automatickému nastaveniu príznaku úpravy formulára.
Dátové typy dostupné v spravovanom formulári
Spravovaný formulár sa od bežného formulára líši aj typmi údajov, s ktorými pracuje. Ak normálna forma funguje s väčšinou typov, ktoré poskytuje 1C:Enterprise (vrátane typov DirectoryObject, DocumentObject atď.), potom v riadenej forme možno rozlíšiť nasledujúce kategórie typov:
- typy, ktoré sa priamo používajú vo formulári, sú typy, ktoré existujú na strane tenkého a webového klienta (napríklad Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
- typy, ktoré sa skonvertujú na špeciálne typy údajov – typy údajov spravovaných formulárov. Takéto typy sú zobrazené v zozname podrobností formulára v zátvorkách, napríklad (DirectoryObject.Products);
- dynamický zoznam (ďalšie podrobnosti nájdete v časti „Dynamický zoznam“ v tejto kapitole).
Konverzia aplikačných objektov na údaje formulára
Niektoré typy aplikácií (napríklad DirectoryObject atď.) neexistujú na strane tenkého a webového klienta (ďalšie podrobnosti nájdete v kapitole Koncepcia riadenej aplikácie). Preto na reprezentáciu takýchto typov aplikácií vo formulári platforma zaviedla špeciálne dátové typy určené na prácu v riadených formulároch. Táto funkcia riadenej aplikácie si vyžaduje konverziu objektov aplikácie na údaje formulára (a naopak).
Používajú sa nasledujúce typy údajov:
- Form DataStructure – obsahuje množinu vlastností ľubovoľného typu. Vlastnosti môžu byť iné štruktúry, kolekcie alebo štruktúry s kolekciami. Tento typ je reprezentovaný napríklad vo forme DirectoryObject.
- FormDataCollection je zoznam napísaných hodnôt, podobne ako pole. K prvku kolekcie sa pristupuje pomocou indexu alebo identifikátora. Prístup podľa ID nemusí byť v niektorých prípadoch k dispozícii. Je to kvôli typu aplikačného objektu, ktorý predstavuje táto kolekcia. Identifikátor môže byť ľubovoľné celé číslo. Tento typ je zastúpený napríklad vo forme tabuľkovej časti.
- Form DataStructureWithCollection je objekt, ktorý je reprezentovaný ako štruktúra a kolekcia súčasne. Dá sa s ňou zaobchádzať ako s ktoroukoľvek z týchto entít. Tento typ predstavuje napríklad množinu záznamov vo formulári.
- Form DataTree – objekt určený na ukladanie hierarchických údajov.
Aplikačný objekt je reprezentovaný jedným alebo viacerými dátovými prvkami formulára. Vo všeobecnosti hierarchia a zloženie údajov formulára závisí od zložitosti a prepojenia aplikačných objektov riadeného formulára.
Napríklad dokument obsahujúci tabuľkovú časť bude reprezentovaný objektom typu FormDataStructure (samotný dokument), ktorému je podriadený objekt typu FormDataCollection (tabuľková časť dokumentu).
Dôležité! Pri vývoji konfigurácie je dôležité pamätať na to, že aplikačné objekty sú dostupné iba na serveri, zatiaľ čo dátové objekty formulára je možné použiť na serveri aj na klientovi.
Odovzdávanie údajov medzi klientskou a serverovou časťou spravovaného formulára
V skutočnosti môžeme povedať, že údaje formulára sú jednotnou reprezentáciou údajov z rôznych aplikačných objektov, s ktorými formulár pracuje jednotne a ktoré sú prítomné na serveri aj na klientovi. To znamená, že formulár obsahuje určitú „projekciu“ údajov objektu aplikácie vo forme vlastných dátových typov a v prípade potreby medzi nimi vykonáva konverziu. Ak však vývojár konfigurácie implementuje svoj vlastný algoritmus spracovania údajov, musí konverziu údajov (zo špecializovaných typov na typy aplikácií a naopak) vykonávať nezávisle.
Pri úprave detailov formulára v špecializovanom editore (podrobnejšie v časti „Podrobnosti formulára“ v kapitole „Editory“) je možné ovplyvniť prenos údajov medzi klientom a serverom počas behu formulára. Na to slúži stĺpec editora podrobností. Vždy používajte. Účinok tejto vlastnosti sa líši pre tri typy atribútov:
- Pre atribút podriadený dynamickému zoznamu (stĺpec dynamického zoznamu):
- vlastnosť povolená – atribút je vždy načítaný z databázy a zahrnutý do údajov formulára;
- vlastnosť je zakázaná - atribút sa načíta z databázy a zahrnie do údajov formulára iba vtedy, keď je k atribútu alebo jeho podriadenému atribútu priradený aktuálne viditeľný prvok formulára.
- Pre rekvizity podriadené kolekcii pohybu:
- vlastnosť je povolená – pohyby dokladov sa načítajú z databázy a budú prítomné v údajoch formulára;
- vlastnosť je zakázaná - pohyby dokladov sa nebudú čítať z databázy a nebudú zahrnuté do údajov formulára (ak neexistuje prvok formulára, ktorý odkazuje na pohyby dokladov).
- Ďalšie podrobnosti formulára:
- vlastnosť je povolená – atribút bude prítomný v údajoch formulára bez ohľadu na to, či existuje alebo nie je aspoň jeden prvok formulára, ktorý je spojený s atribútom alebo jeho podriadeným atribútom;
- vlastnosť je zakázaná - atribút bude prítomný v údajoch formulára iba vtedy, ak je k atribútu alebo jeho podriadenému atribútu priradený prvok formulára. Na rozdiel od atribútov dynamického zoznamu tu nezáleží na viditeľnosti prvku spojeného s atribútom.
Poznámka. Malo by sa pamätať na to, že vlastnosť nastavená na nadradenom atribúte ovplyvňuje všetky podriadené atribúty. Napríklad, ak je vlastnosť Použiť vždy vymazaná pre tabuľkovú časť dokumentu, potom systém usúdi, že táto vlastnosť je vymazaná aj pre všetky podriadené podrobnosti (napriek skutočnému stavu vlastnosti).
Metódy na konverziu údajov objektu aplikácie na údaje formulára
Na konverziu objektov aplikácie na údaje formulára a späť existuje súbor globálnych metód:
- ValueInFormData(),
- FormDataInValue(),
- CopyFormData().
Dôležité! Metódy, ktoré pracujú s aplikačnými objektmi, sú dostupné len v serverových procedúrach. Metóda kopírovania hodnôt medzi údajmi formulára je dostupná na serveri a na klientovi, pretože nevyžaduje aplikačné objekty ako parametre.
Pri konverzii údajov formulára na objekt aplikácie musíte zvážiť ich kompatibilitu.
- ValueInFormData() – konvertuje objekt typu aplikácie na údaje formulára;
- FormDataInValue() – konvertuje údaje formulára na objekt typu aplikácie;
- CopyFormData() – skopíruje údaje formulára, ktoré majú kompatibilnú štruktúru. Vráti hodnotu True, ak bola kópia úspešná, alebo False, ak je štruktúra objektu nekompatibilná.
Poznámka. Pri vykonávaní štandardných akcií (otvorenie formulára, vykonanie štandardného príkazu Write a pod.) formulára s hlavnými detailmi sa konverzia vykoná automaticky.
Uveďme príklad, ako použiť transformáciu údajov vo vlastných algoritmoch.
ObjectProduct = Directories.Products.FindByName("Kávnik").GetObject(); ValueInFormData(ObjectItem, Object);
EndProcedure
&OnClient Procedure Write()
WriteOnServer();
EndProcedure
&Procedúra na serveri WriteOnServer()
ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();
EndProcedure
Objekt ManagedForm má na serveri dostupné aj metódy:
- ValueВFormAttribute() – konvertuje objekt typu aplikácie na špecifikovaný atribút formulára.
- FormAttributeVValue() – konvertuje atribút údajov formulára na objekt typu aplikácie.
Použitie týchto metód je zvyčajne pohodlnejšie, pretože majú napríklad informácie o type podrobností formulára. Okrem toho metóda Form AttributesValue() nastavuje súlad medzi údajmi formulára a objektom, ktorý sa používa pri generovaní správ. Viac sa o tom môžete dočítať v kapitole „Možnosti navigácie služby“.
Uveďme príklad použitia týchto metód.
// Konvertuje atribút Object na objekt aplikácie. Dokument = Form AttributesValue("Object"); // Vykoná prepočet pomocou metódy definovanej v module dokumentu. Document.Recalculate(); // Skonvertuje objekt aplikácie späť na rekvizitu. ValueВFormAttributes(Document, “Object”);
EndProcedure
Softvérové rozhranie
FormDataTree
- FindById
- GetItems
Popis:
Navrhnuté na modelovanie stromu v údajoch spravovaného formulára.
Tento objekt je možné serializovať do/z XDTO. Typ XDTO zodpovedajúci tomuto objektu je definovaný v mennom priestore. Názov typu XDTO:
GetItems
Syntax:
GetItems()
Návratová hodnota:
Typ: Formulár DataCollection of Tree Elements.
Popis:
Získa kolekciu prvkov stromu najvyššej úrovne.
Dostupnosť: 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íska prvok kolekcie podľa ID.
Dostupnosť: klient, server, tenký klient, webový klient.
FormDataTreeItem
Vlastnosti:
<Имя свойства> (<Имя свойства>)
- GetId (GetId)
- GetParent
- GetItems
- Nehnuteľnosť
Popis:
Prvok stromu údajov formulára.
FormDataTreeItemCollection
Prvky kolekcie: DataFormTreeElement
Pre objekt je možné prechádzať zberom pomocou operátora Pre každý... Od... Slučka. Priechod vyberá prvky kolekcie. K prvku kolekcie je možné pristupovať pomocou operátora [...]. Index prvku sa odovzdá ako argument.
- Vložiť
- Pridať
- Index (IndexOf)
- počítať
- jasný
- Získajte
- Pohybujte sa
- Odstrániť
Popis:
Kolekcia drevených prvkov.
Dostupnosť: klient, server, tenký klient, webový klient.
Pozri tiež:
- FormDataTreeElement, metóda GetElements
- DataFormTree, metóda GetItems
Vlastnosti práce so stromom hodnôt
Aktualizácia stromu
Je tu problém padá platformy pri aktualizácii stromu.
Ak bol niektorý uzol v strome rozšírený a bol vybratý podriadený uzol, potom pri aktualizácii stromu pomocou funkcie ValueInFormData plošina padá.
Riešenie: Pred aktualizáciou musíte vymazať strom.
Napríklad:
&Na serveri Procedúra ClearTree(elements) Pre každý prvok z prvkov Loop ClearTree(element.GetElements()); EndCycle; elementy.Clear(); EndProcedure
&Na serveri Postup Vyplniť strom konceptu() dConcepts = srProperties.Build strom konceptu(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); EndProcedure
&Procedúra OnClient OnDateOnChange(Element) Fill ConceptTree(); EndProcedure
Platforma 1C:Enterprise vám umožňuje programovo pridávať a meniť prvky spravovaného formulára. Poďme zistiť, prečo to môže byť potrebné.
Softvérová úprava formulára môže byť potrebná v niekoľkých prípadoch:
- Pri dokončovaní štandardných konfigurácií na uľahčenie následného postupu aktualizácie. V tomto prípade sa zmení iba modul formulára. Moduly sa aktualizujú oveľa jednoduchšie ako formuláre.
- Pri implementácii niektorých bežných algoritmov. Napríklad v podsystéme „Zákaz úpravy podrobností o objekte“ je možné programovo vytvoriť tlačidlo pre všetky objekty pripojené k podsystému, aby bolo možné upravovať podrobnosti.
- Pri implementácii niektorých špecifických algoritmov. Napríklad v adresári Nomenklatúra sú vytvorené polia na úpravu ďalších podrobností.
V spravovanom formulári môžete programovo pridávať, meniť a odstraňovať:
- náležitosti;
- miestne tímy;
- prvkov.
Všetky tieto operácie sú možné iba na serveri.
Programové pretváranie má obmedzenia:
- Môžete odstrániť iba programovo pridané podrobnosti/príkazy/prvky. Objekty vytvorené v konfigurátore nemôžete programovo vymazať.
- Nemôžete priradiť atribút ako hlavný.
Zmena príkazov formulára
Na správu zloženia príkazov pre objekt ManagedForm existuje zbierka Tímy
Pridať (< ИмяКоманды >)
množstvo ()
Nájsť (< ИмяКоманды >)
Odstrániť (< Команда >)
Kolekcia Teams je dostupná na klientovi aj na serveri. Kolekciu (metódy Add() a Delete()) môžete zmeniť iba na serveri. Môžete vyhľadať a získať počet prvkov (metódy Find () a Count ()) na klientovi aj na serveri.
Ako príklad práce s príkazmi formulára si vytvorte nový príkaz ChangeHistory s nadpisom „ChangeHistory...“, ktorý bude volať handler DisplayHistory(). Vytvorenie nastane pri otvorení formulára.
&Na serveri
Postup WhenCreatingOnServer(Failure, StandardProcessing)
Tím = Tímy. Pridať( "História zmien");
Tím . Akcia = ;
Tím . Titul = "História zmien...";
EndProcedure
&OnClient
Postup Connectable_DisplayHistory(Príkaz)
// akcie príkazov
EndProcedure
Obslužný program príkazu sa musí nachádzať vo formulári a musí mať direktívu kompilácie &OnClient.
Zmena podrobností formulára
Čítanie zloženia detailov formulára vykonáva funkcia Získajte podrobnosti(< Путь >) vracia pole typu FormAttributes. Parameter funkcie určuje cestu k rodičovskému atribútu (ako reťazec). Ak je parameter vynechaný alebo je zadaný prázdny reťazec, vrátia sa podrobnosti najvyššej úrovne.
Zmena podrobností sa vykonáva pomocou metódy Zmeniť podrobnosti(<Pridané podrobnosti>, <Odnímateľné detaily>) objekt ManagedForm. K parametrom Pridané podrobnosti A Odnímateľné detaily Prenášajú sa polia s prvkami typu Form Attributes.
Pozor!
Proces zmeny zloženia detailov je pomerne náročný na zdroje. Formulár sa v skutočnosti vytvára znova. V tomto ohľade sa práca s detailmi formulára vykonáva v dávkovom režime.
Vytvorme nový atribút formulára s názvom Kupujúci:
AddedDetails = Nové pole;
Pridané podrobnosti. Pridať(Nové atribúty formulára(„Kupujúci“, Popis nového typu („Odkaz na adresár. Protistrany“), „Klient“));// Zmeny v zložení detailov
);
Zmena prvkov formulára
Ovládať zloženie prvkov objektu ManagedForm existuje zbierka Prvky. Zber má niekoľko spôsobov:
Vložiť (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Pridať (< Имя>, < ТипЭлемента>, < Родитель >)
množstvo ()
Nájsť (< Имя >)
Presunúť (< Элемент>, < Родитель>, < МестоРасположения >)
Odstrániť (< Элемент >)
Kolekcia Items je dostupná na klientovi aj na serveri. Upravte kolekciu (metódy vloženia () , Pridať () , Presunúť () a Odstrániť () ) sú dostupné len na serveri. Môžete vyhľadať a získať počet prvkov (metódy Find () a Count ()) na klientovi aj na serveri. Prvky kolekcie môžu byť:
- FormGroup;
- FormTable;
- FormField;
- Tlačidlo formulára.
K prvkom formulára môžete programovo priradiť obslužné rutiny udalostí. Metóda je určená na tieto účely SetAction(< ИмяСобытия>, < Действие >) .
Pozrime sa na niektoré z najbežnejších príkladov práce s príkazmi, detailmi a prvkami formulára.
Pridanie príkazu a príslušného tlačidla:
// Vytvorenie príkazu
Tím = Tímy. Pridať( "História zmien");
Tím . Akcia = "Plug-in_DisplayHistory"; // Formulár musí obsahovať procedúru so zadaným názvom
Tím . Smerovanie = "História zmien...";
// Vytvorte tlačidlo a priraďte ho k príkazu
Element = Položky. Pridať( "História zmien", Type("FormButton" ));
Element.CommandName = "História zmien";
Pridanie atribútu a súvisiaceho vstupného poľa:
// Popis pridaných detailov
AddedDetails = Nové pole;
Pridané podrobnosti. Pridať(Nové možnosti formulára („Kupujúci“, Popis nového typu ( "DirectoryLink. Protistrany"), "Zákazník" ));
// Zmena zloženia detailov
ChangeDetails (Pridané podrobnosti);
// Vytvorenie vstupného poľa a pripojenie k atribútu
Element = Položky. Pridať("Kupujúci" , Typ ("Pole formulára" ));
Element . Zobraziť = FormFieldView. Vstupné pole;
Element . PathToData= "kupujúci" ;
Priradenie obsluhy udalosti k prvku formulára:
ItemCustomer. SetAction("Keď sa to zmení", "Connected_BuyerOnChange");
&OnClient
Postup Connected_BuyerOnChange(Element)
// Akcie udalosti
EndProcedure
Pozor!
Procedúry, ktoré sú nastavené ako obslužné rutiny udalostí z kódu pomocou metódy SetAction(), odporúča sa nastaviť predponu Connectable_.
Pozor!
Môžete si stiahnuť spracovanie s príkladmi programového vyhľadávania a zmeny detailov, príkazov a prvkov riadeného formulára.
Podrobnosti formulára zabezpečujú jeho spojenie s údajmi. V tomto prípade môže byť jeden (a iba jeden) z detailov označený ako hlavný; nemusí to byť nevyhnutne typ údajov, na ktorý formulár kreslíme. Správanie formulára však bude závisieť od typu údajov hlavného atribútu. Okrem zmeny správania formulára sa mení aj kontext modulu formulára. Spolu s metódami a vlastnosťami formulára sa v ňom sprístupňujú aj metódy a vlastnosti objektu, ktorý je hodnotou hlavného atribútu. Je dôležité, aby formuláre typu Free Form nemali základné detaily. V tomto prípade je správanie formulára určené iba nastaveniami používateľa. Zvážme otázky týkajúce sa základných detailov.
Otázka 10.05 skúšky 1C: Platform Professional. Na čo sa používa hlavný atribút formulára?
- Definuje zdroj údajov pre formulár ako celok
- Definuje štandardné možnosti platformy pre prácu s formulárom s údajmi typu uvedeného v hlavnom atribúte
- Poskytnúť možnosť programového prístupu k detailom objektu z kontextu lokálneho formulára
- Poskytuje vizualizáciu detailov objektu v dialógovom okne formulára
- 2 a 3 sú správne
- 1 a 2 sú správne
Správna odpoveď je číslo šesť, pozri vyššie.
Otázka 10.06 skúšky 1C: Platform Professional. Na čo sú potrebné podrobnosti formulára?
- Na popis obsahu údajov, ktoré sú zobrazené, upravované alebo uložené vo formulári
- Na zobrazenie a úpravu údajov vo formulári
- 1 a 2 sú správne
Správna odpoveď je tretia – obe.
Otázka 10.07 skúšky 1C: Platform Professional. Ak chcete priradiť základné atribúty ľubovoľnému riadenému formuláru...
- Vo vlastnostiach atribútov formulára musíte zaškrtnúť políčko "Základné podrobnosti".
- musíte vyplniť vlastnosť „Údaje“ formulára výberom požadovaného atribútu formulára
Správna odpoveď je druhá:
Otázka 10.08 skúšky 1C: Platform Professional. Ak chcete priradiť hlavné detaily ľubovoľnému pravidelnému tvaru...- formulár musí byť hlavný, hlavné podrobnosti sa určujú automaticky
- Vo vlastnostiach atribútov formulára musíte zaškrtnúť políčko "Základné podrobnosti".
- musíte prejsť do ponuky "Upraviť", "Základné podrobnosti" a vybrať požadovanú hodnotu
- musíte vyplniť vlastnosť „Údaje“ formulára výberom požadovaného atribútu formulára
Štvrtá správna odpoveď je:
Hlavné detaily sú zvýraznené tučným písmom:
Otázka 10.09 skúšky 1C: Platform Professional. Ak existuje jeden hlavný atribút formulára, je možné pridať ďalší hlavný atribút?- Toto je nemožné
- Je to možné priradením príslušnej hodnoty vlastnosti atribútu formulára
- Je to možné len programovo, pri prístupe k objektu "Formulár".
- To je možné pridaním ďalšej hodnoty do zodpovedajúcej vlastnosti formulára
Správna odpoveď je prvá, je tu striktne jedna hlavná požiadavka, pretože spojenie s objektom musí byť jednoznačné.
Otázka 10.113 skúšky 1C: Platform Professional. Ktorý z detailov formulára na obrázku je hlavný?
- Zoznam kurzov mien
- DirectoryObject
- Adresárové formuláre nemajú základné detaily
- Adresáre majú všetky základné detaily
Formulár sa ovláda cez rôzne formulárové prvky, ktoré sú hierarchicky umiestnené na záložke Prvky návrhár formulárov. Najdôležitejším prvkom je samotná forma, ktorá sa nachádza na vrchole hierarchie prvkov a zvyšné prvky sú jej podriadené.
Všetky prvky formulára možno rozdeliť do piatich skupín: polia, prvky zoskupovania, tlačidlá, dekorácie a tabuľky. Vo svojich článkoch budem analyzovať každú zo skupín. V tomto článku začneme študovať jeden z typov prvkov poľa - vstupné pole, ale predtým sa naučíme, ako pridať prvok do formulára.
Pridávanie prvkov do formulára
To sa robí celkom jednoducho: musíte vybrať prvok Formulár v okne Prvky návrhu formulára a kliknite na tlačidlo „Pridať“. Potom sa otvorí okno, v ktorom musíte vybrať požadovaný typ prvku
Po výbere sa v okne zobrazí požadovaný prvok Prvky.
Prvok spravovaného formulára Lúka
Pozrime sa na prvok spravovaného formulára Lúka. Tento prvok je potrebný na zadanie informácií do formulára. A tiež na zobrazenie akýchkoľvek informácií. Po pridaní tohto prvku do formulára sa vpravo otvorí paleta vlastností prvku formulára. Zatiaľ by vás mali zaujímať dve vlastnosti – DataPath a View.
Vo vlastnosti DataPath môže vývojár priradiť element formulára k požadovanému atribútu formulára. Upozorňujeme, že po pridaní prvku Vstupné pole na formulári to nebolo zobrazené na samotnom formulári. Stalo sa to preto, lebo náš nový prvok nie je spojený s . Napríklad vo formulári spracovania som vytvoril niekoľko atribútov s rôznymi primitívnymi typmi a jeden atribút s typom odkazu.
Teraz prepojme náš nedávno pridaný prvok formulára s jedným z detailov. Ak to chcete urobiť, vyberte požadovaný atribút z vlastnosti PathKData prvku.
Potom sa vyplnia vlastnosti DataPath a View a samotný prvok sa zobrazí v zobrazení formulára.
Venujte pozornosť vlastnosti prvku vyhliadka. Táto vlastnosť určuje funkčnosť vstupného poľa. Pre túto vlastnosť môžete vybrať rôzne hodnoty.
V závislosti od zvolenej hodnoty sa určí funkčnosť. Na obrázkoch vyššie je vybratá hodnota – vstupné pole, t.j. do tohto vstupného poľa môžeme zadať ľubovoľné hodnoty a ak vyberieme hodnotu štítkové pole, potom nebudeme môcť zadať nič.
Táto hodnota nehnuteľnosti vyhliadka Vstupné polia sú vhodné na výber, keď potrebujete používateľovi zobraziť pomocné informácie.
Teraz pridajme nový prvok formulára s typom Vstupné pole a spojte ho s rekvizitami PodrobnostiDátum prostredníctvom nám už známej vlastnosti DataPath
Ako vidíte, zmenil sa vzhľad vstupného poľa a zmení sa aj možný výber hodnôt pre vlastnosť View.
Dospeli sme teda k záveru, že funkčnosť vstupného poľa závisí od typu atribútu.
Pre rekvizity s typom Boolean K dispozícii budú nasledujúce hodnoty vlastností zobrazenia.
A pre atribúty s typom odkazu budú k dispozícii ďalšie hodnoty vlastnosti View.
Podrobnejšia práca s formulárovými prvkami pomocou praktických príkladov je uvedená v knihe „Základy vývoja v 1C: Taxi. Riadený vývoj aplikácií v 12 krokoch“.
Niekedy sa zdá, že naučiť sa programovací jazyk v 1C je komplikované a ťažké. V skutočnosti je programovanie v 1C jednoduché. Moje knihy vám pomôžu ľahko a rýchlo zvládnuť programovanie v 1C: a „Základy vývoja v 1C: Taxi“
Naučte sa programovať v 1C pomocou mojej knihy „Programovanie v 1C v 11 krokoch“
- Žiadne zložité technické výrazy.
- Viac ako 700 strán praktického materiálu.
- Ku každej úlohe je priložená kresba (snímka obrazovky).
- Zbierka úloh na domácu úlohu.
- Kniha je napísaná jasným a jednoduchým jazykom - pre začiatočníka.
Táto kniha je vhodná pre tých, ktorí už s programovaním začali a majú s touto témou určité ťažkosti a pre tých, ktorí programujú už dlho, ale nikdy nepracovali s riadenými formulármi 1C.
- Bez zložitých technických výrazov;
- Viac ako 600 strán praktického materiálu;
- Každý príklad je doplnený nákresom (snímka obrazovky);
- Kniha sa posiela e-mailom vo formáte PDF. Dá sa otvoriť na akomkoľvek zariadení!
Promo kód na 15% zľavu - 48PVXHeYu
Ak vám táto lekcia pomohla vyriešiť akýkoľvek problém, páčila sa vám alebo bola užitočná, môžete podporiť môj projekt darovaním ľubovoľnej sumy:
Môžete zaplatiť manuálne:
Yandex.Money - 410012882996301
Web Money - R955262494655
Pridajte sa k mojim skupinám.
A Data Transfer Object na štruktúrovanie kódu, riadená forma v prostredí 1C 8.2.
Úvod
Začnime krátkym popisom konceptu „riadenej formy“ a súvisiacich konceptov platformy 1C. Znalci platforiem možno budú chcieť túto časť preskočiť.V roku 2008 bola dostupná nová verzia platformy 1C: Enterprise 8.2 (ďalej len Managed Application), ktorá úplne mení celú vrstvu práce s rozhraním. To zahŕňa príkazové rozhranie, formuláre a systém okien. Zároveň sa mení nielen model vývoja používateľského rozhrania v konfigurácii, ale je navrhnutá aj nová architektúra oddelenia funkcionality medzi klientskou aplikáciou a serverom.
Spravovaná aplikácia podporuje nasledujúce typy klientov:
- Hrubý klient (normálny a spravovaný režim spustenia)
- Tenký klient
- Webový klient
Hlavné rozdiely spravovaných formulárov pre vývojárov:
- Deklaratívny, nie „pixel po pixeli“ popis štruktúry. Konkrétne umiestnenie prvkov vykoná systém automaticky pri zobrazení formulára.
- Všetky funkcie formulára sú opísané ako podrobnosti A tímov. Podrobnosti sú údaje, s ktorými formulár pracuje, a príkazy sú akcie, ktoré sa majú vykonať.
- Formulár beží na serveri aj na klientovi.
- V kontexte klienta sú takmer všetky typy aplikácií nedostupné, a preto nie je možné meniť údaje v informačnej databáze.
- Pre každú metódu alebo premennú formulára musí byť špecifikovaná kompilačnej smernice, definovanie miesta vykonávania (klient alebo server) a prístup ku kontextu formulára.
- &OnClient
- &Na serveri
- &OnServerBez kontextu
- &OnClientOnServerWithout Context
Všetky ďalšie diskusie budú o pravej strane ilustrácie, o tom, ako štruktúrovať kód modulu a aké princípy vám umožnia implementovať efektívnu interakciu klient-server.
Definujme problém
Od aktívneho používania novej verzie platformy 1C uplynulo niekoľko rokov a spoločnosť 1C a jej mnohí partneri vydali mnohé riešenia (konfigurácie).Dospeli vývojári počas tejto doby k spoločnému chápaniu princípov interakcie klient-server pri vytváraní formulárov a zmenil sa prístup k implementácii softvérových modulov v novej architektonickej realite?
Pozrime sa na štruktúru kódu (modul formulára) v niekoľkých formách rovnakej štandardnej konfigurácie a pokúsime sa nájsť vzory.
Štruktúrou rozumieme sekcie kódu (najčastejšie sú to bloky komentárov), ktoré vývojár pridelil skupinovým metódam a kompilačné direktívy pre tieto metódy.
Príklad 1:
Sekcia obsluhy udalostí Metóda - na klientovi Metóda - na serveri Metóda - na klientovi Sekcia servisných procedúr a funkcií Pomocné vstupné riadiace funkcie
Príklad 2:
Servisné postupy a funkcie Platobné doklady Hodnoty Obslužné jednotky udalostí
Príklad 3:
Servisné procedúry na serveri Servisné procedúry na klientovi Servisné procedúry na serveri bez kontextu Obslužné nástroje udalostí hlavičky Príkazové obsluhy udalostí
Príklad 4:
Všeobecné procedúry Obslužné nástroje udalostí formulára Procedúry podsystému „kontaktné informácie“.
V podstate chýba štruktúra kódu, alebo mierne povedané, je podobná tomu, čo bolo vo formulároch 8.1:
- Neinformatívne slová „všeobecný, servisný, pomocný“.
- Nesmelé pokusy oddeliť metódy klienta a servera.
- Metódy sú často zoskupené podľa prvkov rozhrania „Práca s tabuľkovou časťou Produkty, Kontaktné informácie“.
- Ľubovoľné usporiadanie metód a kódových skupín. Obslužné rutiny udalostí môžu byť napríklad v jednom formulári navrchu, v druhom na spodku, v treťom nie sú vôbec zvýraznené atď.
- A nezabúdajme, že toto všetko je v rámci jednej konfigurácie.
- Áno, existujú konfigurácie, v ktorých sú slová „General, Service, Auxiliary“ vždy na rovnakých miestach, ale...
Prečo potrebujete štruktúru kódu?
- Zjednodušenie údržby.
- Zjednodušiť učenie.
- Zaznamenávanie všeobecných/dôležitých/úspešných zásad.
- ...vaša možnosť
Prečo nepomáha existujúci vývojový štandard od 1C?
Pozrime sa na zásady publikované na diskoch ITS a v rôznych „Príručkách pre vývojárov...“, ktoré sa odporúčajú pri písaní riadeného formulára.- Minimalizujte počet volaní servera.
- Maximálny výpočtový výkon na serveri.
- Nekontextové volania servera sú rýchlejšie ako kontextové.
- Program s ohľadom na komunikáciu klient-server.
- a tak ďalej.
Dizajnové vzory či generačná múdrosť
Interakcia klient-server sa používa v rôznych softvérových technológiách už desaťročia. Odpoveď na otázky načrtnuté v predchádzajúcej časti je už dávno známa a je zhrnutá do dvoch základných princípov.- Vzdialená fasáda(ďalej len rozhranie vzdialeného prístupu)
- Objekt prenosu údajov(ďalej len objekt prenosu údajov)
- … Každý objekt potenciálne určený na vzdialený prístup musí mať rozhranie s nízkou granularitou, čo minimalizuje počet hovorov potrebných na vykonanie určitého postupu. ... Namiesto toho, aby ste si vyžiadali faktúru a všetky jej položky samostatne, musíte si prečítať a aktualizovať všetky položky faktúry v jednej požiadavke. To ovplyvňuje celú štruktúru objektu...Pamätajte: rozhranie vzdialeného prístupu neobsahuje doménovú logiku.
- ...keby som bola starostlivá matka, určite by som svojmu dieťaťu povedala: "Nikdy nepíšte objekty prenosu dát!" Vo väčšine prípadov nie sú objekty prenosu údajov ničím iným nadutý set poľa... Hodnota tohto nechutného monštra spočíva výlučne v možnosti prenášať viacero informácií cez sieť v rámci jedného hovoru- technika, ktorá má veľký význam pre distribuované systémy.
Príklady šablón na platforme 1C
Rozhranie na programovanie aplikácií, ktoré má vývojár k dispozícii pri vývoji riadeného formulára, obsahuje mnoho príkladov týchto princípov.Napríklad metóda OpenForm(), typické „hrubé“ rozhranie.
OpeningParameters = New Structure("Parameter1, Parameter2, Parameter3", Hodnota1, Hodnota2, Hodnota3); Form = OpenForm(FormName, OpeningParameters);
Porovnajte so štýlom prijatým vo verzii 8.1.
Form = GetForm(FormName); Form.Parameter1 = Hodnota1; Form.Parameter2 = Hodnota2; Form.Open();
V kontexte riadeného formulára existuje veľa „objektov prenosu údajov“. Môžete si vybrať systémový A definované vývojárom.
Systémové modelujú objekt aplikácie na klientovi vo forme jedného alebo viacerých dátových prvkov formulára. Nie je možné ich vytvoriť bez odkazu na podrobnosti formulára.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureWithCollection
- DataShapesTree
- ValueInFormData()
- FormDataValue()
- CopyFormData()
- ValueInFormAttributes()
- FormAttributesValue()
Príklad 1C v8.1:
// na klientovi v kontexte formulára FillUserCache(DepartmentLink)
Príklad 1C v8.2:
// na serveri v kontexte formulára ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");
Objekty prenosu údajov, ktorých štruktúru určuje vývojár, sú malou podmnožinou typov dostupných na klientovi aj na serveri. Ako parametre a výsledky metód „zhrubnutého“ rozhrania sa najčastejšie používajú nasledovné:
- Primitívne typy (reťazec, číslo, boolean)
- Štruktúra
- Korešpondencia
- Pole
- Odkazy na objekty aplikácie (jedinečný identifikátor a textová reprezentácia)
Funkcia &OnServerWithoutContext ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [objednávka][popis chyby] Pre každú objednávku z objednávok cyklus StartTransaction(); Skúste DocOb = Order.GetObject(); …. iné akcie, možné nielen s objednávkou... Výnimka CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndPokus; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()
Štruktúrovanie kódu
Hlavné ciele, ktoré by mal modul riadeného formulára odrážať a pristupovať k riešeniu.- Jasné oddelenie kódu klienta a servera. Nezabúdajme, že v čase realizácie ide o dva interagujúce procesy, z ktorých každý má výrazne odlišnú dostupnú funkcionalitu.
- Jasná identifikácia rozhrania vzdialeného prístupu, ktoré serverové metódy možno volať z klienta a ktoré nie? Názvy metód vzdialeného rozhrania začínajú predponou „Server“. To vám umožňuje okamžite vidieť prenos kontroly na server počas čítania kódu a zjednodušuje používanie kontextovej pomoci. Všimnite si, že oficiálne odporúčanie (ITS) navrhuje metódy pomenovania s postfixami, napríklad ChangeOrderStatusOnServer(). Opakujeme však, že nie všetky serverové metódy je možné volať z klienta, a preto je dôležitejšia logická dostupnosť, než umiestnenie kompilácie. Preto predponou „Server“ označíme len metódy dostupné klientovi, zavolajme napríklad metódu ServerChangeOrderStatus().
- Čitateľnosť. Vec vkusu, akceptujeme objednávku, keď modul začne s procedúrami vytvárania formulára na serveri a metódami vzdialeného prístupu.
- Udržiavateľnosť. Musí existovať jasné miesto na pridanie nového kódu. Dôležitým bodom je, že šablóny metód automaticky vytvorené konfigurátorom sú pridané na koniec modulu. Keďže obslužné rutiny udalostí pre prvky formulára sa najčastejšie vytvárajú automaticky, príslušný blok je umiestnený ako posledný, aby sa každý obslužný program neťahal na iné miesto v module.
- Grafická možnosť – jasne zobrazuje hlavný tok vykonávania.
- Možnosť text je príkladom návrhu šablóny na rýchle vloženie štruktúry do nového modulu formulára.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Dátum =""/> // <Описание> // // ///////////////////////////////////////////////// ///////////////////////////// PREMENNÉ MODULU //////////////////// ////////////////////////////////////////////////// ////////// // NA SERVERI //******* UDALOSTI NA SERVERI ******* &Na serveri Postup pri vytvorení na serveri (zlyhanie, štandardné spracovanie) / /Vložiť obsah obsluhy Koniec procedúry //******* ROZHRANIE NA VZDIALENÝ PRÍSTUP ******* //******* OBCHODNÁ LOGIKA NA SERVERI ******* ///////// ///////////////////////////////////////// /////// ///////////////////// BEŽNÉ METÓDY KLIENTA A SERVERA /////////////// /////// /////////////////////////////////////////// ///// //////// // NA KLIENTOVI //******* OBCHODNÁ LOGIKA NA KLIENTOVI ******* //******* TÍM * ****** //******* KLIENTSKÉ AKCIE ******* /////////////////////////// ///// ///////////////////////////////////////////// // / / HLAVNÍ OPERÁTORI PROGRAMU
Súvisiace otázky
Na záver si načrtneme niekoľko oblastí, na ktoré je užitočné myslieť pri programovaní interakcie klient-server.- Možnosti implementácie rozhrania vzdialeného prístupu. Asynchrónnosť, úroveň detailov...
- Ukladanie do vyrovnávacej pamäte. 1C urobil neúspešné architektonické rozhodnutie, ktoré zaviedlo ukladanie do vyrovnávacej pamäte iba na úrovni metód volania bežných modulov a neposkytovalo možnosti riadenia (čas relevantnosti, resetovanie na požiadanie).
- Implicitné volania servera. Nezabudnite na technologické vlastnosti, veľa „neškodných“ operácií na klientovi vyprovokuje platformu, aby kontaktovala server.
