012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Vývoj e-learningové aplikace webu 2.0 s pomocí nástroje GWT ˇ B AKALÁ RSKÁ PRÁCE

Michal Meloun

Brno, podzim 2007

Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: RNDr. Tomáš Pitner, Ph.D. ii

Shrnutí Obsahem této práce je praktická ukázka vývoje webové aplikace pomocí nástroje GWT, vˇcetnˇe popisu použitých technologií. Výsledná aplikace je urˇcena pro vytváˇrení testu, ˚ které se skládají ze standardních testových otázek. Tyto testy jsou dále nabízeny k rˇ ešení ostatním uživatelum ˚ a vytvoˇrená aplikace podporuje služby obvyklé pro web 2.0. Kromˇe vývoje samotného a popisu použitých technologií je obsahem práce analýza systému, uživatelský návod a administrátorská pˇríruˇcka.

iii

Klíˇcová slova GWT, AJAX, webová aplikace, e-learning, web 2.0, MySQL

iv

Obsah 1

2

3

4

5

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Pˇredmˇet bakaláˇrské práce . . . . . . . . . . . . 1.2 Struktura . . . . . . . . . . . . . . . . . . . . . . 1.3 Duležité ˚ pojmy použité v práci . . . . . . . . . 1.3.1 AJAX . . . . . . . . . . . . . . . . . . . . 1.3.2 Web 2.0 . . . . . . . . . . . . . . . . . . . 1.3.3 E-learning . . . . . . . . . . . . . . . . . Technologie a prostˇredky použité k implementaci 2.1 Google Web Toolkit . . . . . . . . . . . . . . . . 2.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . 2.3 Apache Tomcat . . . . . . . . . . . . . . . . . . 2.4 IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . Analýza aplikace . . . . . . . . . . . . . . . . . . . . 3.1 Požadavky . . . . . . . . . . . . . . . . . . . . . 3.2 Tvorba a správa testu˚ . . . . . . . . . . . . . . . ˇ 3.3 Rešení testu˚ . . . . . . . . . . . . . . . . . . . . 3.4 Štítky . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Model užití aplikace . . . . . . . . . . . . . . . 3.6 Datový model . . . . . . . . . . . . . . . . . . . 3.6.1 Tabulka Categories . . . . . . . . . . . . 3.6.2 Tabulka Users . . . . . . . . . . . . . . . 3.6.3 Tabulka Tests . . . . . . . . . . . . . . . 3.6.4 Tabulka Questions . . . . . . . . . . . . 3.6.5 Tabulka Answers . . . . . . . . . . . . . 3.6.6 Tabulka Comments . . . . . . . . . . . . 3.7 Technické požadavky . . . . . . . . . . . . . . . Vývoj aplikace . . . . . . . . . . . . . . . . . . . . . 4.1 Struktura GWT projektu . . . . . . . . . . . . . 4.2 Klientská cˇ ást aplikace . . . . . . . . . . . . . . 4.2.1 Uživatelské rozhraní . . . . . . . . . . . 4.2.1.1 Rozvržení objektu˚ na stránce . 4.2.1.2 Internacionalizace . . . . . . . 4.2.2 Systém sekcí aplikace a správa historie 4.3 Data . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Volání aplikaˇcní logiky . . . . . . . . . . . . . . 4.4.1 Asynchronní komunikace . . . . . . . . 4.4.2 Definice služeb . . . . . . . . . . . . . . 4.4.3 Volání služeb na stranˇe klienta . . . . . 4.5 Zapojení aplikace . . . . . . . . . . . . . . . . . Uživatelská pˇríruˇcka . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 1 1 2 2 2 3 5 5 6 6 7 8 8 8 8 8 9 9 9 10 10 11 12 12 12 13 13 15 15 16 17 18 19 19 19 20 21 22 25 v

5.1 Registrace a pˇrihlášení uživatele 5.2 Tvorba a úprava testu˚ . . . . . . 5.3 Vyhledávání testu˚ . . . . . . . . . ˇ 5.4 Rešení testu . . . . . . . . . . . . 5.5 Export a import testu . . . . . . . 6 Administrátorská pˇríruˇcka . . . . . . 6.1 Vytvoˇrení databáze . . . . . . . . 6.2 Zapojení aplikace . . . . . . . . . 6.3 Správa aplikace . . . . . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . A Pˇríloha . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25 26 28 30 31 33 33 34 35 37 39 40

vi

Kapitola 1

Úvod 1.1

Pˇredmˇet bakaláˇrské práce

Cílem této práce je poskytnout praktickou ukázku, jak pomocí nástroje GWT (Google Web Toolkit) vyvíjet webovou aplikaci používající netriviální data, a vytvoˇrený produkt zdokumentovat. Webové aplikace jsou populární pˇredevším pro všudypˇrítomnost webového prohlížeˇce jako klienta a schopnost aktualizovat a spravovat je bez nutnosti šíˇrit a instalovat software na potenciálnˇe tisíce uživatelských poˇcítaˇcu. ˚ Doba, kdy byl web stavˇen pouze na statických HTML (Hypertext Markup Language) stránkách, je již minulostí a dnes existuje mnoho technik a technologií pro vývoj webových aplikací, které generují dynamicky sérii webových stránek ve standardním formátu HTML/XHTML (Extensible Hypertext Markup Language). Velmi cˇ asté je používaní skriptování na stranˇe klienta, zvláštˇe pro vytvoˇrení dojmu interaktivity bez nutnosti znovunaˇctení stránky, což rˇ ada uživatelu˚ shledává rušivým. V poslední dobˇe se zaˇcínají používat technologie, které umožnují ˇ spolupráci skriptu˚ na klientské stranˇe se serverovou cˇ ástí aplikace. Jedním z pˇríkladu˚ je AJAX (Asynchronous JavaScript and XML), což je technika vývoje webu využívající kombinaci HTML, JavaScriptu a rozhraní XMLHttpRequest, které umožnuje ˇ naˇcítat klientským skriptum ˚ informace ze serveru, aniž by bylo tˇreba obnovovat celou stránku. Tato technika bude níže podrobnˇeji popsána. Vývojáˇrský nástroj GWT usnadnuje ˇ vývoj webových aplikací postavených na výše zmínˇené technice AJAX. Byl uvolnˇen v kvˇetnu roku 2005 a existuje nemalé množství návodu˚ a ukázek, jak s ním pracovat. Vývoj je ve vˇetšinˇe pˇrípadu˚ demonstrován na pomˇernˇe triviálních aplikacích, což není vubec ˚ na škodu. Smyslem této práce je pokusit se pˇriblížit práci s GWT pˇri vývoji rozsáhlejšího projektu. Pro tento úˇcel bude vyvinuta aplikace eTesting sloužící pro podporu e-learningu a podporující služby obvyklé pro web 2.0.

1.2

Struktura

Práce je rozdˇelena do nˇekolika kapitol. V rámci úvodní kapitoly je, kromˇe tohoto úvodu a seznámení s použitými prostˇredky, struˇcnˇe popsáno pár pojmu, ˚ které souvisí s touto prací, a je potˇreba znát je pro orientaci v problematice. Druhá kapitola se zabývá podrobnˇejším popisem technologií, které byly použity pˇri vývoji a jsou nezbytné pro chod aplikace. Dále následuje kapitola vˇenující se analýze vyvíjené aplikace. Je zde popsáno, co se od ní oˇcekává, jakým zpusobem ˚ s ní budou uživatelé pracovat, jak bude aplikace ukádat data. Poté je pro1

˚ 1.3. D ULEŽITÉ POJMY POUŽITÉ V PRÁCI stor vˇenován samotnému vývoji. Tato cˇ ást je rozdˇelena do pˇeti podkapitol. První z nich se zabývá strukturou projektu. Smyslem druhé podkapitoly je seznámit se s prostˇredky, které nabízí GWT pro tvorbu klientské cˇ ásti aplikace. Další podkapitola se vˇenuje práci s daty. V následující cˇ ásti jsou popsány mechanizmy pro volání aplikaˇcní logiky, cˇ ili je zde pˇriblížena komunikace mezi klientskou cˇ ástí aplikace a serverem. Poslední z tˇechto podkapitol se zabývá zprovoznˇením aplikace na Java aplikaˇcním serveru. Obsahem zbylých dvou kapitol jsou informace pro uživatele a správce aplikace. Nutno poznamenat, že v rámci této práce nebudou podrobnˇe vysvˇetlovány základní principy fungování GWT, a proto k jejich plnému pochopení je vhodné si tyto principy nastudovat. Dostaˇcující muže ˚ být napˇríklad cˇ lánek1 od Romana Pichlíka, který byl publikován na serveru Interval.cz.

1.3

Duležité ˚ pojmy použité v práci

1.3.1

AJAX

Termín AJAX se poprvé veˇrejnˇe objevuje v dubnu roku 2005 v cˇ lánku Jasse Jamese Garreta nazvaném Ajax: A New Approach to Web Applications. Myšlenky, na kterých je AJAX založen, jsou však výraznˇe starší. AJAX není technologie sama o sobˇe, ale jedná se o termín, který popisuje nový pˇrístup k použití mnoha existujících technologií dohromady, vˇcetnˇe HTML cˇ i XHTML, CSS, JavaScriptu, DOM, XML, XSLT a XMLHttpRequest. Pomocí tˇechto technologií je možné inkrementálnˇe aktualizovat uživatelské rozhraní webové aplikace bez obnovování celé prohlížené stránky. Aplikace je pak rychlejší a lépe reaguje na aktivitu uživatelu. ˚ Mezi nevýhody patˇrí hlavnˇe zmˇeny v používání paradigmatu webu, nebot’ webové stránky se chovají jako plnohodnotné aplikace se složitou vnitˇrní logikou, nikoli jako posloupnost stránek, mezi kterými se lze navigovat pomocí tlaˇcítek Zpˇet a Další. Moderní aplikace založené na techince AJAX jsou však schopny funkce tˇechto tlaˇcítek obnovit za použití ruzných ˚ technik, jak bude i v této práci ukázáno. Problémem muže ˚ být i sít’ová latence. Pokud není uživateli jasnˇe signalizováno, že aplikace zpracovává jeho požadavek, pak jediné, co zaregistruje, je zpoždˇená reakce. Další nevýhodou je nutnost používat moderní grafické prohlížeˇce, které podporují potˇrebné technologie. V souˇcasné dobˇe je již k dispozici celá rˇ ada2 rozhraní pro programování aplikací, které jsou založeny právˇe na technice AJAX. 1.3.2

Web 2.0

Tento termín oznaˇcuje to, co nˇekteˇrí považují za další fázi vývoje webu, vˇcetnˇe jeho architektury a aplikací. Tˇežko popsat web 2.0 pˇresnou definicí, avšak tato další fáze rozvoje webu se vyznaˇcuje nˇekolika rysy. Jedná se o zmˇenu hypertextových stránek z izolovaných úložišt’ informací na zdroje obsahující informace i funkcionalitu, cˇ ímž se stávají platformou posky1. 2.

2

˚ 1.3. D ULEŽITÉ POJMY POUŽITÉ V PRÁCI

Obrázek 1.1: Porovnání modelu klasické webové aplikace s modelem webové aplikace založené na technice AJAX tující webové aplikace koncovému uživateli. Zárovenˇ jde o sociální fenomén, nebot’ tvorba a distribuce webového obsahu je dostupná komukoliv, komunikace je otevˇrená, panuje snaha o decentralizaci autorit, sdílení a znovuvyužití. Duležitým ˚ rysem je více organizovaný a setˇrídˇený obsah s propracovanˇejší hyperlinkovou strukturou. Je ale tˇreba upozornit, že se nejedná ani tak o revoluci, jako spíše evoluci, tedy postupný vývoj webu. 1.3.3

E-learning

Tento pojem oznaˇcuje vzdˇelávací proces využívající informaˇcní a komunikaˇcní technologie k tvorbˇe kursu, ˚ k distribuci studijního obsahu, komunikaci mezi studenty a pedagogy a k rˇ ízení studia. E-learning v sobˇe zahrnuje rˇ adu dílˇcích aktivit, které mohou být propojené do uceleného systému, ale také nemusejí. Muže ˚ se jednat o rozsáhlé kurzy plnˇe distanˇcního charakteru a propracované nástroje kolaborativního uˇcení, naopak ale muže ˚ jít jen o doplnˇení prezenˇcní výuky. Vhodných ICT (Information and Communication Technology) nástroju˚ je rˇ ada. Jmenovat lze napˇríklad vystavení studijních materiálu˚ na internetu nebo intranetu, nabídku k nim vztažených autotestu, ˚ komunikaci prostˇrednictvím diskusních fór, emailu˚ a dalších synchronních nebo asynchronních komunikaˇcních nástroju. ˚ Všechny uvedené ná3

˚ 1.3. D ULEŽITÉ POJMY POUŽITÉ V PRÁCI stroje je vhodné integrovat a pro tyto úˇcely proto slouží specializované aplikace pro rˇ ízení procesu vzdˇelávání. Tˇechto systému˚ je rˇ ada a kromˇe nˇekolika desítek nejznámˇejších existují stovky systému˚ s nejruznˇ ˚ ejším rozsahem.

4

Kapitola 2

Technologie a prostˇredky použité k implementaci 2.1

Google Web Toolkit

Již zadání této práce vyžaduje pro tvorbu aplikace použití nástroje GWT, jelikož smyslem práce je vývoj aplikace pomocí tohoto nástroje pˇriblížit. Konkrétnˇe byla využita verze 1.4.10 pro operaˇcní systém Windows, což však není podstatné. K dispozici jsou také verze pro operaˇcní systémy Mac OS a Linux. Jak bylo uvedeno v úvodu, Google Web Toolkit1 je vývojáˇrský nástroj, který usnadnuje ˇ vývoj webových aplikací postavených na technice AJAX. Jedná se o produkt s otevˇreným zdrojovým kódem od spoleˇcnosti Google Inc., uvolnˇený v kvˇetnu roku 2005. Výhoda tohoto nástroje spoˇcívá hlavnˇe v tom, že se snaží JavaScript nahradit jazykem Java úplnˇe, cˇ ili i na stranˇe klienta. Dynamickou cˇ ást aplikace je možno napsat v Javˇe a tento kód je poté GWT kompilátorem pro finální stránky pˇreložen do JavaScriptu. Toto nahrazení Javou je výhodné z hlediska vývoje, kdy se jedná o klasickou Java aplikaci, kterou je možno ladit a testovat. Emulace Java platformy pˇredstavuje jednak podporu syntaxe a konstruktu˚ jazyka na úrovni verze 1.4 a jednak cˇ ásti základního API (Application Programming Interface) z balíˇcku java.lang a java.util. Zmínˇené Java API, napˇríklad java.lang.String, je tedy reimplementováno v JavaScriptu. Díky tomu kód napsaný v Javˇe a pˇreložený do JavaScriptu muže ˚ bˇežet v prostˇredí prohlížeˇce. Duležité ˚ také je, že pˇri vývoji není nutné starat se o kompatibilitu mezi prohlížeˇci. Kompatibilní JavaScritptový kód generuje GWT kompilátor. Systém Google Web Toolkit se skládá celkem z pˇeti stavebních kamenu. ˚ Kromˇe zmínˇeného kompilátoru z jazyka Java do JavaScriptu a emulace Javy platformy mezi nˇe patˇrí: •

vlastní komponenty pro tvorbu uživatelského rozhraní

•

vývojový shell

•

zpusob ˚ asynchronní implementace vzdáleného volání

Dále GWT poskytuje další užiteˇcné funkce, které usnadnují ˇ tvorbu aplikací. Konkrétnˇe je vhodné zmínit tyto: • 1.

vlastní prostˇredky pro správu historie v aplikaci

5

2.2. MYSQL •

zpusob ˚ rˇ ešení internacionalizace

•

možnost skládání uživatelského rozhraní a stylování pomocí CSS

•

nástroje pro vygenerování kostry aplikace a projektových souboru˚ pro import do vývojového prostˇredí Eclipse

•

JUnit integraci

•

podporu rozhraní JSNI (JavaScript Native Interface)

Výhodou vývoje aplikací pomocí tohoto systému by mˇela být hlavnˇe jednoduchost a rychlost, kvalitní dokumentace, rostoucí komunita uživatelu, ˚ podpora od spoleˇcnosti Google a podpora Java platformy.

2.2

MySQL

Pro ukládání dat je použit databázový systém MySQL2 . Jedná se o produkt vytvoˇrený švédskou firmou MySQL AB a je považován za úspˇešného prukopníka ˚ dvojího licencování. K dispozici je jak pod bezplatnou licencí GPL (General Public Licence), tak pod komerˇcní placenou licencí. Komunikace s touto databází probíhá pomocí jazyka SQL, avšak podobnˇe jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s nˇekterými rozšíˇreními. Tento systém byl od poˇcátku optimalizován pˇredevším na rychlost, a to i za cenu nˇekterých zjednodušení. Má jen jednoduché zpusoby ˚ zálohování a donedávna nepodporoval pohledy, triggery a uložené procedury. Tyto vlastnosti jsou doplnovány ˇ teprve v posledních letech, kdy zaˇcaly nejˇcastˇejším uživatelum ˚ produktu již ponˇekud scházet. Pro potˇreby vyvíjené aplikace je však tento systém plnˇe dostaˇcující. Od verze 3.23.23 navíc tento databázový systém podporuje fulltextové vyhledávání, které bylo pro vyhledávání na základˇe štítku˚ v aplikaci použito.

2.3

Apache Tomcat

Apache Tomcat3 je relativnˇe jednoduchý Servlet/JSP (JavaServer Pages) kontejner, který ve verzi 5.5 implementuje specifikace Servlet 2.4 a specifikaci JSP 2.0. Obsahuje ještˇe další nástroje, které umožnují ˇ vývoj a nasazení webových aplikací a webových služeb. Urˇcitou zajímavostí muže ˚ být fakt, že Tomcat je referenˇcní implementací J2EE Servlet/JSP, což znamená, že pokud budou JSP stránky fungovat pod tímto serverem, budou fungovat také ve všech J2EE certifikovaných serverech na všech jejich platformách. 2. 3.

6

2.4. INTELLIJ IDEA

2.4

IntelliJ IDEA

Aplikace byla vyvíjena v prostˇredí IntelliJ IDEA 6.0 4 od spoleˇcnosti JetBrains. První verze tohoto vývojového prostˇredí byla uvolnˇena v lednu roku 2001 a brzy stala velmi populární. Jednalo se o první Java IDE (Integrated Development Environment) obsahující nástroje pro úpravu existujícího kódu za úˇcelem zvýšení jeho kvality, aniž by tím utrpˇelo jeho vnˇejši chování. IntelliJ IDEA je inteligentní vývojové prostˇredí, které se zamˇerˇ uje hlavnˇe na produktivitu programátora. Jedná se o velmi zdaˇrilý produkt a podstatný je fakt, že toto IDE poskytuje mnoho užiteˇcných nástroju˚ pro tvorbu GWT projektu˚ a celkovˇe vývoj znaˇcnˇe usnadnuje. ˇ Nevýhodou muže ˚ být skuteˇcnost, že IntelliJ IDEA není bezplatnˇe šíˇritelný produkt a nemusí být dostupný každému. Avšak ani pˇríznivci jiných vývojových prostˇredí nemusí být zklamáni, nebot’ již byly vytvoˇreny pˇrídavné moduly pro populární NetBeans i Eclipse. Konkrétnˇe se jedná o moduly gwt4nb5 a Cypal Studio for GWT6 .

4. 5. 6.

7

Kapitola 3

Analýza aplikace 3.1

Požadavky

Webová aplikace eTesting umožní uživatelum ˚ vytváˇret testy skládající se ze standardních testových otázek a jejich odpovˇedí. Takto vytvoˇrené testy budou poté volnˇe nabízeny k rˇ ešení dalším uživatelum. ˚ Tyto testy budou sloužit k procviˇcování látky z ruzných ˚ oboru. ˚ Nejedná se tedy o aplikaci, která by uchovávala rozsáhlé statistiky o bodových ziscích jednotlivých uživatelu˚ z jednotlivých testu, ˚ a už vubec ˚ nebude urˇcena k ostrému testování. Aplikace bude podporovat služby obvyklé pro Web 2.0.

3.2

Tvorba a správa testu˚

Možnost vytváˇret testy bude mít každý uživatel pˇrihlášený do systému, k cˇ emuž bude staˇcit vyplnˇení registraˇcního formuláˇre a samotné pˇrihlášení. Test bude uživatel vytváˇret pomocí formuláˇre, který bude k dispozici. Vytvoˇrený test se bude skládat z testových otázek. Každá testová otázka by mˇela obsahovat text otázky, možné odpovˇedi v textové formˇe a informaci o správné odpovˇedi, která bude vždy právˇe jedna. Systém hodnocení bude pro všechny testy shodný. Testy, které uživatel vytvoˇrí, bude mít možnost nadále upravovat. Dále bude možno testy exportovat a importovat ve formátu XML.

3.3

ˇ Rešení testu˚

Vytvoˇrené testy budou nabízeny k rˇ ešení všem uživatelum. ˚ Testy budou rozdˇeleny do kategorií, které budou v systému vytvoˇreny. Uživatel si bude moci nechat seˇradit testy dle ruzných ˚ kritérií. U každého testu bude uložen nejvyšší, nejnižší a prumˇ ˚ erný bodový zisk. Na základˇe tˇechto hodnot bude moci každý rˇ ešitel svuj ˚ bodový zisk porovnat. Bude-li se rˇ ešiteli testu zdát, že vyhodnocení otázky je chybné, bude mít možnost tuto otázku oznaˇcit jako chybnˇe zadanou. Mimoto bude umožnˇeno ohodnotit test známkou a pˇridat k nˇemu komentáˇr.

3.4

Štítky

V rámci vytváˇrení testu˚ bude možno každou otázku cˇ i celý test oznaˇcit pomocí štítku. ˚ Štítek je heslovitý údaj vztahující se k danému testu (dané otázce). Pomocí tˇechto štítku˚ bude 8

3.5. MODEL UŽITÍ APLIKACE možno testy i samotné otázky seskupovat. To umožní jednak tˇrídˇení testu˚ dle vybraných štítku, ˚ ale nabídne to i zajímavou možnost sestavit si test z otázek vybraných z ruzných ˚ testu˚ na základˇe vybraného štítku. Takto pak bude možné sestavit si test skládající se z otázek, které se budou vztahovat ke konkrétnˇejšímu tématu.

3.5

Model užití aplikace

Funkˇcní struktura aplikace je zobrazena na obrázku 3.1. Samotní uživatelé aplikace jsou zde dále rozdˇeleni do dvou skupin na uživatele pˇrihlášené do systému a uživatele nepˇrihlášené.

správce úkolem správce je aplikaci zprovoznit a spravovat data uložená v databázi

nepˇ rihlášený uživatel má pˇrístup ke všem testum, ˚ muže ˚ je rˇ ešit a hodnit, muže ˚ vyjádˇrit nesouhlas se zadáním otázky

pˇ rihlášený uživatel má stejná práva jako uživatel nepˇrihlášený, navíc muže ˚ k testum ˚ pˇridávat komentáˇre, vytváˇret a spravovat testy vlastní

3.6

Datový model

Pro zpusob ˚ ukládání dat je navržen jednoduchý datový model, který je popsán na obrázku 3.2. Je vhodné pozastavit se na tomto místˇe nad zpusobem ˚ ukládání štítku, ˚ které je v aplikaci možno pˇridat jednotlivým testum ˚ a otázkám. Seznam tˇechto štítku˚ je u testu (otázky) uložen jako textový rˇ etˇezec, kde jednotlivé štítky jsou oddˇeleny mezerou. Tento zpusob ˚ narušuje normalizaci databáze, avšak je vhodný pro implementaci fulltextového vyhledávání v MySQL databázi, proto jsou štítky v databázi ukládány právˇe tímto zpusobem. ˚ 3.6.1

Tabulka Categories

Tato tabulka slouží k ukládání kategorií, které jsou testum ˚ pˇriˇrazeny. Každému testu musí být pˇriˇrazena právˇe jedna kategorie. •

category_id jednoznaˇcný identifikátor kategorie

•

category_text název dané kategorie

9

3.6. DATOVÝ MODEL

Obrázek 3.1: Model užití aplikace 3.6.2

Tabulka Users

V této tabulce jsou uloženy uživatelé aplikace. •

user_id jednoznaˇcný identifikátor uživatele aplikace

•

name jméno daného uživatele

•

password heslo uživatele šifrované algoritmem MD5

•

email email daného uživatele

3.6.3

Tabulka Tests

V této tabulce se nachází informace o vytvoˇrených testech. •

test_id jednoznaˇcný identifikátor uloženého testu

•

category_id identifikaˇcní cˇ íslo kategorie, která je testu pˇriˇrazena

•

user_id identifikaˇcní cˇ íslo autora testu 10

3.6. DATOVÝ MODEL

Obrázek 3.2: Datový model aplikace •

name název daného testu

•

created datum uložení testu

•

tags rˇ etˇezec štítku˚ testu

•

max_score nejvyšší bodový zisk z daného testu

•

min_score nejnižší bodový zisk z daného testu

•

average_score datum uložení testu

•

solved_counter rˇ etˇezec štítku˚ testu

•

average_rating nejvyšší bodový zisk z daného testu

•

ratings_counter nejnižší bodový zisk z daného testu

3.6.4

Tabulka Questions

Tato tabulka je urˇcena k ukládání jednotlivých otázek z vytvoˇrených testu. ˚ •

question_id jednoznaˇcný identifikátor dané otázky

•

test_id identifikaˇcní cˇ íslo testu, do kterého otázka patˇrí

•

text text dané otázky 11

3.7. TECHNICKÉ POŽADAVKY •

tags rˇ etˇezec štítku˚ otázky

•

objections_counter hodnota udávající, kolik uživatelu˚ oznaˇcilo danou otázku jako chybnou

3.6.5

Tabulka Answers

V této tabulce se nachází odpovˇedi na uložené otázky. •

answer_id jednoznaˇcný identifikátor dané odpovˇedi

•

question_id identifikaˇcní cˇ íslo otázky, které odpovˇed’ patˇrí

•

text text dané odpovˇedi

•

correct identifikátor správnosti dané odpovˇedi

3.6.6

Tabulka Comments

Tato tabulka slouží pro ukládání komentáˇru, ˚ které jsou pˇridány jednotlivým testum. ˚ •

comment_id jednoznaˇcný identifikátor daného komentáˇre

•

test_id identifikaˇcní cˇ íslo testu, ke kterému byl komentáˇr pˇridán

•

user_id identifikaˇcní cˇ íslo autora komentáˇre

•

added datum vložení komentáˇre

•

text text daného komentáˇre

3.7

Technické požadavky

Vytvoˇrená aplikace bude pro svuj ˚ chod potˇrebovat podporu Javy na stranˇe serveru a databázový systém MySQL. Pro ukázku bude zprovoznˇena v servletovém kontejneru Apache Tomcat nainstalovaném na serveru kore.fi.muni.cz. Databáze se pak bude nacházet na serveru db.fi.muni.cz. Klientskou cˇ ást by dle autoru˚ GWT mˇelo být možno spustit ve vˇetšinˇe moderních internetových prohlížeˇcu˚ s aktivním JavaScriptem. Uvedena je konkrétnˇe podpora pro prohlížeˇce Firefox/Gecko, Windows Internet Explorer, Opera a Safari.

12

Kapitola 4

Vývoj aplikace 4.1

Struktura GWT projektu

Struktura vytváˇreného projektu dodržuje obecná pravidla. Duležité ˚ je, že je oddˇelena cˇ ást, která bude zprovoznˇena na stranˇe serveru, od cˇ ásti klientské. Tato základní struktura bývá zpravidla vygenerována pomocí nástroju˚ vývojového prostˇredí. Samotný Google Web Toolkit poskytuje efektivní nástroj applicationCreator pro vygenerování kostry aplikace, avšak vytváˇrení aplikací v moderním vývojovém prostˇredí usnadní mnoho zbyteˇcné práce. Základní rozdˇelení projektu vypadá takto: •

cz.muni.fi.xmeloun2.eTesting balík obsahující moduly definované v XML souborech a balíky nižší urovnˇe

•

cz.muni.fi.xmeloun2.eTesting.client balík, jehož obsahem jsou zdrojové soubory klientské cˇ ásti, a balíky nižší úrovnˇe

•

cz.muni.fi.xmeloun2.eTesting.server balík obsahující zdrojové soubory té cˇ ásti aplikace, která bude zprovoznˇena na stranˇe serveru, a balíky nižší úrovnˇe

Balík cz.muni.fi.xmeloun2.eTesting obsahuje právˇe jeden konfiguraˇcní XML soubor ETesting.gwt.xml popisující základní modul. V souboru jsou uvedeny tˇri moduly, ze kterých hlavní modul dˇedí, dále je zde nastavena cˇ eská lokalizace, nachází se zde definice zavádˇecí tˇrídy a koncových bodu˚ pro jednotlivé objekty vystavené pro vzdálené volání metod. Celý obsah tohoto souboru vypadá následovnˇe: <module> <extend-property name="locale" values="cs" />

13

4.1. STRUKTURA GWT PROJEKTU

<entry-point class=’cz.muni.fi.xmeloun2.eTesting.client.ETesting’/> <servlet path="/UsersService" class="cz.muni.fi.xmeloun2.eTesting.server.UsersServiceImpl"/> <servlet path="/TestsService" class="cz.muni.fi.xmeloun2.eTesting.server.TestsServiceImpl"/> <servlet path="/QuestionsService" class="cz.muni.fi.xmeloun2.eTesting.server.QuestionsServiceImpl"/>

Balík cz.muni.fi.xmeloun2.eTesting.public obsahuje zavádˇecí stránku, což je bˇežný soubor formátu HTML, který je zaveden pˇri spuštˇení aplikace. Obsahem souboru ETesting.html je, kromˇe bˇežného formátování HTML dokumentu, element pro pˇripojení GWT modulu a externího CSS souboru. V tˇele dokumentu lze nalézt volání zavádˇecího skriptu a iframe pro podporu historie v aplikaci. Vedle tohoto souboru se v balíku nachází soubor ETesting.css, ve kterém jsou definovány kaskádové styly, a složka s obrázky použitými v aplikaci. Celý obsah zavádˇecí stránky vytváˇrené aplikace vypadá takto: ..:: ETesting Application ::.. <meta name=’gwt:module’ content=’cz.muni.fi.xmeloun2.eTesting.ETesting’> <meta name="gwt:property" content="locale=cs"> <script language="javascript" src="gwt.js"> <iframe id="__gwt_historyFrame" style="width:0;height:0;border:0">

Balík nesoucí název cz.muni.fi.xmeloun2.eTesting.client obsahuje implementaci tˇrídy ETesting, která je vstupním bodem aplikace, což znamená, že je vyvolána pˇri spuštˇení aplikace. Tato tˇrída implementuje rozhraní EntryPoint obsahující jedinou metodu onModuleLoad(), ve které je popsáno, co se má vykonat v okamžiku spuštˇení. Dále se v klientské cˇ ásti nachází další balíky, jejichž obsah je struˇcnˇe následující: •

cz.muni.fi.xmeloun2.eTesting.client.bean balík obsahující tˇrídy dodržující konvence JavaBean

•

cz.muni.fi.xmeloun2.eTesting.client.section balík obsahující tˇrídy reprezentující jednotlivé sekce v aplikaci 14

ˇ 4.2. KLIENTSKÁ CÁST APLIKACE •

cz.muni.fi.xmeloun2.eTesting.client.service balík obsahující definice rozhraní objektu, ˚ které jsou volány na serveru, a k nim analogická rozhraní v asynchronním módu

•

cz.muni.fi.xmeloun2.eTesting.client.ui balík obsahující definice komponent uživatelského rozhraní

•

cz.muni.fi.xmeloun2.eTesting.client.util balík obsahující definice pomocných tˇríd

V balíku cz.muni.fi.xmeloun2.eTesting.client.server lze pak nalézt implementace rozhraní, které se nacházejí v balíku cz.muni.fi.xmeloun2.eTesting.client. service, pˇresnˇeji rˇ eˇceno jejich synchronních variant. Tento mechanizmus je popsán níže.

4.2

Klientská cˇ ást aplikace

4.2.1

Uživatelské rozhraní

Pro tvorbu uživatelského rozhraní nebyl použit žádný pomocný nástroj. Komponenty jsou definovány v patˇriˇcných tˇrídách a vizuálnˇe jsou upraveny pomocí kaskádových stylu˚ definovaných v souboru ETesting.css. Na uživatelské rozhraní aplikace byly kladeny hlavnˇe tyto požadavky: •

práce s aplikací by mˇela být snadná a intuitivní

•

oblast celé stránky by mˇela být pˇrehledná, vizuální zpracování spíše jednoduché

•

vstupní data by mˇela být rˇ ádnˇe kontrolována, aby nedošlo pozdˇeji ke kolizím

•

kontrola vstupních dat by mˇela probíhat na úrovni klienta a to ihned v okamžiku jejich zadávání, nikoliv pˇri odesílání na server (toto je rˇ ešeno pomocí patˇriˇcných validátoru˚ a naslouchaˇcu, ˚ nepˇrípustný formát textových rˇ etˇezcu˚ by nemˇelo být možno ke zpracování vubec ˚ odeslat)

•

vhodnˇe pˇriˇradit naslouchaˇce textovým polím a dalším komponentám, aby uživatel mohl potvrzovat zadaná data stiskem patˇriˇcné klávesy namísto stisknutím potˇrebného tlaˇcítka (vyplnování ˇ formuláˇru je poté rychlejší a pohodlnˇejší)

•

soubˇežnˇe s anglickou verzí aplikace by mˇela být vytváˇrena cˇ eská lokalizace

•

o veškerých chybách, které vzniknou na serveru a pˇri komunikaci s ním, by mˇel být uživatel informován (toto by mˇelo být rˇ ešeno informací v dialogovém oknˇe, které pˇrinejmenším informuje o vzniklé komplikaci)

15

ˇ 4.2. KLIENTSKÁ CÁST APLIKACE 4.2.1.1 Rozvržení objektu˚ na stránce Jelikož klientská cˇ ást aplikace je spouštˇena v oknˇe internetového prohlížeˇce, je potˇreba se tomuto faktu pˇrizpusobit. ˚ Problematika základního rozvržení objektu˚ je rˇ ešena v privátní metodˇe buildLayout() tˇrídy ETesting, která je vyvolána hned pˇri naˇctení zavádˇecí stránky. Je zde realizováno základní rozmístˇení jednotlivých panelu˚ a urˇcení jejich prostorových vlastností. Vizuální zpracování je doplnˇeno v patˇriˇcném souboru.

Obrázek 4.1: Rozvržení objektu˚ na stránce Stránka je rozdˇelena vertikálnˇe do dvou oblastí, kde pravá cˇ ást využívá jednu tˇretinu okna prohlížeˇce a obsahuje: •

panel s textovými poli pro pˇrihlašování uživatelu˚ do systému (obsah tohoto panelu je po pˇrihlášení uživatele pˇrestavˇen tak, že obsahuje informace o pˇrihlášeném uživateli a patˇriˇcné odkazy)

•

formuláˇr pro výbˇer parametru, ˚ na jejichž základˇe budou vyhledány testy

•

panel s textovým polem pro vyhledávání testu˚ na základˇe štítku˚ 16

ˇ 4.2. KLIENTSKÁ CÁST APLIKACE Tyto tˇri uvedené panely jsou definovány jako samostatné komponenty v balíku cz.muni. fi.xmeloun2.eTesting.client.ui (pro vytváˇrení nových komponent byla využita technika skládání již existjích komponent rozšíˇrením tˇrídy Composite). Panel pravý zabírá zbylé dvˇe tˇretiny oblasti stránky a obsahuje tyto komponenty: •

logo stránky

•

nadpis a popis aktuální sekce

•

panel, na kterém jsou zobrazovány obsahy jednotlivých sekcí

Jak již bylo pospáno, vizuální zpracování je v systému GWT ošetˇreno pomocí CSS. Každá základní komponenta má standardnˇe nadefinovanou tˇrídu, díky cˇ emuž je upravitelná právˇe pomocí kaskádových stylu. ˚ V rámci API je pak možné každé komponentˇe uživatelského rozhraní pˇriˇradit libovolnou CSS tˇrídu. Pˇri návrhu aplikace byla snaha pˇriˇrazovat vlastní styl vˇetšinˇe objektu, ˚ aby bylo možno v pˇrípadˇe potˇreby vizuální stránku jednotlivých komponent snadno upravit bez zasahování do samotného kódu a aby tato úprava nevyvolala více zmˇen, než-li je žádoucí. Naopak byla snaha spíše se vyhýbat úpravám stylu˚ na globální úrovni. Ve vˇetšinˇe tˇríd byla vytvoˇrena privátní metoda setStyleNames(), která pˇriˇradí patˇriˇcné styly všem objektum ˚ dané tˇrídy. V pˇrípadech, kdy byl pˇriˇrazován styl lokálním objektum, ˚ bylo samozˇrejmˇe potˇreba pˇriˇradit jej ihned v daném bloku. 4.2.1.2 Internacionalizace Internacionalizace je rˇ ešena obdobným zpusobem ˚ jako v jazyce Java. Základem lokalizace jsou soubory, ve kterých jsou pˇreložené texty, a Java rozhraní, které k nim umožnuje ˇ pˇrístup. Tyto soubory i rozhraní lze nalézt v balíku cz.muni.fi.xmeloun2.eTesting.client. ui.i18n. Pro pˇrístup k textum ˚ bylo konktrétnˇe vytvoˇreno rozhraní ETMessages, které obsahuje metody pro volání jednotlivých textu. ˚ Definované metody lze volat pomocí takto vytvoˇreného objektu: ETMessages messages = (ETMessages)GWT.create(ETMessages.class); String message = messages.getMessage();

Soubˇežnˇe s anglickou verzí byla vytváˇrena cˇ eská lokalizace. Anglické texty lze nalézt v souboru ETMessages.preperties a cˇ eskou variantu v souboru ETMessages_cs. properties. V rámci zavádˇecí stránky vytvoˇrené aplikace je definováno, že má být spuštˇena cˇ eská varianta. Toto lze zrušit odstranˇením elementu <meta name="gwt:property" content="locale=cs">

z hlaviˇcky HTML dokumentu. 17

ˇ 4.2. KLIENTSKÁ CÁST APLIKACE 4.2.2

Systém sekcí aplikace a správa historie

Systém GWT umožnuje ˇ rˇ ešit velice elegantní cestou problém všech aplikací, které jsou založeny na technice AJAX. Jedná se o navigaci pomocí tlaˇcítek Zpˇet a Další v internetovém prohlížeˇci. Vstupní tˇrída ETesting implementuje GWT rozhraní HistoryListener obsahující metodu onHistoryChanged(String historyToken). Obecnˇe je možné na každou zmˇenu stavu reagovat patˇriˇcným nastavením aplikace do daného stavu. Pˇrechod z jednoho stavu do druhého je rozlišen pomocí argumentu historyToken. Ve vytváˇrené aplikaci je zmˇena stavu reprezentována pˇrechodem do jiné sekce. Tˇrídy spojené se systémem sekcí jsou umístˇeny v balíku cz.muni.fi.xmeloun2.eTesting. client.section a pˇrechod mezi sekcemi v aplikace lze struˇcnˇe popsat následujícím zpu˚ sobem: 1. všechny sekce aplikace jsou potomkem abstraktní tˇrídy Section, musí v nich být tedy definovány abstraktní metody uvedené tˇrídy 2. sekce je popsána svým názvem a popisem (tyto údaje jsou uloženy ve statické tˇrídˇe SectionInfo tˇrídy Section) 3. každá sekce aplikace obsahuje statickou metodu init(), která ji inicializuje a vrátí informace o vytvoˇrené sekci 4. pˇri spuštˇení aplikace jsou všechny sekce inicializovány metodou loadSections(), která je definována ve tˇrídˇe ETesting, a jejich popisy jsou vloženy do seznamu sections 5. pokud dojde ke zmˇenˇe v historii aplikace, je argument historyToken rˇ ádnˇe zpracován (toto bude popsáno níže) a jeho cˇ ást urˇcující název sekce je porovnána s názvy sekcí, které jsou uloženy seznamu sections 6. je-li sekce v seznamu nalezena, obsah staré sekce je odebrán ze stránky a je vložen obsah sekce nové 7. pokud sekce v seznamu nalezena není, je zobrazena úvodní sekce (tento pˇrípad muže ˚ nastat, když uživatel upraví argument historyToken, který je pˇredáván v URL) K tomuto je tˇreba doplnit nˇekolik poznámek. Obsah sekcí je vytvoˇren pˇri spuštˇení aplikace, avšak bˇehem práce v sekci muže ˚ být její obsah pozmˇenˇen a je žádoucí, aby se sekce pˇrí pˇríštím zobrazení nacházela ve výchozím stavu. Každá sekce proto obsahuje metody onShow(String extraToken) a onHide(), ve kterých je urˇceno, co má být v sekci uvedeno pˇri jejím zobrazení a skrytí. Již bylo zmínˇeno, že argument historyToken je pˇri zobrazení sekce urˇcitým zpusobem ˚ zpracován. Duvod ˚ je ten, že nˇekteré sekce vyžadují další argumenty pro zobrazení svého obsahu. Jedná se napˇríklad o identifikaˇcní cˇ íslo testu, který má být zobrazen, nebo kritéria, 18

4.3. DATA na jejichž základˇe má být vypsán seznam testu. ˚ Argument historyToken je proto rozdˇelen na dvˇe cˇ ásti, které jsou od sebe oddˇeleny teˇckou. Text pˇred teˇckou urˇcuje název sekce, která má být zobrazena, a ve zbytku jsou uloženy další informace zpracované patˇriˇcnou sekcí. V pˇrípadech, kdy je tˇreba v druhé cˇ ásti uložit více údaju, ˚ jsou tyto argumenty oddˇeleny vlnkou. Celý rˇ etˇezec historyToken pak muže ˚ vypadat napˇríklad takto: testsOverview.Historie~created~DESC~1

ˇ Cást rˇ etezce nalézající se za teˇckou je pˇredána jako argument metodˇe onShow(String extraToken). Každá sekce si pak tento rˇ etˇezec zpracuje a v pˇrípadˇe, že neodpovídá požadovanému formátu, zobrazování sekce je pˇrerušeno a uživatel je o chybˇe informován. V této souvislosti je potˇreba zmínit problém, který se vyskytl po spuštˇení aplikace v nˇekterých prohlížeˇcích. Konkrétnˇe se jedná o internetové prohlížeˇce Mozilla 1.7.11 a Opera 9.02. Obsahuje-li argument historyToken cˇ eské znaky (konkrétnˇe se muže ˚ jednat o název kategorie, nebo štítek), prohlížeˇc ho nedokáže zpracovat. Z tohoto duvodu ˚ jsou výše zmínˇené programy v cˇ eském prostˇredí pro aplikaci nepoužitelné.

4.3

Data

Jak již bylo zmínˇeno, data jsou na stranˇe serveru ukládána do databáze MySQL dle datového modelu uvedeného výše. Na stranˇe klienta jsou pro nˇe definovány tˇrídy dodržující konvence JavaBean. Systém zasílání tˇechto objektu˚ na server a zpˇet bude popsán níže, avšak aby tyto objekty mohly být mezi klientem a serverem posílány, je tˇreba zmínit jejich serializaci. GWT podporuje v základu pouze malou množinu objektu˚ (napˇr. java.lang.String). Jelikož v aplikaci je potˇreba posílat vlastní objekty, musí být dodržena následující pravidla: •

objekt musí implementovat GWT rozhraní IsSerializable. Jedná se o rozhraní podobného typu, jako je rozhraní Serializable v jazyce Java

•

pokud je argumentem nebo návratovým typem kolekce, musí být uvedena typová javadoc anotace elementem @gwt.typeArgs v rozhraní, které ji definuje

•

všechny vnitˇrní objekty musí splnovat ˇ výše uvedené podmínky

Všechny tˇrídy v balíku cz.muni.fi.xmeloun2.eTesting.client.bean splnují ˇ výše uvedené podmínky a mohou být posílány mezi klientem a serverem. Pro vytvoˇrení tabulek v MySQL databázi je urˇcen skript, který je souˇcástí práce.

4.4

Volání aplikaˇcní logiky

4.4.1

Asynchronní komunikace

Klíˇcový rozdíl mezi aplikací, která je založena na technice AJAX, a tradiˇcní webovou aplikací je právˇe asynchronní zpusob ˚ komunikace. Tento zpusob ˚ umožnuje ˇ internetovému prohlížeˇci aktualizovat urˇcitou cˇ ást stránky, aniž by bylo zapotˇrebí aktualizovat stránku celou. 19

ˇ 4.4. VOLÁNÍ APLIKA CNÍ LOGIKY Stránka v prohlížeˇci se pak chová podobnˇe jako bˇežná aplikace a stává se více interaktivní. Z pohledu programátora se tato komunikace skládá ze dvou cˇ ástí: •

prohlížeˇcem je definován XMLHttpRequest objekt (pomocí JavaSriptu), který umožnuje ˇ webové stránce zaslat pomocí protokolu HTTP požadavek a obdržet odezvu na nˇej (na rozdíl od bˇežného požadavku toto volání nepozastaví chod prohlížeˇce v okamžiku cˇ ekání na odpovˇed’)

•

reakce na obdrženou odezvu

Nejdˇríve je tedy zavolána cˇ ást bˇežící na stranˇe serveru, poté se vyˇcká na odezvu a na základˇe této odezvy jsou vykonány patˇriˇcné akce na stranˇe klienta. Duležitou ˚ skuteˇcností je, že vše se odehrává na pozadí bez rušivého vyˇckávání a obnovení, jak tomu bˇežnˇe bývá pˇri zmˇenˇe obsahu stánky v prohlížeˇci. Aby výše zmínˇená komunikace mohla probíhat, je v GWT implementován mechanizmus vzdáleného volání metod. Tento mechanizmus je rˇ ízen strukturou nˇekolika rozhraní a je popsán na obrázku 4.2, vˇcetnˇe ilustrace rozložení vzdáleného volání na kód klientský a kód, který je zpracován na stranˇe serveru.

Obrázek 4.2: RPC model 4.4.2

Definice služeb

Ve vytváˇrené aplikaci jsou definovány tyto služby: 20

ˇ 4.4. VOLÁNÍ APLIKA CNÍ LOGIKY •

služba UsersService, ve které jsou definovány metody pro získávání potˇrebných informací o uživatelích systému a uživatelské relaci

•

služba TestsService, ve které jsou definovány metody pro získávání potˇrebných informací o testech v systému

•

služba QuestionsService, ve které jsou definovány metody pro získávání potˇrebných informací o otázkách v systému

Rozhraní tˇechto objektu˚ jsou definována v balíku cz.muni.fi.xmeloun2.eTesting. client.service, kde se nachází i analogická rozhraní v asynchronním módu. Na rozdíl od svých synchronních variant tyto metody nevrací žádnou hodnotu a jejich posledním parametrem je objekt typu AsyncCallback, jak systém GWT pˇredepisuje. Na stranˇe serveru (v balíku cz.muni.fi.xmeloun2.eTesting.server) se nalézají implementace tˇechto rozhraní. Úkolem vˇetšiny metod definovaných v tˇechto službách je naˇcíst požadovaná data z databáze, pˇrípadnˇe databázi patˇriˇcnˇe aktualizovat. Jelikož je žádoucí informovat uživatele o veškerých výjimkách vzniklých i na stranˇe serveru, jsou metody ve výše uvedených službách definovány tak, aby bylo možno informaci o vzniklé výjimce poslat do klientské cˇ ásti. Vznikne-li tedy na stranˇe serveru nežádoucí výjimka, celé volání skonˇcí neúspˇešnˇe vznikem výjimky typu SerializableException nebo výjimky, která ji rozšiˇruje. Tato situace je poté v klientské cˇ ásti na patˇriˇcném místˇe zpracována. Zmínˇená tˇrída SerializableException je nadtˇrídou všech výjimek, které vznikají pˇri RPC (Remote procedure calling), a v aplikaci jsou definovány dvˇe výjimky tuto tˇrídu rozšiˇrující. Konkrétnˇe se jedná o tyto dvˇe: •

výjimka UnauthorizedException, která vzniká v pˇrípadˇe neúspˇešné autorizace

•

výjimka TestException, která vzniká pokud se nepodaˇrí naˇcíst požadovaná data z databáze, pˇrípadnˇe data patˇriˇcným zpusobem ˚ aktualizovat

Cesty k definovaným rozhraním a jejich implementacím jsou uvedeny v souboru ETesting. gwt.xml pomocí patˇriˇcného elementu, jak je požadováno. 4.4.3

Volání služeb na stranˇe klienta

Obecný postup pˇri volání služby v systému GWT je ve struˇcnosti následující: 1. je tˇreba vytvoˇrit klientský proxy objekt implementující patˇriˇcné rozhraní 2. nastavit koncový bod, na kterém je vzdálená implementace vystavená 3. vytvoˇrit objekt pro zpracování výsledku volání 4. provést samotné volání 21

4.5. ZAPOJENÍ APLIKACE Tento postup aplikovaný vypadá následovnˇe (pro ukázku je uveden pˇríklad získání otázek z testu, který je urˇcen svým identifikaˇcním cˇ íslem): QuestionsServiceAsync questionsService = (QuestionsServiceAsync)GWT.create(QuestionsService.class); ServiceDefTarget endpoint = (ServiceDefTarget)questionsService; endpoint.setServiceEntryPoint("/QuestionsService"); AsyncCallback callback = new AsyncCallback() { public void onSuccess(Object result) { // zde je zpracován výsledek (v~tomto pˇ rípadˇ e seznam otázek) } public void onFailure(Throwable caught) { // zde je zpracována výjimka, která vznikla } }; questionsService.getQuestions(Integer testId, callback);

Aby nebylo nutné každé volání tímto zpusobem ˚ rozepisovat, jsou ve zdrojovém kódu vytvoˇreny tyto dvˇe pomucky: ˚ •

v definicích rozhraní služeb (v synchronních variantách) jsou vytvoˇreny statické tˇrídy, pomocí nichž lze zpˇrístupnit vytvoˇrený proxy objekt vˇcetnˇe nastaveného koncového bodu

•

v balíku cz.muni.fi.xmeloun2.eTesting.client.util je k dispozici abstraktní tˇrída ETAsyncCallback implementující rozhraní AsyncCallback, ve které je definována reakce na selhání pˇri komunikaci (konkrétnˇe je tato reakce popsána v metodˇe onFailure(Throwable caught)), nebot’ tato reakce je ve vˇetšinˇe pˇrípadu˚ stejná (na základˇe vzniklé výjimky je vypsáno chybové hlášení)

Pˇríklad uvedený výše muže ˚ být tedy ve zdrojovém kódu zapsán takto: QuestionsServiceAsync questionsService = QuestionsService.App.getInstance(); QuestionsService.getQuestions(testId, new ETAsyncCallback() { public void onSuccess(Object result) { // zde je zpracován výsledek } });

Tímto zpusobem ˚ je v aplikaci realizována vˇetšina volání. Pouze v pˇrípadˇe, kdy je tˇreba reagovat na selhání zvláštním zpusobem, ˚ nemá použití tˇrídy ETAsyncCallback smysl.

4.5

Zapojení aplikace

Pro ukázku je hotový produkt1 zprovoznˇen na aplikaˇcním serveru Tomcat. Zapojení GWT aplikace se obecnˇe skládá z tˇechto dvou základních kroku: ˚ 1.

22

4.5. ZAPOJENÍ APLIKACE •

získání potˇrebných souboru˚ a jejich umístˇení na server

•

upozornˇení serveru na veškeré jím vykonávané akce, které jsou volány z klientské cˇ ásti

První nezbytný krok je pˇreklad zdrojového kódu, což lze snadno realizovat napˇríklad pomocí patˇriˇcného tlaˇcítka v konzoli hostitelského módu. Vygenerované soubory je poté zapotˇrebí umístit na server, v pˇrípadˇe serveru Apache Tomcat do adresáˇre webapps, ve kterém je dále zapotˇrebí vytvoˇrit složku pro novˇe zapojovanou aplikaci. V této složce je nutno vytvoˇrit podadresáˇr WEB-INF/classes, do kterého budou umístˇeny všechny pˇreložené tˇrídy. Alternativnˇe lze pˇreložené tˇrídy vložit jako archiv formátu JAR do složky WEB-INF/lib, do které je potˇreba pˇridat všechny další použité knihovny, pˇrinejmenším pak knihovnu gwtservlet.jar. Po provedení výše uvedených kroku˚ je nezbytné definovat všechna volání serveru zpu˚ sobem srozumitelným pro webový server Tomcat. Konkrétnˇe je zapotˇrebí definovat tato volání jako servlety v souboru web.xml. Pro každý servlet definovaný v souboru ETesting.gwt.xml je nutné definovat elementy <servlet> a <servlet-mapping> v souboru web.xml. Obsah tohoto souboru vypadá takto: <web-app> <servlet> <servlet-name>UserService <servlet-class> cz.muni.fi.xmeloun2.eTesting.server.UserServiceImpl <servlet-mapping> <servlet-name>UserService /UserService <servlet> <servlet-name>TestsService <servlet-class> cz.muni.fi.xmeloun2.eTesting.server.TestsServiceImpl <servlet-mapping> <servlet-name>TestsService /TestsService <servlet> <servlet-name>QuestionsService <servlet-class> cz.muni.fi.xmeloun2.eTesting.server.QuestionsServiceImpl

23

4.5. ZAPOJENÍ APLIKACE <servlet-mapping> <servlet-name>QuestionsService /QuestionsService

Takto vytvoˇrený soubor musí být nakonec umístˇen do adresáˇre WEB-INF a aplikace by mˇela být pˇripravena ke spuštˇení.

24

Kapitola 5

Uživatelská pˇríruˇcka 5.1

Registrace a pˇrihlášení uživatele

Pro registraci nového uživatele je urˇcena sekce, do níž se lze dostat pomocí odkazu, který je umístˇen pod formuláˇrem pro pˇrihlášení uživatele. Jsou zde podrobnˇe popsána omezení, která jsou kladena na vstupní data. Konkrétnˇe se jedná o tyto omezení: •

délka uživatelského jména musí být v rozsahu tˇrí až dvaceti znaku, ˚ pˇriˇcemž mezery na zaˇcátku a konci rˇ etˇezce jsou odstranˇeny, což platí pro všechna další vstupní data

•

zadání emailu není povinné, nicménˇe pokud je zadán, délka rˇ etˇezce musí být v rozsahu tˇrí až padesáti znaku˚ (další podmínky nejsou na formát emailu kladeny)

•

délka hesla musí být v rozsahu pˇeti až patnácti znaku˚ (další podmínky nejsou na formát emailu kladeny)

•

zadané heslo je potˇreba ještˇe jednou vyplnit do posledního textového pole

Tlaˇcítko pro odeslání registraˇcního požadavku je zpoˇcátku neaktivní. Aktivním se stává až v okamžiku, kdy jsou splnˇeny výše uvedené podmínky. Po odeslání dat mohou nastat tˇri situace: •

selže komunikace se serverem, pˇrípadnˇe dojde k chybˇe na stranˇe serveru a uživateli je zobrazeno chybové hlášení (vˇcetnˇe informace o výjimce, která nastala)

•

vyplnˇené uživatelské jméno se již v databázi vyskytuje, registrace neprobˇehne a uživatel je o tomto faktu informován

•

registrace probˇehne úspˇešnˇe, uživatel je o tomto faktu informován a pˇresmˇerován do sekce s informacemi o novˇe vytvoˇreném uživateli

V pˇrípadˇe, že registrace probˇehne úspˇešnˇe, naskýtá se uživateli možnost pˇrihlášení do systému. Pro samotné pˇrihlášení staˇcí vyplnit pˇrihlašovací formuláˇr, který se nachází v pravém horním rohu stránky. Formát vstupních dat je opˇet kontrolován v okamžiku jejich zadávání. Zapotˇrebí je vyplnit uživatelské jméno a heslo. Zadávané textové rˇ etˇezce jsou kontrolovány na základˇe stejných podmínek jako pˇri registraci. Jsou-li vyplnˇené údaje ve správném formátu, aktivuje se tlaˇcítko pro jejich odeslání, stejnˇe jako u registraˇcního formuláˇre. Po odeslání dat mohou opˇet nastat tˇri situace: 25

˚ 5.2. TVORBA A ÚPRAVA TEST U •

dojde k selhání pˇri komunikaci se serverem, pˇrípadnˇe dojde k chybˇe na stranˇe serveru a uživateli je zobrazeno chybové hlášení (vˇcetnˇe informace o výjimce, která nastala)

•

zadané uživatelské heslo se neshoduje s heslem v databázi, o cˇ emž je uživatel informován

•

pˇrihlášení do systému probˇehne úspˇešnˇe, pˇrihlašovací formuláˇr je odebrán z panelu, na jeho místˇe je zobrazeno jméno pˇrihlášeného uživatele a patˇriˇcné odkazy (uživatel je pˇresmˇerován do úvodní sekce aplikace)

Pˇrihlašovací formuláˇr umožnuje, ˇ aby si prohlížeˇc zapamatoval uživatelovo jméno a heslo. To však platí pouze za pˇredpokladu, že prohlížeˇc podporuje soubory cookie. Trvanlivost uloženého cookie souboru je nastavena na dvacet dnu. ˚ V pˇrípadˇe úspˇešného pˇrihlášení bude uživateli umožnˇeno vykonávat tyto operace: •

pˇridat komentáˇr k vyhodnocenému testu

•

vytvoˇrit (importovat) nový test

•

upravit (odstranit) dˇríve vytvoˇrený test

Závˇerem je vhodné uvést pár slov k bezpeˇcnosti. Hesla jsou pˇred uložením do databáze zašifrována pomocí algoritmu MD51 , v otevˇreném tvaru tedy nejsou pˇrístupná. Samotná komunikace šifrována není.

5.2

Tvorba a úprava testu˚

Pokud je uživatel pˇrihlášen, je mu nabídnuta možnost vytváˇret testy a modifikovat ty, které již vytvoˇril dˇríve. Do sekce sloužící pro vytváˇrení testu˚ se lze dostat pomocí odkazu umístˇeného na panelu s informacemi o pˇrihlášeném uživateli. To samé platí pro modifikaci testu. ˚ Sekce pro vytvoˇrení nového testu obsahuje formuláˇr pro zadání základních atributu, ˚ formuláˇr pro vytvoˇrení otázky a seznam pˇridaných otázek. Zpoˇcátku je aktivní pouze první jmenovaný formuláˇr, do kterého je tˇreba zadat následující údaje: •

název testu, jehož délka musí být v rozmezí tˇrí až sedmdesáti znaku˚

•

výbˇer kategorie, pˇriˇcemž je zapotˇrebí vybrat tu vhodnou z nabízeného seznamu

•

seznam štítku˚ testu, ve kterém jsou jednotlivé štítky oddˇeleny mezerou a pro který platí následující omezení a doporuˇcení: –

1.

celý tento rˇ etˇezec smí obsahovat nejvýše 70 znaku˚ (jeho zadání není povinné)

26

˚ 5.2. TVORBA A ÚPRAVA TEST U –

štítek by mˇel obsahovat více než tˇri znaky

–

zakázány jsou znaky +(plus), -(mínus), ~(vlnka), a .(teˇcka)

Výše uvedená pravidla pro deklaraci štítku˚ se mohou jevit jako velmi omezující (nejvíce omezení na minimální délku jednoho štítku). Další nepˇríjemností je fakt, že existuje seznam anglických slov, která jsou pˇri vyhledávání ignorována. Všechny tyto nedostatky jsou dány zpusobem ˚ implementace vyhledávání štítku˚ v databázi a lze je rˇ ádnou úpravou databáze odstranit. V pˇríruˇcce pro administrátora aplikace je tato problematika zmínˇena, avšak nelze spoléhat, že bude databáze rˇ ádnˇe upravena, proto je vhodné rˇ ídit se výše popsanými pravidly. V okamžiku, kdy vyplnˇená data splnují ˇ výše uvedené podmínky, aktivuje se tlaˇcítko pro pˇridání testu do databáze. Jakmile uživatel toto tlaˇcítko stiskne, informace o testu se uloží, vyplnˇený formuláˇr se stane neaktivním a naopak je aktivován formuláˇr pro tvorbu otázek. V horším pˇrípadˇe muže ˚ nastat jedna z chyb, které jsou uvedeny na konci této kapitoly. Pokud vše dopadne dobˇre, je test v databázi uložen, avšak neobsahuje žádnou otázku. I v pˇrípadˇe, že uživatel práci ukonˇcí, zustane ˚ prázdný test uložen. Na konci sekce se nachází tlaˇcítko pro ukonˇcení tvorby testu, avšak není nezbytné jej pro ukonˇcení práce použít, nebot’ slouží pouze pro pˇresmˇerování do sekce, ve které jsou uvedeny informace o novˇe vytvoˇreném testu. Po pˇridání testu je z panelu odebráno tlaˇcítko urˇcené pro vytvoˇrení testu a na jeho místo je pˇridáno jiné, které slouží k úpravˇe atributu˚ testu. Po jeho stisku je formuláˇr opˇet aktivován a zadané údaje lze modifikovat. Tuto úpravu je opˇet potˇreba potvrdit. Pˇridávání otázek do testu je opˇet velmi snadné. Do pˇripraveného formuláˇre je zapotˇrebí vyplnit následujícím zpusobem ˚ tyto údaje: •

první musí být zadán text otázky (3-255 znaku) ˚

•

pomocí patˇriˇcného textového pole postupnˇe pˇridat odpovˇedi, které jsou po pˇridání zobrazeny ve formuláˇri (3-255 znaku) ˚

•

ze zadaných odpovˇedí vybrat jednu správnou

•

seznam štítku˚ testu, ve kterém jsou jednotlivé štítky oddˇeleny znakem mezera a pro který platí stejná omezení a doporuˇcení jako pro štítky testu˚

Jakmile jsou tyto údaje vyplnˇeny, je možno otázku odeslat. Muže ˚ se však ještˇe stát, že pˇridání nebude povoleno z tˇechto dvou možných duvod ˚ u: ˚ •

nebyla vybrána správná odpovˇed’

•

poˇcet odpovˇedí neodpovídá pˇredepsaným pravidlum ˚ (otázka musí obsahovat dvˇe až deset odpovˇedí)

Pokud jsou výše uvedené podmínky splnˇeny, otázka je do testu pˇridána a je zobrazena na panelu, který se nachází pod formuláˇrem pro pˇridávání otázek. V horším pˇrípadˇe muže ˚ 27

˚ 5.3. VYHLEDÁVÁNÍ TEST U opˇet nastat jedna ze situací, které jsou uvedeny na konci kapitoly. Otázky je možno z testu odebírat pomocí tlaˇcítka, které se nachází u každé zobrazené otázky. V systému je nastaveno, že test muže ˚ obsahovat nejvýše padesát otázek, proto se po pˇridání padesáté otázky stává formuláˇr neaktivní. Ve výše zmínˇených formuláˇrích jsou také k dispozici tlaˇcítka pro vymazání vyplnˇených údaju. ˚ Pokud tuto volbu využije uživatel pˇri tvorbˇe otázky, budou pouze vymazány vyplnˇené údaje. Pokud však využije tuto možnost ve formuláˇri, který je urˇcen pro tvorbu testu, bude test vymazán z databáze vˇcetnˇe již vytvoˇrených otázek. Na tuto skuteˇcnost je uživatel upozornˇen. Sekce pro úpravu již vytvoˇrených testu˚ je pouze rozšíˇrením výše popsané sekce pro tvorbu testu˚ nových. Pˇrednˇe je potˇreba vybrat test, který má být modifikován. Seznam vytvoˇrených testu˚ je uživateli zobrazen poté, co klikne na odkaz umístˇený taktéž na panelu s informacemi o pˇrihlášeném uživateli. Zde má uživatel pˇrehled o vytvoˇrených testech a kromˇe možností otevˇrít test pro úpravy muže ˚ test jednoduše z databáze odstranit. Pokud se rozhodne test modifikovat, bude pˇresmˇerován do sekce, která je témˇerˇ totožná se sekcí pro tvorbu testu nového. Rozdíl je ten, že formuláˇr pro zadání atributu˚ testu je neaktivní a údaje v nˇem jsou již vyplnˇeny. Stejnˇe jako u tvorby nového testu je zde možnost atributy opravit. Zárovenˇ jsou na patˇriˇcném panelu zobrazeny otázky, které již byly do testu pˇridány. Jinak zde lze pracovat stejným zpusobem, ˚ jako pˇri vytváˇrení testu nového. Na závˇer jsou zmínˇeny komplikace, ke kterým muže ˚ pˇri tvorbˇe nebo úpravˇe testu dojít: •

pˇridání nového testu nebo otázky není povoleno z duvodu ˚ neexistující uživatelské relace a je zapotˇrebí znovu se pˇrihlásit do systému (nejpravdˇepodobnˇejší pˇríˇcinou tohoto problému muže ˚ být fakt, že uživatel s aplikací delší dobu nepracoval)

•

pˇridání nového testu nebo otázky selže z duvodu ˚ chyby pˇri komunikaci se serverem, pˇrípadnˇe dojde k chybˇe na stranˇe serveru (o této chybˇe bude uživatel informován)

•

požadovaná data se nepodaˇrí zapsat do databáze, nebo se je nepodaˇrí naˇcíst (o této chybˇe bude uživatel informován)

5.3

Vyhledávání testu˚

Pˇri spuštˇení aplikace se uživateli na úvodní stránce vypíše seznam patnácti nejnovˇejších testu. ˚ S tímto seznamem již dále pracovat nelze. Testy lze dále vyhledávat v aplikaci dvˇema zpusoby. ˚ Je možno nechat si vypsat seznam testu˚ na základˇe požadovaných kritérií, nebo lze vyhledávat pomocí štítku, ˚ které jsou testum ˚ pˇriˇrazeny. Prostor bude vˇenován nejprve první variantˇe. Pro výbˇer kritérií, na jejichž základˇe mají být testy vypsány, slouží formuláˇr, který se nalézá v levé cˇ ásti stránky hned pod formuláˇrem pro pˇrihlášení do systému. Uživatel zde muže ˚ výpis testu˚ ovlivnit následujícím zpusobem: ˚ 28

˚ 5.3. VYHLEDÁVÁNÍ TEST U 1. lze vybrat kategorii, ze které mají být testy vybrány, pˇrípadnˇe vybrat možnost pro výpis všech testu˚ v databázi 2. je možno vybrat, na základˇe jakých kritérií budou testy seˇrazeny, konkrétnˇe lze testy seˇradit podle data pˇridání do systému, poˇctu rˇ ešitelu, ˚ nebo prumˇ ˚ erného hodnocení 3. zpusob ˚ seˇrazení (sestupnˇe nebo vzestupnˇe) Poté muže ˚ uživatel odeslat požadavek pro výpis testu. ˚ Po jeho odeslání nastane jedna z následujících situací: •

pˇri komunikaci se serverem, pˇrípadnˇe na stranˇe serveru dojde k chybˇe a uživatel je o této chybˇe informován

•

nepodaˇrí se rˇ ádnˇe naˇcíst požadovaná data z databáze a uživatel je na tuto skuteˇcnost upozornˇen

•

operace probˇehne úspˇešnˇe, avšak v databázi nejsou žádné testy splnující ˇ požadovaná kritéria a uživateli se místo seznamu testu˚ zobrazí vˇeta, která na tuto skuteˇcnost upozornuje ˇ

•

operace probˇehne úspˇešnˇe, požadované testy jsou nalezeny a vypsány

Na stránce muže ˚ být v jednu chvíli vypsáno nejvýše šestnáct testu. ˚ Pokud chce uživatel vypsat testy další, je zapotˇrebí kliknout na odkaz, který je umístˇen pod vypsanými testy. Stejnˇe tak se lze pˇresunout na výpis pˇredchozích testu, ˚ jsou-li nˇejaké. Tyto objekty se pod seznamem testu˚ objeví pouze v pˇrípadˇe, kdy mají smysl (jsou k dispozici další nebo pˇredchozí testy). Nad seznamem vypsaných testu˚ se dále nalézají odkazy, pomocí nichž je možno mˇenit kritéria pro rˇ azení a zpusob ˚ tohoto rˇ azení. Druhý zmínˇený zpusob ˚ je vyhledávání na základˇe pˇriˇrazených štítku. ˚ Pro tento úˇcel je vytvoˇren formuláˇr, který lze nalézt taktéž v pravé cˇ ásti stránky. Obsahuje pouze jedno textové pole a tlaˇcítko pro potvrzení. Do tohoto pole je zapotˇrebí zadat jeden nebo více štítku, ˚ na jejichž základˇe mají být vyhledány testy. Kromˇe obyˇcejného výˇctu hledaných štítku˚ lze použít pro vyhledávání tyto symboly: •

znak +(plus) pˇred štítkem, který oznamuje, že tento štítek musí být u testu uveden

•

znak -(mínus) pˇred štítkem, který oznamuje, že tento štítek nesmí být u testu uveden

•

kulaté závorky pro vytváˇrení složitˇejších výrazu, ˚ jako je napˇríklad tento rˇ etˇezec: +(historie dˇejiny) +Brno –Praha

Pokud není pˇred štítkem uveden žádný symbol, test nemusí být tímto štítkem oznaˇcen. Po odeslání požadavku pro vyhledání nastane jedna z tˇechto situací: •

pˇri komunikaci se serverem, pˇrípadnˇe na stranˇe serveru dojde k chybˇe a uživatel je o této chybˇe informován 29

ˇ 5.4. REŠENÍ TESTU •

nepodaˇrí se rˇ ádnˇe naˇcíst požadovaná data z databáze a uživatel je na tuto skuteˇcnost upozornˇen

•

operace probˇehne úspˇešnˇe, avšak v databázi nejsou žádné testy (otázky) splnující ˇ požadovaná kritéria (uživatel je pˇresmˇerován do patˇriˇcné sekce a místo seznamu testu˚ je zobrazena vˇeta, která na tuto skuteˇcnost upozornuje) ˇ

•

operace probˇehne úspˇešnˇe, uživatel je pˇresmˇerován do patˇriˇcné sekce, je vypsány informace o poˇctu nalezených otázek a požadované testy

Sekce, do které je uživatel pˇresmˇerován, je rozdˇelena do dvou oblastí. Nejdˇríve je zobrazena informace o poˇctu otázek, které odpovídají odeslanému požadavku, a pod touto informací se nalézá seznam vyhledaných testu. ˚ Kromˇe informace o poˇctu nalezených otázek lze pak v první cˇ ásti sekce nalézt tlaˇcítko pro sestavení testu z tˇechto otázek a možnost omezit jejich poˇcet v takto vytvoˇreném testu. Po stisknutí zmínˇeného tlaˇcítka je test sestaven a pro jeho rˇ ešení platí stejná pravidla jako pro rˇ ešení bˇežného testu (tato problematika je popsána v následující kapitole). Rozdíl je ten, že bodový zisk není možno porovnat, test nelze ohodnotit a k testu neexistují žádné komentáˇre. Možnost oznaˇcit otázku jako chybnou zde samozˇrejmˇe je. Seznam nalezených testu˚ je podobný tomu, který byl popsán výše. Opˇet je na jedné stránce možno zobrazit nejvýše šestnáct testu˚ a lze je dále rˇ adit dle nabízených kritérií.

5.4

ˇ Rešení testu

Rozhodne-li se uživatel urˇcitý test rˇ ešit, staˇcí kliknout na jeho název v nˇekteré ze sekcí aplikace. Nejdˇríve budou uživateli zobrazeny informace o testu, který si vybral. Pod tˇemito informacemi lze nalézt komentáˇre rˇ ešitelu. ˚ Pro spuštˇení testu je urˇceno tlaˇcítko na panelu s informacemi o daném testu. Po jeho stisknutí jsou vypsány otázky a uživatel muže ˚ zaškrtávat odpovˇedi. Správná je vždy právˇe jedna odpovˇed’, na otázky není nutné odpovídat. Je-li uživatel s rˇ ešením testu hotov, muže ˚ požádat o jeho vyhodnocení. Pro tento úˇcel je opˇet k dispozici tlaˇcítko, které se nalézá na panelu za poslední otázkou testu. V tomto okamžiku je vypoˇcítán bodový zisk uživatele a ten je zapoˇcítán do statistik rˇ ešeného testu. Pravidla pˇri vyhodnocování jsou následující: •

za oznaˇcení správné odpovˇedi jsou uživateli pˇripoˇcítány dva body

•

za oznaˇcení nesprávné odpovˇedi je uživateli odebrán bod

•

neoznaˇcí-li uživatel žádnou odpovˇed’, není mu žádný bod odeˇcten ani pˇriˇcten

Probˇehne-li vyhodnocení úspˇešnˇe, u jednotlivých otázek jsou vyznaˇceny vedle odpovˇedí rˇ ešitele odpovˇedi správné. Ke každé otázce je pˇridáno tlaˇcítko, pomocí kterého muže ˚ rˇ ešitel vyjádˇrit nesouhlas se správnou odpovˇedí. U každé testové otázky je vždy zobrazeno, kolik rˇ ešitelu˚ ji už takto oznaˇcilo. Dále je u každé otázky uveden bodový zisk, pˇrípadnˇe ztráta. Pod seznamem otázek se nachází panel, na kterém je uveden rˇ ešiteluv ˚ celkový bodový zisk 30

5.5. EXPORT A IMPORT TESTU a je porovnán s nejvyšším, nejnižším a prumˇ ˚ erným bodovým ziskem z rˇ ešeného testu. Vedle tˇechto informací zde má uživatel možnost vykonat následující operace: •

ohodnotit test na základˇe jeho kvalit známkou od jedné (nejhorší) do deseti (nejlepší)

•

pˇridat k testu komentáˇr (pro tuto operaci musí být uživatel pˇrihlášen)

Sekci lze poté opustit libovolným zpusobem. ˚ V pˇrípadˇe, že má uživatel zájem rˇ ešit test ještˇe jednou, muže ˚ použít funkci internetového prohlížeˇce pro aktualizaci stránky, cˇ ímž se test znovu spustí. Zde je tˇreba doplnit, že aplikace je v souˇcasné verzi navržena tak, aby veškeré otázky i odpovˇedi vypisovala stále ve stejném poˇradí. Na závˇer je opˇet vhodné zmínit komplikace, ke kterým by bˇehem provádˇení nˇekteré z výše uvedených operací mohlo dojít. Konkrétnˇe mohou nastat tyto: •

pˇri nˇekteré z operací se vyskytne chyba pˇri komunikaci se serverem, pˇrípadnˇe chyba na stranˇe serveru (o této skuteˇcností bude uživatel informován)

•

v databázi nebudou nalezena požadovaná data (muže ˚ se také ale stát, že test neobsahuje žádnou otázku, což není bráno jako chyba, pouze bude uživateli tento fakt oznámen)

•

v databázi nebudou nalezena požadovaná data (muže ˚ se také ale stát, že test neobsahuje žádnou otázku, což není bráno jako chyba, pouze bude uživateli tento fakt oznámen)

5.5

Export a import testu

Na panelu s podrobnými informacemi o vybraném testu se vedle tlaˇcítka pro jeho spuštˇení nalézá tlaˇcítko pro export testu ve formátu XML. V souˇcasné verzi probíhá export tak, že test ve formátu XML je vypsán na stránku, a to hned pod panel popisující test (panel s komentáˇri je tak posunut níže). Pro jeho uložení je tedy zapotˇrebí test ze stránky zkopírovat. Takto exportovaný test má následující podobu (uvedený test obsahuje jedinou otázku, která nabízí tˇri možné odpovˇedi): <prompt> text_otázky první_nesprávná_odpovˇ ed’

31

5.5. EXPORT A IMPORT TESTU druhá_nesprávná_odpovˇ ed’ správná_odpovˇ ed’

Pro import testu ve výše uvedeném formátu slouží formuláˇr, ke kterému se lze dostat pomocí patˇriˇcného odkazu umístˇeného na panelu s informacemi o pˇrihlášeném uživateli (je tedy zapotˇrebí být rˇ ádnˇe pˇrihlášen). Tento formuláˇr je složen pouze z textového pole pro vstupní test v patˇriˇcném formátu a tlaˇcítka pro potvrzení operace. Po zadání testu do zmínˇeného textového pole a stisku tlaˇcítka se aplikace pokusí test uložit. Po provedení této akce muže ˚ nastat jedna z tˇechto událostí: •

vložený text není ve správném formátu, test není uložen

•

pˇri komunikaci se serverem nebo na stranˇe serveru dojde k chybˇe

•

dojde k chybˇe pˇri pokusu o uložení testu do databáze

•

import testu není povolen z duvodu ˚ neexistující uživatelské relace a je zapotˇrebí znovu se pˇrihlásit do systému (nejpravdˇepodobnˇejší pˇríˇcinou tohoto problému muže ˚ být fakt, že uživatel s aplikací delší dobu nepracoval)

•

operace probˇehne úspˇešnˇe, test je uložen do databáze

V pˇrípadˇe neúspˇešného dokonˇcení operace bude uživatel informován o vzniklé chybˇe. Pokud se test podaˇrí uložit, bude v databázi evidován jako test vytvoˇrený uživatelem, který jej importoval.

32

Kapitola 6

Administrátorská pˇríruˇcka 6.1

Vytvoˇrení databáze

Jak již bylo v práci vícekrát zmínˇeno, data jsou ukládána v relaˇcní databázi MySQL. Pˇri instalaci aplikace je tedy potˇreba tuto databázi na vhodném místˇe vytvoˇrit. Pro správný chod aplikace je vyžadováno použití minimálnˇe verze MySQL 4.01. Duvod ˚ tohoto omezení byl již v práci také zmínˇen. Od uvedené verze je totiž možno v databázi implementovat fulltextové vyhledávání, které je v aplikaci použito. Pro podporu cˇ eských znaku˚ by mˇela databáze používat vhodnou znakovou sadu, napˇríklad latin2 nebo lépe UTF-8. Ke zmínˇenému systému fulltextového vyhledávání se váže nˇekolik dalších požadavku˚ na databázi. Pokud bude databázový systém ponechán ve svém výchozím nastavení, vyskytnou se pˇri vyhledávání testu˚ na základˇe požadovaných štítku˚ tyto komplikace: •

hledané slovo (štítek) musí obsahovat nejménˇe cˇ tyˇri znaky, kratší slova budou pˇri vyhledávání ignorována (existuje i omezení na maximální délku slova, které je dáno verzí použitého databázového systému MySQL)

•

je dán seznam slov definovaných v databázovém systému, která jsou pˇri vyhledávání ignorována (jedná se o nejˇcastˇeji používaná slova v anglickém jazyce)

•

vyskytne-li se v hledaném slovˇe nˇekterý z rˇ ídící znaku, ˚ výsledek hledání pravdˇepodobnˇe nebude odpovídat požadavku (jedná se napˇríklad o logické operátory použité pˇri vyhledávání)

Výše uvedená omezení lze odstranit, pokud máme k dispozici zdrojový kód MySQL databáze. Konkrétnˇe se jedná o tyto kroky: •

omezení na minimální a maximální délku vyhledávaných slov lze zmˇenit úpravou hodnot systémových promˇenných ft_min_word_len a ft_max_word_len (po provedení této zmˇeny je zapotˇrebí znovu spustit server, pˇrípadnˇe znovu vystavˇet indexy)

•

seznam slov ignorovaných pˇri vyhledávání lze upravit zmˇenou systémové promˇenné ft_stopword_file (po provedení této zmˇeny je zapotˇrebí znovu spustit server, pˇrípadnˇe znovu vystavˇet indexy) 33

6.2. ZAPOJENÍ APLIKACE •

rˇ ídící znaky používané pˇri vyhledávání lze upravit zmˇenou systémové promˇenné ft_boolean_syntax (tuto úpravu lze provést za chodu serveru, pˇrípadné vystavˇení indexu˚ není potˇreba)

Systém fulltextového vyhledávání v databázi MySQL je navržen pro nejvyšší efektivitu. Výše uvedené zmˇeny (snížení minimální délky vyhledávaných slov, zrušení seznamu ignorovaných slov) muže ˚ obecnˇe zpusobit ˚ snížení efektivity. V pˇrípadˇe vytvoˇrené aplikace se však nejedná o bˇežné vyhledávání slov v textu. Prohledávány jsou textové rˇ etˇezce obsahující seznam štítku, ˚ které jsou pˇriˇrazeny urˇcitému testu nebo otázce. Uvedené modifikace databáze jsou proto žádoucí. Podrobnˇejší postup modifikace databáze lze nalézt na domovských stránkách databázového systému MySQL1 . Pro vytvoˇrení tabulek v nové databázi je urˇcen pˇriložený skript. Schéma databáze kopíruje datový model uvedený v kapitole výše. Všechny vytvoˇrené tabulky jsou typu MyISAM, aby v nich bylo možno implementovat fulltextové vyhledávaní (prakticky je implementováno pouze v tabulkách Tests a Questions). Kromˇe vytvoˇrení tabulek je obsahem tohoto skriptu vložení jedné položky do tabulky pro kategorie testu. ˚ Vložení této položky je pro správný chod aplikace velmi duležité ˚ a je potˇreba, aby tato kategorie byla vložena jako první (její identifikaˇcní cˇ íslo bylo rovno jedné). Uvedenou kategorii bude moci uživatel pˇriˇradit vytváˇrenému testu, pokud nebude v nabídce žádná vhodná. Duležitˇ ˚ ejší je ale fakt, že tato kategorie bude pˇriˇrazena testu v pˇrípadˇe, že požadovaná kategorie nebude v databázi nalezena. Pˇri vytváˇrení testu uživatel vybírá ze seznamu dostupných kategorií, cˇ ili by tato situace nastat nemˇela, muže ˚ k ní však dojít napˇríklad v pˇrípadˇe importování testu. Název této kategorie je možno dle libosti upravit. Dále je žádoucí naplnit tabulku dalšími kategoriemi, které budou pˇri vytváˇrení testu nabízeny. Samotní uživatelé kategorie vytváˇret nemohou.

6.2

Zapojení aplikace

Obecný zpusob ˚ zapojení GWT aplikací je uveden v kapitole výše. Vytvoˇrený produkt je k dispozici v archivu ve formátu WAR (Web Archive). Aplikaci je tedy možno jednoduše zavést na server Tomcat pomocí programu Tomcat Manager2 . V pˇrípadˇe, že není podobný program k dispozici, je tˇreba umístit obsah archivu na server do patˇriˇcného adresáˇre. Pro chod aplikace je však zapotˇrebí definovat pˇrístup k vytvoˇrené databázi. Toto je realizováno v souboru context.xml, který lze nalézt ve zmínˇeném archivu v adresáˇri META-INF. Jeho obsah muže ˚ vypadat napˇríklad takto:

34

6.3. SPRÁVA APLIKACE maxActive="50" maxIdle="30" maxWait="10000" driverClassName="com.mysql.jdbc.Driver" username="uzivatel" password="heslo" url="jdbc:mysql://stroj/eTData"/>

Atributy uzivatel, heslo a url je samozˇrejmˇe nutné nahradit tak, aby odpovídaly požadavkum ˚ vytvoˇrené databáze. Pˇri zkušebním zapojení aplikace jsem se setkal s problémem, kdy se aplikaci nedaˇrilo rˇ ádným zpusobem ˚ zavést JDBC ovladaˇc, aˇckoliv soubor mysql-connector-java-5.0.7-bin.jar byl správnˇe umístˇen v adresáˇri WEB-INF/ lib. Tento problém byl vyˇrešen pˇresunutím archivu do adresáˇre $CATALINA_HOME/lib (u starších verzí serveru Tomcat je pro spoleˇcné knihovny urˇcen adresáˇr $CATALINA_HOME/ common/lib). Na jiný aplikaˇcní server než Tomcat jsem aplikaci zavést nezkoušel, avšak vˇerˇ ím, že by nemˇel být problém. O veškerých chybách, které vzniknou na stranˇe serveru nebo pˇri komunikaci s ním, by uživatel mˇel být rˇ ádnˇe informovnán, což napomáhá pˇri jejich odstranˇení.

6.3

Správa aplikace

V souˇcasné verzi nedisponuje aplikace žádným administrátorským rozhraním. Veškerá uložená data je nutno spravovat pomocí tabulek v databázi patˇriˇcnými pˇríkazy jazyka SQL (respektive dialektem tohoto jazyka pro databázový systém MySQL). Všechny tabulky vˇcetnˇe atributu˚ jsou popsány v kapitole zabývající se analýzou aplikace. Je zde k dispozici pomˇernˇe pˇrehledný datový model, který popisuje jednotlivé závislosti. Pro doplnˇení je vhodné upozornit na následující skuteˇcnosti: •

odstranˇení uživatele z databáze má za následek vymazání všech jeho testu˚ a komentáˇru˚ k testum ˚

•

po odstranˇení testu z databáze budou odstranˇeny veškeré otázky tomuto testu náležící a veškeré komentáˇre s tímto testem spojené

•

odstranˇení otázky má za následek smazání všech odpovˇedí na danou otázku

Díky výše uvedeným skuteˇcnostem muže ˚ správce aplikace patˇriˇcné objekty v pˇrípadˇe potˇreby jednoduše odstranit a není tˇreba se obávat, že v databázi zbyteˇcnˇe zustanou ˚ nepˇrístupné položky. Toto odstranˇení lze provést napˇríklad následujícím zpusobem ˚ (identifikaˇcní cˇ ísla uživatelu˚ a testu˚ lze v aplikaci snadno nalézt): mysql> DELETE FROM Tests WHERE test_id = 158;

Uživatelum ˚ aplikace je povoleno vytvoˇrit si svuj ˚ úˇcet, avšak v souˇcasné verzi jim není umožnˇeno tento úˇcet dále jakýmkoliv zpusobem ˚ upravovat. Ve zmínˇeném pˇrípadˇe bude zapotˇrebí kontaktovat správce aplikace, aby atributy rˇ ádnˇe upravil. Pokud uživatel napˇríklad 35

6.3. SPRÁVA APLIKACE zapomene heslo, bude muset správce kontaktovat a požádat ho o vytvoˇrení hesla nového. Nové heslo bude nucen správci sdˇelit a ten muže ˚ pak uživateluv ˚ uˇcet napˇríklad následujícím zpusobem ˚ upravit (v systému MySQL je k dispozici funkce MD5(’heslo’) pro šifrování textových rˇ etˇezcu˚ algoritmem MD5): mysql> UPDATE Users SET password = MD5(’nove_heslo’) WHERE user_id = 241;

Schéma databáze je velmi jednoduché, proto pˇri základních znalostech jazyka SQL lze uložená data pomˇernˇe snadno spravovat.

36

Kapitola 7

Závˇer V rámci této práce byla s pomocí nástroje GWT a dalších technologií navržena webová aplikace, jejímž úkolem je podpora e-learningových služeb. Aplikace konkrétnˇe umožnuje ˇ uživatelum ˚ pomocí pˇripravených formuláˇru˚ vytváˇret testy požadovaného formátu, tyto testy dále spravovat a nabízet je k rˇ ešení ostatním uživatelum. ˚ Kromˇe samotného rˇ ešení vytvorˇ ených testu˚ mohou rˇ ešitelé svuj ˚ výsledek porovnat s výsledkem prumˇ ˚ erným, nejvyšším a nejnižším. Dále je umožnˇeno pˇripojit k testu vlastní komentáˇr, test ohodnotit známkou a v pˇrípadˇe nesouhlasu s urˇcitou otázkou (její odpovˇedí) tento nesouhlas vyjádˇrit. Jednalo se prakticky o muj ˚ první návrh webové aplikace a mou první zkušenost s technikou AJAX. Z tohoto pohledu je vhodné poznamenat, že pˇri alesponˇ základních znalostech jazyka Java je GWT pro seznámení se s problematikou a první realizované projekty pomˇernˇe vhodný nástroj. V úvodní podkapitole vˇenující se GWT byly vyjmenovány výhody tohoto nástroje a po získaných zkušenostech mohu se všemi uvedenými fakty souhlasit. Zdá se, že uživatelská základna stále roste a GWT se tˇeší pomˇernˇe znaˇcné popularitˇe. K dispozici jsou stále nové knihovny a komponenty, které vývoj usnadnují. ˇ Nástroj je velmi vhodný pro rozsáhlejší rˇ ešení, a to hlavnˇe z duvodu ˚ celistvosti zdrojového kódu vytváˇrených systému, ˚ což má za následek jeho snadnˇejší údržbu a rozšiˇritelnost. GWT se naopak nejeví jako pˇríliš vhodný nástroj pro implementaci dílˇcích cˇ ástí vˇetších systému. ˚ Pro oživení webových prezentací, které jinak nepoužívají JavaScript, technikou AJAX bych, na základˇe informací z cˇ lánku od Jana Novotného1 , doporuˇcil spíše knihovnuDWT (Direct Web Remoting)2 . Nástroj GWT vyžaduje rˇ ešením vlastním stylem a za každou odchylku je ve vˇetšinˇe pˇrípadu˚ ˇ tˇreba zaplatit. Casto je zapotˇrebí použít vše nebo nic. Vytvoˇrená webová aplikace by dle mého soudu mohla najít své uplatnˇení v oblasti elearningu. V pˇredbˇežném zadání práce nebyly kladeny požadavky na její výslednou podobu. Myšlenka vytvoˇrit aplikaci právˇe v této podobˇe mne napadla mimo jiné na základˇe zadání domácích úkolu˚ v semináˇri z anglického jazyka. Úkolem každého studenta bylo sestavit nˇekolik testových otázek, které byly odevzdány vedoucímu semináˇre, ten z nich sestavil test a poskytl ho úˇcastníkum ˚ semináˇre. Zde jsem poznal, že vytváˇrení takových testu˚ muže ˚ být pro studium pˇrínosnˇejší než jejich samotné rˇ ešení. Mým cílem bylo tedy navrhnout systém, který umožní všem uživatelum ˚ tímto zpusobem ˚ vlastní testy jednoduše vytváˇret, a poskytne alesponˇ základní prostˇredky pro efektivní rˇ ešení testu. ˚ 1. 2.

37

ˇ 7. Z ÁV ER

Aplikace v souˇcasné podobˇe naplnuje ˇ to, co jsem od ní oˇcekával. Pˇresto by si dle mého soudu zasloužila nˇekterá další rozšíˇrení. Navrhoval bych nabídnout uživatelum ˚ více formátu˚ vytváˇrených testu, ˚ podporu standardu IMS QTI3 , usnadnit správu uživatelských úˇctu˚ nebo napˇríklad doplnit aplikaci o administrátorské rozhraní.

3.

38

Pˇríloha A

Pˇríloha Souˇcástí práce je pˇriložené CD, jehož obsahem je: •

zdrojový kód této práce ve formátu XML

•

tato práce ve formátu PDF

•

tato práce ve formátu HTML

•

tato práce ve formátu RTF

•

zdrojový kód aplikace, vˇcetnˇe skriptu˚ pro vytvoˇrení tabulek databáze

•

aplikace ve formátu WAR

39

Literatura [1] Chaganti, P.: GWT Java AJAX Programming, Pack Publishing Ltd., 2007. [2] Google Web Toolkit, Google Inc., . [3] Novotný, J.: Není AJAX jako AJAX - GWT vs. DWR, 2007, . [4] Pichlík, R.: Google Web Toolkit, Interval.cz, 2006, . [5] Rappin, N.: Build an Ajax application using Google Web Toolkit, Apache Derby, and Eclipse, IBM, 2006, .

40

012345

Recommend Documents