Tvorba webové aplikace za využití frameworku Nette

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra systémové analýzy

Studijní program: Aplikovaná informatika Obor: Informatika

Tvorba webové aplikace za využití frameworku Nette BAKALÁŘSKÁ PRÁCE

Student

:

Tomáš Křížek

Vedoucí

:

Ing. Martin Sova

Oponent :

Ing. Jaroslav Kalina

2013

Prohlašuji, že jsem bakalářskou/diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.

V Praze dne 8. května 2014

.................................. Tomáš Křížek

Poděkování Tímto bych rád poděkoval mému vedoucímu práce Ing. Martinu Sovovi, za poskytnuté rady a konzultace. Dále Bc. Renatě Saifrtové za cenné připomínky a dávky optimismu. A v neposlední řadě také všem ostatním, kteří se podíleli na ladění výsledné aplikace.

Abstrakt Cílem této práce je návrh a vývoj webové aplikace, která je založena na strategické deskové hře Diplomacie. Tato aplikace je vystavěna na českém frameworku Nette, s jehož základy je čtenář během práce seznámen. Kromě frameworku Nette a možností samotného jazyka PHP, je při tvorbě využito také technologií MySQL, XML a jQuery.

Klíčová slova webová aplikace, desková hra, framework, php, mysql, xml, Nette

Abstract The objective of this thesis is to design and develop a web application that is based on a strategic board game Diplomacy. This application is built on the czech Nette framework, about which the reader is familiarized during thesis. Besides framework Nette and scripting language PHP, is used MySQL, XML and jQuery.

Keywords web application, board game, framework, php, mysql, xml, Nette

Obsah 1

Úvod .................................................................................................................. 1 1.1 Cíle práce ..........................................................................................................................1 1.2 Struktura práce ................................................................................................................1 1.3 Předpokládaný výsledek práce.......................................................................................1

2

Popis deskové hry Diplomacie a stanovení kritérií pro tvorbu webové aplikace ................................................................................................................ 2 2.1 2.2 2.3 2.4

Základní popis a stručná historie hry Diplomacie ........................................................2 Shrnutí pravidel................................................................................................................2 Průběh hry ........................................................................................................................4 Typy rozkazů ....................................................................................................................5 2.4.1 Rozkaz k obraně ..................................................................................................5 2.4.2 Rozkaz k útoku ....................................................................................................5 2.4.3 Rozkaz k podpoře v obraně ...............................................................................5 2.4.4 Rozkaz k podpoře v útoku ..................................................................................5 2.4.5 Rozkaz konvoj .....................................................................................................6 2.5 Vyhodnocení bitvy ...........................................................................................................6 2.6 Definice kritérií .................................................................................................................6

3

Postupy tvorby webové aplikace ....................................................................... 7 3.1 Procedurální programování ............................................................................................7 3.2 Objektové programování .................................................................................................7 3.3 Návrhové vzory ................................................................................................................8 3.3.1 Singleton..............................................................................................................8 3.3.2 Factory Method ...................................................................................................9 3.4 Framework ......................................................................................................................10 3.4.1 Důvody pro využití frameworku .......................................................................11 3.4.2 Oddělení kódu a zobrazovací logiky ...............................................................11 3.4.3 Validace .............................................................................................................11 3.4.4 Přepisování URL ...............................................................................................11 3.4.5 Object Relation Mapping ..................................................................................12 3.4.6 Servisní třídy .....................................................................................................12

4

Framework Nette ............................................................................................... 13 4.1 4.2 4.3 4.4 4.5

Struktura projektu na Nette ...........................................................................................14 Dependency Injection a DI kontejner ...........................................................................15 Auto-loading tříd ............................................................................................................16 Debugování a zpracování chyb ....................................................................................17 Routování URL ...............................................................................................................19

4.6 Model-View-Presenter ...................................................................................................19 4.6.1 Životní cyklus presenteru .................................................................................20 4.6.2 Model a jeho použití v presenteru ...................................................................21 4.6.3 View a šablonovací systém Latte ....................................................................22 4.7 Flash zprávy ...................................................................................................................23

5

Návrh aplikace ................................................................................................... 24 5.1 Funkční nároky na aplikaci ...........................................................................................24 5.1.1 Uživatelská sekce..............................................................................................24 5.1.2 Hrací plán...........................................................................................................24 5.1.3 Vyhodnocování příkazů ....................................................................................25 5.2 UML diagram aktivit .......................................................................................................25 5.3 UML konceptuální diagram ...........................................................................................26 5.4 Návrh GUI .......................................................................................................................28 5.4.1 Přehled her ........................................................................................................28 5.4.2 Návrh hracího plánu .........................................................................................28

6

Implementace aplikace ..................................................................................... 30 6.1 Uživatelské rozhraní ......................................................................................................30 6.2 Herní plán .......................................................................................................................31 6.2.1 Řešení grafického vykreslení políček a armád ...............................................31 6.2.2 Zadávání rozkazů ..............................................................................................32 6.3 Vyhodnocení rozkazů ....................................................................................................34 6.3.1 Vyhodnocení bitevních rozkazů.......................................................................34 6.3.2 Vyhodnocení ústupů.........................................................................................39 6.3.3 Vyhodnocení obsazených území a stavba jednotek ......................................39

7

Závěr ................................................................................................................ 40 7.1 Shrnutí cílů .....................................................................................................................40

Seznam zdrojů ......................................................................................................... 41

1 Úvod

1

1 Úvod 1.1

Cíle práce

Cílem této práce je vytvoření plně funkční webové aplikace, která bude založena na deskové hře Diplomacie a bude splňovat všechna kritéria stanovena v návrhu. Dalším cílem je přiblížit čtenáři základy českého PHP frameworku Nette a samotný postup tvorby webové aplikace.

1.2

Struktura práce

V samém začátku práce je popsána výše zmíněná desková hra Diplomacie a vyzdviženy důvody, proč je právě tato hra vhodná pro přepracování do nového formátu webové aplikace. Jsou zde také definována kritéria, na základě jejichž splnění je možné považovat aplikaci za plně funkční a hratelnou. Druhou část práce tvoří návrh aplikace a samotná implementace. Závěr je věnován vyhodnocení úspěšnosti splnění zadaných kriterií a shrnutí výsledků práce.

1.3

Předpokládaný výsledek práce

Hlavním výstupem práce je plně funkční webová aplikace, která bude umístěna na adrese diplomacie.pripravujeme.eu, kde bude přístupná široké veřejnosti. Aplikace by měla více zpopularizovat deskovou hru Diplomacie a umožnit každému její bezplatné vyzkoušení. Klíčem k úspěchu je funkční, ale zároveň atraktivní grafické rozhraní.

2 Popis deskové hry Diplomacie a stanovení kritérií pro tvorbu webové aplikace

2

2 Popis deskové hry Diplomacie a stanovení kritérií pro tvorbu webové aplikace V této části je představena desková hra Diplomacie a jsou zde stanovena kritéria nutná pro plně funkční webovou aplikaci, která bude vytvořena na základech této hry.

2.1

Základní popis a stručná historie hry Diplomacie

Diplomacie je stolní strategická hra, kterou v roce 1954 vytvořil americký pošťák Allan Brian Calhamer. Odehrává se na mapě Evropy v období před první světovou válkou. Každý hráč ovládá jednu ze sedmi velmocí a snaží se postupně obsazovat území ostatních hráčů. A protože samostatně nelze získat dostatečnou převahu, musí se hráči mezi sebou domlouvat, pomáhat si a vytvářet mocné aliance, aby si následně ve správné chvíli bodli kudlu do zad. Kromě vytříbené bojové strategie je tedy potřeba i kvalitních komunikačních dovedností a odhadu, kdy opustit potápějící se loď a přeskočit na druhý břeh. Tato hra stejně jako například šachy, potlačuje faktor náhody na pouhé rozlosování počátečních pozic. Od chvíle, kdy má každý zvolenou svou velmoc, je celý osud Evropy v rukách hráčů. Další zajímavostí je i samotný průběh hry. Většina deskových her je hrána na tahy a to v tom smyslu, že se jednotlivý hráči postupně střídají v předem daném pořadí. Oproti tomu v Diplomacii během jednoho tahu hrají všichni hráči zároveň. Tento postup je vyřešen tak, že všichni hráči tajně sepíší své rozkazy a ty pak dohromady vyhodnocuje gamemaster1 hry. Tento řídící prvek hry může být právě jednoduše nahrazen algoritmem, který server vyhodnotí. Diplomacie byla také první komerčně vydanou hrou určenou ke korespondenčnímu hraní, které bylo později nahrazeno hraním přes email. Díky tomu již existuje komunita hráčů, která se odpojila od tradiční deskové varianty a je u nich větší pravděpodobnost k přechodu od emailu k webové aplikaci. (1)

2.2

Shrnutí pravidel

Klasická verze hry se hraje v sedmi hráčích a to na mapě Evropy z roku 1901. Z té doby je vybráno i sedm velmocí, které jsou náhodně rozlosovány mezi hráče.

1

Gamemaster je nezávislý rozhodčí hry, který vyhodnocuje všechny rozkazy a řídí hru.


3

 Anglie (London, Edinburgh, Liverpool),  Francie (Paris, Brest, Marseilles),  Německo (Berlin, Munich, Kiel),  Rakousko-Uhersko (Vienna, Budapest, Trieste),  Itálie (Roma, Venezia, Napoli),  Turecko (Constantinople, Ankara, Smyrna),  Rusko (Moscow, Saint Petersburg, Warsaw, Stevastopol)

Obrázek č. 1 – Hrací plán k deskové variantě z roku 1999 (Zdroj: 2)

Na mapě je kromě neutrálních polí také 34 zásobovacích center, která jsou na ilustračním obrázku označeny žlutým sluníčkem. Cílem každého hráče je obsadit většinu, tedy 18 těchto zásobovacích center. Každá z velmocí začíná se třemi. Pouze Rusko má v počátku hry výhodu jednoho zásobovacího centra navíc. Jak již název napovídá, ovlivňují tyto zásobovací centra počet armád, které je velmoc schopna uživit. Armády se ve hře vyskytují ve dvou typech a to buď jako pěší jednotky nebo flotily. Nijak se neliší svou bitevní silou, pouze mají rozdílné možnosti pohybu. Pro jednodušší rozlišení


4

budu dále používat pojmenování „armáda“ pro pěší jednotku a „flotila“ pro lodě. Armády se tedy mohou přesouvat pouze po souši. V případě že potřebují překonat moře, musí využít flotilu nebo více flotil, které umožní speciální přesun přes konvoj. Tento pohyb bude více popsán v části zabývající se typy rozkazů. Flotily se pohybují po mořích nebo po pobřežních políčkách sousedících s mořem. Na každém políčku může po vyhodnocení bitev a přesunů zůstat vždy jen jedna jednotka.

2.3

Průběh hry

Celé jedno kolo je v Diplomacii prezentováno jako rok a skládá se z několika herních fází, které jdou po sobě vždy ve stejném pořadí. Rok je rozdělen na dvě válečná období jaro a podzim, pro která se vždy zadávají rozkazy armádám. Po skončení bitev na podzim jsou také vyhodnocena získaná a ztracená území. Zabírat lze pouze pole označená jako zásobovací centra. Následně se porovná počet vlastněných armád a flotil s počtem zásobovacích center. Pokud má hráč více zásobovacích center než jednotek a má ve svých rodných městech volno, (kvůli pravidlu o jedné jednotce na políčku nelze stavět jednotky v městech, ve kterých se již nějaká jednotka nachází) může si zadat rozkaz pro stavbu nových jednotek. Flotily lze stavět pouze v přímořských městech. Pokud má hráč naopak více jednotek než zásobovacích center, je nucen některé jednotky rozpustit. Tento proces se stále opakuje, dokud některý z hráčů nezíská vítěznou většinu zásobovacích center.

Vyhodnocení bitev

Rozkazy pro podzim

Vyhodnocení bitev

Rozkazy pro jaro

Stavba a rozpouštění jednotek

Vyhodnocení zabraných území

Diagram č. 1 – Průběh hry (Zdroj: autor)


2.4

5

Typy rozkazů

Aby mohlo dojít k přesunu a bitvám armád, musí každá jednotka dostat přesné rozkazy od svého velitele. Ty se zapisují před každým tahem, jsou přísně tajné a za žádných okolností si je hráči nesmí ukázat.

2.4.1

Rozkaz k obraně

Jedná se o nejjednodušší a zároveň i základní rozkaz, který se automaticky provádí, pokud jednotka žádný rozkaz neobdržela. Ta se v tomto případě nikam nepřesouvá, brání se silou 1. Může přijímat výhody plynoucí z rozkazu podpora v obraně.

2.4.2

Rozkaz k útoku

Jednotka útočí na sousední pole, kam je dle svého typu oprávněna k přesunu. Pro armády se jedná o všechna suchozemská pole, pro flotily moře a pobřeží. V případě, že se armádě nepodaří prolomit obranu na cílovém poli, zůstává v obraně na své původní pozici, ale již nemůže využít výhod z rozkazu podpora v obraně.

2.4.3

Rozkaz k podpoře v obraně

Podpora v obraně může být udělena pro spřátelenou jednotku na poli, které je podporující jednotkou dosažitelné. (Je možné na toto pole směrovat příkaz k útoku.) Podporované pole získá +1 sílu k obraně. Tato podpora může být zrušena jakýmkoliv útokem na podporující jednotku.

2.4.4

Rozkaz k podpoře v útoku

Podpora v útoku může být udělena pro útok spřátelené jednotky na pole, které je podporující jednotkou dosažitelné. (Je možné na toto pole směrovat příkaz k útoku.) Takovýto útok získá +1 sílu k útoku. Tato podpora může být zrušena jakýmkoliv útokem, kromě útoku vedeného z pole, na které je právě tato podpora směrována. V tomto případě je podpora zrušena pouze úspěšným útokem, který vede k ústupu jednotky.


2.4.5

6

Rozkaz konvoj

Díky tomuto speciálnímu rozkazu mohou flotily umožnit přesun pozemních armád přes moře. Armáda v tomto případě napíše rozkaz ke konvoji na vybrané pobřežní pole. Tento rozkaz má parametry útoku, akorát je proveden pouze v případě, že má na každém mořském poli, které překonává spřátelenou flotilu s rozkazem ke konvoji této armády. Jedná se také současně o jediný rozkaz umožňující překonat více než jedno pole za tah. Flotily se při konvoji nikam nepřesouvají, mohou poskytovat konvoj pouze jedné určené jednotce a to do předem stanoveného pobřežního pole. Flotila, která poskytuje konvoj, nesmí být donucena k ústupu. V takovém případě ji nelze pro přesun po moři použít.

2.5

Vyhodnocení bitvy

Po vyhodnocení všech podpor se spočítá síla jednotek, které bojují o dané pole. Pokud má některá z nich převahu, získá nebo ubrání dané pole. Jednotky, které se bránily a byly poraženy, musí na konci tahu vybrat pole pro ústup. Nelze ustupovat na obsazené pole nebo na pole ze kterého byl veden útok na ustupující jednotku. Také nelze donutit k ústupu své vlastní jednotky. Pokud jsou síly vyrovnány, nedochází k žádným přesunům.

2.6

Definice kritérií

Požadavky na webovou aplikaci jsou: 1. Webová aplikace bude přístupná každému, kdo se zaregistruje. 2. Po přihlášení bude mít uživatel možnost založit novou hru nebo se připojit k již vytvořené. Počet souběžně hraných her pro jednoho hráče nebude omezen. 3. Webová aplikace bude založena na originálních pravidlech deskové hry Diplomacie, které v případě nutnosti lehce přizpůsobí pro algoritmizaci. 4. Aplikace bude postavena na frameworku Nette. 5. Hra bude navržena tak, aby ji bylo v budoucnu možné rozšířit o další verze herního plánu.

3 Postupy tvorby webové aplikace

7

3 Postupy tvorby webové aplikace Při použití programovacího jazyka PHP je nutné nejprve vyhodnotit, jakým způsobem psát kód. Nabízí se totiž dvě varianty. Procedurální nebo objektový přístup. Obě cesty jsou schůdné a poskytují různé výhody a nevýhody. Záleží převážně na typu a složitosti projektu, počtu lidí, kteří se budou na vývoji podílet a v neposlední řadě také na osobních preferencích daného programátora.

3.1

Procedurální programování

Při použití procedurálního přístupu se problém řeší předem danou sérií funkcí, kterým se předají vstupní data, ty jsou určitým způsobem zpracována a posléze použita jako vstup následující funkce. Postup se dá přirovnat k vaření podle receptu. Nejprve vyndáme vajíčka z lednice, rozklepnutím a rozšleháním získáme směs vhodnou k dalšímu zpracování na rozpálené pánvičce, abychom na konci procesu získali méně či více lahodný pokrm. Každá část tohoto procesu přijímá určité vstupy, které přeměňuje na výstupy. Tradičním postupem při procedurálním programování je využití metody Top-down, která spočívá v rozdělování hlavní procedury na čím dál menší části. Při použití příkladu s vajíčky by se tedy jednalo nejprve o hlavní funkci „Vytvoř lahodná míchaná vajíčka“, která se postupně bude rozpadat na dílčí funkce jako „Nakup vajíčka“, „Připrav pokrm“ a „Servíruj“. Tento proces dělení se opakuje do té doby, než jsou získány elementární procedury, které již není tak těžké zrealizovat.

3.2

Objektové programování

Objektový přístup je rozdílný už způsobem uvažování při tvorbě aplikace. Oproti procedurálnímu programování, kde šlo o postupné předávání vstupů a výstupů mezi funkcemi, si můžeme řešený problém rozebrat na objekty, které spolu budou sice spolupracovat, ale nad jejich vlastními aktivitami můžeme uvažovat nezávisle. Dost často se lze při tvorbě objektů držet skutečností z reálného světa, protože vytvářené objekty budou mít pravděpodobně podobné vlastnosti a funkce. Díky tomu si lze řešený problém lépe představit a snadno vyhodnotit, které objekty budou potřeba a jak spolu budou následně spolupracovat. Jako analogie poslouží např. stavba domu, kdy se instalatéři zabývají trubkami a elektrikáři zase elektroinstalací. Instalatéry nemusí zajímat, jestli je okruh v ložnici na 10


8

nebo 20 ampérů. Zabývat se musí pouze svou vlastní prací. Firma zaštiťující celou stavbu pak zajišťuje, že každý ze subdodavatelů dělá svou práci tak, jak je zapotřebí, ale nutně se nemusí zabývat detaily jednotlivých těchto úkolů. OOP přístup je podobný v tom, že každý z objektů skrývá před ostatními detaily své implementace. Jak svůj úkol provádí, není pro ostatní komponenty systému relevantní. Podstatná je služba, kterou je objekt schopen poskytnout. (3, s. 29-30) Jednou z výhod OOP přístupu je znovupoužitelnost kódu. Vytvořením třídy získáme určitou datovou strukturu a funkcionalitu, které poté může být využita na mnoha místech v aplikaci. Například taková třída Osoba může obsahovat parametry jako jméno, datum narození nebo pohlaví. Poté na základě těchto informací dokáže vygenerovat aktuální věk nebo vhodné oslovení. Pokud je tato třída vhodně naprogramována, může byt využita nejen na několika místech v jednom projektu, ale najde své uplatnění třeba i v úplně jiných projektech. Další výhodou je modularita tříd. Pokud je potřeba přidat nějakou funkcionalitu nebo se vyskytla nějaká chyba, opraví se pouze na jednom místě a změna se projeví všude, kde je třída použita. To značně urychlí proces hledání a opravování chyb a také usnadní rozšiřování tříd o nové funkce.

3.3

Návrhové vzory

Stěžejní částí vývoje aplikace je především její návrh. Pokud si špatně navrhneme základy projektu, je velmi pravděpodobné, že se během implementace vyskytne problém, který nebudeme schopni efektivně a korektně vyřešit, bez většího zásahu do kódu celé aplikace. Když se taková situace vyskytne, je to také první signál, že aplikace není příliš flexibilní a případné změny nebo rozšíření funkčnosti, by mohly představovat velkou dávku frustrace při přepisování starého kódu a v neposlední řadě i znatelné navýšení nákladů na projekt. Návrhové vzory nejsou žádnou knihovnou nebo částí zdrojového kódu, kterou bychom přímo vkládali do svého projektu. Jde spíše o šablonu či postup, který se osvědčil při řešení určitého problému a je tedy výhodné stejné problémy řešit podle takto zavedeného postupu. (4, s. 17-18)

3.3.1

Singleton

V programovacím jazyce PHP lze pomocí klíčových slov public, private a protected nastavit přístup k jednotlivým atributům nebo metodám třídy. Také lze určit, které metody mohou nebo dokonce musí být přepsány. Bohužel už nelze nijak omezit nebo kontrolovat


9

množství instancí dané třídy. K tomu právě slouží jeden z nejjednodušších a zároveň i nejpoužívanějších návrhových vzorů Singleton. Příklad implementace class Singleton { private static $instance = null; public static function getInstance() { if(null == self::$instance) { self::$instance = new self(); } return self::$instance; } protected function __construct() {} private function __clone () {} } Definice Návrhový vzor Singleton zajistí, že z určité třídy může existovat nejvíce jedna instance, a poskytne k ní globální přístupový bod. (4, s. 49-57)

3.3.2

Factory Method

Pokud vytváříme jednotlivé instance tříd pomocí operátoru new přímo tam, kde je zrovna potřebujeme, zaděláváme si na problém. Když totiž bude tvorba instancí roztříštěna na mnoha místech v kódu, znamená to, že každou změnu budeme muset zapracovávat na všech těchto výskytech. To sebou opět přináší vyšší náklady a zvyšuje šanci výskytu chyb. Tento problém řeší návrhový vzor Factory Method. Spočívá ve vytvoření abstraktní třídy, která definuje metodu pro vytvoření a následné vrácení instance daného objektu. Jelikož je tato třída nastavena jako abstraktní, nemůže být použita pro vytváření konkrétních instancí. Proto tedy musí být nejdřív vytvořen potomek této abstraktní třídy, který bude určenou výrobní metodu implementovat. Tím je zajištěno, že zapracování případných změn lze provést pouze změněním této metody a odpadá tedy nutnost dlouze procházet celý zdrojový kód aplikace. Další výhodou je


10

možnost s instancí ještě nějakým způsobem pracovat než ji vrátíme k používání. Tím se také dá omezit velké množství kódu, který bychom jinak byli nuceni opakovat po každém vytvoření instance. Určitou nevýhodu je ale nutnost pro každou konkrétní implementaci odvozovat novou třídu. Často je potřeba tuto třídu vytvářet jen za jedním účelem a obsahuje pouze pár řádků kódu pro tvorbu a vrácení žádaného objektu. V kódu se nám pak začnou vršit instance konkrétních továren, čímž už jsme zase svazování konkrétní implementací. Tento problém lze řešit vytvořením třídy, která implementuje statickou výrobní metodou s parametrem, podle kterého se pak následně rozhoduje, od kterého objektu budeme instanci vytvářet a vracet. Tím pak odpadá nutnost vytvářet instance továrniček. Místo toho si rovnou staticky zavoláme metodu pro vytvoření instance žádaného objektu. Definice Návrhový vzor Factory Method definuje rozhraní pro vytváření objektů, při čemž vlastní tvorbu instancí přenechává svým potomkům. Potomci rozhodují, které konkrétní implementace se mají použít. (4, s. 61-68)

3.4

Framework

Framework je softwarová struktura, která slouží jako podpora při programování a vývoji a organizaci jiných softwarových projektů. Může obsahovat podpůrné programy, knihovny API, podporu pro návrhové vzory nebo doporučené postupy při vývoji. (5) V podstatě jde o takový odrazový můstek pro nový projekt. Za framework se dá považovat pár předdefinovaných tříd, které pak programátor může podle svého uvážení využít. Na druhou stranu může framework představovat robustní systém, který si své správné použití již vynucuje a přímo nás tlačí do určité architektury projektu a vštěpuje nám jisté návyky. To se v případě PHP, jakožto velmi volného a flexibilního jazyka, který programátora nijak nesvazuje, může odrážet dvěma způsoby. Pro nezkušeného vývojáře může být pomocná ruka frameworku k nezaplacení. Zamezí zmatené architektuře projektu, pohlídá základní bezpečnostní nástrahy a celkově povede k přehlednějšímu výstupu. Co se však pro začátečníka může jevit jako božská mana, pro ostříleného programátora může představovat nejednu vzteky rozbitou klávesnici. Proto je dobré při volbě frameworku brát v potaz zkušenosti vývojáře a také rozsah a typ projektu, který bude za pomoci frameworku vytvářen.


3.4.1

11

Důvody pro využití frameworku

Jednoduše řečeno pokud zrovna nevytváříme statický web o třech stránkách a jedním formulářem, dokáže toho za nás framework udělat hodně. Proč tedy znovu vynalézat kolo, když už to udělal někdo jiný. Když píšeme nový složitější projekt, je vždy potřeba vytvořit nějaký podpůrný kód, který se pro většinu projektů bude opakovat. Pokud si tuto část píšeme sami, může to také vést k tomu, že si vytvoříme třeba i vlastní funkční framework, ale nakonec se v něm vyznáme pouze mi sami a pro ostatní to bude španělská vesnice. Z toho tedy plyne další výhoda používání již zaběhlého frameworku. Ten je v první řadě důkladně odladěn a hlavně známý většímu okruhu lidí, kteří se pak mohou podílet na stejném projektu.

3.4.2

Oddělení kódu a zobrazovací logiky

Pravděpodobně i ten nejzákladnější framework by měl trvat na oddělení kódu a zobrazovací logiky. Je to jeden z předpokladů přehledného kódu a dobře strukturované architektury projektu. Docílit toho lze buďto pouhým oddělením skriptů do dvou skupin nebo poněkud elegantněji pomocí šablonovacího systému. (3, s. 394)

3.4.3

Validace

Pokud chceme po uživateli, aby zadával nějaká vstupní data, vždy je lepší počítat s variantou, že to udělá tím nejnešťastnějším způsobem a v naprosto jedinečném formátu. Nelze tedy jen vedle políčka formuláře nadepsat „datum narození zadávejte ve formátu DD-MM-YYYY (např. 22-03-1991)“. Je nutné takovéto vstupy po uživateli zkontrolovat a při nevydařeném pokusu dát i dostatečně přesnou zpětnou informaci, jak má svůj vstup opravit. Hláška o tom, že se v zadaném emailu nenachází zavináč, určitě dovede uživatele k cíli lépe než strohé oznámení, že se ve vyplněném formuláři nacházejí nějaké chyby. Kvalitní frameworky již mají předdefinované některé běžné typy validace a dokonce i vlastní způsob hlášek a upozornění pro uživatele. (3, s. 395)

3.4.4

Přepisování URL

Čím je webová aplikace složitější a rozsáhlejší, tím delší a ošklivější budou i URL adresy, které tato aplikace využívá. Kromě evidentního estetického problému vede tato skutečnost i k dalším komplikacím. Když je adresa dlouhá a komplikovaná, zvyšuje se šance, že při jejím zadávání udělá uživatel chybu nebo si ji vůbec nezapamatuje. Také vyhledávače ocení spíše adresy, které již v názvu jasně stanoví, o čem bude obsah. Pokud je v URL také


12

velké množství parametrů, může to přilákat potencionální hackery, kteří tím dostávají větší šanci porozumět vnitřním principům aplikace. Proto velká část frameworků nabízí nějaký mechanismus přepisu URL adres. To spočívá v zapracování změn na úrovni webového serveru. Buďto tuto konfiguraci obstará framework sám nebo jsou k mání instrukce jak a co nastavit ručně. (3, s. 395)

3.4.5

Object Relation Mapping

Při modelování a vývoji aplikací je snaha co nejvěrněji zachytit realitu. Objekty reálného světa jsou v aplikaci reprezentovány jako entity. Zatímco je v relační databázi entita reprezentována jako řádek, resp. množina řádků v databázových tabulkách, tak v objektově orientovaném jazyce je entita zpravidla reprezentována jako instance nějaké třídy. (6) V podstatě se jedná o abstraktní vrstvu, která zajišťuje přemostění mezi třídami aplikace, jejichž objekty jsou reprezentovány jako záznamy v databázi. Díky ORM není potřeba psát dokola jakýkoliv SQL kód, protože o základní databázové funkce CRUD2 je postaráno. Z toho vyplývá hned několik výhod. První a evidentní je fakt, že se musí napsat mnohem méně kódu a tudíž se zmenšuje i prostor pro případné chyby. Zajímavější je ale spíše snažší přenositelnost na jiné databázové platformy. Protože se komunikace s databází odehrává na jednom místě, stačí vyměnit ORM vrstvu a do zbytku aplikace již není potřeba nijak zasahovat. (7)

3.4.6

Servisní třídy

Často frameworky nabízejí i velké množství tříd, které na první pohled nikam nezapadají. Jedná se o takzvané servisní třídy, které zajišťují různé užitečné funkce jako třeba autentizaci uživatelů, odesílání emailů nebo práci s řetězci. Tyto třídy nemají žádný vliv na samotné fungování frameworku a pokud je nechceme využívat, nemusíme. Na druhou stranu proč vynalézat znovu kolo, když se s trochou důvěry může použít kód někoho jiného. V tomto ohledu tedy nejvíce záleží na samotném programátorovi a na jeho osobních preferencích, jestli si psát pomocné třídy sám nebo využít předpřipravené servisní třídy.

2

CRUD reprezentuje 4 základní operace create, read, update a delete

4 Framework Nette

13

4 Framework Nette Nette Framework je napsaný v PHP 5 s plným využitím objektů (OOP). Ačkoliv vznikl už v roce 2004, teprve vloni byl uvolněn jako open source a zpřístupněn veřejnosti. Jeho licence, která vychází z BSD, patří k těm nejvolnějším. Vyrostla kolem něj jedna z nejaktivnějších komunit českých PHP vývojářů, ne-li nejaktivnější vůbec. Nette používají významné tuzemské společnosti. A podle nezávislého testu na serveru Root je jedním z nejvýkonnějších frameworků vůbec. (8) Nette Framework je šířen jako svobodný software a může ho tedy používat naprosto kdokoliv. Uživatelé ho mohou svobodně spouštět, kopírovat, distribuovat a libovolně měnit. Své úpravy, opravy a vylepšení pak mohou veřejně publikovat a předávat ostatním. Není nijak zpoplatněn a není nikde třeba žádat o svolení k jakékoliv z výše zmíněných operací. Aby toto vše bylo možné, musí být přístupný zdrojový kód frameworku. Proto je Nette jako každý svobodný software automaticky podmnožinou skupiny Open source. Další výhodou svobodného softwaru je minimální riziko závislosti uživatele na používaném softwaru. Pokud tvůrce přestane software dále vyvíjet, může to po něm převzít někdo jiný. V případě právě Nette frameworku to je ve světle nedávných událostí důležitější než kdy jindy. Hlavní vývojář David Grudl začátkem toho roku oznámil, že se již nadále nebude na vývoji podílet. Má se to tak, že už pro mě nebyla radost současným způsobem dál Nette vyvíjet. Framework hodně roste, ale většinu stále programuji sám. A trend neukazoval, že by se to mělo zlepšit, právě naopak. Za rok 2012 podle statistik můj podíl na kódu Nette krásně klesl pod 90 %. Jenže v loňském roce (2013) se to vrátilo na nějakých 95 %. (9)

4 Framework Nette

4.1

14

Struktura projektu na Nette

Framework Nette poskytuje Sandbox, který lze stáhnout z oficiálních stránek a použít jako základní stavební kámen nového projektu.

Obrázek č. 2 – architektura Sandboxu (Zdroj: 10)

Jediný adresář www by měl být přístupný z webu, aby nikdo nemohl prohlížet kód aplikace. Je tedy dobré ho nastavit jako kořenový adresář. Sem také patří všechny veřejné soubory jako obrázky, CSS styly a JavaScript soubory. Nachází se tu také soubor index.php, přes který prohlížeč posílá všechny své požadavky. Kódu v tomto souboru moc není, pouze se zde do lokální proměnné uloží systémový DI kontejner, který nám vrací soubor bootstrap.php a následně se spustí celá aplikace.

Obrázek č. 3 – obsah souboru index.php (Zdroj: 11)

Hlavní jádro aplikace se však nachází ve složce app, která obsahuje konfigurační soubory, presentery, modely a šablony. Také je zde umístěn soubor bootstrap.php, který slouží k načtení celého frameworku a obsahuje základní nastavení aplikace.

4 Framework Nette

15

Obrázek č. 4 – ukázka konfiguračního souboru bootstrap.php (Zdroj: autor)

Zde se provádí spuštění autoloadu, nastavuje se zde debugger, logy, DI kontejner, cache a konfigurační soubor config.neon.

4.2

Dependency Injection a DI kontejner

Podstatou Dependency Injection (DI) je odebrat třídám zodpovědnost za získávání objektů, které potřebují ke své činnosti (tzv. služeb) a místo toho jim služby předávat při vytváření. [12] Obecně v objektovém programování je Dependency Injection technika pro vkládání závislostí mezi jednotlivými komponentami programu bez nutnosti uchování reference v době sestavování programu. V Nette by se celé tajemství Dependecy Injection dalo shrnout do jedné věty: „nic nesháněj, ať se postará někdo jiný“. To ve výsledku znamená, že pokud někde potřebujeme využívat cizí objekt, necháme si ho předat v konstruktoru. Jednoduše delegujeme starost o shánění tohoto objektu o úroveň výš. Takovýmto způsobem delegace však nejde pokračovat do nekonečna. Proto existuje DI kontejner, který slouží jako vrchní stvořitel a požadované objekty nám vytváří. Přesněji řečeno DI kontejner obsahuje libovolné množství továrniček, každou pro jiný objekt.

4 Framework Nette

16

Obrázek č. 5 – Příklad DI kontejneru (Zdroj: 12)

Vzhledem k tomu, že se jedná dost o rutinní záležitost, přináší Nette ideální řešení jak si toto nudné psaní kódu odpustit. DI kontejner si lze totiž nechat vygenerovat automaticky. Stačí pouze do konfiguračního souboru config.neon uvést všechny služby, pro které chceme vytvořit továrničku.

4.3

Auto-loading tříd

Pokud bychom nepoužívali framework, museli bychom si vždy ručně zajistit načítání všech potřebných souborů pomocí příkazu require. Jednak je to dost unavující způsob a hlavně se mohou načítat i soubory, které zrovna v danou chvíli není potřeba vůbec zpracovávat.

4 Framework Nette

17

Framework Nette má pro tento problém elegantní a velmi užitečné řešení. Je jím nástroj RobotLoader, který zajistí automatické načítání tříd pro celou aplikaci včetně jakýchkoliv knihoven třetích stran. Funguje na podobném principu jako vyhledávací roboti, kteří si indexují webové stránky. Prochází všechny PHP skripty a hledá v nich třídy a rozhraní, které si následně ukládá do cache. Stačí pak jen nakonfigurovat jaké adresáře prohledávat a kam ukládat výsledky hledání. Standardně je RobotLoader nastaven tak, že při dotazu na neexistující třídu nespouští nové prohledávání skriptů. Tato vlastnost lze ve vývojovém prostředí samozřejmě změnit, ale na produkčním serveru je doporučené ponechat výchozí nastavení a při nahrávání nových verzí aplikace jednoduše promazat cache. Tak se automaticky provede nové prohledání skriptů a uloží se aktuální stav. Pokud bychom chtěli některé adresáře vynechat z prohledávání, přidáme do nich soubor netterobots.txt a nastavíme v něm „Disallow: /názevAdresáře“.

4.4

Debugování a zpracování chyb

Protože jazyk PHP svou volností poskytuje velký prostor pro vytváření těžko odhalitelných chyb, může být občas jejich hledání velice nepříjemné a zdlouhavé. Aby debugování nevytvářelo tolik vrásčitých programátorů, přináší Nette špičkový diagnostický nástroj, který má již zdomácnělý název Laděnka (Tracy). Ten lze opět zapnout a nastavit v konfiguračním souboru bootstrap.php. Pokud je aplikace již vystavená pro veřejnost, je důležité Laděnku přepnout do produkčního módu, kdy chyby pouze loguje do nastaveného adresáře a uživateli ukazuje pouze obecnou chybovou stránku. Kdyby Laděnka zůstala zapnuta i v plném provozu aplikace, představovala by bezpečnostní hrozbu, protože by při případné chybě zobrazila část kódu aplikace. První velkou výhodou, kterou Laděnka přináší, je Debugger Bar. Jedná se o panel, který se drží v pravém dolním rohu stránky. Dá se samozřejmě přesunout na libovolnou pozici a také si ji bude při znovunačtení stránky pamatovat. V základu přináší informace o velikosti stránky, době potřebné k jejímu načtení a přehled všech provedených dotazů na databázi. Debugger panel lze také libovolně rozšiřovat o různé doplňky, přesně podle potřeb daného vývojáře.

Obrázek č. 6 – Debugger Bar v Nette (Zdroj: 13)

4 Framework Nette

18

Při používání čistého PHP se případné chyby vypisují přímo do zdrojového kódu a zorientovat se v takovém výstupu nemusí být vždy úplně jednoduché.

Obrázek č. 7 – výpis chyby v čistém PHP (Zdroj: 13)

Pokud však používáme Laděnku, dočkáme se mnohem přívětivějšího výpisu. Ten nám nejen jasně ukáže, kde přesně se chyba vyskytla, ale také vysvětluje, o jakou chybu se vlastně jedná. Celá stránka je také živá a umožní nám se proklikat k dalším podrobnostem, které mohou lépe objasnit příčinu vzniklé chyby.

Obrázek č. 8 – výpis chyby za použití Laděnky (Zdroj: 13)

4 Framework Nette

4.5

19

Routování URL

Routování je obousměrné překládání mezi URL a akcí presenteru. Obousměrným myslíme možnost z URL odvodit akci presenteru, ale také obráceně, k akci vygenerovat odpovídající URL. (14) Když v naší aplikaci potřebujeme vytvořit odkaz, není nutné psát URL adresu natvrdo, ale pouze vybereme presenter a akci, kterou chceme volat, předáme případné parametry a framework nám URL vygeneruje sám. Požadovaný tvar URL pak určuje router. Ten lze nastavit tak, aby se adresy vytvářely v co možná nejlidštějším a lehce zapamatovatelném tvaru. Kromě toho že tím zpříjemníme život uživatelům, docílíme i lepších výsledků u vyhledávačů. Pro definici tvaru URL vytvoříme objekt Route, jehož prvním parametrem je maska cesty a druhým výchozí akce presenteru zapsaná jako řetězec nebo pole. Takovýchto Route lze nastavit více a budou se poté vyhodnocovat postupně od první po poslední. Jakmile maska vyhoví, použije se daná routa. Proto by se měly ty nejobecnější masky uvádět až úplně na samém konci.

4.6

Model-View-Presenter

Model-View-Presenter je návrhový vzor, který odděluje aplikační logiku od způsobu výpisu. Kromě značného zlepšení přehlednosti kódu to přináší i lehčí budoucí vývoj aplikace. Pokud se například renovuje vzhled, děje se tak jen na jednom místě a nemusí se manipulovat se způsobem získání a zpracování dat. Dalším přínosem je možnost samostatně testovat jednotlivé části. Model Model je místem, kde by se měl nacházet hlavní mozek aplikace. Obsahuje aplikační logiku a zabývá se prací s daty. Každá operace, kterou uživatel vykoná jako například přihlášení, přidání zboží do košíku nebo vyfiltrování produktů, by mělo být v modelu reprezentováno příslušnou metodou. Také je oddělen od zbytku aplikace a komunikuje výhradně s presenterem. View Tato vrstva se stará o finální vykreslení dat uživateli. K tomu je v Nette standardně využíván šablonovací systém Latte, který ale není nutností a může být případně libovolně nahrazen.

4 Framework Nette

20

Presenter Presenter, někdy také označován jako Controller, je propojovací vrstvou aplikace. Funguje jako takový most mezi Modelem a View. Zpracovává požadavky, dotazuje se Modelu a získaná data předává dál do View.

4.6.1

Životní cyklus presenteru

Každý požadavek na aplikaci se přes soubory index.php a bootstrap.php dostane k objektu $application. Tento objekt však HTTP požadavku nerozumí, proto požádá router, aby mu adresu přeložil. Tím získá informaci o tom, který presenter a akce má být použita. Pomocí služby presenterFactory vytvoří objekt třídy daného presenteru a zavolá zvolenou akci. Presenter požadavek vyhodnotí a podá výslednou odpověď. Tou může být HTML stránka, obrázek, JSON, dokument či pouhé přesměrování. V samotném presenteru se však nachází mnohem více typů akcí, které mohou být volány. Ty mají jasně určené pořadí, které respektuje takzvaný životní cyklus presenteru.

Obrázek č. 9 – Životní cyklus presenteru (Zdroj: 10)

4 Framework Nette

21

startup() Ihned po vytvoření presenteru se zavolá metoda startup(). Je to vhodné místo například pro kontrolu uživatelských oprávnění. Pokud si definujeme vlastní metodu startup(), musíme zavolat předka parent::startup(). action() Jedná se o obdobu metody render(), ale využívá se pro akce, které nic nevykreslují. Například přihlášení uživatele, vložení zboží do košíku nebo smazání položky. V takovém případě spíše provede své úkoly a následně přesměruje jinam. Jelikož se akce volá ještě před metodou render(), může se zde případně zvolit i jiná render() metoda. handle<Signal>() Zde se zpracovávají tzv. signály nebo subrequesty. Metoda handle<Signal>() je určena především pro komponenty nebo pro zpracování AJAXových požadavků. beforeRender() Tato metoda se provádí vždy před samotnou metodou render() a využívá se především k nastavení hodnot, které jsou společné pro více view. render() Na tomto místě by se měla získat data z modelu a předat šabloně k vykreslení. shutdown() Tato metoda se volá při ukončení životního cyklu presenteru.

4.6.2

Model a jeho použití v presenteru

Model je jednou ze tří samostatných vrstev v architektuře MVC, je složen z mnoha tříd, kde každá obstarává určitou část logiky aplikace. Pro různé presentery můžeme potřebovat vždy pouze některé třídy, které pokud jsou registrovány jako služby v DI kontejneru, jednoduše získáme pomocí Dependency Injection.

4 Framework Nette

22

Jak již bylo zmíněno presenter je obstaráván pomocí služby presenterFactory, která po jeho vytvoření kontroluje, jestli nevyžaduje nějaké služby od DI kontejneru. To lze do presenteru zapsat buďto pomocí anotace @inject nebo použitím metody inject().

Obrázek č. 10 – Vložení modelu do presenteru (Zdroj: autor)

4.6.3

View a šablonovací systém Latte

V MVC architektuře View představuje prezenční vrstvu, která by měla sloužit k vykreslení a naformátování dat. Ačkoliv je PHP původem šablonovací jazyk kombinování PHP a HTML v šabloně vypadá nepřehledně a zbytečně složitě. Z tohoto důvodu vznikají v PHP různé šablonovací systémy a jeden takový je právě součástí frameworku Nette. Jedná se o šablonovací systém Latte, který využívá dva druhy speciálních značek.  makra ve složených závorkách, například {foreach …}  n:makra, která se zapisují jako atributy přímo do elementů, například n:if=“…“ Tato makra slouží pro výpis proměnných, tvorbu odkazů, psaní cyklů nebo podmínek. Jedná se v podstatě o zápis prezenční logiky v šablonách. Pro běžné používání si lze vystačit s předefinovanými Latte makry, které jsou v rámci Nette k dispozici. Pokud bychom potřebovali nějaká vlastní makra, lze si je pomocí Latte API vytvořit. (15) V šablonách lze také využívat speciální funkce, které pomáhají přeformátovat data do požadovaného formátu. Jedná se o takzvané helpery. Díky nim pak můžeme například převést celý text do velkých písmen nebo ho zkrátit na určitý počet znaků. Latte zápis pak vše ještě zjednodušuje. Helpery se uvádějí za svislítkem, lze je zřetězit a aplikují se v pořadí od levého k pravému. Parametry se zadávají oddělené dvojtečkou nebo čárkou. (16)

4 Framework Nette

23

Obrázek č. 11 – Ukázka použití helperu pro zkrácení textu na 100 znaků (Zdroj: autor)

Důležitou vlastností každého dobrého šablonovacího systému je i automatické escapování proměnných. Tím se rozumí převedení znaků, které mají v HTML speciální význam na jiné odpovídající sekvence. Opomenutím tohoto ošetření by vznikla závažná bezpečnostní díra, která by mohla být zneužita například pomocí Cross Site Scripting (XSS)3. Latte jde v tomto směru ještě dál. Dokáže totiž rozeznat, v které části dokumentu se makro s výpisem proměnné nachází a následně zvolit ten správný způsob escapování. Ten se totiž například v HTML použije jiný než třeba v JavaScriptu.

4.7

Flash zprávy

Tyto zprávy jsou používány pro oznámení výsledku nějaké akce nebo stavu, ve kterém se aplikace právě nachází. Důležitou vlastností je to, že zůstávají v šabloně k dispozici i po přesměrování. Typickým příkladem je třeba odhlášení uživatele, kdy při odhlášení nastavíme zprávu a přesměrujeme na domovskou stránku, případně na stránku s přihlášením. Tam poté vypíšeme naši zprávu s informací, že odhlášení proběhlo v pořádku. Flash zprávy se nastavují právě v presenteru a to metodou flashMessage(). Prvním parametrem je text zprávy a druhým nepovinným parametrem je typ zprávy, který může rozlišovat informační, potvrzovací nebo chybové hlášky. Zprávy jsou poté presenterem automaticky předány šabloně v proměnné $flashes. O jednoduchý výpis se pak už lze v šabloně postarat velice snadno.

Obrázek č. 12 – Příklad výpisu flash zpráv v šabloně (Zdroj: autor)

3

Cross Site Scripting je metoda narušení webových stránek zneužívající neošetřených výstupů.

5 Návrh aplikace

24

5 Návrh aplikace 5.1

Funkční nároky na aplikaci

Aplikace by měla dostatečně pokrýt všechny stanovené požadavky z těchto tří hlavních části. Uživatelská sekce, hrací plán a vyhodnocování příkazů.

5.1.1

Uživatelská sekce

Uživatel by měl mít možnost registrace, při které si určí své jméno a heslo. Poté co se za použití zvolených údajů úspěšně přihlásí, uvidí přehled všech svých aktivních her a přehled her, které ještě nemají plný počet hráčů. Také bude mít možnost hry samostatně zakládat. Jeden hráč se bude moci současně účastnit libovolného množství her, ale v každé hře může být přihlášen pouze jednou. Jednotlivé hry se mohou nacházet ve třech základních stavech.  Nově založená hra, která čeká na zaplnění požadovaným množstvím hráčů.  Aktivní hra, která již byla spuštěna a stále probíhá její hraní.  Ukončená hra, která již byla dohrána. Informace o stavu hry a hráčích, kteří se jí účastní, musí být viditelné jak v uživatelské sekci v přehledu her tak i na samotném detailu hry.

5.1.2

Hrací plán

Spolu s informacemi o hráčích, aktuálním skóre a stavu hry se bude na detailu hry nacházet i hrací plán. Ten bude současně sloužit jako hrací deska, kde bude přehledně zobrazena mapa se všemi jednotkami a také pomocí něj bude možné zadávat rozkazy pro armády. Pro zobrazení jednotek bude použito dvou různých tvarů, aby bylo rozlišeno, zda se jedná o pěší armádu nebo o flotilu. Hráči své jednotky rozeznají podle barvy státu, který jim byl na začátku hry přiřazen. Rozkazy pro jednotky bude možné zadávat interaktivně za pomoci klikání na jednotlivá políčka na mapě. Po úspěšném zadání se rozkaz objeví v přehledu rozkazů pro dané kolo, odkud ho bude také možné smazat. Úpravy v rozkazech půjde provádět do chvíle, kdy hráč nastaví svůj stav na „Připraven“. Pro následující úpravy

5 Návrh aplikace

25

v rozkazech bude svůj stav muset znovu změnit na „Nepřipraven“. Kolo se ukončí a rozkazy předají k vyhodnocení až ve chvíli, kdy všichni hráči změní svůj stav na „Připraven“. Stav připravenosti jednotlivých hráčů bude také vyobrazen v horní části detailu hry. Herní plán by měl být navržen tak, aby umožňoval budoucí rozšíření o další herní varianty map. Pro základní verzi bude použito klasické mapy Evropy z roku 1901.

5.1.3

Vyhodnocování příkazů

Každou hru bude možno vyhodnotit nezávisle na ostatních. Na základě pravidel deskové hry Diplomacie bude vytvořen vyhodnocovací algoritmus. Ten také ošetří výskyt paradoxních situací, které vznikaly kvůli neúplnosti původních pravidel, kdy jedna situace mohla být vyřešena více různými způsoby. Této opravy by mělo být docíleno přidáním nových nebo úpravy stávajících pravidel.

5.2

UML diagram aktivit

Na tomto diagramu je vidět, jak se celý průběh hry odehrává v jednotlivých cyklech, které se stále dokola opakují, dokud některý z hráčů nezíská většinu zásobovacích center.

Diagram č. 2 – UML diagram průběhu hry (Zdroj: autor)

5 Návrh aplikace

26

Už z tohoto návrhu je patrné, že se hra bude nacházet v různých stavech, podle kterých budou omezeny typy rozkazů, které bude možno v danou chvíli zadávat. Herní stavy:  zadávání bitevních rozkazů,  zadávání ústupů,  tvorba a rozpouštění armád

5.3

UML konceptuální diagram

Na základě požadavků a pravidel hry Diplomacie, byl navržen tento základní diagram, který reprezentuje hlavní strukturu tříd a slouží jako předloha pro vytvoření potřebných tabulek v databázi.

Diagram č. 3 – UML diagram předpokládané struktury tříd (Zdroj: autor)

Středem veškerého dění je objekt Game, který obsahuje GamePlan a také veškeré zúčastněné hráče. Je důležité rozlišovat objekty User a Player. V prvním případě se jedná o registrovaného uživatele (User), který má své přihlašovací jméno a heslo. Když se takový uživatel přidá k nějaké hře, je mu k jeho účtu vytvořen objekt Player, který reprezentuje jeho účast v dané hře.

5 Návrh aplikace

27

Herní plán je pochopitelně složen z jednotlivých políček, na kterých se mohou případně nacházet armády. Další návrh reprezentuje třídy, které se týkají vyhodnocovacího algoritmu. Každá armáda dostává před bitvou jeden z šesti možných rozkazů a ty se primárně týkají jednoho bitevního políčka. Jakákoliv armáda se může také během procesu vyhodnocování ocitnout pod útokem a tím získá ještě ke svému původnímu rozkazu novou roli obránce políčka, na kterém se právě nachází.

Diagram 4 – UML diagram struktury tříd bitevního algoritmu (Zdroj: autor)

5 Návrh aplikace

5.4

28

Návrh GUI

Samotná aplikace si v podstatě vystačí pouze s přihlašovací obrazovkou, registračním formulářem, přehledem her a hracím plánem. Registrace a přihlášení lze obsloužit pouze jednoduchým formulářem, který nevyžaduje složitější návrh. Pro přehled her a hrací plán je už vhodné vytvořit wireframe, který slouží jako předloha pro grafické zpracování a kódování výsledné stránky.

5.4.1

Přehled her

Na přehled her je uživatel přesměrován ihned po přihlášení. Nachází se zde seznam všech volných her, do kterých se může uživatel přihlásit a přehled těch, kterých se již účastní. U každé z her je uvedeno datum založení, název, přihlášení hráči, stav hry a rok (v diplomacii se počítají jedno celé kolo jako rok). Každý hráč může také založit libovolné množství nových her. K tomu slouží formulář ve spodní části této obrazovky.

Obrázek č. 13 – Návrh obrazovky „Přehled her“ (Zdroj: autor)

5.4.2

Návrh hracího plánu

Pokud má hra již dostatečný počet hráčů a byla tedy zahájena, lze se dostat na stránku s jejím hracím plánem. Jedná se o nejdůležitější obrazovku celé aplikace, protože zde vlastně probíhá celá hra. Hlavní částí je bezpochyby interaktivní herní mapa, které zobrazuje rozložení jednotek a zároveň slouží jako nástroj pro zadávání všech rozkazů. Způsob implementace této mapy je rozebrán v následující kapitole, která je věnována finální tvorbě

5 Návrh aplikace

29

celé aplikace. V návrhu stačí vědět, že políčka budou na mapě označena zkratkami svých názvů a barevně zvýrazněna podle příslušnosti k dané velmoci. Stejnými barvami budou rozlišeny i armády. Kromě mapy se zde zobrazují také všechny podstatné informace, které bylo možné vidět i v přehledu her. Navíc je tu tabulka aktuálních rozkazů a také přehled těch, které byly již vyhodnoceny minulé kolo.

Obrázek č. 14 – Návrh obrazovky „Herní plán“ (Zdroj: autor)

6 Implementace aplikace

30

6 Implementace aplikace 6.1

Uživatelské rozhraní

Hru, tak jak je navržena, mohou hrát pouze registrovaní uživatelé. Proto se každý hráč musí nejdříve zaregistrovat a až po přihlášení mu bude zpřístupněn zbytek webové aplikace s přehledem her. Pro registraci si stačí zvolit jedinečné uživatelské jméno a libovolné heslo. Formulář a zpracování registrace obsluhuje RegistrationPresenter. Ten s pomocí modelu UserRepository vyhodnotí unikátnost uživatelského jména a při úspěšném průchodu následně uloží do databáze. Hesla jsou do databáze ukládána v již zašifrované podobě, aby nemohlo dojít k jejich zneužití. Pro následné přihlášení slouží SignPresenter, který opět obsahuje tvorbu formuláře pro zadávání uživatelského jména a hesla a zároveň se stará o vyvolání autentizace uživatelů. Ta se provádí pomocí služby user, kterou v presenteru získáme voláním $user = $this->getUser(). Poté je využita třída Authenticator, která respektuje rozhraní IAuthenticator. Pro jeho implementaci je zapotřebí pouze jediné metody authenticate(), která se stará, jak už název napovídá, právě o autentizaci uživatelů. Na základě zadaného jména je z databáze vybrán příslušný uživatel a přistoupí se k porovnání hesla. Pokud se vše shoduje, je vytvořen objekt s identitou uživatele, který bude uložen do cookies. V opačném případě je vyhozena výjimka s popisem důvodu neúspěšného přihlášení. Kromě tradičního použití metody logout() lze nastavit i časový interval, po kterém dojde k automatickému odhlášení uživatele. K tomuto nastavení slouží metoda setExpiration(), volaná při přihlášení. Jako parametr lze uvést relativní čas v sekundách, UNIX timestamp nebo textový zápis. Druhý parametr stanoví, zda se má uživatel odhlásit při zavření prohlížeče.

Obrázek č. 15 – Příklad nastavení expirace přihlášení (Zdroj: 17)


6.2

31

Herní plán

Jedním z požadavků na aplikaci bylo vyřešit flexibilní způsob, kterým by šla hra v budoucnu rozšířit o různé nové verze herních plánů, které umožní jiné rozložení a pojmenování políček. Hrát tak půjde například na půdě Ameriky, Afriky či na úplně imaginárním světadíle. Herní plán musí obsluhovat tři základní věci. Za prvé musí být schopen správně vykreslit mapu a obstarat vykreslování všech armád na správných pozicích. Za druhé musí správně vygenerovat strukturu políček, nadefinovat jim příslušné vlastnosti a uložit je do databáze. A nakonec musí umožnit intuitivní zadávání příkazů pomocí klikání myší na políčka mapy. Všechny základní informace, které popisují příslušný herní plán, budou uloženy v souboru XML. Z toho se poté na začátku hry vygenerují databázové záznamy pro políčka a také se bude používat pro vykreslování mapy a při vyhodnocení rozkazů.

6.2.1

Řešení grafického vykreslení políček a armád

Varianta A – Mapa v jednom obrázku Takové řešení by spočívalo v použití jednoho obrázku pro celou mapu. Armády by se pak absolutně umístily na souřadnice daného políčka. Problém by byl s interaktivním zadáváním rozkazů pro jednotlivé armády. Na které políčko zrovna máme najeto myší, by muselo být zjišťováno pomocí výpočtu mezi souřadnicemi myši a vektory políček. Také by nešlo docílit nějakého dodatečného zvýraznění aktivního políčka, protože v HTML kódu bychom neměli žádné elementy reprezentující takové pole. Pouze bychom znali souřadnice jeho vektoru. Varianta B – Mapa složená z obrázků pro každé pole Toto řešení by nám umožnilo lépe zvýraznit aktivní pole, protože by již každé mělo vlastní obrázek. Na druhou stranu by to vedlo k velkému množství obrázků, které bychom museli absolutně umístit vedle sebe. Varianta C – Mapa z vektorových SVG elementů v HTML5 Poslední varianta využívá možností HTML5, které dovolují vytvořit SVG obrázek, poskládaný z různých vektorových elementů. Díky tomu můžeme vytvořit jednotlivá políčka jako SVG elementy a to bez žádných obrázků.


32

Jako nejvhodnější byla zvolena varianta C, protože umožňuje využít strukturu již vytvořené mapy ve formátu SVG a uložit ji do XML souboru. Tam se k jednotlivým elementům připojí herní informace o políčku (ID, název, zkratka, typ, seznam sousedních polí).

Obrázek č. 16 – Ukázka jednoho záznamu pole v XML souboru (Zdroj: autor)

Podle tohoto XML souboru je hra v samém začátku inicializována. Díky použití PHP funkce simplexml_load_file() lze jednoduše načíst celý XML soubor a následně jej uložit do proměnné. Pak již můžeme jednoduše procházet jednotlivá políčka cyklem. Z XML souboru také získáme informace o velmocích a základním rozložením armád. Všechny tyto informace uložíme do databáze, přepneme stav hry na aktivní a může se začít hrát. XML je parsováno také pokaždé, kdy potřebujeme herní plán. Tento proces se odehrává v třídě GamePlan po zavolání metody generateGamePlanFromXml($path). V proměnné path je uvedena výchozí cesta ke klasické verzi mapy. Ta může být samozřejmě nahrazena v případě vytvoření nového XML souboru. Každé pole v plánu je pak reprezentováno instancí třídy Field. Ta jednak uchovává informace o políčku, ale také zajišťuje správné vytvoření HTML elementu, který bude pole reprezentovat na mapě. V tomto ohledu je velmi užitečná pomocná třída Html, kterou obsahuje Nette framework. Přes statické volání funkce el() lze vytvářet libovolné HTML elementy, nastavovat jim různé atributy a následně je do sebe vnořovat. Toho je právě využito v metodě getElement() třídy Field, která vygeneruje a vrátí právě element políčka na mapě. Tomu se na základě uchovaných vlastností nastaví správný popisek a vybere barva dané velmoci.

6.2.2

Zadávání rozkazů

K zajištění tohoto požadavku na herní plán je použito javascriptové knihovny jQuery, která má širokou podporu prohlížečů a nabízí funkce pro procházení a změnu DOM, AJAX nebo manipulaci s CSS. Všechny tyto vlastnosti jsou klíčové pro vytvoření systému zadávání rozkazů. (18)


33

V první řadě je zajištěno, že po kliknutí na vlastní armádu zobrazíme blok s výběrem možných rozkazů. Následně je odeslán AJAXem požadavek na odpovídající akci v presenteru. Ta podle typu rozkazu vyhodnotí další postup. Pokud nejde zrovna o rozkaz k obraně, který nevyžaduje uvedení dalších polí, vrátí akce soubor ve formátu JSON, který obsahuje všechna validní pole pro daný rozkaz. Tato pole jsou poté pomocí javascriptu zvýrazněna na mapě a jsou aktivní pro další výběr. Tímto způsobem je poskládán celý rozkaz, který následně uložíme do databáze. Výběr validních políček pro dané rozkazy se řídí pravidly hry Diplomacie. V případě základních rozkazů jako je útok a podpora v obraně se jedná vždy o sousední políčka kolem armády, pro kterou je rozkaz zadáván. Každé pole umí vracet svá sousední pole, která se ale různí podle typu armády. Například pěší jednotky se nemohou přesouvat do moře a naopak flotily nesmí pronikat do vnitrozemí. U rozkazu k podpoře v útoku již musíme zadávat o pole navíc, abychom jasně specifikovali, jaký útok podporujeme. Proto se zde nejdříve musí vyhledat všechny armády, které s tou naší sdílejí stejné sousedy a které bychom mohli podpořit v útoku na tato společná pole. Z pohledu algoritmizace je nejsložitější rozkaz ke konvoji jednotek přes moře a to především proto, že se jedná o jediný rozkaz, který umožňuje provést přesun o více než jedno pole. Není tedy předem jasně definováno, kolik polí budeme muset kontrolovat. Z tohoto důvodu bylo nutné vytvořit rekurzivní funkci4 findConvoyChains(), která bude schopna vyhledat všechny dostupné trasy mezi vodou oddělenými políčky. Vždy musí jít o řetěz sousedních políček se začátkem a koncem na pevnině. Políčka se samozřejmě nesmí opakovat, jinak by docházelo ke smyčkám. Postup této funkce lze popsat takto: 1. Jako první parametr se vloží pole se všemi základními řetězy. Ty jsou reprezentovány také polem, kde jako první prvek je uloženo právě ID startovního políčka a druhým prvkem je ID prvního mořského pole s flotilou. 2. Dalšími parametry jsou všechny flotily na moři a instance herního plánu. 3. Při každém průchodu funkce se prochází všechny řetězy a testuje se vždy poslední prvek pole v aktuálním řetězu. a. Nejdříve se otestuje, jestli se poslední políčko již nenachází na pobřeží a nejedná se tedy o úspěšně ukončený řetěz.

4

Rekurzivní funkce je taková funkce, jež ve své definici volá sama sebe.


34

b. Pokud je poslední pole na moři, je možné, že se řetěz bude dále větvit. V každém případě bude na konci procesu smazán, protože není ukončený. Uloží se jen jeho případné rozšířené verze. Dále se ověří přítomnost flotily a začnou se procházet sousední pole. Nejdříve se otestuje, jestli se již dané sousední pole v řetězu nenachází, abychom se vyhnuli nekonečným smyčkám. Pokud je sousední pole nové a jedná se o pobřeží nebo o moře s flotilou, je vytvořena kopie původního řetězu, do které je toto pole přidáno. 4. Tento proces se opakuje tak dlouho, dokud jsou vytvářeny nové kopie řetězů. Pokud během průchodu funkce není vytvořena žádná nová kopie, znamená to, že jsou již všechny řetězy úspěšně ukončeny a mohou být vráceny. Výsledkem může být samozřejmě i prázdné pole, pokud se odhalí, že není možné provádět žádné konvoje.

6.3

Vyhodnocení rozkazů

Nejrozsáhlejší a také nejdůležitější částí celé aplikace je samotné vyhodnocování rozkazů. Jejich typ a způsob zpracování se liší podle stavu, ve kterém se hra v danou chvíli nachází. Tyto stavy jsou podle návrhu tři, ale v rámci jednoho celého kola může hra změnit stav až pětkrát. To je způsobeno tím, že vyhodnocení bitev a ústupů jednotek probíhá jak v jarní, tak i v podzimní fázi hry. Oproti tomu přerozdělení získaných území a následná výstavba jednotek se odehrává pouze jednou, a to na konci podzimu.

6.3.1

Vyhodnocení bitevních rozkazů

Každou hru reprezentuje instance třídy Game. Ta si vždy nejprve pomocí metody loadGame() načte potřebná data z databáze, naplní seznam hráčů a aktualizuje svůj herní plán. Poté na ní lze zavolat metodu executeOrders(), která se stará právě o celkové vyhodnocení bitevních rozkazů. Protože se jedná o nejkomplikovanější metodu v celé aplikaci, je rozdělena na více menších částí, které jsou následně blíže popsány. Představeny jsou tedy všechny použité třídy, zdůvodněna úprava pravidel a na konec je rozebrán i postup celé metody executeOrders().


35

Použité třídy Pro jednotlivé typy bitevních rozkazů jsou vytvořeny vlastní třídy, jejichž objekty se generují na začátku metody executeOrders() podle záznamů uložených v databázi. Každý typ je vyhodnocován trochu jinak. Attacker Spolu s rozkazem k útoku přes konvoj jde o jediný rozkaz, který se primárně nebrání a nemůže přijímat podpory v obraně. Naopak si ukládá případné podpory v útoku. Třída Attacker obsahuje tyto metody.  addAttackSupport() – Přidá objekt třídy AttackSupport, který reprezentuje podporu v útoku.  getAttackPower() – Vrací sílu útoku spočítanou podle aktivních podpor.  isAttackSupportSolved() – Vrací TRUE/FALSE podle toho, jestli jsou už všechny přislíbené podpory vyřešeny a platné. Defender Tento rozkaz se zvolí pro všechny armády, které neutočí nebo nemají žádný rozkaz nastavený. I armáda, která sama poskytuje jakoukoliv podporu, může být sama podporována v obraně. Proto je objekt této třídy vytvářen i pro armády s rozkazem k podpoře. Metody této třídy jsou obdobné jako u třídy Attacker.  addDefensiveSupport() – Přidá objekt třídy DefensiveSupport, který reprezentuje podporu v obraně.  disableSupport() – Ruší efekt podpory v obraně.  getDefensivePower() – Vrací sílu obrany spočítanou podle aktivních podpor. DefensiveSupport Jedná se o jednoduchý objekt, který reprezentuje podporu v obraně. Obsahuje pouze vazbu na svou armádu a cílové políčko, které má za úkol podporovat. Poté už si jen drží informaci o tom, jestli je aktivní. Podpora v obraně totiž může být zrušena jakýmkoliv útokem, kromě útoku pomocí konvoje (viz. přidané pravidlo o konvojích). AttackSupport Podpora v útoku je o trošku složitější varianta třídy DefensiveSupport. Také má vazbu na svou armádu a na políčko, které má podporovat v útoku. K tomu si ale také pamatuje cílové pole útoku, aby bylo možné ověřit, že byla podpora zapsána správně. Protože je proces rušení podpor v útoku o něco složitější než v případě podpory v obraně, musí si také


36

držet informaci o tom, jestli již byla tato podpora definitivně vyřešena a může být použita k výpočtu síly útoku, který podporuje. ConvoyAttack Jde o speciální druh útoku pěších jednotek přes moře, který může být vyhodnocen pouze v případě, že je podpořen dostatečným počtem flotil umožňujících tento přesun. Třída ConvoyAttack obsahuje tyto metody.  addConvoySupport() – Přidá objekt třídy ConvoySupport, který reprezentuje flotily umožňující tento konvoj.  findConvoyChains() – Rekurzivní funkce pro nalezení možných cest konvoje, poskládaných ze zadaných objektů ConvoySupport.  execute() – Vyhodnotí, jestli byla nalezena nějaká cesta pro konvoj a je možné provést útok přes moře. ConvoySupport Tento rozkaz slouží k poskytnutí flotily pro přesun pěší armády přes moře. Opět si pamatuje jak vazbu na svou armádu, tak startovní a cílové pole pro konvoj, který umožňuje. Flotila je použitelná pouze v případě, že si ubrání svou pozici. Pokud by byla nepřátelským útokem donucena k ústupu, nelze s ní počítat při tvorbě řetězu pro konvoj. Battlefield Battlefield je třída, která reprezentuje místo střetu armád a slouží k vyhodnocování soubojů jednotek. Na začátku metody executeOrders() je pro každé políčko z herního plánu vytvořen jeden objekt této třídy. Kromě objektu Field, který je Battlefieldu předán už v konstruktoru může být nastaven jeden obránce a libovolné množství útočníku, kteří se snaží toto pole obsadit. Obráncem může být pouze objekt třídy Defender a pole útočníků je zase složeno z objektů třídy Attacker. Stejně jako samotná třída Game má svou metodu executeOrders() pro vyhodnocení rozkazů, má i třída Battlefield svou metodu execute(), která vyhodnocuje výsledek bojů na tomto poli. Úprava pravidel Na základě stanovených kritérií se proces vyhodnocení bitev řídí původními pravidly deskové hry Diplomacie. Nicméně jedním z požadavků bylo také ošetření nekonzistence právě těchto pravidel, podle kterých bylo možné docílit paradoxu při vyhodnocování konvojů. Přesun pomocí konvoje je jediným z rozkazů, jehož uskutečnění je podmíněno výsledkem jiných bojů. Pokud je totiž konvoj úspěšně proveden, může svým útokem ovlivnit výsledek bojů o pole, na kterém se nacházela flotila, která tento konvoj pomohla uskutečnit. Tím se


37

teoreticky může vyskytnout situace, kdy si vlastně konvoj sám sobě ruší šanci na uskutečnění. To poté vede k vzniku paradoxu a nejasného výkladu pravidel. Pro jednodušší pochopení problému je uveden příklad reálné situace. Francouzská jednotka v Brestu útočí pomocí konvoje v průlivu La Manche(The English Channel) na Londýn. Zároveň na francouzskou flotilu vede útok anglická flotila z Walesu a německá z Belgie. Oba tyto útoky jsou podporovány jednou jednotkou, takže výsledná síla útoků 2:2 vede k remíze a francouzská flotila není nucena ustoupit. Tím je tedy umožněno úspěšně provézt francouzský útok na Londýn. Tento útok je podporován další francouzskou jednotkou z Yorkshire a silou 2:1 poráží obranu v Londýně. Poražená anglická flotila, již ale nemůže poskytovat podporu pro předešlý konflikt v průlivu La Manche, čímž se změní rozložení sil na 2:1 pro Německo. Protože je již jasný vítěz, francouzská flotila musí ustoupit a není dále schopna poskytovat konvoj do Londýna. Kvůli tomu nemůže být přerušena podpora poskytována z Londýna a takhle stále dokola.

Obrázek č. 17 – Příklad paradoxní situace při útoku pomocí konvoje (Zdroj: 19)

Originální pravidla jsou v tomto ohledu nedostačující. Proto bylo přijato nové pravidlo, které ustanovuje, že žádný útok vedený pomocí konvoje, nemůže přerušit poskytované podpory. Na základě této změny lze konvojem přesouvané jednotky vyhodnotit jako poslední, protože již nemohou ovlivnit výsledky ostatních bitev.


38

Postup funkce executeOrders() Protože se tato metoda skládá z necelého tisíce řádků kódu, nebude zde rozebírána každá její podmínka, ale spíše zachycen logický proces, který vede k úspěšnému vyhodnocení všech rozkazů. 1. Vygenerování objektů Battlefield pro každé políčko herního plánu. 2. Načtení rozkazů z databáze. 3. Vytvoření objektů Attacker a Defender, které se připojují přímo k Battlefieldu. 4. Vytvoření objektů AttackSupport a DefensiveSupport a jejich připojení k daným objektům Attacker a Defender. 5. Uložení všech flotil s rozkazem ke konvoji do objektů ConvoySupport. 6. Zrušení obraných podpor od armád, které jsou sami pod útokem. 7. Pro rušení podpor v útoku jsou ještě doplňující podmínky, které nedovolují, aby napadená armáda rušila svým útokem podporu v útoku na sebe samotnou. a. Pokud na armádu poskytující podporu v útoku nevede žádný útok, označíme ji jako vyřešenou a aktivní. b. Pokud na armádu poskytující podporu v útoku vede nějaký útok, ověříme, jestli je tento útok veden z pole, na které směřuje útok námi podporovaný. i. Pokud ano, musel by tento útok donutit armádu, která poskytuje podporu, k ústupu. Ověří se tedy, jestli je už na tomto poli souboj vyřešen. 1. Pokud ano, podle výsledku bitvy podporu nastavíme na aktivní nebo neaktivní. V obou případech je již vyřešena. 2. Pokud boj o toto pole ještě nebyl rozhodnut, musí se podpora nechat nevyřešená a bude čekat na další průchod celého vyhodnocovacího procesu. ii. Pokud je veden z jiného pole, můžeme podporu označit jako vyřešenou, ale neaktivní. 8. Po průchodu podpor jsou procházeny samotné útoky. a. Pokud mají všichni účastníci boje o dané políčko vyřešené podpory, spočítá se síla obrany a všech útoků. Obránce vyhrává v případě stejné nebo větší bojové síly než útočník. Také může vyhrát, když se o pole střetne víc útočníků se stejnou silou. V takovém případě není obranná síla podstatná.


39

b. V případě nevyřešených podpor je pole označeno jako nevyřešené a bude čekat na další průchod vyhodnocení. 9. Pokud dosud nebyly vyřešeny všechny útoky, vracíme se zpět k bodu číslo 7. 10. Po vyřešení všech útoků zjistíme, které z konvojů lze uskutečnit. 11. Následně vše nastavíme do počátečních stavů, zopakujeme body číslo 3 a 4 a přidáme do útoků i úspěšné konvoje. 12. Přeskočí se bod číslo 5, protože konvoje jsme již vyřešili a zopakujeme vyhodnocovací proces od bodu číslo 6. Po vyhodnocení všech útoků již máme vše vyřešené a můžeme pokročit k zaznamenání armád, které byly donuceny k ústupu. 13. Pro každou armádu na ústupu jsou získány sousední volné pozice, na které je možné ustoupit. Ty jsou uloženy do databáze a v další fázi tahu nabídnuty hráči pro zvolení ústupu. 14. Nakonec se už jen uloží nové pozice armád, které se úspěšně přesunuly.

6.3.2

Vyhodnocení ústupů

Tato fáze tahu nastává pouze v případě, že byly nějaké jednotky donuceny k ústupu, jinak je vynechána. Z databáze jsou hráčům nabídnuty možnosti ústupů, které tam byly uloženy ve fázi vyhodnocování výsledků bojů. Poté se již jen kontroluje, jestli nějaké dvě armády neustupují na stejné pole. Pokud ano, jsou obě zrušeny. Rozpuštěné jsou taky všechny armády, které nedostaly rozkaz, kam mají ustoupit.

6.3.3

Vyhodnocení obsazených území a stavba jednotek

Na konci podzimní části tahu jsou také vyhodnocena zabraná území. V tuto chvíli se také kontroluje, jestli je již nějaký vítěz, který vlastní většinu zásobovacích polí. Pokud ne, jsou hráčům spočítány všechny jednotky a zásobovací centra. 1. Více armád než zásobovacích center – Hráči je nabídnut seznam jeho armád, ze kterého musí vybrat armády pro zrušení, jinak jsou vybrány náhodně. 2. Více zásobovacích center než armád – Hráči je nabídnut seznam polí volných k výstavbě. Poté může, ale nemusí zadat rozkaz ke stavbě jednotek. 3. Zásobovacích center je stejné množství jako armád – Hráč v tomto tahu nic nedělá.

7 Závěr

40

7 Závěr V samotném začátku práce byla představena desková hra Diplomacie, která sloužila jako předloha pro výslednou aplikaci. Také zde byla stanovena kritéria, která musí být splněna, aby mohla být aplikace považována za plně funkční. Teoretická část dále pokračovala v obecném popisu frameworku a objasnění důvodů jeho využívání. Následně byl představen konkrétně český framework Nette a popsána struktura projektu, postaveném na jeho základě. Byly také zmíněny hlavní výhody, které použití frameworku Nette přináší. Dále navazovala praktická část práce, která začínala samotným návrhem celé aplikace. Byly zde vypracovány konceptuální diagramy, diagram aktivit a wireframy pro grafický návrh aplikace. Během následné implementace se ukázaly výhody, které přináší využití Nette frameworku. Zejména při řešení registrace a autentizace uživatelů, kde se nemusí začínat od nuly a je zde již většina podstatných věcí vyřešena. Také se velice osvědčil debugovací nástroj Laděnka, který je podle mého názoru jednou z nejlepších vymožeností frameworku Nette.

7.1

Shrnutí cílů

Hlavním cílem této práce bylo vytvoření plně funkční webové aplikace, která je založena na strategické deskové hře Diplomacie. Ta byla v úvodu důkladně popsána a následně úspěšně vytvořena. V kapitolách 5 a 6 je popsán celý návrh a vývoj, což může také posloužit jako pomůcka pro každého, kdo by plánoval převedení podobného typu deskové hry do webové podoby. Aplikace je v současné době již umístěna na webové adrese diplomacie.pripravujeme.eu a je přístupná široké veřejnosti. To by také mohlo vést k větší popularitě této hry, která nebyla doposud dostupná v české webové variantě. Kromě hlavního cíle byl také splněn cíl vedlejší, kterým bylo poskytnutí teoretických základů k používání českého frameworku Nette. V tomto směru může přispět i výsledná webová aplikace, která se dá využít jako pomocný materiál pro studenty, kteří se chtějí seznámit s právě tímto frameworkem a nemají dostatek praktických příkladů. Proto jsou také veškeré kódy celé aplikace dostupné na přiloženém CD.

7 Závěr

41

Seznam zdrojů [1] Diplomacy (game). In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-03-30]. Dostupné z: http://en.wikipedia.org/wiki/Diplomacy_(game) [2] Dipwiki [online]. 2008 [cit. 2014-05-08]. Dostupné z: http://www.dipwiki.com/ [3] LECKY-THOMPSON, Ed a Steven D NOWICKI. PHP 6: programujeme profesionálně. Vyd. 1. Brno: Computer Press, 2010 ISBN 978-80-251-3127-5. [4] BÖHMER, Marian. Návrhové vzory v PHP. 1. vyd. V Brně: Computer Press, 2012, 320 s. ISBN 978-80-251-3338-5. [5] Framework. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-03-07]. Dostupné z: http://cs.wikipedia.org/wiki/Framework [6] Objektově relační mapování. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-03-08]. Dostupné z: http://cs.wikipedia.org/wiki/Objektov%C4%9B_rela%C4%8Dn%C3%AD_mapov%C 3%A1n%C3%AD [7] ORM frameworky pro PHP5: Obecný úvod. In: Zdrojak.cz [online]. 2010 [cit. 201405-07]. Dostupné z: http://www.zdrojak.cz/clanky/orm-frameworky-pro-php5-obecnyuvod/ [8] GRUDL, David. Začínáme s Nette Framework: Nette Framework: zvyšte svoji produktivitu. In: Zdrojak.cz [online]. 2009 [cit. 2014-03-09]. Dostupné z: http://www.zdrojak.cz/clanky/nette-framework-zvyste-svoji-produktivitu/ [9] HASSMAN, Martin. David Grudl: Nette Framework čeká zlomový rok. In: Zdrojak.cz [online]. 2014 [cit. 2014-03-17]. Dostupné z: http://www.zdrojak.cz/clanky/davidgrudl-nette-ceka-zlomovy-rok/ [10] Začínáme. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/quickstart/getting-started [11] MVC aplikace & presentery. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/presenters [12] Dependency Injection. Nette [online]. 2014 [cit. 2014-04-21]. Dostupné z: http://doc.nette.org/cs/2.1/dependency-injection [13] Debugování a zpracování chyb. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/debugging [14] Routování URL. Nette [online]. 2014 [cit. 2014-04-17]. Dostupné z: http://doc.nette.org/cs/2.1/routing [15] Výchozí Latte makra. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/default-macros [16] Helpery. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/templating#toc-helpery

7 Závěr

42

[17] Přihlašování & oprávnění uživatelů. Nette [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://doc.nette.org/cs/2.1/access-control [18] Browser support. JQuery [online]. 2014 [cit. 2014-05-08]. Dostupné z: http://jquery.com/browser-support/ [19] SZYKMAN, Simon a Manus HAND. Eliminating the Paradox in Diplomacy. Diplom [online]. 1999 [cit. 2014-05-08]. Dostupné z: http://www.diplom.org/Zine/F1999R/Debate/paradox.html

Tvorba webové aplikace za využití frameworku Nette

Recommend Documents