Návrh a tvorba webových aplikací s využitím WebML a ASP.NET

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Návrh a tvorba webových aplikací s využitím WebML a ASP.NET DIPLOMOVÁ PRÁCE

Jakub Faltýnek

Brno, 2011

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Mgr. Jan Konečný

ii

Poděkování Rád bych poděkoval Mgr. Janu Konečnému za ochotu vést moji diplomovou práci, vstřícnost při konzultacích a cenné rady, které mi při psaní práce pomohly. Dále bych chtěl poděkovat panu Danu Leteckému za bezplatné poskytnutí produktu DayPilot a firmě 3WPro za poskytnutí serveru pro vytvořenou aplikaci. V neposlední řadě patří dík mé manželce Veronice za trpělivost a podporu a také za vytvoření titulního obrázku aplikace.

iii

Shrnutí Obsahem této práce je popis některých současných technologií pro návrh a tvorbu webových aplikací. Důraz je kladen na metodiku WebML, novinky v CSS 3 a také na dotazovací jazyk LINQ, který je součástí ASP.NET. Následně je s využitím těchto technologií navržena a implementována webová aplikace pro plánování dětských táborů.

iv

Klíčová slova Webová aplikace, WebML, CSS 3, ASP.NET, dětský tábor

v

Obsah Úvod . . . . . . . . . . . . . . . . Web a webové aplikace . . . . . . . . . . 2.1 Historie . . . . . . . . . . . . . 2.2 Web 2.0 . . . . . . . . . . . . . 2.3 Webové aplikace . . . . . . . . . . 3 Návrh webových aplikací . . . . . . . . . 3.1 Specifikace požadavků . . . . . . . . 3.2 Metodiky pro návrh webových aplikací . . . 3.2.1 WebML . . . . . . . . . . . 3.2.1.1 Datový model . . . . . . 3.2.1.2 Kompozice webové aplikace . 3.2.1.3 Navigační model . . . . . 3.2.1.4 Současný stav metodiky WebML 3.2.2 UML . . . . . . . . . . . . 3.2.3 ERD . . . . . . . . . . . . 4 Technologie pro tvorbu webových aplikací . . . . 4.1 HTML . . . . . . . . . . . . . . 4.1.1 Historie a vývoj HTML . . . . . . 4.1.2 HTML 5 . . . . . . . . . . . 4.2 CSS . . . . . . . . . . . . . . . 4.2.1 Vývoj CSS . . . . . . . . . . 4.2.2 CSS 3 . . . . . . . . . . . 4.2.2.1 Pozadí, rámečky a text . . . 4.2.2.2 Přechody a animace . . . . 4.2.2.3 Selektory . . . . . . . 4.2.2.4 Další zajímavé novinky v CSS 3 4.3 JavaScript . . . . . . . . . . . . 4.4 AJAX . . . . . . . . . . . . . . 4.5 ASP.NET . . . . . . . . . . . . . 4.5.1 Výhody a vývoj ASP.NET . . . . . 4.5.2 LINQ . . . . . . . . . . . 4.6 Java EE . . . . . . . . . . . . . 4.7 Další současné technologie . . . . . . . 5 Webová aplikace pro plánování dětských táborů . . 5.1 Motivace . . . . . . . . . . . . . 5.2 Specifikace požadavků . . . . . . . . .

1 2

1

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3 5 5 6 7 9 9 11 11 12 14 18 20 20 22 23 23 23 24 25 25 26 26 31 32 33 34 35 36 36 37 40 41 42 42 43

OBSAH

5.3

5.4

5.2.1 Vyhodnocení dotazníků . . . . . . . . . 5.2.2 Požadované funkce . . . . . . . . . . Návrh aplikace . . . . . . . . . . . . . . 5.3.1 Diagram případů užití . . . . . . . . 5.3.2 Datový a hypertextový model metodiky WebML 5.3.3 Entitně-relační diagram . . . . . . . . Implementace aplikace . . . . . . . . . . . . 5.4.1 Použité technologie . . . . . . . . . . 5.4.2 Programování aplikace . . . . . . . . . 5.4.3 Struktura aplikace . . . . . . . . . . . 5.4.4 Použité knihovny . . . . . . . . . . . 5.4.5 Přenesení aplikace na server . . . . . . . 5.4.6 Stručný popis aplikace . . . . . . . . . Současný stav aplikace a možnosti vývoje do budoucna .

5.5 6 Závěr . . Literatura . . A Obsah CD

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

43 48 49 49 49 54 59 59 60 61 62 63 63 65 66 67 69

Kapitola 1

Úvod Webové aplikace v současnosti využívá k nejrůznějším účelům stále více lidí. Stávají se důležitými pomocníky v zaměstnání, nebo možností, jak naplnit volný čas. Jejich počet díky rostoucí popularitě rychle stoupá. Současně s tím se objevuje množství technologií pro vývoj těchto aplikací, takže každý tvůrce si dnes může vybrat nejvhodnější programovací jazyk a nástroje dle svých konkrétních potřeb. Zatímco některé technologie časem zapadnou a přestanou se využívat, jiné jsou na výsluní, stále se vyvíjí a přináší nové funkce, které mohou tvorbu aplikací ještě více zpříjemnit. V této práci jsou popsány některé z těchto technologií. Zahrnuty jsou jak metody pro návrh aplikací, tak možnosti, které má programátor při samotné tvorbě webové aplikace. Ačkoliv jsou již webové aplikace velmi rozšířené, existují stále oblasti, pro něž by určitě mělo smysl nějakou vytvořit, ale ještě se tak nestalo. Jednou z nich je problematika dětských táborů, konkrétně otázka plánování táborového programu. Tento úkol je totiž obvykle řešen skupinou vedoucích, která se často není schopna osobně scházet natolik často, aby mohl vzniknout kvalitní a propracovaný táborový program. Pomoci by mohla aplikace, která by umožňovala program plánovat, k níž by měli všichni vedoucí snadný přístup a kde by mohli také například sdílet své nápady a názory na vše, co se tábora týká. Proto je v praktické části práce taková aplikace navržena a vytvořena. První kapitolou práce je tento úvod. Druhá kapitola stručně popisuje, jak se vyvíjel web od samotných počátků až po současnost. Je zde definován pojem Web 2.0 nebo spíše vlastnosti, které jej charakterizují. V závěru kapitoly jsou popsány výhody a nevýhody webových aplikací a uvedeno několik příkladů v současnosti nejvyužívanějších aplikací. Třetí kapitola se věnuje metodám návrhu webových aplikací. Nejdříve jsou popsány možnosti, jak získat požadavky kladené na budoucí aplikaci. Poté následuje část věnující se metodám umožňujícím navrhnout aplikaci z různých hledisek. Podrobně je popsána metodika WebML, která pomocí speciálních modelů umožňuje navrhnout uživatelské rozhraní aplikace. Dále je zmíněn velmi známý modelovací jazyk UML. Velmi stručně je zde popsán diagram případů užití. V závěru kapitoly se ještě nachází část věnovaná entitně-relačnímu diagramu, který se využívá pro návrh databázové struktury aplikace. Obsahem čtvrté kapitoly je popis některých v současnosti využívaných technologií při programování webových aplikací. Nejprve je stručně popsána historie a vývoj jazyka HTML a novinky ve verzi HTML 5. Poté následuje část věnovaná CSS. Podrobně jsou zde popsány některé z novinek ve specifikaci CSS 3. Dále je pouze stručně zmíněn JavaScript a poté technologie AJAX, která právě JavaScriptu značně využívá. Podrobněji je potom popsán ASP.NET a především jeho součást LINQ, jež se využívá pro komunikaci aplikace s databází.

3

1. ÚVOD Na konci kapitoly je ještě uvedeno několik informací o Java EE a některých dalších technologiích pro tvorbu webových aplikací. Pátá kapitola je věnována webové aplikaci pro plánování dětských táborů. Nejprve jsou vyhodnoceny dotazníky, jež byly vyplněny vedoucími, kteří se táborů účastní a také je plánují. Poté následuje soupis požadavků na aplikaci. V další části věnující se návrhu aplikace jsou popsány vytvořené modely metodiky WebML, diagram případů užití a také entitně-relační diagram. Pak následují informace o použitých technologiích při implementaci aplikace a stručný popis samotného programování. V závěru je zmíněno, jak již byla aplikace do současné chvíle využita, a jsou nastíněny možností dalšího vývoje v budoucnu. Šestou a zároveň poslední kapitolou je závěr, v němž jsou shrnuty výsledky celé práce.

4

Kapitola 2

Web a webové aplikace V současné době si značná část společnosti ve vyspělých zemích světa dokáže jen stěží představit život bez Internetu. A počet lidí, kteří by možností, jež poskytuje, alespoň občas nevyužili, stále klesá. Nejvíce využívanou službou Internetu je bezesporu WWW (World Wide Web), pro niž se vžil zkrácený pojem web. V této kapitole je popsán vznik a vývoj webu, jeho současné rysy a možnosti, kam by se mohl do budoucna ubírat. Také je vysvětlen pojem webová aplikace a zmíněno několik příkladů v současnosti nejpopulárnějších webových aplikací.

2.1 Historie Internet začal vznikat jako armádní projekt USA v 70. letech minulého století. Cílem bylo vybudovat decentralizovanou síť, která bude schopna fungovat i v případě výpadku některého z uzlů. V roce 1969 tak vznikl ARPANET, síť, jež je považována za předchůdce dnešního Internetu. Pro přenos dat se začaly používat pakety. Od roku 1972 se začala vyvíjet rodina protokolů TCP/IP a v roce 1983 nahradila do té doby používaný protokol NCP. Díky tomu mohl vstoupit na scénu web. Základy webu položil Tim Berners-Lee, když v roce 1989 přišel s projektem vytvoření distribuovaného hypertextového systému. Je také autorem prvního internetového prohlížeče WorldWideWeb, později přejmenovaného na Nexus. Byl to první program, který nevyužíval jen File Transfer Protocol (FTP), ale i nově vytvořený Hypertext Transfer Protocol (HTTP). Od této chvíle se začal Internet i web rozšiřovat. A to tak, že již v roce 1996 měl asi 55 milionů uživatelů. V tomto období umožňoval web uživateli pouze čtení informací vložených na stránky jejich autorem. Pro tvorbu stránek se využíval jazyk HTML a CSS, později se přidal i JavaScript a Flash umožňující rozpohybování statických stránek. Lidem ovšem přestávalo stačit být pouze pasivními konzumenty informací a chtěli se sami podílet na vytváření obsahu webu, mít možnost bezprostředně reagovat na získané informace a komunikovat s ostatními lidmi připojenými k Internetu. Proto se začal web měnit, postupně se vyvinuly nové technologie, které všechny tyto věci umožnily. Objevily se také první webové aplikace, jež se staly alternativou k tradičním aplikacím instalovaným na osobních počítačích. Tyto nové vlastnosti a trendy se začaly souhrnně označovat jako Web 2.0. .

5

2. WEB A WEBOVÉ APLIKACE

2.2 Web 2.0 Definovat přesně pojem Web 2.0 je velmi obtížné, ne-li nemožné. Jedná se o termín, který v roce 2005 poprvé použil Tim O’Reilly na konferencích o moderním webu, které pořádal. Nejedná se o žádný pevně daný standard, ale spíše o nové metody tvorby internetových stránek, nově využívané technologie a nové způsoby využití webu. Zahrnuty jsou ale i technologie známé již několik let, které se ovšem začaly hojněji využívat až v poslední době. Než tedy popsat Web 2.0 jednou větou, je lepší vysvětlit tento pojem pomocí znaků, o kterých se v souvislosti s ním hovoří. Mezi nejčastěji zmiňované patří: 

princip „many-to-many“ – označení pro typ komunikace na internetu. Na rozdíl od způsobu one-to-one, kdy se mezi sebou baví dva jednotlivci, a one-to-many, kdy jeden člověk sděluje informace mnoha jiným, umožňuje tento přístup tvořit informace všem uživatelům a vzájemně je sdílet a doplňovat.



kolektivní inteligence – souvisí s předchozím principem, přidáváním informací od mnoha jedinců vzniká směs znalostí velké skupiny. Nevýhodou je množství nepřesných, či úplně nesmyslných informací, které jsou spolu s kvalitními produkovány, a které poté nemusí být snadné od sebe rozpoznat.



reputační systémy – napomáhají rozlišovat kvalitu nejrůznějších produktů, společností, či informací. Uživatel má možnost hodnotit zakoupené zboží, prodejce, u kterého nakupoval, nebo například příspěvky ostatních uživatelů v diskuzích. Systémy mohou mít i dvě úrovně, kdy je možné známkovat hodnotící uživatele a určit tak, čí hodnocení má největší váhu.



wiki systémy – umožňují rychlé a snadné vytváření a úpravu stránek. Přidávat či editovat obsah může často každý návštěvník stránek, někdy je možnost omezená pouze pro registrované uživatele. Nejznámějším a nejrozsáhlejším systémem je encyklopedie Wikipedia. V současnosti existují desítky různých wiki systémů, jež jsou využívané mnoha společnostmi i jednotlivci v nejrůznějších oblastech.



grafika – je důležitou součástí moderních webových aplikací a někdy i rozhodujícím faktorem pro uživatele při volbě mezi několika možnostmi. Design má být jednoduchý a přehledný. Mezi nejvíce využívané prvky se řadí výrazné logo, jednoduchá navigace, syté barvy či plastické plochy.

Pro Web 2.0 je také charakteristický neustálý vývoj a změna. Stejně rychle se může dobrý nápad rozšířit mezi miliony uživatelů, jako se do té doby úspěšná společnost propadnout až na dno popularity.

6

2. WEB A WEBOVÉ APLIKACE Již dnes se občas objevují pojmy Web 3.0 i 4.0, jež označují směr, kterým by se mohl web i internet celý do budoucna ubírat. Mezi nejčastěji skloňované termíny patří „sémantický web“, jenž označuje web neobsahující pouze data, ale i jejich význam, což by mohlo napomoci strojovému čtení a zpracování informací. Od toho by již nemuselo být daleko k umělé inteligenci využívané na internetu. Až budoucnost však ukáže, zda jsou tyto předpoklady pravdivé, nebo se dočkáme něčeho naprosto jiného.

2.3 Webové aplikace Za webovou aplikaci považujeme aplikaci běžící na serveru, s níž uživatel komunikuje pomocí klienta na svém počítači, kterým je nejčastěji webový prohlížeč. Ten sám o sobě nezná logiku aplikace, a proto se pro něj užívá označení tenký klient. V poslední době se webové aplikace těší stále větší popularitě. K jejich největším výhodám patří možnost aktualizace a spravování aplikací bez nutnosti stahování a instalace softwaru na osobní počítače uživatelů, existence pouze jedné verze aplikace, dostupnost odkudkoli, fungování bez ohledu na používaný operační systém, dostačující pro práci je webový prohlížeč. Nevýhodou může být nedostupnost některých funkcí běžně známých z desktopových aplikací, jako je technika drag and drop. Webový prohlížeč totiž zobrazuje pouze webové stránky dynamicky generované webovou aplikací na serveru, které bez použití dalších technologií nemohou poskytnout stejné možnosti jako desktopové aplikace. K odstranění těchto omezení se využívá skriptování na straně klienta pomocí skriptovacího jazyka JavaScript. Ten umožňuje přidávání nejrůznějších dynamických prvků do statických stránek. Je také využíván technologií AJAX, díky které je možné načíst informace ze serveru bez nutnosti obnovování celé stránky. Další nevýhodou jsou odlišné implementace HTML a CSS v jednotlivých prohlížečích, které přidávají práci tvůrcům aplikací při snaze o stejný vzhled bez ohledu na prohlížeč. Tento problém se někdy řeší použitím technologií Adobe Flash či Java appletů, které je však třeba pomocí zásuvných modulů doinstalovat do webových prohlížečů. Výhody nicméně nad nevýhodami převažují, a proto se setkáváme s webovými aplikacemi na internetu čím dál častěji. Mezi typické a hojně využívané představitele se řadí: 

Google Docs, Microsoft Office Web Apps – online balíky kancelářských aplikací, které jsou v mnoha případech plnohodnotnou náhradou za desktopové varianty. Umožňují snadné sdílení vytvořených dokumentů s ostatními uživateli, export do klasických formátů, či propojení s dalšími webovými aplikacemi (v případě společnosti Google), jako jsou Gmail či Google Calendar.



Google Maps, Seznam Mapy.cz – podrobné online atlasy celého světa (v případě Mapy.cz především České republiky), umožňující plánování tras, zjištění informací

7

2. WEB A WEBOVÉ APLIKACE o místech na daných adresách, vkládání a prohlížení fotek ve vyhledaných lokalitách. Často bývají využívány v jiných aplikacích a jsou nad nimi budovány další vrstvy poskytující nové typy informací. 

YouTube – největší aplikace na internetu umožňující sledování, nahrávání a sdílení videí. Je založena na technologii Adobe Flash. Existuje spousta alternativ (z českých např. Stream.cz), avšak YouTube se budou vyrovnávat stěží.



Facebook – v současnosti největší sociální síť na internetu s více než 500 miliony aktivních uživatelů obsahující v sobě množství aplikací pro komunikaci, zábavu či sdílení multimediálních dat. Z pohledu rychlého vývoje a popularizace je typickým příkladem Web 2.0 aplikace.

Výčet aplikací by mohl být mnohem širší, nicméně pro ukázku byly zmíněny jen ty nejpopulárnější a nejrozšířenější. Jak je tedy vidět, webové aplikace se dostávají v některých případech na stejnou úroveň jako jejich desktopové protějšky, a proto je jim třeba věnovat odpovídající úsilí ve všech fázích vývoje od shromažďování požadavků až po samotnou implementaci. Těmito etapami se zabývají následující kapitoly.

8

Kapitola 3

Návrh webových aplikací Na samotném počátku každé aplikace se nachází myšlenka či nějaký nápad. Ne vždy je ale přínosné snažit se takovou myšlenku ihned transformovat v aplikaci. Je docela možné, že podobný nápad už měl někdo dříve a taková aplikace již existuje. Pak je často mnohem výhodnější používat již existující aplikaci namísto vyvíjení zbrusu nové, která bude mít stejný účel. Další otázka, kterou je dobré si položit, se týká využití aplikace. Bude aplikace užitečná pouze pro mě nebo i pro další lidi? Usnadní skutečně to, k čemu bude vytvořena, nebo existuje jiný způsob, který je efektivnější a finančně méně náročný než vývoj a údržba aplikace? Jestliže se i po zodpovězení těchto otázek jeví nápad jako hodný realizace, je možné přistoupit k první větší oblasti vývoje aplikace, kterou je specifikace požadavků a poté návrh samotné aplikace.

3.1 Specifikace požadavků Výběr metody zjišťování požadavků na budoucí aplikaci se odvíjí od toho, kdo požaduje vývoj dané aplikace a kdo ji poté bude využívat. Jinak je tomu v případě vývoje aplikace pro cizí osobu či společnost a jinak v situaci, kdy člověk realizuje sám vlastní nápad v oblasti, které dobře rozumí. Pro sběr požadavků se nejčastěji používají tyto metody: 

Interview – nejčastější metoda, obzvláště v případě tvorby aplikace na zakázku. Tvůrce aplikace často není orientován v oblasti, v níž se pohybuje zákazník, proto ji musí nejdříve pochopit. K tomu je velmi výhodné využít právě interview. Je možné zeptat se zákazníka na cokoliv nejasného a porozumět tak všemu podstatnému. Důležité je provést interview s více zaměstnanci na různých pozicích v dané společnosti, aby byly získané informace a požadavky co nejkomplexnější. Tazatel musí být schopen pokládat vhodné dotazy, ze kterých je poté možné vyvodit potřebné závěry. Musí také působit příjemným dojmem a důvěryhodně, aby mu byli všichni dotazovaní ochotni povědět všechny potřebné informace. Výhodami interview jsou množství a kvalita získaných informací v případě kvalitního tazatele i respondenta a také adaptabilita, tedy možnost zavést rozhovor kamkoli je v dané situaci třeba. Nevýhodou jsou naopak vysoké nároky na kvalitu tazatele a také časová náročnost, takže je možné pracovat pouze s omezeným počtem respondentů.

9

3. NÁVRH WEBOVÝCH APLIKACÍ o Strukturované interview – typ interview, kdy jsou již otázky předem připraveny a respondent na ně postupně odpovídá. Výhodou je menší závislost na tazateli, neopomenou se důležité věci a je možné připravit promyšlené dotazy. o Skupinové interview – v jednu chvíli je přítomno více respondentů. Přínosem je možnost získání většího množství informací, vzájemné doplňování a rozšiřování odpovědí. Problémem ale mohou být osoby, které nejsou ochotné pustit jiné ke slovu a naopak také ty, které mají obavu vyslovit svůj názor. Proto jsou zde schopnosti tazatele ještě důležitější než u klasického interview. 

Dotazníky – metoda, kterou je možné pomocí vhodně volených otázek dobře ověřit, zda o aplikaci budou mít uživatelé zájem nebo jestli již používají něco podobného. Dá se také například zjistit, jaké funkce aplikace by nejčastěji využívali. Tato metoda se tedy hodí v situaci, kdy tvůrce vyvíjí aplikaci na základě vlastního nápadu, je tedy v oblasti, pro niž je aplikace určena, orientován, a proto potřebuje hlavně zjistit, jestli se požadavky potencionálních uživatelů aplikace shodují s těmi jeho, nebo mají uživatelé nějaké další, nad kterými neuvažoval. Může také zjistit, jací uživatelé by aplikaci hlavně využívali a na základě toho také aplikaci přizpůsobit. Při tvorbě dotazníku je třeba důsledně promyslet všechny otázky. Vždy musí být jasné, na co se otázka ptá, aby mohl respondent poskytnut přesnou odpověď. Je třeba volit otázky tak, aby se z odpovědí daly získat všechny potřebné informace, ale zároveň nesmí být otázek příliš mnoho, neboť by to mohlo respondenta odradit od vyplnění, případně by již nebyl schopen se dostatečně na vyplňování soustředit.



Sledování pracovního procesu u zákazníka – méně častá metoda, kdy tvůrce aplikace sleduje přímo procesy probíhající u zákazníka a na základě vlastních pozorování, pak sepisuje požadavky na aplikaci. Tuto metodu je vhodné použít spíše jako doplněk k interview než jako samostatný způsob sběru informací.



Studium existujících aplikací – využívá se v případě, že již existuje aplikace s podobnými funkcemi či účelem. Je dobré všechny takové aplikace prozkoumat a zjistit, co poskytují, jaké jsou jejich nedostatky a jak je uživatelé nejvíce využívají. Na základě těchto pozorování se potom určují požadavky na novou aplikaci, ve kterých je třeba vyvarovat se chyb a zbytečných funkcí existujících

10

3. NÁVRH WEBOVÝCH APLIKACÍ aplikací. Je také důležité, aby vyvíjená aplikace přinesla něco nového, co uživatelé ve starších nenajdou. Jinak hrozí, že budou stále používat původní aplikace a nová nebude téměř využívána. Po dokončení specifikace požadavků je možné přejít k návrhu aplikace obsahující všechny požadované funkce a mající potřebné vlastnosti.

3.2 Metodiky pro návrh webových aplikací Aby na konci vývoje celá aplikace správně fungovala, je nezbytné nejprve vytvořit kvalitní návrh aplikace. Případné chyby v návrhu se totiž přenáší při implementaci do samotné aplikace a poté se projevují při jejím užívání. Odstranění těchto problémů je pak často velmi nákladné a v nejhorších případech může dojít až k ukončení dalšího vývoje a používání takové aplikace. Návrhu aplikace je proto nutné věnovat dostatek času a úsilí, které se ovšem později vrátí v podobě spokojených uživatelů a snadné údržby a rozvíjení aplikace. K tvorbě návrhu aplikace je dobré využít metodiky, které umožňují pomocí nejrůznějších diagramů znázornit strukturu celé aplikace, všechny její části, funkce a vlastnosti. Nejrozšířenější modelovacím jazykem pro návrh aplikací je UML (Unified Modeling Language). Při návrhu webových aplikací je však velice důležité myslet na funkčnost a ergonomii uživatelského rozhraní, na nichž je do značné míry postaven úspěch těchto aplikací a UML ani jiné klasické metodiky se tímto návrhem příliš nezabývají [1]. Proto se objevilo WebML.

3.2.1 WebML WebML (Web Modeling Language) se objevilo na počátku tohoto tisíciletí. S počátkem vývoje je spjata italská univerzita Politecnico di Milan. WebML je především metodika pro návrh webových aplikací. Podporuje ale celý životní cyklus aplikace a umožňuje pomocí metadat z vytvořených návrhových modelů generovat funkční základní kostru aplikace. Tato kapitola je však zaměřena pouze na modely, které WebML definuje. Řadí se sem: 

Datový model – slouží pro návrh datové struktury, která reprezentuje informace zpracovávané a prezentované ve webové aplikaci. Je velice podobný klasickému entitně-relačnímu modelu. Jedná se o konceptuální model, který se velmi jednoduše převádí do konkrétní relační databáze [1].



Hypertextový model – je tvořen dvěma submodely, které jsou spolu těsně spjaty.

11

3. NÁVRH WEBOVÝCH APLIKACÍ o

Kompozice webové aplikace – definuje složení aplikace z jednotlivých stránek a také složení stránek z předdefinovaných elementů (Units). Ty představují atomické součásti obsahu stránky a jsou vázány na entity datového modelu, ze kterých čerpají svůj obsah a chování.

o

Navigační model – zobrazuje, jak jsou mezi sebou jednotlivé stránky a jejich elementy provázány.

Obecně se dá říci, že tento model definuje strukturu a funkčnost webové aplikace na konceptuální úrovni, což znamená, že navržená aplikace je ještě nezávislá na implementačních detailech a není také určen vzhled aplikace [1]. Tyto modely jsou podrobně popsány v následujících podkapitolách.

3.2.1.1 Datový model Jak již bylo zmíněno, slouží datový model pro návrh datové struktury aplikace. Je tvořen sadou entit, které jsou mezi sebou provázány pomocí vazeb s příslušnou kardinalitou. Entita reprezentuje určitou skupinu objektů reálného světa, které se označují jako instance entity. Všechny instance dané entity se nazývají populací a vyznačují se stejnou vnitřní datovou strukturou, která se vyjadřuje množinou atributů. Jménem a právě sadou atributů je každá entita popsána. Každý atribut má přiřazen datový typ. WebML definuje následující obecné datové typy:  Integer, Float, Decimal  String, Text, Password, URL  Date, Time, Timestamp  Boolean  Blob Tyto datové typy jsou navrženy tak, aby byly nezávislé na konkrétním databázovém systému ale zároveň obsaženy alespoň ve většině z nich. WebML umožňuje také definovat vlastní datové typy, pokud by tyto předdefinované nebyly dostačující. Grafická notace pro entity ve WebML nijak nevybočuje ze zažitých způsobů a je znázorněna na obrázku 3.1. Jak je zde také vidět, u entit je možné určit, které atributy jsou primárním klíčem. Vazby v datovém modelu znázorňují logické vztahy mezi entitami. V datovém modelu WebML jsou povoleny pouze vazby mezi dvěma entitami. Vazba mezi více entitami se dá vždy znázornit pomocí centrální (vazební) entity, jež je se všemi entitami, které se vazby účastní, spojena binární vazbou. Každá vazba má definovanou kardinalitu. Ta určuje, kolik instancí

12

3. NÁVRH WEBOVÝCH APLIKACÍ

Obrázek 3.1: Příklad entity datového modelu WebML jedné entity může mít vztah s jakoukoliv instancí druhé entity. Uvádí se vždy minimální kardinalita, jež může nabývat hodnot 0 nebo 1, a maximální kardinalita, která může mít hodnotu 0 nebo N (nekonečno). V datovém modelu WebML se kardinality zapisují opačným způsobem než je obvyklé v klasických entitně-relačních diagramech, což může být poněkud matoucí.

Obrázek 3.2: Vazba s kardinalitami Vazba na obrázku 3.2 tedy znázorňuje, že jedna osoba může mít více kontaktních adres a na každé adrese může bydlet právě jedna osoba, zatímco v klasickém entitně-relačním diagramu by takto zapsané kardinality znamenaly, že ke každé osobě je přiřazena právě jedna adresa a na dané adrese může bydlet jedna nebo více osob. Datový model také umožňuje sestavovat hierarchie entit. Znamená to, že nadřazená entita může mít své podřazené entity. Podřazená entita je speciálním případem nadřazené entity, dědí od ní všechny atributy a může k nim přidat také svoje specifické atributy. Hierarchie může mít více úrovní, ale každá podřízená entita nesmí mít více než jednu nadřízenou entitu. Jak je vidět, datový model WebML nepřináší v podstatě nic nového. Přestavuje však základ pro tvorbu hypertextového modelu, který již v klasických metodikách obdobu nemá. Aby tedy bylo možné hypertextový model korektně vytvořit, je třeba nejdříve navrhnout právě datový model.

13

3. NÁVRH WEBOVÝCH APLIKACÍ 3.2.1.2 Kompozice webové aplikace Prvním ze dvou modelů, jež společně tvoří hypertextový model, je kompozice webové aplikace. Jak již bylo řečeno, pro tvorbu tohoto modelu je třeba mít nejdříve dokončen datový model. Cílem kompozice webové aplikace je definovat strukturu webové aplikace, konkrétně jejího uživatelského rozhraní. Neuvažuje se však nijak nad konkrétním designem aplikace. Ve WebML se na každou webovou aplikaci nahlíží jako na kolekci webových stránek. Ty se pak skládají z různých základních prvků, které se v terminologii WebML nazývají Units. Přehled základních typů Units, jejich vlastností a využití je uveden v tabulce 3.1. U většiny Units je třeba určit, odkud čerpá svůj obsah. Zde se právě ukazuje potřeba již vytvořeného datového modelu, neboť u Units se mimo jiné určuje:  Zdrojová entita – definuje entitu datového modelu, jejíž instance tvoří zdrojová data pro příslušnou Unit.  Selektor – definuje aktuální obsah Unit. Pomocí booleovských podmínek určuje, jaké instance dané entity mají tvořit obsah příslušné Unit. Hodnoty do podmínky jsou buď zadávány přímo, nebo mohou být přeneseny pomocí metod z jiných Units. Ne u všech Units je nutné tyto vlastnosti definovat. Záleží na typu Unit a také na tom, jaká data se mají zobrazit.

WebML Unit Data Unit

Multi Data Unit

Stručný popis Představuje jednu příslušné entity.

instanci

Vlastnosti (objekt)    

Představuje více instancí jedné entity  na dané webové stránce.   

Jméno Zdrojová entita Selektor Atributy převzaté ze zdrojové entity

Jméno Zdrojová entita Selektor Atributy převzaté ze zdrojové entity  Pravidlo řazení instancí

14

3. NÁVRH WEBOVÝCH APLIKACÍ Index Unit

Představuje seznam instancí dané entity. Na rozdíl od Multi Data Units se používají pro zobrazení stručného seznamu instancí, jehož účelem je umožnit výběr jedné z nich. Nezobrazují tedy kompletní informace o instancích jako Multi Data Units.

   

Jméno Zdrojová entita Selektor Atributy převzaté ze zdrojové entity  Pravidlo řazení instancí

Multi Choice Index Unit

Varianta Index Units, kdy je možné  vybrat více než jednu instanci.   

Hierarchical Index Unit

Varianta Index Units, kdy jsou instance  Jméno uspořádané hierarchicky do stromové  Pro každou úroveň: struktury. o Zdrojová entita o Selektor o Atributy převzaté ze zdrojové entity o Pravidlo řazení instancí

Scroller Unit

Entry Unit

Jméno Zdrojová entita Selektor Atributy převzaté ze zdrojové entity  Pravidlo řazení instancí

Slouží pro procházení seznamů instancí dané entity rozdělených při větším počtu do listů. Používá se ve spojení s Data Unit, Multidata Unit nebo Index Unit.

   

Jméno Zdrojová entita Selektor Počet instancí na každém listu  Pravidlo řazení instancí

Slouží k modelování uživatelských  Jméno vstupů, tedy pro definování formulářů.  Datový typ vstupních dat  Výchozí hodnota  Validační pravidla

15

3. NÁVRH WEBOVÝCH APLIKACÍ Multi Entry Unit

Varianta Entry Unit, která obsahuje více  Jméno polí pro uživatelské vstupy.  Pro každé pole: o Jméno o Datový typ vstupních dat o Výchozí hodnota o Validační pravidla  Jméno  Zdrojová entita  Hodnoty atributů nové instance

Create Unit

Zajišťuje vytvoření nové instance entity.

Delete Unit

Zajišťuje odstranění jedné nebo více  Jméno instancí entity.  Zdrojová entita  Selektor

Modify Unit

Zajišťuje změnu instancí entity.

jedné

nebo

více    

Jméno Zdrojová entita Selektor Změněné hodnoty atributů instance

Login Unit

Ověřuje identitu uživatele přistupujícího  Uživatelské jméno k aplikaci.  Heslo

Logout Unit

Přesměrovává uživatele na výchozí  Site View, kam bude stránku, kde není kontrolována identita. uživatel přesměrován

Tabulka 3.1: Přehled Units modelu kompozice webové aplikace WebML [2, 3]

16

3. NÁVRH WEBOVÝCH APLIKACÍ Create, Delete a Modify Units patří do skupiny operačních Units, které slouží pro znázornění manipulace s daty. Nejsou součástí žádné stránky. Jsou to jen abstraktní prvky webové prezentace. WebML také zavádí elementy modelu kompozice webové aplikace, které sdružují jednotlivé Units do větších celků. Jejich přehled je v následující tabulce 3.2. WebML element

Stručný popis

Vlastnosti

Page

Reprezentuje jednu webovou stránku  Jméno aplikace. Obsahuje jednotlivé Units  Umístění v aplikaci a/nebo vnořené stránky (AND/OR sub-pages).

AND sub-pages

Vnořené stránky, které se mohou  Jméno pro každou zobrazit přes základní stránku. vnořenou stránku Mohou v sobě obsahovat Units nebo další vnořené stránky.

OR sub-pages

Vnořené stránky, z nichž vždy právě  Jméno jedna je zobrazena.  Výchozí zobrazená Mohou v sobě osahovat Units nebo vnořená stránka další vnořené stránky.

Master Page

Obsahuje jednu nebo více stránek  Jméno a může také obsahovat Units. Ty jsou potom v aplikaci součástí každé stránky vložené do dané Master Page.

Area

Představuje jednu oblast webové  Jméno aplikace. Jsou v ní umístěné stránky a Master Pages, které do dané oblasti patří. Může obsahovat některé Units a také vnořené oblasti.

Tabulka 3.1: Přehled elementů sdružujících Units do větších celků [3] Vůbec největším logickým celkem, který lze v modelu kompozice webové aplikace zobrazit jsou Site Views. Ukazují, jak se webová aplikace zobrazuje různým skupinám

17

3. NÁVRH WEBOVÝCH APLIKACÍ uživatelů. Jiné funkce či stránky jsou dostupné například registrovaným uživatelům, jiné náhodným návštěvníkům a ještě jiné administrátorům. Pro každý Site View se vytváří samostatný model, který ukazuje, co je pro kterou skupinu dostupné. Ani kompletní model kompozice webové aplikace však dostatečně nepopisuje uživatelské rozhraní aplikace. Nejsou v něm žádné vazby mezi stránkami a jednotlivými Units, které by daly aplikaci smysl. Tyto vztahy dodává až navigační model.

3.2.1.3 Navigační model Úkolem navigačního modelu ve WebML je provázat jednotlivé Units a webové stránky pomocí nejrůznějších odkazů a tím ukázat, jak se má aplikace chovat. Odkaz je v modelu vždy znázorněn šipkou a může jím být (obrázky 3.3 – 3.5):  Orientované propojení dvou webových stránek  Propojení dvou Units v rámci jedné webové stránky  Propojení dvou Units v různých webových stránkách

Obrázek 3.3: Propojení dvou stránek

Obrázek 3.4: Propojení dvou Units v jedné stránce

Obrázek 3.5: Propojení dvou Units na různých stránkách Odkazy propojující jednotlivé webové stránky, se nazývají nekontextové odkazy. Ty, které propojují dvě Units v rámci jedné nebo dvou stránek, se naopak označují jako kontextové, neboť většinou přenáší mezi Units parametry, jež jsou využívány v selektorech příslušných Units. Přenášený parametr se zapisuje přímo k odkazu do modelu (obrázek 3.6). Pro přehlednost

18

3. NÁVRH WEBOVÝCH APLIKACÍ modelu je však možné tento údaj vynechat v případě, že se mezi Units přenáší implicitní parametry, které jasně definují instanci entity (např. primární klíč). Podobně není nutné zapisovat vždy k Units v modelu kompozice webové aplikace selektor.

Obrázek 3.6: Přenášení parametru mezi Units Jestliže se v modelu kompozice webové aplikace objevují i operační Units, je třeba do navigačního modelu doplnit speciální odkazy, které se nazývají OK links a KO links. Každá operace s instancí může skončit úspěšně, či neúspěšně. Na základě tohoto výsledku může být aplikace přesměrována rozdílným způsobem. K zobrazení přesměrování slouží právě OK a KO links. Z každé operační Unit může vystupovat maximálně jeden OK link a jeden KO link.

Obrázek 3.7: Příklad použití OK a KO links Na obrázku 3.7 je zobrazeno, jak se OK a KO links využívají. OK link je vždy zobrazena zelenou barvou, KO link naopak červenou. Pomocí Multi Entry Unit zadáme údaje o nové instanci entity, jež poté předáme operační Create Unit. Ta se pokusí novou instanci vytvořit. Pokud je operace úspěšná, je aplikace přesměrována na stránku s Index Unit, která zobrazuje

19

3. NÁVRH WEBOVÝCH APLIKACÍ všechny dosud vytvořené instance dané entity. V případě neúspěchu operace se aplikace vrací opět na stránku s Multi Entry Unit, kde má uživatel možnost údaje opravit a pokusit se znovu o vytvoření instance. Spojením modelu kompozice webové aplikace a navigačního modelu vzniká komplexní hypertextový model webové aplikace, který zobrazuje, jak jsou data v aplikaci zobrazována, jak je možné s nimi manipulovat a také ukazuje navigaci mezi jednotlivými stránkami aplikace.

3.2.1.4 Současný stav metodiky WebML Ačkoliv zanedlouho uplyne již 10 let od vzniku WebML, není tento způsob návrhu webových aplikací příliš rozšířen. Je otázkou, proč tomu tak je. Zda z důvodu, že WebML není stále dostatečně kvalitně rozpracováno a neumožňuje kvalitní návrh aplikace vytvořit, nebo proto, že aplikační návrháři zůstávají raději u déle známého UML, které lépe znají a umí s ním pracovat. Z mého pohledu se pomocí WebML dá struktura webové aplikace poměrně dobře navrhnout, a proto se přikláním spíše ke druhé variantě. Pro návrh webové aplikace pomocí WebML existuje v současnosti pouze jeden kvalitní CASE nástroj, který se jmenuje WebRatio. Je možné v něm vytvořit všechny potřebné modely. Kromě zde popsaných základních elementů všech modelů poskytuje další rozšiřující elementy, hlavně v oblasti Units. I z toho je vidět, že WebML není mrtvá metodika, ale stále se vyvíjí a snaží se pomocí nových elementů umožnit vytváření přesnějších návrhů aplikací. WebRatio také dokáže po dokončení návrhu aplikace vygenerovat z vytvořených modelů základní kostru aplikace v programovacím jazyce Java. V nástroji je možné upřesňovat nejrůznější parametry aplikace a její nastavení, a tím ovlivnit výslednou podobu a funkčnost vygenerované aplikace. Vzhledem k tomu, že v současnosti dochází ke stále většímu rozvoji webových aplikací, je možné, že se WebML v budoucnu ještě více prosadí, zvláště pokud UML neumožní kvalitně a názorně webové aplikace navrhovat. Záležet však bude především na ochotě návrhářů opustit UML a naučit se pracovat s odlišnou, ale možná efektivnější metodikou.

3.2.2 UML Modelovací jazyk UML (Unified Modeling Language) představuje v současné době nejpoužívanější metodiku pro návrh aplikací. Vznikl v roce 1994 a dnes existuje ve verzi 2.3. Přestože neposkytuje žádný model, který by konkrétně umožňoval návrh uživatelského rozhraní webových aplikací, je užitečné jej použít při modelování dalších aspektů aplikace. UML definuje celkem 14 diagramů, které jsou rozděleny do dvou hlavních skupin. První skupinou jsou diagramy struktur, jejichž cílem je zobrazit statickou strukturu modelované aplikace a patří sem:  diagram tříd  diagram vnitřní struktury

20

3. NÁVRH WEBOVÝCH APLIKACÍ  diagram objektů  diagram komponent  diagram balíčků  diagram nasazení Druhou skupinou jsou diagramy chování, jež zachycují dynamické aspekty modelované aplikace. Do této skupiny jsou řazeny:  diagram případů užití  diagram aktivit  stavový diagram  diagramy interakce o sekvenční diagram o diagram komunikace o diagram interakcí o diagram časování Při tvorbě návrhu webové aplikace se téměř vždy hodí použít diagram případů užití. Diagram případů užití (Use Case Diagram) zobrazuje všechna možná užití aplikace účastníkem. Každý případ užití má své jméno. Účastník (Actor) je kdokoliv nebo cokoliv, co se systémem komunikuje. Může jím být tedy člověk v různých rolích (např. registrovaný uživatel, administrátor), ale také nějaký hardware či jiný systém. Každý případ užití je zobrazen jednou bublinou s příslušným jménem, která je spojena s odpovídajícím účastníkem. Jednotlivá jména jasně určují podstatu každého případu užití, proto není nutná další textová specifikace a vysvětlování. Příklad účastníka a jednoho případu užití je možné vidět na obrázku 3.8 [4].

Obrázek 3.8: Příklad případu užití v Use Case Diagramu Mezi další často využívané diagramy UML se řadí diagram tříd, sekvenční diagram či stavový diagram. UML také poskytuje možnost rozšíření diagramů pomocí stereotypů, omezení a pojmenovaných hodnot. I tato skutečnost přispívá k tomu, že je UML velice robustním nástrojem, který se ale může stát v některých situacích až nepřehledným, právě díky velkým možnostem, které nabízí.

21

3. NÁVRH WEBOVÝCH APLIKACÍ 3.2.3 ERD ERD (Entity-relationship Diagram, česky entitně-relační diagram) má nezastupitelnou úlohu při návrhu téměř jakékoliv aplikace, neboť slouží pro návrh její datové struktury. Entitně-relační diagram je velice podobný datovému modelu WebML, který právě z ERD vychází. Základem jsou opět entity se svými atributy a vazby mezi nimi s odpovídajícími kardinalitami. Datové typy atributů nejsou pevně stanoveny, jako je tomu u WebML. Je možné navrhovat ERD již s konkrétními typy určité relační databáze, pokud je jasné, která databáze bude při implementaci použita. U vazeb mezi entitami se v porovnání s datovým modelem WebML zapisují kardinality opačně. Příklad na obrázku 3.9 tedy ukazuje vazbu, kdy každá osoba má právě jednu adresu a na dané adrese může bydlet jedna nebo více osob, na rozdíl od stejně zobrazené vazby v datovém modelu WebML mající význam opačný.

Obrázek 3.9: Vazba mezi entitami v ERD Na obrázku je také vidět, jak se často v ERD značí kardinality místo psaných údajů. Diagram na rozdíl od WebML pracuje i s pojmem cizí klíč, což je atribut entity odkazující na instance některé jiné entity. Některé nástroje pro tvorbu ERD dokážou v entitách automaticky cizí klíče generovat na základě vytvořených vazeb. Jelikož drtivá většina webových aplikací pracuje s databázemi, je v případě nevyužití datového modelu WebML entitně-relační diagram nezbytnou součástí návrhu aplikace.

22

Kapitola 4

Technologie pro tvorbu webových aplikací Po dokončení návrhu webové aplikace přichází na řadu její samotná implementace. Na rozdíl od klasických desktopových aplikací, kde si většinou programátor vystačí s jedním programovacím jazykem a případně znalostí SQL pro práci s databází, je situace při tvorbě webových aplikací o něco komplikovanější. Tvůrce aplikace musí téměř vždy při implementaci využít více než jednu technologii, také práce se vzhledem aplikace bývá často pracnější. Od doby, kdy existoval pouze jazyk HTML ve své první verzi, vzniklo mnoho technologií s cílem umožnit vytvářet stále kvalitnější aplikace s čím dál menším úsilím. V této kapitole jsou představeny některé z nich.

4.1 HTML Ať už je webová aplikace tvořena jakoukoli technologií, nakonec se uživateli v internetovém prohlížeči zobrazuje stránka psaná v jazyce HTML (HyperText Markup Language). Tento jazyk je tedy nezbytné znát, neboť je využit v každé webové aplikaci.

4.1.1 Historie a vývoj HTML První verzi HTML vytvořil v roce 1991 Tim Berners-Lee. Umožňovala text rozčlenit do několika logických úrovní, použít několik druhů zvýraznění textu a zařadit do textu odkazy a obrázky. Časem však požadavky uživatelů vzrůstaly, a proto bylo postupně HTML obohacováno o nové prvky, až vznikl standard HTML 2.0. Byla v něm například definována práce s formuláři. V roce 1995 vznikl návrh standardu HTML 3.0, jenž jazyk rozšiřoval o vytváření tabulek a matematických vzorců, umožňoval také lepší obtékání obrázků textem a vytváření stylů dokumentů. Ukázalo se však, že tento standard byl příliš velkým skokem vpřed a žádný prohlížeč ho v té době nedokázal podporovat. Vznikla proto verze HTML 3.2, která obsahovala pouze věci aktuálně implementované v prohlížečích. Rychlý vývoj HTML byl zastaven v roce 1997 vznikem standardu HTML 4.0. V této době již vývoj webových standardů koordinovalo konsorcium W3C. To krátce po vydání standardu HTML 4.0 zveřejnilo ještě jeden standard, kterým byl jazyk XML (eXtensible Markup Language). Ten se rychle stal často využívaným formátem pro výměnu a ukládání dat. Ovlivnil také další vývoj jazyka HTML. V roce 2000 byla totiž vydána specifikace jazyka XHTML 1.0, která měla svoji syntaxi odvozenou právě od XML. Rozdíl oproti klasickému HTML byl pouze v drobně změněné syntaxi. Přestože začal být jazyk XHTML občas využíván,

23

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ nebyl důvod k němu masově přecházet. Na půdě W3C tak začala pracovní skupina XHTML vyvíjet verzi jazyka XHTML 2.0, která měla přinést mnohé zajímavé vlastnosti bohužel za cenu porušení kompatibility s předchozími verzemi jazyka HTML a XHTML. Tento krok nebyl výrobci webových prohlížečů příznivě přijat, a proto stále zůstávali u HTML 4.0 a XHTML 1.0. Nakonec i uvnitř W3C převážil názor, že XHTML 2.0 je slepá cesta a místo toho začalo v roce 2007 vznikat HTML 5 [5].

4.1.2 HTML 5 Tento nejnovější standard začal vznikat především z důvodu nedostačujících možností v HTML 4. Bez použití kaskádových stylů nebylo možné příliš definovat strukturu webové stránky. S rostoucím objemem multimediálního obsahu na internetu se začala objevovat potřeba přehrávače v prohlížečích, čehož ovšem nebylo možné pomocí HTML 4 dosáhnout a bylo tak nutné začít využívat nejrůznější pluginy, nejvíce technologii Flash. Tyto nedostatky, ale také některé další si HTML 5 klade za cíl odstranit. HTML 5 poskytuje nové možnosti při strukturování webové stránky. Místo nutnosti používat značku div spojenou s různými styly pro vytvoření požadované struktury stránky umožňuje využít tyto nové značky:  header – hlavička stránky  footer – patička stránky obsahující např. informace o autorských právech  nav – část stránky sloužící pro zobrazení navigačních odkazů  aside – boční panel stránky  section – programátorem definovaná část stránky na webu  article – část stránky obsahující nějaký text Použití těchto značek usnadňuje uživateli používajícímu různé asistenční technologie pohyb po stránce. Zpřehledňují také kód stránky a usnadňují jeho tvorbu. Pro práci s multimediálními daty přináší HTML 5 nové značky audio a video, do nichž se jednoduše vloží odkaz na požadovaný soubor, jehož přehrání potom zajišťuje přímo prohlížeč. Jasnou výhodou této novinky je nezávislost na softwaru třetích stran, jako je např. právě Flash. Uživatelům tedy pro přehrání souborů skutečně stačí pouze webový prohlížeč a nemusí instalovat nic dalšího. Dalším přínosem jsou nové typy, které je možné nastavit u značky input sloužící pro zobrazení formuláře. Tím se mimo jiné přesněji určí účel formuláře. Novým typy jsou např.:  datetime – datum a čas  month – měsíc  week – týden  number - číslo  email – pole pro zadání emailové adresy (s ověřením, zda je formát správný)  search – vyhledávací políčko

24

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Úplnou novinkou by měla být značka canvas, schopná vykreslovat grafiku. Uplatnit by se mohla třeba při vytváření dynamických grafů závislých na aktuálních datech. Mělo by být možné ji využít i pro vytváření her. Standard HTML 5 je stále ve vývoji a termín vydání finální verze specifikace je až rok 2022. Předpokládá se ale, že finální verze HTML 5 by mohla být k dispozici již příští rok a poté přijde doba ladění a odstraňování nedostatků. Webové prohlížeče v současných verzích již mnoho nových vlastností HTML 5 podporují, proto se dají ve webových aplikacích často využívat. Je třeba však počítat s tím, že občas ještě nemusí být všechno dokonalé a bez problémů funkční.

4.2 CSS Jazyk HTML byl navržen především pro tvorbu webových stránek z hlediska obsahu, na vzhled se příliš neohlížel. To začalo být ovšem problémem v okamžiku, kdy se začal web rozšiřovat do komerční sféry. Objevily se totiž požadavky na lepší kontrolu nad grafickým vzhledem stránky. V reakci na to byly do specifikace jazyka přidány nové atributy, které měly tyto problémy odstranit. Důsledkem však byl čím dál nepřehlednější kód webové stránky a také nutnost vkládat všechny potřebné grafické prvky do každé stránky, kde měly být použity. Proto byla v roce 1996 vydána první specifikace CSS (Cascading Style Sheets, česky kaskádové styly). Úkolem CSS bylo a také dnes je umožnit snadné formátování webových stránek. Všechny potřebné vlastnosti, jež se týkají vzhledu všech elementů na stránkách, je možné umístit do jednoho odděleného dokumentu. Na ten pak stačí odkázat na každé stránce, kde se mají nastavení projevit. Zpřehledňuje se tím tedy samotný kód stránky a také se výrazně usnadňuje změna vzhledu, neboť již není nutné měnit nastavení v každé stránce, ale stačí změnu provést pouze jednou v dokumentu se styly. Jedna stránka může být formátována i více než jedním takovým dokumentem.

4.2.1 Vývoj CSS Verze CSS 1 přinesla možnost základní manipulace s písmem, barvami na stránkách, umožnila vytváření a práci s rámečky a také nastavování pozice jednotlivých elementů na stránce. Podpora v tehdejších prohlížečích byla zpočátku bídná, postupem času se však situace začala zlepšovat a v roce 1998 již bylo CSS alespoň částečně použitelné. V této době se již pracovalo na specifikaci CSS 2, jejíž finální verze byla vydána v roce 2000. Ta přinesla zdokonalení již existujících vlastností v CSS 1 a také nové možnosti vytváření vzhledu stránek. Trvalo poměrně dlouho, než prohlížeče začaly CSS 2 dostatečně podporovat, ale v současné době je situace v této oblasti již velmi uspokojivá, i když stále existují drobné rozdíly při interpretaci CSS jednotlivými prohlížeči.

25

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ 4.2.2 CSS 3 Od roku 2005 se na scéně pomalu začíná objevovat nejnovější verze kaskádových stylů, kterou je CSS 3. Dokončení vývoje této specifikace se očekává až v roce 2015, již teď však prohlížeče podporují spoustu nových vlastností, které CSS 3 přináší, proto už jistě stojí za to využít je v moderních webových aplikacích. Některé z těchto vlastnosti jsou také v této kapitole podrobněji popsány. Novinky v CSS 3 by se daly rozdělit do několika kategorií:  Pozadí, rámečky a text  Přechody a animace  Selektory Kromě těchto uvedených skupin vlastností, přináší CSS 3 další novinky, které stojí mimo tyto kategorie. S každou novou verzí některého z prohlížečů se zvyšuje podpora CSS 3 vlastností, na funkčnost všech novinek bude ale třeba ještě nějaký rok počkat. Podpora vlastností CSS 3 jednotlivými prohlížeči je brána podle stavu v dubnu 2011, kdy byly dostupné verze Internet Explorer 9.0, Mozilla Firefox 4.0, Opera 11.10, Chrome 10.0 a Safari 5.0.

4.2.2.1 Pozadí, rámečky a text Vlastnosti v této kategorii jsou v současnosti již velmi dobře podporovány ve většině prohlížečů, proto již mohou být směle ve webových aplikacích využívány. Hlavními zástupci této skupiny jsou:  Border radius – kulaté rohy rámečků  Box shadow – stín za hranicí elementu  Text shadow – stín za textem  CSS transform – změna velikosti a pozice elementu  Gradient – barevné přechody  RGBA – zápis barev pomocí jejich složek a průhlednost Border radius Kulaté rohy se do vzniku této vlastnosti řešily jedině pomocí obrázků, které se vložily jako pozadí daného elementu. Díky této vlastnosti již není třeba obrázků pro tento účel využívat, k definování zaobleného rohu stačí jednoduchý zápis: border-radius: {number} px

26

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Jako hodnota se uvádí počet pixelů. Ten označuje, jak daleko od rohu zaoblení začíná. Je možné použít i složitější zápis: border-radius: {number} px {number} px {number} px {number} px Ten umožňuje nastavit různé zaoblení pro jednotlivé rohy rámečku. Zaoblení také nemusí být pravidelné a může vytvářet část elipsy. Zápis pak vypadá takto: border-*-*-radius: {number} px {number} px Hvězdičky zastupují slova pro přesné určení jednoho ze čtyř rohů (top, bottom a left, right), první číslo udává začátek zaoblení na vodorovné ose, druhé pak na svislé. Místo počtu pixelů je také možné použít údaj v procentech, který říká, jakou část z šířky či výšky rámečku má zabírat zaoblení. Pomocí této vlastnosti se dají vytvořit třeba tvary zobrazené na obrázku 4.1.

Obrázek 4.1: Tvary vytvořené pomocí vlastnosti border-radius [6] Box shadow Tato vlastnost umožňuje vytvořit jednak stín za hranicí určitého elementu (např. div), ale také uvnitř něj. Zde, stejně jako u mnoha jiných vlastností CSS 3, je potřeba pro použití v některých prohlížečích přidat při zápisu před název vlastnosti předponu podle typu prohlížeče. Pro Mozillu Firefox je to -moz-, pro Operu -o- a pro pro prohlížeče z jádrem Webkit (Chrome, Safari) -webkit-. Internet Explorer využívá v některých situacích, kdy nepodporuje klasický zápis vlastnosti, speciální odlišnou syntaxi, která zde nebude rozebírána. V tomto případě je nutné použít předponu pro Webkit prohlížeče. Obvyklý zápis tedy vypadá takto: -webkit-box-shadow: {number} px {number} px {number} px {color} box-shadow: {number} px {number} px {number} px {color}

27

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ První číslo definuje horizontální posunutí stínu, kladná hodnota směrem doprava, záporná pak doleva. Druhé číslo určuje vertikální posunutí, kladná hodnota značí směr dolů. Třetí hodnotou se udává, nakolik má být okraj stínu rozmazaný. Barva stínu může být zapsána slovně či hexadecimálně. U rozmazání okraje není přesně definováno, jak se má podle zadané hodnoty vykreslit, proto můžeme narazit mezi prohlížeči na drobné rozdíly. Tato vlastnost poskytuje ještě další parametry, které mohou výsledný stín ovlivnit, ty však zatím nemusí fungovat správně ve všech prohlížečích. Za zmínku stojí důležitý parametr inset, který zajistí vytvoření vnitřního stínu. Je také možné definovat více stínů, které na sebe navazují. Otázkou je praktická využitelnost této možnosti, ale v některých případech by se i toto mohlo hodit. Na obrázku 4.2 jsou zobrazeny jednoduché ukázky stínů vytvořených pomocí této vlastnosti.

Obrázek 4.2: Stíny vytvořené pomocí vlastnosti box-shadow Text shadow Díky této vlastnosti je možné přidat stín k textu. Pracuje na podobném principu jako box-shadow a její zápis proto vypadá obdobně: text-shadow: {number} px {number} px {number} px {color} Umožňuje také vytváření vícenásobných stínů. Tato vlastnost v současnosti funguje ve všech prohlížečích kromě Internet Exporeru 9. Příklad textu se stínem je vidět na obrázku 4.3.

Obrázek 4.3: Text se stínem vytvořeným pomocí vlastnosti text-shadow CSS transform Touto vlastností je možné pomocí několika parametrů měnit zobrazení elementů na stránce. V tomto případě je nutné pro každý prohlížeč použít vlastní definici s příslušnou předponou.

28

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Bez ní je zápis následující: transform: rotate({number}deg) scale({number}) skew({number}deg) translate({number}px) Jednotlivé parametry mají tyto významy:  rotate – otočení elementu kolem své osy o zadaný počet stupňů ve směru hodinových ručiček  scale – zvětšení nebo zmenšení vzhledem k výchozí velikosti. Udává se desetinným číslem, kdy 1.0 je výchozí velikost.  skew – míra zkosení od vlastní osy ve stupních  translate – posunutí elementu v pixelech Parametry scale, skew a translate se dají nastavit pro horizontální i vertikální směr. Stačí do definice přidat k daným parametrům druhou hodnotu. Ta poté určuje změnu v horizontálním směru. Gradient Díky této vlastnosti je možné zase o něco méně používat obrázky při tvorbě vzhledu stránky. Umožňuje totiž vytvořit barevné přechody pozadí, čehož dříve jinak než pomocí obrázků nešlo dosáhnout. Existují dva typy přechodů, jedním je linear-gradient vytvářející přechod z jedné strany na druhou, druhým pak radial-gradient, který tvoří přechod od středu ke krajům. Vlastnost se zapisuje do definice pozadí elementu. Linear-gradient Pro použití linear-gradient je třeba zadat definice s předponami, navíc je zápis pro prohlížeče Webkit odlišný od prohlížečů Mozilla Firefox a Opera. Vypadá takto: -moz-linear-gradient({position}, {color percent}, {color percent}) -o-linear-gradient({position}, {color percent}, {color percent}) -webkit-gradient(linear, {start position}, {end position}, color-stop({percent, color}), color-stop({percent, color})) Pro zajímavost následuje zápis definující přechod v Internet Exploreru: filter: progid:DXImageTransform.Microsoft.gradient( startColorstr={color}, endColorstr={color},GradientType=0 )

Parametr position určuje směr přechodu. Hodnota top značí shora dolů, left pak zleva doprava.

29

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ U prohlížečů Webkit je zápis trošku odlišný, směr shora dolů se značí left top, left bottom, zleva doprava potom left top, right top. Procenta u barev udávají, v jakém místě bude pozadí tvořeno pouze danou barvou. Je samozřejmě možné vytvořit přechod mezi více barvami přidáním barvy a procenta do definice. Protože je tato vlastnost zřejmě nejkomplikovanější ze zde uvedených, na obrázku 4.4 je vyobrazen konkrétní příklad podle následující definice: -o-linear-gradient(left, #2c539e 0%, #FCFCE5 17%, #A03919 40%, #339117 47%, #339117 77%, #D8EF43 100%)

Obrázek 4.4: Příklad použití vlastnosti linear-gradient radial-gradient Vlastnost radial-gradient pracuje na podobném principu jako linear-gradient. Definice opět musí obsahovat předpony prohlížečů a bez nich vypadá takto: radial-gradient({position}, {type}, {colors percent}) Parametr position udává, v jakém místě pozadí je střed, od kterého má požadovaný přechod začít. Může být zadán v pixelech nebo procentech. Type může nabývat hodnot elipse nebo

circle. Ty určují tvar přechodu. Poté stejně jako u linear-gradient následují barvy a k nim příslušná procenta, jež definují kde a co se má v přechodu objevit. Na následujícím obrázku 4.5 je opět zobrazen konkrétní příklad podle následující definice: -moz-radial-gradient(50% 50%, circle, yellow, green 30%, brown 60%);

Obrázek 4.5: Příklad použití vlastnosti radial-gradient

30

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ RGBA CSS 3 přináší novou funkci rgba, která umožňuje definovat barvu pozadí pomocí jejích jednotlivých složek a k tomu přidává možnost nastavit průhlednost daného pozadí. Zápis funkce vypadá následovně: rgba({red}, {green}, {blue}, {opacity}) Čísla mezi 0 a 255 postupně udávají červenou, zelenou a modrou složku barvy, poslední desetinné číslo v rozmezí mezi 0 a 1 určuje průhlednost pozadí. Čím nižší hodnota, tím vyšší je průhlednost. Na obrázku 4.6 je zobrazen příklad různých hodnot parametru průhlednosti.

0.2

0.5

0.8

1.0

Obrázek: 4.6: Zobrazení pozadí s různými hodnotami průhlednosti

4.2.2.2 Přechody a animace Pomocí vlastností patřících do této kategorie je možné webovou aplikaci určitým způsobem rozpohybovat a vylepšit tak její vzhled a hodnocení u uživatelů. Přechody umožňují definovat plynulé změny vzhledu elementů na stránce. Byly vymyšleny společností Apple a W3C je přes počáteční odpor nakonec do specifikace přidalo. Dnes jsou přechody podporovány všemi prohlížeči kromě Internet Exploreru. K definici je však třeba přidat předpony prohlížečů. Vypadá takto: transition: {property} {time}s {type} {delay}s Prvním parametrem se určuje vlastnost prvku, která má být při přechodu animována. Druhý udává, jak dlouho má přechod trvat. Type určuje, jaký bude mít přechod průběh. Na výběr jsou tyto hodnoty:  linear – rovnoměrný přechod  ease – postupné zpomalování  ease-in – zrychlení  ease-out – zpomalení  ease-in-out – nejdříve zrychlení, potom zpomalení  cubic-bezier(x1, y1, x2, y2) – přechod proběhne podle Bézierovy křivky vytvořené pomocí zadaných hodnot Poslední parametr udává v sekundách, jak dlouho se má se začátkem přechodu čekat.

31

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Přechody jsou použitelné hlavně při změnách prvků, a proto by se měly vkládat k odpovídajícím definicím elementů (např. element:hover, element:active). Animace jsou v současnosti podporovány ve Webkit prohlížečích a Mozille Firefox. Jejich definování je trochu komplikovanější. Ukázáno je na následujícím příkladu: -webkit-animation-name: animace;

– nastavení jména animace

-webkit-animation-duration: 2s;

– doba trvání animace

-webkit-animation-iteration-count: infinite; – počet opakování animace -webkit-animation-timing-function: linear;

– průběh animace (podobně jako u přechodů)

Nakonec je definována samotná animace: @-webkit-keyframes animace { from {-webkit-transform:rotate(0deg);} to {-webkit-transform:rotate(360deg);} } Jedno proběhnutí této animace bude trvat 2 sekundy, bude se stále opakovat, mít lineární průběh a podstatou animace bude otočení prvků o 360 stupňů. Již teď je možné na internetu najít spoustu velice podařených animací vytvořených pomocí CSS 3. Zda se tento způsob jejich tvorby více prosadí, se uvidí až v dalších letech [7].

4.2.2.3 Selektory Selektory umožňují na stránce definovat konkrétní element, pro nějž mají platit určité vlastnosti. Nejznámějšími a nejvyužívanějšími selektory jsou selektor třídy (class) a ID selektor (id). Kromě nich se však již ve specifikaci CSS 2 objevily některé další, jež umožňují určovat elementy jiným způsobem. CSS 3 nově přináší mnoho dalších možností výběru požadovaných prvků na stránkách. Jednou z nich je vybrání elementů na základě jejich obsahu. Pomocí pseudotřídy element:contains(„řetězec“) je možné vybrat všechny elementy, které obsahují zadaný řetězec. Definici p:contains(„informatika“) tedy odpovídají všechny odstavce obsahující slovo informatika. Užitečnými selektory by mohly být ty, jež určují elementy podle stromu dokumentu. V CSS 2 byl k dispozici pouze selektor :first-child, označující prvního potomka elementu.

32

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ CSS 3 definuje tyto nové selektory (definice se vždy vztahuje k elementu E):  E:last-child – poslední dítě svého rodiče  E:first-of-type – první sourozenec svého typu  E:last-of-type – poslední sourozenec svého typu  E:nth-child(n) – n-té dítě svého rodiče  E:nth-last-child(n) – n-té dítěte svého rodiče, počítáno odzadu  E:nth-of-type(n) – n-tý sourozenec svého typu  E:nth-last-of-type(n) – n-tý sourozenec svého typu, počítáno odzadu  E:only-child – jediné dítě svého rodiče  E:only-of-type – jediný sourozenec svého typu Za výraz n je navíc možné kromě čísla dosadit i polynom ve tvaru an + b. To může najít uplatnění třeba v následujícím příkladu, kde se vybírají zvlášť liché a sudé řádky tabulky. tr:nth-child(2n) – sudé řádky tabulky tr:nth-child(2n+1) – liché řádky tabulky Mezi další novinky na poli selektorů patří ty, které umožňují rozpoznat stavy formulářových komponent. Patří sem například určení povolených (:enabled), zakázaných (:disabled) či zaškrtnutých (:checked) prvků. Většinu nových selektorů již prohlížeče podporují, proto by neměly při jejich použití vznikat žádné vážnější problémy [8].

4.2.2.4 Další zajímavé novinky v CSS 3 Specifikace CSS 3 definuje mnoho dalších novinek, které nejde příliš zařadit do předchozích kategorií. Některé z nich však jistě stojí za zmínku. Ovlivnit rozvržení textu na stránce nově umožňuje zajímavá vlastnost column-count, která dokáže rozdělit text v elementu do zadaného počtu sloupců. Navíc je možné pomocí vlastnosti column-gap určit, jak velká mezera má být mezi jednotlivými sloupci, a vlastností column-rule definovat, zda se má mezi sloupci objevit nějaká čára. CSS 3 také přináší možnosti, které už s nastavováním stylů příliš nesouvisí a až budoucnost ukáže, jestli tyto funkce najdou větší uplatnění. Jednou z nich je například možnost komunikace s databází. Následující příklad ukazuje, jak se definuje připojení k databázi: @database { username: „uživatelské jméno“; password: „heslo“; database: „název databáze“; dbhost: „umístění databáze“;}

33

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Poté je již možné pomocí podobné syntaxe jako u definice připojení zadávat databázi jednotlivé dotazy. Další zajímavostí je možnost posílat pomocí CSS 3 emaily. Zápis této funkce je následující: @email { recipient: „příjemce“; subject: „předmět“; message: „text emailu“; } CSS 3 také umožňuje definovat přesměrování stránky pomocí tohoto zápisu: @redirect { request: „požadovaná stránka“; redirect: „cíl přesměrování“; status: „stavový kód“; } Jak tato podkapitola ukázala, specifikace CSS 3 přináší mnoho novinek a vylepšení, které ve výsledku jistě umožní tvorbu stále kvalitnějších webových aplikací. Některé z nich jsou již ve všech prohlížečích bezproblémově funkční, spousta jich však ještě na kvalitní podporu čeká a nezbývá tak než se těšit, že s jejich implementací v prohlížečích se otevřou programátorům další užitečné možnosti pro vytváření moderních webových aplikací.

4.3 JavaScript JavaScript se v současnosti využívá téměř ve všech webových aplikacích, proto je na místě se o něm alespoň krátce zmínit. Autorem tohoto objektově orientovaného skriptovacího jazyka je Brendan Eich. Cílem bylo vytvořit jazyk, který by pomohl vytvářet více interaktivní webové stránky. Ačkoliv by se podle jména mohlo zdát, že je JavaScript nějakou variantou programovacího jazyka Java, kromě podobné syntaxe nemají nic společného. Slovo Java se v názvu objevilo pouze z marketingových důvodů. Na rozdíl od ostatních interpretovaných programovacích jazyků se JavaScript spouští na straně klienta. Výhodou tohoto přístupu je, že není třeba odesílat data z uživatelského počítače na server a zpět, protože o zpracování se stará přímo klient, je také možné snadno reagovat na různé události, jako je například stisk klávesy či pohyb myši. Jednou z nevýhod je naopak fakt, že uživatel může na svém počítači JavaScript zakázat, což může zapříčinit neočekávané chování aplikace.

34

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Programátoři mohou vytvářet knihovny funkcí, jež usnadňují práci s JavaScriptem, a tím i tvorbu webových aplikací. V poslední době se staly populárními knihovny umožňující vytváření nejrůznějších animací a efektů na stránkách. Mezi nejpopulárnější patří jQuery, MooTools či Prototype a jeho nástavby. JavaScript je také podstatnou součástí technologie AJAX, která je popsána v následující podkapitole.

4.4 AJAX Technologie AJAX umožňuje vytvářet interaktivní webové aplikace, které dokážou měnit obsah svých stránek bez nutnosti opětovného načítání celé stránky ze serveru. Samotný termín AJAX (Asynchronous JavaScript and XML) se poprvé objevil až v roce 2005, ale myšlenky, na nichž je založen, jsou téměř o 10 let starší. O AJAXu se někdy mluví spíše jako o pojmu označujícím použití několika technologií dohromady pro dosažení určitého cíle. Mezi tyto technologie patří:     

HTML (XHTML) a CSS – grafická prezentace dat DOM a JavaScript – dynamické zobrazování informací a interakce s nimi XMLHttpRequest – asynchronní výměna dat se serverem XML, JSON – formát přenášených dat mezi webovým prohlížečem a serverem ASP, PHP – programovací jazyk na straně serveru.

Hlavní výhodou AJAXu je tedy odstranění nutnosti načítání a překreslování celé stránky při každé operaci. Umožňuje získat ze serveru pouze ta data, která jsou opravdu potřeba. Během vykonávání takového požadavku není uživatel rušen novým vykreslováním všech grafických prvků na stránce a také díky tomu získává pocit větší plynulosti práce, která se dnes již někdy blíží nebo i vyrovnává desktopovým aplikacím. Mezi serverem a počítačem se také většinou vyměňuje méně dat, což může mít příznivý vliv jak na vytížení sítě, tak na zátěž samotných serverů. Mezi nevýhody patří především to, že aplikace využívající ve velké míře AJAX se chovají jako plnohodnotné aplikace se složitou vnitřní logikou a nikoliv jako posloupnost webových stránek. V takových aplikacích není příliš možné využívat k navigaci například tlačítko Zpět. Taktéž nejde předat URL stránky změněné pomocí AJAXu. Tyto nedostatky se dají sice pomocí určitých technik odstranit, ovšem za cenu složitějšího návrhu a obtížnější implementace celé aplikace. I přes uvedené negativní vlastnosti je AJAX v současnosti velmi populární a stále více využívaný v moderních webových aplikacích [9].

35

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ

4.5 ASP.NET Technologie popsané v předchozích podkapitolách nedokážou dát webové aplikaci tolik vnitřní logiky, aby se mohla srovnávat s desktopovou aplikací. Něco svede JavaScript, ale za cenu různých komplikovaných výrazů a stejně s ne úplně dokonalým výsledkem. Proto vznikly různé frameworky, což jsou robustní technologie, které pomáhají vytvářet komplexní webové aplikace se složitou vnitřní logikou. Využívají k tomu často klasických programovacích jazyků, jež se běžně využívají i k tvorbě desktopových aplikací. Jednou takovou technologií je ASP.NET, který je součástí většího frameworku, jenž nese název .NET Framework. Ten je produktem společnosti Microsoft a kromě webových aplikací lze pomocí jeho součástí vytvářet aplikace desktopové i mobilní. Zde bude podrobněji popsána pouze technologie ASP.NET.

4.5.1 Výhody a vývoj ASP.NET Její název je odvozen od starší technologie pro vývoj webových aplikací, kterou bylo ASP (Active Server Pages). S ní má ale kromě podobného jména společného jen velmi málo. Liší se například v těchto bodech:  ASP.NET umožňuje lépe oddělit kód vnitřní logiky aplikace od prezentačního kódu. Zpřehledňuje se tím celá aplikace a usnadňuje provádění pozdějších změn.  Způsob tvorby webových aplikací se více blíží technice programování desktopových aplikací a programátorům se tak usnadňuje přechod k webovým aplikacím.  Pro vývoj v ASP.NET existuje kvalitní nástroj Microsoft Visual Studio, který velmi pomáhá při celém průběhu tvorby aplikace.  Je možné vybrat si pro programování aplikace jeden z několika dostupných jazyků. Dnes je již volba pouze mezi C# a Visual Basic .NET. Vzhledem ke komplexnosti této technologie je ale třeba věnovat více úsilí nastudování všech základních principů a technik vývoje aplikací pomocí tohoto frameworku. První verze frameworku .NET a tedy i ASP.NET se objevila v roce 2002 a brzy byla následována verzí 1.1. V roce 2005 pak přišla verze 2.0. a s ní i nový nástroj Microsoft Visual Studio 2005 a velké množství nových funkcí, díky nimž se začala technologie ASP.NET stávat velmi populární. Další přelomovou verzí byla .NET 3.5, která se objevila v roce 2007, jež přinesla například technologii LINQ, která je níže popsána podrobněji, a také integraci AJAX frameworku. V Service Packu 1 pro tuto verzi .NET frameworku se objevuje ADO.NET Entity Framework, která umožňuje nový způsob komunikace s databází a souvisí také s technologií LINQ. Nejnovější verze .NET frameworku nese číselné označení 4.0 a byla vydána v roce 2010 společně s novým Microsoft Visual Studiem 2010.

36

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Jelikož je nemožné nějak stručně popsat všechny principy, vlastnosti a možnosti ASP.NET, je v následující podkapitole podrobněji popsána alespoň technologie LINQ, která je jednou z nejzajímavějších a nejužitečnějších novinek v posledních verzích ASP.NET [10].

4.5.2 LINQ Technologie LINQ (Language Integrated Query) je v podstatě integrovaným jazykem pro dotazování nad různými typy dat, usnadňuje také jejich tvorbu, třídění a vyhledávání v nich. Mezi typy dat, pro něž je LINQ možné využít, se řadí normální objekty, nebo spíše jejich kolekce, dále data v databázích či XML soubory. Podle toho se také LINQ rozděluje do těchto kategorií či podtypů:  LINQ to Objects – dotazování nad kolekcemi objektů.  LINQ to XML – dotazování nad XML soubory.  LINQ to ADO.NET o LINQ to DataSet – umožňuje vytvářet dotazy nad DataSet, což je třída reprezentující databázi. o LINQ to SQL – umožňuje vytvářet dotazy přímo nad MSSQL databází. Dotazy psané v LINQ jsou transformovány na SQL dotazy, které jsou potom posílány a prováděny přímo nad databází. o LINQ to Entities – nejnovější součást technologie LINQ, která vytváří dotazy nad entitním modelem vytvořeným pomocí ADO.NET Entity Framework. Se zveřejněním LINQ to Entities bylo rozhodnuto, že již dále nebude vyvíjeno LINQ to SQL, protože všechnu jeho funkcionalitu poskytuje i LINQ to Entities, které navíc přináší další možnosti a funkce, a bude proto preferovaným typem LINQ pro dotazování nad databázemi. Také zbytek této podkapitoly bude zaměřen na LINQ to Entities. Pro jeho lepší pochopení je však třeba se nejdříve trochu zmínit o ADO.NET Entity Framework. Tato technologie umožňuje převést databázové objekty (typicky tabulky) na objekty .NET, k nimž je poté možné přímo přistupovat v kódu aplikace. Jde také provést vše v opačném směru, kdy jsou nejdříve vytvořeny objekty, z nichž je poté vygenerována databázová struktura. Entity Framework tedy vytváří vrstvu mezi .NET aplikací a databází. Programátor se tak nemusí téměř vůbec starat o komunikaci s databází. Stačí na začátku vývoje jednou nastavit správné parametry spojení a potom už může jednoduše pracovat v aplikaci s objekty a o jejich převedení do databáze se již stará Entity Framework. LINQ to Entities tedy spočívá v dotazování se nad objekty vytvořené podle databáze pomocí Entity Framework. Syntaxe dotazů, která je dále popsána je velmi podobná syntaxím v ostatních kategoriích technologie LINQ. Cílem dotazu je nejčastěji vybrat některé prvky z databáze na základě definovaných kritérií. Klíčová slova dotazů jsou téměř totožná s těmi, které jsou využívané v klasických SQL dotazech.

37

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Prvním takovým slovem je select. Za ním následuje typ objektu nebo atribut objektu, který má být vybrán. Na rozdíl od SQL dotazů se slovo select klade až na samotný konec dotazu. Další slovo from určuje, nad kterými objekty má být dotaz prováděn. Slovo where uvozuje část dotazu, kde jsou stanoveny podmínky, podle nichž jsou vybrány vyhovující objekty. Následovat může seřazení vybraných objektů pomocí spojení orderby. Dotaz tedy může vypadat takto: var books = from b in LibraryEntities.Book where b.PublishYear > 2005 orderby b.Name select b; Tento dotaz vybere z databáze z tabulky Book všechny knihy, které byly vydány od roku 2006 až do současnosti, a seřadí je podle jejich jména. Za slovem from se objevuje proměnná b, která zastupuje jednotlivé objekty z tabulky Book. Spojení za slovem in říká, kde se tyto objekty nachází. LibraryEntities je tedy databáze převedená pomocí Entity Framework do objektů a je v aplikaci zastoupena dvěma soubory. Prvním je LibraryEntities.edmx, v němž jsou graficky znázorněny jednotlivé objekty a vazby mezi nimi, druhým je pak Library.designer.cs v němž jsou pomocí tříd jednotlivé objekty definovány. Výsledkem dotazu je tedy kolekce objektů typu Book. Pokud by bylo třeba vybrat jména všech knih v databázi, dotaz by vypadal následovně: var bookNames = from b in LibraryEntities.Book select b.Name; V tomto případě již výsledem není kolekce knih, ale pouze kolekce jejich jmen. Kromě toho je možné vytvářet v dotazech i anonymní typy. Pokud se za slovem select uvede výběr atributů, které se mají ve výsledku objevit, není tímto výsledkem ani kolekce hodnot jednoho konkrétního atributu, ani kolekce celých instancí, ale výsledné prvky vložené do kolekce mají právě anonymní typ. Jestliže se mají vybrat pouze dvojice název knihy a rok vydání, je možné výsledku docílit takto: var namesAndYears = from b in LibraryEntities.Book select new {b.Name, b.PublishYear}; Za zformulovaný dotaz je možné také přidávat nejrůznější funkce, které mohou ovlivnit, co bude nakonec výsledkem dotazu. Mezi nejvyužívanější patří:  Sum, Min, Max, Average, Count – agregační funkce umožňující vykonat příslušné matematické operace na výsledcích dotazu. Následující dotaz vrací spolu s funkcí Count počet všech knih v databázi: var bookCount = (from b in LibraryEntities.Book select b).Count(); 

Take, Skip – funkce umožňující omezit počet vrácených objektů. Take určuje, kolik prvků se má vrátit jako výsledek, Skip naopak definuje počet prvků, které

38

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ se mají přeskočit, a vrací zbytek. Následující příklad vrací prvních 5 knih s nejvyšším počtem stran: var thickestBooks = (from b in LibraryEntities.Book orderby b.NumberOfPages descending select b).Take(5); Slovo descending v dotazu označuje sestupné seřazení. Pokud by bylo třeba řadit vzestupně, využívá se slova ascending. 

Single, SingleOrDefault – umožňuje vrátit právě jednu instanci jako výsledek dotazu. Dá se využít v případě, kdy se jako výsledek pouze jedna instance očekává a je vhodné místo kolekce obsahující jeden prvek získat tento prvek samostatně s konkrétním typem. V případě, že dotaz nevrátí žádný prvek, nebo naopak více než jeden a je použita funkce Single, dojde k vyhození výjimky. Tento problém odstraňuje funkce SingleOrDefault, která v takovém případě vrátí přednastavenou hodnotu. V následujícím dotazu je vybrána kniha, jejíž id je 10: Library.Book book = (from b in LibraryEntities.Book where b.Id == 10 select b).Single();



First, FirstOrDefault – funguje velmi podobně jako funkce Single a SingleOrDefault. Rozdíl je pouze v tom, že vždy vrací první prvek ze všech dotazem vybraných prvků. Nevyhodí tedy výjimku, respektive nevrátí přednastavenou hodnotu v případě, že dotaz vrací více než jeden prvek, ale pouze pokud není vrácen žádný prvek.

Kromě výběru prvků z databáze je však často třeba také prvky do databáze vkládat, měnit či z databáze mazat. S využitím LINQ to Entities a Entity Framework je to však poměrně jednoduchá záležitost. Při vkládání nového prvku do databáze je třeba nejprve klasicky vytvořit novou instanci objektu, například takto: Library.Book book = new Library.Book(); Poté se do jednotlivých atributů objektu vloží potřebné hodnoty a na závěr se instance uloží jako nový prvek do databáze pomocí následujících příkazů: Library.Entities entities = new LibraryEntities(); entities.Book.AddObject(book); entities.SaveChanges();

39

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ Jak je vidět, není vkládání do databáze nikterak složité. Podobné je to se změnami údajů v databázi. Následující příklad ukazuje změnu údaje o roku vydání u knihy s id = 10. Nejprve je třeba vybrat požadovaný prvek pomocí LINQ dotazu: Library.Book book = (from b in LibraryEntities.Book where b.Id ==10 select b).Single(); Následně se u knihy změní požadovaný údaj: book.PublishYear = 2010; A na závěr se opět změny uloží do databáze: Library.Entities entities = new LibraryEntities(); entities.SaveChanges(); I mazání v databázi je jednoduché. Jestliže je například potřeba odstranit knihu opět s id = 10, vybere se nejprve kniha z databáze stejně jako v předchozím příkladu. Potom se vymaže následujícími příkazy: Library.Entities entities = new LibraryEntities(); entities.DeleteObject(book); entities.SaveChanges(); Ze všech zde uvedených příkladů je jistě vidět, že technologie LINQ je velikým přínosem pro vývoj nejen webových aplikací. Kromě zde uvedených funkcí poskytuje mnoho dalších, které mohou ještě více tvorbu aplikací usnadnit. Dá se navíc očekávat další vývoj této technologie v následujících verzích .NET Frameworku, a proto je použití této technologie při programování aplikací dobrou volbou [10].

4.6 Java EE Dalším velmi rozšířeným frameworkem pro tvorbu webových aplikací je Java EE (Java Platform, Enterprise Edition). Je rozšířením platformy Java SE (Standard Edition) o podporu webových aplikací, webových služeb a distribuovaných vícevrstvých aplikací. V současnosti existuje tato platforma ve verzi 6. Java EE je velice robustní framework se spoustou dílčích technologií. S tím souvisí výhody i nevýhody oproti ASP.NET. Programátor si může vybrat z více možností, jakým způsobem bude aplikaci vyvíjet, což v případě ASP.NET kromě volby programovacího jazyka není tolik možné. Na druhou stranu je mnohem těžší se v tomto větším počtu možných přístupů

40

4. TECHNOLOGIE PRO TVORBU WEBOVÝCH APLIKACÍ k vývoji zorientovat a tím pádem může být někdy obtížné vybrat skutečně tu nejlepší technologii. Na úrovni prezentační vrstvy zodpovědné za zpřístupnění funkcionality aplikace uživateli se v současnosti nejvíce využívají technologie JavaServlets a JSP (JavaServer Pages). Poměrně často se používají také různé webové aplikační rámce. Ty mohou být založeny na požadavcích (příkladem jsou technologie Struts, Stripes, Spring MVC), nebo na vizuálních komponentách (například JSF nebo Tapestry). Jestliže má být aplikace součástí nějakého portálu agregujícího různé aplikace, využívají se někdy Java Portlets. V aplikační vrstvě, která zajišťuje vlastní funkcionalitu programu, se používají nejvíce EJB nebo Spring. Pro komunikaci aplikační vrstvy s databází se využívají nástroje jako Hibernate či Java Persistence API. Přestože výčet dostupných technologií není rozhodně úplný, je jasně vidět, že programátor má vždy z čeho vybírat, a také to, že na vytvoření kvalitní aplikace nedostačuje nikdy pouze jedna technologie. V oblasti Java EE je mnoho produktů open-source softwarem, což může být příjemné například z hlediska nulové ceny produktů. Nevýhodami jsou však občas větší množství chyb či nedostatečná dokumentace a podpora, což může někdy prodlužovat dobu vývoje aplikace. Nakonec je tedy na každém, kdo nějakou aplikaci vytváří, aby si zvolil, který způsob tvorby webové aplikace je mu bližší, protože každý má svá pro a proti, a říci obecně, že jeden je lepší, a proto by se měl používat, není možné [11].

4.7 Další současné technologie Při výběru technologií pro tvorbu webové aplikace není programátor omezen pouze na dva výše popsané frameworky. Existuje několik dalších možností, jak aplikace vyvíjet, z nichž některé stojí ještě alespoň za krátkou zmínku. Jednou z nich je například skriptovací programovací jazyk PHP, který již roky patří k nejpopulárnějším způsobům, jak tvořit webové aplikace. V současnosti existuje ve verzi 6 a programátoři mohou využívat několik kvalitních frameworků (například Zend či Yii) pro usnadnění vývoje aplikací psaných v tomto jazyce. Další možností je pro vývoj aplikace použít framework Ruby On Rails. Je postaven na programovacím jazyku Ruby, objevil se v roce 2004 a poskytuje také vše potřebné pro rychlé vytváření webových aplikací od abstraktní vrstvy pro práci s databází až po generátory samotného kódu. Přestože je tato technologie relativně mladá, využívá se již v mnoha projektech a mohla by ji čekat příjemná budoucnost. Dalo by se mnohem déle hovořit o všech uvedených technologiích, ale i dalších, které nebyly zmíněny. Webové aplikace jsou v současnosti zkrátka v kurzu a s nimi i technologie pro jejich tvorbu. Až další roky ukážou, zda se na výsluní udrží nebo budou vystřídány ještě něčím lepším.

41

Kapitola 5

Webová aplikace pro plánování dětských táborů Praktickou část této práce jsem se rozhodl věnovat vytvoření webové aplikace pro plánování dětských táborů pomocí etap vývoje a některých technologií popsaných v předchozí kapitole. V následujících podkapitolách je tedy postupně popsán vývoj aplikace od motivace pro její vytvoření až po samotnou implementaci a možnosti dalšího rozšíření do budoucna.

5.1 Motivace Na myšlenku vytvořit takovou aplikaci mě přivedly vlastní zkušenosti s pořádáním dětských táborů. Pokud má být tábor kvalitní, je třeba jej začít včas a důkladně připravovat. V případě, že by měl program na starost pouze jeden člověk, není třeba komunikaci mezi vedoucími řešit. To se však v praxi téměř nestává. Téměř vždy jsou jednotlivé programové bloky rozděleny mezi vedoucí, kteří se tábora účastní. Jestliže jsou navíc z různých míst, která jsou od sebe více vzdálena, osobní kontakt a domluva bývají omezeny na pár dní během roku nebo krátkou dobu před samotným táborem. Během nich není často možné všechno dopodrobna vymyslet, objevit různé nedostatky či představit potom jednotlivé připravené části programu ostatním tak, aby se zjistilo, zda neexistují dva podobné programové bloky vymyšlené různými vedoucími, nebo jestli daná část zapadá do celkového programu tábora. Výstupy z těchto společných setkání je pak třeba rozeslat nejčastěji emailem v několika různých dokumentech, a pokud chce někdo provést nějakou změnu, je třeba je opět poslat všem ostatním, aby měl každý aktuální verzi všech plánů. Není též možné ihned prodiskutovat takovou změnu či nějaký nový nápad s ostatními, pokud zrovna vedoucí nejsou pohromadě. Všechna tato úskalí by mohla pomoci odstranit webová aplikace, která by uživatelům umožňovala vytvořit program tábora, jehož se účastní. Ten by pak byl pro všechny vedoucí přístupný a mohli by v něm provádět jakékoliv změny, doplňovat nové informace a diskutovat také o různých nápadech na jeho vylepšení. Součástí aplikace by také mohla být databáze táborových aktivit a zveřejněných táborových programů, kde by uživatelé mohli čerpat inspiraci. Od této myšlenky bylo třeba přejít ke zvážení, zda by taková aplikace mohla být užitečná pro větší množství uživatelů. Také bylo vhodné zjistit, zda již nějaká podobná aplikace neexistuje a jaké má případně funkce a nedostatky. Provedení těchto úkonů spolu s hlavními požadavky na novou aplikaci je popsáno v následující podkapitole.

42

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

5.2 Specifikace požadavků Před samotným sepsáním požadovaných funkcí, jež by měla aplikace poskytovat, bylo důležité, jaké možnosti již v této oblasti existují a jestli aplikace může přinést něco nového. Jak se ukázalo, možností není příliš a za zmínku stojí asi pouze Google Calendar, který by k naplánování programu šel jistě použít. Neposkytuje však již pochopitelně žádnou databázi aktivit či možnost prohlížet jednoduše zveřejněné programy táborů. Databází aktivit a programů lze najít několik. Jednou z největších a nejvyužívanějších u nás je v současnosti zřejmě Hranostaj.cz. U táborových programů je situace horší, na několika místech lze pár programů najít, ale větší množství se pohromadě nevyskytuje. Z těchto pozorování vyplývá, že nic, co by odpovídalo zamýšlené aplikaci a mělo pohromadě všechny požadované funkce, neexistuje. Z tohoto pohledu by tedy rozhodně mělo smysl aplikaci vytvářet. Druhou otázkou bylo, zda by taková aplikace našla uplatnění mezi větším počtem uživatelů. Ke zjištění této informace a také některých dalších názorů uživatelů jsem se rozhodl využít dotazník, který jsem vytvořil a poté požádal o jeho vyplnění vedoucí jezdící v současnosti nebo i dříve na tábory.

5.2.1 Vyhodnocení dotazníků Dotazník, který byl vyplňován, měl dvě části. V první dotazovaní odpovídali na otázky, které se týkaly charakteristiky táborů, které připravují nebo v minulosti připravovali, způsobů komunikace mezi vedoucími a čerpání inspirace při tvorbě táborových aktivit. Tato část obsahovala následující dotazy:            

Připravuješ v současnosti tábory? Jak dlouho tábory připravuješ? Pro jaký počet dětí tábory většinou připravujete? Pro jakou věkovou kategorii tábory většinou připravujete? Jaký typ táborů většinou pořádáte? Jak dlouho většinou vaše tábory trvají? Jak velký tým vedoucích máte? Jaké funkce jsi už někdy na táboře zastával? Jakým způsobem tábory připravujete? Jakým způsobem a jak často spolu komunikujete při přípravě? Kde a jak často čerpáte inspiraci při vymýšlení táborových aktivit? Používáte při plánování nějaký harmonogram dne a rozvrh jednotlivých dní s programovými bloky?

43

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Ve druhé části dotazníku následovalo několik otázek, které zjišťovaly názory dotazovaných na potencionální aplikaci pro plánování táborů. Aplikace byla nejdříve stručně popsána takto: Vytvořená aplikace by měla pomoci při plánování táborů. Uživatelé budou moci vytvořit v aplikaci svůj tábor, přidat k němu ostatní vedoucí a společně potom tvořit program tábora. Základem by měl být rozvrh tábora, ve kterém si vytvoří jednotlivé programové bloky. Z rozvrhu povedou odkazy na jednotlivé stránky s konkrétními aktivitami, na nichž budou informace o aktivitě i její popis. Uživatelé budou moci editovat aktivity a také si je například brát na starost. Bude možné vytvářet i další dokumenty související s táborem. Součástí aplikace by měla být i databáze táborových aktivit a programů starších táborů, ze kterých by bylo možné se inspirovat. Následovaly tyto otázky:     

Na základě tohoto popisu, dokážeš si představit, že byste tuto aplikaci v budoucnu využívali? Myslíš, že by vám aplikace mohla nějak usnadnit a zefektivnit plánování tábora? Myslíš, že by se aplikace mohla stát vaším primárním prostředkem pro plánování tábora? Co všechno by měla aplikace umět a poskytovat? Znáš nebo používáš nějakou podobnou aplikaci? Pokud ano, jakou?

Na většinu otázek se odpovídalo zaškrtnutím vyhovující odpovědi, u některých byla umožněna odpověď vlastními slovy. Dotazník vyplnilo celkem 214 lidí, z toho 110 mužů a 104 žen. Zde budou podrobně prezentovány pouze odpovědi na některé otázky. Všechny otázky a odpovědi na ně jsou dostupné na CD přiloženém k této práci. Přes dvě třetiny dotazovaných v současnosti stále tábory připravuje. Nejčastěji jsou připravovány tábory pro 16 – 30 dětí. Věk táborníků se pohybuje nejvíce mezi 9 a 15 lety. Otázka ohledně délky táborů byla důležitá, kvůli pozdější implementaci rozvrhu tábora v aplikaci. Výsledky jsou zobrazeny v grafu 5.1 a ukazují, že nejčastěji jsou pořádány tábory, které trvají jeden až dva týdny. Odpovědi na otázku týkající se počtu vedoucích byly pestré, nejvíce se však vyskytoval počet 5 – 10 vedoucích. Jak je patrné z grafu 5.2, nemalá část dotazovaných zvolila možnost 15 – 25 vedoucích, což už je počet, při němž není snadné docílit většího množství setkaní kvůli plánování tábora tak, aby byli přítomni všichni členové týmu. V těchto případech by mohla aplikace jistě pomoci. U otázky způsobu přípravy táborů byla téměř v 90 % zvolena možnost, že je program plánován během celého roku nebo alespoň jeho části a tedy ne těsně před táborem.

44

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Graf 5.1: Počty odpovědí (osa x) na otázku ohledně délky tábora

Graf 5.2: Odpovědi na otázku týkající se počtu vedoucích na táboře

Graf 5.3: Četnost osobního kontaktu při přípravě tábora

45

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Graf 5.4: Četnost emailové komunikace při přípravě tábora

Graf 5.5: Četnost využití instant messagingu při přípravě tábora V další otázce, která se týkala komunikace mezi vedoucími, byly podstatné odpovědi na četnost osobního kontaktu a využívání emailů či instant messagingu (například ICQ). Ty jsou zobrazeny v grafech 5.3 – 5.5 a potvrzují, že osobně není možné komunikovat příliš často a tak je to nahrazováno právě elektronickou formou. Aplikace by mohla ještě více elektronickou formu komunikace zefektivnit. V poslední otázce první části, jež se týkala čerpání inspirace při tvorbě táborových aktivit, byly odpovědi poměrně rovnoměrně rozděleny. Zastoupena byla poměrně hodně také varianta hledání inspirace na internetu, čemuž by mohla aplikace také pomoci. Odpovědi na otázky z druhé části dotazníku potvrdily, že aplikace by mohla být užitečná a také využívaná větším počtem uživatelů. Více než 90 % dotazovaných si myslí, že by aplikace určitě nebo alespoň možná mohla usnadnit a zefektivnit plánování tábora. Pro 60 % dotazovaných by se mohla aplikace stát primárním prostředkem pro plánování táborů, nicméně osobní komunikaci nemůže předčit, s čímž se nedá nic jiného než souhlasit. Pro asi čtvrtinu dotazovaných by aplikace byla alespoň doplňkem při plánování táborů. Jednotlivé odpovědi a jejich počty jsou zobrazeny v grafech 5.6 – 5.8.

46

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Graf 5.6: Odpovědi na otázku ohledně potencionálního používání aplikace

Graf 5.7: Odpovědi na otázku o usnadnění a zefektivnění plánování tábora

Graf 5.8: Odpovědi na otázku, zda by mohla být aplikace primárním prostředkem pro plánování tábora

47

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Na otázku, zda již dotazovaní využívají nějakou aplikaci pro plánování táborů, téměř všichni odpověděli záporně. Pouze několik odpovědí bylo kladných s dodatkem, že občas využijí aplikace od Google, například Google Docs pro tvorbu táborových dokumentů. Výsledky dotazníku tedy potvrdily moje domněnky o tom, že aplikace by mohla být přínosem, a proto bylo možné začít se samotným vývojem, na jehož začátku bylo třeba sepsat požadované funkce aplikace.

5.2.2 Požadované funkce V této části jsou sepsány základní funkce aplikace rozdělené do několika kategorií. Databáze aktivit  vytvoření nové aktivity  změna údajů vložené aktivity  prohlížení aktivit  vyhledávání aktivit Databáze zveřejněných programů táborů  prohlížení zveřejněného programu  prohlížení táborových aktivit a legendy ve zveřejněném programu  vyhledávání programu Tvorba táborového programu  vytvoření nového tábora  změna údajů o vytvořeném táboře  přidání nebo odebrání vedoucích z tábora  vytvoření, editace a mazání aktivity v programu tábora  vytvoření, editace a mazání legendy tábora  vytvoření, editace a mazání táborových dokumentů  zadávání úkolů vedoucích  zobrazení programu tábora, všech událostí a úkolů vedoucích Přímo od potencionálních uživatelů vzešel ještě před začátkem vývoje požadavek na možnost psaní komentářů a poznámek v některých částech aplikace. Tuto funkci nebylo v plánu v první verzi aplikace implementovat, ale na základě tohoto požadavku je nakonec v aplikaci také. Po sepsání těchto základních funkčních požadavků bylo možné pomalu přejít k návrhu aplikace.

48

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

5.3 Návrh aplikace Cílem návrhu aplikace bylo definovat, jaké typy uživatelů budou v aplikaci existovat, jaké funkce budou mít jednotlivé skupiny dostupné a také jakým způsobem bude uživatelské rozhraní tyto funkce poskytovat. Bylo též potřeba navrhnout strukturu databáze pro ukládání všech dat aplikace. Pro jednotlivé části návrhu byly použity různé metodiky a typy diagramů, které jsou v následujících podkapitolách popsány. Na některých diagramech se také objevuje slovo Táborovač, což je navržený název aplikace.

5.3.1 Diagram případů užití Diagram případů užití (obrázek 5.1) patřící do metodiky UML, definuje jednotlivé role, v nichž mohou uživatelé aplikace být. Každá role má definovánu sadu případů užití. Některé případy užití se nachází ve více rolích, jiné jsou specifické pouze pro jednu konkrétní roli. Sjednocení všech případů užití v podstatě kopíruje požadované funkce aplikace. Základní rolí aplikace je Návštěvník webu, což je například uživatel, který se k aplikaci dostane poprvé. Ten má možnost v aplikaci prohlížet a vyhledávat aktivity a také zveřejněné táborové programy. Kromě toho má možnost se v aplikaci zaregistrovat. Po registraci a přihlášení se dostává do nové role, kterou je Registrovaný návštěvník. K funkcím, které měl dostupné již v předchozí roli, se přidává možnost vytvářet nové aktivity či editovat již vytvořené aktivity. Tato role také umožňuje uživateli založit nový tábor. Tím se dostává do role Zakladatel tábora, jež umožňuje měnit údaje o táboře, zveřejnit táborový program všem uživatelům aplikace a také přidávat do vytvořeného tábora vedoucí, nebo je naopak odebírat. Všichni vedoucí, kteří jsou zakladatelem přidáni, se dostávají do role Člen tábora. Jak Zakladatel tábora, tak Člen tábora přebírají všechny případy užití, které náleží k roli Registrovaný návštěvník. To je na diagramu znázorněno příslušnými šipkami mezi jednotlivými rolemi. Kromě těchto případů užití mají role Člen tábora a Zakladatel tábora množinu dalších. Patří sem například vytvoření táborové události, její editace a mazání, či tvorba táborového dokumentu. Všechny případy užití jsou zobrazeny na diagramu. Jak je již odsud patrné, bude třeba navrhnout uživatelské rozhraní tak, aby byly příslušným rolím dostupné vždy jen povolené funkce.

5.3.2 Datový a hypertextový model metodiky WebML Pro návrh uživatelského rozhraní aplikace jsem se rozhodl využít metodiku WebML. Zde bude více popsán a částečně vyobrazen pouze hypertextový model, který vznikl spojením modelu kompozice webové aplikace a navigačního modelu. Diagram datového modelu WebML a také celý hypertextový model aplikace je dostupný na přiloženém CD. Přímo v práci není

49

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.1: Diagram případů užití

50

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ vše vyobrazeno, neboť nebylo možné docílit rozumné čitelnosti diagramů z důvodu jejich velikosti. Datový model zde není podrobněji popisován, neboť v podstatě odpovídá entitně-relačnímu diagramu, který je popsán později. Za zmínku stojí pouze to, čím se liší. Jednak je to tedy opačný zápis kardinalit, jak již bylo dříve zmíněno. Dalším rozdílem jsou odlišné typy některých atributů jednotlivých entit, neboť datový model WebML neposkytuje všechny typy, které jsou použité v ERD a posléze i v samotné aplikaci. Největší rozdíl je pak v části definující strukturu pro ukládání dat o uživatelích. V datovém modelu je tato struktura zastoupena pouze entitou User, zatímco v ERD je již rozpracována více na základě potřeby později použitých technologií. Pro přehlednost nejsou v diagramu uvedeny minimální kardinality vazeb, protože jsou v podstatě ve všech případech rovny nule. Hypertextový model se skládá ze dvou Site Views, tedy dvou podmodelů, z nichž každý zobrazuje odlišný pohled na uživatelské rozhraní aplikace. První (obrázek 5.2) definuje rozhraní pro neregistrovaného či nepřihlášeného uživatele, druhý naopak rozhraní, které má být dostupné registrovaným a přihlášeným uživatelům. Na prvním diagramu jsou zobrazeny tři Areas, kterými jsou Taborovac, Camps, Activities. Ty představují jednotlivé části aplikace dostupné pro neregistrované uživatele. Každá sekce obsahuje jednu Master Page, v níž jsou pak umístěny jednotlivé stránky se svými Units. V Master Pages v jednotlivých sekcích je možné najít Units CampsOverviewBox a ActivitiesOverviewBox, které tím pádem mají být ve výsledku součástí každé stránky obsažené v dané Master Page. Šipky ukazují, jakým způsobem jsou stránky provázány. Nekontextové odkazy, tedy možnost přechodu na jinou stránku například kliknutím na odkaz v menu, kdy se mezi stránkami nepřenáší žádné informace, nejsou v diagramech zobrazeny. Z každé stránky je totiž tímto způsobem možno přejít na několik stránek jiných a přidání všech těchto odkazů by graf naprosto znepřehlednilo. U kontextových odkazů nejsou uváděny parametry, protože jsou předávány implicitní parametry, kterými jsou id jednotlivých instancí entit. V každé sekci se také nachází Unit Login, pomocí níž se může uživatel přihlásit. Tím pro něj začíná platit druhý Site View, který má jednu novou Area nazvanou MyCamp, které v aplikaci slouží pro plánování táborů. Celý Site View přihlášeného uživatele je na CD. Na obrázku 5.3 je zobrazena alespoň část sekce MyCamp, kde je vidět stránka MyCamp, která zobrazuje program tábora. Na ní je možné otevřít podstránky umožňující přidat nebo editovat táborové události. Stejně tak jsou na tomto výřezu vidět stránky pro zobrazení detailů o události či stránky pro přidání, odebrání a zobrazení úkolů vedoucích (AddRemoveTask, InstructorTasks). Části, které jsou vidět pouze na modelu na CD, definují strukturu mnoha dalších stránek, jež plní všechny funkce ze specifikace požadavků. V modelu nejsou opět z důvodu přehlednosti zahrnuty Units zodpovědné za funkci umožňující vkládání, editací a mazání příspěvků. Jsou však zobrazeny zvlášť na obrázku 5.4. V modelu by patřily do stránek Comments, Activity, MyCamp, PublicCamp, Event, Document a Legend v Site View přihlášeného uživatele. Vytvořením modelů metodiky WebML jsem tedy navrhl strukturu uživatelského rozhraní aplikace. Pro dokončení návrhu ještě zbývalo vytvořit ERD.

51

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.2: Hypertextový model – Site view nepřihlášeného uživatele

52

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.3: Hypertextový model – část Site view přihlášeného uživatele

53

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.4: Část hypertextového modelu definující zobrazení a práci s příspěvky

5.3.3 Entitně-relační diagram Přestože již datový model WebML definuje datovou strukturu aplikace, rozhodl jsem se ještě vytvořit entitně-relační diagram, který umožňuje navrhnout strukturu databáze o něco přesněji třeba díky tomu, že dokáže přesněji definovat typy jednotlivých atributů. Na rozdíl od datového modelu WebML také zobrazuje kardinality tak, jak je to obvyklé, což ho činí o něco srozumitelnějším. Diagram v celku je k dispozici na přiloženém CD, zde jsou odděleně zobrazeny jeho tři hlavní části. První z nich je část databázové struktury ukládající data, která souvisí s táborovými aktivitami (obrázek 5.5). Struktura je poměrně jednoduchá a obsahuje tyto entity:  Activity – představuje táborovou aktivitu.  aspnet_Users – entita představující uživatele. Je více popsána později. Vazba mezi ní a entitou Activity definuje, že každá aktivita je vytvořena jedním uživatelem a každý uživatel může vytvořit 0 až N aktivit.  CommentActivity – první z entit představujících komentáře v jednotlivých částech aplikace.  ActivityMainCategory, ActivityCategory, ActivityPlace – entity představující různé kategorie umožňující upřesnit zařazení aktivit  MainCategoryOfActivity, CategoryOfActivity, PlaceOfActivity – vazební entity představující vztah mezi aktivitou a příslušnou kategorií. Určují, do jakých kategorií je každá aktivita zařazena.

54

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.5: část ERD související s táborovými aktivitami

55

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Druhou a nejrozsáhlejší částí je ta, která definuje strukturu pro ukládání všech dat, jež se týkají plánování táborů (obrázek 5.6). Aby se diagram vlezl v čitelné formě na stránku, jsou v entitách uvedeny pouze primární a cizí klíče. Všechny atributy jsou definované na celkovém diagramu na CD. Zde jsou tedy zobrazeny tyto entity:  Camp – představuje založený tábor.  aspnet_Users – stejná entita jako v předchozí části diagramu. Představuje uživatele. Stejně jako u aktivit je tábor založen jedním uživatelem a každý uživatel může založit 0 až N táborů.  CampMember – vazební entita určující, kteří uživatelé jsou členy jednotlivých táborů.  InstructorTask – představuje úkoly vedoucích na táboře. Jeden vedoucí může mít více úkolů.  Event – entita představující táborovou událost (např. hra, rozcvička, oběd).  ActivityMainCategory, ActivityCategory, ActivityPlace – entity obsažené i v předchozí části diagramu. Táborové události tedy mohou být zařazeny do stejných kategorií jako aktivity.  MainCategoryOfEvent, CategoryOfEvent, PlaceOfEvent – vazební entity představující vztah mezi táborovou událostí a příslušnou kategorií. Určují, do jakých kategorií je každá událost zařazena.  EventInstructor – vazební entita představující vztah mezi táborovými události a vedoucími, kteří jsou za ně zodpovědní. Každou událost může mít na starost 0 až N vedoucích a podobně každý vedoucí může být přiřazen k 0 až N událostem.  Legend – entita představující táborovou legendu (celotáborový příběh). Každý tábor má právě jednu legendu.  Document – představuje táborový dokument, do nějž mohou vedoucí vkládat nejrůznější informace. Každý tábor může mít 0 až N dokumentů.  CommentCamp, CommentPublicCamp, CommentEvent, CommentLegend, CommentDocument – entity podobné CommentActivity z předchozí části diagramu. Představují komentáře v různých oblastech aplikace (např. táborový program, jednotlivé události, dokumenty). Poslední část ERD (obrázek 5.7) není ani tak návrhem databázové struktury, jako spíše jejím pouhým zobrazením. Tuto strukturu totiž vytváří samotný .NET Framework, který tak jednoduše umožňuje registraci uživatelů a správu jejich účtů. Programátor tuto strukturu nemusí nijak vymýšlet, neboť je již optimálně navržena a automaticky vytvořena, pokud je potřeba. O využití technologie ASP.NET při tvorbě aplikace je více napsáno později. Přestože tedy tato část nebyla v rámci vývoje aplikace nijak navrhována, stojí jistě za zmínku alespoň ty entity, které aplikace využívá.

56

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.6: část ERD týkající se táborů a jejich plánování

57

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ

Obrázek 5.7: Databázová struktura pro ukládání dat o uživatelích

58

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Mezi tyto entity patří:  aspnet_Users – stěžejní entita již známá z předchozích částí ERD představující uživatele aplikace.  aspnet_Roles – entita, která představuje uživatelské role (např. administrátor, registrovaný uživatel).  aspnet_UsersInRoles – vazební entita představující vztah mezi uživatelem a rolí. Určuje, kteří uživatelé jsou v jednotlivých rolích.  aspnet_Membership – umožňuje ukládat podrobné informace týkající se především hesel uživatelů  aspnet_Profile – umožňuje ukládat programátorem definované údaje o uživatelích  aspnet_Application – databáze může sloužit pro ukládání dat z více aplikací. Tato entita tedy představuje aplikace, jejichž uživatelé jsou v databázi vloženi. Dokončením ERD byla završena celá fáze návrhu aplikace. V této chvíli bylo možné přejít k vytvoření databázové struktury a poté k programování logiky aplikace a jejího uživatelského rozhraní s využitím vytvořených modelů a diagramů.

5.4 Implementace aplikace Samotné programování aplikace jistě není možné a ani potřebné do detailů popisovat. Stojí ale za to zastavit se u některých bodů implementace a problémů a otázek, které se v této fázi objevily.

5.4.1 Použité technologie Velmi podstatné bylo před začátkem vývoje zvolit vhodné technologie pro vytvoření aplikace. Pro programování aplikace jsem se rozhodl využít .NET Framework. Přestože jsem s ním neměl příliš zkušeností, přišel mi daleko přívětivější a snadnější pro pochopení než Java EE. Ač jsem se s programovacím jazykem Java setkal dříve vícekrát, poslední zkušenost s vývojem webových aplikací pomocí technologií spadajících do Java EE mě utvrdila v tom, že výběr .NET Frameworku byl dobrou volbou. Při vývoji pomocí Java EE se mi nejednou stalo, že jsem několik hodin musel nastavovat prostředí pro vývoj a běh aplikace, neboť z pro mě neznámých důvodů se do té doby fungující nastavení změnilo v nefunkční, aplikační server odmítal spustit aplikaci a podobně. Hledání řešení těchto problémů spotřebovávalo čas, který mohl být využit pro samotný vývoj aplikace. Toto se během vývoje pomocí ASP.NET nestalo. Téměř celou dobu bylo možné soustředit se na programování aplikace. Jako vývojové prostředí jsem používal Microsoft Visual

59

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Studio 2010, které mimo jiné obsahuje lokální webový server, na němž je možné jednoduše spouštět aplikace při vývoji a testování. Umožňuje také vytvořit spojení s databází a vytvářet a upravovat její strukturu a uložená data. Při výběru databázového systému padla asi vcelku pochopitelně volba na Microsoft SQL Server 2008, s nímž si .NET Framework přece jen nejvíce rozumí. Po vybrání technologií již nic nebránilo vytvoření databázové struktury a psaní samotného kódu aplikace.

5.4.2 Programování aplikace Nejdříve jsem se rozhodoval o názvu aplikace, neboť bylo pravděpodobné, že název bude třeba pro pojmenování některých součástí aplikace. Rozhodl jsem se nakonec pro název Táborovač, který již byl několikrát použit i v návrhu, protože jsem o něm uvažoval už od začátku celého vývoje aplikace. Pro správné fungování každé části aplikace bylo nutné mít nejdříve vytvořeny potřebné tabulky v databázi. Jakmile bylo toto splněno, mohlo se začít s programováním jednotlivých stránek aplikace. Na začátku se musel vytvořit jednotný vzhled stránek. Rozhodl jsem se pro tento účel mimo jiné využít některých vlastností CSS 3. Chtěl jsem, aby byly stránky veselé a odpovídaly svému zaměření, proto je aplikace velmi barevná. Je ale vytvořena tak, že není nijak těžké v budoucnu definovat nový vzhled, který třeba tolik barevný nebude. Pro dosažení jednotného rozložení některých prvků na stránkách jsem využil master pages, které jsou jakoby šablonou pro určitou skupinu stránek. K práci s daty v databázi jsem využíval LINQ to Entities, které se ukázalo jako opravdu kvalitní technologie a značné usnadnění vývoje aplikace. Při programování funkční logiky aplikace jsem kód psal do code behind souborů jednotlivých stránek, které mají příponu .aspx.cs. Díky tomu nedocházelo k takovému promíchání kódu s kódem definujícím vzhled stránek přímo v souboru .aspx. Funkční logika byla psána v jazyce C#. Jako první jsem vytvořil část aplikace pracující s aktivitami. V ní nebyly žádné komplikovanější funkce. Bylo pouze důležité vymyslet přehledné zobrazení informací o aktivitách a také naprogramovat správně funkci pro vyhledávání aktivit tak, aby dokázala vracet odpovídající výsledky podle libovolného množství zadaných kritérií. Poté jsem se dal do programování nejdůležitější části aplikace, kterou byly všechny funkce související s vytvářením táborového programu. Zde mi velmi pomohla knihovna DayPilot, která je podrobněji popsána později. Umožnila snadné vytváření programové tabulky a také díky ní nebylo těžké doprogramovat funkce pro vytváření a úpravu táborových událostí. Vytváření a editace událostí má hodně společného se správou aktivit, což urychlilo vývoj některých funkcí. Postupně byly také implementovány zbývající funkce, například ty pro správu táborových dokumentů. Při programování jsem průběžně testoval všechny funkce a snažil se odhalit možné chyby.

60

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Po dokončení této nejrozsáhlejší části aplikace jsem ještě vytvořil stránky, které se měly starat o zobrazování zveřejněných táborových programů. Na závěr jsem implementoval funkcionalitu umožňující vkládat a zobrazovat příspěvky na některých místech aplikace.

5.4.3 Struktura aplikace Databázová struktura vytvořené aplikace odpovídá ERD, takže není nutné ji nijak více popisovat. Visual Studio ji jednoduše umožnilo převést do souborů, které využívá LINQ to Entities pro komunikaci s databází. Přesnou strukturu všech adresářů a souborů aplikace je samozřejmě možné vidět a procházet na přiloženém CD. Zde je uveden pouze stručný popis jednotlivých částí této struktury:  Taborovac – adresář obsahující celou aplikaci. Obsahuje adresáře popsané níže a také některé stránky aplikace. V adresáři jsou také dva důležité soubory, které nedefinují žádnou stránku. Prvním z nich je web.config, což je konfigurační soubor aplikace, v němž jsou uložena nejrůznější nastavení, jako například parametry spojení s databází, údaje o uživatelích, které se mají ukládat, nebo omezení přístupu k určitým částem aplikace pro některé skupiny uživatelů. Druhým souborem je Web.sitemap, který definuje větvení aplikace do jednotlivých kategorií a určuje, kam která stránka patří. Umožňuje pak například snadné vytváření menu v aplikaci.  App_Code – obsahuje mimo jiné třídy obsahující kód aplikace, který bylo vhodné umístit mimo code behind soubory například proto, že by se opakoval ve více z nich. Také jsou zde soubory s příponami .edmx a .Designer.cs, které jsou převedenou databázovou strukturou určenou pro použití technologií LINQ.  App_Data – zde jsou vloženy šablony emailů, které jsou posílané z aplikace. Také je zde uložen soubor obsahující databázi aplikace, pokud není uložena na nějakém jiném místě počítače mimo adresář aplikace.  App_Themes – místo pro uložení různých vzhledů aplikace. Každý je určen jedním podadresářem, obsahujícím obrázky a css soubory, které vzhled definují.  Bin – adresář sloužící pro umístění knihoven využitých v aplikaci. Obsahuje knihovny DayPilot, FreeTextBox a AjaxControlToolkit, které jsou podrobněji popsány později.  Controls – obsahuje soubory s příponou .ascx, což jsou komponenty aplikace, které je pak možné jednoduše vkládat do jakékoliv stránky. V této aplikaci je takto vytvořena komponenta zajišťující zobrazení komentářů a umožňující jejich vkládání. Poté je vložena pomocí krátké definice a speciální značky do potřebných stránek.

61

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ  

   

JavaScript – obsahuje soubory s javascriptovým kódem, na které je možné na stránkách odkazovat. MasterPages – obsahuje soubory definující jednotný vzhled skupiny stránek. Každá ze čtyř hlavních částí aplikace má svou vlastní master page a tyto pak mají jednu společnou nadřazenou master page definující některé vlastnosti společné úplně všem stránkám aplikace. Activities – adresář obsahující stránky části aplikace obsluhující databázi aktivit. Camps – část aplikace zodpovědná za zobrazování zveřejněných táborových programů a funkce s tím související. MyCamp – největší část aplikace poskytující všechny potřebné funkce pro plánování tábora. Help – obsahuje stránky s nápovědou k aplikaci

5.4.4 Použité knihovny Stejně jako v mnoha jiných jazycích je možné při programování v ASP.NET využívat již naprogramovaných knihoven pro usnadnění vývoje aplikací a získání nových funkcí. Ve své aplikaci jsem využil tři knihovny, které mi při vývoji opravdu pomohly. První z nich je knihovna DayPilot (domovká stránka produktu je www.daypilot.org). Ta obsahuje několik elementů, které obecně umožňují vytvořit tabulku s časovým rozvrhem. V aplikaci jsem využil DayPilot Scheduler. Poskytuje mnoho možností jak nastavit výsledný vzhled, mimo jiné umožňuje nastavit počet zobrazených dní, různě zabarvit jednotlivé hodiny či nastavovat šířku a výšku buněk. Umožňuje také naprogramovat reakce na některé akce uživatele, jako je například kliknutí myši na určitou pozici nebo přesunutí události v rozvrhu. Kromě toho je možné naprogramovat, jaká data z databáze se mají zobrazovat u jednotlivých událostí a také jak mají být v rozvrhu zobrazena. Právě díky tomu, že má programátor možnost spoustu věcí doprogramovat podle svých konkrétních potřeb, je DayPilot velice kvalitním produktem, který jsem ve vytvořené aplikaci značně využil. Druhou použitou knihovnou je FreeTextBox (www.freetextbox.com). Je to vlastně WYSIWYG HTML editor. Umožňuje tedy formátovat text pomocí dostupných tlačítek a nabídek. Toto formátování je potom převedeno do HTML kódu a po uložení se tak text na stránce zobrazuje tak, jak jej uživatel vytvořil. Nemusí přitom znát HTML, i když FreeTextBox umožňuje tvořit text i přímo v HTML. V aplikaci je knihovna využita při vkládání podrobných informací o aktivitách a táborových událostech a také při tvorbě táborových dokumentů. Poslední využitá knihovna, která přináší nerůznější funkce zvyšující interaktivitu stránek, se jmenuje AjaxControlToolkit (ajaxcontroltoolkit.codeplex.com). Aplikace používá funkci, jež zobrazuje kalendář při vyplňování dat v aplikaci.

62

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ 5.4.5 Přenesení aplikace na server Po dokončení programování aplikace a otestování všech funkcí ve vývojovém prostředí bylo možné aplikaci přenést na server, aby byla dostupná na internetu pro všechny zájemce. Podařilo se mi zajistit server s operačním systémem Microsoft Server 2008, na němž běží IIS 7 (Internetová informační služba), která je potřebná pro běh webových aplikací na serveru. Potom bylo třeba nainstalovat databázový systém, kterým se stal Microsoft SQL Server 2008. Jakmile bylo prostředí připravené, bylo možné na server aplikaci přesunout. Pro správnou komunikaci s databází bylo nutné provést drobné změny v souboru web.config. Přidáním do IIS se aplikace stala dostupnou pro každého, kdo je připojený k internetu. Na závěr byla ještě pro aplikaci zaregistrována doména. Aplikace je teď tedy dostupná na adrese www.taborovac.cz.

5.4.6 Stručný popis aplikace Při vstupu na úvodní stránku (obrázek 5.8) aplikace se o ní návštěvník dozví některé základní informace. Pomocí záložek Aktivity a Tábory se dostane do příslušných sekcí pro prohlížení a vyhledávání táborových aktivit a zveřejněných táborových programů. Vpravo se může

Obrázek 5.8: Úvodní stránka aplikace Táborovač.cz

63

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ přihlásit či zaregistrovat. Je zde také vidět počet aktivit a zveřejněných programů v databázi a odkazy na nejnověji vložené. Po přihlášení se uživateli objeví nová záložka nazvaná Můj tábor. V této sekci je možné založit jeden či více táborů. Po založení tábora se objeví vygenerovaná tabulka pro tvorbu programu. V ní je pak možné jednoduše přidávat nové události, přesouvat je a měnit délku jejich trvání a také je rušit. Pomocí odkazů v levém menu je možné zobrazit seznam všech událostí a také přidávat či odebírat úkoly vedoucím. Pod tímto menu je zobrazen seznam všech vytvořených táborových dokumentů spolu s odkazy umožňujícími vytvoření nového či smazání existujícího dokumentu. Vpravo je pak možné přepínat se mezi jednotlivými tábory, kterých je uživatel členem. Stránka s ukázkovým programem tábora je vidět na obrázku 5.9. Podrobnější popis této sekce a dostupných funkcí je v aplikaci pod odkazem Nápověda, který se nachází v menu na úvodní stránce.

Obrázek 5.9: Stránka s programem tábora V sekci Aktivity má přihlášený uživatel možnost vytvářet nové aktivity a editovat ty, které již vytvořil. Také může číst a vkládat příspěvky na stránkách aktivit, táborových programů, událostí či dokumentů.

64

5. WEBOVÁ APLIKACE PRO PLÁNOVÁNÍ DĚTSKÝCH TÁBORŮ Všichni registrovaní uživatelé jsou v roli RegisteredUser. Kromě toho v aplikaci existuje role Administrator, která však může být uživateli přidělena pouze pomocí nástroje Web Site Administration Tool, který je součástí Visual Studia, nebo přímým vložením údajů do databáze. Uživatel, který je v této roli, může pracovat se všemi tábory, jako by byl jejich zakladatelem. To samé platí o táborových aktivitách.

5.5 Současný stav aplikace a možnosti vývoje do budoucna Aplikace je tedy v současné chvíli dostupná na již uvedené adrese www.taborovac.cz. Kdokoliv může aplikaci využívat, zaregistrovat se v ní a po přihlášení vytvářet aktivity a táborové programy. Aplikace byla zveřejněna 14. dubna 2011 a do dnešního dne (18. května 2011) se zaregistrovalo 38 uživatelů a úvodní stránka byla navštívena 368krát. Bylo vytvořeno 13 táborů, několik z nich spíše pouze za účelem otestování aplikace, u většiny je však postupně program dotvářen a uživateli je tedy aplikace průběžně využívána. To, že je zveřejněn zatím pouze pro ukázku vytvořený tábor, je celkem pochopitelné, neboť nikdo nechce zobrazit všem program tábora, který ještě neproběhl. Věřím, že po skončení prázdnin uživatelé táborové programy zveřejní. Stejně tak si myslím, že se po tomto období zvýší i počet vložených táborových aktivit, které jsou v současnosti pouze 2. Od několika uživatelů jsem již získal reakce na aplikaci. Většinou hodnotí aplikaci jako užitečnou a vidí také možnosti, jak ji rozšířit o další funkce, což je pro mě velmi přínosné. Důležité pro větší rozšíření aplikace je jistě také její větší propagace na internetu i mimo něj. Tomu jsem zatím nevěnoval příliš pozornosti, ale například umístěním odkazu na některé stránky věnující se problematice táborů by se určitě povědomí o aplikaci zvýšilo. Stačí chvíle přemýšlení, aby člověk vymyslel spoustu funkcí, které by aplikace v budoucnu mohla poskytovat. Patří sem například zdokonalení práce s tabulkou programu tábora, kde by mohla být možnost kopírovat události, pokud se na táboře opakují, nebo také vyplňovat informace pro více událostí současně, pokud mají nějaké společné. Mimo jiné i tento nápad vzešel od uživatelů. Jistě by také nebylo špatné mít možnost do popisu aktivit vkládat přímo video ukázky, které by usnadnily pochopení aktivity. Uživatelé by také určitě využili hodnocení aktivit či označování oblíbených aktivit. V případě širšího pohledu na aplikaci se potom nabízí možnost zakomponovat do ní i možnost tábory nabízet zájemcům, kteří by se v aplikaci mohli na tyto tábory přihlašovat. Taková funkcionalita by pak šla propojit i s plánováním tábora, kde by bylo možné zobrazovat již přihlášené účastníky a provádět s nimi některé další operace. Je tedy vidět, že aplikace má značný potenciál pro další vývoj a hlavně na jejím využívání bude záležet, jak moc se bude do budoucna rozvíjet a zdokonalovat.

65

Kapitola 6

Závěr Cílem této práce bylo popsat proces vývoje webových aplikací od zjišťování požadavků až po implementaci aplikace. Důraz byl kladen na pochopení metodiky WebML a také nastudování technologie ASP.NET a nových vlastností CSS 3. Poté bylo úkolem s využitím těchto technologií navrhnout a implementovat webovou aplikaci pro plánování dětských táborů. Myslím si, že tyto cíle práce byly splněny. V teoretické části byly podrobně popsány jednotlivé modely metodiky WebML, představena technologie LINQ, která je součástí ASP.NET a také vysvětleny a na ukázkách předvedeny některé z mnoha novinek v CSS 3. Praktickým výsledkem práce je pak funkční aplikace Táborovač.cz, jež odpovídá vytvořenému návrhu. V současné chvíli je již dostupná na internetu a pomáhá uživatelům s plánováním táborů. Také snad bude postupně poskytovat stále větší inspiraci v podobě rostoucí databáze aktivit a táborových programů. Aplikace je navíc implementována tak, že je možné do ní v budoucnu snadno přidávat další funkce, které poskytnou ještě větší pomoc všem, kteří tábory připravují. Na úplný závěr bych rád poznamenal, že za nejdůležitější považuji tu skutečnost, že kromě teoretického nastudování a popisu současných webových technologií je výstupem práce i v praxi použitelná aplikace poskytující pomoc těm, kteří se pořádáním táborů snaží dělat něco dobrého pro druhé. Budu velmi rád, pokud jim bude tuto činnost Táborovač.cz v budoucnu stále více usnadňovat.

66

Literatura [1] ZELENKA, PETR: WebML – projektování webových aplikací, [online], 2003, dostupný na www: http://interval.cz/clanky/webml-projektovani-webovych-aplikaci/

(3.2, 3.2.1) [2] ZELENKA, PETR: WebML – kompozice webové aplikace, [online], 2004, dostupný na www: http://interval.cz/clanky/webml-kompozice-webove-aplikace/

(3.2.1.2) [3] Summary of WebML hypertext elements, [online], 2003, dostupný na www: http://www.webml.org/webml/upload/ent17/1/webml_elements.pdf

(3.2.1.2) [4] FALTÝNEK, JAKUB: Informační systém pro podporu organizace dětských táborů, Brno: Masarykova univerzita. Fakulta informatiky, 2009, 34 s. Vedoucí bakalářské práce Mgr. Luděk Bártek, Ph.D. (3.2.2) [5] KOSEK, JIŘÍ: Historie a vývoj html, [online], 2007, dostupný na www: http://htmlguru.cz/uvod-historie.html

(4.1.1) [6] Border-radius: create rounded corners with CSS!, [online], dostupný na www: http://www.css3.info/preview/rounded-border/

(4.2.2.1) [7] SLÁDEK, JAN: Webdesignérův průvodce po CSS3: animace, [online], 2010, dostupný na www: http://zdrojak.root.cz/clanky/webdesigneruv-pruvodce-po-css3animace/

(4.2.2.2) [8] DUDEK, JAN: CSS3 - kaskádové styly budoucnosti, [online], 2005, dostupný na www: http://interval.cz/clanky/css3-kaskadove-styly-budoucnosti/

(4.2.2.3)

67

LITERATURA [9] AJAX, [online], poslední revize 22.3.2011, dostupný na www: http://cs.wikipedia.org/wiki/AJAX

(4.4) [10] SPAANJAARS, IMAR. Beginning ASP.NET 4: In C# and VB. Indianapolis: Wiley Publishing, 2010. 803 s. ISBN 978-0-470-50221-1. (4.5.1, 4.5.2) [11] Java EE, [online], poslední revize 20.9.2010, dostupný na www: http://kore.fi.muni.cz:5080/wiki/index.php/Java_EE

(4.6)

68

Příloha A

Obsah CD Součástí této práce je také CD, obsahující adresáře: 

Táborovač.cz – obsahuje vytvořenou webovou aplikaci. V souboru info.txt je několik pokynů ke spuštění aplikace a informace o vytvořených uživatelských účtech.



Diagramy – obsahuje modely metodiky WebML, diagram případů užití a entitně-relační diagram (celkový a také tři hlavní části zvlášť, tak jak jsou uvedeny v práci).



Dotazník – obsahuje zadání a výsledky dotazníku k diplomové práci.



Text práce – obsahuje tuto práci ve formátu PDF.

69