Framework pro návrh responzivního uživatelského rozhraní nové generace

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Framework pro návrh responzivního uživatelského rozhraní nové generace Bc. Lukáš Rychtecký Vedoucí práce: Ing. Tomáš Černý Studijní program: Otevřená informatika, Magisterský Obor: Softwarové inženýrství a interakce 8. května 2013

2 iv

3 v Poděkování V první řadě bych rád poděkoval vedoucímu diplomové práce panu Ing. Tomáši Černému za pozornost, kterou věnoval mé práci a za jeho odborné rady. Dále bych rád poděkoval své přítelkyni Tereze, blízkým přátelům a rodině. Také děkuji Ivě a Honzovi za stylistické poznámky.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract Today s web is rapidly evolving. Not only desktop computers are used for browsing websites, use of mobile devices is growing rapidly. These devices have above all different screen sizes and different ways of operating (mostly by touch screens). This increases the requirements for creating web pages, thereby increasing costs for development and maintenance. The web provides and manipulates user data. The data validation depends on their types. Modern web pages validate data in an user interface. Validation rules depend on model s classes, so each of their change leads to modification of user interfaces. Such modifications are expensive and liable to mistakes. Goal of this work is to show a way how to significantly reduce the costs of maintaining of user interfaces. Automatic generation of validation from the model class is a new and completely different way of creating of the user interface. Possible ways of costs reduction on the development will be shown, together with nowadays options for maintenance of modern web applications for various devices. Abstrakt Dnešní web se velmi rychle vyvíjí. K zobrazení webových stránek již nepoužíváme jen počítače, ale i mobilní zařízení. Tato zařízení mají odlišný způsob ovládání či velikost obrazovky. To zvyšuje požadavky při tvorbě webových stránek a tím vzrůstají náklady pro vývoj i údržbu. Web poskytuje i zpracovává uživatelská data. Protože jsou data různých typů, jsou často validována. Moderní webové stránky validují data již na úrovni uživatelského rozhraní. Validační pravidla jsou závislá na modelových třídách, proto každá jejich úprava vede k úpravě uživatelského rozhraní. To je nejen nákladné, ale i náchylné na chyby. Cílem práce je najít způsob, jakým lze výrazně zredukovat náklady na údržbu uživatelského rozhraní. Automatické generování validace přímo z modelových tříd je nový a zcela odlišný způsob tvorby uživatelského rozhraní. Ukážeme si i možnosti, jak zredukovat náklady při tvorbě a správě moderních webových aplikací pro různá koncová zařízení. ix

8 x

9 Obsah 1 Úvod 1 2 Popis problému a speficikace požadavků Tvorba moderního webu Požadavky Souhrn požadavků Rešerše Moderní web Validace dat Shrnutí Inplace editace Shrnutí JSF frameworky Shrnutí Analýza a návrh řešení Responzivní design Aplikace CSS Klientská validace Nová komponenta Rozšíření RenderKit Porovnání přístupů Inplace editor Vytvoření editačního pole na straně klienta Generování formuláře na straně serveru Návrh inplace komponenty Použité technologie AspectFaces Výhody Google Closure Library oproti jquery CoffeeScript Mocha LESS CSS xi

10 xii OBSAH 5 Realizace HTML5 validace Integrace s PrimeFaces Integrace H5F Responzivní komponenty Aplikace CSS Inplace editor Distribuce TNT faces Integrace s AspectFaces Testování Jednotkové testování Testování responzivních komponent Uživatelské testování Závěr Integrační testování Výkonové testování Závěr Budoucí práce Seznam použitých zkratek 59 9 Obsah přiloženého CD Apendix A Definice případů užití

11 Seznam obrázků 2.1 Průběh inplace editace, zdroj: [22] Ilustrační znázornění responzivního webu, zdroj: [19] JSF implementace MVC[5] JSF životní cyklus[4] Schématické znázornění responsivních TNT komponent Sekvenční diagram vykreslovací fáze JSF s generováním klientské validace Životní cyklus inplace editoru Obrazovka testovací aplikace - ipad vertikálně Obrazovka testovací aplikace - ipad horizontálně Obrazovka testovací aplikace - iphone vertikálně Obrazovka testovací aplikace - iphone výběr stránky z horizontálního menu Validační zpráva při chybně vyplněné ové adrese Validační zpráva při nevyplnění povinného pole Formulář pro výkonové testování xiii

12 xiv SEZNAM OBRÁZKŮ

13 Seznam tabulek 2.1 Souhrn všech požadavků Matice pokrytí požadavků 2.1 případy užití Matice porovnání polyfillů pro HTML5 validaci Matice porovnání knihoven pro inplace editaci Matice porovnání jednotlivých JSF frameworků Přehled responzivních TNT komponent Přehled rozdělení množin atributů Testování výkonu PrimeFaces komponent Testování výkonu s rozšířením TNT faces xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod Web jako médium se velice rychle vývíjí. Doba, kdy byl web dostupný pouze pro počítače, je již dávno pryč. Dnešní webové stránky vytváříme pro počítače, mobilní telefony, tablety a další jiná zařízení. Z toho jsou patrné požadavky a vyšší náklady na vývoj a údržbu. V této práci se seznámíme s pojmem responsive design a ukážeme si řešení, které redukuje náklady pro vývoj responzivních webových stránek. Uživatelské rozhraní je první s čím přijde uživatel do styku, chápeme jej jako např. webovou stránku, okno aplikace i internetový prohlížeč. Uživatelské rozhraní zobrazuje obsah, poskytuje cenné informace i sbírá data od uživatele. Je to tedy oboustranný komunikační kanál. Proto není vhodné podceňovat kvalitu uživatelského rozhraní. Uživatelské rozhraní se netýká pouze obrazovky počítače, ale i mobilních zařízení. S mobilním zařízení můžeme přistupovat na webové stránky jako s počítačem. V dnešním světe existuje celá řada zařízení, s kterými lze přistupovat na web. Tyto zařízení se časo liší ovládáním a velikostí obrazovky. Když si zobrazíte webovou stránku na počítači a mobilním telefonu dostanete různá uživatelská rozhraní. Protože každé zařízení má jiný způsob ovládání (klávesnice, dotyková obrazovka,... ), musíme při tvorbě webových stránek s těmito požadavky počítat. Do těchto požadavků patří i optimalizace zobrazení obsahu koncovému zařízení. S dotykovou obrazovkou má uživatel jiné motorické schopnosti než s počítačovou myší, s čímž je potřeba při tvorbě webu počítat. Naším cílem je poskytnout uživateli dané informace tak, aby si je mohl co nejlépe vychutnat. Jelikož uživatelské rozhraní je obousměrný komunikační kanál, data nejen zobrazuje, ale i sbírá. Takto získáná data mohou být jsou různých typů, např. jména, data narození, barvu očí či výšku postavy. Tato data mají učitá omezení, např. výška postavy nemůže být záporné číslo. Proces, kdy uživatelské rozhrnaní či systém kontroluje, zda data odpovídají těmto omezením, nazýváme validace dat. Každý systém, který zpracovává data je musí nějakým způsobem validovat. Správa obsahu webové stránky je často realizována formulářem. Uživatel, který spravuje daný obsah, pracuje se dvěma pohledy: editační a prohlížecí. Správa obsahu může být pro uživatele komplikovaná či matoucí. Obsah webové stránky se mezi pohledy často velice liší. Tento přístup může být pro některé uživatele matoucí. V následujících kapitolách si ukážeme přístup, jak uživateli dovolit editovat obsah, který je v obou režimech takřka totožný. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Popis problému a speficikace požadavků 2.1 Tvorba moderního webu Web byl založen koncem devadesátých let 20. století. V listopadu 1990 Robert Cailliau publikoval žádost[6] na projekt "WorldWideWeb". Tato žádost popisovala hypertextové dokumenty, prohlížeče a způsob komunikace klient-server. Web zobrazoval statický obsah a fungoval jako read-only medium 1. Od té doby následoval vývoj webu až do podoby jak ho známe dnes. V roce 1999 byl poprvé použit termín Web 2.0[10] v článku "Fragmented Future". DiNucci zde píše: Web, který známe dnes, načte do okna prohlížeče v podstatě statické stránky, je jen zárodek webu, který teprve přijde. První záblesky webu 2.0 se začínají objevovat a my teprve teď začínáme vidět, v co se toto embryo skutečně může vyvinout. Web už nebude chápán jako statická stránka textu a grafiky, ale jako transportní mechanismus, éter, jehož prostřednictvím interaktivity budeme komunikovat. Web se zobrazí na obrazovce počítače, na vašem televizoru, palubní desce automobilu, mobilním telefonu, ručním herním stroji a možná i na mikrovlnné troubě. Během vzniku různých zařízení zobrazujících web, vznikly i požadavky na optimalizaci zobrazení webu na daném zařízení. Optimálně zobrazit webovou stránku na mobilním zařízení (které má typicky menší rozlišení než bežný monitor pořítače) může být problém. Obrázek o velikosti 300x300 (šířka a výška v pixelech) na zařízení velkém 240x320 optimálně zobrazit nelze. Prohlížeč, na mobilním zařízení, webovou stránku vykreslí zmenšenou, aby přibližne odpovídala zobrazení na monitoru počítače. Takto změnšená stránka se většinou obtížně čte a uživatel je nucen si stránku přiblížit. Po přiblížení je sice text čitelný, ale zase se ztrácí náhled a orientace nad celou stránkou. Takový přístup uživateli zkomplikuje a znepříjemní konzumaci obsahu webové stránky. Při tvorbě aplikací, nejen webových, je nutné kontrolovat a validovat uživatelský vstup. Uživatelská data jsou validována pomocí business pravidel. Tato pravidla určují např. formát 1 V té době neexistovalo nic jako wiki, ani dynamická správa obsahu webu 3

18 4 KAPITOLA 2. POPIS PROBLÉMU A SPEFICIKACE POŽADAVKŮ vstupního pole ( ová adresa), nebo datum v minulosti (datum narození) atd. Představme si klasickou třívrstvou architekturu [15], která se dnes běžně používá nejen u enterprise systémů. Aplikace je typicky rozdělena na persistentní vrstvu, která se stará o uchování dat, business vrstvu, zde jsou aplikovány business pravidla a prezentační vrstvu, která zprostředkovává a příjmá uživatelská data. Na každé vrstvě, výše uvedené architektury, jsou data filtrována. Data nejsou typicky validována pouze podle vstupního fortmátu, ale i podle uživatelských rolí. Vstupní pole může být povinné např. pro roli Uživatel, ale pro roli Administrátor je pole volitelné. Tento přístup se nazývá Role-based Access Control (RBAC)[9]. Díky tomu, že jsou data validována na několika vrstvách, dochází zde k duplikaci validačních pravidel. Úprava nebo přidání validačního pravidla je tedy náchylné na chybu. Vývojář se musí postarat o to, aby na všech daných vrstvách se pravidlo aplikovalo. Je tedy snadné si představit situaci, kdy vývojář zapomene aplikovat pravidlo na dané vrstvě a tato chyba se objeví až v produkčním prostředí při interakci komponent či systémů. Java EE přichází s podporou Beans Validation[13], kdy se validační pravidla zapisují pouze do modelu[16]. Na následující ukázce kódu 2.1 je entita User, která má objekt username. 2 class User { 3 = true) 7 String username; 8 } Listing 2.1: Příklad anotované třídy pro JPA Anotace Entity označuje třídu, která bude persistována v databázi. Na objekt username jsou aplikována tato tři pravidla: uživatelské jméno bude = true) uživatelské jméno nesmí být null (je anotace UiOrder určuje pořadí vstupního pole v UI Tato validační pravidla jsou na objekt aplikována nejenom před uložením do databáze, ale i při validaci uživatelského vstupu v prezentační vrstvě. U webových aplikací probíhá validace typicky na dvou stranách: klientské a serverové. Obě tyto validace patří do prezentační vrstvy. Jediná strana, které se dá věřit, je serverová. Protože klientskou validaci lze potlačit deaktivací JS v prohlížeči. Přesto se klientská validace hojně používá z důvodu lepší interakce s uživatelem[21]. Uživatel komunikuje s aplikací přímo a prakticky okamžitě obdrží odpověď. Další výhodou je, že uživatel není nucen odeslaný formulář vyplnit znovu, či čekat na odpověď od serveru. Inplace editor nebo inplace editace je způsob úpravy webové stránky, bez nutnosti administračního rozhraní. Inplace editor uživateli poskytuje velice jednoduchou a rychlou úpravu obsahu webu.

19 2.1. TVORBA MODERNÍHO WEBU 5 Inplace editor ve stavu prohlížení vypadá jako obyčejný text. Tento text může být doplněn vhodnou ikonou (např. tužky) či hover 2 efektem, aby uživatel pochopil, že je daný text editovatelný. Na obrázku 2.1 je vidět inpalce editor s hover efektem - uživatel najede kursorem myši nad text a ten se zvýrazní. Editovatelný text může být doplněn i vhodným titulkem jako v tomto případě - "Click to edit". Editace je aktivována kliknutím na text a editor přejde ze stavu prohlížení do stavu editace. Editovaný text se zobrazí v obsahu pole a pod polem se zobrazí dvě tlačítka, Save pro uložení a Cancel pro stornování editace. Na vstupní pole je aktivován focus 3 a pole přebralo stylování z editovaného textu v prohlížecím režimu. Přebírání stylování uživateli maximálně přiblíží vzhled editovaného textu z režimu prohlížení. Během ukládání je editovaný text zaměněn za text "saving... ", aby se neztratila interakce mezi uživatelem a webovou stránkou. Po uložení vypadá text jako na začátku. Obrázek 2.1: Průběh inplace editace, zdroj: [22] obsah pole je označen a uživatel může rovnou psát

20 6 KAPITOLA 2. POPIS PROBLÉMU A SPEFICIKACE POŽADAVKŮ 2.2 Požadavky Cílem je implementovat podporu HTML5 validace pro JSF s knihovnou zajišťující klientskou validaci pro prohlížeče, které nepodporují HTML5 validaci. Protože HTML5 přináší mimo validace další funkce, bude knihovna podporovat následující vlastnosti: autofocus 4 placeholder 5 A vstupy typu 6 : datetime date month time week number url search tel color Knihovna pro JS validaci bude podporovat tyto vlastnosti: povinné pole validace podle regulárního výrazu - kontrola platného formátu url - kontrola platného formátu JS knihovna bude aktivována pouze v případě, že daný prohlížeč neimplementuje HTML5 validaci. Budou implementovány JSF komponenty pro usnadnění implementace responzivního uživatelského rozhraní. Komponenty budou sloužit k prototypování i ke koncovému použití. Pomocí komponent bude možné vytvořit horizontální menu, hlavičku a tělo stránky se sloupcem. Horizontální menu bude navrženo tak, aby se co nejvíc optimálně zobrazilo na koncovém zařízení - v rámci možností. Jiné požadavky na horizontální menu nejsou kladeny. Komponenty pro hlavičku, tělo stránky a sloupec budou přizpůsobovat svůj obsah podle velikosti obrazovky koncového zařízení. Velikost textu v komponentách bude adaptivní, takže uživatel nebude nucen stránku přibližovat. CSS daných komponent budou navrženy tak, aby je bylo snadné upravit na hostitelské aplikace. Cílem této práce je vytvořit JSF komponentu pro inplace editaci. Tato komponenta bude podporovat vstupy z externího systému (tj. systém, do kterého se bude tato komponetna integrovat) a validaci jeho vstupů. Dále bude komponenta umožňovat aktivaci editace kliknutím na ikonku, tato ikonka se objeví u editovaného textu. Komponenta bude přejímat styly z editovaného textu, tzn. text v editačním poli bude maximálně odpovídat textu ve stavu prohlížení. Celou komponentu bude možno lehce přestylovat pomocí CSS

21 2.2. POŽADAVKY 7 Popis Označení podpora atributu autofocus R1 podpora atributu placeholder R2 podpora datových typů 2.2 R3 podpora povinného pole R4 validace podle regulárního výrazu R5 responzivní komponenta pro horizontální menu 2.2 R6 reponzivní komponenta pro blog s bočním sloupcem 2.2 R7 komponenta pro inplace editaci 2.2 R8 Tabulka 2.1: Souhrn všech požadavků Souhrn požadavků V přechozích odstavcích byly definovány požadavky. Tyto požadavky jsou rozděleny do logických celků v tabulce 2.1. Každý požadavek je pokryt případem užití 2.2 definovaným v Apendixu A Případ užití R1 R2 R3 R4 R5 R6 R7 R8 U1 X X X U2 X X X X U3 X U4 X U5 X X X X X Tabulka 2.2: Matice pokrytí požadavků 2.1 případy užití

22 8 KAPITOLA 2. POPIS PROBLÉMU A SPEFICIKACE POŽADAVKŮ

23 Kapitola 3 Rešerše 3.1 Moderní web Obrazovka mobilního zařízení je typicky menší než obrazovka monitoru, pro kterou je webová stránka navržena. Pro konzumaci obsahu je nutné stránku přibližit, aby bylo písmo lépe čitelné. Po přiblížení zase ztrácíme nadhled na stránkou a hůře se na ní orientujeme. Stránku tedy oddálíme a takto pořád dokola. Webové inženýrství tento problém se v zásadě řeší dvěma způsoby: verzí webové stránky pro mobilní zařízení nebo pomocí media queries 1. Mobilní webová stránka je klasická webová stránka přizpůsobená zařízení s malou obrazovkou. Při tvorbě webové stránky pro mobilní zařízení se typicky vytvoří subdoména m.domain.com nebo domain.mobi[8]. Mobilní web je pak dostupný na jedné z doménových variant. Pro mobilní web jsou vytvořeny kaskádové styly, které jsou odlišné od verze pro desktop. Z pohledu front-end vývojáře jsou vytvořeny dva weby zobrazující stejný či podobný obsah. Vývoj webu pomocí media queries (responzivní a adaptivní web) jde zcela jiným směrem. Cílem je vytvořit jeden web pro mobilní i desktop zařízení. Media queries je modul CSS3, který umožňuje podmíněné aplikování kaskádových stylů. Jeho zápis dovoluje omezovat aplikování CSS podle šířky či výšky obrazovky dného zařízení. Výsledkem je jedna webová responzivní stránka, která umí přizpůsobit svůj obsah danému zařízení. Oba přístupy mají své výhody a nevýhody. Nedá se mezi nimi určit vítěz. Jako vodítko, pro zvolení správné techniky, pomůže cíl webu. Pokud je cílem webu poskytnout uživateli co nejlepší uživatelský zážitek 2 a rychlé rozhodování, je lepší vytvořit mobilní verzi webové stránky. V případě, že potřebujeme webovou stránku často aktualizovat či přidávat nové věci, bude responzivní řešení vhodnější. Je to z důvodu jednodušší aktualizace webové stránky. U mobilní verze je totiž nutné aktualizovat i desktop verzi, což může být časově i finančně nákladné. Dalším aspektem jsou i finanční náklady. Vývoj mobilní verze je levnější v porovnání s responzivní webovou stránkou, jejíž tvorba je náročnější. Pokud je záměrem, že mobilní

24 10 KAPITOLA 3. REŠERŠE verze bude lehce odlišná od desktop verze, je mobilní web výhodnějším řešením. V případě optimalizace výkonu webu či SEO 3 je responzivní web lepším řešením. Responzivní design je technika tvorby webových stránek, která má za cíl zprostředkovat obsah s nejoptimálnějším uživatelským zážitkem[18]. V praxi to znamená, že se webová stránka přizpůsobí cílovému zařízení (počítač, mobilní telefon, tablet,... ) a poskytne obsah v optimální podobě. Tato technika může měnit strukturu webu mezi jednotlivými zařízeními, za cílem umožnit konzumentovi co nejpříjemnější práci s webovou stránkou. Vývoj webové stránky pomocí media querires se rozděluje na dva přístupy: responzivní a adaptivní. Oba tyto přístupy staví na moderních technologii CCS3, ovšem liší se v přístupu k vývoji[24]. Adaptivní web se navrhuje pro konkrétní zařízení (konkrétní velikosti obrazovky). Tím se určí, že pro zařízení o rozměrech AxB se web vykreslí jiným způsobem než pro CxD. Responzivní web jde opačným směrem. Webová stránka je navržena tak, aby pomocí fluid grids[12] a media queries zobrazila obsah podle velikosti obrazovky zařízení. Fluid grids (česky plovoucí mřížky) jsou bloky, které tzv. plavou 4 na stránce. Umístění bloku se řídí podle velikosti obrazovky daného zařízení. Princip je lépe patrný z obrázku 3.1. Z obecného principu je responzivní návrh lepší než adaptivní, ale v určitých případech je adaptivní návrh více pragmatický. Adaptivní návrh webu dává větší kontrolu nad výsledným vzhledem. Tento fakt je zjevný, protože se web tvoří pro konkrétní zařízení. Responzivní web má oproti adaptivnímu o stovky více stavů, ve kterých se může nacházet. Vetšina těchto stavů se liší velmi nepatrně, ale díky těmto stavům je obtížné přesně určit výsledný vzhled. To dělá návrh responzivního webu složitějším a hůře testovatelným. Responzivní návrh ovšem přináší výhodu v širokém spektru cílených zařízení. Ano, nelze přesně určit jak bude web vypadat na zařízení o rozměrech AxB, ale lze tvrdit, že web bude uživatelsky přívětivý. Protože je adaptivní web vázaný na určité rozměry, bude responzivní web pravděpodobně lépe přizpůsoben zařízení, než adaptivní, který s danými rozměry nepočítá. Adaptivní rozvržení webu má své přednosti a jedná se o levnější řešení, které se i lépe testuje. Pokud je webová stránka cílena na pár zařízení, bude adaptivní návrh lepší řešení. Adaptivní návrh je také vhodnější pro integraci do již existujícího webu, kdy často není možná kompletní reimplementace[23]. Jak již bylo řečeno media queries je součástí CSS od verze 2. Ve verzi 3 došlo k jejich vylepšení. Toto vylepšení umožňuje podmíněné CSS selektory např. podle minimální velikosti obrazovky. Následující ukázka 3.1 selektoru aplikuje styl pouze na zařízení, které není širší než 900px. screen and (max width: 900px) { 2 / / 3 } Listing 3.1: Příklad media query Díky media queries dostává CSS úplně jiný rozměr. Selektory s omezením na velikost obrazovky dovolují naprosto měnit celé rozhraní webové stránky pouze podle klientské obrazovky. To dává vývojářům do ruky velice silný nástroj

25 3.2. VALIDACE DAT 11 Obrázek 3.1: Ilustrační znázornění responzivního webu, zdroj: [19] Media queries se neomezují pouze na šířku či výšku obrazovky, podporují také orientaci (zda je zařízení otočené vertikálně či horizontálně), poměr stran, barevné spektrum atd. Veškeré podporované vlastnosti jsou na W3C Validace dat HTML5 6 je standardizovaný jazyk pro prezentování strukturovaného obsahu na webu. Jedná se o již 5. verzi připravovanou W3C 7. Standard přináší do HTML spoustu novinek, reaguje tak na požadavky dnešní doby. Tento standard je sice stále ve fázy release candidate 8, ale modelní prohlížeče již několik let postupně implementují novou funkcionalitu. HTML5 přichází s nativní klientskou validací, které není založena na JS. Starší prohlížeče, které neimplementují HTML5, tuto validaci zcela ignorují. Polyfill, nebo polyfiller, je knihovna, poskytující vývojářům technologii, kterou by nativně měl podporovat prohlížeč[20]. S takovou knihovnou lze použít nové vlastnosti a funkce API pohlížeče i v produkčním prostředí aplikace. Knihovna simuluje nebo dodává vývojáři stejné API jako mají prohlížeče, které toto API implementují nativně. Polyfilly se rozmohly v souvislosti s HTML5, kdy část vývojářů chtěla použít nové možnosti, avšak kvůli kompatibilitě se starými prohlížeči to nebylo možné. Polyfill je v podstatě kus JS kódu, který se vloží do webové stránky. Tento kód detekuje, zda prohlížeč podporuje žádanou vlastnost, a pokud ne, nasimuluje danou funkčnost Specifikace je připravena k vydání, ale není ještě oficiálně schválena

26 12 KAPITOLA 3. REŠERŠE Polyfilly pracují tzv. non-obtrusive 9. Cílem polyfillů je také oddělení aplikace a daného prohlížeče. Polyfill zaplní mezeru mezi aplikací a chybějící funkcionalitou prohlížeče. Aplikace by neměla být vázaná na polyfill, jinak by vznikla závislost a jeho budoucí odstranění by bylo problémové. Webshims Lib 10 je modulární polyfill pro funkcionalitu přinášející HTML5. Knihovna je postavená nad jquery a Modernizr 11. Webshims Lib podporuje celou řadu vlastností: validaci, canvas, JSON, geolokaci, EcmaScript5 a další. Jako nevýhodu lze označit závislost na dalších zmíněných knihovnách jquery a Modernizer. H5F 12 je další z řady polyfillů. Knihovna se zaměřuje pouze na HTML5 validaci, to se také odráží na její velikosti 5kB. Velkou výhodou je, že knihovna nemá žádné závislosti. Podle oblíbenosti (427 hvězd 13 ) a forků je autor aktivní a vybudoval si menší komunitu. H5F je dokonce v balíčkovacím systému Bower. Formvalidation.js 14 je také polyfill bez dalších závislostí. U této knihovny je zajímavá možnost, úpravy validačních zpráv pomocí CSS 15. Knihovna podporuje pouze Internet Explorer 8 a vyšší. Html5Forms.js 16 je polyfill, který implementuje pouze podmnožinu z HTML5 validace. Tato knihovna nepodporuje vstupní pole typu nebo url. h5validate 17 je polyfill postavený na jquery, který podporuje HTML validaci od Internet Exploreru verze 6. Knihovna umožňuje rozšířit sadu validačních regulárních vzorů o vlastní. h5validate podporuje všechny funkce HTML5 validace Shrnutí Všechny výše uvedené knihovny jsou si velice podobné. Knihovna Html5Forms.js pro svoje nedostatky (nedostatečná podpora vlastností HTML5 validace) není dále zajímavá. Knihovny Webshims Lib a Html5Forms.js mají zavislosti na dalších knihovnách. Souhrn vlastností knihoven je v tabulce 3.1. Pro tuto práci byla vybrána knihovna H5F nejen kvůli aktivitě autora, ale i díky tomu, že je v balíčkovacím systému Bower. Knihovna má automatické testy a dokonce používá server pro kontinuální integraci oddělení JS kódu od HTML stránky

27 3.3. INPLACE EDITACE 13 Název Závislosti podpora HTML5 validace Webshims Lib jquery a Moernizr plná H5F ne plná Formvalidation.js ne plná Html5Forms.js jquery částečná h5validate jquery částečná Tabulka 3.1: Matice porovnání polyfillů pro HTML5 validaci 3.3 Inplace editace jquery In Place Editor 19 je malá knihovna pro inplace editaci postavená nad jquery. Poslední změna v tomto projektu byla a podle issue trackeru 20 se zdá, že autor není nijak aktivní. Knihovna má velmi omezenou konfiguraci, např. podporuje pouze tyto HTML vstupy: text, textarea nebo select. Dále se nedá integrovat s již existující validací, protože má svojí vlastní validaci vstupů. Toto omezení je velice nepříjemné. Editaci vstupního pole se spouští kliknutím na daný text, což může být pro uživatele matoucí. Tato vlastnost je opět pevně vestavěna a nedá se nakonfigurovat. Zásadní problémem je způsob, jakým knihovna pracuje se serverem. Při uložení se obsah vstupního pole odešle na konkrétní URL nebo předá funkci (callback). Tento způsob konfigurace nemůže být aplikovatelný, pokud nevíme na jakou URL se daný vstup odešle. Např. JSF se o URL pro zpracování formuláře stará samo, takže integrace by byla velice obtížná, pravděpodobně i nereálná. Z předchozích odstavců jasně vyplývá, že jquery In Place Editor není vhodná knihovna pro tuto práci. Jeditable 21 je další knihovna pro inplace editaci postavená nad jquery. Podobně jako jquery In Place Editor i Jeditable obsahuje podporu HTML vstupů: text, textarea a select. Jeditable umožňuje změnit popisy tlačítek pro uložení či stornování editaci, ale editace se opět spouští kliknutím na daný text (kde uživatel ani nemusí poznat, že je text editovatelný). Jako v předchozím případě odesílá knihovna data na konkrétní url nebo je předá funkci. X-editable 22 je pokročilá knihovna umožňující inplace editaci. Knihovna podporuje dva módy, inplace editaci nebo editaci v popup okně. Vzhled editace lze nastavit pomocí Bootstrap 23, jquery UI 24 nebo jquery 25. Ve srovnání s předchozími knihovnami podporuje X-editable mnohem více vstupů: text, textarea, select, date, dateui, combodate atd. Editaci lze aktivovat kliknutím na daný text nebo kliknutím na příslušnou ikonu s tužkou. V integraci s Bootstrap lze text editovat i pomocí WYSIWYG 26 editoru. X-editable umožňuje

28 14 KAPITOLA 3. REŠERŠE jquery IPE 29 Jeditable X-editable InlineEdit 3 Aktivace kliknutím na text text text nebo ikonu text Vlastní vstupy ne ne ano ne Validace ne vlastní ne vlastní Přebírání stylů ne ne ne ano Odeslání na url nebo callback url nebo callback url nebo callback url Tabulka 3.2: Matice porovnání knihoven pro inplace editaci tvorbu vlastních vstupů, viz Address 27. InlineEdit 3 28 je minimalistická knihovna pro inplace editaci. Knihovna má velice omezené nastavení v porovnání s předchozími knihovnami. Editace se aktivuje kliknutím na editovaný text, tato vlastnost nelze ovlivnit konfigurací. Za velkou výhodu lze označit přebírání stylů editovaného textu Shrnutí Všechny výše uvedené knihovny jsou si velice podobné. Umožňují spuštění editace kliknutím na text, nebo na ikonu tužky, přebírají styly editovaného textu apod. Jejich nevýhodou je nutná konfigurace pro každý editovaný text. Typy vstupů jsou napevno vestavěné, takže jejich přizpůsobení a integrace s již existujísím systémem je velice obtížná. Protože knihovny používají vlastní vstupy k editaci, integrovat validační pravidla znamená, zduplikovat již existující validaci ze systému. Tento fakt vede k chybám nejen při vývoji, ale hlavně při údržbě systému. Souhrn vlastností knihoven je v tabulce 3.2. Z tabulky vyplývá, že žádná z uvedených knihoven není vhodná pro tuto práci. Všechny uvedené knihovny používají vlastní vstupy, které lze často jen obtížně přizpůsobit. Díky tomuto faktu nelze knihovny integrovat s již existujícím systémem a jeho validačními pravidly. Integrace je možná pouze duplikací validačních pravidel z existujícího systému do knihovny, což s sebou nese řadu rizik, jako třeba náchylnost na chyby a údržbu. 3.4 JSF frameworky JSF 30 je specifikace pro tvorbu webových stránek na platformě Java a je součástí Java Platform, Enterprise Edition. JSF je komponentově orientovaný webový framework určený pro tvorbu uživatelského rozhraní postavený na Java EE platformě. JSF implementuje návrhový vzor MVC[14]. Schéma MVC pro JSF je vidět na obrázku 3.2. HTTP požadavek je zachycen Faces Servletem a delegován na danou JSF stránku (Facelet šablonu). Facelet šablona získá data z modelu pomocí Expression language[11] a výstup se odešle pomocí HTTP odpovědi zpět. JSF je stavový framework a jeho životní cyklus se skládá z šesti fází, které jsou znázorněny na obrázku

29 3.4. JSF FRAMEWORKY 15 JSF 2.0 poskytuje jako šablonovací systém Facelets, serverovou validaci pomocí Beans validation[11], podporu AJAXu a základní navigaci. Ve verzi 2.0 přišlo JSF, kromě výkonnostních vylepšení, s podporou Java EE Obrázek 3.2: JSF implementace MVC[5] Obrázek 3.3: JSF životní cyklus[4] Současná verze JSF 2.1 neposkytuje klientskou validaci. A to ani pomocí HTML5 či JS. Vývojář tedy musí psát klientskou validaci ručně. To znamená, zduplikovat validační pravidla z modelu do JS. Takový způsob vývoje aplikací má řadu nevýhod. Protože jsou validační pravidla na několika místech, je tento způsob náchylný na chyby a údržbu. JSF framework poskytuje Bean validation 32. Tento standard integruje validaci serverové části a persistentní vrstvy (pomocí anotací 33 ). Tímto se redukuje duplicita dat, validační

30 16 KAPITOLA 3. REŠERŠE pravidla jsou zapsána pouze v modelu, avšak JSF neposkytuje klientskou validaci. Tuto validaci lze vytvořit ručně, ale tento přístup duplikuje validační pravidla a tím je náchylný na chyby. Další možností je využití AJAXu. V JSF 2.0 je AJAX plně podporován a uživatelský vstup je na klientské straně validován proti serveru. S každou validací se na server posílá požadavek, i když se validační pravidlo vůbec nezměnilo (např. formát ové adresy je stále stejný). Tímto způsobem se zbytečně zahltí server požadavky, protože je klientská strana nemůže nijak validovat. Framework RichFaces 34 v poslední verzi 35 obsahuje podporu vlastnosti placeholder, ale HTML5 validace není podporována. Klientská validace je v RichFaces implementována pomocí JavaScriptu i AJAXu tzv. validovaná hodnota se odešle z klienta na server a ten odpoví, zda je hodnota validní. Tím RichFaces splňují standardní JSF validaci i Bean validaci 36. Od RichFaces existuje ještě fork 37 RichFaces Bootstrap 38. Autoři sice tvrdí, že tento fork podporuje HTML5, ale HTML5 validace zde opět není podporována. RichFaces obsahují komponentu pro inplace editaci 39. Na tuto komponentu lze sice aplikovat validační pravidla pro klientskou validaci, ale protože zde není podpora HTML5 nesplňuje komponenta požadavky této práce. Framework PrimeFaces 40 v poslední verzi 41 také podporuje vlasnost placeholder, ale HTML5 validace opět není podporována. Klientské validace lze dosáhnout pouze pomocí AJAXu. Narozdíl od RichFaces zde není JavaScriptová validace. PrimeFaces obsahují komponentu pro inplace editaci 42, ale protože PrimeFaces nepodporují HTML5 validaci, nesplňuje komponenta požadavky této práce. Framework OmniFaces 43 ve své poslední verzi 44 podporuje celou řadu funkcionality z HTML5 45. Omnifaces částečně podporují i HTML5 validaci, např. lze validovat vstupní pole jako , URL apod., zde chybí ovšem zásadní vlastnost a to required - povinné pole. OmniFaces neobsahují komponentu pro inplace editaci. Framework OpenFaces 46 v poslední verzi 47 podporují klientskou validaci pomocí JavaScriptu i AJAXu, ale HTML5 nepodporují. Openfaces neobsahují ani koponentu pro inplace editaci. Framework ADF 48 v poslední verzi 49 obsahuje podporu klientské validace pomocí JavaScriptu i AJAXu. ADF neobsahují komponentu, která by podporovala inplace editaci verze byla vydána jedná se o odnož původního projektu verze verze verze 3.0,

31 3.4. JSF FRAMEWORKY 17 Framework ICEFaces 50 v poslední verzi 51 podporují klientskou validaci pomocí JavaScriptu i AJAXu. Podpora HTML5 zde není žádná. ICEFaces neobsahují ani komponentu pro inplace editaci. Framework MyFaces 52 ve své poslední verzi 53 obsahují HTML5 validaci. Tato podpora je zajištěna pomocí vlastních komponent 54. Příklad 3.2 použití takové komponenty vypadá třeba takto: 1 <hx:inputtext id="textit" value="#{inputtextbean.someparam}"> 2 <f:validateregex pattern="[0 9][A Z]{3}" /> 3 </hx:inputtext> Listing 3.2: Příklad použití komponenty MyFaces InputText Tato komponenta se přeloží do HTML 3.3 přibližně takto: 1 <input id="textit" name="textit" type="text" pattern="[0 9][A Z]{3}" /> Listing 3.3: Výsledek transformace komponenty MyFaces InputText Toto řešení je dobré, ale přináší s sebou jistou nevýhodu. Pokud již máme existující aplikaci, řádově s desítky či stovkami použitých komponent typu inputtext, musíme je všechny nahradit za komponentu inputtext z MyFaces. Tento proces může být časově náročný a hlavně náchylný na chyby. Je potřeba otestovat aplikaci všude, kde se tato komponenta vyskytuje. Což může být i velice nákladné. Z tohoto důvodu není toto řešení dostatečné pro tuto práci. MyFaces neobsahují komponentu pro inplace editaci Shrnutí Z přechozích odstavců jasně plyne, že na trhu není dostupný JSF framework, který by podporoval HTML5 validaci (i s vlastností required), komponentu pro inplace editaci. RichFaces obsahují komponentu pro inplace editaci a klientskou validaci, ale nepodporují HTML5 validaci. Tabulka 3.3 shrnuje porovnání jednotlivých frameworků. Ani jeden z výše uvedených frameworků nesplňuje požadavky této práce

32 18 KAPITOLA 3. REŠERŠE Framework HTML5 validace JS validace AJAX validace Inplace editor Richfaces ne ano ano ano Primefaces ne ne ano ano Omnifaces ne ne ano ne Openfaces ne ano ano ne ADF ne ne ne ne ICEFaces ne ne ne ne MyFaces ano ne ne ne Tabulka 3.3: Matice porovnání jednotlivých JSF frameworků

33 Kapitola 4 Analýza a návrh řešení 4.1 Responzivní design Komponenty pro responzivní uživatelské rozhraní by měly být navrženy tak, aby od vývojáře vyžadovaly minimální úsilí pro integraci do hostitelské aplikace. Protože je cílem této práce vytvořit komponenty pro horizontální menu a tělo stránky (např. pro blog), bude výhodné tyto komponenty rozdělit a vytvořit je vzájemně nezávislé. Tento přístup umožní vývojáři maximální volnost. Z tohoto důvodu budou vytvořeny následující komponenty: Article - komponenta pro obsah článku Content - obalovací komponenta pro tělo článku a sloupec Header - obaluje hlavičku stránky HorizontalMenu - reprezentuje horizontální menu MenuItem - položka menu Sidebar - sloupec na pravé straně Protože by komponenty měly vývojáře odstínit od nutnosti stylování, budou navrženy tak, aby jejich integrace byla pouze na úrovni vložení komponent do XHTML šablon. Následující příklad 4.1 zobrazuje možnost použití komponent. 1 <!DOCTYPE html> 2 <html xmlns=" 3 xmlns:h=" 4 xmlns:tnt=" 5 <h:body> 6 <tnt:header> Header content </tnt:header> 7 <tnt:horizontalmenu> 8 <tnt:menuitem> Home </tnt:menuitem> 9 <tnt:menuitem> Contact </tnt:menuitem> 10 </tnt:horizontalmenu> 11 <tnt:content> 12 < tnt:article > Article content </ tnt:article > 13 <tnt:sidebar> Sidebar content </tnt:sidebar> 19

34 20 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 14 </tnt:content> 15 </h:body> 16 </html> Listing 4.1: Příklad použití responsivních komponent Tento kód představuje klasickou webovou stránku s horizontálním menu a bočním sloupcem. Komponenty mají v podstatě pouze sémantický význam. Slouží k obalení obsahu, který je poté zabalen do HTML5 značek. Komponenty budou mít přednastavené chování podle velikosti obrazovky koncového zařízení. Tím se vývojář nemusí starat o CSS. Komponenty budou upravovat velikost svého obsahu, písma a také obtékání, pro přizpůsobení koncovému zařízení. Jednotlivé komponenty budou vykresleny do HTML5 značek, přehled v tabulce 4.1. Responzivní chování komponent je schématicky naznačeno na obrázku 4.1. Vlastnosti font-size, padding a margin se budou proporciálně změnšovat podle velikosti cílového zařízení. To umožní zobrazit obsah webu optimálně bez nutnosti přiblížení. Ze schématu je patrné proporcionální zmenšení prvků webu podle koncového zařízení. Na prvních dvou zařízení (zleva) se pozice prvků nemění, na druhém zařízení se pouze upraví velikost písma a zmenší okolí a velikost prvků. Na třetím zařízení je už patrná změna uspořádání prvků. Horizontální menu se změnilo ve výběrové menu (select box) a boční sloupec se zobrazí až pod vlastním obsahem (tělem). Přesunutím bočního sloupce vznikne prostor pro tělo obsahu a bude tak možné přizpůsobit písmo velikosti obrazovky. Komponenta HorizontalMenu bude mít dva způsoby responzivního zobrazení na zařízeních, jejichž šířka obrazovky je menší než 30em. První způsob zobrazení komponenty bude vykreslením položek menu pod sebe (na širší obrazovce se položky menu vykreslí vedle sebe). Druhý způsob zobrazení bude pomocí HTML elementu Select. Tento způsob zmenší velikost menu na minimum a tak dá prostor pro zobrazení obsahu webu. Vybráním položky v selectboxu bude uživatel přesměrován na danou stránku. Výběr způsobu zobrazení bude konfigurovatelný pomocí atributu komponenty. TNT komponenta HTML5 Popis značky Article article Sémantická značka reprezentující obsah sekce - příklad Content div Obalující značka - příklad Header header Sémantická značka pro úvod nebo navigaci - příklad HorizontalMenu nav Sémantická značka pro navigaci - příklad MenuItem li Značka pro položku v seznamu - příklad Sidebar aside Značka pro vedlejší obsah, boční sloupce apod. - příklad Tabulka 4.1: Přehled responzivních TNT komponent Aplikace CSS Komponenty budou zavislé na CSS, proto je nutné tyto CSS aplikovat v hostitelské aplikaci. Nejjednodušší způsob je CSS umístit na web a vývojář si je přidá do CSS souboru dané aplikace. Tento přístup má výhodu v tom, že se nezvýší počet HTTP požadavků kvůli načtení dalšího CSS souboru. Menší nevýhoda je v pohodlnosti integrace, nestačí pouze vložit komponentu do XHTML šablony.

35 4.1. RESPONZIVNÍ DESIGN 21 Obrázek 4.1: Schématické znázornění responsivních TNT komponent Druhá možnost je automaticky vložit do HTML značky Head odkaz na CSS soubor TNT. Vložení by mělo proběhnout automaticky při prvním použití komponenty. Pokud se žádná komponenta nepoužije, je zbytečné vkládat odkaz na CSS soubor. Výhoda tohoto přístupu spočívá v jednoduchosti integrace, stačí pouze vložit komponentu do XHTML šablony. Nevýhoda je další HTTP požadavek na CSS soubor. Cílem je všechny CSS umístit do jednoho souboru a na ten odkazovat v HTML. Takto může prohlížeč daný soubor cachovat a zrychlit tím načítání webu. Protože oba přístupy mají své výhody a nevýhody, bude vývojaři umožněno vybrat si, co mu lépe vyhovuje. Výběr přístupu bude pomocí konfugurace web.xml, parametrem TNT.AUTO_LOAD. Příklad konfigurace je v ukázce <context param> 2 <param name>tnt.auto_load</param name> 3 <param value>false</param value> 4 </context param> Listing 4.2: Vypnutí automatického načítání závislostí TNT komponent Výše uvedenou konfigurací se deaktivuje automatické načítání závislostí CSS. Pro aktivaci stačí vložit hodnotu true. Pokud není parametr uveden v konfiguraci, jsou závislosti načítány automaticky. Pro správnou aplikaci responzivních komponent je nutné přidat do webové stránky element Meta viewport 1. Tento element umožní správné zobrazení stránky na mobilním zařízení. Vložení tohoto elementu do HTML stránky bude opět podléhat výše uvedené konfiguraci. 1

36 22 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.2 Klientská validace Naším cílem je navrhnout knihovnu pro klientskou validaci. Tato knihovna by měla minimalizovat náklady na vývoj a údržbu uživatelského rozhraní. Validační pravidla je nutné někde zaznamenat. Mohli bychom vytvořit komponenty, ze který by se transformací vytvořilo HTML s validací. Komponentám je nutné předat dané validační informace. Tyto pravidla bychom mohli deklarovat v prezentační vrstvě. Při představě, že nad entitou může existovat více pohledů (formulářů) by to znamenalo duplikaci kódu. Tato duplikace by sebou přinesla problémy nejenom při vývoji, ale i údržbě kódu. Přesuneme-li se o vrstvu níže, mohli bychom tyto validační pravidla zachytit v business vrstvě. Zachycením validačních pravidel u dané entity odstraníme duplikování v prezentační vrstvě. Pravidla se budou propagovat z entity do komponenty. Při změně typu atributu entity stačí upravit validační pravidlo pouze v entitě a daná informace se zpropaguje do prezentační vrstvy. Tento přístup využívají např. některé frameworky pro práci s databází, kdy jsou informace o typu atributu uloženy přímo v entitě. Navrhovaná knihovna využije aspektů entity, které mohou být nezávislé na technologii, knihovně či jazyku. Uvažujme dvě možnosti realizace HTML5 validace, pomocí nových komponent nebo injektováním generování klientské validace do již existujících komponent. V následujících odstavcích probereme oba přístupy a ukážeme si jejich výhody a nevýhody Nová komponenta Protože je JSF komponentový framework nabízí se možnost realizovat nové komponenty pro uživatelský vstup. Tyto komponenty by generovaly HTML5 výstup s danou validací. Použití takové komponenty by mohlo vypadat nějak takto <tnt:inputtext value="#{user.name}" 2 required="true" clientrequired="true"/> Listing 4.3: Příklad triviálního použití komponenty InputText Výše uvedená ukázka komponenty by vykreslila na webové stránce vstupní textové pole, které je povinné. Komponenta obsahuje atribut required, které vyžaduje pole vyplnit na úrovni serverové validace. Atribut clientrequired, které vyžaduje vypnit pole na klientské straně. V této ukázce je zjevná duplicita validačních pravidel z pohledu vývojáře. Pokud vývojář chce, aby pole bylo povinné, musí danou informaci vyplnit ve dvou atributech, což může být náchylné na chyby. Tento přístup lze vylepšit. Uvažujme tedy, tuto komponentu na ukázce <tnt:inputtext value="#{user.name}" required="true"/> Listing 4.4: Příklad použití komponenty InputText bez duplikace Jedná se o stejnou komponentu jako v předchozím příkladu. Tentokrát zmizel atribut clientrequired. Klientská i serverová validace je generována z atributu required. Protože sloučení těchto pravidel davá větší smysl.

37 4.2. KLIENTSKÁ VALIDACE 23 Takovou komponentu pro textový vstup bychom mohli implementovat a tím by splnila svůj účel. Aby se komponenta chovala jako standardní komponenty pro vstup z JSF 2 museli bychom přidat podporu pro validační zprávy atd. Implementace takové komponenty by byla duplikace již existující (a hlavně otestované) komponenty s přidáním funkcionality. Její použití by se pak nelišilo od standardní komponenty pro textový vstup, porovnejme použití standardní komponenty InputText a TNT InputText <tnt:inputtext value="#{user.name}" required="true"/> 2 3 vs. 4 5 <h:inputtext value="#{user.name}" required="true"/> Listing 4.5: Porovnání použítí standardní komponenty InputText a TNT InputText Z pohledu vývojáře se použití nové komponenty takřka neliší od standardní komponenty inputtext. Přidat klientskou validaci pro nové formuláře bude triviální. V případě integrace a přidání validace pro již existující formuláře nebude situace tak jednoduchá. Bude nutné refaktorovat původní kód a změnit namespace komponenty z h na tnt. Tento zásah do systému může být velice náročný na proveditelnost i na otestování. Případě ručního refaktorování ja náchylnost na chyby velmi vysoká. Pokud se rozhodneme o strojové refaktorování, je nutné zkontrolovat výsledných kód. Výše jsme si ukázali komponentu pro textový vstup. Uvažujme, že budeme chtít HTML5 validaci i u jiných vstupů, jako jsou: datum, číslo, výběrový atribut atd. Budeme nuceni implementovat další komponentu pro daný vstup. Tímto přístupem se dostaneme k tomu, že budeme implementovat znovu všechny komponenty ze standardní sady JSF s HTML5 validací. Zde je patrné, že tento přístup není zcela optimální. Pojďme si shrnout výhody a nevýhody. Výhody: zcela nová komponenta nezávislá na již existujícím řešení snadná integrace prakticky stejné použití jako u standardních komponent Nevýhody: reimplementace již existujích funkcionalit chybovost při implementaci velký počet komponent pro různé vstupy obtížná integrace do již existujícího systému a formulářů Rozšíření RenderKit V JSF se komponenty typicky skládají ze dvou hlavních částí: třídy komponenty (potomek UIComponent 3 reprezentující chování) a renderer (stará se o výstup komponenty do HTML)

38 24 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ V Renderer 4 fázi JSF[11] se na každém rendereru komponenty volá množina encode* metod, v tomto pořadí: encodebegin - vykreslí začátek (otevírací HTML tag) komponenty encodechildren - vykreslí potomky komponenty encodeend - vykreslí konec (ukončovací HTML tag) komponenty Renderer používá k HTML výstupu ResponseWriter 5. ResponseWriter je nadstavba nad klasickým java.io.writer (output buffer). Jeho API poskytuje metody pro snadné vytvoření XML dokumentu. Často používané metody: startelement writeattribute writetext endelement Tyto metody se automaticky starají escapování pro XML, XHTML či HTML. Protože každá metoda používá pro vykreslování implementaci ResponseWriter nabízí se možnost, aplikovat HTML5 validaci prostřednictvím vlastního ResponseWriter. Instanci ResponseWriter vytváří RenderKit 6. Instance RenderKit je vytvářena třídou RenderKitFactory 7, která poskytuje a přidává nové RenderKit instance. Vlastní implementaci RenderKitFactory je nutno zaregistrovat v konfiguračním souboru JSF faces-config.xml[11], příklad konfigurace <faces config version="2.0"> 2 <name>tnt</name> 3 <factory> 4 <render kit factory> 5 com.codingcrayons.tnt.kit. Html5RenderKitFactory 6 </render kit factory> 7 </factory> 8 </faces config> Listing 4.6: Registrace RenderKitFactory ve faces-config.xml Ukázka registrace vlastní RenderKit třídy <faces config version="2.0"> 2 <name>tnt</name> 3 <application> 4 <default render kit id> 5 Html5RenderKit 6 </default render kit id>

39 4.2. KLIENTSKÁ VALIDACE 25 7 </application> 8 <render kit> 9 <render kit id>html5renderkit</render kit id> 10 <render kit class> 11 com.codingcrayons.tnt.kit. Html5RenderKit 12 </render kit class> 13 </render kit> 14 </faces config> Listing 4.7: Registrace RenderKit ve faces-config.xml Následná implementace vlastního ResponseWriter, by přetížila metodu startelement a spolu se standardním výstupem by do bufferu vypsala i atributy pro HTML5 validaci. Injekci generování validace lépe popisuje zjednodušený sekvenční diagram 4.2. Diagram začíná ve fázi vykreslení komponent. ViewHandler si vyžádá vykreslení komponenty UI- ViewRoot, která zastřešuje všechny ostatní komponenty. Tato komponenta postupně deleguje vykreslení na všechny své potomky (UIComponent). Voláním metody encodeall je komponentě poskytnuta instance FacesContext, která poskytuje ResponseWriter (v našem případě intance Html5ResponseWriter). Komponenta používá util metody (startelement,... ) a právě v tomto bodě dochází ke generování validace metodou writehtml5attributes. ResponseWriter je společný pro všechny komponenty, proto lze aplikovat generování klientské validace pro každou vstupní komponentu. Obrázek 4.2: Sekvenční diagram vykreslovací fáze JSF s generováním klientské validace Toto řešení sebou přináší velkou výhodu v tom, že není potřeba reimplementovat již existující komponenty. Vytvořením vlastní implementace ResponseWriter rozšíříme vlastnosti existujících komponent. Integrace takového rozšíření do existujícího systému je jednoduchá. Shrňme si výhody a nevýhody tohoto řešení:

40 26 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Výhody: rozšíření stávajícího řešení snadná integrace z pohledu použití komponent se nic nemění není nuto reimplementovat sadu komponent rozšíření lze snadno odebrat ze systému validace se projeví u všech komponent Nevýhody: vývojář může chtít pouze serverovou validaci bez klientské (málo pravděpodobné) Porovnání přístupů Porovnáním obou uvedených přístupů docházíme k závěru, že výhodnější je řešení pomocí RenderKit. Integrace tohoto řešení je pro vývojáře triviální. Stačí přidat knihovnu TNT faces ve formátu JAR 8 do projektu a knihovna se sama postará o načtení vlastního RenderKit. Pro značné výhody se v této práci dále bude implementovat druhé řešení, které zasáhne jen minimálně do hostitelské aplikace a funguje s již existujícími komponentami. Protože podpora HTML5 validace v něchterých současných prohlížečích stále není implementována[2], bude pro klientskou validaci použit polyfill H5F viz kapitola Inplace editor Naším cílem je vytvořit komponentu, která umožní editovat text na stránce. Text by měl být editovatelný přímo v místě umístění, bez nutnosti přechodu na jinou stránku či zobrazením dialogového okna. Při návrhu inplace editoru je nutné soustředit se na následující body: zobrazení a skrytí editoru zobrazení a skrytí editovaného textu interakce s uživatelem během odesílání dat na server připojení ikony reprezentující editovatelný text editovaný text by měl maximálně odpovídat zobrazovanému textu (formátování atd.) Realizovat inplace editor lze dvěma způsoby, přípojením komponenty k danému textu a vyvořením pole pro editaci na straně klienta, nebo vytvořením pole pro editaci na serverové straně. V následujících sekcích si probereme oba přístupy a ukážeme jejich výhody a nevýhody. 8

41 4.3. INPLACE EDITOR Vytvoření editačního pole na straně klienta První možnost, která se nabízí, je vygenerovat vygenerovat na straně klienta vstupní pole pro editaci. Toto pole bude ve výchozím stavu skryté a zobrazí se buď po kliknutí na editovatelný text nebo kliknutím na editační ikonu. Tímto přístupem nemusí být šablona XHTML na straně serveru vůbec ovlivněna. Stačí text, který chceme editovat, označit například CSS třídou a kód na klientské straně se už o vše postará. Představme si jednoduchý textový element v ukázce <span class="editable">text</span> Listing 4.8: Triviální editační textový element A triviální JS kód, funkce editable vytvoří skryté pole pro editaci a tlačítka pro odeslaní a stornování editace var editabletext = document.getelementsbyclassname( editable ); 2 editable(editabletext); Listing 4.9: Ukázka aplikace ovládací funkce inplace editoru Tato ukázka použití je triviální. Budeme potřebovat výslednou hodnotu editace odeslat na server, takže se časem dostaneme ke konfiguraci. Pro začátek můžeme předat argumenty přímo funkci editable var editabletext = document.getelementsbyclassname( editable ); 2 editable(editabletext, { 3 url : / edit, 4 name: name 5 }); Listing 4.10: Konfigurace inplace editoru pomocí parametrů Podle výše uvedené ukázky bychom mohli danou komponentu realizovat. Při použití bychom ale narazili na to, že pro každý editovaný text, musíme zavolat funkci editable a předat jí konfiguraci. Pojďme tedy přesunout konfiguraci přímo k editovanému textu a funkce editable si je výtáhne přímo z elementu <span class="editable" data url="/edit" data name="name">text</span> Listing 4.11: Konfigurace inplace editace pomocí data atributů Zde jsme využili data atributů z HTML5. Tato varianta je už lepší, protože stačí vložit volání funkce editable do stránky pouze jednou. Náš editovaný text nemusí být vždy jen text, můžeme chtít editovat např. datum. Budeme tedy muset upravit komponentu tímto způsobem <span class="editable" data url="/edit" 2 data name="created" data type="date"> </span> Listing 4.12: Inplace editor pro datum Když půjdeme dál, datum má spoustu formátů, které se liší především podle regionu použití. Budeme tedy chtít jinou variantu pro prohlížení a jinou jako hodnotu pro uložení. Upravme tedy element podle ukázky 4.13.

42 28 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 1 <span class="editable" data url="/edit" data name="created" 2 data type="date" data value=" "> </span> Listing 4.13: Inplace editor jiný formát data pro uložení hodnoty a výpis Danou hodnotu můžeme také chtít validovat. Hodnotu samozřejmě můžeme odeslat na server a tam jí zvalidovat. Ale my chceme dát uživateli okamžitou odpověď a nazatěžovat síť zbytečnými dotazy. Budeme chtít validovat přímo na klientské straně. Datum musí být mezi rokem 2010 a 2014, upravme použití <span class="editable" data url="/edit" data name="created" 2 data type="date" data value=" " 3 data min=" " 4 data max=" "> </span> Listing 4.14: Inplace editor datum, omezení rozsahu Uvažujme místo datu text, který je na serverové straně formátován následovně: první písmeno je zapsáno kapitálkou počet znaků je omezen na 10, pokud je text delší, je zkrácen na 10 znaků a ukončen výpustkou Při editaci takového textu budeme chtít při editaci plný text, bez omezení na velikost a formátování. Upravme tedy náš kód: 1 <span class="editable" data url="/edit" data name="name" 2 data type="text" data value="lorem ipsum" 3 >Lorem ipsu...</span> Listing 4.15: Inplace editor textu, rozdílné formátování pro výpis a editaci Po editaci textu potřebujeme text opět naformátovat podle pravidel, formátujme tedy na straně klienta <span class="editable" data url="/edit" data name="name" 2 data type="text" data value="lorem ipsum" 3 data format="firstletter" 4 data ellipsis="10" 5 >Lorem ipsu...</span> Listing 4.16: Inplace editor textu, formátování pomocí konfigurace Komponenta se začíná komplikovat a zde dochází pomalu k duplicitě validačních a formátovacích pravidel. Formátovací funkce musí být implementovány na serverové i na klientské straně. Zde je patrná nevýhoda údržby konzistence obou funkcí. Dále v případě generovaného UI budeme muset implementovat komponenty pro editaci na serverové i na klientské straně. Tímto přístupem se vydaly všechny knihovny v sekci 3.3 a komponenty v sekci 3.4. Ukažme si tedy výhody a nevýhody tohoto přístupu. Výhody:

43 4.3. INPLACE EDITOR 29 konfigurace přímo u editovaného textu jednoduché použití Nevýhody: duplikace kódu ze serveru do klienta nemožnost ovlivnit a upravit výslednou editaci Generování formuláře na straně serveru Předchozí sekce odhalila některé nedostatky přístupu generování editace na straně klienta. Pojďme to zkusit z druhé strany a generovat editaci na straně serveru. Uvažujme tedy opět triviální ukázku kódu <div> 2 <span>lorem ipsu...</span> 3 <input type="text" value="lorem ipsum"> 4 </div> Listing 4.17: Vygenerované HTML z komponenty První patrný rozdíl je ten, že editační pole je vygenerované na serveru. Tento přístup redukuje duplikování validačních pravidel, protože z pohledu serveru bylo vygenerováno editační pole jako pro běžný formulář. Pro uživatelskou přívětivost můžeme chtít během editace zobrazit třeba nápovědu ve formě otazníku. A protože bude potřeba naformátovat odeslanou hodnotu vstupu, aktualizujeme text pro zobrazení AJAXem. Ukázka vygenerovaného HTML <div> 2 <div class="view content"> 3 <span>lorem ipsu</span> 4 </div> 5 <div class="edit content"> 6 <input type="text" value="lorem ipsum"> 7 <span class="help">?</span> 8 </div> 9 </div> Listing 4.18: Vygenerované HTML pro inplace editor, rozdělení na dvě sekce Hlavní změnou je rozdělení kódu na dvě části: view-content - zobrazovací část edit-content - editační část Odeslaná hodnota je na serveru zpracována a odeslána zpět klientovi již zformátovaná. Tím jsme zcela zamezili duplikaci formátování textu na klientské straně. Jako v předchozí sekci budeme chtít hodnotu odeslat na server. Uvažujme rozdíl mezi formulářovou a inplace

44 30 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ editací pouze ten, že v inplace editaci přibyl element pro zobrazení textu. Vstupní pole ve formulářové editaci nemají informaci o tom, na jakou URL se budou odesílat. Pojďme zkusit tento přístup aplikovat stejně tak pro inplace editaci. Porovnání inplace editace 4.20 a formulářové editace 4.19: 1 <form> Formulářová: 2 <input type="text" value="lorem ipsum"> 3 <span class="help">?</span> 4 </form> Inplace: 1 <form> 2 <div> Listing 4.19: Klasická formulářová editace 3 <div class="view content"> 4 <span>lorem ipsu...</span> 5 </div> 6 <div class="edit content"> 7 <input type="text" value="lorem ipsum"> 8 <span class="help">?</span> 9 </div> 10 </div> 11 </form> Listing 4.20: Inplace editace Obě ukázky se moc neliší. Odeslání hodnoty vstupního pole je teď v režii formuláře, jako je tomu u klasického formuláře. Záměrně zde chybí tlačítko na odeslání formuláře. Shrňme si tedy výhody a nevýhody tohoto řešení: Výhody: z pohledu serveru a životního cyklu aplikace, stejné jako klasický formulář odstraněna duplikace kódu (validační a formátovací pravidla) kontrola UI pro editaci Nevýhody: nutné generování vstupního pole na serveru (což může být pro některé aplikace nevhodné řešení) Návrh inplace komponenty Na základě předchozích sekcí bude realizována komponenta pro inplace editaci podle druhého řešení tj. generováním vstupního pole na straně serveru. Z logiky se bude komponenta dělit na dvě části:

45 4.4. POUŽITÉ TECHNOLOGIE 31 serverová část - použití komponenty v XHTML šabloně klientská část - zobrazení a skrytí editoru atd. Serverová část bude realizována jako standardní JSF komponenta. Příklad použití v XHTML šabloně <h:form> 2 <h3> 3 <tnt:inplace id="name" type="text" required="true" 4 value="#{usercontroller}" 5 printvalue="#{usercontroller.formattedname}"/> 6 </h3> 7 </h:form> Listing 4.21: Příklad použití komponenty pro inplace editaci Klientská část bude realizována pomocí JavaScriptu, který bude do stránky vložen automaticky jako jiné závislosti v sekci Použité technologie AspectFaces AspectFaces 9 je knihovna, která generuje uživatelské rozhraní z datového modelu. Ke generování využívá inspekci zdrojového kódu (anotace). Protože je uživatelské rozhraní generováno, jsou validační pravidla na jednom místě (v datovém modelu). Proto bude snaha využít inspekce zdrojového kódu a generovat klientskou validaci. Příklad 4.22 anotované třídy pro AspectFaces. 1 class User { 2 3 private String name; 4 6 public String getname() { 7 return name; 8 } 9 10 public void setname(string name) { 11 this.name = name; 12 } 13 } Listing 4.22: Anotovaná třída pro AspectFaces Anotace NotNull deklaruje pole jako povinné. AspectFaces k přiřazení datového typu a šablony používá mapování v konfiguraci JFormBuilder byl přejmenován na AspectFaces,

46 32 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 1 <configuration> 2 <mapping> 3 <type>string</type> 4 <default tag="inputtext.xhtml" 5 maxlength="255" size="30" required="false"/> 6 </mapping> 7 </configuration> Listing 4.23: Mapování třídy String pro AspectFaces Tato konfigurace mapuje datový typ String na šablonu inputtext.xhtml 4.24 a šabloně předá parametry: maxlength, size, required. Šablona inputtext.xhtml by mohla vypadat třeba takto: 1 <ui:decorate xmlns=" 2 xmlns:ui=" 3 xmlns:h=" 4 template="#{template}"> 5 6 <ui:param name="rendered" 7 value="#{render$field.firsttoupper()$}"/> 8 <ui:param name="label" 9 value="#{text[ $field$ ]}"/> 10 <ui:param name="id" 11 value="#{prefix}$field$"/> 12 <ui:param name="required" 13 value="#{$required$}"/> 14 <ui:param name="maxlength" 15 value="$maxlength$"/> 16 <ui:param name="size" 17 value="$size$"/> 18 <ui:param name="value" 19 value="#{$entitybean.shortclassname()$.$field$}"/> <ui:define name="input"> 22 <h:inputtext 23 rendered="#{rendered}" 24 required="#{required}" 25 id="#{id}" 26 maxlength="#{maxlength}" 27 size="#{size}" 28 value="#{value}"/> 29 </ui:define> <ui:define name="output"> 32 <h:outputtext value="#{value}"/> 33 </ui:define> </ui:decorate> Listing 4.24: Šablona InputText pro AspectFaces

47 4.4. POUŽITÉ TECHNOLOGIE 33 Na první pohled může šablona působit složitě, ale pro JSF vývojáře je to běžná šablona. Jediná odlišnost je ve výrazech uzavřených mezi dolary, to jsou proměnné Aspect- Faces. V první části šablony jsou definovány proměnné pro šablonu (ui:param). V druhé části (ui:define name="input") je definována šablona pro editaci vstupního pole. Část třetí (ui:define name="output") slouží pro výpis daného pole[1]. Podrobnější návod lze nalézt v dokumentaci AspectFaces. Integrace AspectFaces do projektu je jednoduchá. AspectFaces podporuje balíčkovací systém pro Java projekty Maven 10. Závislost se vyplní do souboru pom.xml do značky dependencies <dependency> 2 <groupid>com.codingcrayons.aspectfaces</groupid> 3 <artifactid>aspectfaces</artifactid> 4 <version>1.2.0</version> 5 </dependency> Listing 4.25: Konfigurace závislosti na AspectFaces v pom.xml Tento kód zajistí vložení knihovny do projektu. Protože balíčky AspectFaces nejsou uloženy v centrálním uložišti Maven, je nutné přidat ještě adresu serveru <repository> 2 <id>aspectfaces repo</id> 3 <url> 4 </repository> Více podrobností v dokumentaci 11. Listing 4.26: Konfigurace repozitáře v pom.xml Výhody Google Closure Library oproti jquery Protože se část této práce týká klientské strany, bude implementována v JavaScriptu. Implementace JavaScriptu se mezi prohlížeči lehce liší, proto bylo vhodné vybrat nějaký framework, který tento problém vyřeší. DOM API pro JavaScript je velice nešikovně a hlavně neprakticky navrženo[7]. Jako důsledek tohoto nedostatku si většina programátorů napíše vlastní knihovnu, která jim usnadní práci. Ti chytřejší z nich se podívají po nějakém existujícím řešení, kterých je celá řada, např: jquery 12, Prototype 13, ExtJS 14, Dojo 15, a jiné. Stejným způsobem vznikla i knihovna jquery. Původní záměr byl odstranit nekompatibility mezi prohlížeči a usnadnit práci s DOMem. Tento cíl splnilo jquery výborně a díky tomu se stalo velice populární. jquery je pouze DOM Helper 16. jquery nijak nepomáhá s architekturou aplikace, rozdělením do tříd apod. Proto jsou často knihovny a aplikace napsané v jediném souboru o DOM Helper je výraz pro knihovnu, která zjednodušuje práci s DOMem webového dokumentu

48 34 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ stovkách či tisících řádcích. Tento přístup je známkou code smells[17], špatného návrhu a velice obtížné testovatelnosti. Údržba takového kódu je nesmírně náročná a riziko chybovosti je velice vysoké. Pro tuto práci je potřeba knihovna, která zjednoduší architekturu aplikace, umožní dynamické načítání tříd a jejich rozdělení do samostatných souborů. Tím se zefektivní vývoj, údržba kódu a hlavně testovatelnost. Z těchto důvodů byla vybrána Google Closure Library 17. Closure je plnohodnotný framework, který umožňuje strukturovat aplikaci do jmenných prostorů a poskytuje nástroj k automatickému načítání tříd. V Closure jsou napsány služby jako je Gmail, Maps a spousta jiných služeb od Googlu. Closure obsahuje také nástroj pro statickou optimalizaci výsledného kódu - Closure Compiler 18. Compiler umí detekovat nepoužité funkce, mrtvý kód 19, i volání funkce se špatným počtem argumentů 20. Compiler kód před produkčním nasazením analyzuje a provede jeho minifikaci 21. Minifikace je proces, kdy jsou z kódu odstraněny zbytečné mezery, komentáře a optimalizovány jména funkcí a proměnných. Výsledný je mnohem menší a tím se urychlí jeho načítání do webového prohlížeče CoffeeScript JavaScript byl navržen v roce 1995 a vychází ze syntaxe jazyka C. Proto není jeho syntaxe expresivní. CoffeeScript 22 je jazyk vycházející ze syntaxe Ruby a Pythonu, který se kompiluje do JavaScriptu. CoffeeScript byl vybrán, protože jeho syntaxe je příjemnější, usnadňuje psaní tříd a jazykových konstruktů Mocha Pro JavaScript se nabízí mnoho testovacích frameworků 23. Pro Test-driven development 24 je vhodný framework, kterým se dají spouštět testy na serveru, ideálně z příkazové konzole. Jedním z nich je Mocha 25. Mocha je hojně používaný testovací framework, který poskytuje interface pro Test-driven development a Behavior-driven development 26. Navíc Mocha poskytuje několik formátů testových reportů LESS CSS LESS je jazyk, který usnadňuje práci s CSS. LESS rozšiřuje CSS o proměnné, operace, funkce a umožňuje dědičnost pomocí zanořování

49 4.4. POUŽITÉ TECHNOLOGIE 35 Pomocí LESS lze CSS rozdělit do logických bloků, jednotlivých souborů. Výstupem kompilace je pouze jeden CSS soubor, jehož velikost může být minifikována - odstranění bílých znaků a komentářů.

50 36 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

51 Kapitola 5 Realizace Všechny komponenty vytvořené v této práci jsou vytvořeny jako rozšíření JSF označované TNT faces. TNT faces jsou uvolněny pod BSD licencí 1 a dostupné ve veřejném repozitáři < 5.1 HTML5 validace Podle návrhu bylo generování HTML5 validace implementováno pomocí rozříšení ResponseWriter. Pro HTML5 byla vytvořena třída Html5ResponseWriter jako potomek ResponseWriterWrapper. Protože se při vykreslování komponent volá na ResponseWriter metoda startelement, bylo nejlepším řešením její přetížení. Metoda startelement podle signatury dostane argumentem název elementu a danou komponentu, která se právě vykresluje. V metodě startelement je umístěna detekce typu komponenty. HTML5 elementy mají vzájemně různé atributy a to i v rámci elementu input, ve třídě byly vytvořeny množiny povolených atributů. Množiny atributů byly rozděleny do sekcí podle tabulky 5.1 V případě, že je komponenta instancí jednoho z následujících typů: UIForm 1 Název množiny Popis FORM_ATTRS Atributy pro element Form SELECT_ATTRS Atributy pro element Select TEXTAREA_ATTRS Atributy pro element Textarea INPUT_ATTRS Atributy pro element Input INPUT_PASSWORD_ATTRS Atributy pro element Input typ password INPUT_RANGE_ATTRS Atributy pro element Input typ range INPUT_RANGE_TYPES Typy elementu Input BUTTON_ATTRIBUTES Atributy pro element Input typ submit Tabulka 5.1: Přehled rozdělení množin atributů 37

52 38 KAPITOLA 5. REALIZACE HtmlInputText HtmlInputSecret HtmlInputTextarea UISelectBoolean UISelectOne UISelectMany UICommand Jsou vypsány její atributy podle tabulky 5.1. V případě, že není komponenta detekována není vypsán žádný atribut. Tím je zaručeno, že nebudou narušeny jiné komponenty. Povolené atributy pro jednotlivé komponenty jsou napevno vestavěné, avšak je možno vytvořit potomka Html5ResponseWriter a rozšířit tak množiny povolených atributů. Html5ResponseWriter rozšiřuje HTML_BASIC renderkit, tím je kompatibilní se standardními komponentami. O vytvoření instance Html5ResponseWriter se stará Html5RenderKit. Samotný Html5RenderKit je vytvářen Html5RenderKitFactory a to tak, že pokud není v kofiguračním souboru faces-config.xml zaregistrován jiný RenderKit. Vytvoření instance Html5RenderKit ukazuje následující ukázka kódu public RenderKit getrenderkit(facescontext ctx, String renderkitid) { 3 RenderKit renderkit = wrapped.getrenderkit(ctx, renderkitid); 4 if (HTML_BASIC_RENDER_KIT.equals(renderKitId)) { 5 renderkit = new Html5RenderKit(renderKit, ctx); 6 } 7 return renderkit; 8 } Listing 5.1: Implementace vytvoření Html5RenderKit Html5RenderKitFactory je zaregistrována v faces-config.xml 5.2: 1 <faces config version="2.0"> 2 <name>tnt</name> 3 <factory> 4 <render kit factory> 5 com.codingcrayons.tnt.kit. Html5RenderKitFactory 6 </render kit factory> 7 </factory> 8 </faces config> Listing 5.2: Registrace vytvoření Html5RenderKitFactory Tato konfigurace je součástí knihovny TNT faces, takže vývojář nemusí registrovat Html5RenderKitFactory ručně. V případě, že hostitelská aplikace používá vlastní RenderKit nebo RenderKitFactory, není problém vytvořit instanci Html5RenderKit ručně v RenderKitFactory. Tím je framework TNT faces připraven na integraci do hostitelské aplikace.

53 5.2. RESPONZIVNÍ KOMPONENTY Integrace s PrimeFaces Při integraci s frameworkem PrimeFaces se HTML5 validace vůbec negenerovala. Bylo nutné debugovat a prozkoumat jejich zdrojové kódy. Při debugování bylo objeveno, že při vykreslování PrimeFaces komponent není do metody startelement předávána daná komponenta. Resp. byla předávána hodnota null. Toto znemožnilo propagaci atributů komponent a proto nemohla být vykreslena HTML5 validace. Ač se tento problém zdál neřešitelný, při průzkumu zdrojových kódů JSF byla objevena metoda getcurrentcomponent na třídě UIComponent. Tato medota vrací aktuálně zpracovávanou komponentu. Takže v případě, že předaná komponenta do metody startelement je null, pokusí se Html5ResponseWriter komponentu vyhledat a předat ke zpracování. Toto řešení bylo otestováno a dokonce nasazeno na produkci webu AspectFaces Integrace H5F Knihovna H5F je distribuována pomocí balíčkovacího systému Bower 2. Závislosti pro Bower jsou uloženy v souboru bower.json { 2 "name": "tnt faces", 3 "version": "0.1.2", 4 "dependencies": { 5 "H5F": "1.0.0" 6 } 7 } Listing 5.3: Konfigurace závislosti na H5F v bower.json Instalace závislostí se provede příkazem bower install. Pro snížení velikosti zdrojů načítaných v hostitelské aplikaci, je kód H5F připojen a minifikován spolu s ostatním kódem TNT faces. 5.2 Responzivní komponenty Podle návrhu byly vytvořeny komponenty: Article Content Header HorizontalMenu MenuItem Sidebar 2

54 40 KAPITOLA 5. REALIZACE Všechny komponenty byly vytvořeny jako standardní JSF komponenty. Každou komponentu je nutno zaregistrovat v konfiguračním souboru tnt.taglib.xml, příklad registrace komponenty HorizontalMenu <facelet taglib 2 xmlns=" 3 version="2.0"> 4 <namespace> 5 6 <tag> 7 <tag name>horizontalmenu</tag name> 8 <component> 9 <component type>tnt.horizontalmenu</component type> 10 </component> 11 <attribute> 12 <name>mini</name> 13 <required>false</required> 14 <type>boolean</type> 15 </attribute> 16 </tag> 17 </facelet taglib> Listing 5.4: Registrace komponenty HorizontalMenu v taglib.xml Registrace komponenty obsahuje: název komponenty, který se bude používat v XHTML šabloně - tag-name identifikátor komponenty - component-type atribut komponenty mini Atribut komponenty mini určuje, jak se horizontální menu vykreslí. Pokud je mini = true, je menu vykreslenu jako HTML element select. Jinak se položky menu vykreslí pod sebe. Tím je splněn požadavek na konfigurovatelnost horizontálního menu. Protože do atributu komponenty lze vložit výraz Expression Language 3, lze dynamicky měnit vzhled menu za běhu aplikace. Níže uvedený kód ukazuje možnost dynamické změny vzhledu menu <tnt:horizontalmenu mini="#{settings.showselectbox}"> 2 <tnt:menuitem> Domu </tnt:menuitem> 3 <tnt:menuitem> Kontakt </tnt:menuitem> 4 </tnt:horizontalmenu> Listing 5.5: Použití komponenty HorizontalMenu v XHTML šabloně Výraz #{settings.showselectbox} je za běhu aplikace vyhodnocen a návratová hodnota je předána komponentě. Tímto způsobem lze dynamicky přepínat vzhled menu. CSS style jsou implementovány pomocí nástoje LESS Pro každou komponentu je vytvořen jeden LESS soubor, tento přístup umožňuje lepší dekompozici. Pro vytvoření 3

55 5.3. INPLACE EDITOR 41 produkčního JAR balíčku jsou všechny LESS soubory vloženy zkompilovány do jednoho výsledného CSS souboru. Takto se minimalizuje nutný počet HTTP požadavků a tím se zrychlí načtení hostitelského aplikace. Velikost výsledného CSS souboru je optimalizována, odstranění prázdných znaků atd. Aplikaci komponent lze vyzkoušet na adrese < kde jsou integrovány s knihovnou AspectFaces Aplikace CSS Podle návrhu byla vytvořena konfigurace pro automatické nahrávání zavislostí komponent. Pro tento úkol byla vytvořena třída DependenciesManager. Pro vláknovou bezpečnost je její instance vytvořena pro každý HTTP požadavek. Tato instance je uložena jako atribut FacesContext. Tím je dosaženo její vytvoření on-demand a uložení pro další práci během HTTP požadavku. Protože v době renderování komponenty je již pozdě na vykreslení odkazu na CSS, je nutno vložit CSS v konstruktoru komponenty. K tomuto účelu slouží metoda inserttntcss. Tato metoda přidá do UIViewRoot jako resource CSS. Registrace resource musí proběhnout před začátkem renderování stromu komponent, jinak by se CSS do hlavičky nevložilo. Stejným způsobem je provedena registrace Meta viewport. K tomuto účelu slouží metoda insertmetaviewport. DependenciesManager načítá konfiguraci z web.xml a podle toho registruje resource v UIViewRoot. Načtení konfigurace je opět způsobem on-demand (na vyžádání). DependenciesManager se také stará o to, aby nebyl stejný resource vložen do hlavičky několikrát. 5.3 Inplace editor Podle návrhu byl inplace editor rozdělen na dvě sekce: JSF UI komponentu klientskou část Pro automatické načítání zavislostí byl použit DependenciesManager jako u responzivních komponent. Pro aktualizování zobrazovaného textu je za běhu aplikace vytvořena JSF komponenta HtmlOutputText, která se formátuje na serveru. Pro správné zachování životního cyklu JSF je za běhu aplikace vytvořeno AJAX tlačítko pro odeslání hodnoty. Toto tlačítko je detekováno klientským kódem a zobrazuje se pouze během editace. Klientská část byla vytvořena jako nezávislá komponenta na JSF. Je to samostatná knihovna napsána v jazyce CoffeeScript. Tato knihovna nazvaná InplaceNG je veřejně dostupná na < Realizace InplaceNG byla rozdělena to tří tříd: InplaceBuilder - vytváří strukturu editoru (ikonka atd.)

56 42 KAPITOLA 5. REALIZACE InplaceBehaviour - stará se o chování editoru (kliknutí na ikonku, odeslání formuláře atd.) InplaceEditor - samotný editor, spojuje veškerou funčnost Celé použití bylo zabaleno, pro jednodušší použití, za API. Příklad použití je v ukázce cc. api. attachinplace (. tnt edit content input,. tnt view content span ); Listing 5.6: Ukázka aplikování inplace editoru v JS Vstupem funkce attachinplace jsou dva parametry: CSS selektor vstupního pole CSS selektor elementu pro zobrazení Pro ikonku byla použita knihovna Font Awesome 4. Výhoda knihovny Font Awesome je ta, že ikonka není obrázek, ale písmo. Tím lze libovolně upravit CSS ikonky. Inplace editor je implementován tak, aby přebral CSS editovaného textu. Ukázka je vidět na obrázku 5.1. Editovaný text je původně element H1, jehož CSS se aplikují na vstupní pole i během editace. Obrázek 5.1 také zobrazuje ikonu reprezentující aktivitu, během odesílání hodnoty na server. Uživatel je tak stále v interakci s aplikací. Obrázek 5.1: Životní cyklus inplace editoru 5.4 Distribuce TNT faces Integrace TNT faces do Maven projektu je zcela jednoduchá. Knihovna TNT faces je vytvořena jako závislost pro Maven. Balíček je umístěn v Maven repozitáři CodingCrayons 5, který je veřejně přístupný. Pro integraci stačí zapsat do pom.xml, ukázka <dependency> 2 <groupid>com.codingcrayons</groupid> 3 <artifactid>tnt</artifactid> 4 <version>0.1.1</version>

57 5.5. INTEGRACE S ASPECTFACES 43 5 </dependency> 6 7 <repository> 8 <id>aspectfaces repo</id> 9 <url> 10 </repository> Listing 5.7: Nastavení závislosti na TNT faces v pom.xml Do ostatních projektů lze vložit TNT faces jako JAR soubor, který je umístěn na < 5.5 Integrace s AspectFaces Knihovna TNT faces je navržena tak, aby byla zcela nezávislá na AspectFaces. To zvyšuje její kohezi a škálovatelnost. Mějme následující XHTML šablonu pro AspectFaces <ui:decorate template="#{template}"> 2 3 <ui:param name="rendered" 4 value="#{render$field.firsttoupper()$}"/> 5 <ui:param name="label" 6 value="#{text[ $field$ ]}"/> 7 <ui:param name="id" 8 value="#{prefix}$field$"/> 9 <ui:param name="required" 10 value="#{$required$}"/> 11 <ui:param name="maxlength" 12 value="$maxlength$"/> 13 <ui:param name="size" 14 value="$size$"/> 15 <ui:param name="type" 16 value="$type$"/> 17 <ui:param name="value" 18 value="#{$entitybean.shortclassname()$.$field$}"/> <ui:define name="input"> 21 <h:inputtext 22 rendered="#{rendered}" 23 required="#{required}" 24 id="#{id}" 25 maxlength="#{maxlength}" 26 size="#{size}" 27 type="#{empty type? text : type}" 28 value="#{value}"/> 29 </ui:define> <ui:define name="output"> 32 <h:outputtext value="#{value}"/> 33 </ui:define>

58 44 KAPITOLA 5. REALIZACE </ui:decorate> Listing 5.8: Příklad šablony pro AspectFaces Šablona obsahuje deklaraci proměnných (ui:param) a dvě části: část pro editaci (ui:define name="input") a část pro výpis (ui:define name="output"). V části pro editaci je použita standardní komponenta pro textový vstup. Komponenta inputtext používá atribut type, který umožní propagaci typu vstupu pro HTML5 validaci. Atribut required se chová stejně jako u standardní komponenty (pole je povinné), navíc je povinnost vyplnění atributu zpropagována až do HTML. Žádné další změny pro integraci s AspectFaces nejsou nutné. V rámci této práce byl vytvořen Maven projekt, který využívá tyto knihovny. Projekt je veřejně dostupný na adrese <

59 Kapitola 6 Testování 6.1 Jednotkové testování Jednotkové testování[3] (unit testing) je metodika, která testuje kód po malých částech. U objektového kódu jsou tyto části typicky metody. Jednotlivé testy by měly být mezi sebou nezávislé a měly by testovat pouze daný objekt. Pokud má objekt nějaké zavislosti, typicky se využívá mockování. Mockování je metodika, kdy na místo opravdového objektu vytvoříme falešný objekt. Tento falešný objekt typicky nemá žádnou logiku, nebo má předem definované chování. Testování s mocky se využívá pokud nás nezajímá integrace objektu s jinými, ale pouze to, zda objekt pracuje správně podle našich očekávání. Mockování se také používá v situacích, kdy nemůžeme testovat s reálnými systémy (např. API bankovního systému). V prostředí Javy je několik frameworků pro jednotkové testování. Dva nejpoužívanější jsou junit a TestNG. Pro TNT faces byl vybrán TestNG, protože je novější a staví na nedostatcích junit. Pro mockování byl vybrán framework Mockito. Protože je TNT faces vytvořen jako Maven projekt, testy lze spustit z konzole příkazem mvn test. V prostředí JavaScriptu opět existuje řada knihoven pro testování. Pro TNT faces byla vybrána knihovna Mocha, protože je hojně používaná. InplaceNG používá pro vývoj nástroj Grunt JS 1. Což je nástroj ke správě a udržbě aplikace pomocí příkazové řádky. Testy se spouští příkazem grunt test. Knihovny Mockito a Mocha poskytují API pro TDD a BDD. Jednotkových testů je více jak Testování responzivních komponent Knihovna TNT faces byla testována spolu s AspectFaces. Aplikace, kde jsou obě knihovny integrovány, je dostupná online 2. Náhled aplikace na zařízení ipad vertikálně 6.1, ipad horizontálně 6.2 a iphone vertikálně 6.3. Responzivnost komponent na této aplikaci byla otestována na těchto zařízeních:

60 46 KAPITOLA 6. TESTOVÁNÍ MacBook Air, Chrome iphone 3SG, Chrome a Safari iphone 4, Safari ipad, Safari ipad 2, Safari Nexus S, Android 2 Galaxy Nexus, Android 4 BlackBerry, PlayBook 2 BlackBerry, 9000 Obrázek 6.1: Obrazovka testovací aplikace - ipad vertikálně

61 6.3. UŽIVATELSKÉ TESTOVÁNÍ 47 Obrázek 6.2: Obrazovka testovací aplikace - ipad horizontálně 6.3 Uživatelské testování Jelikož tato práce se týká uživatelského rozhraní, je nutno komponenty otestovat i z pohledu použitelnosti. Komponenty byly uživatelsky otestovány na aplikaci Showcase AspectFaces 3, kde testovaný subjekt bude plnit předem připravený scénář. Testovací zařízení: MacBook Air, obrazovka 1440 x 900 iphone 3SG, obrazovka 480 x 320 Scénář: Přejít na stránku "Life cycle" Přejít na stránku "More" Najít nejnovější Tweet Editovat povinný nadpis H1 3

62 48 KAPITOLA 6. TESTOVÁNÍ Editovat ovou adresu Editovat vstupní pole s omezením na malé znaky anglické abecedy Slečna Iva (28 let) splnila scénář bez problémů, reagovala rychle a intuitivně. Před kliknutím na selectbox byla dotázána, co očekává po vybrání položky v seznamu 6.4, odpověděla, že přechod na danou stránku. Nalezení nejnovějšího Tweetu jí nečinilo také problémy, ani na iphonu, kde je boční sloupec přesunut na konec stránky. Z toho se dá vyvodit, že uživatel není zmaten, pokud se na menší obrazovce změní uspořádání prvků na stránce. Před editací nadpisu byla tázána, co znamená ikona tužky, správně odpověděla, že editování textu 5.1. Poté klika na ikonu, odstranila daný text a pokusila se odeslat prázné pole. Při pokusu odeslání se zobrazila validační zpráva 6.6, participantka podle zprávy vyplnila vstupní pole a uložila ho kliknutím na tlačtko OK. Dále následoval úkol editace ové adresy. Cílem bylo vyzkoušet, jakou bude mít uživatel reakci, při chybně vyplněné adrese. Proto byla participantka záměrně vyzvána chybně vyplnit ovou adresu. Její reakce byla podle očekávání, ihned po zobrazení zprávy 6.5 vyplnila adresu správně a uložila ji Závěr Z uživatelského testování vyplývá, že uživatel není zmaten pokud se stránka přizpůsobí velikosti cílového zařízení. Při testování se nenarazilo na žádné problémy ani nejasnosti, velikost písma byla dobře čitelná. Participantka se sama hodnotí jako běžný uživatel, který používá Internet a kancelářský software. Změna horizontálního menu na výběrový seznam, pro optimalizaci místa na menší obrazovce, uživatele nemate. Všechny testovací scénáře pokryly případy použití z tabulky Integrační testování Pro integrační testování byla použita aplikace Showcase AspectFaces 4. Jako testovací scénáře byly použity scénáře z uživatelského testování. Pro testování byl použit nástroj Selenium 5. Selenium simuluju chování uživatele pomocí Javascriptu, podle předem připravaného scénáře. Testování aplikace Showcase proběhlo ve třech testovacích sadách: se standardními komponentami JSF, s komponentami PrimeFaces a s rozšířením TNT faces. Cílem testování bylo dokázat, že TNT faces nenaruší původní chování ostatních komponent. TNT faces mají pouze rozšiřovat vlastnosti komponent přidáním klientské validace. Integrační testování prokázalo, že TNT faces zachovávají původní chování komponent na serverové části. Rozšířením komponent o klientskou validaci se snížil počet nutných HTTP dotazů na server, protože prohlížeč nedovolil odeslání formuláře, pokud všechny jeho vstupní pole nebyly validní

63 6.5. VÝKONOVÉ TESTOVÁNÍ 49 (ms) min medián max Připojení Zpracování Čekání Celkem Tabulka 6.1: Testování výkonu PrimeFaces komponent (ms) min medián max Připojení Zpracování Čekání Celkem Tabulka 6.2: Testování výkonu s rozšířením TNT faces 6.5 Výkonové testování Protože testování není jenom kvalita kódu a uživatelská přívětivost, je na místě otestovat TNT faces i z hlediska výkonu. Cílem tohoto testování je změřit zatížení, které přináší TNT faces. Pro testování byla vybrána instance aplikace Showcase AspectFaces 6. Testovaná stránka obsahovala 18 formulářových prvků 6.7. Jako nástroj k testování byl vybrán Apache HTTP server benchmarking tool 7. Jedná se o konzolový nástroj, který má jednoduché použití. Apache Benchmark byl spuštěn s těmito parametry: 20 současných vláken 20 dotazů Konfigurace stroje, na kterém proběhlo testování: MacBook Air, Mac OS X 10 procesor: 1.7 GHz Intel Core i5 paměť: 4 GB 1333 MHz DDR3 Výkonové testování proběhlo ve dvou fázích: s použitím PrimeFaces komponent a s rozšířením TNT faces. Cílem bylo zjistit, zda rozšíření komponent o klientskou validaci přinese nějaká zatížení či zpomalení aplikace. Měření bylo opakováno 5x a hodnoty byly potom zprůměrovány. Medián doby odpovědi s komponentami PrimeFaces byl 3128 ms, maximální doba odezvy byla jen o několik desítek

64 50 KAPITOLA 6. TESTOVÁNÍ vyšší 3288 ms. Medián doby odezvy s použitím rozšíření TNT faces byl 3268 ms, rozdíl je tedy pouze 140 ms ve srovnání s hodnotami naměřenými s PrimeFaces. Maximální doba odezvy s TNT faces byla 3312 ms, což je pouze o 24 ms více než bez použití TNT faces. Detailní výsledek testování PrimeFaces komponent je v tabulce 6.1 a tabulka 6.2 ukazuje hodnoty naměřené s TNT faces. Z testování jasně vyplynulo, že využití TNT faces v aplikaci nenese takřka žádné zpomalení. Načtení aplikace s TNT faces bylo v průměru pomalejší v řádu jednotek či desítek milisekund. Toto zpomalení nelze považovat vypovídající, může být ovlivněno více faktory (cache, latence sítě,...).

65 6.5. VÝKONOVÉ TESTOVÁNÍ 51 Obrázek 6.3: Obrazovka testovací aplikace - iphone vertikálně

66 52 KAPITOLA 6. TESTOVÁNÍ Obrázek 6.4: Obrazovka testovací aplikace - iphone výběr stránky z horizontálního menu Obrázek 6.5: Validační zpráva při chybně vyplněné ové adrese

67 6.5. VÝKONOVÉ TESTOVÁNÍ 53 Obrázek 6.6: Validační zpráva při nevyplnění povinného pole Obrázek 6.7: Formulář pro výkonové testování