VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství
Generování výstupních sestav v prostředí webu Diplomová práce
Lukáš Kolafa
Vedoucí práce: Ing. Vilém Sklenák, CSc. prosinec 2010
Prohlášení Prohlašuji, že jsem vypracoval samostatně diplomovou práci na téma „Generování výstupních sestav v prostředí webu“. Použitou literaturu a další podkladové materiály uvádím v přiloženém seznamu literatury.
V Praze dne 14. 12. 2010
Lukáš Kolafa
Abstrakt Dnes je velmi často potřeba z firemních informačních systémů tisknout dokumenty, které jsou vzhledově ušity firmě na míru. Informace, které se mají na takovém dokumentu zobrazit, bývají uloženy v databázích. Obsahem této práce je popis způsobů, jak data automaticky převádět na formátovaný dokument. Snažím se ukázat některé metody, jak automaticky generovat tiskové výstupy a jak pro ně co nejjednodušeji vytvářet šablony. Pro účely této práce jsem vytvořil menší webovou aplikaci, která připomíná informační systém dopravní firmy. Aplikace umožňuje vytvářet dokumenty pomocí tiskových šablon. Všechny dokumenty jsou generovány v běžně rozšířených formátech.
Abstract Today it is very often necessary to print different documents from company information systems. These documents, that are designed to represent the company, contain information that is usually stored in databases. The goal of this thesis is to show the methods for the automatic conversion of data into formatted documents. My aim is to show some methods, how to automatically generate printouts and how to create templates for them in an easy way. For the purpose of this thesis, I’ve developed a small web application, which stands for an information system of a logistics company. The application allows creating documents with the help of templates. All documents are generated in generally common formats.
Poděkování Rád bych tímto poděkoval vedoucímu své práce Ing. Vilému Sklenákovi, CSc. za podporu při její tvorbě a mnohé cenné podněty.
Obsah Úvod ...................................................................................................................... 8 1 Použité formáty .............................................................................................. 9 1.1 XML ....................................................................................................... 9 1.2 WordML & Open XML........................................................................... 9 1.3 PDF ....................................................................................................... 10 1.4 LaTeX & LyX ....................................................................................... 10 2 XSLT ........................................................................................................... 11 2.1 XPath .................................................................................................... 11 2.2 Ruční psaní XSLT šablony .................................................................... 11 3 Aplikace ....................................................................................................... 13 3.1 DBGenerator ......................................................................................... 13 3.1.1 Zdrojové XML ............................................................................. 14 3.1.2 Schéma zdrojového souboru......................................................... 15 3.1.3 Automatické formátování ............................................................. 16 3.1.4 Význam při vývoji webové aplikace............................................. 17 3.2 Logistics ................................................................................................ 18 3.2.1 Popis aplikace jako ERP systému ................................................. 19 3.2.2 Tvorba a správa databáze ............................................................. 19 3.2.3 Použité typy výstupů .................................................................... 21 3.2.4 Nahrávání šablon ......................................................................... 21 3.2.5 Stylování tabulek ......................................................................... 22 3.2.6 Ukládání generovaných dokumentů ............................................. 23 4 Generování dokumentů ................................................................................. 24 4.1 Microsoft XSLT Inference Tool ............................................................ 24 4.1.1 Parametry transformace ............................................................... 25 4.1.2 Chybová hlášení konverze............................................................ 26 4.2 Serializace do XML ............................................................................... 26 4.2.1 Automaticky generovaný kód....................................................... 26 4.2.2 Využití objektového přístupu ....................................................... 27 4.2.3 Vnoření serializovaných objektů .................................................. 30 4.3 Generování dokumentu MS Word ......................................................... 30 4.3.1 Tvorba šablon .............................................................................. 30 4.3.2 XSL transformace v ASP.NET aplikaci....................................... 36 4.3.3 Dodatečné úpravy dokumentu ...................................................... 37 4.3.4 Předání výsledného dokumentu uživateli...................................... 43 4.4 Generování dokumentu pro starší verze MS Word ................................. 44 4.4.1 Řešení problému s kompatibilitou ................................................ 44 4.5 Generování tabulek ................................................................................ 45 4.5.1 Export do aplikace MS Excel ....................................................... 45 4.5.2 Obrázky ....................................................................................... 46 4.5.3 Špatné zobrazení rámečků ............................................................ 47 4.5.4 Export HTML tabulky ................................................................. 47 4.6 Využití programu LyX a jazyka LaTeX ................................................. 48 4.6.1 Tvorba šablon .............................................................................. 49 4.6.2 Konverze LyX formátu na LaTeX ................................................ 50 4.6.3 Konverze LaTeX formátu do PDF souboru .................................. 50 4.6.4 Rozdíl mezi aktuálním a cílovým stavem transformace ................ 50 6
4.7 Generování PDF .................................................................................... 52 4.7.1 Použité programy pro konverzi .................................................... 52 4.7.2 Srovnání výsledků konverze......................................................... 53 4.8 Generování ostatních formátů ................................................................ 54 4.9 Srovnání konverzních nástrojů ............................................................... 55 Závěr a srovnání použitých metod ........................................................................ 57 LyX a LaTeX ................................................................................................... 57 Šablony WordML ............................................................................................. 57 Tvorba PDF dokumentů.................................................................................... 58 Seznam zdrojů ...................................................................................................... 59
7
Úvod V moderním světě se stále více mluví o počítačích, každý dělá vše na počítačích a nakupovat už chodíme pomalu také jen na počítači. Všechna data jsou uložena v databázích a papírové dokumenty mizí ze světa. Vzniká tak potřeba data uložená v databázích prezentovat v nějaké formě okolnímu světu. Může se jednat o tisk dokumentů na papír nebo generování katalogů, které se rozesílají zákazníkům elektronickou poštou. Je tedy velice důležité nalézt jednoduchou formu, jak dokumenty vytvářet. Forma a vzhled dokumentů slouží také jako reprezentace firmy. Každá společnost má své vlastní logo, barvy a standardní vzhled produktů. Je proto potřeba nalézt způsob, jak vytvářet vzory pro firemní dokumenty, ať už se jedná o dokumenty určené k tisku nebo určené k prezentaci v počítačovém prostředí. Pro tento účel se nabízí šablony s dynamickým obsahem. Ty mají standardní vzhled a obsah textu se přizpůsobí podle objektu, který dokument generuje. Vytváření takových šablon a popis možností, jak takové šablony používat je součástí této práce. Firmy většinou mívají své vlastní grafiky, kteří se starají o marketing a vnější komunikaci. To jsou lidé vzdělaní v jiném oboru, než je programování nebo dokonce s IT nemají vůbec nic společného. Je však žádoucí, aby šablony vytvářeli právě tito lidé. Proto se budu snažit najít způsob, jak umožnit právě těmto lidem vytvářet šablony použitelné pro generování firemních dokumentů. Aplikace, kterou jsem vytvořil, pracuje s několika druhy šablon a lze na ní prezentovat možnosti automatického generování výstupů. Detailně zde popíšu, jak se šablony vytváří, zpracovávají, jak probíhá samotné generování a v konečné fázi zpracování výsledného dokumentu. Hlavní cíl je prezentovat co nejjednodušší metodu vytváření šablon pro uživatele. Práce obsahuje stručný popis formátů, které jsou použity pro generování výstupních sestav. V navazující kapitole je nastíněn princip XSL transformace, která tvoří jádro celé metody využití šablonového systému. Další části jsou věnovány popisu vytvořených aplikací k této práci, ve kterých jsou implementovány veškeré principy zde popsané. Kapitola „Generování dokumentů“ se podrobně zabývá metodami a způsoby, jak vytvářet konkrétní formáty a které šablony pro ně lze využít. V závěru práce hodnotím všechny implementované metody a postupy.
8
1 Použité formáty V této práci je použito množství různých formátů. Některé jsou použity pro výstupní dokumenty, jiné zase předávají nebo zpracovávají data v aplikaci. Ty nejdůležitější zde stručně představím.
1.1 XML Extensible Markup Language jsou anglická slova, která tvoří zkratku XML. Je to univerzální značkovací jazyk, který umožňuje předávat data mezi aplikacemi v otevřeném formátu. Data nejsou v binární podobě, jak bývalo zvykem u většiny souborů. Data jsou uložena v souboru v textové podobě a uzavřena v elementech, které dávají hodnotám význam. Elementy jsou v sobě vnořeny tak, že každý dokument XML lze převést na strom s jedním kořenem. 1 XML formát je ideální pro výměnu dat, protože se nemusí používat speciální program pro přečtení tohoto souboru. Pro konkrétní případy mají data samozřejmě předem definovanou strukturu. Čtenář, který data bude číst bez znalosti jejich významu, může význam částečně odhadnout pouze na základě názvu elementů. Tento formát je velmi snadno zpracovatelný a transformovatelný do dalších formátů. To je dáno jeho stromovou strukturou. Mnoho formátů je založeno na XML a rozšiřují ho. Formáty jako HTML, XSL, WordML apod. jsou pouze specializované soubory XML.
1.2 WordML & Open XML V balíčku Microsoft Office 2007 byl uveden formát Open XML. Microsoft byl často kritizován za používání uzavřeného a binárního formátu pro své dokumenty. Poprvé byl uveden otevřený formát, který mohli číst a upravovat programy třetích stran. Jak již název vypovídá, formát je založen na XML. Pokud nahlédneme do jeho struktury, zjistíme, že struktura sice odpovídá syntaxi XML, ale je tak složitá, že ji prakticky číst nelze. Formát je ale dokumentovaný a otevřený a lze ho tedy zpracovat jinými programy.
1
Teoreticky je povolen jen jeden kořen. V praxi se často setkáváme s dokumenty s více kořeny.
9
WordML je označení pro kombinaci dokumentů aplikace Word v Open XML formátu s XML značkami. Jedná se vlastně o obyčejný dokument Word, ve kterém jsou vyznačena místa, která lze dynamicky nahrazovat pomocí XSL transformace. WordML ještě není XSLT šablona, je to vlastně dokument, který vznikne XSL transformací po sloučení s XML daty. Na tomto formátu je založen hlavní způsob generování dokumentů v mé aplikaci, protože šablony lze vytvářet jednoduše v prostředí aplikace MS Word.
1.3 PDF Zkratka PDF je tvořena slovy Portable Document Format. Je to formát vytvořený společností Adobe a zaručuje, že se daný dokument zobrazí na každém počítači stejně, nezávisle na použitém softwaru a operačním systému. Dokumenty PDF nelze snadno upravovat. To je zároveň výhoda a nevýhoda. Protože je nelze snadno upravovat, je těžké obstarat export do tohoto formátu. Ale na druhou stranu takto vytvořený dokument je většinou bezpečně uzavřen proti úpravám uživatele. Aplikace vytvořená s touto prací ukazuje některé cesty jak dokumenty PDF vytvářet. Některé způsoby jsou však problematické, protože výsledný dokument nedosahuje požadovaných kvalit. Záleží na použitém softwaru, který zajišťuje generování samotného PDF dokumentu z jiných formátů.
1.4 LaTeX & LyX LaTeX (čteno latech) je sazební systém, který využívá formátovacího stroje TeX. Jsou to vlastně makra a příkazy, které umožňují lépe využít TeX. Jeho výhoda je velice jemné pozicování textu s přesností až miliontiny milimetru. Syntaxe jazyka se zapisuje formou příkazů a textů. Používají se zde různé příkazy na tvorbu odstavců, matematických zápisů, nadpisů apod. LyX je program, který spojuje možnosti jazyka LaTeX a textového editoru. Usnadňuje zápis příkazů LaTeXu a rovnou zobrazuje text ve výsledné podobě nebo alespoň v přibližné podobě. LyX používá sice vlastní formát, který se liší od jazyka LaTeX, ale tento formát lze snadno exportovat do jazyka LaTeX, přes který se následně generuje výsledný dokument. LyX umožňuje vytvářet dokumenty v jazyce LaTeX i bez znalosti tohoto jazyka. Toho využívám při tvorbě šablon jako další možnosti tvořit formátované dokumenty.
10
2 XSLT XSLT je zkratka označující eXtensible Stylesheet Language Transformations. Jedná se tedy o podskupinu XSL, která se zabývá transformacemi XML. Jsou to pravidla, jak lze data uložená ve formě XML transformovat do jakéhokoliv jiného výstupu. Může to být například textový soubor, HTML stránka, jiný XML dokument apod. Záleží jen na tom, jak jsou nadefinovaná pravidla transformace v použité šabloně. XSLT je základem celé této práce, proto zde stručně popíši základní aspekty transformace. XSLT je standard konsorcia W3C z roku 1999. Jedná se o rozšířený způsob automatického zpracování XML dat a je hojně implementován. Architektura .NET, kterou jsem použil pro vývoj aplikací ji implementuje také přímo v základních knihovnách, takže není problém ji využít. Zaměřil jsem se jednak na použití XSL transformace, ale jsou zde uvedeny i některé nevýhody programů, které ji využívají a ty se snažím obcházet jiným způsobem. Tato práce je kombinací více přístupů tak, aby se jednoduchou cestou daly vytvářet šablony pro tiskové výstupy běžné ve firemních aplikacích.
2.1 XPath XPath je dotazovací jazyk na XML data. Je to zkratka ze slov XML Path Language. V podstatě je tento jazyk analogií ke známému dotazovacímu jazyku SQL na tabulkové databáze. XML i databáze mohou sloužit jako úložiště dat. Dokonce se někdy hovoří o tom, že oba přístupy jsou si velmi podobné. Proto také oba mají dotazovací jazyk. Způsob jakým XSLT funguje, je založený na jazyce XPath. Pomocí dotazu lze vytáhnout z XML dokumentu jakoukoliv část nebo části. Princip XSLT ve skutečnosti přiřazuje XML struktuře filtrované dotazy XPath určitý výstup, na který se značka převede. Detaily pro nás nejsou až tak důležité, protože XSLT procesor je již zabudovaný v architektuře .NET a já ho jen využiji. Syntaxi jazyka XPath je však dobré znát alespoň z části. Jeden ze způsobů, jakým obohacuji možnosti XSLT šablon, je vkládání XPath výrazů přímo do textu. Jazyk zde tedy lze využít pro lepší formátování a komplikovanější výstupy. Pro zběžné seznámení se syntaxí jazyka je výborná internetová stránka www.w3schools.com/xpath, která zde uvádí stručného průvodce základy i s názornými příklady.
2.2 Ruční psaní XSLT šablony Šablonu pro konverzi XML lze samozřejmě psát ručně. Struktura dokumentu je také XML, tak není problém použít jakýkoliv textový editor. Syntaxe není úplně složitá, je ale potřeba ovládat jazyk XPath. Při ručním psaní šablony nejsme vázáni na možnosti programů třetích stran, takže můžeme docílit rozmanitých výstupů. 11
V této práci se zabývám naopak možnostmi, jak ruční psaní XSLT šablon vynechat. Syntaxe šablon sice není až tak složitá, avšak pro opravdu široké uplatnění mé aplikace je nutné, aby téměř každý byl schopen tyto šablony vytvářet. Zaměřil jsem se tedy na ty nástroje, které umí vytvářet XSLT šablony uživatelsky jednoduchými cestami.
12
3 Aplikace Hlavní částí celé práce jsou dvě samostatné aplikace, na kterých lze názorně ukázat veškeré zde popisované techniky. Jelikož se v obou případech jedná o poměrně složité aplikace, bylo nutné zvolit pro jejich vývoj pokročilejší programovací prostředí technologie ASP.NET od firmy Microsoft. Tento jazyk je zvláště výhodný při vývoji webových aplikací, jelikož značně ulehčuje práci s objekty ve stránce a udržováním jejich stavu. V obou případech je využit jazyk C# ve verzi ASP.NET 3.5. První aplikace je nazvaná DBGenerator a slouží pouze jako podpůrná pro vývoj druhé hlavní webové aplikace Logistics. Název DBGenerator odpovídá účelu aplikace a tím je automatické generování kódu pro vytváření databáze. Logistics je název fiktivní firmy, pro kterou jsem webové stránky vytvořil.
3.1 DBGenerator DBGenerator je desktopová aplikace. Nejedná se tedy o webové stránky a lze ji spustit pouze na lokálním počítači s nainstalovanou podporou pro ASP.NET ve verzi 3.5. Při práci s databází se používají často opakované sekvence programového kódu, který lze velmi snadno dynamicky generovat a ušetřit tak nemálo času. Generování kódu pro tvorbu, správu a dotazování SQL databáze je však pouze jedna polovina funkcionality programu. Dále je generován i kód, který automatizuje serializaci všech vybraných objektů z databáze do XML, což je využito při generování výstupů. Podrobněji je vše popsáno v následujících kapitolách.
Obr. 3-1, Program DBGenerator
13
Na Obr. 3-1 je vidět formulář programu. Umožňuje mimo jiné vybrat zdrojový XML soubor, cestu pro generované soubory a další nastavení, která se týkají přesného tvaru vygenerovaného kódu. Ty nemají na vzhled vygenerovaných dokumentů v podstatě žádný vliv, pouze drobně upravují způsob práce s programovým kódem. Důležitá je ale část Default Formats for XML serialization, která přímo ovlivňuje automatickou serializaci. Veškeré nastavení je možno samozřejmě uložit, takže zůstane stejné při dalším spuštění programu.
3.1.1 Zdrojové XML Jako zdroj dat pro generování jsem zvolil formát XML. Lze pro něj totiž vytvořit schéma, které alespoň částečně kontroluje syntaxi a v dobrém XML editoru (v mém případě Visual Studio 2008) dokonce při editaci nabízí přípustné hodnoty pro urychlení zápisu.
name="CodebookEntry" comment="Ciselnik cele aplikace"> name="ID" key="true" identity="1, 1" type="int"/> name="CodebookFolderID" type="int" comment="Vazba na..."/> name="Name" type="string" length="100" unique="true"/> name="DisplayText" type="string" length="250" comment="Textova hodnota..."/> <proc name="GetByName" type="single" comment="Vrati jeden zaznam z tabulky..."> <param name="Name" direction="input" query="true"/> <param name="*" direction="none" query="true"/> SELECT * FROM [CodebookEntry] WHERE [Name] = @Name
RETURN @@ERROR
Takto vypadá zápis jednoduché SQL tabulky s několika sloupci a jednou procedurou. Z ukázky je patrné, že pomocí atributů lze nastavit téměř všechny možnosti, které databáze nabízí. Navíc lze ke každému objektu přiložit komentář, který se generuje ve standardním formátu do zdrojového kódu tak, aby se zobrazoval při používání metod a parametrů. Samozřejmě lze generovat i pravidla pro referenční integritu. Zde je například ukázka napojení na tabulku CodebooFolder včetně kaskádových pravidel a kontroly unikátnosti na sloupci Name. Definovat lze i SQL procedury včetně volby vstupních a výstupních parametrů. Hlavička procedury se vygeneruje automaticky podle použitých parametrů, avšak lze napsat i vlastní hlavičku a generovat tak například trigger.2 Používání SQL procedur je velmi výhodné, protože databázový server je nemusí při každém spouštění znovu překládat a výsledek je pak rychlejší.
2
Trigger je specielní SQL kód, který se spouští za určitých okolností (výmaz, úprava řádku, apod.). Syntaxe je velmi podobná SQL proceduře.
14
Mimo zde uvedené procedury se ještě u každé tabulky automaticky vytváří základní procedury pro dotazování objektu podle klíčových hodnot, mazání, editaci a přidávání záznamu. Dopisují se jen nestandardní procedury, pokud je například potřeba svázat více tabulek nebo výsledek nestandardně řadit.
3.1.2 Schéma zdrojového souboru Kontrola syntaxe zdrojového XML se provádí pomocí schématu ve formátu W3C XML Schema. Pro naše potřeby možnosti tohoto formátu bohatě vystačí, složitější kontrola zde není nutná.
Obr. 3-2, Schéma zdrojového XML souboru
Na Obr. 3-2 je vidět struktura celého zdrojového souboru. Jedná se vlastně jen o tabulky se sloupci, referenčními vazbami a spustitelné procedury se vstupními a výstupními parametry. Definovány jsou i typy některých atributů. Za zmínku stojí typy proctype a coltype. Proctype ovlivní zásadně tvar kódu, který obaluje data. Některé procedury pouze vybírají data a jsou přizpůsobeny pro vkládání filtrovacích a třídících parametrů. Editační procedury naopak předávají nové hodnoty SQL proceduře ve formě parametrů. Lze vytvářet i speciální typ view, který nevytváří proceduru ale objekt chovající se podobně jako tabulka. 15
DBGenerator umožňuje používat tyto typy procedur: <xs:simpleType name="proctype"> <xs:restriction base="xs:string"> <xs:enumeration value="scalar"/> <xs:enumeration value="list"/> <xs:enumeration value="single"/> <xs:enumeration value="update"/> <xs:enumeration value="view"/> <xs:enumeration value="simple"/>
Coltype určuje datový typ sloupce. Rozlišuje se mnoho hodnot od číselných, textových až po binární typy jako je obrázek. Prakticky téměř vše, co lze do databáze vložit. Důležitou součástí datových typů je soubor PropertyTypes.txt, definující způsob překladu datových typů SQL databáze na datové typy jazyka C#.
3.1.3 Automatické formátování Při XSL transformaci se do šablon vkládají objekty serializované do XML. Tento formát ale umožňuje předávat pouze textové hodnoty. Nakonec generované dokumenty jsou vlastně také pouze texty. Způsob, jak převádět číselné a jiné hodnoty na texty musí být tedy nějak definován. Aby se zachovala jednotnost celé aplikace a všech generovaných dokumentů, je zapotřebí nastavit výchozí formátování.
Obr. 3-3, Výchozí formátování textových hodnot
Z Obr. 3-3 je vidět, že aplikace umí nastavit výchozí konverzi pro pět nejpoužívanějších datových typů. Tyto hodnoty se generují přímo do zdrojového kódu. public void SetDefaultFormatsForSerialization() { SkipNullValuesBySerialization = true; IntFormat = ""; DecimalFormat = "#,#0.00;-#,#0.00;0"; DateTimeFormat = "d. M. yyyy"; TrueValue = "Ano"; FalseValue = "Ne"; }
16
Samozřejmě lze v každém konkrétním případě použít jinou konverzi, ale beze změn budou vypadat všechny dokumenty stejně. Veliký význam to má například pro formát datumové hodnoty kvůli různým způsobům zápisu v jiných zemích. Formát odpovídá syntaxi jazyka C# pro standardní převod textových hodnot metodou ToString. Výsledná část kódu pro serializaci jedné tabulky vypadá následovně: public override Dictionary<string, string> GetValuesForSerialization() { Dictionary<string, string> result = new Dictionary<string, string>(); result.Add("ID", ID.ToString(IntFormat)); result.Add("PartyID", PartyID.ToString(IntFormat)); result.Add("Name", Name ?? String.Empty); result.Add("Surname", Surname ?? String.Empty); if (!SkipNullValuesBySerialization || (Suffix != null)) result.Add("Suffix", (Suffix == null) ? String.Empty : Suffix ?? String.Empty); if (!SkipNullValuesBySerialization || (BirthDate != null)) result.Add("BirthDate", (BirthDate == null) ? String.Empty : BirthDate.Value.ToString(DateTimeFormat)); return result; }
Zavoláním této metody lze dostat serializované všechny sloupce z databázového objektu. V ukázce je vidět i použití výchozího formátu pro konverzi hodnot. V tomto případě je ještě navíc rozlišeno, zda se budou tisknout prázdné hodnoty. Prázdná hodnota sice není vidět, ale ovlivní, zda se ve výsledném XML objeví její element. To může ovlivnit výsledek XSL transformace. Tato část programu DBGenerator má tedy největší význam pro automatické generování výstupů z webové aplikace.
3.1.4 Význam při vývoji webové aplikace Jak bylo popsáno výše, tato aplikace značně zmenšila množství ručně psaného kódu. To nejen šetří čas, ale pomáhá také udržet jednotnost celého zdrojového kódu i XML výstupu serializace. Tvorba šablon je jednodušší, pokud je struktura XML všech objektů do sebe vnořených shodná. Tlačítko „Test“ ověřuje správnost syntaxe zdrojového XML souboru a vytváří testovací prázdnou databázi. Tím se ověří, zda je možno přepsat původní zdrojové kódy objektů. Strukturu testovací databáze lze využít při změně struktury databáze aplikace, aniž by se musela smazat a znovu založit. Tím by se ztratila veškerá data pro testování při vývoji aplikace. K porovnání struktur dvou databází je zapotřebí použít speciální program. 3
3
Takovým programem může být například SQL Compare společnosti Red Gate, který jsem použil při vývoji.
17
Výhodné je také využití komentářů. IntelliSense4 mimo jiné zobrazuje i komentáře připojené k metodám a funkcím. Zde používám dynamické komentáře tvořené podle parametrů SQL procedur, takže je vždy jasná referenční integrita tabulek, jaké sloupce se z databáze vybírají i použité parametry procedury.
Obr. 3-4, Referenční integrita tabulky v komentáři
Obr. 3-5, Komentář metody volající SQL proceduru
Pro srovnání zde uvedu přibližný odhad poměru ručně psaného a vygenerovaného kódu. Zdrojový soubor XML pro popis databáze má v současném stavu aplikace 25,4 kB a 442 řádků. Pouze soubor se samotným SQL kódem pro vytvoření všech databázových objektů má 49,1 kB a 2129 řádků. Každé databázové tabulce náleží jedna třída, jejíž instance představují jednotlivé řádky. Proto se generuje s každou tabulkou jeden soubor s definicí její třídy. Metody, které volají SQL procedury, výsledek dotazu správně transformují do instance v paměti. Dále obsahují metodu pro serializaci popsanou výše. Dohromady mají všechny soubory tabulkových tříd 304 kB. Výsledná úspora ručně psaného kódu je tedy značná. V tomto případě je napsáno pouze 7 % kódu. Tato úspora pravděpodobně nevynahradí práci na generátoru, ale musíme brát v úvahu i fakt, že program je víceúčelový a do budoucna se jistě jeho vývoj vyplatí.
3.2 Logistics Webová aplikace, na které ukážu generování dynamických výstupů je vytvořena pro fiktivní firmu Logistics zabývající se přepravou a pronajímáním nákladních aut. Funkcionalita stránek umožňuje vyzkoušet veškeré prvky, které budu testovat při generování dokumentů. Je potřeba vytvářet výstupy s hromadnými tisky, dynamickými i statickými obrázky a tabulkami. Aplikace je přizpůsobena tomu, aby šlo tyto prvky nastavit a následně tisknout. 4
Implementace automatického doplňování kódu od společnosti Microsoft.
18
Design a způsob ovládání webových stránek je udělán tak, aby připomínal desktopovou aplikaci.5 Možná částečně nestandardní provedení, ale je vhodné pro správu dat tohoto typu. Aplikace umožňuje otevírat nová podokna a předávat mezi okny vybrané prvky. Teoreticky lze otevřít neomezené množství podoken, která jsou vzájemně provázána. Mateřské okno se vždy znepřístupní, aby šlo ovládat pouze poslední aktivní okno. Takto je to navrženo s ohledem na zvyklosti používané v běžném operačním systému a aby se uživatel v otevřených oknech neztratil. Silnou zbraní této aplikace je tabulkové zobrazení dat. Většina dat, která je potřeba uchovávat v reálném světě lze zobrazit formou tabulky, proto je zde implementován způsob jak jednoduše data třídit, filtrovat a zobrazovat do tabulek. Stránky se v zásadě dělí na dva typy – editační a seznamové. Ty seznamové zobrazují položky v tabulkách s možností přidávat nové záznamy a ty staré vybrat pro zobrazení a úpravu v editační stránce. Ta většinou upravuje jeden konkrétní objekt, tedy jeden řádek v databázové tabulce.
3.2.1 Popis aplikace jako ERP systému Design a formu aplikace je možno použít pro postavení většího ERP systému. Pro náš účel stačí pouze drobná část z tak rozsáhlých systémů. Aplikace Logistics implementuje správu osob a firem včetně adres a kontaktů. Dále umožňuje do systému nahrávat obrázky a připojovat je k určeným objektům. Firma se zabývá přepravou, proto je v aplikaci ještě část se zakázkami a správou firemních vozů, které pronajímá. Pro skutečnou firmu si zde lze představit mnoho dalších oblastí od účetnictví až po automatickou správu skladů. Všechny ostatní části aplikace slouží k tisku dokumentů, správě tiskových šablon a vygenerovaných dokumentů. Některé výstupy se ukládají do databáze a vždy se připojují k objektu, ze kterého byly vygenerovány. U osob a firem lze tedy najít odkaz na seznam jejich generovaných dokumentů. U hromadných tisků více položek nelze dokument k ničemu připojit, proto se neukládá. V následujících kapitolách stručně popíši ovládání aplikace, vytvoření a správu databáze a nahrání šablon k tisku. To jsou nezbytné kroky k vygenerování prvního dokumentu. Tyto kroky jsou však plně automatizovány pro urychlení startu aplikace.
3.2.2 Tvorba a správa databáze Správa databáze je na samostatné stránce, která nepatří do zbytku aplikace. Slouží k prvnímu vytvoření databáze a lze k ní přistoupit i bez již existující databáze, kdežto samotná aplikace nemůže být bez databáze ani spuštěna.
5
Proto budu webové stránky nazývat výrazem webová aplikace. Z programového hlediska i hlediska uživatelského se vlastně jedná o aplikaci pouze prezentovaná formou webových stránek.
19
Tato stránka je přístupná na adrese /Logistics/Admin/Default.aspx a je chráněna samostatným heslem. Později je tato stránka přístupná i z aplikace. DBGenerator vytvořil metodu pro vytvoření kompletní databáze, z této stránky lze tuto metodu spustit. Dále je zde možné vytvořit prvního uživatele jménem „config“ a naplnit databázi testovacími daty. Do aplikace se s testovacími daty nahrají i některé obrázky a tiskové šablony, které se nejčastěji používají pro testování funkčnosti. Veškeré tyto kroky lze spustit ve správném pořadí jedním tlačítkem „Kompletní obnova“. Pokud se vyskytne chyba, je uložena do souboru err.log, který zde lze také zobrazit.
Obr. 3-6, Náhled celé databáze Logistics
Nejdůležitějšími tabulkami z celé databáze jsou tabulky ConvertTemplate a TableExportStyle. Tyto přímo obsahují nahrané šablony a nastavení výstupů. Ostatní tabulky jen ukládají data samotné aplikace, která lze následně exportovat do dynamických výstupů.
20
3.2.3 Použité typy výstupů Jádro většiny dokumentů tvoří serializovaná XML data objektů v databázi. 6 Výjimku tvoří pouze export tabulek, které se zpracovávají jiným způsobem. Avšak i pro tento export je využit stejný XmlSerializer, jako u ostatních postupů.7 Pro generování tabulek jsou použity tři různé typy formátů: • • •
HMTL soubor Sešit aplikace MS Excel ZIP soubor obsahující tabulku MS Excel a připojené obrázky
Obyčejné dokumenty netabulkového typu lze generovat ve více různých formátech. Primárním cílem této práce je generování dokumentů ve formátu MS Word a PDF. Konverzní servery třetích stran, které tato aplikace využívá, umožňují konverzi do dalších formátů. Některé z nich jsou též implementovány v aplikaci a lze pro ně utvořit šablonu. Slouží zde ale spíše jen pro ukázku, že konverzní servery mají širší využití. Exportovat lze tyto formáty: •
Dokument MS Word
• •
Dokument MS Word 97 – 2003 Portable Document Format (PDF)
• • •
Rich Text Format (RTF) XML Paper Specification (XPS) Obrázek ve formátu PNG
• •
PostScript (PS) HTML soubor
• •
Scalable Vector Graphics (SVG) Jakýkoliv další formát, který lze definovat XSLT šablonou
Některé formáty nelze využít pro hromadný tisk, protože při konverzi se převede pouze první stránka. Problému hromadného tisku se podrobněji budu věnovat v dalších kapitolách.
3.2.4 Nahrávání šablon Aby generované dokumenty mohly být opravdu dynamické, musí aplikace umožnit uživatelsky změnit šablonu pro konkrétní typ výstupu. Veškeré šablony nahrané do systému uchovává tabulka ConvertTemplate. Je zde uložena samotná šablona, pokud je potřeba tak i její XSLT verze, typ akce a typ šablony.
6
Nemusí se jednat pouze o data přímo z databáze, teoreticky lze do XML exportovat cokoliv, data jakkoliv upravit, třídit, sumarizovat apod. 7 XmlSerializer je třída obstarávající serializaci dat do XML struktury. Pro každý typ objektu je vytvořen její potomek, který si sám určí výsledný tvar a obsah XML dat.
21
Typ šablony určuje, jakým způsobem a v jakém formátu bude konečný výstup generován. Lze zvolit ze všech výše uvedených formátů pro generování obyčejného dokumentu. Pro některé formáty je možné zvolit vícero postupů, jak dokument vytvořit. Například formát PDF lze získat třemi různými cestami. Typ akce určuje k jakému objektu v systému je šablona připojena. Podle akce se rozlišuje tisk osob, firem, zakázek a katalogu vozů. Editační okno pro šablony je v sekci Výstupy. Systém od prvního naplnění databáze některé vytvořené šablony již obsahuje, lze tedy tyto upravit nebo přidat nové. Panel pro nahrávání dat šablony je nejdříve skryt, zobrazí se až po uložení názvu šablony do databáze. Hodnota Multišablona určuje, zda lze šablonu použít pro hromadný tisk. Systém to ovlivní pouze tak, jestli se šablona zobrazí v seznamu pro tisk u více prvků dohromady. U tisku konkrétního objektu se nabízí vždy všechny šablony. Jestli toto políčko můžeme zaškrtnout, záleží na typu šablony a také na samotné šabloně. Více tento problém rozeberu později. Po uložení základních informací o šabloně lze nahrát samotnou šablonu. Zde je důležité mít správně vybrán typ šablony, protože to rozhoduje o formě, jakou se dále data zpracují. Kontrola vstupního souboru se neprovádí, takže je na uživateli, aby nahrál správnou šablonu. U některých typů formátu ještě musí dojít ke konverzi na XSLT tvar šablony, aby mohla být dále použita. Pokud dojde při konverzi šablony k nějaké chybě či varování, je uloženo i se šablonou do systému a zobrazeno uživateli. To se může využít při testování výstupů. Pokud je zde vše správně nastaveno, měla by se šablona zobrazit na správném místě v nabídce pro tisk objektů.
3.2.5 Stylování tabulek V sekci výstupy je také stránka s nastavením exportu tabulek. Zde lze definovat vzhled exportovaných tabulek. Umožněno je nastavovat zvlášť rámečky a výplně řádků včetně rozlišení sudých a lichých řádků. Styly, které lze nastavit, odpovídají možnostem kaskádových stylů z HTML jazyka. Vnitřně se totiž tabulky také generují v HTML formátu a to i pro MS Excel. Barvy lze zapisovat všemi způsoby, které povolují kaskádové styly, tedy šesti a třímístný hexadecimální zápis nebo slovní název barvy v anglickém jazyce. Dole ve stránce je náhled tabulky, jak vypadá aplikování veškerých stylů do HTML. Při konverzi do MS Excel dojde k částečnému zkreslení, takže náhled nemusí plně odpovídat konečnému výsledku. Nastavení lze vždy vrátit do původního stavu, který je barevně podobný zobrazení tabulek v aplikaci. Toto nastavení neovlivňuje, jak se tabulky zobrazují v aplikaci, pouze ovlivní export do dalších formátů.
22
3.2.6 Ukládání generovaných dokumentů Třetí položkou v sekci výstupy je seznam generovaných dokumentů. Zde je přehled všech exportů, které byly v aplikaci vytištěny a uloženy. Některé exporty se zatím neukládají, protože je nelze spojit s konkrétním objektem. Soubory se ukládají podobně jako obrázky do souborového systému aplikace. Každý takový soubor má jeden záznam v tabulce StoredFile s doplňujícími informacemi. Ta je společná pro obrázky i dokumenty. Další tabulka GeneratedDocument spojuje tento soubor s použitou šablonou, takže lze dokumenty zpětně dohledat i podle typu šablony a vždy stáhnout ve správném formátu. Mimo tento kompletní seznam lze dokumenty nalézt i u konkrétních exportovaných objektů. Například v editaci osoby se seznam vytřídí tak, aby se zobrazily pouze vytištěné dokumenty konkrétní osoby.
23
4 Generování dokumentů Proces vygenerování dynamického dokumentu je poměrně dlouhý a dělí se do několika fází. V této práci budu každou část popisovat zvlášť. Celý proces začíná vytvořením šablony a končí stažením hotového dokumentu z aplikace.
Obr. 4-1, Celý proces generování dokumentu
Na Obr. 4-1 je vidět celý proces generování dokumentu. Některé fáze nejsou vždy povinné, toto je kompletní výčet. Podle typu šablony mohou být některé fáze vynechány. Výjimkou je šablona založená na LaTeXu, kde používám vlastní typ transformace místo XSLT.
4.1 Microsoft XSLT Inference Tool Společnost Microsoft vydala v roce 2004 nástroj umožňující konvertovat Word dokument na XSLT šablonu. Jedná se o velmi dobrý nástroj pro tvorbu šablon. Šablony totiž může nyní vytvářet každý, kdo umí pracovat s aplikací MS Word i bez hlubších znalostí XSLT. Celá aplikace je zdarma ke stažení na stránkách firmy Microsoft a její instalace je doplněna o podrobný návod, jak vytvářet šablony. 8
8
Stav v listopadu 2010.
24
Celý nástroj se vlastně skládá z jednoho spustitelného souboru, kterému se předávají parametry z příkazové řádky, a případné chyby vypisuje na standardní výstup. Jazyk C# samozřejmě umí spouštět a ovládat procesy a při spuštění jim předávat parametry, tak není problém aplikaci zakomponovat do celého systému. Nástroj je napsán v .NET architektuře, takže lze dekompilovat zpět na zdrojový kód a používat ho přímo jako součást aplikace, avšak toto není povoleno licencí. Licence bohužel hovoří i o faktu, že nelze aplikaci použít pro finanční zisk poskytováním služeb třetím stranám s tímto softwarem. Je však otázkou, jak přesně je věta v licenčním ujednání myšlena. Možná nelze nabízet služby tohoto softwaru třetím stranám, ale hotové šablony přitom použít pro generování dokumentů třetím stranám lze.9
4.1.1 Parametry transformace Nástroj umožňuje částečně ovlivnit, jakým způsobem se výsledná XSLT šablona bude chovat. Definuje celkem 9 parametrů, které lze použít z příkazové řádky. Parametr
Význam
-db
„Data binding“ mód
-mx
Elementy mohou obsahovat složitější obsah jako například obrázky
-nf
Šablona je vždy vygenerována i přes chybové stavy
-ns
Jmenný prostor použitý v XML datech
-nsa
Všechny jmenné prostory použité v šabloně se zpracují
-o
Cesta výstupního souboru
-oi
Potomci uzlu budou seřazeni, tak jak jsou seřazeni v XML datech (výchozí stav)
-os
Potomci uzlu budou seřazeni, tak jak jsou seřazeni v šabloně
-v
Výpis více informací při konverzi Tab. 4-1, Parametry nástroje(1)
Pro naše účely jsou důležité hlavně parametry pro definování výstupního souboru a definování jmenného prostoru. Ostatní parametry nejsou nezbytně nutné pro vytvoření správné XSLT šablony. Aplikace by však měla mít možnost doplnit při nahrávání dat šablony i tyto parametry ke konverzi aby bylo možné využít všech možností, které nám nástroj nabízí. Zatím toto implementováno není a šablony se vytváří podle výchozího nastavení.
9
V originále licenční smlouvy je napsán text: „You may not rent, lease, lend or provide commercial hosting services to third parties with the Software.“
25
4.1.2 Chybová hlášení konverze Při testování různých šablon jsem zatím narazil pouze na jedno chybové hlášení nástroje, že textový uzel obsahuje více různých formátování. Tato hláška vyplývá ze způsobu, jakým se provádí transformace. Pouze nám říká, že v XML značce pro nahrazení hodnoty bylo použito více různých formátování a nástroj si musí z jednoho vybrat. Při XSL transformaci nelze použít více stylů pro jeden textový uzel, proto se použije jen jeden z nich. Toto varování se vyskytuje velmi často, protože při vytváření šablon lze jen obtížně zajistit, aby každý textový uzel měl stoprocentně jednotné formátování. Pokud jsme s výsledkem při generování dokumentů spokojeni, můžeme tuto hlášku ignorovat.
4.2 Serializace do XML Část transformace, kdy se data uložená v aplikaci převádí na předem danou strukturu, se nazývá XML serializace. Aby mohla XSL transformace fungovat, musí mít data přesně danou strukturu. Aplikace Logistics je navržena tak, že struktura XML při serializaci je pevně daná a lze ji měnit jen změnou zdrojového kódu. Dynamičnost je zajištěna šablonou. Výsledné XML musí být navrženo tak, aby šlo co možná nejlépe využít v šablonách a měli jsme volnou ruku v možnostech, jak data zobrazit. V praxi toto není zcela možné, vždy se dostaneme do situace, kdy je potřeba XML strukturu upravit tak, abychom byli schopni nějakou část zobrazit na určitém místě v dokumentu. Jsou zde implementovány ale i další mechanismy, které toto riziko zmenšují. Cílem je navrhnout takovou strukturu, aby se do zdrojového kódu nemuselo nikdy zasahovat, protože to je nejnákladnější. Úprava šablony je triviální záležitostí. V této části budu popisovat jak je serializace řešena programově. Tu je také velice důležité dobře navrhnout, protože když dojde na situaci, že se nevyhneme změně ve struktuře XML, tak by měly být úpravy co nejrychleji a nejsnáze proveditelné.
4.2.1 Automaticky generovaný kód Základ celé serializace tvoří automaticky generovaná část z programu DBGenerator. Program připraví jednu metodu, která vloží všechny sloupce z databázového objektu do XML v elementech stejně pojmenovaných, jako sloupec v databázi. Tím je zajištěno, že všechny hodnoty uchovávané v databázi se nemusí ručně přidávat a exportují se automaticky. Přidávají se jen další hodnoty potřebné na výstupu, které jsou nějak upraveny. Generovaný kód jsem popsal již v části 3.1.3. Zde jen zdůrazním, že tato metoda vrací slovník obsahující název hodnoty (název sloupce v databázi) a hodnotu konkrétního objektu (buňka v databázi). Díky tomu lze metodu zavolat a vložit hodnoty objektu na jakékoliv místo nebo je jinak před vložením do XML zpracovat.
26
4.2.2 Využití objektového přístupu Celý systém tříd pro serializaci je navržen tak, aby co možná nejméně kódu bylo psáno ručně. Navíc musí být možno jednotlivé části XML do sebe vnořovat a zachovat stejnou strukturu u stejných objektů, aby se zjednodušilo tvoření šablon a omezily se typické chyby při jejich vytváření, jako je špatně vnořený element, což způsobí nevygenerování některé části textu. Základem je třída XmlSerializer. Funguje pouze jako předek a nelze ji použít přímo. Od ní dědí všechny typy výstupů podle typu objektu, pro který se serializace dělá. Ty odpovídají typům šablon. V aplikaci Logistics jsou zatím definovány jen 4 typy: • •
Osoba Firma
• •
Vůz Zakázka
Každý tento typ má svůj vlastní XmlSerializer, který se stará jen o naplnění samotného XML metodou FillXmlData. Předek se postará o správný obal dat, kořenový element a vloží do dat i jmenný prostor, který se musí shodovat se zvoleným prostorem v šabloně. Druhý důležitý předek je třída BaseTable, která funguje jako společný předek všem třídám tvořeným z databázových tabulek. Každá tabulka, která je definovaná ve zdrojovém XML souboru programu DBGenerator, vytváří stejnojmennou třídu obsahující všechny sloupce jako hodnoty. Instance této třídy pak představuje jeden konkrétní řádek tabulky. Třída BaseTable definuje tyto základní metody pro použití při serializaci: •
AddObjectToXml
•
GetValuesForSerialization
•
AddValuesAfterDefaultSerialization
Zdrojový kód metody AddObjectToXml: public void AddObjectToXml(XmlHelper xh, string mainTag) { xh.WriteStartElement(mainTag); xh.AddElements(GetValuesForSerialization()); AddValuesAfterDefaultSerialization(xh); xh.WriteEndElement(mainTag); }
27
Zde je vidět volání všech metod. AddObjectToXml volá již dříve zmiňovanou metodu
GetValuesForSerialization.
Ta
přidá
všechny
automaticky
generované hodnoty objektu. AddValuesAfterDefaultSerialization je prázdná metoda a nic nedělá. Potomek třídy BaseTable ji ale může přetížit a přidat další hodnoty, které se vždy budou generovat s tímto objektem. Parametr mainTag je nepovinný a rozhoduje, do jakého uzlu budou elementy vnořeny. Mohou být vloženy též přímo bez nadřazeného elementu. public override void AddValuesAfterDefaultSerialization(XmlHelper xh) { base.AddValuesAfterDefaultSerialization(xh); xh.WriteAddresses("Addresses", PartyID); xh.WriteContacts("Contacts", null, true, PartyID); }
Takto může vypadat metoda AddValuesAfterDefaultSerialization. Tato je vyjmuta ze třídy Company, která uchovává informaci o jedné firmě. V tomto případě se s každou firmou vždy generují i adresy a kontakty firmy do uvedených nadřazených elementů. Ve třídě XmlSerializer je nejdůležitější metoda GetXmlData, která vrací kompletní serializované XML. Významná je tato část kódu: xmlWriter.WriteStartDocument(); xmlWriter.WriteStartElement(root, ns); foreach (object iterationParameter in ObjectIterationParameters) { xmlWriter.WriteStartElement(DefaultNewObjectTag); FillXmlData(xh, iterationParameter); xmlWriter.WriteEndElement(); } xmlWriter.WriteEndElement(); xmlWriter.WriteEndDocument();
Takto vypadá volání metody FillXmlData z hlavního předka celé serializace. Je zde vidět, jak se vkládají kořenové elementy kvůli správné syntaxi XML výstupu a spárování se šablonou. Iterace přes parametry je zde z důvodu možnosti hromadného tisku. Data se pro každý objekt tisknou ve stejné struktuře, jen se oddělí nadřazeným elementem, aby bylo možné v šabloně jednotlivé objekty odlišit. Typicky se pak pro tento element použije formát, který zajistí stránkování dokumentu tak, aby každý objekt byl na samostatné stránce. Iterační parametr může být například ID záznamu v tabulce, podle kterého přetížená metoda pozná, jaký objekt má generovat.
28
protected override void FillXmlData(XmlHelper xh, object iterationParameter) { int partyID = (int)iterationParameter; Person person = Person.DBGetByPartyID(DataAccess, partyID); person.AddObjectToXml(xh, null); xh.WriteSysUser(UserInfo, "SysUser", true, true); xh.WriteDateAndTime(null); }
V ukázce je přetížená metoda FillXmlData ze třídy Person pro generování XML jedné osoby. Podle iteračního parametru se vytáhne správný objekt z databáze a poté stačí pouze na tomto objektu zavolat metodu AddObjectToXml, která se již sama postará o vložení veškerého XML spojeného s osobou. Dále se zde ještě vkládá informace o přihlášeném uživateli a aktuální datum. Tento způsob umožňuje velmi snadno kombinovat vnořené objekty zavoláním pouze jediné metody. Na jednoduchém objektu, jako je osoba, se to zcela neprojeví, ale v budoucnu může být aplikace použita pro rozsáhlý ERP systém, ve kterém bude potřeba serializovat složité objekty. Z tohoto pohledu je v aplikaci nejsložitější objekt Case představující jednu zakázku firmy. Metoda pro přidání dalších dat do XML, které se negenerují automaticky, vypadá takto: public override void AddValuesAfterDefaultSerialization(XmlHelper xh) { base.AddValuesAfterDefaultSerialization(xh); Party.GetPartyObject(xh.DataAccess, OwnerPartyID.Value, out type).AddObjectToXml(xh, "Owner" + type); Party.GetPartyObject(xh.DataAccess, CustomerPartyID.Value, out type).AddObjectToXml(xh, "Customer" + type); QueryParams qp = new QueryParams(); qp.AddWhereCondition(true, "CaseID", ID, null, false, "="); var caseCarList = CaseCar.DBGetList(xh.DataAccess, qp); foreach (var caseCar in caseCarList) { Car.DBGet(xh.DataAccess, caseCar.CarID).AddObjectToXml(xh, "Car"); } xh.AddElement("Profit", Profit.ToString(DecimalFormat)); }
Tato ukázka není zcela kompletní, některé podmínky jsou pro jednoduchost odstraněny. Je zde ponechána ta část, na které je nejlépe vidět, jak snadno lze do sebe vnořovat objekty do výsledného XML. Nejdříve se přidají do zakázky data zákazníka a vlastníka zakázky, což může být firma nebo osoba. Poté se z databáze vyberou pronajatá auta a všechna se serializovaná vloží do XML.
29
4.2.3 Vnoření serializovaných objektů Při vkládání objektu metodou AddObjectToXml je možné rozhodnout parametrem mainTag, jestli a do jakého nadřazeného elementu se hodnoty vloží. Někdy je potřeba objekt neoddělovat od ostatní struktury. Pokud se naopak tiskne více podobných objektů v řadě a v šabloně se organizují do tabulek, musíme je oddělit nadřazeným uzlem. Oddělovat je potřeba též objekty, které obsahují shodné názvy sloupců, aby při XSLT nedocházelo ke kolizi hodnot a dalo se rozlišit, který formát se použije pro každou hodnotu. Příklad, kde jsem musel ve struktuře oddělit hodnoty je u objektů obsahujících datum s názvem Date.
Uzel Printed odděluje datum a čas vytištění dokumentu, který se vkládá s každým serializovaným objektem. U osoby to není potřeba oddělovat, protože osoba neobsahuje hodnotu Date. Zanořením se změní cesta k elementu a lze pak rozlišit datum vytištění dokumentu a datum výroby vozu.
4.3 Generování dokumentu MS Word S použitím XSLT Inference Tool (viz 4.1) lze velmi jednoduše generovat dokumenty pro aplikaci MS Word. Novější verze balíčku MS Office podporují tzv. Open XML formát dokumentů. Ten samý dokument lze uložit ve více formátech, takže zobrazený vypadá stejně, ale data jsou zcela jiná. XML verze je otevřená a syntaxí zcela odpovídá pravidlům formátu XML, což velice zjednodušuje další zpracování, nebo generování dokumentu. Pomocí XSLT lze právě takové struktury, jako je XML, snadno generovat. Díky této možnosti mohl vzniknout i nástroj pro konverzi Open XML dokumentů na XSLT šablonu. Společnost Microsoft tento nástroj zveřejnila a nabídla zdarma ke stažení a tím umožnila generování dokumentů pro MS Word prakticky komukoliv.
4.3.1 Tvorba šablon Nástroj pro konverzi šablon obsahuje i názorný návod jak šablony vytvářet a upravovat. Celý návod je poměrně stručný, protože vytváření šablon je v podstatě stejně složité, jako vytvořit obyčejný dokument v programu MS Word.
30
Je nutné se naučit pouze pár základních pravidel jak vkládat XML značky na místa, která se mají při XSLT dynamicky měnit. Nebudu zde překládat dodaný návod k nástroji, popíši spíše můj způsob, který mi přijde nejrychlejší a nejlepší pro vytvoření šablony. Zaměřím se na některé aspekty, které jsou v praxi důležité u dokumentů pro firmy podobných jako je Logistics. U složitějších šablon je potřeba jistá zkušenost s některými „triky“. Někdy je obtížné docílit dynamického obsahu na místech, která jsou mimo odpovídající strukturu XML. Většinou se dá vše řešit pomocí plovoucích textových polí a podobných prvků. Nejnáročnější může pak být situace, kdy tiskneme data na již předtištěný papír, jako je například obálka či složenka. Pak vytvoření takové šablony může trvat i hodiny, kdy přesně umisťujeme prvky ve stránce tak, aby se generovaly do správných míst.
Word jako nástroj pro tvorbu šablon Než začneme vytvářet první šablonu, je potřeba znát strukturu XML dat. Tu lze ručně vytvořit podle zdrojového kódu serializace objektu. Další možností je použít přímo XML generované jako vsup do transformace. Aplikace Logistics umožňuje stažení generovaného XML.
Obr. 4-2, Nabídka tisku podle konkrétní šablony
Takto vypadá v aplikaci jedna tisková šablona. Obsahuje tři aktivní tlačítka: •
Ikona Word: tisk hotového dokumentu
• •
Ikona XML: zobrazení objektu serializovaného do XML Ikona M: zobrazení značek pro dodatečné úpravy
XML data se stahují jako textový soubor s příponou TXT, aby šla snadno prohlížet. Pokud soubor uložíme s příponou XML a otevřeme v aplikaci MS Word, můžeme rovnou začít vytvářet šablonu. Na Obr. 4-3 je znázorněn serializovaný vůz do XML. Toto už je vlastně první nejjednodušší šablona. Pokud bychom ji bez úprav nahráli do aplikace Logistics, bude pouze vypisovat tyto hodnoty s tím, že se nahradí obsah uvnitř značek za data konkrétního vozu. Aby šel soubor použít jako šablona, musíme ho uložit ve správném formátu.
31
Obr. 4-3, Zobrazení XML v aplikaci MS Word
Obr. 4-4, Uložení šablony WordML
Při ukládání je důležité, aby nebylo zaškrtnuté políčko „Uložit pouze data“, jak ukazuje Obr. 4-4. Tím by se zrušilo veškeré formátování a uložila se pouze XML struktura. Bez zaškrtnutí se uloží dokument, který na první pohled vypadá jako obyčejný dokument MS Word. Vnitřně má však jinou strukturu, která se nazývá WordML.10
Význam XML značek při úpravě WordML šablony WordML je tedy vlastně naformátovaný dokument aplikace MS Word obsahující XML značky pro dynamické nahrazování obsahu při XSL transformaci. Zobrazit a skrýt XML obsah lze stiskem kláves „Shift + Ctrl + X“. Pokud je XML obsah skrytý, vypadá šablona přesně tak, jak bude vypadat po XSL transformaci, pouze bude nahrazen obsah uvnitř vyznačených elementů. Obsah mimo elementy zůstane stejný, můžeme ho tedy využít pro statické popisky dynamických částí a úpravu okolní grafiky.
10
WordML je vlastně Open XML formát pro šablony s XML značkami.
32
Obr. 4-5, Úprava WordML šablony
Na Obr. 4-5 je zobrazena šablona již částečně upravená a připravená k použití. Obsahuje statický text, zarovnání elementů tabulátorem a další drobné úpravy. Při porovnání s generovaným XML vozu, si můžeme všimnout, že zde chybí značka pro element ID. To co není v šabloně, bude při transformaci ignorováno. Takto lze skrýt obsah, který nechceme na konečném výstupu. Pro jeden objekt může existovat více různých šablon a každá bude zobrazovat jen svoji část, pro kterou byla určena. Jeden důležitý aspekt, který ovlivní chování značek, je jejich barevné zobrazení. Některé jsou fialově podbarveny. WordML rozlišuje pouze tyto dva druhy značek. Rozdíl je v tom, že ty bílé mohou uvnitř obsahovat statický text včetně dalšího formátování a odřádkování. Ty fialové nemohou obsahovat odřádkování a měly by mít obsažen pouze jeden styl formátování. 11 Pokud v elementu není žádné odřádkování a zapíšeme před něj text, automaticky se změní na fialově podbarvený. Způsob jak ho změnit zpět na nepodbarvený mi není znám. Jediná možnost jak to udělat je nakopírování nepodbarveného elementu se stejným jménem z jiného místa.
Možnosti a omezení šablon Podrobnější návod, jak přesně vkládat značky do dokumentu můžeme nalézt u konverzního nástroje od společnosti Microsoft. Zdůraznit zde chci pouze možnost tvorby tabulek, protože ta je v praxi často potřeba.
11
Pokud má fialová značka v sobě více formátování, tak není jasné, který se má použít a při konverzi na šablonu a nástroj vypíše varování. Není to ale chyba, kvůli které by nešla šablona použít.
33
Obr. 4-6, Tvorba dynamických tabulek
Tabulka na Obr. 4-6 může být použita pro hromadný tisk více vozů. Každý vůz je v samostatném elementu Object. Pokud je takto vložen do řádku tabulky, bude se s každým objektem automaticky generovat nový řádek. Teoreticky je možné upravit šablonu i tak, aby se generoval každý sudý řádek jinak podbarvený. Formát lze rozlišovat i podle atributů v elementech, takže stačí upravit XML serializaci, aby se každý druhý objekt generoval s jiným atributem. Velkým omezením těchto šablon je, že nelze vložit značku do oblasti záhlaví a zápatí. 12 V praxi je u firemních dokumentů často potřeba dynamicky generovat záhlaví a zápatí. Například jméno uživatele, který dokument vytiskl nebo datum tisku dokumentu. Toto řeším jiným způsobem pomocí dodatečných úprav dokumentu, který popíši později. Další častý problém je, pokud chceme vložit dynamický text na místo, které leží mimo oblast nadřazeného elementu. Aby správně fungovala XSL transformace, musí být elementy v dokumentu v sobě vnořeny přesně tak, jak se generuje XML. Pokud značka leží mimo tuto strukturu, tak se ignoruje. Jedno řešení může být vložení textového pole do oblasti nadřazeného elementu s pevným ukotvením a textové pole pak posuneme mimo tuto oblast. Toto je však velmi složitý postup, často v něm vznikají chyby a výsledná šablona je velmi nepřehledná.
Obr. 4-7, Element mimo oblast 12
Ve skutečnosti tam značku vložit lze, ale nelze ji pak zařadit do kořenového elementu. Značky v záhlaví a zápatí prakticky tedy použít nelze.
34
Na Obr. 4-7 je chybné vložení elementu WholeName mimo oblast nadřazeného elementu. Tento způsob nefunguje, protože druhá část dat se úplně vynechá. V některých případech lze toto řešit opět pomocí dodatečných úprav dokumentu. Poslední veliká nevýhoda tohoto přístupu je nemožnost tvorby dynamických obrázků. Grafika lze vkládat do elementů a generovat ji i opakovaně, ale generují se vždy pouze obrázky použité přímo v šabloně. Bez možnosti dynamicky měnit obrázky však nebude tento systém v praxi použitelný. Změna obrázků je tedy také řešena dodatečnými úpravami přímo v datech vygenerovaného dokumentu.
Jmenné prostory Pokud otevíráme XML data v aplikaci MS Word, musí již být v nějakém jmenném prostoru. Ve značkách sice jmenný prostor není graficky znázorněn, ale v pozadí šablony je uložen a je velice důležitý pro správnou funkci XSL transformace. Pro aplikaci Logistics se generuje veškeré XML ve jmenném prostoru LogiscticsDocument.
