PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY
DIPLOMOVÁ PRÁCE
Technologie pro tvorbu webových textových editorů
2011
Radim Boušek
Místopřísežně prohlašuji, že jsem celou práci včetně příloh vypracoval samostatně.
Přílohu A., danou mi k dispozici, jsem samostatně doplnil.
2. duben 2011
Radim Boušek
i
Anotace Diplomová práce se věnuje průzkumu a zhodnocení stávajících webových technnologií vhodných pro tvorbu webových editorů. Ve zkoumaných technologiích byly vytvořeny prototypy, které jsou schopné formátovat text zhruba na úrovni RTF a exportovat dokument do formátu PDF s napojením na produkty firmy GMC Software Technology.
ii
Děkuji Mgr. Martinu Dostálovi, Ph.D. za odborné vedení této diplomové práce. Ing. Vladimíru Jirákovi z firmy GMC Software Technology za ochotu, poskytování rad a materiálů k práci.
iii
Obsah 1. Cíl diplomové práce 1.1. Očekávaná funkčnost prototypu . . . . . . . . . . . . . . . . . . .
Cílem je zhodnocení možností textového formátování v různých webových technologiích a vytvoření prototypu webového editoru (s možností textového formátování zhruba na úrovni RTF), který bude transformovat text (kód) generovaný editorem do jednoho z následujících formátů: (RTF, DOCX, PS, PDF) nebo jiného jazyka (formátu) převoditelného na tyto formáty. S těmito formáty umí pracovat PNetT („Téčko“, produkt na tisk a zpracování dokumentů firmy GMC Software Technology). Téčko umí na základě interního firemního formátu TSgml1 generovat dokument PDF atd. Jedním z dalších cílů je zjištění, ve které technologii se nejsnáze provede převod na podporovaný dokument. Tj. která webová technologie je nejvhodnější na vytvoření editoru a následnou transformaci do dokumentu (např. PDF). Problematika zahrnuje nastudování možností webové editace textu vybraných technologií, porozumění interní reprezentaci textu (včetně formátu TSgml), vytvoření editoru, exportu do jednoho z cílových dokumentů (PDF, RTF apod.). Vhodné je zapojení produktů firmy GMC Software Technology při vytvoření prototypového řešení, zejména využití interního formátu TSgml. Firma GMC Software technology již takový editor má, ale ne ve zkoumaných technologiích. Tato práce slouží jako vodítko pro nalezení nejvhodnější technologie a její následné nasazení. Obecné možnosti realizace (A, B) jsou zobrazeny na Obr.1: 1 Jedná se XML notaci obsahu textového dokumentu, z níž lze vygenerovat různé typy dokumentů (PDF,Docx atd.), viz specifikace formátu v První příloze. K vytvoření PDF kromě tohoto XML je potřeba i předdefinovaná šablona dokumentu zvaná WFD, kterou je možné vytvořit v produktu PNetT. Soubory TSgml a WFD tak spolu tvoří nejmenší základ pro vytvoření dokumentu (např. PDF) pomocí produktů od firmy GMC Software Technology.
1
Obrázek 1. Obecné řešení.
1.1.
Očekávaná funkčnost prototypu
Seznam konkrétních požadavků, které by měl editor splňovat, nebyl ani v zadání ani ze strany GMC Software Technology formálně specifikován. Důvodem byl i fakt, že některé prvky je možné implementovat v jedné technologii, zatímco u druhé technologie se může stát, že tento prvek není proveditelný. Ústní formou ze strany GMC Software Technology však byla předána představa toho, co by editor mohl obsahovat a jak by měl fungovat. Základní představa editoru vychází z toho, že je potřeba vytvořit webový editor s možností bohatého formátování textu a možností exportu textu do jednoho z formátů (PDF, Docx, PS) pomocí firemních produktů. Alternativní cesta, která by byla jednodušší a nepoužila by firemní produkty k vytvoření dokumentu, by byla pro firmu GMC Software Technology také zajímavá. Základní prvky, které by editor měl obsahovat jsou tyto: velikost písma, druh písma, styl písma (tučné, podtržené a kurzíva), barva písma. Vhodné by bylo zjistit, jak je to například s implementací složitějších prvků jako je tabulka, odstavec, odsazení, výška řádku apod. Volba těchto prvků a jejich implementace záleží na volbě diplomanta, vzhledem k možnostem, které nám 2
konkrétní technologie nabízí. Další částí je export webové reprezentace formátovaného textu do dokumentu se snahou zachovat formátování textu vytvořeného uživatelem ve webovém editoru i v dokumentu. Pro firmu GMC Software Technology je klíčové zhodnocení možností a poznatků o tom, co je v dané technologii proveditelné a co není, a jaké jsou způsoby řešení konkrétních prvků a problémů. Žádoucí jsou i konzultace s firmou GMC Software Technology o technickém řešení prototypu.
3
2.
Stávající webové textové editory
V této kapitole se seznámíme s běžně dostupnými textovými editory na webu. Dále obsahuje jejich stručný přehled a charakteristiku. Jsou zde popsány jejich možnosti a funkcionality, odkaz na stránky, kde je možné si buď daný editor vyzkoušet, nebo zdarma stáhnout.
2.1.
Google Docs (Writerly)
Pod službou Google Docs (původně Writerly) můžete nalézt velice propracovanou online aplikaci, která zastupuje celý kancelářský balík programů: textový editor, tabulkový procesor a program pro tvorbu prezentací. Textový editor je poměrně dost přehledný, nabízí řadu funkcí známých z klasických aplikací, které pracují s textem. Dokumenty lze ukládat do šesti různých formátů: .ODT (OpenOffice), .DOC (MS Word), PDF, RTF, obyčejný text (.TXT), HTML. Dokumenty lze pak dále sdílet na webu či publikovat na blogu. Možnosti textového editoru: ∙ Umožňuje základní nastavení dokumentu, podporuje 11 fontů (mezi nimi např. Verdana, Tahoma, Garamond, Courier atd.). ∙ Podporuje psaní přes celou obrazovku. ∙ Umožňuje tisk dokumentů. ∙ Pamatuje si i starší verze daného dokumentu (je možno se k nim vrátit, porovnat je mezi sebou). ∙ Umožňuje vkládat obrázky, tabulky, zarovnávat text, vytvářet seznamy a číslované seznamy. ∙ Umožňuje spočítat počet slov, kontrolovat český (anglický, slovenský) pravopis. ∙ Umožňuje ukládání do formátů: ODT (OpenOffice), .DOC (MS Word), PDF, RTF, obyčejný text (.TXT), HTML.
4
Obrázek 2. Google Docs. Vzhledem k tomu, že soubory se ukládají na server, je nutné si pro používání této služby (zdarma) vytvořit účet na stránce http://www.google.com. Pokud již takový účet máme, stačí se pod ním přihlásit. Adresa: http://docs.google.com
2.2.
TinyMCE
TinyMCE Editor je platformově nezávislý, JavaScript HTML WYSIWYG2 webový editor vydaný jako Open Source pod LGPL od Moxiecode Systems AB. Je schopný převádět textové HTML pole nebo jiné HTML elementy do instancí editoru. TinyMCE je velmi jednoduché integrovat do dalších jiných webových systémů. Implementace - HTML, JavaScript. Rysy TinyMCE: ∙ Jednoduchá integrace - Potřeba jen pár řádků kódu. ∙ Přizpůsobitelnost - Témata a pluginy, blokování invalidních elementů a vynucení atributů. ∙ Browserfriendly - Fungující v prohlížečích Mozilla, MSIE, FireFox, Opera, Safari a Chrome. 2
WYSIWYG je akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totožná s výslednou verzí dokumentu.
5
∙ Odlehčenost - PHP/.NET/JSP/Coldfusion GZip compresory, zmenší TinyMCE o 75 % a zajistí rychlejší zobrazení. ∙ AJAX compatabilní - Jednoduché využití AJAX k uložení a nahrání obsahu. ∙ Multi-jazyková pordpora - Podpora používá jazykové balíčky. ∙ Open Source - Zdarma pod LGPL licencí, miliony lidí pomáhají testovat a vylepšovat editor každý den.
Obrázek 3. TinyMCE. Možnosti textového editoru: ∙ Velmi bohatě vybavené menu tlačítek umožňující úpravu textu. ∙ Podpora vkládání obrázků, tabulek, souborů, videa. ∙ Kontrola pravopisu různých jazyků. ∙ Možnost editace generovaného HTML. ∙ Podpora full-screen. ∙ Možnost vytvoření vlastních menu tlačítek s vlastní funkcionalitou. Adresa: http://tinymce.moxiecode.com
6
2.3.
FCKeditor
FCKeditor je textový editor pro použití na webových stránkách. Zajišťuje mnoho běžně používaných funkcí z dektopových aplikací typu Word na webu. S FCKeditorem je možné psát text, formátovat ho, vytvářet tabulky atd. Editor není potřeba instalovat, jediné, co je k běhu potřeba, je kompatabilní webový prohlížeč jako je Internet Explorer, Firefox, Safari nebo Opera. Implementace HTML, JavaScript. Rysy FCK editoru: ∙ Kompatabilita s různými prohlížeči. ∙ Výstupem je XHTML 1.0 kód. ∙ Formátování písma a textu. ∙ Vkládání obrázků - Podpora uploadu a server browsing. ∙ Upravitelnost - Toolbar lze kopletně upravit. ∙ Podpora více jazyků - Automatická detekce uživatelského jazyka. ∙ Integrace s různými jazyky - Možná itegrace s ASP, ASP.NET, Java, ColdFusion, Perl, PHP, JavaScript a dalšími. ∙ Open Source - Editor je distribuován pod GPL, LGPL a MPL open source licencí.
Obrázek 4. FCK editor. Možnosti textového editoru: ∙ Bohatá výbava funkcí. ∙ Možnost vkládání předpřipravených šablon. ∙ Vkládání tlačítek, textboxů, skrytých polí atd. 7
∙ Možnost vložení vlastních stylů pomocí tagu div. ∙ Editace a vložení Flash objektů. ∙ Tisk. ∙ Fullscreen. ∙ Šest druhů písem. Adresa: http://www.FCKeditor.net/
2.4.
NicEdit
NicEdit je WYSIWYG editor pro webové stránky. Jeho cílem je být jednoduchý a rychlý, jak je to jen možné pro uživatele této aplikace. NicEdit je extremně odlehčený a může být jednoduše integrován do jakékoliv stránky s minimálním úsilím. Uživatel může pracovat s efektivním a bohatým textovým editorem. Implementace - HTML, JavaScript, Ajax.
Obrázek 5. NicEdit. Rysy NicEdit: ∙ Kompatabilita s prohlížeči. ∙ Jednoduchost. ∙ Upravitelnost. ∙ Malá velikost: <35KB celkem, <10KB zkompresováno. ∙ Jen 2 soubory (js + ikony) potřeba pro operaci. Adresa: http://nicedit.com/
8
2.5.
Yahoo UI editor
Rich Text Editor je UI komponenta, která nahrazuje standartní HTML textovou oblast. Dovoluje bohaté formátování textu včetně odrážek, zahrnuje použití tučného písma nebo kurzívy a přidává možnost drag-and-drop operací při úpravě velikosti obrázků. Toolbar Rich Text Editoru je rozšiřitelný prostřednictvím pluginů, pomocí kterých lze dosáhnout vysokého stupně přizpůsobení. Implementace - HTML, JavaScript.
Součástí nedávno vydaných extenzí pro ASP.NET 4.0 je mimo jiné i ASP.NET MVC, dlouhodobě očekavaný nový framework pro budování webových aplikací. Zkratka MVC (Model-View-Controller) označuje návrhový vzor (nebo spíše architektonický vzor, podle Wikipedie), který se snaží přísně oddělit logiku aplikace, uživatelské rozhraní a datový model aplikace. Model-view-controller (MVC) (někdy také označovaná jako Model-2) je softwarová architektura, která rozděluje datový model aplikace, uživatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. I když byla poprvé popsána roku 1979, do širšího povědomí se dostala až s příchodem webových aplikací, zejména s rozšířením frameworku Ruby on Rails. Frameworků podobného zaměření již dneska existuje více než dost, zejména pro PHP. ASP.NET MVC 2 (detaily o technologii viz kniha [2]) je implementace tohotu vzoru pro webové aplikace od firmy Microsoft.
Obecně řečeno, vytváření aplikací s využitím architektury MVC vyžaduje vytvoření tří komponent, mezi které patří: ∙ Model (model), což je specifická reprezentace dat (objektů), s nimiž aplikace pracuje. ∙ View (pohled), který převádí data reprezentovaná modelem do podoby vhodné k interaktivní prezentaci uživateli. ∙ Controller (řadič), který reaguje na události (typicky pocházející od uživatele) a zajišťuje změny v modelu nebo v pohledu. Komponenty Controller a View jsou ve standardním rozdělení vrstev na prezentační, doménovou3 a datovou obvykle zařazovány jako prezentační vrstva. V MVC je tato prezentační vrstva rozdělena mezi komponenty Controller a View, nicméně nejdůležitější rozdělení je mezi prezentací a doménovou vrstvou. Ačkoliv může být koncept MVC realizován různým způsobem, obecně platí tento princip: 1. Uživatel provede nějakou akci v uživatelském rozhraní (např. stiskne tlačítko). 2. Controller obdrží oznámení o této akci z objektu uživatelského rozhraní. 3
Představuje model dat aplikace, objekty, atributy, omezení a jejich vztahy mezi sebou.
10
3. Controller přistoupí k modelu a v případě potřeby provede aktualizaci dat na základě provedené uživatelské akce (např. aktualizace nákupního košíku uživatele). 4. Model zpracuje změněná data (např. přepočítá celkovou cenu, daně a expediční poplatky pro položky v košíku). Některé aplikace užívají mechanizmus pro perzistentní uložení dat (např. databázi). 5. Komponenta View použije aktuální model pro zobrazení dat uživateli (např. vypíše obsah košíku). Komponenta View získává data přímo z modelu, zatímco model nepotřebuje žádné informace o komponentě View (je na ní nezávislý). Nicméně je možné použít návrhový vzor Observer (viz str.265 v knize [10]), umožňující modelu informovat jakoukoliv komponentu o případných změnách dat. V tomto případě se komponenta View zaregistruje u modelu jako příjemce těchto informací. Je důležité podotknout, že v takovém případě controller nepředává doménové objekty (model) komponentě View, nicméně jí může poslat příkaz, aby svůj obsah podle modelu zaktualizovala. 6. Samotnému konečnému zobrazení výsledku uživateli ještě může u webaplikací předcházet odpověď ze serveru ke klientovi aplikace, aby si ihned vyžádal obnovení stránky. Tím je zaručeno, že při obnovení stánky uživatelem (refresh, F5 v prohížeči) nevyvolá na serveru požadovanou akci opakovaně, ale že se jedná pouze o obnovení view, nyní už bez požadavku na změnu dat (modelu). 7. Uživatelské rozhraní čeká na další akci uživatele, která celý cyklus zahájí znovu. Jaké jsou výhody ASP.NET MVC oproti ASP.NET WebForms? ∙ Striktnější oddělení UI, logiky a dat. ∙ Nastavitelnost (jednoduše lze např. změnit tvar URL adres). ∙ Lepší testovatelnost kódu. ASP.NET MVC 2 je plně integrován ve Visual Studiu 2010. Pro běh je potřeba .NET Framework 4.0. Předchozí verze Visual Studia jej nepodporují ale pro Visual Studio 2008 lze nainstalovat rozšíření. Lze využít i Visual Studio 2010 express, které je možné si zdarma stáhnout z internetu.
11
4.
Dokumentace řešení ASP.NET MVC 2
Tato kapitola obsahuje dokumentaci k technologii ASP.NET MVC 2, zjištěné problémy při vytváření dokumentu a analýzu technologie. Ná základě frameworku ASP.NET MVC byl vytvořen po konzultacích v GMC Software Technology prototyp. Toto řešení využívá Open Source FCK Editor, který generuje HTML. Po následné itegraci FCK do ASP.NET MVC, byl vytvořen pomocí XSL transformace a služeb GMC Software Technology výsledný dokument (PDF).
4.1.
Struktura projektu ASP.NET MVC
Při vytváření solution4 se nás VS5 10 zeptá, zda chceme vytvořit i projekt na testování. Tento projekt v rámci solution slouží implementátorovi k psaní potřebných testů. Projekt se skládá ze tří hlavních složek - Models, Views a Controllers. Složka Views obsahuje jednotlivá View. Složka Controllers obsahuje jednotlivé objekty Controller přiřazené nějakým pohledům. Složka Models obsahuje modely aplikace. ∙ View - Slouží k zobrazování obsahu stránek, reprezetuje GUI aplikace. ∙ Controller - Zodpovídá za komunikaci a interakci s GUI, vyvolává potřebné akce v Modelu. ∙ Model - Vlastní imlementace logiky aplikace. Třídy applikační logiky. Projekt je možné dále dělit a skupině stránek lze přiřadit Controller. Např. stránkám ve složce Wiews/Home je přiřazen Controller - Controllers/HomeController.cs. V Controller(u) se určí, s kterým modelem bude komunikovat.
4.2.
Logika MVC aplikace
MVC aplikace je rozdělena do již zmíněných tří částí. Při spuštění solution je nastavnen implicitní Controller a jeho metoda, která vrátí pohled (webová stránka *.aspx ). Toto nastavení lze změnit v souboru global.asax. Lze tedy ovlivnit, který Controller a která metoda vracející View se zavolá jako první po spuštění projektu. Interakce View a modelu probíhá výhradně přes Controller. Pokud je potřeba provést nějakou akci ve View, je zavolána příslušná metoda controllera. Ten je zodpovědný za zavolání dalších metod a tříd, které jsou implementovány v Modelu. 4 5
Solution je název pro spouštěcí soubor celého projektu pro Visual Studio. Microsoft Visual Studio.
12
4.3.
FCK editor a ASP.NET MVC
Po konzultacích v GMC Software Technology byl vybrán Open Source editor FCK k integraci do ASP.NET MVC. FCK editor lze stáhnout na stánkách projektu (http://www.FCKeditor.net/download). Pro tento projekt byl k dispozici ve verzi 2.6.4, která je opět ve složce ASP.NETMVC/Install k nahlédnutí.
4.3.1.
Integrace FCK do ASP.NET MVC
Pro potřebu tohoto řešení bylo potřeba integrovat FCK editor do technologie ASP.NET MVC. Postup integrace do ASP.NET MVC není popsán na stránkách FCK editoru, tudíž bylo potřeba dalšího hledání vhodného postupu při integraci. Cílem bylo tedy stáhnout složku s FCK editorem a zahrnout editor do ASP.NET MVC projektu tak, aby s ním některý Controller mohl dále manipulovat. Po stáhnutí zip souboru s FCK editorem byl soubor rozbalen. Tento zip soubor obsahuje jedinou složku FCKeditor, která byla zahrnuta do projektu, do složky Scripts.
Obrázek 7. Integrovaný FCK editor. Pro potřebu zobrazení FCK editoru v aspx stránce byl do projektu přidán soubor FCKeditorapi.js, který zajisťuje přilinkování FCK do aspx stránky. V architektuře ASP.NET MVC aspx stránky představují jednotlivé pohledy (Views), které se zobrazují uživateli. Pro umístění FCK editoru do View byl ve složce Views/Home vytvořen nový pohled (View) s názvem FCKEdit.aspx.Tomuto pohledu je potřeba přiřadit Controller a metodu, která View vrací. V tomto případě jde o HomeController.cs a jeho metoda ProcessData, která po zavolání vrátí FCKEdit.aspx. Důsledkem toho se např. při klinutí na odkaz stránky se vždy volá metoda objektu Controller, která vrací 13
určitý pohled (View). Pro správné zobrazení editoru v aspx stránce bylo nutné přidat do stránky JavaScript, který přilinkuje editor do HTML tagu textarea. Po nastavení v Global.asax výchozí metody ProcessData příslušné ke třídě HomeController se po spuštění projektu ve VS106 FCK editor zobrazí. Po těchto krocích bylo dosaženo zprovoznění FCK editoru v technologi ASP.NET MVC. Struktura souborů po integraci do solution vypadá následovně:
Obrázek 8. Struktura FCK. Ve složce _samples lze najít příklady integrace do různých technologií. Jsou zde vzorové soubory a způsoby přilinkování FCK editoru např. do ASP.NET, php, perl, HTML, adobeAir, python. Složka editor obsahuje strukturované JavaScriptové soubory a pluginy pro FCK. Ty se přilinkovávají při spuštění projektu. V kořenové složce je mnoho souborů, nejdůležitějšími jsou FCKeditor.js, FCKstyles.xml, FCKtemplates.xml, myFCKconfig.js. Tyto soubory obsahují základní nastavení FCK editoru. 6
Microsoft Visual Studiu 2010
14
4.3.2.
Konfigurace FCK editoru
Konfigurace FCK editoru byla velmi důležitou součástí tohoto řešení. Přehled o tom, co vše lze nakonfigurovat, je možné nalézt v souboru FCKeditor/FCKconfig.js. Pro samostatné nastavení je doporučeno si vytvořit vlastní konfigurační soubor. V tomto případě to byl FCKeditor/myFCKconfig.js. Zde byla uložena všechna vlastní nastavení editoru. Odkazy na konfigurace se vkládají přímo do stránky, kde je FCK editor vložen. Byl zvolen jiný skin editoru a jeho dostupné funkce. FCK editor má k dipozici standardně dva vzhledy, z nichž byl vybrán uživatelsky atraktivnější vzhled. FCK editor nabízí řadu funkcí pro editaci textu, v tomto prototypu tak bohatá výbava funkcí nebyla potřeba, proto byly některé funkce FCK editoru omezeny. Do vlastního konfiguračního souboru lze například zpřístupnit jen základní funkce. Ty se definují ve vlastním toolbarsetu7 . Základní vlastní nastavení může vypadat např. takto: FCKConfig.SkinPath = FCKConfig.BasePath + ’skins/office2003/’; FCKConfig.ToolbarSets["MyToolbar"] = [ [’Bold’, ’Italic’, ’-’, ’OrderedList’, ’UnorderedList’, ’-’, ’Link’, ’Unlink’, ’-’, ’About’], ’/’, [’Source’, ’DocProps’, ’-’, ’Save’, ’NewPage’, ’Preview’] ];
Důležitou roli v tomto řešení ovšem hrál HTML kód, který FCK generuje. Do jisté míry si implementátor může říct, jaké HTML bude editor generovat. To je důležité zejména, když je potřeba převádět HTML kód z FCK na jíný kód např. Xthml, TSgml apod. V tomto případě je zde možnost nastavit tzv. Entermode, jež ovlivňuje, který HTML tag se bude generovat při stiknutí klávesy enter. Zde jsou tři možnosti tagy - p , div , br . V tomto případě byl zvolen tag div , kvůli jednoduchosti a menší problémovosti v prohlížecích. Nastavení se provede takto: FCKConfig.EnterMode = ’div’; // p | div | br Problémy při původní konfiguraci a generování HTML elementu
...
při stisku klávesy enter byly značné. Text se odsazoval v každém prohlížeči trochu jinak a navíc po dlouhém zkoušení s CSS styly se toto chování odsazování nepodařilo změnit. Tyto problémy byly například u prohlížečů IE, Firefox. Cílem bylo, aby se při odřádkování editor choval ve všech prohlížečích stejně. 7
Panel s tlačítky, které zajišťují různé funkce pro editaci textu.
15
4.3.3.
Interakce FCK a modelu
Psaní a editace textu je zajištěno FCK editorem a jeho metodami v JavaScriptu. Dále bylo potřeba zajistit interakci s Modelem, při požadavku na vytvoření PDF. To se provede přes Controller HomeController a jeho metodu Download . Tato metoda vyzvedne obsah (HTML) vygenerovaný FCK editorem a předá jej Modelu. Model byl v našem případě reprezentován třídou ModelHome . Přes jeho metodu CreatePdf s parametrem HTML z editoru je vrácen výsledný dokument. V rámci ASP.NET MVC se výsledek vrací v takzvaných ActionResultech, což je výsledek operace provedené v modelu. Viz následující kapitola Schéma řešení.
4.4.
Schéma řešení
Obrázek 9. Schéma řešení technologie ASP.NET MVC 2 s FCK.
16
HTML z editoru je předáno modelu, který jej převede na formát TSgml. Model potom předá TSgml a WFD8 šablonu komponentě PrintNetConnect, která pomocí PNetT vytvoří dokument PDF, jak je znázorněno na obrázku 9.
4.5.
Implementovaná funkčnost
V této technologii je použit FCK editor, který obsahuje množství prvků pro editaci textu na webu. Byla upravena konfigurace editoru a po ní editor obsahuje pouze následující funkčnost pro editaci textu: ∙ Tučné písmo. ∙ Podtržení písma. ∙ Kurzíva. ∙ Horní index. ∙ Dolní index. ∙ Odsazení vlevo. ∙ Odsazení vpravo. ∙ Zarovnání textu vlevo. ∙ Zarovnání textu na střed. ∙ Zarovnání textu pravo. ∙ Zarovnání textu do bloku. ∙ Hyperlink. (Není exportován do PDF z důvodu omezení vyplývající z formátu TSgml a WFD.) ∙ Druh písma. ∙ Velikost písma. ∙ Barva písma. Editor obsahuje i následující pomocné funkce: ∙ Export do PDF. ∙ Zobrazení HTML obsahu. 8 WFD šablona je vzhledovým vzorem dokumentu, do kterého se později při vytváření dokumentu přidají data ve formě TSgml. Šabloně musí odpovídat vstupní data TSgml. WFD šablonu lze vytvořit v desktopové aplikaci PNetT, která je součástí nainstalované služby PNetTServer.
17
∙ Nový dokument. ∙ Náhled. ∙ Vyjmout. ∙ Kopírovat. ∙ Vložit. ∙ Vložit text z dokumentu MS Word. ∙ Undo. ∙ Redo. ∙ Najít. ∙ Nahradit. ∙ Vybrat text. ∙ Odebrat aplikované formátování textu.
Obrázek 10. Editor v technologii ASP.NET MVC 2 a FCK.
18
4.5.1.
Možnosti rozšíření
Způsob, jakým je možné daný editor rozšířit pro editaci textu, je závislý na možnostech jazyka HTML, jehož notace reprezentuje text na webu. Na druhé straně jsme omezeni schopnostmi cílového jazyka nebo formátu, do kterého je HTML transformováno (TSgml9 ). V tomto případě je zde však jen několik málo elementů, o které by bylo možné editor rozšířit. Příkladem může být tabulka, obrázek, odsazení prvního řádku odstavce, výška řádku. U složitějších elementů se však vždy setkáme s komplexnější transformací a problémem udržet formátování a rozměry přibližně stejné, jak je vytvoří uživatel.
4.6.
Popis Tříd
Tato kapitola obsahuje implementační detaily prototypového řešení. Obsahuje třídy a metody, které bylo nutné vytvořit k vytvoření dokumentu v této technologii. MvcApplication je třídou reprezentující celou webovou aplikaci. Metody: ∙
Application_Start Inicializační metoda spuštění aplikace, volá metodu RegisterRoutes .
∙
RegisterRoutes Metoda volající Controller a jeho metodu, která vrátí View.
4.6.1.
Views
Reprezentují hlavní složku prezentační vrstvy. Site - Site reprezentuje vzhledovou šablonu pro View. FCKEdit - FCKEdit je konkrétní View s FCK editorem. FCKJQuery - FCKJQuery je konkrétní View s FCK editorem integrovaným přes jQuery. 9
Interní reprezentace dokumentu firmy GMC Software Technology, viz První příloha.
19
4.6.2.
Controllers
Controllers jsou komunikačním meziprvkem mezi Views a Models. HomeController Metody: ∙ ProcessData Vrací view FCKEdit. ∙ Download Metoda která vyzvedne obsah editoru, zavolá model a vrátí vytvořený dokument. ∙ ShowFCKJQuery Vrací view do kterého je integrován FCK editor pomocí jQuery místo JavaScriptu. ∙ Ostatní metody vracejí jiná View, která v tomto řešení nejsou důležitá. 4.6.3.
Models
Models jsou objekty datové vrstvy. DownloadResult je pomocná třída pro vracení výsledku do GUI. Property: ∙
FileDownloadName Nastavuje jméno souboru.
∙
VirtualPath Nastavuje cestu k souboru.
ModelHome je hlavní třída logické části volající podtřídy. Metody: ∙
CreatePdf Vrátí cestu k vytvořenému dokumentu, volá metodu CreatePdfFile třídy TFileCreator.
TFileCreator je pomocná třída, která komunikuje s webovými službami od GMC software technology.
20
Metody: ∙
CreatePdfFile Vrátí cestu k vytvořenému dokumentu. Naplní objekty pro komunikaci se službami od GMC. Vytvoří xml data metodou CreateXmlData. Private:
∙ CreateXmlData Vrátí Xml dokumnet ve formátu TSgml. Provede XSL transformaci HTML do TSgml pomocí třídy FormatConverter. FormatConverter je pomocná třída, která provádí převod XHTML do TSgml. Metody: ∙
ConvertXhtml2TSgml Provede XSL tranformaci. Vrátí XML dokument ve formátu TSgml.
∙ Finalyze Pomocná metoda pro odstranění nadbytečných Cariage Returnů10 . ∙ replaceWrongCharacters Pomocná metoda pro odstranění nadbytečných mezer. Private: ∙ character Pomocná metoda pro dekódování českého znaku v HTML. ∙ CheckBreakLines Pomocná metoda pro kontrolu správného odřádkování. ∙ replaceCzChar Pomocná metoda pro dekódování všech českých znaků. ParseClass je pomocná třída, jejíž metody jsou volány z XSL transformace. Metody: 10
Carriage return (zkratka CR, česky „návrat vozíku“) je v počítačové terminologii název pro speciální netisknutelný řídící znak, který posune kurzor na začátek řádku.
21
∙ IsNextAtribute Zjistí zda daný string obsahuje další atributy. ∙ NoAlign Zjistí zda string neobsahuje HTML atribut text-align. ∙ NoIndent Zjistí zda string neobsahuje HTML atribut text-indent. ∙ ParseStyleAttribName Získá první HTML atribut ze stringu. ∙ ParseStyleAttribValue Získá hodnotu prvního HTML atributu ze stringu. ∙ ParseStyleNextAttrib Zkrátí string obsahující atributy o první atribut a vrátí zbytek řetězce. Private: ∙ AtributeName Vrátí atribut TSgml na základě HTML atributu. ∙ AtributeValue Vrátí hodnotu atributu TSgml na základě HTML hodnoty atributu. ∙ ParseNumbers Převede pixely na mm pro formát TSgml. ∙ ToHexColor Převede barvu ve tvaru RGB do hexadecimálního tvaru.
22
4.7.
Problémy při vytváření dokumentu
Cílem je zjistit v každém prototypu možnosti formátování a vytváření dokumentu v konkrétní technologii. Další snahou bylo, co nejvíce se přiblížit vzhledu dokumentu na webu a dostat stejný výstup a stejné formátování i ve výsledném dokumentu, což však nebylo hlavním cílem práce. Při implenetaci řešení se objevily i některé problémy, které postupně komplikovaly práci. Vždy se jednalo o podobný problém, který spočíval v tom, že vzhled stránky ve webovém editoru, reprezentovaný XML, HTML a jinými značkovacími jazyky, nebyl přesně stejný jako vzhled stránky ve výsledném PDF souboru, který je reprezentovaný TSgml. V tomto prototypu bylo možné využít textového formátování na úrovni možností jazyka HTML, který reprezentoval dokument na webu. Většinu textových elemetů HTML, krom jistých vyjímek (hypertextový odkaz, odrážky), bylo možné zapsat v cílovém formátu TSgml a z něj pak vygenerovat PDF. Jedním z největších problémů byl v tomto prototypu rozdílnost zobrazení stejného HTML v různých prohlížečích, reprezetující bohaté textové formátování. Při přesně stejné konfiguraci editoru, přesně stejném textu v editoru a použitém formátování, dva rozdílné prohlížeče zobrazily webový dokument mírně odlišně. Hlavním rozdílem u textu, který je delší než jeden řádek v editoru, je automatické zalomení textu na konci řádku. Problém je způsoben rozdílnou interpretací stejného HTML, zejména pak velikostí písma, které je ve webovém dokumentu v jednotkách pt. Rozdílné zobrazení viz obrázky 11. a 12.
Obrázek 11. Text v prohlížeči Internet Explorer 8.
23
Obrázek 12. Text v prohlížeči Mozilla Firefox 3.6.
Obrázek 13. Výsledné PDF po transformaci. Dalším problémem byla rozdílná interpretace velikosti písma, která u textu delšího než jeden řádek v editoru způsobovala rozdílné zalomení textu na webu i v dokumentu PDF. Ačkoli byla použita stejná jednotka písma pt a stejné písmo operačního systému jak na webu, tak v dokumentu PDF interpretace na webu a v PDF byla mírně rozdílná. Problém byl způsoben vlastní interpretací velikostí písma a jeho zobrazení prohlížečem. Při zobrazení velikosti písma hraje roli jednotka DPI11 , na platformě Windows je tato hodnota standartně 96, na platformě Mac je tato hodnota standartně 72. Při transformaci na Windows serveru předpokládáme hodnotu 96 DPI. Z hodnoty DPI lze spočítat k šířce dokumentu v milimetrech v PDF dokumentu ekvivalentní hodnotu pro šířku textového pole v editoru v pixelech. Co však nemůžeme ovlivnit ani zjistit je, jakým způsobem je interpretováno písmo operačního systému v prohlížeči. Výsledkem je tak mírně odlišné zalomení volně běžícího textu viz obrázek 13. 11
Dots per inch (DPI) je údaj určující, kolik obrazových bodů (pixelů) se vejde do délky jednoho palce. viz[14]
24
Další problémy, se kterými se v tomto typu řešení můžeme setkat, spočívají v zobrazování barev. Jeden problém spočívá v tom, že každý prohlížeč zobrazí barvu trochu jinak – je tedy možné, že v prohlížeči Mozilla Firefox bude barva sytější než v prohlížeči Internet Explorer. Druhý problém, se kterým jsem se při řešení setkal, ale který nemá na koncového uživatele žádný vliv, spočívá v tom, že zatímco v jednom prohlížeči je barva generována hexadecimálně, v druhém je generována ve tvaru RGB. Jelikož v cílovém formátu TSgml je barva reprezentovaná hexadecimálně, je nutné transformovat barvy generované ve tvaru RGB na tento formát. To klade nároky na transformační proces, který musí obsahovat funkce, které si s tímto problémem dokáží poradit. Při psaní textu ve webovém editoru také dochází k automatickému HTML zakódování českých znaků s čárkami a háčky. Například znak ’á’ je interpretován jako á apod. Transformační proces musí řešit vhodné HTML dekódování obsahu a zajistit vhodné nahrazení spravným znakem. Do podobné sitace se dostaneme s mnoha dalšími znaky nejenom české abecedy. Dekódování znaků není jednoduché z toho důvodu, že potřebujeme vždy provést tuto změnu jen u zlomku textu ze vstupního HTML formátu . Jedním z dalších problémů, který je potřeba řešit, je identifikace odstavců. V cílovém formátu TSgml musí být text vždy v odstavci. Webová iterpretace textu sice pojem odstavec zná, ale je zde velký rozdíl v zobrazení obsahu odstavce na webu a odstavce v dokumentu PDF, zejména co se týče výšky řádku apod. Změnou konfigurace webového editoru šlo zaměnit generování HTML elementu p za element div.Výsledkem transformace HTML vstupu je přeměna všech elementů div na odstavec tak, jak je popsán v definici formátu TSgml. V tomto prototypu by bylo možné z webového editoru transformovat do TSgml i složitejší element, jako je například tabulka. Problémem u tohoto elementu je zachování stejného formátování buněk a textu uvnitř tabulky. Vzhledem ke komplexnosti tohoto elementu nebylo přistoupeno k vlastní implementaci. Jedním z problémů při implementaci webového editoru může být získání informací o textu, na kterém se aktuálně nachází kurzor. V tomto případě však díky jasnému formátování HTML a FCK JavaScriptu jsme schopni uživateli v nabídce toolbaru vždy zobrazit aplikovaný druh písma, velikost, barvu apod. V neposlední řadě je také třeba řešit dobu transformace. Tedy za jakou dobu uživatel dostane vygenerovaný dokument po vyvolání této žádosti ve webovém editoru. Transformace jako taková je komplexní proces, ve kterém je třeba vyřešit všechny výše uvedené problémy, navíc mít jistotu, že se vždy bude generovat správný cílový formát (TSgml, interní formát dokumentu GMC Software Tech25
nology). Čím více textu a formátování, tím větší vznikají nároky na transformaci samotnou. Transformace je z HTML do TSgml zajištěna pomocnými funkcemi a XSLT šablonou (viz src/asp.netMVC/MvcApplication1/MvcApplication1/ Models/PNet/XHTML2TSgml_def.xslt ). V tomto případě první vyrobení dokumentu trvá do šesti sekund na nasazeném serveru, při každé další žádosti o dokument je výroba rychlejší než první vyrobení dokumentu ve stejném prohlížeči, pokud jej uživatel mezitím nezavře. Důvodem je jednak cache prohlížeče, ale i serveru, který provádí transformaci pomocí XSLT šablony. Ve webovém editoru je mnoho prvků, které ovlivňují vzhled textu (odstavce, styl písma, druh písma, řádkování, velkost písma, barva, odsazení ...) a čím větší je nabídka možností textového formátování, tím bohatší dokument můžeme vytvořit. Na druhé straně je však obtížnější zůstat co nejblíže formátování tak, jak jej vidí uživatel na webu i v cílovém dokumentu PDF.
4.8.
Analýza ASP.NET MVC a FCK editoru
Kapitola obsahuje analýzu použitelnosti ASP.NET MVC s FCK editorem. Kritéria použitá při hodnocení a jejich výsledky na základě vytvořeného prototypu. 4.8.1.
Editor
ASP.NET MVC není typickým představitelem pro tvoru RIA12 aplikací, poskytuje však větší kontrolu nad HTML. Tvorba editoru by v rámci této technologie mohla vypadat následovně: ∙ Kombinace HTML a JavaScriptu. ∙ Editor vytvořený pomocí jQuery. ∙ Editor vytvořený v jiné technologii přilinkovaný do ASP.NET MVC. Po zvážení byl zvolen jako kandidát open source FCK editor, který byl přilinkován pomocí JavaScriptu. Z důvodu následujících výhod: ∙ Podpora mnoha funkcí pro editaci textu. ∙ Možnost konfigurace generovaného HTML. ∙ Nezávislost na platformě. 12
RIA (Rich Internet Application) jsou webové aplikace, které se snaží překlenout rozdíly mezi klasickou webovou aplikací a desktopovou aplikací. RIA aplikace se snaží v rámci webového prohlížeče napodobovat desktopové aplikace svým vzhledem i chováním a poskytnout vyšší uživatelský komfort.
26
Během implementace řešení však byly zjištěny i tyto nevýhody: ∙ Změna v konfiguraci JavaScriptu FCK editoru se v některých případech hned neprojevila. Důvodem byl prohlížeč a typ serveru, na kterém aplikace běžela (zejména ASP.NET Development server, který se spustí při stisku klávesy F5 ve Visual Studiu), kde docházelo ke cachování JavaScriptu. ∙ Generování rozdílného HTML elementu reprezentující barvu textu v různých prohlížečích (Firefox, Internet Explorer). ∙ Nemožnost efektivně vyřešit rozdílné zobrazení textu v různých prohlížečích. 4.8.2.
Vytvoření dokumentu
Jelikož samotný editor produkoval pouze HTML, bylo potřeba zjistit způsob pro převod HTML na jiný značkovací jazyk či dokument. ASP.NET MVC jako framework poskytuje mnoho nástrojů pro transformaci dat. Avšak neposkytuje implementátorovi nástroj na jednoduchý převod HTML rovnou na dokument (DOCX, PDF ...), proto je nutné využít dílčích transformací XML. Pro transformace lze v ASP.NET MVC využít následující: ∙ Vlastní kód aplikace (C#, VB). ∙ XSL transformace ve verzi 1.0. ∙ Nějaká jiná komponenta použitelná pro převod (knihovna apod.). Bylo využito kombinace všech tří možností. Kvůli tomu, že samotné XSL 1.0 nemá dostatek funkcí potřebných k transformaci, bylo použito XSL transformace používající pomocné funkce napsané v C#. Výsledkem převodu byl dokument ve formátu TSgml. Pro vytvoření PDF se využila webová služba od firmy GMC software technology. Výhody zvoleného řešení: ∙ Kontrola nad transformovaným dokumentem. ∙ Kontrola nad převodem českých znaků. ∙ Možnost jednoznačné specifikace výsledku převodu. Nevýhody zvoleného řešení: ∙ Nutnost využití více prostředků pro transformaci a ne jen čisté XSL. ∙ Závislost transformace na HTML generovaným FCK editorem (pro HTML z jiného editoru by se transformace elementů musela upravit). 27
∙ Potřeba instalace .NET frameworku a IIS13 serveru (aplikaci není možné hostovat na serveru s operačním systémem Linux). 4.8.3.
Hodnocení a Závěr
Spojením FCK editor a ASP.NET MVC 2 se podařilo vytvořit textový editor, který umožnuje bohatou úpravu textu. Provést transformaci HTML a získat dokument, který vzhledově odpovídá úpravě textu na webu. Nejdůležitější kritéria pro hodnocení technologie: ∙ Vhodnost pro vytvoření webového editoru. ∙ Vhodnost technologie pro vytváření dokumentu. ∙ Nezávislost řešení na prohlížeči. ∙ Podpora trasformace a vytváření dokumentů. ∙ Zobrazení aplikace a její nezávislost na platformě. ∙ Nezávislost řešení na nasazovaném serveru. ∙ Možnost vytvořit bohaté GUI pro webové aplikace. ∙ Oddělení prezentační, aplikační a datové vrstvy. ∙ Možnosti rozšiřitelnosti webové aplikace. Pokud bychom zvolili následující stupnici hodnocení: 1 - Velmi vhodné (výborně). 2 - Méně vhodné (dobře). 3 - Nevhodné (nedostačující). Výsledek hodnocení technologie ASP.NET MVC 2 by vypadal následovně: Vhodnost technologie ASP.NET MVC pro imlementaci webového editoru: ∙ 2 - Pouze ve spojení s opensourcovým editorem nebo jiným editorem pro bohatou úpravu textu. Vhodnost technologie ASP.NET MVC pro vytváření dokumentu: 13
Internet Information Services je aplikace pro hostování webových aplikací od firmy Microsoft obsažená v operačním systému Windows.
28
∙ 2 - Vzhledem k tomu, že poskytuje nástroje potřebné pro transformaci, ovšem podpora pro generování dokumentů je slabá. Nezávislost ASP.NET MVC s FCK na prohlížečích: ∙ 3 - Kvůli použití JavaScriptu u FCK musí implementátor počítat s tím, že z každého prohlížeče může získat jiný HTML výstup. Navíc zde jsou problémy s úpravou CSS stylů. FCK má podobný problém se zobrazením v různých prohlížečích. Nezávislost webové aplikace v prohlížeči na platformě: ∙ 1 - Prohlížeče všech platforem by se zobrazením webové aplikace neměly mít problém díky použití a generovaní HTML. Nezávislost webové aplikace na nasazovaném serveru: ∙ 3 - Pouze servery s operačním systémem Windows. Možnost vytvořit bohaté GUI pro webové aplikace: ∙ 2 - Je nutné vystačit se základními HTML elementy a ty skládat do větších celků. Oddělení prezentační, aplikační a datové vrstvy: ∙ 1 - Z důvodu požití Model-View-Controller. Rozšiřitelnost webové aplikace v ASP.NET MVC: ∙ 2 - Implementátor je schopen rozšířit funkčnost aplikace avšak za značného usílí při práci s GUI. Jako celek a vhodnost použítí technologie ASP.NET MVC při implementaci webového editoru, který generuje dokument, bych hodnotil známkou 2. A to z následujících důvodů: Technologie ASP.NET MVC neposkytuje vhodné prvky pro tvorbu bohatých webových aplikací zaměřených na editaci textu. Silnou stránkou je kontrola nad HTML a oddělení prezentační, aplikační a datové vrstvy. Navíc poskytuje množství knihoven, které je možno využít k implementaci business logiky. Technologie je vhodná i pro tvorbu velkých webových projektů. Ve spojení s některým HTML textovým editorem je použitelná i pro vytváření dokumentu na webu, velkou nevýhodou je rozdílné zobrazení stejných HTML elementů textu v různých prohlížečích.
29
5.
Technologie ADOBE Flex 4
Technologie Adobe Flex je open-source framework pro vytváření webových aplikací. Výsledkem po kompilaci aplikace je soubor *.SWF, který se v prohlížeči zobrazí jedině přes naistalovaný plugin Flash Player. Je nutné mít takovou verzi pluginu, která obsahuje framework Flex, který je poměrně nový. Ve verzi 4 je již integrovaný Text Layout Framework (dále jen TLF) pro rich-text-editing (bohatou úpravu textu) na webu. Detaily o TLF lze najít na následující adrese: http://labs.adobe.com/technologies/textlayout/ . Hierarchii objektů v TLF lze nalézt v knize [5], kap. 7.1. Největší výhodou použití této technologie je, že oproti kombinaci HTML a JavaScriptu apod. se aplikace chová a vypadá ve všech webových prohlížečích stejně. Odpadá tak běžný problém testování v různých prohlížečích z hlediska generovaného vzhledu. Pro vývoj webových aplikací ve Flex lze využít open-source nástroj Eclipse (v tomto případě nemusí být dostupná intelisense), nebo vývojové prostředí od ADOBE - Flex Builder. Ten je ovšem placený, ale je možné jej vyzkoušet na 30 dní zdarma.
30
6.
Dokumentace řešení ADOBE Flex 4
Tato kapitola obsahuje dokumentaci k řešení v technologii ADOBE Flex 4, která v této vezi obsahuje nový framework pro úpravu textu na webu. Dále obsahuje programátorskou dokumentaci, zjištěné problémy při vytváření dokumentu v této technologii a její analýzu.
6.1.
Diagram řešení
Znázornění prototypového řešení je na následujícím diagramu.
Obrázek 14. Schéma řešení technologie FLEX.
31
Webový editor je vytvořený ve Flex 4 build 4.0.0.6898. Verze buildu je důležitá, protože v době psaní této práce vznikaly další verze tohoto frameworku, které obsahovaly změny interních tříd a metod. Zobrazení editoru v prohlížeči zajišťuje Flash plugin, který obsahuje již zmíněnou verzi frameworku. Počínaje verzí 4.0 je v technologii Flex obsažen Text Layout Framework (TLF), který umožňuje bohatou editaci textu na webu. Výstupem textového formátování na webu může být HTML se specifickými tagy TLF, nebo XML reprezentace textu Text Layout Markup (dále jen TLM). TLM je interním fomátem TLF, který zahrnnuje všechny elementy jazyka pro renderování bohatého textového fotmátování. Pro výstup a další zpracování dokumentu byl použit TLM. Ve chvíli, kdy klient požádá o vytvoření dokumentu, je TLM předáno WCF14 (Detaily o WCF lze nalézt v knize [12]) webové službě DocService. Ta po transformaci TLM XML na TSgml15 (viz První příloha) předá TSgml a WFD16 webové službě PrintNetConnect. Tato služba využije PrintNetT, který vytvoří finální dokument (PDF, Docx, RTF atd.). Vrácený dokument je vytvořen na straně DocService a do webové Flex aplikace je vrácen odkaz na vytvořený dokument, jak je znázorněno na obrázku 14.
6.2.
Implementovaná funkčnost
V této technologii byl vytvořen webový editor pomocí Text Layout Frameworku (TLF), frameworku přímo zaměřeném na editaci textu na webu. Základním elementem, do kterého se text vykresluje, je objekt TextFlow. Z možností pro editaci textu obsažené v TLF byly vybrány a implementovány následující prvky pro editaci textu: ∙ Tučné písmo. ∙ Podtržení písma. ∙ Kurzíva. ∙ Horní index. ∙ Dolní index. ∙ Odsazení odstavce. ∙ Zarovnání textu vlevo. 14
Windows Communication Foundation - je jednou z novinek, které přinesl .NET Framework 3.0. WCF je jednotný framework na vytváření servisně orientovaných aplikácí (SOA). Jednou ze silných stránek WCF je fakt, že sjednocuje Microsoft technologie používané pro distribuované aplikace. 15 Interní XML pro generování dokumentů společnosti GMC software technology. 16 Šablona nutná spolu TSgml k vytvoření dokumentu.
32
∙ Zarovnání textu na střed. ∙ Zarovnání textu pravo. ∙ Zarovnání textu do bloku. ∙ Hyperlink. (Není exportován do PDF z důvodu omezení vyplývajícího z formátu TSgml a WFD.) ∙ Druh písma. ∙ Velikost písma. ∙ Barva písma. Editor obsahuje i následující pomocné funkce: ∙ Export do PDF. ∙ Undo. ∙ Redo. ∙ Zobrazení HTML reprezentace s TLF specifickými tagy. ∙ Zobrazení Text Layout Markupu, interní reprezentace textu v TLF. ∙ Zobrazení čísla verze frameworku použitého pro build aplikace.
Obrázek 15. Editor v technologii ADOBE Flex 4.
33
6.2.1.
Možnosti rozšíření
Text layout framework nabízí řadu netriviálních prvků, o které je možné editor rozšířit. Příkladem může být zakroucení textu, obrázek, odrážky, podpora arabského způsobu písma (zprava doleva), automatické zobrazení textu ve sloupcích, výška řádku aplikovaná na část textu v odstavci. U některých prvků však narazíme na problém s transormací do TSgml. Takové prvky není snadné přenést nebo je zde problém s odlišným způsobem zadání způsobu, jakým se má prvek vykreslit v dokumentu.
6.3.
Popis tříd
Projekt se skládá ze dvou hlavních částí - Webový editor v technologii Flex, webová služba WCF DocService. Webový editor je samostatný projekt, který obsahuje jen logiku pro manipulaci textu na webu. Obsah editoru je po interakci odeslán webové službě WCF, která má na starost vytvoření dokumentu PDF. Tato kapitola obsahuje seznam tříd, metod a událostí prototypu v této technologii. 6.3.1.
Flex Projekt
Soubor SimpleEditor.mxml je hlavním vstupem do aplikace. Soubor SimpleEditorPanel.mxml a SimpleEditorPanel.as obsahují většinu logiky Flexového webového editoru na úpravu textu. Složka PopUps obsahuje definice pomocných aplikačních komponent při interakci s aplikací. SimpleEditor Obsahuje control SimpleEditorPanel. Funkce: ∙
errorHandler Error-handling při načítání souboru.
∙
loadCompleteHandler Handler po úspěšném načtení souboru.
∙
handleResize Inicializace výšky a šířky aplikace.
SimpleEditorPanel Obsahuje controly LinkWindow, FlowMarkup. Funkce a Události: ∙
init Inicializace. 34
∙
populateFontFamily Zveřejnění a načtení písem.
∙
textFlow Vrací textový objekt k další manipulaci.
∙
graphicStatusChangeEvent Událost změny grafického stavu v TextFlow.
∙
selectionChangeListener Událost změny výběru v TextFlow.
∙
updateComboBox Update dropdownlistu, aby zobrazoval v danném momentě zvolenou hodnotu.
∙
DefaultCharacterFormat Vrací konfiguraci standartního formátování (písmo, velikost).
∙
FontStyleCheck Updatuje UI na základě zvoleného textu v editoru.
∙
changeFontFamily Změna písma.
∙
changeFontSize Změna velikosti písma.
∙
changeTextIndent Změna odsazení paragrafu.
∙
changeTextAlign Změna zarovnání paragrafu.
∙
UndoClick Provede Undo editoru.
∙
RedoClick Provede Redo editoru.
∙
BoldClick Tučné písmo. 35
∙
ItalicClick Kurzíva.
∙
UnderlineClick Podtržení písma.
∙
ChangeColor Změna barvy písma.
∙
RemoveLink Odstranění Linku z editoru.
∙
SupClick Horní index.
∙
SubClick Dolní index.
∙
getDoc Asynchroní volání WCF služby předávající TLF markup s žádostí o vytvoření dokumentu.
∙
handleDocumentFlexResult Událost která proběhne po vrácení výsledku volání WCF služby.
∙
openWindow Pomocná funkce k otevření okna s vráceným dokumentem.
∙
OpenFile Otevření vráceného dokumentu.
∙
PrepareFlow Připraví TLF XML k exportu.
PopUps Funkce a Události: ∙
GetFlow Vrátí aktuální XML odpovídající dokumentu v editoru.
∙
LinkDialog Otevře Link dialog. 36
∙
FlowDialog Pomocná funkce otevírající okno s markup XML.
∙
HTMLDialog Otevře dialog s HTML.
∙
MarkupDialog Otevře dialog s TLF XML.
6.3.2.
WCF DocService Projekt
Popis tříd WCF, které provádí transformaci XML na TSgml a dále volají služby PNC, PNetT. DocumentService Hlavní třída datové části. Metody: ∙
GetData Testovací metoda, pro získání jednoduchých dat.
∙
DocumentFlex Volá pomocné funkce, se vstupním formátem TLM provede transformace a vrátí odkaz na vytvořený soubor.
∙
DocumentSLrtb Volá pomocné funkce, se vstupním formátem XAML17 (viz kniha [8]) provede transformace a vrátí vytvořený soubor v binární podobě.
∙
GetDocumentLink Volá pomocné funkce, se vstupním formátem XML provede transformace a vrátí odkaz na vytvořený soubor.
TFileCreator Pomocná třída. Metody: ∙
GetDocContent Na základě předaných parametrů vytvoří dokument pomocí webové služby od GMC Sofware technology a vrátí dokument v binární podobě.
∙
GetDocFileLink Vyrobí dokument pomocí GetDocContent a vrátí odkaz na dokument.
17
Notace objektů v technologii Microsoft Silverlight.
37
∙
GenerateFileName Vygeneruje název souboru.
∙
IsFileOpen Zjistí, zda je daný soubor otevřený.
∙
DeleteUnusedFiles Vymaže staré soubory.
∙
ReadFile Vrátí obsah souboru v binární podobě.
Constants Pomocná třída. Fieldy: ∙
C_BASE_DIR Cesta do kořenového adresáře projektu.
∙
C_XML_DATA_INPUT Název datové třídy ve WFD šabloně.
∙
C_WFD_DATA Cesta k WFD šabloně.
∙
C_XSL_FLEX_TLF_TO_TSgml Cesta k XSL souboru pro tranformaci TLF.
∙
C_XSL_SilvRTB_XAML_TO_TSgml Cesta k XSL souboru pro tranformaci XAML.
∙
C_DOCUMENT_DIR Fyzická cesta k veřejnému adresáři.
∙
C_WEB_DOCUMENT_DIR Url Cesta k veřejnému adresáři.
∙
C_TRANSFORMED_XML Cesta k transformovanému vstupu.
Converter Pomocná třída. Metody:
38
∙
CreateXmlData Provede XSL tranformaci pomocí třídy FormatConverter a vrátí TSgml dokument.
FormatConverter Pomocná třída. Metody: ∙
Convert Provede XSL tranformaci a vrátí XML výsledek.
∙
Preprocess Nachystá vstupní XML k tranformaci.
Keygen Pomocná třída. Metody: ∙
GetUniqueKey Vytvoří unikátní klíč zadané délky.
6.4.
Problémy při vytváření dokumentu
Při vytváření tohoto prototypu byly zjištěny i některé problémy, které ovlivňovaly vývoj. Vstupním formátem byl TLM, tedy interní reprezentace textu v Text Layout Frameworku. Cílovým formátem byl TSgml s následným převodem do PDF s formátem papíru A4. Díky Flash pluginu prohlížeče se text zobrazí pro klienta aplikace ve všech jeho webových pohlížečích stejně. Tranformace z TLM na formát TSgml byla provedena přes XSLT šablonu (src/DocService/DocService/Xsl/FlexTLF2Tsgml.xslt.xslt). Protože tato technologie neposkytuje silné nástroje, jak tuto transformaci provést, byla zapojena webová služba implementovaná v jiné technologii, která zajišťuje transformaci a vytvoření dokumentu, na nějž vrací odkaz. Důvodem vrácení odkazu na dokument je, že samotná transformace opět trvá nějakou dobu a pokud bychom ještě serializovali výsledek dokumentu do binární podoby na straně webové služby a v editoru opět rekonstruovali, ztratili bychom ještě nějaký čas při posílání dokumentu k uživateli. Opět platí, že čím více textu a čím více formátování, tím složitější transformace. Ale i tak jsme schopni dostat dokument k uživateli do pěti sekund na nasazeném serveru. Navíc při každé další transformaci je vytvoření dokumentu rychlejší než to úplně první, pokud uživatel nezavře mezi vytvářením dalšího dokumentu prohlížeč. Další nevýhodou je například absence elementu tabulka v textovém frameworku. Obsahuje sice bohaté možnosti, jak formátovat text a provádět 39
s textem úpravy, které by v např. v HTML byly nemožné, ale základní věc, jako je tabulka, neobsahuje. Jedinou možností, jak tam takový objekt zobrazit, je napsat vlastní user control, který bude tabulku simulovat. Na jeho vytvoření je kladen velký nárok. V textové reprezentaci by o sobě musel obsahovat velmi podrobné informace, aby byl transformovatelný do cílového formátu TSgml. Opět tu byly ale zjištěny problémy související se šířkou dokumentu a automatickým zalamováním textu, který je delší než jeden řádek a nebyl odřádkován uživatelem. Technologie ADOBE Flex sice obsahuje textový framework, ale zatím nezná pojem formát papíru nebo něco podobného. Text je vkladán do textového elementu TextFlow, který má nastavenou velikost v pixelech. Velikost písma v TLF je udávána v pixelech. Tím pádem se dostávame zpět k problému, jak vhodně vybrat šířku tohoto elementu, aby nám většina textu a zalamování odpovídala i ve výsledném dokumentu PDF. TLF používá k vykreslení textu standardně písmo z operačního systému, do aplikace je však možno přilinkovat písmo jiné, které lze pak použít. Tento problém se nepodařilo vyřešit, protože se nenašel způsob, jakým je text přesně interpretován a jaká je standardní hodnota DPI18 u technologie Flex. Navíc je zde vždy nastavení klientského počítače, kde se písmo i nastavená hodnota DPI může lišit, což může způsobit rozdílné vykreslení textu pro různé platformy a různé klienty aplikace. Bohužel i tak se v některých případech, při použití různých druhů písma, velikostí písma, stylů tučné a kurzíva, dostaneme do situace, že ve výsledném dokumentu se některá slova, která měla být ještě na předchozím řádku, zalomí na řádek nový. Bohužel ani v tomto případě v TLM není k dispozici informace o konci řádku a zalomení textu, který uživatel sám nevytvořil pomocí klávesy enter. Výše zmíněný problém je spojen s i velikostí písma, kdy v některých případech při velikosti písma 14 a písma např. Century Gothic zůstává formátování a zalamování téměř stejné. Při změně velikosti písma na hodně malé (např. pomocí horního a dolního indexu) nebo na velké, se dostaneme opět k trochu rozdílnému zalamování. Je tu i problém s transformací velikosti písma, který lze řešit jen nějakým vhodným převodem z velikosti v pixelech na velikost v pointech (standardně 1 px = 0.75 pt, což se může lišit v závislosti na rolišení, operačním systému, DPI apod.). Ve výsledném dokumentu tak dostaneme stejné formátování textu s tím, že zalomení textu delšího než jeden řádek není vždy ekvivalentní a dochazí zde k malým odlišnostem, které v konečném důsledku nejsou zásadním problémem technologie. Textový framework na druhou stranu nabízí možnosti, které jsou těžko 18
Dots per inch (DPI) je údaj určující, kolik obrazových bodů (pixelů) se vejde do délky jednoho palce. Viz[14]
40
proveditelné v cílovém formátu. Lze například nastavit velikost výšky řádku na část textu v odstavci, což je možné nastavit například v cílovém formátu pouze na celý odstavec. Další možností je jisté zakroucení textu do spirály apod. Zde ale vždy narazíme na možnosti cílového formátu. Protože tam taková možnost není, nemůžeme ji tedy ani implementovat a nabídnout uživateli. Krom zmíněných nevýhod lze však konstatovat, že TLF je velmi solidní nástroj pro editaci textu na webu s bohatými možnostmi nejrůznějšího formátování.
6.5.
Analýza ADOBE Flex 4
Tato kapitola obsahuje analýzu použitelnosti technologie Adobe Flex 4 k bohaté editaci textu na webu a vytvoření dokumentu, na základě vytvořeného prototypového řešení. 6.5.1.
Editor
Protože Flex 4 je webovou technologií, která poskytuje velké množství webových prvků pro tvorbu webového editoru, je vhodným kandidátem na tvorbu prototypu. Ve spojení s textovým frameworkem umožňuje provádět transformace textu, které v HTML nejsou možné. Příkladem může být otočení a zakroucení textu, nastavení výšky řádku na část textu v odstavci. Celkově se dá říci, že se jedná o bohatší možnosti editace textu. TLF navíc poskytuje základní elementy, např. undo manager a TLF XML notaci, která je reprezentací dokumentu na webu. Výhody tvorby editoru ve Flex 4: ∙ TLF framework pro podporu bohaté editace textu na webu. ∙ Odpadá problém s odlišným zobrazením v různých webových prohlížečích díky flashplayeru. ∙ Nezávislost nasazení stránky na platfomě (výsledkem je HTML stránka a swc soubor, který se zobrazí v rámci flashplayeru). Nevýhody tvorby editoru ve Flex 4: ∙ Absence nástrojů pro přenos bytového pole při volání webové služby. ∙ Absence nástrojů pro xsl transormaci (možno pouze prostřednictvím JavaScriptu). ∙ Chybí možnost vytvořit tabulku v editoru. ∙ Chybí jednoduchý export do Adobe PDF. 41
6.5.2.
Vytvoření dokumentu
Adobe Flex je technologie zaměřená zejména na grafické prvky. Proto zde nenajdeme silné nástroje pro vytváření business logiky. TLF je poměrně nový framework, bohužel zde chybí nativní podpora exportu TLF XML do PDF. Je možné, že v dalších verzích tato podpora bude. Proto je vhodné zapojit jinou technologii, která poskytne potřebné nástroje pro vytváření dokumentu. V tomto případě bylo využito WCF webové služby, která z TLM XML vytvořila TSgml a ten lze následně transformovat na dokument (PDF, DOCX ...) pomocí produktů GMC Software Technology. Pro transformace lze ve Flex využít následující: ∙ JavaScript a XSL. ∙ Transformace provedená voláním jiné aplikace (webové služby). ∙ Nějaká jiná komponenta použitelná pro převod (knihovna apod). K transformaci jsem použil druhou variantu. Absence komponent pořebných pro transformaci XML je ve Flex 4 značná. Podporuje však propojení s webovými službami, a proto je vhodnější postupovat při vytváření dokumentu tímto způsobem. 6.5.3.
Alernativní možnosti
JavaScript a XSL - Řešením by mohlo být vložení javasriptové funkce do Flex řešení, která by provedla XSL transformaci s předaným XML (TLM) a XSL šablonou. V tomto případě je možné pouze převést TLM na jiné XML. Možnosti, jaký typ dokumentu by bylo možné generovat, by byly značně omezené. Vedlo by to na možnost vytvořit například Docx19 , kde by ovšem vyvstaly problémy s potřebou generovat více XML souborů, ze kterých by se na konci vytvořil Docx. Navíc by zde byly kladeny velké nároky na znalost cílového formátu, v uvedeném příkladu open-XML formát. Pokud bychom chtěli generovat více různých typů dokumentů, museli bychom znát každý formát podrobně, abychom jej mohli generovat. Otázkou by dále bylo, zda by JavaScript fungoval ve všech prohlížečích stejně. Komponenta použitelná pro převod - V tomto případě bychom museli najít takovou komponentu, která by uměla z předaného TLM vytvořit dokument, navíc by musela být použitelná v rámci Flex. Možná by se nám podařilo najít nějakou placenou, ale open-source komponentu, která by to dokázala, ovšem lze najít jen těžko. Nevýhodou by opět bylo, že bychom sice našli vhodnou 19
Dokument aplikace Microsoft Word 2007
42
komponentu, ale ta by typicky uměla převod jen na jeden z požadovaných typů dokumentu (Docx, PDF, RTF...). Převod na jeden z formátů by byl jistě úspěch, vyvstala by pak otázka, zda není možné tedy nějak převést jeden formát na druhý (např. Docx na PDF apod.). Pokud bychom to chtěli po technologii ADOBE Flex opět bychom se potýkali s absencí nástrojů na podobné operace. 6.5.4.
Hodnocení a Závěr
Spojením Adobe FLEX 4 a Windows Communication Foundation se podařilo vytvořit textový editor, který umožnuje bohatou úpravu textu. Dále se podařilo provést transformaci TLM a získat dokument, který vzhledově odpovídá úpravě textu na webu. Editor lze rozšířit a pomocí něj provádět velmi bohatou úpravu textu. Nesmíme však zapomenout, že potřebujeme nástroj, který bude umět z TLM XML na webu vytvořit odpovídající dokument. V tomto případě webová služba zajišťující vytvoření dokumentu z předané webové reprezentace textu. Nejdůležitější kritéria pro hodnocení technologie: ∙ Vhodnost pro vytvoření webového editoru. ∙ Vhodnost technologie pro vytváření dokumentu. ∙ Nezávislost technologie na prohlížečích (i prohlížeče různých platforem). ∙ Nezávislost zobrazení webové aplikace v prohlížeči. ∙ Nezávislost řešení na nasazovaném serveru. ∙ Možnosti vytvořit bohaté GUI webové aplikace. ∙ Oddělení prezentační, aplikační a datové vrstvy. ∙ Možnosti rozšiřitelnosti webové aplikace. ∙ Možnosti bohatého formátování textu a jeho manipulace. ∙ Schopnost zachovat stejné formátování textu po transformaci. Pokud bychom zvolili následující stupnici hodnocení: 1 - Velmi vhodné (výborně). 2 - Méně vhodné (dobře). 3 - Nevhodné (nedostačující). 43
Výsledek hodnocení technologie Adobe Flex 4 by vypadal následovně: Vhodnost technologie ADOBE Flex 4 pro imlementaci webového editoru: ∙ 1 - Vzhledem k integrovanému text layout frameworku, který umožňuje velmi bohaté formátování textu. Vhodnost technologie pro vytváření dokumentu: ∙ 2 - Ve spojení s jinou komponentou či webovou službou. Nezávislost technologie na prohlížečích (i prohlížeče různých platforem): ∙ 1 - Díky flash playeru všechny moderní prohlížeče zvládají. Nezávislost zobrazení webové aplikace v prohlížeči: ∙ 1 - Prohlížeče všech platforem by měly zobrazovat aplikaci stejně díky Flash playeru. Vyjímkou může být zobrazení textu, který je závislý na operačním systému, rozlišení a DPI. Nezávislost webové aplikace na nasazovaném serveru: ∙ 1 - Libovolný webový server. Možnosti pro tvorbu bohatého GUI aplikace: ∙ 1 - Podpora bohatého GUI, zvlášť textových možností. Oddělení prezentační, aplikační a datové vrstvy: ∙ 2 - Ve spojení s jinou komponentou je vhodnější vzhledem k front-endovému charakteru. Rozšiřitelnost webové aplikace: ∙ 1 - Velká možnost rozšiřitelnosti. Možnosti bohatého formátování textu a jeho manipulace. ∙ 1 - Velká možnost online text manipulace včetně bohatého formátování. Jedinou slabinou jsou zde složitější objekty jako je tabulka, která je ovšem nahraditelná jinou user control. Schopnost zachovat stejné formátování textu po transformaci. ∙ 2 - Poměrně dobře lze zachovat formátování největším problémem je zachování velikosti písma a nových řádků textu, který není odřádkován klávesou enter. 44
Jako celek a vhodnost použítí technologie Adobe Flex při implementaci webového editoru, který generuje dokument, bych hodnotil známkou 1. A to z následujících důvodů: Technologie poskytuje vhodné prvky pro tvorbu bohatých webových aplikací. Navíc poskytuje framework zaměřený na editaci textu na webu. Slabší stránkou jsou prvky pro business logiku, avšak ve spojení s jiným nástrojem nebo webovou službou se může stát silným prostředkem pro generování dokumentů. Vzhledem k tomu, že tento framework je poměrně nový, chybí zde nativní podpora pro export dokumentu nebo tisk. Je možné, že v dalších verzích tohoto frameworku se objeví tato funkcionalita. Záleží jen na směru vylepšení, kterým se tento framework vydá.
45
7.
Technologie Microsoft SilverLight 4
Jedná se poměrně o novou webovou technologii od firmy Microsoft. Pro běh aplikací SilverLight je nutné mít nainstalovaný plugin do prohlížeče podobně jako u platformy Flash (Flex). Pokud uživatel plugin naistalovaný nemá, je vyzván, aby si jej naistaloval (pomocí webového odkazu). Hlavním rozdílem oproti technologii Flash je způsob vykreslovaní obsahu. SilverLight používá k akceleraci obsahu grafickou kartu klientského počítače (tedy počítače uživatele), nikoli pouze procesor jako je tomu u technologie Flash. Nevýhodou může být úzká podpora pouze dvou platforem - Windows a MacOS. Hlavní výhodou oproti použití HTML je podobně jako u technologie Flex stejné vykreslení obsahu nezávislé na prohlížeči. Hlavním objektem pro práci s textem je Rich Text Editor (RTE). Detaily o textovém formátování lze nalézt v knize [7], str. 185.
46
8.
Dokumentace řešení Microsoft SilverLight 4
Tato kapitola obsahuje dokumentaci k prototypu vytvořeném v technologii Microsoft SilverLight 4. Dále obsahuje programátorskou dokumentaci, zjištěné problémy při vytváření dokumentu a analýzu použitelnosti této technologie pro textový webový editor s možností exportu do jednoho z formátů PDF, Docx apod.
8.1.
Diagram řešení
Znázornění prototypového řešení je na následujícím diagramu.
Obrázek 16. Schéma řešení technologie Silverlight.
47
Prototyp editoru vychází z MSDN příkladu http://msdn.microsoft.com/cs-cz/library/ff426926%28v=vs.95%29.aspx, který byl upraven a rozšířen o podporovanou funkčnost (formátování textu podporované TSgml formátem, vytvoření PDF). Xaml20 (viz kniha [8]) je exportován z editoru a předán WCF webové službě (DocService). Tato služba zajistí tranformaci vstupu na TSgml a vytvoření dokumentu PDF pomocí komponent firmy GMC Software Technology (PnetTserver a PrintnetConnect). Vrácený dokument je vytvořen na straně DocService a do SilverLight aplikace je vrácen odkaz na vytvořený dokument. Tento proces je znázorněn na obrázku 16.
8.2.
Implementovaná funkčnost
V této technologii pomocí objektu Rich Text Editor, který je zodpovědný za vykreslení a manipulaci s textem, byl vytvořen webový editor s následujícími prvky pro editaci textu: ∙ Tučné písmo. ∙ Podtržení písma. ∙ Kurzíva. ∙ Hyperlink. (Není exportován do PDF z důvodu omezení vyplývajících z formátu TSgml a WFD.) ∙ Druh písma. ∙ Velikost písma. ∙ Barva písma. Editor obsahuje i následující pomocné funkce: ∙ Export do PDF. ∙ Vyjmout. ∙ Kopírovat. ∙ Vložit. ∙ Tisk. ∙ Editovat a čist dokument. 20
XML notace pro objekty v technologii SilverLight.
48
∙ Zobrazení XAML21 . ∙ Nový dokument. ∙ Uložení webového dokumentu do XML. ∙ Načtení webového dokumentu z XML. ∙ Načtení textu z přetaženého (drag & drop) dokumentu Docx.
Obrázek 17. Editor v technologii Microsoft Silverlight 4.
8.2.1.
Možnosti rozšíření
V této technologii je značné omezení schopností bohatého formátování textu na webu i manipulace s textem přes api editoru. Při rozšíření o implementaci zarovnání odstavců vlevo, na střed, vpravo a do bloku jsou schopnosti editoru a bohatého formátování téměř vyčerpány. Narazíme zde na limity editoru, který sice dokáže zobrazit složitější elementy (grid, obrázek), ale manipulace a export těchto elementů není jednoduše možná.
8.3.
Popis tříd
Projekt se skládá z dvou hlavních částí - Webový editor v technologii SilverLight, webová služba WCF DocService. 21
XML notace objektů v technologii MS Silverlight.
49
8.3.1.
SilverLight Projekt
DocDownload Pomocná třída reprezentující okno pro stáhnutí souboru. Události a Metody: ∙
setErrorMessage Zveřejní chybu v HTML stránce.
∙
DocDownload_Click Vyzve uživatele k uložení souboru.
∙
CancelButton_Click Zrušení akce.
InsertURL Pomocná třída reprezentující okno pro zadání hyperlinku. Události a Metody: ∙
InsertURL Konstruktor, vytvoří hyperlink.
∙
OKButton_Click Potvzení vložení hyperlinku do textu.
∙
CancelButton_Click Zrušení akce.
PrintPreview Pomocná třída reprezentující okno obrázkem textu, který lze vytisknout. Události a Metody: ∙
ShowPreview Vytvoří bitmapu z aktuálního obsahu editoru.
∙
OKButton_Click Potvzení tisku.
∙
CancelButton_Click Zrušení akce.
MainPage Pomocná třída reprezentující editor textu s menu. Události a Metody: 50
∙
MainPage_Loaded Inicializace editoru textem.
∙
btnBold_Click Aplikuje tučné písmo na vybraný text.
∙
btnItalic_Click Aplikuje kurzívu na vybraný text.
∙
cmbFonts_SelectionChanged Aplikuje změnu písma na vybraný text.
∙
cmbFontSizes_SelectionChanged Aplikuje změnu velikosti písma na vybraný text.
∙
cmbFontColors_SelectionChanged Aplikuje změnu barvy na vybraný text.
∙
btnHyperlink_Click Otevře podokno pro zadaní webového odkazu.
∙
btnCut_Click Aplikuje operaci vyjmout na vybraný text.
∙
btnCopy_Click Aplikuje operaci kopírovat na vybraný text.
∙
btnPaste_Click Aplikuje operaci vložit do textového editoru.
btnMarkUp_Checked Zobrazí-Schová aktuální XML reprezentaci objektů v textovém editoru.
∙
btnRO_Checked Zapne-vypne read-only mód editoru.
∙
rtb_Drop Načtení textového nebo Docx souboru přetažením do editoru.
51
∙
ParseTextFile Získá text z textového souboru.
∙
ParseDocxFile Získá text z Docx souboru.
∙
btnNew_Click Vymaže obsah textového editoru.
∙
btnSave_Click Vyzve uživatele k uložení XML z textového editoru.
∙
btnOpen_Click Vyzve uživatele k načtení XML z textového editoru.
∙
rtb_SelectionChanged Změna místa kurzoru v textovém editoru.
∙
UpdateTextCntrlState Nastaví konkrétní hodnoty atributů textu na správné hodnoty v menu (barva, velikost apod.).
∙
SelectComboBoxItem Vybere hodnotu daného ComboBoxu.
∙
btnSave_PDF_Click Získá XML z editoru, zavolá webovou službu a spustí progress bar. Při získání odezvy otevře okno s vytvořeným dokumentem.
∙
TogleProgress Zobrazí-Skryje progressbar.
8.3.2.
WCF DocService
Tato část již byla v tomto textu zdokumentována dříve, viz WCF DocService.
52
8.4.
Problémy při vytváření dokumentu
Při implementaci tohoto prototypu byly zjištěny i některé problémy v rámci této technologie, které znesnadňovaly vytvoření kvalitního editoru a jednoznačně identické reprezentace dokumentu PDF s webovým protějškem. Jedním z problémů při vytváření editoru samotného byl fakt, že rich text editor podporuje jen základní funkcionalitu práce s textem a neposkytuje jednoduché API pro zíkávání informací o textu, na kterém se aktuálně nachází kurzor. I když byl napsán kód správně podle dokumentace editoru tak, aby získával informaci o formátování textu, na kterém se nachází kurzor, tak při pohybu kurzoru v textu vpřed i vzad se část informace o aktuálním formátování schodovala s nadřazeným elementem. V tomto případě je vždy nadřazeným elementem paragraph a podelementem je tzv. Run. Výsledkem tohoto chování je při pohybu kurzoru nesprávná informace uživatele o zvoleném typu, velikosti a barvy písma slova, na kterém se nacházel kurzor. Tato informace se podobně jako je tomu v editoru Microsoft Word, zobrazuje na panelu tlačítek, které zajišťují jednotlivé formátování. Jedinou variantou, kdy dostaneme tuto informaci správnou, je vybrání (označení) části textu kurzorem. Omezení možností rich text editoru určovalo počet funkcionalit, které byly implementovány. Editor obsahuje jen základní funkcionality, jako jsou písma, barvy, zarovnání vpravo, vlevo a na střed, tím jsme ale jeho možnosti skoro vyčerpali. Jednou věcí je, jaké elementy editor dokáže zobrazit, druhou věcí je, jak tyto elementy reprezentuje a jak je možno s nimi manipulovat. Zde však narazíme na velký extrém. Editor sice dokáže zobrazit složitější element, jako je např. Grid s nějakými tabulkovými daty, pokud si ale vyexportujeme Xaml22 reprezentaci objektů z editoru, složitější elementy v něm nejsou. Dostaneme tedy neúplnou informaci o tom, co editor obsahuje. Abychom dostali úplou informaci o všech elementech v editoru, je nutné jít trnitější cestou a napsat vlastní logiku, která prochází tzv. Object tree (hierarchie tříd v editoru) a exportuje element po elemetu do XML. Pokud už bychom tuto funkcionalitu implementovali, narazíme na další problém, jak s těmito elementy v editoru manipulovat. Rich text editor, který je schopen tyto elementy zobrazit, nám ale nenabízí skoro žádné možnosti, jak s těmito elementy dynamicky manipulovat nebo měnit jejich vlastnosti. Omezení možností je zde značné. V některých případech dokonce paradoxní. Například podpora undo a redo je zde částečná. Editor tyto operace umí na povel klávesových zkratek (ctrl+z, ctrl+y), ale objekt editoru takové metody pro volání neposkytuje. K tomu, abychom tyto operace mohli vyvolat, potřebujeme vlastní implementaci těchto operací. Další možnosti, jako jsou nastavení výšky řádku a odsazení prvního řádku v odstavci, zde nenajdeme a opět bychom museli 22
XML notace pro objekty v technologii SilverLight.
53
jít vlastní implementací. I zde narazíme na čas potřebný k transformaci vstupní reprezentace na výsledný dokument, tedy převod XAML na TSgml pomocí XSLT šablony src/DocService/DocService/Xsl/SilvXaml2Tsgml. I zde byla zvolena cesta vrácení odkazu na vytvořený dokument, raději než jeho serializaci a deserializaci při cestě zpět k uživateli, která by způsobovala zpoždění při žádosti o vytvoření dokumentu. Výsledný čas vytvoření dokumentu by měl být do pěti sekund na nasazeném serveru. Po prvním vytvoření je čas opět o něco rychlejší, než vytvoření první. Dalším problémem je podobně jako u ostatních prototypů automatické zalomení textu, který je delší než jeden řádek. Rich text editor, který sám o sobě neví nic o jakémkoliv formátu papíru např. A4, nám navíc neřekne, které slovo končí na jakém řádku, pokud uživatel text neodřádkuje klávesou enter, v takovém případě je řádkování vždy zachováno. Velikost textu i editoru je udávána v pixelech. Protože se jedná o složtější problém, který je spojený s druhem, velikostí a stylem písma, DPI, operačním systémem, nebyl tento problém úplně vyřešen. Výsledkem je jistý kompromis, který zachovává formátování s tím, že v případě textu delšího než jeden řádek nám některá slova, která ve webové reprezentaci jsou na řádku předchozím, končí na dalším řádku v dokumentu PDF. Rich text editor v technologii SilverLight dokáže zobrazit bohaté elementy, ale při implementaci funkčnosti, manipulace s textem a exportu narazíme na řadu problémů.
8.5.
Analýza SilverLight 4
Tato kapitola obsahuje analýzu použitelnosti technologie SilverLight 4 k vytvoření webového editoru s bohatou možností editace textu na webu a exportem do PDF. 8.5.1.
Editor
SilverLight je novou webovou technologií, která odstiňuje rozdíly v renderování obsahu v různých prohlížečích díky pluginu naistalovanému v prohlížeči. Navíc firma GMC Software Technology projevila zájem o tuto technologii, protože jejich produkty využívají .NET framework. Proto se jedná se zajímavého kandidáta pro vytvoření prototypu editoru. Bohužel tato technologie neobsahuje textový framework zaměřený vyloženě na manipulaci a renderování bohatě formátováného textu. Obsahuje však Rich Text Editor, s jehož pomocí lze manipulovat s textem a dosáhnout bohatšího formátování. Tento editor byl rozšířen v rámci možností této technologie o bohaté formátování a export webové 54
reprezentace textu do PDF. Výhody tvorby editoru ve Silverlight 4: ∙ Kompatibilita s nejrozšířenějšími platformami. ∙ Odpadá problém s různým zobrazením v různých prohlížečích díky SilverLight pluginu. ∙ Nezávislost nasazení stránky s řešením na platfomě. (Výsledkem je HTML stránka a xap soubor, který se zobrazí v rámci SilverLight pluginu.) Pro hostování SilverLight aplikace tedy není vyžadována platforma Windows. ∙ Nástroje a knihovny dostupné v klientském řešení díky .NET. Nevýhody tvorby editoru v Silverlight 4: ∙ Absence mocnějších nástrojů pro manipulaci textu. ∙ Chybí jednoduchý export do Adobe PDF, Docx apod. ∙ Při exportu XML z webového editoru není zahrnuto XML složitějších elementů jako např. tabulek apod. typu UIElement. Jedinou možností, jak získat úplné XML všech objektů v editoru, je napsat vlastní XML generátor, který by procházel rekurzivně všechny objekty v editoru a vracel XML. Tato cesta je bohužel jedinou možností jak získat úplnou informaci o všech objektech v editoru. V konfrontaci s ostatními technologiemi je zde otázka, proč jít touto složitější cestou. ∙ Chybí možnost vytvořit tabulku v editoru (pouze jako složený objekt, který však nebude v exportovaném XML). 8.5.2.
Vytvoření dokumentu
SilverLight je technologie zaměřená zejména na grafické prvky, nástroje pro business logiku je možné přilinkovat do zkompilovaného SilverLightího souboru. Vhodnějším řešením však bývá volání webových služeb ze SilverLight aplikace. Vytvořený prototyp postavený na Rich Text Editoru, jehož XML (XAML23 ) lze exportovat, využívá volání WCF webové služby. Tato služba zajištuje tranformaci XML na TSgml a vytvoření PDF dokumentu pomocí komponent od firmy GMC Software Technology. Tato technologie bohužel neobsahuje nástroj nebo knihovnu, která by byla schopna vrátit webovou reprezentaci textu v nějakém podporovaném formátu (PS, PDF, Docx).
23
XML notace pro vytáření webových prvků v technologii SilverLight.
55
Pro transformace lze v této technologii využít následující: ∙ JavaScript a XSL. ∙ Transformace provedená skrz volání jiné aplikace (webové služby). ∙ .NET knihovna použitelná pro převod vložená do SilverLight aplikace. K transformaci byla použita druhá varianta. Jedná se o vhodnější oddělení Front-Endové aplikace od business logiky. 8.5.3.
Alernativní možnosti
JavaScript a XSL - Řešením by mohlo být vložení JavaSriptové funkce do SilverLight řešení, která by provedla XSL transformaci s předaným XML a XSL šablonou. Podobně jako u technologie Flash by pak bylo možné generovat např. Open XML formát Docx. .NET použitelná pro převod - Zde by k dipozici musela být nějaká open-source knihovna v .NET která by provedla XSL transfromaci, pomocí ní by bylo možné generovat open XML formát dokumentu Docx. Největším problémem těchto přístupů je komplexnost cílového formátu, nemluvě o schopnosti generovat stejně vypadající dokument jako dokument zobrazený na webu. Pokud bychom ale chtěli výsledný dokument převést na jiný formát, opět bychom se potýkali s absencí nástrojů na podobné operace. 8.5.4.
Hodnocení a Závěr
Spojením Silverlight 4 a Windows Communication Foundation se podařilo vytvořit textový editor, který umožnuje bohatou úpravu textu. Dále se podařilo provést transformaci XML a získat dokument, který vzhledově odpovídá úpravě textu na webu. Nejdůležitější kritéria pro hodnocení technologie: ∙ Vhodnost pro vytvoření webového editoru. ∙ Vhodnost technologie pro vytváření dokumentu. ∙ Nezávislost technologie na prohlížečích (i prohlížeče různých platforem). ∙ Nezávislost zobrazení webové aplikace v prohlížeči. ∙ Nezávislost řešení na nasazovaném serveru. ∙ Možnosti vytvořit bohaté GUI webové aplikace. 56
∙ Oddělení prezentační, aplikační a datové vrstvy. ∙ Možnosti rozšiřitelnosti webové aplikace. ∙ Možnosti bohatého formátování textu a jeho manipulace. ∙ Schopnost zachovat stejné formátování textu po transformaci. Pokud bychom zvolili následující stupnici hodnocení: 1 - Velmi vhodné (výborně). 2 - Méně vhodné (dobře). 3 - Nevhodné (nedostačující). Výsledek hodnocení technologie SilverLight 4 by vypadal následovně: Vhodnost technologie SilverLight 4 pro imlementaci webového editoru: ∙ 2 - Základní operace s textem dostupné, chybí však pokročilejší možnosti (undo-redo manager, úplné XML z editoru apod.). Vhodnost technologie pro vytváření dokumentu: ∙ 2 - Ve spojení s jinou komponentou či webovou službou. Nezávislost technologie na prohlížečích (i prohlížeče různých platforem): ∙ 2 - Většina nejrozšířenějších platforem a prohlížečů podporuje tuto technologii. Nezávislost zobrazení webové aplikace v prohlížeči: ∙ 1 - Prohlížeče podporovaných platforem (Windows OS, Mac OS) zobrazují aplikaci stejně díky pluginu. Nezávislost webové aplikace na nasazovaném serveru: ∙ 1 - Libovolný webový server vhodný pro web-hosting, pokud uvažujeme jen o aplikaci napsané v SilverLight. Možnosti pro tvorbu bohaté GUI aplikace: ∙ 1 - Podpora bohatého GUI, animací a hardwarové akcelerace. Oddělení prezentační, aplikační a datové vrstvy: ∙ 1 - Ve spojení s jinou komponentou je vhodnější vzhledem k front-endovému charakteru. 57
Rozšiřitelnost webové aplikace: ∙ 2 - Limitované možnosti pro editaci textu. Možnosti bohatého formátování textu a jeho manipulace. ∙ 3 - Možnosti Rich Text Editoru pro jednoduchou manipulaci s textem jsou značně omezené, na profesionální nástroj k výrobě dokumentů je to nedostatečné. Vývojový tým by musel vyvinout poměrně velké úsilí, aby obešel všechny problémy a získal výsledek, který by byl konkurenceschopný vzhledem k editaci textu na webu a jiným alternativám. Schopnost zachovat stejné formátování textu po transformaci. ∙ 2 - U jednoduššího formátování lze dobře zachovat formátování s malými odlišnostmi, problémem je malý počet prvků, které lze jednoduše exportovat z webové reprezentace do XML při zachování všech textových informací o jednotlivém prvku. Jako celek a vhodnost použítí technologie SilverLight při implementaci webového textového editoru, který generuje dokument, bych hodnotil známkou 3. A to z následujících důvodů: Technologie umožňuje vytvoření bohatého uživatelského prostředí. Slabší stránkou je shopnost manipulace s textem. Technologie obsahuje Rich Text Editor, ale v aktuální verzi 4 nedává vývojářům široké možnosti k editaci textu. V některých případech manipulace s textem přes objekty, které text zapouzdřují, je težkopádná a nepochopitelná (Například při získávání informací o textu, který se nachází na aktuální pozici kurzoru nelze tuto informaci jednoduše získat. Informace o textu, kterou dostaneme, se střídá s nadřazeným elementem a tedy je nepřesná.). Další nevýhodou je, že i když můžeme v editoru zobrazit složitější objekty, při exportu XML z editoru o nich nemáme žádné informace. U této technologie, podle mého názoru, tedy chybí mocnější prvky a podpora pro bohaté formátování textu na webu.
58
9.
Installace a nasazení na server
Pro běh protypových řešení je nutné naistalovat software od firmy GMC Software Technology, který je schopen z xml formátu TSgml a Wfd šablony vytvořit dokument různých formátů (Docx,PDF, RTF ...). K instalaci je nutná platforma Windows, .NET Framework ve verzi 4.0 a IIS Server 7.0. Jedná se o dva produkty: PrintNetTServer a PrintNetConnect. Produkt PrintNetTServer zajištuje vytvoření dokumentu, PrintNetConnect zajištuje komunikaci mezi externími komponentami nebo řešeními a PrintNetTServerem. Oba produkty využívají demo licence, kterou uživatel vloží běhěm instalace. Licence je zajištěna jedním licenčním souborem (soubor s koncovkou *.lic), který obsahuje demo licenci běžně na tři až šest měsíců. Pro oba produkty stačí jeden stejný soubor. Na požádání lze zdarma obdržet demolicenci od firmy GMC Software Technology.
9.1.
PrintNetTServer
Instalace PrintNetTServer pomocí instalátoru krok za krokem. Instalátor lze nalézt ve složce bin/Install/Setup-PrintNet-T-6.1-SP2-32.exe.
Obrázek 18. PrintNetTServer instalátor, krok 1.
59
Obrázek 19. PrintNetTServer instalátor, krok 2.
Obrázek 20. PrintNetTServer instalátor, krok 3.
60
Obrázek 21. PrintNetTServer instalátor, krok 4.
Obrázek 22. PrintNetTServer instalátor, krok 5.
61
Obrázek 23. PrintNetTServer instalátor, krok 6.
Obrázek 24. PrintNetTServer instalátor, krok 7.
62
Obrázek 25. PrintNetTServer instalátor, krok 8.
Obrázek 26. PrintNetTServer instalátor, krok 9.
63
Obrázek 27. PrintNetTServer instalátor, dokončení instalace.
9.2.
PrintNetConnect
Instalace PrintNetConnect pomocí instalátoru krok za krokem. Instalátor lze nalézt ve složce bin/Install/Setup-PrintNet Connect-6.1.1.66-Hotfix.exe.
64
Obrázek 28. PrintNetConnect instalátor, krok 1.
Obrázek 29. PrintNetConnect instalátor, krok 2.
65
Obrázek 30. PrintNetConnect instalátor, krok 3.
Obrázek 31. PrintNetConnect instalátor, krok 4.
66
Obrázek 32. PrintNetConnect instalátor, krok 5.
Obrázek 33. PrintNetConnect instalátor, krok 6.
67
Obrázek 34. PrintNetConnect instalátor, krok 7.
Obrázek 35. PrintNetConnect na IIS7. Po úspěšné instalaci se na IIS serveru vytvoří Virtual Directory se jménem printnetconnect (standardně v C:/intepub/wwwroot/printnetconnect). Dále je potřeba nastavit v souboru: intepub/wwwroot/printnetconnect/pncappsettings.config hodnotu wseonly na false.
68
9.3.
Prototypy Editoru
Instalace business logiky (DocService) a frontendových aplikací - MVC, Flex a SilverLight na IIS 7. 9.3.1.
DocService
DocService je projekt, který zajišťuje transformaci XML z editoru a vytvoření výsledného dokumentu pro technologie Flex a SilverLight. Konfigurace IIS Serveru Uvedený postup platí pro systémy Vista/Windows 7. Testovanou platformou byla anglická verze Windows 7 x64. Analogické kroky platí pro Windows Server 2008. V systému je potřeba naistalovat Internet Information Services (IIS) server (U systému Vista/Win7 se jedná o IIS 7, a IIS 6 comapatability manager). Po instalaci IIS v sekci (Contol Panel / Programs / Turn Windows features on or off )nejsou vybrané standardní komponenty dostačující. Potřebujeme vybrat alespoň Windows authentication, IIS 6 Management Compatibility (pro visual Visual Studio) a pravděpodobně i další. Je vhodné je vybrat všechny.
Obrázek 36. Povolení IIS 7. 69
V otevřeném dialogu “Turn Windows features on or off” musíme zapnout sub-componenty .NET 3.5: WCF HTTP a Non-HTTP Activation. Je důležité, abychom po potvrzení restartovali počítač, i když k tomuto kroku nejsme vyzváni.
Obrázek 37. Povolení komponent IIS 7. Pokud se jedná o instalaci IIS server, je nutné zaregistrovat i ASP.NET componenty pro IIS spuštěním C: /Windows/Microsoft.NET/Framework/v2.0.50727/aspnet_regiis.exe –i Nakonec je nutné registrovat WCF také pro IIS (např. pro rozpoznání .svc koncovky) spuštením C:/Windows/Microsoft.NET/Framework/v3.0/ Windows Communication Foundation/ServiceModelReg.exe –i Na IIS serveru je vhodné vytvořit virtual directory se jménem rbdiploma, která bude obsahovat další čtyři virtual directory pro běh všech prototypů. Nasazení WCF Služby Instalace DocService (WCF webové služby, která vytvoří dokument). Nejjednodušší a nejrychlejší cestou je otevřít projekt src/DocService/DocService.sln ve Visual Studiu 2010, kliknout na projekt DocService v solution exploreru a v menu kliknout na : Build->Publish DocService. Jako adresu zadat http://localhost/rbdiploma/DocService/. Tato adresa je pak předána jako parametr klientům (Flex 4, SilverLight4). Visual Studio automaticky na IIS serveru vytvoří novou virtuální directory s WCF webovou službou DocService. Aplikační pool by měl mít práva zápisu a modifikace. Složka Public by měla být dostupná i pro anonymního uživatele.
70
Obrázek 38. Publikace webové služby na IIS 7. Druhou možností je zkopírovat obsah složky /src/DocService/DocService do nové virtual directory na IIS serveru. Virtual directory by se měla jmenovat DocService, vzhledem k další konfiguraci projektů, které budou s touto službou komunikovat. Třetí možností je vytvořit WCF instalátor, což by ale vyžadovalo další vývoj, který vzhledem k výše zmíněným alternativním řešením není nutný. 9.3.2.
FCK a ASP.NET MVC 2
Pro běh této aplikace je nutný .NET Framework 4.0. Na IIS severu v kořenové virtual directory (rbdiploma) vytvoříme novou virtual directory se jménem MVC. Jako aplikační pool zvolíme .NET Framework 4.0. Obsahem bude složka src/ASP.NETMVC/MvcApplication1/MvcApplication1, kde nastavíme práva zápisu a modifikace v podsložkách pro aplikační pool. 9.3.3.
Flex 4
Pro běh této aplikace nám stačí .NET Framework 2.0. Na IIS severu v kořenové virtual directory (rbdiploma) vytvoříme novou virtual directory se jménem FLEX. Jako aplikační pool zvolíme .NET Framework 2.0. Obsahem 71
bude složka src/FlexProjects/FlexProject/bin-debug, ve které nastavíme práva zápisu a modifikace v podsložkách pro aplikační pool. Nastavíme WCF DocService url jako parametr v SimpleEditor.html stránce. AC_FL_RunContent( "src", "SimpleEditor", "width", "100%", "height", "1000", "align", "middle", "id", "SimpleEditor", "quality", "high", "flashvars", "docserviceurl= http://localhost/rbdiploma/docservice/documentservice.svc", "bgcolor", "#ffffff", "name", "SimpleEditor", "allowScriptAccess","sameDomain", "type", "application/x-shockwave-flash", "pluginspage", "http://www.adobe.com/go/getflashplayer" ); Crossdomain Do kořenového uzlu celého IIS serveru je potřeba zkopírovat dva soubory, které povolují komunikaci klientů s webovou službou. Do kořenové virtual directory zkopírujeme tedy src/clientaccesspolicy.xml a src/crossdomain.xml. 9.3.4.
SilverLight 4
Pro běh této aplikace nám stačí .NET Framework 2.0. Na IIS severu v kořenové virtual directory (rbdiploma) vytvoříme novou virtual directory se jménem SL. Jako aplikační pool zvolíme .NET Framework 2.0. Obsahem bude složka src/SL/SilverlightTextEditor/SilverlightTextEditor/Bin/Debug a v ní nastavíme práva zápisu a modifikace v podsložkách pro aplikační pool. Pokud jsme tak dosud neučinili, nesmíme zapomenout na dva soubory viz Crossdomain. Nastavíme WCF Docservice url jako parameter v Index.html:
