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

Č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

iv

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.

vi

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 20. 4. 2011

.............................................................

viii

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

x

Obsah 1 Úvod

1

2 Popis problému a speficikace požadavků 2.1 Tvorba moderního webu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Souhrn požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 6 7

3 Rešerše 3.1 Moderní web . . 3.2 Validace dat . . . 3.2.1 Shrnutí . 3.3 Inplace editace . 3.3.1 Shrnutí . 3.4 JSF frameworky 3.4.1 Shrnutí .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 Analýza a návrh řešení 4.1 Responzivní design . . . . . . . . . . . . . . . . . . . . 4.1.1 Aplikace CSS . . . . . . . . . . . . . . . . . . . 4.2 Klientská validace . . . . . . . . . . . . . . . . . . . . . 4.2.1 Nová komponenta . . . . . . . . . . . . . . . . 4.2.2 Rozšíření RenderKit . . . . . . . . . . . . . . . 4.2.3 Porovnání přístupů . . . . . . . . . . . . . . . . 4.3 Inplace editor . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Vytvoření editačního pole na straně klienta . . 4.3.2 Generování formuláře na straně serveru . . . . 4.3.3 Návrh inplace komponenty . . . . . . . . . . . 4.4 Použité technologie . . . . . . . . . . . . . . . . . . . . 4.4.1 AspectFaces . . . . . . . . . . . . . . . . . . . . 4.4.2 Výhody Google Closure Library oproti jQuery . 4.4.3 CoffeeScript . . . . . . . . . . . . . . . . . . . . 4.4.4 Mocha . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 LESS CSS . . . . . . . . . . . . . . . . . . . . .

xi

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

9 9 11 12 13 14 14 17

. . . . . . . . . . . . . . . .

19 19 20 22 22 23 26 26 27 29 30 31 31 33 34 34 34

xii

OBSAH

5 Realizace 5.1 HTML5 validace . . . . . . . 5.1.1 Integrace s PrimeFaces 5.1.2 Integrace H5F . . . . . 5.2 Responzivní komponenty . . . 5.2.1 Aplikace CSS . . . . . 5.3 Inplace editor . . . . . . . . . 5.4 Distribuce TNT faces . . . . . 5.5 Integrace s AspectFaces . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

37 37 39 39 39 41 41 42 43

6 Testování 6.1 Jednotkové testování . . . . . . . . 6.2 Testování responzivních komponent 6.3 Uživatelské testování . . . . . . . . 6.3.1 Závěr . . . . . . . . . . . . 6.4 Integrační testování . . . . . . . . . 6.5 Výkonové testování . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

45 45 45 47 48 48 49

. . . . . . . .

. . . . . . . .

7 Závěr 55 7.1 Budoucí práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8 Seznam použitých zkratek

59

9 Obsah přiloženého CD

61

10 Apendix A 10.1 Definice případů užití

63 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Seznam obrázků 2.1

Průběh inplace editace, zdroj: [22] . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3

Ilustrační znázornění responzivního webu, zdroj: [19] . . . . . . . . . . . . . . 11 JSF implementace MVC[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 JSF životní cyklus[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 4.2

Schématické znázornění responsivních TNT komponent . . . . . . . . . . . . . 21 Sekvenční diagram vykreslovací fáze JSF s generováním klientské validace . . 25

5.1

Životní cyklus inplace editoru . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1 6.2 6.3 6.4 6.5 6.6 6.7

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 Validační zpráva při chybně vyplněné emailové adrese . . . . . . . . . Validační zpráva při nevyplnění povinného pole . . . . . . . . . . . . Formulář pro výkonové testování . . . . . . . . . . . . . . . . . . . .

xiii

. . . . . . . . . . . . menu . . . . . . . . . . . .

. . . . . . .

5

46 47 51 52 52 53 53

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1 2.2

Souhrn všech požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matice pokrytí požadavků 2.1 případy užití . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3

Matice porovnání polyfillů pro HTML5 validaci . . . . . . . . . . . . . . . . . 13 Matice porovnání knihoven pro inplace editaci . . . . . . . . . . . . . . . . . . 14 Matice porovnání jednotlivých JSF frameworků . . . . . . . . . . . . . . . . . 18

4.1

Přehled responzivních TNT komponent

5.1

Přehled rozdělení množin atributů . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1 6.2

Testování výkonu PrimeFaces komponent . . . . . . . . . . . . . . . . . . . . 49 Testování výkonu s rozšířením TNT faces . . . . . . . . . . . . . . . . . . . . 49

xv

7 7

. . . . . . . . . . . . . . . . . . . . . 20

xvi

SEZNAM TABULEK

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

2

KAPITOLA 1. ÚVOD

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 medium1 . 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

4

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

vstupního pole (emailová 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. 1 2

@Entity class User {

3

@UiOrder(1) @NotNull @Column(unique = true) String username;

4 5 6 7 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 unikátní @Column(unique = true) • uživatelské jméno nesmí být null (je povinné) @NotNull • 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.

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 hover2 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 focus3 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]

2 3

http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo-classes obsah pole je označen a uživatel může rovnou psát

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: • autofocus4 • placeholder5 A vstupy typu6 : • datetime

• email

• date

• url

• month

• search

• time

• tel

• week

• color

• number Knihovna pro JS validaci bude podporovat tyto vlastnosti: • povinné pole • validace podle regulárního výrazu • email - 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. 4

http://www.w3.org/TR/html-markup/input.text.html#input.text.attrs.autofocus http://www.w3.org/TR/html-markup/input.text.html#input.text.attrs.placeholder 6 http://www.w3.org/TR/html-markup/input.html 5

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ů

2.2.1

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 10.1. Případ užití R1 R2 R3 R4 R5 R6 R7 U1 X X U2 X X X U3 X U4 X U5 X X X X

R8 X X

X

Tabulka 2.2: Matice pokrytí požadavků 2.1 případy užití

8

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

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 queries1 . 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ážitek2 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í 1 2

http://www.w3.org/TR/css3-mediaqueries http://www.allaboutux.org/ux-definitions

9

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 SEO3 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. plavou4 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. 1 2 3

@media screen and (max−width: 900px) { /∗ ∗/ }

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. 3 4

http://en.wikipedia.org/wiki/Search_engine_optimization http://www.w3schools.com/css/css_float.asp

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 W3C5 .

3.2

Validace dat

HTML56 je standardizovaný jazyk pro prezentování strukturovaného obsahu na webu. Jedná se o již 5. verzi připravovanou W3C7 . 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 candidate8 , 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. 5

http://www.w3.org/TR/css3-mediaqueries http://www.w3.org/TR/2012/CR-html5-20121217 7 http://www.w3.org 8 Specifikace je připravena k vydání, ale není ještě oficiálně schválena 6

12

KAPITOLA 3. REŠERŠE

Polyfilly pracují tzv. non-obtrusive9 . 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 Lib10 je modulární polyfill pro funkcionalitu přinášející HTML5. Knihovna je postavená nad jQuery a Modernizr11 . 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. H5F12 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ězd13 ) a forků je autor aktivní a vybudoval si menší komunitu. H5F je dokonce v balíčkovacím systému Bower. Formvalidation.js14 je také polyfill bez dalších závislostí. U této knihovny je zajímavá možnost, úpravy validačních zpráv pomocí CSS15 . Knihovna podporuje pouze Internet Explorer 8 a vyšší. Html5Forms.js16 je polyfill, který implementuje pouze podmnožinu z HTML5 validace. Tato knihovna nepodporuje vstupní pole typu email nebo url. h5Validate17 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.

3.2.1

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í integraci18 . 9

oddělení JS kódu od HTML stránky http://afarkas.github.com/webshim/demos/index.html 11 http://modernizr.com 12 https://github.com/ryanseddon/H5F 13 https://github.com/ryanseddon/H5F/stargazers 14 https://github.com/chemerisuk/formvalidation.js 15 https://github.com/chemerisuk/formvalidation.js#internationalization 16 https://github.com/zoltan-dulac/html5Forms.js 17 http://ericleads.com/h5validate 18 https://travis-ci.org/ryanseddon/H5F 10

3.3. INPLACE EDITACE

Název Webshims Lib H5F Formvalidation.js Html5Forms.js h5Validate

13

Závislosti jQuery a Moernizr ne ne jQuery jQuery

podpora HTML5 validace plná plná plná částečná částečná

Tabulka 3.1: Matice porovnání polyfillů pro HTML5 validaci

3.3

Inplace editace

jQuery In Place Editor19 je malá knihovna pro inplace editaci postavená nad jQuery. Poslední změna v tomto projektu byla 28.1.2011 a podle issue trackeru20 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. Jeditable21 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-editable22 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í Bootstrap23 , jQuery UI24 nebo jQuery25 . 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í WYSIWYG26 editoru. X-editable umožňuje 19

https://code.google.com/p/jquery-in-place-editor https://code.google.com/p/jquery-in-place-editor/issues/list 21 http://www.appelsiini.net/projects/jeditable 22 http://vitalets.github.com/x-editable 23 http://vitalets.github.com/x-editable/assets/zip/bootstrap-editable-1.4.3.zip 24 http://vitalets.github.com/x-editable/assets/zip/jqueryui-editable-1.4.3.zip 25 http://vitalets.github.com/x-editable/assets/zip/jquery-editable-1.4.3.zip 26 http://en.wikipedia.org/wiki/WYSIWYG 20

14

KAPITOLA 3. REŠERŠE

jQuery IPE29 Aktivace kliknutím na text Vlastní vstupy ne Validace ne Přebírání stylů ne Odeslání na url nebo callback

Jeditable text ne vlastní ne url nebo callback

X-editable text nebo ikonu ano ne ne url nebo callback

InlineEdit 3 text ne vlastní ano url

Tabulka 3.2: Matice porovnání knihoven pro inplace editaci tvorbu vlastních vstupů, viz Address27 . InlineEdit 328 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.

3.3.1

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

JSF30 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 3.3. 27

http://vitalets.github.com/x-editable/demo.html?c=inline http://dev.justinmaier.com/inlineEdit3 30 http://javaserverfaces.java.net 28

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 631 .

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 validation32 . Tento standard integruje validaci serverové části a persistentní vrstvy (pomocí anotací33 ). Tímto se redukuje duplicita dat, validační 31

http://jcp.org/en/jsr/detail?id=316 http://beanvalidation.org 33 http://beanvalidation.org/intro 32

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 emailové 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 RichFaces34 v poslední verzi35 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 validaci36 . Od RichFaces existuje ještě fork37 RichFaces Bootstrap38 . Autoři sice tvrdí, že tento fork podporuje HTML5, ale HTML5 validace zde opět není podporována. RichFaces obsahují komponentu pro inplace editaci39 . 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 PrimeFaces40 v poslední verzi41 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 editaci42 , ale protože PrimeFaces nepodporují HTML5 validaci, nesplňuje komponenta požadavky této práce. Framework OmniFaces43 ve své poslední verzi44 podporuje celou řadu funkcionality z HTML545 . Omnifaces částečně podporují i HTML5 validaci, např. lze validovat vstupní pole jako email, URL apod., zde chybí ovšem zásadní vlastnost a to required - povinné pole. OmniFaces neobsahují komponentu pro inplace editaci. Framework OpenFaces46 v poslední verzi47 podporují klientskou validaci pomocí JavaScriptu i AJAXu, ale HTML5 nepodporují. Openfaces neobsahují ani koponentu pro inplace editaci. Framework ADF48 v poslední verzi49 obsahuje podporu klientské validace pomocí JavaScriptu i AJAXu. ADF neobsahují komponentu, která by podporovala inplace editaci. 34

http://www.jboss.org/richfaces verze 4.3.1 byla vydána 7.3.2013 36 http://beanvalidation.org 37 jedná se o odnož původního projektu 38 https://bootstrap-richfaces.rhcloud.com 39 http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=inplaceInput&skin=classic 40 http://www.primefaces.org 41 verze 3.5 42 http://www.primefaces.org/showcase/ui/inplace.jsf 43 https://code.google.com/p/omnifaces 44 verze 1.4 45 https://showcase-omnifaces.rhcloud.com/showcase/renderkits/Html5RenderKit.xhtml 46 http://www.openfaces.org 47 verze 3.0, 4.11.2010 48 http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html 49 11.1.1.6.0 35

3.4. JSF FRAMEWORKY

17

Framework ICEFaces50 v poslední verzi51 podporují klientskou validaci pomocí JavaScriptu i AJAXu. Podpora HTML5 zde není žádná. ICEFaces neobsahují ani komponentu pro inplace editaci. Framework MyFaces52 ve své poslední verzi53 obsahují HTML5 validaci. Tato podpora je zajištěna pomocí vlastních komponent54 . Příklad 3.2 použití takové komponenty vypadá třeba takto: 1 2 3



Listing 3.2: Příklad použití komponenty MyFaces InputText Tato komponenta se přeloží do HTML 3.3 přibližně takto: 1



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.

3.4.1

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.

50

http://www.icesoft.org 3.2.0 52 http://myfaces.apache.org 53 2.0.7 54 http://myfaces.apache.org/html5/features.html 51

18

KAPITOLA 3. REŠERŠE

Framework Richfaces Primefaces Omnifaces Openfaces ADF ICEFaces MyFaces

HTML5 validace JS validace ne ano ne ne ne ne ne ano ne ne ne ne ano ne

AJAX validace Inplace editor ano ano ano ano ano ne ano ne ne ne ne ne ne ne

Tabulka 3.3: Matice porovnání jednotlivých JSF frameworků

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 2 3 4 5 6 7 8 9 10 11 12 13

Header content Home Contact < tnt:article > Article content Sidebar content

19

20

14 15 16

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



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 Article Content Header HorizontalMenu MenuItem Sidebar

HTML5 article div header nav li aside

Popis značky Sémantická značka reprezentující obsah sekce - příklad Obalující značka - příklad Sémantická značka pro úvod nebo navigaci - příklad Sémantická značka pro navigaci - příklad Značka pro položku v seznamu - příklad Značka pro vedlejší obsah, boční sloupce apod. - příklad

Tabulka 4.1: Přehled responzivních TNT komponent

4.1.1

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.

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 4.2. 1 2 3 4

<param−name>TNT.AUTO_LOAD <param−value>false

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

https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag

22

4.2

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

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.

4.2.1

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 4.3. 1 2



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 4.4. 1



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.

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 JSF2 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 4.5. 1



2 3

vs.

4 5



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ářů

4.2.2

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). 2 3

http://www.jsftoolbox.com/documentation/help/12-TagReference/html/index.jsf https://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/component/UIComponent.html

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 4.6. 1 2 3 4 5 6 7 8

tnt com.codingcrayons.tnt.kit.Html5RenderKitFactory

Listing 4.6: Registrace RenderKitFactory ve faces-config.xml Ukázka registrace vlastní RenderKit třídy 4.7. 1 2 3 4 5 6

tnt <default−render−kit−id> Html5RenderKit 4

https://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/render/Renderer.html https://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ResponseWriter.html 6 https://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/render/RenderKit.html 7 https://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/render/RenderKitFactory.html 5

4.2. KLIENTSKÁ VALIDACE

7 8 9 10 11 12 13 14

25

Html5RenderKit com.codingcrayons.tnt.kit.Html5RenderKit

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 UIViewRoot, 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 4.2.2 (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í:

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é)

4.2.3

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 JAR8 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 3.2.

4.3

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

http://en.wikipedia.org/wiki/JAR_(file_format)

4.3. INPLACE EDITOR

4.3.1

27

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 4.8. 1

<span class="editable">Text

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 4.9. 1 2

var editableText = document.getElementsByClassName(’editable’); 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 4.10. 1 2 3 4 5

var editableText = document.getElementsByClassName(’editable’); editable (editableText, { url : ’/ edit ’, name: ’name’ });

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 4.11. 1

<span class="editable" data−url="/edit" data−name="name">Text

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 4.12. 1 2

<span class="editable" data−url="/edit" data−name="created" data−type="date">20.1.2012

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.

28

1 2

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

<span class="editable" data−url="/edit" data−name="created" data−type="date" data−value="2012−01−20">20.1.2012

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í 4.14. 1 2 3 4

<span class="editable" data−url="/edit" data−name="created" data−type="date" data−value="2012−01−20" data−min="2010−01−01" data−max="2013−12−31">20.1.2012

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 2 3

<span class="editable" data−url="/edit" data−name="name" data−type="text" data−value="lorem␣ipsum" >Lorem ipsu...

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 4.16. 1 2 3 4 5

<span class="editable" data−url="/edit" data−name="name" data−type="text" data−value="lorem␣ipsum" data−format="firstLetter" data−ellipsis="10" >Lorem ipsu...

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:

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

4.3.2

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 4.17. 1 2 3 4

<span>Lorem ipsu...

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 4.18. 1 2 3 4 5 6 7 8 9

<span>Lorem ipsu

<span class="help">?

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

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: Formulářová: 1 2 3 4

<span class="help">?

Listing 4.19: Klasická formulářová editace Inplace: 1 2 3 4 5 6 7 8 9 10 11

<span>Lorem ipsu...

<span class="help">?

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í)

4.3.3

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:

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ě 4.21. 1 2 3 4 5 6 7

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 4.1.1.

4.4 4.4.1

Použité technologie AspectFaces

AspectFaces9 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

private String name;

3 4

@NotNull public String getName() { return name; }

5 6 7 8 9

public void setName(String name) { this.name = name; }

10 11 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 4.23. 9

JFormBuilder byl přejmenován na AspectFaces, http://www.aspectfaces.com

32

1 2 3 4 5 6 7

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

<mapping> String <default tag="inputText.xhtml" maxLength="255" size="30" required="false"/>

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 2 3 4



5 6 7 8 9 10 11 12 13 14 15 16 17 18 19



20 21 22 23 24 25 26 27 28 29



30 31 32 33



34 35



Listing 4.24: Šablona InputText pro AspectFaces

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é AspectFaces. 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 Maven10 . Závislost se vyplní do souboru pom.xml do značky dependencies 4.25. 1 2 3 4 5

<dependency> com.codingcrayons.aspectfaces <artifactId>aspectfaces 1.2.0

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 4.25. 1 2 3 4

aspectfaces−repo http://maven.codingcrayons.com

Listing 4.26: Konfigurace repozitáře v pom.xml Více podrobností v dokumentaci11 .

4.4.2

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ř: jQuery12 , Prototype13 , ExtJS14 , Dojo15 , 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 Helper16 . 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 10

http://maven.apache.org http://wiki.codingcrayons.com/display/af/Static+use+of+AspectFaces 12 http://jquery.com 13 http://prototypejs.org 14 http://www.sencha.com/products/extjs 15 http://dojotoolkit.org 16 DOM Helper je výraz pro knihovnu, která zjednodušuje práci s DOMem webového dokumentu 11

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 Library17 . 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 Compiler18 . Compiler umí detekovat nepoužité funkce, mrtvý kód19 , 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 minifikaci21 . 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.

4.4.3

CoffeeScript

JavaScript byl navržen v roce 1995 a vychází ze syntaxe jazyka C. Proto není jeho syntaxe expresivní. CoffeeScript22 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ů.

4.4.4

Mocha

Pro JavaScript se nabízí mnoho testovacích frameworků23 . Pro Test-driven development24 je vhodný framework, kterým se dají spouštět testy na serveru, ideálně z příkazové konzole. Jedním z nich je Mocha25 . Mocha je hojně používaný testovací framework, který poskytuje interface pro Test-driven development a Behavior-driven development26 . Navíc Mocha poskytuje několik formátů testových reportů.

4.4.5

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í27 . 17

https://developers.google.com/closure/library https://developers.google.com/closure/compiler 19 http://en.wikipedia.org/wiki/Dead_code 20 https://developers.google.com/closure/compiler/docs/api-tutorial3 21 http://en.wikipedia.org/wiki/Minification_(programming) 22 http://coffeescript.org 23 http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript 24 http://en.wikipedia.org/wiki/Test-driven_development 25 http://visionmedia.github.com/mocha 26 http://en.wikipedia.org/wiki/Behavior-driven_development 27 http://lesscss.org 18

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ářů.

36

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

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

http://en.wikipedia.org/wiki/BSD_licenses

Název množiny FORM_ATTRS SELECT_ATTRS TEXTAREA_ATTRS INPUT_ATTRS INPUT_PASSWORD_ATTRS INPUT_RANGE_ATTRS INPUT_RANGE_TYPES BUTTON_ATTRIBUTES

Popis Atributy pro element Atributy pro element Atributy pro element Atributy pro element Atributy pro element Atributy pro element Typy elementu Input Atributy pro element

Form Select Textarea Input Input typ password Input typ range Input typ submit

Tabulka 5.1: Přehled rozdělení množin atributů

37

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 5.1. 1 2 3 4 5 6 7 8

@Override public RenderKit getRenderKit(FacesContext ctx, String renderKitId) { RenderKit renderKit = wrapped.getRenderKit(ctx, renderKitId); if (HTML_BASIC_RENDER_KIT.equals(renderKitId)) { renderKit = new Html5RenderKit(renderKit, ctx); } return renderKit; }

Listing 5.1: Implementace vytvoření Html5RenderKit Html5RenderKitFactory je zaregistrována v faces-config.xml 5.2: 1 2 3 4 5 6 7 8

tnt com.codingcrayons.tnt.kit.Html5RenderKitFactory

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.

5.2. RESPONZIVNÍ KOMPONENTY

5.1.1

39

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.

5.1.2

Integrace H5F

Knihovna H5F je distribuována pomocí balíčkovacího systému Bower2 . Závislosti pro Bower jsou uloženy v souboru bower.json 5.3. 1

{ "name": "tnt−faces", "version": "0.1.2", "dependencies": { "H5F": "1.0.0" }

2 3 4 5 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

http://bower.io

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 5.4. 1 2 3 4

http://codingcrayons.com/tnt

5 6 7 8 9 10 11 12 13 14 15 16 17

horizontalMenu tnt.HorizontalMenu mini <required>false boolean

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 5.5 1 2 3 4

Domu Kontakt

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 4.4.5. Pro každou komponentu je vytvořen jeden LESS soubor, tento přístup umožňuje lepší dekompozici. Pro vytvoření 3

http://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html

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.

5.2.1

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.)

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 5.6. 1

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 Awesome4 . 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 CodingCrayons5 , který je veřejně přístupný. Pro integraci stačí zapsat do pom.xml, ukázka 5.7. 1 2 3 4

<dependency> com.codingcrayons <artifactId>tnt 0.1.1 4 5

http://fortawesome.github.io/Font-Awesome http://maven.codingcrayons.com

5.5. INTEGRACE S ASPECTFACES

5

43



6 7 8 9 10

aspectfaces−repo http://maven.codingcrayons.com

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 5.8. 1



2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18



19 20 21 22 23 24 25 26 27 28 29



30 31 32 33



44

KAPITOLA 5. REALIZACE

34 35



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 .

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 40.

6.2

Testování responzivních komponent

Knihovna TNT faces byla testována spolu s AspectFaces. Aplikace, kde jsou obě knihovny integrovány, je dostupná online2 . 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: 1 2

http://gruntjs.com http://showcase.aspectfaces.com

45

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ě

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 AspectFaces3 , 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

http://showcase.aspectfaces.com

48

KAPITOLA 6. TESTOVÁNÍ

• Editovat emailovou 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 emailové 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 emailovou adresu. Její reakce byla podle očekávání, ihned po zobrazení zprávy 6.5 vyplnila adresu správně a uložila ji.

6.3.1

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 2.2.

6.4

Integrační testování

Pro integrační testování byla použita aplikace Showcase AspectFaces4 . 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 Selenium5 . 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í. 4 5

http://showcase.aspectfaces.com http://docs.seleniumhq.org/projects/ide

6.5. VÝKONOVÉ TESTOVÁNÍ

(ms) Připojení Zpracování Čekání Celkem

49

min 1 0 0 3127

medián 1 3127 3126 3128

max 3222 3286 3286 3288

Tabulka 6.1: Testování výkonu PrimeFaces komponent (ms) Připojení Zpracování Čekání Celkem

min 1 0 0 3268

medián 540 3267 3267 3268

max 3269 3268 3267 3312

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 AspectFaces6 . Testovaná stránka obsahovala 18 formulářových prvků 6.7. Jako nástroj k testování byl vybrán Apache HTTP server benchmarking tool7 . 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 6 7

http://showcase.aspectfaces.com http://httpd.apache.org/docs/2.2/programs/ab.html

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ě, ...).

6.5. VÝKONOVÉ TESTOVÁNÍ

Obrázek 6.3: Obrazovka testovací aplikace - iPhone vertikálně

51

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é emailové adrese

6.5. VÝKONOVÉ TESTOVÁNÍ

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í

53

54

KAPITOLA 6. TESTOVÁNÍ

Kapitola 7

Závěr Diplomová práce splnila cíle, které si stanovila. V rámci této práce byla vytvořena knihovna TNT faces, která minimalizuje náklady při tvorbě klientské validace, která zlepšuje uživatelskou interakci se systémem. Její použití v JSF aplikacích umožní generování klientské validace bez nutnosti zásahu do původního kódu. Díky této jednoduchosti v integraci, lze knihovnu použít u nových tak i již existujících systémech. Součástí knihovny jsou i komponenty pro responzivní design. Tyto komponenty lze využít nejenom k prototypování, ale i vytvoření reálného webu. Responzivní komponenty optimalizují rozložení prvků na webové stránce podle velikosti obrazovky koncového zařízení. Uživatel mobilního zařízení s obrazovkou menší než běžný monitor, tak není nucen webovou stránku zvětšovat a je lépe schopen konzumovat její obsah. Tím je zjednodušen vývoj reponsivního webu v prostředí JSF. Komponenta pro inplace editaci umožňuje editovat daný text s maximálním přiblížením vzhledu v prohlížecím režimu. To zlepšuje uživatelský zážitek a stírá se tak rozdíl mezi prohlížením a administrací obsahu. Knihovna TNT faces byla uvolněna jako open-source kód pod svobodnou licencí1 . V současné době je knihovna nasazena do produkce webových stránek AspectFaces2 a Showcase AspectFaces3 . Byla kontaktována i komunita JBoss4 . Výkonové testování TNT faces dokázalo, že dynamické generování klientské validace nezatěžuje ani nezpomaluje aplikace v JSF. Tím se knihovna stává lehkým doplňkem a vývojáři se nemusejí bát její integrace.

7.1

Budoucí práce

Následující kroky povedou k vylepšení dokumentace a přidání dalších příkladů použití TNT faces. Dalším rozšířením bude automatické mapování typů vstupů na nativní datové typy v Javě, např. date. Inplace editor bude rozšířen o editaci Rich textu, může se jednat o WYSIWYG editor či značkovací jazyk Markdown. 1

https://github.com/LukasRychtecky/tnt http://aspectfaces.com 3 http://showcase.aspectfaces.com 4 https://community.jboss.org/thread/227852 2

55

56

KAPITOLA 7. ZÁVĚR

Literatura [1] AspectFaces documentation. http://wiki.codingcrayons.com/display/af/AspectFaces, stav z 25. 3. 2013. [2] Can I use. http://caniuse.com/#feat=form-validation, stav z 23. 3. 2013. [3] Testing. http://wiki.codingcrayons.com/display/af/AspectFaces, stav z 2. 6. 2013. [4] The JSF application lifecycle, . http://www.ibm.com/developerworks/library/j-jsf2/, stav z 22. 3. 2013. [5] JSF Architecture, . http://aragorn.pb.bialystok.pl/~dmalyszko/PSS_Project/JavaServer%20Faces.htm, stav z 22. 3. 2013. [6] BERNERS-LEE, R. T. C. Fragmented Future. http://www.w3.org/Proposal.html, stav z 23. 3. 2013. [7] CROCKFORD, D. An Inconvenient API: The Theory of the Dom. http://yuiblog.com/blog/2006/10/20/video-crockford-domtheory, stav z 22. 3. 2013. [8] CUTTS, M. .mobi versus m Subdomain for Your Mobile Website. http://notixtech.com/blog/mobi-versus-m-subdomain-your-mobile-website, stav z 29. 3. 2013. [9] D. F. FERRAIOLO, D. R. K. – CHANDRAMOULI, R. Role-Based Access Control. 1. : Artech House, Inc., 2003. [10] DINUCCI, D. Fragmented Future. http://darcyd.com/fragmented_future.pdf, stav z 23. 3. 2013. [11] ED BURNS, C. S. JavaServer Faces 2.0, The Complete Reference, ISBN-13: 9780071625098. 1. : Mc Graw Hill, 2009. [12] ELAM, K. Grid Systems: Principles of Organizing Type., ISBN 1-56898-465-0. 1. : New York: Princeton Architectural Press, 2004. [13] EMMANUEL BERNARD, S. P. JSR 303: Bean Validation. http://beanvalidation.org/1.0/spec,

57

58

LITERATURA

stav z 22. 4. 2013. [14] GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. 1. : Addison-Wesley, 1994. [15] MARTIN, F. Patterns of Enterprise Application Architecture. 1. : Addison-Wesley Longman Publishing Co., Inc., 2002. [16] MARTIN, F. GUI Architectures. http://martinfowler.com/eaaDev/uiArchs.html, stav z 22. 4. 2013. [17] MARTIN FOWLER, J. B. W. O. D. R. K. B. Refactoring: Improving the Design of Existing Code, ISBN-13: 978-0201485677. 1. : Addison-Wesley, 1999. [18] MICKLEY, G. Z. Stunning CSS3: A Project-based Guide to the Latest in CSS. : New Riders ISBN 978-0-321-72213-3. [19] POLACEK, J. What The Heck Is Responsive Web Design? http://johnpolacek.github.com/scrolldeck.js/decks/responsive, stav z 30. 3. 2013. [20] SHARP, R. What is a Polyfill? http://remysharp.com/2010/10/08/what-is-a-polyfill, stav z 5. 4. 2013. [21] SKRUPSKY N., B. P. H. T. V. V. N. Z. L. M. M. WAVES: Automatic Synthesis of Client-side Validation Code for Web Applications. 1. : ASE Science Journal, 2012. [22] TOXBOE, A. Inplace Editor. http://ui-patterns.com/patterns/InplaceEditor, stav z 4. 4. 2013. [23] ZELDMAN, J. Adapted, . http://simplebits.com/notebook/2011/08/19/adapted/, stav z 30. 3. 2013. [24] ZELDMAN, J. RESPONSIVE DESIGN. I DON’T THINK THAT WORD MEANS WHAT YOU THINK IT MEANS., ISSN 1534-0309, . http://www.zeldman.com/2011/07/06/, stav z 29. 3. 2013.

Kapitola 8

Seznam použitých zkratek AJAX Asynchronous JavaScript and XML BDD Behavior-driven development CSS Cascading Style Sheets DOM Document Object Model HTML HyperText Markup Language HTTP HyperText Transfer Protocol JAR Java Archive Java EE Java Enterprise Edition JPA Java Persistence API JS JavaScript JSF JavaServer Faces JSF UI JavaServer Faces User Interface MVC Model-View-Controller TDD Test-driven development UI User Interface URL Uniform Resource Locator XHTML Extensible HyperText Markup Language XML Extensible Markup Language

59

60

KAPITOLA 8. SEZNAM POUŽITÝCH ZKRATEK

Kapitola 9

Obsah přiloženého CD Na CD jsou umístěny tyto položky: • tnt - složka obsahující zdrojové kódy TNT faces • inplaceng - složka obsahující zdrojové kódy InplaceNG • dipl - složka obsahující text diplomové práce

61

62

KAPITOLA 9. OBSAH PŘILOŽENÉHO CD

Kapitola 10

Apendix A 10.1

Definice případů užití

Editace povinného nadpisu - U1 Cíl: Editovat povinný nadpis H1 Scénář: • Uživatel klikne na editační ikonku • Systém skryje původní text a zobrazí vstupní pole s textem, který bude mít stejnou velikost, barvu a pozadí jako text pro zobrazení. • Uživatel odešle obsah vstupního pole tlačítkem "OK" • Pokud je obsah vyplněný, zobrazí se během odesílání na server AJAX spinner, po uložení spinner zmizí a zobrazí se aktualizovaný nadpis • Jinak prohlížeč zobrazí validační zprávu, že je pole povinné a nedovolí odeslání obsahu Editace vstupního pole typu email - U2 Cíl: Editovat emailovou adresu Scénář: • Uživatel klikne na editační ikonku • Systém skryje původní adresu a zobrazí vstupní pole s adresou, která bude mít stejnou velikost, barvu a pozadí jako adresa pro zobrazení. • Uživatel odešle obsah vstupního pole tlačítkem "OK" • Pokud je obsah validní emailová adresa, zobrazí se během odesílání na server AJAX spinner, po uložení spinner zmizí a zobrazí se aktualizovaná adresa • Jinak prohlížeč zobrazí validační zprávu, že obsah není validní emailová adresa a nedovolí odeslání obsahu Navigování na stránku "Life cycle" - U3 Cíl: Přechod na stránku "Life cycle" Scénář:

63

64

KAPITOLA 10. APENDIX A

• Pokud není obrazovka zařízení širší než 320px, vybere uživatel stránku "Life cycle"ze seleckboxu • Jinak uživatel vybere stránku "Life cycle"z horizontálního menu a klikne na odkaz • Systém přesměruje na vybranou stránku Zobrazení nejnovějšího Tweetu - U4 Cíl: Uživatel úspěšně nalezne a otevře nejnovější Tweet Scénář: • Uživatel na koncovém zařízení s obrazovkou mezi 200px - 2500px nalezne sloupec s nejnovějším Tweetem a klikne na odkaz • Systém přesměruje na vybraný Tweet Editace vstupního pole omezení znaků - U5 Cíl: Editovat vstupní pole, které je omezeno na malé znaky anglické abecedy Scénář: • Uživatel klikne na editační ikonku • Systém skryje původní text a zobrazí vstupní pole s textem, který bude mít stejnou velikost, barvu a pozadí jako text pro zobrazení. • Uživatel odešle obsah vstupního pole tlačítkem "OK" • Pokud je obsah validní (malé znaky anglické abecedy), zobrazí se během odesílání na server AJAX spinner, po uložení spinner zmizí a zobrazí se aktualizovaný text • Jinak prohlížeč zobrazí validační zprávu, že obsah není validní a nedovolí odeslání obsahu