VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika

Š a b l o n o v a c í s y s t é m y a M V C a rc h i t e k t u r a v e webových aplikacích bakalářská práce

Autor: Michal Novotný Vedoucí práce: Ing. Tomáš Richta Jihlava 2012

Vysoká škola polytechnická Jihlava Tolstého 16, 586 01 Jihlava

ZADÁNÍ BAKALÁŘSKÉ PRÁCE

Autor práce:

Michal Novotný

Studijní program:

Elektrotechnika a informatika

Obor:

Aplikovaná informatika

Název práce:

Šablonovací systémy a MVC architektura ve webových aplikacích

Cíl práce:

Prostudujte architektonický koncept Model View Controller (MVC). Popište základní principy a výhody použití tohoto konceptu při tvorbě webových aplikací. Předveďte na příkladech. Prostudujte a vysvětlete princip šablonovacích systémů. Ukažte na příkladech výhody a nevýhody použití. Na případové studii "Rezervační systém pro DKO", kterou jste společně s kolegy řešil v rámci předmětu Řízení softwarových projektů, předveďte praktické nasazení obou těchto principů v praxi. Implementaci pečlivě zdokumentujte.

Ing. Tomáš Richta

Ing. Bc. Michal Vopálenský, Ph.D.

vedoucí bakalářské práce

vedoucí katedry Katedra elektrotechniky a informatiky

ABSTRAKT Bakalářská práce se zabývá použitím návrhového vzoru Model View Controller (MVC) a šablonovacího systému Smarty při tvorbě webových aplikací. Softwarová architektura MVC je detailně popsána a demonstrována na případové studii Rezervační systém vstupenek pro DKO Jihlava. Práce také zahrnuje analýzu problémové domény.

KLÍČOVÁ SLOVA MVC, šablonovací systém, Smarty, PHP, MySQL, JavaScript, HTML, AJAX, rezervační systém

ABSTRACT This bachelor theses deals with the using of design pattern Model View Controller (MVC) and Smarty template engine for developing web applications. MVC software architecture is described in detail and demonstrated on a case study Ticketing reservation system for DKO Jihlava. Theses also consists of an analysis of the problem domain.

KEYWORDS MVC, template engine, Smarty, PHP, MySQL, JavaScript, HTML, AJAX, reservation system

Poděkování Na tomto místě bych rád poděkoval vedoucímu své bakalářské práce Ing. Tomáši Richtovi za jeho cenné rady a zájem o studovanou problematiku. Dále bych chtěl poděkovat DKO Jihlava za spolupráci a možnost podílet se na vzniku zajímavého projektu.

Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne 31. 12. 2011

.............................................. Podpis

Obsah 1

Úvod ............................................................................................................................ 10

2

Použité technologie .................................................................................................... 12

3

2.1

PHP ....................................................................................................................... 12

2.2

JavaScript .............................................................................................................. 12

2.3

MySQL ................................................................................................................. 12

2.4

HTML ................................................................................................................... 13

2.5

CSS ....................................................................................................................... 13

Studie MVC architektury ......................................................................................... 14 3.1.1

Model ............................................................................................................. 15

3.1.2

Pohled ............................................................................................................ 15

3.2

Řadič ..................................................................................................................... 16

3.3

Business třídy ........................................................................................................ 16

3.3.1

4

Servisní třídy ................................................................................................. 17

3.4

Šablonovací systémy............................................................................................. 17

3.5

Šablonovací systém Smarty .................................................................................. 18

3.5.1

Instalace ......................................................................................................... 18

3.5.2

Ukázka ........................................................................................................... 19

3.5.3

Syntaxe a proměnné....................................................................................... 20

3.5.4

Vestavěné funkce ........................................................................................... 21

Analýza ....................................................................................................................... 23 4.1

Stávající stav ......................................................................................................... 23

4.2

Zadavatelské požadavky ....................................................................................... 23

4.3

Případy užití .......................................................................................................... 25

4.3.1

Rezervace sedadel na představení ................................................................. 26

4.3.2

Registrace uživatele do systému .................................................................... 27

4.3.3

Zobrazení přehledu rezervací ........................................................................ 28

4.3.4

Zobrazení přehledu uživatelů ........................................................................ 28

4.3.5

Zobrazení detailu rezervace ........................................................................... 28

4.3.6

Zobrazení detailu uživatele ............................................................................ 28

4.4

Datová analýza ...................................................................................................... 29

4.4.1

Formulace požadavků .................................................................................... 29

4.4.2

ER model ....................................................................................................... 30

4.5

Model domény ...................................................................................................... 31

4.5.1

Návrh modelových tříd .................................................................................. 31

4.5.2

Sequence diagramy ........................................................................................ 32

5

Implementace ............................................................................................................. 34 5.1

5.1.1

Model ............................................................................................................. 34

5.1.2

Pohled ............................................................................................................ 34

5.1.3

Řadič .............................................................................................................. 35

5.2

Business třídy ........................................................................................................ 37

5.3

Servisní třídy ......................................................................................................... 37

5.3.1

Třída DB ........................................................................................................ 38

5.3.2

Třída Access .................................................................................................. 40

5.3.3

Třída CheckForm ........................................................................................... 41

5.4 6

MVC architektura ................................................................................................. 34

Použitý JavaScript................................................................................................. 42

Závěr ........................................................................................................................... 43

Literatura ............................................................................................................................. 44 Seznam zkratek .................................................................................................................... 45 Seznam příloh ...................................................................................................................... 46 A Grafická podoba............................................................................................................... 47 B Diagram užití ................................................................................................................... 49 D Diagramy sequence .......................................................................................................... 53 E Diagram ER ...................................................................................................................... 56 F Diagramy tříd ................................................................................................................... 57 G Souborová struktura aplikace .......................................................................................... 58

Seznam Obrázků Obrázek 3.1: Paradigma MVC (Model View-Controller) ................................................... 14 Obrázek 4.1 Diagram případu užití ..................................................................................... 25 Obrázek 4.2: Diagram aktivit - Rezervace sedadel na představení ..................................... 26 Obrázek 4.3: Diagram aktivit - Registrace uživatele do systému........................................ 27 Obrázek 4.4: Diagram aktivit - Zobrazení detailu rezervace............................................... 28 Obrázek 4.5: Datový ER diagram ....................................................................................... 30 Obrázek 4.6: Diagram modelových tříd .............................................................................. 31 Obrázek 4.7: Sequence diagram - Přidání nového představení ........................................... 32 Obrázek 4.8: Seguence diagram - Registrace uživatele do systému ................................... 33 Obrázek 5.1: Třída DB ........................................................................................................ 38 Obrázek 5.2: Třída Access................................................................................................... 40 Obrázek A.1: Rezervace - přehled představení ................................................................... 47 Obrázek A.2: Rezervace - přehled sedadel v sále ............................................................... 48 Obrázek B.1: Diagram užití ................................................................................................. 49 Obrázek C.1: Diagram aktivit - Rezervace sedadel na představení .................................... 50 Obrázek C.2: Diagram aktivit - Registrace uživatele do systému ....................................... 50 Obrázek C.3: Diagram aktivit - Přidání nového představení............................................... 51 Obrázek C.4: Diagram aktivit - Zobrazení přehledu rezervací ........................................... 51 Obrázek C.5: Diagram aktivit - Zobrazení přehledu uživatelů ........................................... 52 Obrázek C.6: Diagram aktivit - Zobrazení detailu rezervace .............................................. 52 Obrázek C.7: Diagram aktivit - Zobrazení detailu rezervace .............................................. 52 Obrázek D.1: Sequence diagram - Registrace uživatele do systému .................................. 53 Obrázek D.2: Sequence diagram - Přidání nového představení .......................................... 54 Obrázek D.3: Sequence diagram - Zobrazení přehledu rezervací ....................................... 54 Obrázek D.4: Sequence diagram - Zobrazení přehledu uživatelů ....................................... 55 Obrázek D.5: Sequence diagram - Zobrazeni detailu rezervace ......................................... 55 Obrázek D.6: Sequence diagram - Zobrazení detailu uživatele .......................................... 55 Obrázek E.1: Diagram ER ................................................................................................... 56 Obrázek F.1: Modelové třídy............................................................................................... 57 Obrázek F.2: Servisní třídy.................................................................................................. 57 Obrázek G.1: Souborová struktura aplikace ........................................................................ 58

Seznam tabulek Tabulka 3.1: Syntaxe proměnných ve Smarty ..................................................................... 20 Tabulka 3.2: Operátory systému Smarty ............................................................................. 21 Tabulka 5.1: Typy uživatelů ................................................................................................ 40 Tabulka 5.2: Validační metody třídy CheckForm ............................................................... 41

1 Úvod Tato bakalářská práce se zabývá problematikou Model View Controller (MVC). Jedná se o architektonický koncept, který se používá k tvorbě softwaru. Architektura softwaru je jakási kostra, či šablona, podle které je aplikace konstruována. Jde tedy o množinu jasně definovaných pravidel, jež je nezbytné dodržovat. Typů těchto návrhových vzorů existuje více, přičemž každý je něčím specifický a má nějaké výhody i nevýhody. Volba softwarové architektury aplikací by rozhodně neměla být podceňována. Nevhodný výběr, či pouze nedodržení pravidel softwarové architektury se v praxi může projevit několika aspekty. Je více pravděpodobné, že výsledná aplikace bude méně spolehlivá, či dokonce nestabilní. V programovém kódu se mohou vyskytnout nežádoucí redundance a zpráva, či rozšíření aplikace, by mohl být značný problém. Je také více pravděpodobné že dojde k prodloužení času vývoje aplikace. Vhodný výběr softwarové architektury je proto velmi důležitý a v praxi může společnostem zabývajícím se vývojem softwarových aplikací ušetřit značné finanční obnosy. MVC architektura dnes velmi nabývá na popularitě. Základní princip použití tohoto návrhového vzoru je v rozdělení aplikace na tři základní části, model, pohled a kontrolér. Každá z těchto komponent zastává konkrétní funkcionalitu. Modelová vrstva je považována za srdce aplikace, provádí veškeré logické operace. Další komponenta, pohled, se stará pouze o zobrazení výsledné grafické podoby. Poslední komponenta, tedy řadič, zachytává události vyvolané uživatelem, či aplikací. Rozhoduje, zda se informace zpracují modelovou vrstvou, nebo zda dojde k přímému zobrazení dat pomocí instrukce předané pohledu. Tento koncept naprosto odděluje logickou část od grafické části aplikace, což přináší mnoho výhod. Programový kód nabude na přehlednosti, snadno se dají dohledat případné chyby, při použití jazyka PHP a šablonovacího systému ve webové aplikace, je docíleno naprostého oddělení PHP a HTML kódu, což umožňuje efektivně rozdělit vývoj aplikace mezi více programátorů. V bakalářské práci je použití architektonického konceptu MVC demonstrováno na konkrétní webové aplikaci, která by měla umožňovat rezervaci vstupenek na představení Jihlavského DKO. Aplikace byla již ve čtyřčlenném týmu v rámci předmětu Řízení softwarových projektů částečně realizována. Nebyl ovšem aplikován žádný známý návrhový vzor, proto se v kódu objevovalo mnoho duplicitních částí, struktura kódu nebyla příliš přehledná a většina částí aplikace byla psána strukturovanou formou. Z hlediska 10

rozsahu a množství požadavků na systém je volba návrhového vzoru MVC velmi žádoucí. To ovšem znamenalo rekonstruovat analýzu a navrhnout aplikaci v souladu s MVC architekturou, touto problematikou se zabývá kapitola 4. Analýza.

11

2 Použité technologie V této kapitole jsou okrajově popsané všechny technologie, které byly použity k vývoji aplikace. Bylo zvoleno vývojové prostředí NetBeans IDE 7.0.1, které podporuje vývoj technologií PHP, HTML, CSS i JavaScriptu a nabízí mnoho užitečných nástrojů.

2.1 PHP Hypertext Preprocessor, původně Personal Home Page, je programovací skriptovací jazyk určený k tvorbě webových stránek. Při použití PHP se skript provádí na straně serveru, uživateli je následně předán výsledek pomocí protokolu HTTP. Syntaxe je velmi podobná programovacím jazykům C++ a JAVA. PHP je multiplatformní jazyk, může fungovat na více operačních systémech, nejčastěji je ovšem používán Linux a Microsoft Windows. Verze PHP5 již podporuje plnohodnotné objektové programování a nabízí nespočet funkcí, či knihoven a umožňuje přístup k nejrozšířenějším databázovým systémům, jako je (MySQL, PostgreSQL, Oracle). Jazyk PHP je k vývoji internetových stránek dosti používaný, proto se setkáme i s dostačující podporou u společností poskytující webový hosting.

2.2 JavaScript JavaScript je objektově orientovaný skriptovací jazyk, určený pro použití ve webových aplikacích. Název JavaScript je poněkud matoucí, s jazykem Java, krom podobné syntaxe, nemá nic společného. Jak bylo řečeno, syntaxe je dosti podobná jazykům C a Java. Skripty se zapisují přímo do HTML kódu, či do externích souborů s příponou js, které se do stránky vkládají. JavaScript se provádí na straně klienta poté, co se odešle stránka ze serveru. Většinou je použit pro dynamické ovládání prvků stránky, či k tvorbě grafických animací.

2.3 MySQL MySql je relační databázový systém. Dotazy na databázi jsou realizované SQL jazykem, neboli Structured Query Language. MySql je jeden ze základních prvků nové generace aplikací tzv. LAMP (Linux, Apache, MySQL, PHP / Perl / Python).

12

„Databáze MySQL je používaná v komunitě Open Source ze všech databází nejvíce. Databázový systém MySQL na trhu s databázemi opakuje úspěch Linuxu na trhu operačních systémů.“ (KOFLER Michael, 2007)

2.4 HTML HTML (HyperText Markup Language) je značkovací hypertextový jazyk určený pro vývoj internetových stránek. Jazyk HTML využívá značky tzv. tagy, které mohou obsahovat atributy. Tagy jsou definované názvem, který je uzavřen v ostrých závorkách. Značky se dělí na párové a nepárové. Párové tagy se skládají z uvozovací a uzavírací značky, přičemž uzavírací tag musí obsahovat zpětné lomítko. Na obsah, který se vyskytuje mezi párovými tagy, se vztahují pravidla dané atributy a typem tagů. Chceme-li například zobrazit tučné písmo, použijeme následující formuli: <strong>tučné písmo<strong/>. Struktura výsledné stránky je striktně daná. Dle normy HTML by měl dokument začínat kořenovým tagem . Dále je zapotřebí definovat hlavičku, v které se vyskytují metadata, ale nezobrazují se, pouze specifikují vlastnosti dokumentu. Mohou se v ní objevit tyto nepovinné tagy: meta, link, title, script, atd. Další část dokumentu označená tagem , obsahuje vše, co se má ve stránce zobrazit. Na závěr musí být dokument uzavřen ukončovací značkou . Zobrazení výsledného HTML dokumentu zajišťují software zvaný webový prohlížeč, který očekává kompatibilní strukturu a syntaxi dokumentu s normou HTML. Internetových prohlížečů existuje více, přičemž se v zobrazení dokumentu, mohou vyskytnout drobné rozdíly, což pro webové vývojáře není příliš žádoucí.

2.5 CSS CSS (Cascading Style Sheets), neboli kaskádové styly, je jazyk určený pro definici způsobu zobrazení HTML. Jazyk byl vyvinutý organizací W3C. Jsou vydány dvě verze CSS1 a CSS2, na verzi CSS3 se pracuje. Kaskádové styly oddělují vlastnosti zobrazení od struktury dokumentu HTML. Zapisují se přímo do kódu HTML, nebo do externích souborů s příponou css, tyto soubory musejí být v hlavičce dokumentu definovány.

13

3 Studie MVC architektury Architektura MVC neboli Model view controller je druh návrhového vzoru softwaru, který v poslední době úspěšně nabývá na popularitě. Jak už plyne z názvu, základní princip této softwarové architektury spočívá v rozdělení aplikace do tří základních samostatných komponent, které mezi sebou mohou komunikovat. Aplikace se tedy dělí na model, pohled a řadič. Hlavní komponenta, někdy označovaná jako srdce aplikace, je model, který se stará o veškerou funkční logiku, řadič spravuje obsluhu událostí, vyvolané většinou uživatelem, nebo podmětem, vyvolaným samotnou aplikací. Pohled zobrazuje výstupní data zpracované logickou částí programu, jedná se o tzv. Graphical user interface (GUI), ve webových aplikacích pohled generuje HTML kód, který následně webový prohlížeč zobrazí do grafické podoby. Z hlediska přehlednosti a rozšiřitelnosti kódu je návrhový vzor MVC vhodná volba softwarové architektury. Další výhoda tohoto návrhového vzoru spočívá v zaměnitelnosti jednotlivých komponent za jiné. Představme si, že máme webovou aplikaci a chceme ji rozšířit o použití na PDA zařízeních. S implementací MVC vzoru postačí zaměnit, či upravit pouze komponentu pohled, která bude konsistentně fungovat s PDA přístroji, přičemž logická část, tedy model, bude zachována beze změn.

Obrázek 3.1: Paradigma MVC (Model View-Controller)

14

3.1.1 Model Model je považována za nejdůležitější část aplikace. Představme si tuto komponentu jako kolekci tříd, která má za úkol modifikovat data dle konkrétních požadavků uživatele. Na vstupu se modelové části předají nějaká data, provedou se příslušné operace a na výstupu poskytne zpracovaná data, která následně zobrazí komponenta pohled. Je tedy zřejmé, že model nemá žádnou přímou vazbu mezi pohledem, není jeho starost, jak se výsledná data zobrazí. Modelové třídy by tedy měly správně fungovat, i kdyby se využily například pomocí příkazové řádky. Máme-li webovou aplikaci, znamená to, že se v modelu nesmí vyskytovat žádné prvky GUI, tedy HTML kód a nic, co přímo souvisí s výslednou podobou grafického zobrazení. Jedním z důležitých úkolů modelu je zajistit spojení s databází a realizovat databázové dotazy dle konkrétních požadavků a popřípadě je zpracovat v použitelná data, které pohled dokáže zobrazit. „Model je částí, jež je zcela nezávislá na volbě řadiče nebo na volbě šablonovacího systému. Model by měla tvořit sada opětovně použitelných, modulárních tříd – chytrých stavebních kamenů, které můžete k projektu přidat anebo je z něj odebrat, jak jen potřebujete.“ (LECKY-THOMPSON Ed a Steven D. NOWICKI, 2010)

3.1.2 Pohled Pohled je komponenta, která uživateli zobrazuje data zpracovaná modelovou vrstvou aplikace. V praxi je reprezentován většinou kolekcí tříd, která se zabývá problematikou GUI, u webových aplikací jde o HTML šablonu, která obsahuje pouze HTML kód, tedy pouze části související s grafickou podobou zobrazení. Není to však snadné tak jak se jeví, v praxi jistě často narazíme na problém při dynamickém zobrazení GUI. Mějme nějaký obsah, který se má zobrazit pouze na základě splnění nějaké logické podmínky, či nějaká dynamická data, která jsou vyžadována zobrazit například formou tabulky. Je tedy zřejmé, že pohled musí umožňovat použití jednoduchých podmínek, či cyklů k procházení dynamických informací. V pohledu by se neměly vyskytovat přímé odkazy na modelové objekty a rozhodně by pohled neměl obsahovat žádné databázové operace. Značná výhoda této konstrukce spočívá v jednoduché zaměnitelnosti jednotlivých částí pohledu. Vyskytne-li se v řadiči například instrukce k zobrazení nějakých dat zpracovaných modelovou vrstvou ve formě grafu, můžeme navrhnout pohled pro zobrazení sloupcového grafu, jiný pohled pro zobrazení koláčového, či lineárního grafu za 15

použití stejných informací generovaných modelovou častí aplikace. Případná modifikace grafické podoby aplikace je proto velmi snadná.

3.2 Řadič Poslední ze tří komponent návrhového vzoru MVC je řadič. Jeho úkolem je zachytávat události vyvolané uživatelem, či samotnou aplikací, tyto požadavky vyhodnocovat a na základě okolností rozhodne, zda se použijí třídy modelové vrstvy, nebo zda dojde k zobrazení GUI pomocí pohledu. Řadič si můžeme představit jako jakéhosi zprostředkovatele informací mezi modelovou vrstvou a pohledem. Při jakékoli akci uživatele se nejprve volá řadič, ten na základě okolností, ve webových aplikacích, tedy hodnot přijatých metodou GET, POST a informaci o požadované stránce uživatele, vyhodnotí situaci a dle potřeby využívá třídy modelové vrstvy, zpracovaná data těmito objekty se následně zobrazí pomocí pohledu. Znamená to tedy, že řadič obsahuje přímou vazbu na model, tak i na pohled. V praxi se jedná o kolekci PHP spustitelných skriptů reprezentující jednu konkrétní webovou stránku.

3.3 Business třídy Na Business třídy lze nahlížet jako na stavební kameny, které tvoří modelovou vrstvu aplikace. Měly by realizovat řešení problémů reálného světa, respektive daný okruh problémů. Chceme-li například umožnit uživatelům registraci do systému, nejprve tedy uživateli předložíme formulář obsahující povinné údaje, které se musí vyplnit a následně odeslat, jak se ale tento případ užití projeví na straně serveru? Spustí se příslušný řadič, ten vytvoří instanci business třídy Uzivatel, která disponuje metodu pro vložení hodnot do databáze, té se tedy formou parametrů předají data, zpracují se a výsledkem metody bude booleovská hodnota informující o správnosti uložení nového uživatele do databáze, tuto informaci řadič předá pohledu a ten pomocí jednoduché podmínky rozhodne, jaká správa se uživateli zobrazí. Všechny podobné problémy týkajícího se reálného světa, by měly realizovat business třídy.

16

3.3.1 Servisní třídy Servisní třídy jsou též součástí modelové vrstvy softwaru. Měly by například řešit komunikaci mezi databází, odesílání emailových správ, generování jiných formátů, operace se soubory, apod. V knize PHP6 je definují takto: „Je dobrým pravidlem, že se nevytvářejí instance servisních tříd. Používají se staticky, protože už ze své podstaty by neměly existovat žádné rozdíly mezi jejich jednotlivými instancemi. Naproti tomu v případě business tříd se instance vytvářejí téměř vždy (mohou však mít statické metody), protože se v odpovídající datové struktuře aplikace zpravidla ukládá jedna nebo více instancí. Jinými slovy vaše aplikace bude mít více uživatelů, ale jen jednu komponentu pro odesílání emailů.“ (LECKY-THOMPSON Ed a Steven D. NOWICKI, 2010)

3.4 Šablonovací systémy Šablonovcí systémy pro webové aplikace se vyznačují schopností efektivně rozdělit programovací kód, umožňují například oddělit PHP skripty od HTML kódu, který musí být umístěný v tzv. šablonách, většinou jde o soubory s příponou například tpl. V těchto souborech je umožněno používat jednoduché podmínky, cykly, či řídící struktury. Dá se říci, že každý šablonovací systém definuje jednoduchý programovací jazyk se striktně danou syntaxí. Nabízí se otázka, zda má používání šablonovacího systému nějaký smysl. Při tvorbě jednoduchých internetových stránek, kdy není zapotřebí použití databáze, či programování logických funkcí, nemá použití šablon téměř žádné výhody. Vyvíjí-li se ovšem rozsáhlejší projekt, v kterém je zapotřebí použít spoustu programového kódu, použití šablon přináší mnoho výhod. Dojde-li tedy k rozdělení programového kódu od HTML kódu, celkový zdrojový kód bude rozhodně přehlednější, než kdybychom je míchali dohromady. Použití šablon tedy umožní oddělit vývoj grafické podoby od logické vrstvy softwaru.

17

3.5 Šablonovací systém Smarty Smarty je šablonovací systém vytvořený v jazyce PHP. Systém disponuje mimo jiné možností použití řídících struktur, cyklů, proměnných, či vestavěných funkcí. Velkou výhodou systému je jeho vysoká rychlost, jež dosahuje proto, že zkompilované šablony se ukládají do mezipaměti v podobě PHP skriptů. Pokud, se obsah těchto skriptů v opakujících se požadavcích nemění, šablona se už znovu nekompiluje, ale načte se přímo z mezipaměti.

3.5.1 Instalace „Instalace systému Smarty je snadná, na rozdíl od mnoha další šablonovacích systémů se však nejedná o tradiční balíček PEAR, takže si jej musíte stáhnout a nainstalovat ručně. Smarty je aktuálně k dispozici na adrese www.smarty.net. Následně je zapotřebí přesunout knihovny systému Smarty někam, kde je uvidí PHP. Obecně vzato stačí zkopírovat kompletní obsah podadresáře libs do umístění jako je /usr/local/lib/php.“ (LECKYTHOMPSON Ed a Steven D. NOWICKI, 2010) V kořenové složce aplikace je nutné vytvořit následující složky: 

Template



Template_c



Config



Cache

Složka template bude obsahovat veškeré použité šablony, její existence je povinná. V template_c se ukládají již zkompilované šablony a je též povinná. Složka config je nepovinná a může obsahovat konfigurační soubory, které mohou specifikovat nastavení systému. Poslední adresář cache je nepovinný, obsahuje cache. Smarty dovoluje použít jiné názvy těchto adresářů i jiné cesty vůči souboru Smarty.class.php, v takovémto případě se tyto změny musí definovat, je tedy zapotřebí přepsat členské proměnné třídy, které zmiňované cesty k souborům obsahují. Přepsat hodnotu můžeme například takto: $objSmarty->template_dir = "pohled/templates";

18

3.5.2 Ukázka Z následujícího kódu by mělo být zřejmé, jak Smarty funguje. Ve skriptu home.php se definuje objekt třídy Smarty, metodou display() objekt načte šablonu sablona.tpl, která obsahuje výsledný THML kód stránky. Ta se ihned po zpracování metodou zobrazí. Soubor home.php: display( "sablona.tpl" ); ?>

Soubor sablona.tpl: Obsah šablony

19

3.5.3 Syntaxe a proměnné Veškeré příkazy jazyku Smarty se zapisují do složených závorek, lze ale použít jakýkoli znak, ty se ovšem musí objektu Smarty definovat. Například takto: $objSmarty->left_delimiter

= „<-„;

$objSmarty->right_delimiter = „->“;

Chceme-li vložit komentář do šablony Smarty, použijeme následující syntaxi: {* Toto je komentář a nebude zobrazen *}

Syntaxe u deklarace proměnných ve Smarty je stejná jako v jazyce PHP, proměnné musejí začínat znakem $ a nemusíme definovat typ proměnné, o to se postará Smarty. V tabulce vidíme, jak přistupovat k různým typům proměnných.

PHP

Smarty

$x

{$x}

Klasická proměnná

$pole[4]

{$pole[4] }

Pole s indexem 4

$pole[“index“]

{$pole.index}

Asociativní pole

$pole[“index1“] [“index2“]

{$pole.index1.index2}

Dvourozměrné pole

$objekt->metoda()

{$objekt->metoda()}

Přístup k metodě objektu

Tabulka 3.1: Syntaxe proměnných ve Smarty

Modifikátory proměnných pomocí různých pravidel umožňují na úrovni šablon Smarty modifikovat obsah konkrétních proměnných. Chceme-li tedy použít modifikátor, nejprve zapíšeme proměnnou, za ní znak | a nakonec přidáme požadovaný modifikátor. Při použití modifikátoru na pole bude pravidlo aplikováno na každý prvek v poli, chceme-li modifikátor použít na pole jako na celek, musíme před něj přidat symbol @. Smarty těchto modifikátorů nabízí celou řadu, viz manuál Smarty.

20

3.5.4 Vestavěné funkce Smarty také disponuje již předdefinovanými funkcemi. Základem dobré webové stránky je možnost dynamického zobrazení obsahu, toho lze dosáhnout použitím podmínek a cyklů pro průchod datových struktur. Ve Smarty můžeme použít dobře známou podmínku if, jejíž syntaxi je následující: {if Podminka} {* obsah *} {/if}

Qualifier

Alternates

Syntax Example

Meaning

PHP Equivalent

==

eq

$a eq $b

Je rovno

==

!=

ne, neq

$a neq $b

Není rovno

!=

>

gt

$a gt $b

Větší než

>

<

lt

$a lt $b

Menší než

<

>=

gte, ge

$a ge $b

Větší nebo rovno než

>=

<=

lte, le

$a le $b

Menší nebo rovno než

<=

$a === 0

identita

===

=== !

not

not $a

negace

!

%

mod

$a mod $b

Zbytek po dělení

%

is [not] div by

$a is not div by 4

Je dělitelné bezezbytku

$a % $b == 0

is [not] even

$a is not even

Je sudé číslo

$a % 2 == 0

is [not] even by

$a is not even by $b

Seskupení sudých čísel

($a / $b) % 2 == 0

is [not] odd

$a is not odd

Je liché číslo

$a % 2 != 0

is [not] odd by

$a is not odd by $b

Seskupení lichých čísel

($a / $b) % 2 != 0

Tabulka 3.2: Operátory systému Smarty

21

Mimo jiné Smarty umožňuje procházet jedno i vícerozměrná pole, k tomuto účelu byl zkonstruován cyklus s názvem section. Jedná se o podobný cyklus jako foreach v PHP a obsahuje několik povinných parametrů. Parametr name jednoznačně identifikuje cyklus. Parametr look určuje počet průchodů cyklem, nebo objekt, který bude procházen, aplikujeme-li průchod na pole, cyklus se zopakuje tolikrát, kolik pole obsahuje prvků. Jeden z dalších, ovšem nepovinných parametrů je start, nastavuje počátek iterace cyklu a defaultně je nastaven na nulu. Dalším parametrem step, můžeme definovat počet kroků iterace. Parametrem max určíme maximální počet iterací v cyklu. Průchod jednorozměrným polem: {section name="index" loop=$pole}

{$pole[index]}

{/section}

Generování sudých čísel do 16: {section name="hodnota" start="0" loop="16" step="2"} {$smarty.section.hodnota.index} {/section}

V tomto popisu šablonovacího systému Smarty byla vysvětlena jen ta nejdůležitější charakteristika systému. Smarty ovšem disponuje nespočet funkcemi, o kterých v kapitole Šablonovací systém Smarty nepadla zmínka. Pro detailní studii doporučuji materiály nacházející se na oficiálních webových stránkách systému Smarty.

22

4 Analýza 4.1 Stávající stav V současné chvíli DKO Jihlava nabízí rezervaci vstupenek na představení pouze na základě telefonátu či emailové zprávy. Tyto informace vyhodnotí příslušná osoba a vytvoří, nebo aktualizuje soubor ve formátu Excel, který obsahuje údaje o konkrétním představení a stavu jednotlivých sedadel v podobě reálné mapy divadelního sálu. Tyto soubory jsou jako přehled dostupných vstupenek na představení k dispozici ke stažení na internetových stránkách DKO. V dnešní době Internetu a možnosti komputerizace problému, je to dosti neefektivní řešení. Adekvátním východiskem je použití elektronického systému, který by tyto funkční požadavky realizoval, zároveň by umožnil zákazníkům snadnou rezervaci vstupenek pomocí webové stránky, to znamená z jakéhokoli místa na světě, kde je k dispozici počítač a připojení k síti Internet.

4.2 Zadavatelské požadavky DKO Jihlava požaduje navrhnout a realizovat elektronický rezervační vstupenkový systém pro hraná představení na úrovni internetové aplikace. Systém se bude skládat ze dvou rozhraní, uživatelského a administrátorského. Uživatelské rozhraní bude přístupné všem uživatelům. Jeho základní priorita je umožnit rezervaci vstupenek na konkrétní divadelní představení. Tento proces se skládá z několika kroků. Uživatel nejprve z nabídky vybere požadované představení, poté se zobrazí reálná mapa sedadel divadelního sálu, z které bude zřejmé, jaké sedadlo je již obsazené a jaké je stále volné. V tomto kroku bude možné kliknutím myši vybrat jakékoli volné sedadlo, je ovšem daný maximální počet vstupenek pro konkrétní představení, který nelze překročit. V další fázi rezervace systém uživateli rekapituluje přehled vybraných vstupenek, přičemž umožní jednotlivá sedadla odebrat z rezervace. V předposledním kroku systém vyžaduje autentizaci uživatele pomocí kontaktního formuláře, který obsahuje tyto povinné údaje: jméno, příjmení, telefon a email. Systém však uživateli nabízí možnost registrace do systému, tímto způsobem autentizace odpadne vyplňování formuláře při každé rezervaci tímtéž uživatelem. Klient se pouze autorizuje pomocí jedinečného uživatelského jména a hesla, tyto údaje si uživatel definuje při registraci.

23

V závěrečném kroku rezervace systém poskytne uživateli informace o průběhu dokončené rezervace. Administrátorské rozhraní je přístupné pouze adekvátním osobám po splnění příslušné autentizace. Rozhraní obsahuje jednoduché grafické menu, které rozděluje obsah na jednotlivé kategorie. Administrátorovi umožní přidat nové představení do systému, zobrazit přehled rezervací a uživatelů, provést rezervaci vstupenek, či potvrdit přijatou platbu rezervace.

24

4.3 Případy užití Po rozhovoru se zadavatelem projektu zjistíme všechny jeho požadavky, které musí splňovat výsledný systém. Tyto nároky se dají velmi přehledně znázornit pomocí diagramu případu užití tzv. Use case diagram. Diagram zachycuje možné aktéry používající systém, operace, které mohou realizovat a vztahy vyskytující se mezi nimi. „Figurka reprezentuje aktéra, bublina případ užití. V diagramech případu užití se aktér zpravidla chápe jako role spojená s osobou, ačkoli může reprezentovat také systém, který s vaším systémem spolupracuje“. (LECKY-THOMPSON Ed a Steven D. NOWICKI, 2010) Jak vidíme na obrázku 4.1: Diagram případu užití, rezervační systém využívají dva typy aktérů, uživatel a administrátor, přičemž každý z nich má právo uskutečnit pouze nějaké operace. Uživatel má možnost rezervovat sedadla na představení a registrovat se do systému. Administrátor může též rezervovat sedadla na představení, má ale také práva pro přidání nového představení, zobrazení přehledu rezervací, uživatelů, detailů rezervace, či detailu uživatele a smí potvrdit přijatou platbu za vstupenky na představení.

Obrázek 4.1 Diagram případu užití

25

4.3.1 Rezervace sedadel na představení Případ užití Rezervace sedadel na představení se skládá z několika kroků. Uživatel musí nejprve vybrat požadované představení, k dispozici je filtr, který seznam představení eliminuje dle kalendářního roku a měsíce. Poté se uživateli zobrazí reálná mapa divadelního sálu. Jednotlivá sedadla reprezentují grafické obrazce, specifikují se tři základní typy: volné, obsazené a již vybrané sedadlo. V této části si uživatel vybere požadovaná místa a přejde k dalšímu kroku rezervace. V této sekci se zobrazí přehled již zamluvených sedadel, ty lze ovšem z rezervace odebrat. V této fázi rezervace je možné dosavadní kroky opakovat, lze tímto způsobem rezervovat vstupenky na jiné představení, či v započaté operaci pokračovat dále. V další části procesu dochází k autentizaci uživatele. Pokud je uživatel registrovaný, postačí, když se přihlásí do systému, pokud registrovaný není, musí vyplnit formulář, který obsahuje tyto povinné údaje: jméno, příjmení, telefonní číslo a emailovou adresu. Po správné autentizaci uživatele dojde k zobrazení informace o průběhu rezervace.

Obrázek 4.2: Diagram aktivit - Rezervace sedadel na představení

26

4.3.2 Registrace uživatele do systému Předpoklad pro úspěšný provoz rezervačního systému je využití širokým okruhem uživatelů. Je proto vhodné samotný proces rezervace co nejvíce z hlediska uživatele zjednodušit. Jedno z mnoha řešení je nabídnout uživateli možnost registrovat se do systému. Při rezervaci tedy odpadne autentizace v podobě vyplnění čtyř povinných formulářových polí, které se mohou uživateli při častém opakování rezervací jevit jako příliš zdlouhavé. K autentizaci postačí zadání uživatelského jména a hesla, které si uživatel zvolí při registraci. Mimo jiné se při registraci uvedou stejné údaje, jako při konečné fázi rezervace, a to tyto: jméno, příjmení, telefonní číslo a emailová adresa. Následné přihlášení bude možné v jakékoli fázi rezervace vstupenek.

Obrázek 4.3: Diagram aktivit - Registrace uživatele do systému

K následujícím procesům má přístup pouze oprávněná osoba, tedy správce rezervačního systému. Správce, či administrátor disponuje oprávněním k několika procesům. Jedno z nich je přidání nového představení. Jedná se vlastně o vyplnění formuláře, který zahrnuje tyto povinné údaje: název, datum a čas začátku představení, maximální počet rezervovaných míst, které může uživatel v jedné rezervaci uskutečnit. Dále se definuje cena vstupenky, ta se ovšem může lišit dle různé pozice sedadla, respektive dle konkrétní řady v sále. Je tedy možné nastavit pro každou řadu sedadel v sále jinou cenu vstupenky. Ihned po potvrzení operace, je možné realizovat rezervace na následně přidané představení.

27

4.3.3 Zobrazení přehledu rezervací Pomocí tohoto případu užití má administrátor absolutní přehled o stávajících rezervacích na představení. Informace jsou zobrazeny v podobě seznamu rezervací, které se dají selektovat dle konkrétního představení. Výsledná tabulka umožňuje řazení záznamů dle vybraného sloupce. Lze také dohledat konkrétní záznam skrze identifikační číslo rezervace. Ze záznamu je patrné, zdali je rezervace zaplacená, či nikoli.

4.3.4 Zobrazení přehledu uživatelů Zobrazení uživatelů je dosti podobné, jako zobrazení přehledu rezervací. Systém zobrazuje seznam registrovaných uživatelů v podobě tabulky. K dispozici je opět filtr, který umožňuje vyhledávání uživatelů dle jména, příjmení a identifikačního čísla uživatele. Opět je možné řadit záznamy dle vybraného sloupce tabulky.

4.3.5 Zobrazení detailu rezervace Tento případ užití zobrazí kompletní informace o dané rezervaci dle identifikačního čísla. V případě, že uživatel zaplatí rezervaci, správce systému má pravomoc nastavit stav platby na zaplacený.

Obrázek 4.4: Diagram aktivit - Zobrazení detailu rezervace

4.3.6 Zobrazení detailu uživatele Poslední případ užití zobrazuje kompletní informace o uživateli a všechny jeho platné rezervace v podobě tabulek.

28

4.4 Datová analýza V projektu

je

dle

charakteru

zadavatelských

požadavků

jednoznačně

nezbytné

implementovat bázi dat. Nejprve se tedy provede počáteční analýza, je vhodné formulovat všechny požadavky a v souladu s nimi navrhnout vhodný relační model, který bude efektivně uchovávat informace. Důležitá je také vhodná volba databázového stroje. Dle zkušeností, rozšířenosti a spolehlivosti byl zvolen databázový stroj MySQL.

4.4.1 Formulace požadavků 

Databáze uchovává informace o představení



Cena vstupenky se liší dle představení a dle aktuální řady v sálu



Sál je rozdělen na přízemí a balkon



Evidují se údaje o uživateli



Uživatel má možnost registrace do systému



Uživatel smí uskutečnit rezervaci na jednotlivá sedadla v sále dle představení



Rezervace obsahuje údaje o pozici zamluvených sedadel



Eviduje se druh a stav platby jednotlivých rezervací



Správce systému má možnost potvrdit přijatou platbu pro konkrétní rezervaci

29

4.4.2 ER model ER model (Entity-relationship model) se používá k abstraktnímu znázornění dat. Měl by co nejlépe vystihnout pohled na konkrétní oblast. V těchto diagramech se setkáme s pojmy jako entita, entitní vztah, či atribut. Entita reprezentuje objekt, který by měl být jednoznačně identifikovaný. Atribut popisuje vlastnosti každého členu množiny entit. Mezi entitami může vzniknout entitní vztah, který lze také popsat atributy. Tyto vztahy mohou nabývat tří typů kardinality. 

poměr 1:1



poměr 1:N



poměr N:M

Obrázek 4.5: Datový ER diagram

30

4.5 Model domény Modelování domény znamená posunout se dále ve vývoji softwaru. Nyní máme k dispozici případy užití a datovou analýzu. Z těchto informací a poznatků lze vycházet při navržení modelové části systému. V MVC architektuře tato vrstva reprezentuje model, který je složen z Business tříd. Tyto třídy by měly co nejvýstižněji modelovat, to co v reálném světě. Má-li systém umožňovat rezervaci vstupenek na představení, určitě by se v systému měla objevit třída rezervace a představení. Třídy se navrhnou pomocí diagramu tříd, který pochází z UML rodiny. Diagram tříd popisuje třídy a vztahy mezi nimi. Třída je reprezentována obdélníkem, který obsahuje název, atributy a metody třídy. Mezi jednotlivými třídami se mohou vyskytnout nějaké souvislosti, definují se jako vztahy asociace, kompozice, realizace a generace.

4.5.1

Návrh modelových tříd

Obrázek 4.6: Diagram modelových tříd

31

4.5.2 Sequence diagramy V této části analýzy jsou již zpracované případy užití a návrh modelových tříd. K dispozici jsou téměř všechny nezbytné informace, které potřebujeme k zahájení samotného programování. Existují však tzv. sekvenční diagramy pocházející z rodiny UML, které velmi dobře znázorňují použití objektů v aplikaci. Diagramy jsou většinou integrovány na konkrétní případy užití, které jsou z pohledu programátora příliš obecné. Avšak sekvenční diagramy demonstrují všechny použité objekty, zprávy a metody, které jsou na daný případ užití aplikovány. Následující sequence diagram znázorňuje případ užití přidání nového představení. Jak vidíme, v horní části se nacházejí instance tříd. Přerušovaná čára, která z nich vychází, reprezentuje životnost objektu. Obdélník, který se nachází na přerušované čáře, znázorňuje aktivitu objektu. Instance třídy může posílat jiným objektům zprávy s očekávaným výstupem, v diagramu jej značíme šipkami.

Obrázek 4.7: Sequence diagram - Přidání nového představení

32

Krok po kroku 1. Správce systému si vyžádá přidání nového představení. 2. Případ užití má na starosti řadič s názvem addPredstaveni, který obsahuje instance třech modelových tříd. 3.

Řadič volá metody checkStart, getErrorList, getValueList a isCheck.

4. Na základě výsledků metody isCheck se volají metody objektů tříd Predstaveni a Sal. Objeví-li se na výstupu metody isCheck hodnota true, volá se metoda addPredstaveni, objeví-li se na výstupu hodnota false, volají se metody getPrizemi a getBalkon.

Z těchto posloupností je tedy naprosto zřejmé, jak a kdy používat modelové objekty. Na obrázku 4.8: Seguence diagram - Registrace uživatele do systému vidíme další sequence diagram, který popisuje konkrétní případ užití.

Obrázek 4.8: Seguence diagram - Registrace uživatele do systému

33

5 Implementace Tato kapitola popisuje závěrečný vývoj aplikace a tedy vlastní programování. Podrobně nastiňuje jednotlivé použití a strukturu komponent návrhové vzoru MVC. Dále je zkoumána funkcionalita servisních a business tříd.

5.1 MVC architektura Použití návrhového vzoru MVC ve webových aplikacích je velmi specifické. Striktní dodržení pravidel architektury vyžaduje naprosté oddělení komponent řadiče a pohledu, což by se v tomto projektu dalo realizovat, mělo by to ovšem negativní vliv na výkon softwaru. Proto byla v aplikaci akceptována malá odchylka od architektury MVC, avšak ta nemá žádný vliv na zmiňované výhody architektury. Komponenty typu řadič obsahují část řídící struktury komponenty pohled. Znamená to, že v PHP skriptech reprezentující řadič se objevuje objekt šablonovacího systému Smarty, který kompiluje a vykresluje šablony. Řešením problému by bylo navrhnout třídu, která by obsahovala referenci na objekt Smarty a skrze něj by pracovala se šablonami. S touto třídou by pak pracovala komponenta řadič. Byl by to jakýsi řídící prvek komponenty pohled. Ovšem z hlediska rozsahu, přehlednosti a struktury webové aplikace by to byl pouze jakýsi mezikrok, který nemá velké opodstatnění a měl by záporný vliv na výkon aplikace.

5.1.1 Model Komponenta model je reprezentována Business a Servisními třídami, které jsou detailně popsány dále.

5.1.2 Pohled Pohled, jak už bylo řečeno, je jedna ze základních komponent MVC architektury. Jedná se o prezentační část aplikace, výslednou grafickou podobu zobrazí v podobě HTML tagů. K tomuto účelu byl tedy použit šablonovací systém Smarty, který vyžaduje striktní dodržení souborové struktury. Všechny použité šablony, čili soubory s příponou .tpl, se musí nacházet v adresáři templates. Vysvětleme si na konkrétním příkladu princip šablon. Metoda objektu Smarty display() zobrazí obsah šablony, jejíž název je zároveň parametrem metody. Tato šablona main.tpl obsahuje základní strukturu výsledné stránky. Nalezneme zde základní pilíře webové stránky v podobě tagů a . V párovém tagu 34

body si můžeme všimnout formule, které rozumí jazyk Smarty, jde o instrukci ve složených závorkách include file, touto funkcí docílíme toho, že v tomto místě můžeme vložit jinou šablonu, jejíž název specifikujeme v řadiči. Touto metodou dosáhneme minimální redundanci HTML kódu. Můžeme říci, že jediná část, která se v HTML kódu mění, je pouze obsah stránky, ten se vkládá zmiňovanou instrukcí {include file={$CONTENT}}, kde $CONTENT je proměnná, ve které je uložena adresářová cesta k příslušné šabloně.

5.1.3 Řadič Komponenta řadič zajišťuje vzájemnou komunikaci mezi modelovou vrstvou a aplikační vrstvou. Z hlediska kódu je to skript, který dle potřeby používá instance Business a Servisních tříd. Na základě instrukcí sestaví šablonu, která obsahuje HTML kód a tu odešle protokolem HTTP klientovi. Z hlediska webové aplikace si řadič můžeme představit jako jeden konkrétní PHP skript. Vysvětlíme si, jak funguje a co vše obsahuje na konkrétním případu. V prvním kroku procesu rezervace musíme z nabídky nejprve vybrat představení. 35

To vše realizuje jedna webová stránka, kterou reprezentuje řadič v podobě PHP skriptu s názvem program.php viz obrázek. Nejprve připojíme třídu Smarty.php, Servisní třídu Access.php a Business třídu Program.php. Poté vytvoříme instanci třídy Smarty.php a její metodou assign() přidáme potřebné šablony. Pomocí třídy Aceess a skriptu access.php ověříme přístup uživatele. V další části kódu použijeme Business třídu Program, jejíž metody provádí logickou část, v tomto případě získají informace o aktuálním programu DKO, dále sestaví filtr usnadnění orientace mezi jednotlivými měsíci a poskytne rezistentní data. Následně si tyto data v podobě jedno, či dvourozměrného pole přidají do objektu Smarty. V závěru se volá metoda display(), která vložené informace zkompiluje a odešle klientovi. assign('INCLUDE_JS' , 'js/jquery.js'); $objSmarty->assign('LOGIN'

,

'templates/login.tpl'); $objSmarty->assign('CONTENT'

,

'templates/content/program.tpl'); $objAccess = new Access(1); require_once 'access.php'; $objProgram = new Program(); $objProgram->filter_month(); $objProgram->get_db_program(); $objSmarty->assign('FILTER',

$objProgram->get_month());

$objSmarty->assign('PROGRAM', $objProgram->get_program()); $objSmarty->display("main.tpl"); ?>

36

5.2 Business třídy Business třídy v aplikaci tvoří modelovou vrstvu. Zastávají veškerou aplikační logiku softwaru. Podle analýzy modelu domény, respektive na základě diagramu tříd a sequence diagramu, byly tyto třídy naprogramovány. Metody tříd byly doplněny o programovací kód, který zastává požadovanou funkcionalitu a komunikuje s bází dat. Až na pár výjimek, byla výsledná struktura shodná s počátečním návrhem modelových tříd.

5.3 Servisní třídy Jak už bylo řečeno, servisní třídy patří též do modelové vrstvy aplikace. Kniha PHP6 doporučuje tyto třídy konstruovat tak, aby byly statické. Při použití statické třídy se totiž nemusí vytvářet instance. Z hlediska jejich charakteru bývá pravidlem, že takovéto třídy jsou považovány za znovupoužitelné, mají tedy široký okruh uplatnění. V následujících kapitolách jsou tyto třídy detailně popsány a vysvětleny.

37

5.3.1 Třída DB Mezi důležité servisní třídy patří třída s názvem DB. Jejím úkolem je navázat spojení s databází a umožnit realizaci SQL dotazů. Jedná se o statickou třídu, proto se při jejím použití nemusí vytvářet instance. To je výhodné, zejména při nutnosti použití databáze ve více souborech, či jiných třídách.

Obrázek 5.1: Třída DB

Třída byla zkonstruována na základě dvou myšlenek z knih PHP6 a Mistrovství v MySQL. V rozsáhlých projektech je běžné, že spojení s databází je zapotřebí realizovat ve více částech programu. Je ale nesmyslné opakovaně vytvářet nové připojení k databázi. Konstrukce pro připojení s databází je inspirována návrhovým vzorem singleton. Jedná se o použití statické metody, která na výstupu vrací připojení k databázi. Tato metoda nejprve zjistí, zda už nějaké připojení k databázi existuje, zdali ano, toto připojení vrátí, zdali připojení neexistuje, vytvoří nové připojení a to následně také vrátí. Tento děj je realizován pomocí globální proměnné typu dvourozměrného pole, které obsahuje pouze jednu hodnotu, v níž je uloženo připojení k databázi. Index tohoto prvku v poli je serializovaný řetězec přístupových údajů k databázi šifrovaný PHP funkcí MD5. Za předpokladu, že přístupové údaje budou vždy stejné, což se v této aplikaci očekává, nemůže dojít k navázání více jak jednoho připojení k bázi dat.

38

Funkce realizující připojení k databázi: public static function getConnect() { $data = DB::data(); $key = md5(serialize($data)); if(!isset($GLOBALS["db_handle"][$key]) || !($GLOBALS["db_handle"][$key]) instanceof mysqli) { try { $GLOBALS["db_handle"][$key] = @new mysqli($data['host'],$data['username'],$data['password'],$d ata['database']); if(mysqli_connect_errno()) throw new Exception("Pripojeni k databazovemu serveru se nezdarilo! "); else $GLOBALS["db_handle"][$key]>set_charset("utf8"); } catch(Exception $e) { die($e->getMessage()); exit(); } } return $GLOBALS["db_handle"][$key]; }

Další metody třídy DB realizují databázové dotazy. Metody jsou rozděleny dle typů SQL dotazů. Požaduje-li se například uskutečnění dotazu typu INSERT INTO, od databáze se tedy neočekává žádný výsledek, pouze informace o průběhu dotazu v podobě hodnoty typu boolean, využije se metoda query_command(). Předpokládá-li se však jako výsledek dotazu dvourozměrné asociativní pole, aplikuje se metoda query_array().

39

5.3.2 Třída Access Hlavním úkolem třídy Access je realizovat autentizaci uživatelů. Jediným atributem třídy Access je user_level, který charakterizuje typ uživatele, může nabývat číselnou hodnotu od nuly do tří, kde každá z číslic indikuje následující stavy.

0

Neregistrovaný uživatel

1

Registrovaný uživatel

2

Administrátor

3

Neregistrovaný uživatel + Registrovaný uživatel + Administrátor Tabulka 5.1: Typy uživatelů

V jednotlivých oddílech aplikace je zapotřebí rozlišit oprávnění k přístupu dle typu uživatele. Je zřejmé, že kompetenci pro případ užití Přidání představení bude mít pouze správce systému. V příslušném skriptu se deklaruje objekt třídy Access, parametrem konstruktoru se upřesní typ uživatele, pro správce systému tedy číslo dvě. Objekt se poté spojí s databází a zjistí, zda je přístup oprávněný.

Obrázek 5.2: Třída Access

Třída Access pro uložení identifikátoru uživatele používá PHP funkci session. Požaduje-li se uchovávat proměnné, které budou identifikovat konkrétní uživatelé, hodnoty by se musely odesílat při každém požadavku na obnovení webové stránky. Efektivnější způsob spočívá v použití PHP session. Je to metoda, která umožňuje ukládání proměnných hodnot přímo na serveru, které jsou spárovány s konkrétními uživateli. Funkce session 40

vygeneruje kód, který se automaticky odesílá s HTTP protokolem a u koncového uživatele se uloží do proměnné cookies. Tato hodnota se při jakémkoli požadavku uživatele odesílá zpět na server, kde se porovná s jinými možnými identifikátory a při shodě dojde k oprávnění přístupu k proměnným. Je to dosti rafinovaný způsob zabezpečení, ale není neprolomitelný. Vygenerovaný kód lze však odposlouchat a zneužít k přístupu do nepřístupné části aplikace. Proto se vygenerovaný identifikační kód často kombinuje s jinými hodnotami, ukládá se například IP adresa, datum, či typ prohlížeče.

5.3.3 Třída CheckForm V aplikaci se objevují formulářové prvky, které přenášejí data zadaná uživatelem do báze dat systému. Před zpracováním údajů je nezbytné kontrolovat obsah dat. Byla tedy navrhnuta servisní třída CheckForm, která validaci provádí. V základním provedení tato třída rozezná, zda je hodnota formulářového pole obsažena v globálních proměnných POST a GET. Dále umožňuje kontrolovat několik základních požadavků na přijatý řetězec: viz tabulka. Tyto metody k validaci textových řetězců používají regulární výrazy. Regulární výraz je jakési předepsané pravidlo definované metaznaky, které se aplikuje na daný textový řetězec. Očekává se tedy, že kontrolovaná hodnota bude obsahovat pouze dané znaky, v určitém pořadí a v daném počtu. Tuto kontrolu vyhodnocuje PHP funkce ereg(), která očekává dva parametry. V prvním parametru regulární výraz a v druhém parametru kontrolovaný řetězec. V případě, že je regulární výraz splněný, vrací hodnotu true, v opačném případě vrací false. Toto je například regulární výraz pro validaci emailové adresy: '^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$' Check_require()

Povinný údaj

Check_min()

Minimální počet znaků

Check_max()

Maximální počet znaků

Check_email()

Odpovídá platnému emailu

Check_tel()

Odpovídá platnému telefonímu číslu

Check_onlyNumbers()

Pouze číselná hodnota

Tabulka 5.2: Validační metody třídy CheckForm

41

Názvy požadovaných formulářových polí a validační metody, které se na dané textové řetězce aplikují, se definují pomocí dvourozměrného asociativního pole, jenž se předává pomocí parametru konstruktoru třídy. Další požadavky na validaci můžeme ovšem postupně přidávat metodou addCheck(). Máme-li definované požadavky, zahájíme validaci metodou checkStart(). Zdali kontrola proběhla správně, informuje metoda isCheck(). Objeví-li se nějaké nekonzistentní hodnoty, lze si vyžádat seznam v podobě asociativního pole, pomocí kterého můžeme uživatele o těchto validačních problémech informovat.

5.4 Použitý JavaScript V aplikaci se objevují střípky JavaScriptu. Jedná se o objektově orientovaný skriptovací jazyk, který se vkládá přímo do HTML kódu, nebo se importují celé soubory s příponou js. Velmi často je používána knihovna JQuery, která je napsaná v JavaScriptu a má spoustu již definovaných funkcí. Programátorovi usnadní práci a razantně sníží čas potřebný k vývoji některých dynamických prvků stránky. V rezervačním systému je použita například funkce post(), která je určena k navázání spojení se serverem, aniž by byl odeslán požadavek na obnovení, či načtení nové webové stránky. Funkce post pomocí knihovny JQuery: $(document).ready(function() { $.post("rezervace.php", {predstaveni:predstaveni, umisteni:umisteni, rada:rada, sedadlo:sedadlo}, function(data) { } ); }); });

42

6 Závěr Cílem této bakalářské práce bylo prostudovat a popsat použití šablonovacího systému a MVC architektury ve webových aplikacích a tyto poznatky využít k návrhu a implementaci webového systému pro DKO Jihlava, který umožňí rezervaci vstupenek na představení v divadelním sále. Úvodní část bakalářské práce se věnuje studii návrhovému vzoru MVC softwaru a šablonovacímu systému Smarty. Je charakterizován základní princip použití architektury MVC, její specifikace a výhody. Dále je podrobně popsán způsob aplikování systému Smarty. Tato kapitola je částečným podkladem k analýze rezervačního systému pro DKO Jihlava. Již v návrhu struktury softwaru bylo nezbytně nutné dodržet a postupovat v souladu s charakteristickými rysy zvolené architektury. Mimo jiné zde byly zpracovány a vyhodnoceny veškeré zadavatelské požadavky, které byly též podnětem k návrhu aplikace. V další kapitole je popisována implementace, která vychází ze studie MVC a analýzy problémové domény. Při implementaci se objevila drobná nesrovnalost při použití MVC architektury v důsledku specifické charakteristiky webové aplikace. Problém je vysvětlen, dále je navrhnuto možné východisko, avšak toto by mělo negativní dopad na výkon aplikace, proto bylo ponecháno prvotní řešení. Ze strany DKO Jihlava bylo navrhnuto možné rozšíření aplikace, které by klientům nabízelo různé metody plateb za rezervované vstupenky, zejména platba uskutečněná převodem na účet a platba pomocí kreditní karty. Dnes tyto způsoby plateb nabývají velmi na popularitě, uživatelé rezervačního systému by je bezesporu uvítali.

43

Literatura [1]

LECKY-THOMPSON, Ed a Steven D NOWICKI. PHP 6: programujeme profesionálně. Vyd. 1. Překlad Ondřej Gibl. Brno: Computer Press, 2010, 718 s. Programujeme profesionálně. ISBN 978-802-5131-275.

[2]

VRÁNA, Jakub. 1001 tipů a triků pro PHP. Vyd. 1. Brno: Computer Press, 2010, 456 s. ISBN 978-802-5129-401.

[3]

KOFLER, Michael. Mistrovství v MySQL 5. Vyd. 1. Překlad Jan Svoboda, Ondřej Baše, Jaroslav Černý. Brno: Computer Press, 2007, 805 s. ISBN 978-802-5115022.

[4]

Gutmans, Andi; BAKKEN, Stig; RETHANS, Derick: mistrovství v PHP. 2. vyd. Brno: Computer Press, a.s., 2008. 655 s. ISBN 978-80-251-1519-0.

[5]

DARIE, Cristian; BRINZAREA, Bogdan; CHERECHES-TOSA, Filip; BUCICA, Mihai: AJAX a PHP tvoříme interaktivní webové aplikace PROFESIONÁLNĚ. 1. vyd. Brno: Zoner Press, 2006. 320 s. ISBN 80-86815-47-1.

[6]

PHP Template Engine | Smarty [online]. [cit. 2011-11-18]. Dostupné z: http://www.smarty.net/

[7]

JQuery: The Write Less, Do More, JavaScript Library [online]. [cit. 2011-11-23]. Dostupné z: http://jquery.com/

[8]

PHP:

Hypertext

Preprocessor

[online].

[cit.

2011-11-23].

Dostupné

z:

http://www.php.net/ [9]

MySQL :: The world's most popular open source database [online]. [cit. 2011-1123]. Dostupné z: http://www.mysql.com/

44

Seznam zkratek MVC

(Model View Controller) - softwarová architektura

PHP

(Hypertext Preprocessor, původně Personal Home Page) - programovací jazyk

HTML

(HyperText Markup Language) - značkovací jazyk určený pro vývoj webových stránek

CSS

(Cascading Style Sheets) - jazyk pro způsob specifikace zobrazení webových stránek

JAVA

programovací jazyk

C++

programovací jazyk

HTTP

(Hypertext Transfer Protocol) - internetový protokol

SQL

(Structured Query Language) - standardizovaný databázový jazyk

MySQL

databázový systém

LAMP

(Linux, Apache, MySQL, PHP / Perl / Python) - sada softwaru jako platforma pro realizaci internetových stránek

GUI

(Graphical user interface) - část softwaru, grafické uživatelské rozhranní

PDA

(personal digital assistant) - malý kapesní počítač

ERM

(Entity-relationship model) - metoda datového modelování

UML

(Unified Modeling Language) - grafický jazyk pro vizuální návrh softwaru

jQuery

(Javascript Query) – knihovna JavaScriptu

45

Seznam příloh Literatura ............................................................................................................................. 44 Seznam zkratek .................................................................................................................... 45 Seznam příloh ...................................................................................................................... 46 A Grafická podoba............................................................................................................... 47 B Diagram užití ................................................................................................................... 49 D Diagramy sequence .......................................................................................................... 53 E Diagram ER ...................................................................................................................... 56 F Diagramy tříd ................................................................................................................... 57 G Souborová struktura aplikace .......................................................................................... 58 H Přiložené CD

46

A Grafická podoba

Obrázek A.1: Rezervace - přehled představení

47

Obrázek A.2: Rezervace - přehled sedadel v sále

48

B Diagram užití

Obrázek B.1: Diagram užití

49

C Diagramy aktivit

Obrázek C.1: Diagram aktivit - Rezervace sedadel na představení

Obrázek C.2: Diagram aktivit - Registrace uživatele do systému

50

Obrázek C.3: Diagram aktivit - Přidání nového představení

Obrázek C.4: Diagram aktivit - Zobrazení přehledu rezervací

51

Obrázek C.5: Diagram aktivit - Zobrazení přehledu uživatelů

Obrázek C.6: Diagram aktivit - Zobrazení detailu rezervace

Obrázek C.7: Diagram aktivit - Zobrazení detailu rezervace

52

D Diagramy sequence

Obrázek D.1: Sequence diagram - Registrace uživatele do systému

53

Obrázek D.2: Sequence diagram - Přidání nového představení

Obrázek D.3: Sequence diagram - Zobrazení přehledu rezervací

54

Obrázek D.4: Sequence diagram - Zobrazení přehledu uživatelů

Obrázek D.5: Sequence diagram - Zobrazeni detailu rezervace

Obrázek D.6: Sequence diagram - Zobrazení detailu uživatele

55

E Diagram ER

Obrázek E.1: Diagram ER

56

F Diagramy tříd

Obrázek F.1: Modelové třídy

Obrázek F.2: Servisní třídy

57

G Souborová struktura aplikace

Obrázek G.1: Souborová struktura aplikace

58