Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Diplomová práce Webová aplikace - interaktivní katalog restaurací s pokročilým vyhledáváním Bc. Tomáš Záruba Vedoucí práce: Ing. Jiří Novák 3. ledna 2013

4

5 Poděkování Děkuji všem, kteří mě podporovali při psaní této práce. Rád bych poděkoval především Ing. Jiřímu Novákovi, který mě vedl ke zdárnému dokončení této práce

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 3. ledna

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Tomáš Záruba. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Záruba, Tomáš. Webová aplikace - interaktivní katalog restaurací s pokročilým vyhledáváním. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

9 Abstract The aim of this thesis is to create restaurant catalogue as website and mobile application with implementation of advanced searching method. The thesis begins with introduction study, followed by analysis, design, implementation and testing of both application. The thesis is concluded by evaluation of whole thesis. Keywords web application, mobile application, semantic search Abstrakt Cílem této diplomové práce je vytvoření webové a mobilní aplikace, které budou sloužit jako katalog restaurací s pokročilými možnostmi vyhledávání. Práce začíná úvodní studií, dále se věnuje analýze, návrhu, implementaci obou aplikací, testování a v závěru je zhodnocení celé práce. Klíčová slova webová aplikace, mobilní aplikace, sémantické vyhledávání ix

10

11 Obsah Úvod 1 Popis problému Průzkum trhu Existující řešení Specifikace cíle Úvodní studie Základní popis systému Business pohled na jednotlivé procesy systému Fulltextové a sémantické vyhledávání Požadavky na systém Případy užití Nefunkční požadavky Analýza Vyhledávací modul Webová aplikace Webová + Mobilní aplikace Návrh Popis použitých frameworků Návrh databáze Diagram tříd Realizace případů užití Mobilní aplikace xi

12 5 Návrh uživatelského rozhraní Uživatelské rozhraní webové aplikace Uživatelské rozhraní mobilní aplikace Implementace Použité technologie Vývoj webové aplikace Vývoj mobilní aplikace Testování Testy použitelnosti webové aplikace Testy použitelnosti mobilní aplikace Automatické testy GUI Unit testy Závěr 73 Zhodnocení práce Možné rozšíření Literatura 75 A Seznam použitých zkratek 77 B Příručka administrátora 79 B.1 Základy administrace B.2 Administrace ontologie jídel B.3 Administrace restaurací C Příručka administrátora restaurace 85 C.1 Vložení restaurace C.2 Administrace restaurace C.3 Editace jídelního lístku D Dotazníky pro testování s uživateli 87 D.1 Screener D.2 Seznam úkolů pro testování webové aplikace D.3 Seznam úkolů pro testování mobilní aplikace D.4 Dotazník po testu E Instalace webové a mobilní aplikace 93 E.1 Instalace webové aplikace E.2 Instalace mobilní aplikace xii

13 F Obsah přiloženého CD 95 xiii

14

15 Seznam obrázků 0.1 Webová aplikace Business procesy uživatelské části webové aplikace Business procesy administrační části webové aplikace Business procesy vyhledávacího modulu Google - předpověď počasí Případy užití popisující vyhledávání Případ užití vkládání komentářů Případ užití přihlašování a registrace uživatele Případy užití administrace restaurace Případy užití administrace webové aplikace Aktivity diagram vyhledávání jídel Aktivity diagram vyhledávání jídel Aktivity diagram správy ontologie Aktivity diagram vložení nové restaurace Aktivity diagram editace základních informací o restauraci Aktivity diagram vyhledávání restaurací a jídel (uživatelská část) Aktivity diagram registrace a přihlásení uživatele Aktivity diagram vkládání komentáře Uložení grafu metodou closure table Návrh databáze webové aplikace Diagram tříd modelů Životní cyklus presenteru Class diagram presenterů uživatelské části aplikace Class diagram presenterů administrace restaurace xv

16 4.7 Class diagram presenterů globální administrace Class diagram formulářů uživatelské části webové aplikace Class diagram formulářů administrace restaurace Class diagram formulářů administrace State diagram vyhledávání jídla State diagram vložení nového uzlu do ontologie State diagram vložení nové hrany do ontologie Životní cyklus aktivity Class diagram aktivit State diagram vložení nového jídla Návrh uživatelského rozhraní - wireframe homepage stránky Návrh uživatelského rozhraní - wireframe výsledků vyhledávání Návrh uživatelského rozhraní - wireframe detail restaurace Grafický návrh webové aplikace Grafický návrh mobilní aplikace Grafický návrh mobilní aplikace B.1 Přihlášení do administrace B.2 Správa slovníku synonym B.3 Ukázka editace vlastností hran B.4 Ukázka editace uzlů B.5 Ukázka editace hran B.6 Ukázka administrace restaurací C.1 Ukázka administrace restaurace pro majitele restaurací xvi

17 Úvod Tato kapitola popisuje problém, který budu v diplomové práci řešit a specifikuje cíle diplomové práce. Popis problému V posledních letech zažívá internet nebývalý rozmach a s tím se prudce zvyšuje i počet webových stránek a informacích, které jsou na internetu obsaženy. Někteří lidé pohlíží na celou množinu webových stránek jako na velkou databázi. Pro uživatele internetu, kteří hledají nějaké informace, je ovšem nejdůležitější najít co možná nejrychleji data, která hledají. Těžko si lze dnes představit používání internetu bez vyhledávačů jako je Google nebo Seznam, kdyby tady takové služby neexistovaly, asi jen stěží bychom dokázali z internetu vytěžit to co dnes. Bohužel internetové vyhledávače jsou pouze systémy fungující strojově, chybí jim tedy lidská inteligence. Často proto bývá problém spojit uživatelovu představu o tom, co vlastně hledá s možnostmi vyhledávače a také s poskytnutými výsledky. Na druhou stranu jsou strojové systémy schopny udělat práci, kterou by člověk zpracovával možná několik let. Nyní k trochu konkrétnějšímu problému. V České Republice je používání internetu poměrně dost rozšířené a to vědí i majitelé firem, kteří se proto snaží svoje společnosti prezentovat na internetu. Výjimkou nejsou ani restauratéři, většina restaurací má dnes webové stránky nebo se jiným způsobem prezentují na internetu. Toho využívají i uživatelé a na internetu hledají restaurace pro svůj firemní oběd, slavnostní večeři nebo jiné příležitosti. Někdy ovšem může být takové hledání docela oříšek. Základní idea na tuto diplomovou práci mě napadla ve chvíli, kdy jsem 1

18 Úvod se chtěl najíst v restauraci v Praze a měl jsem chuť na zeleninový salát. Ideální situace pro použití vyhledávání na internetu. Bohužel jsem nebyl příliš úspěšný. Zeleninový salát je příliš obecný pojem než aby ho měla nějaká restaurace na jídelním lístku a proto jsem musel nakonec svoje hledání provést tak, že jsem si vytipoval restaurace, které by mohly nabízet saláty a ty jsem jednu po druhé otevíral a kontroloval jídelní lístek, stala se z toho poměrně dlouhodobá záležitost, určitě delší než bych chtěl strávit nad výběrem restaurace na oběd v mém okolí. Začal jsem se tedy zajímat o tento problém detailněji. Průzkum trhu V předchozí podkapitole jsem nastínil myšlenku, která mě přivedla na tuto diplomovou práci. Dále jsem si chtěl ověřit, jestli mám stejnou potřebu pouze já nebo by i více lidí uvítalo vyhledávání restaurací podle toho, co v nich vaří nebo podle dalších parametrů. Primárně jsem se ale zaměřil na vyhledávání restaurací podle jídla. Na českém internetu existuje několik webových portálů, které umožňují pokládat zdarma dotazníky. Jedním z těchto webů je i zeptejse.cz[20], který jsem pro svůj průzkum zvolil. Kvalita takto prováděného průzkumu není příliš vysoká, ovšem celý průzkum je zdarma a pro studijní účely by mohl být dostačující. Průzkumu se zúčastnilo 151 uživatelů. Přibližně 50 Existující řešení Před stanovením cílů diplomové práce jsem také hledal podobné existující řešení na českém trhu. Našel jsem poměrně dost katalogů restaurací, které ale po většinou slouží jako linkové farmy. Největší český katalog Firmy.cz obsahuje většinu restaurací, ale opět v něm najdeme pouze základní informace, ale neobsahuje jídelní lístek, ten nalezneme vždy až na konkrétním webu dané restaurace. Asi nejznámější projekt v tomhle ohledu je lunchtime.cz (obr. 0.1), který funguje jako katalog restaurací, ale mimo jiné umožňuje vkládat na web jídelní lístky restaurací. Tento webový projekt je v poslední době stále více oblíbený, ale také nenabízí příliš velké možnosti vyhledávání. Základní filtrace probíhá podle adresy, což je určitě užitečné, ale dále již není možné vyhledávat jídla v restauracích, opět by tedy bylo nutné ručně projít všechny jídelní lístky a hledat dané jídlo. 2

19 Specifikace cíle Obrázek 0.1: Webová aplikace Specifikace cíle Na základě malého průzkumu trhu a prohledání existujících řešení jsem stanovil cíl své diplomové práce. Cílem je vytvořit katalog restaurací, který bude umožňovat pokročilé vyhledávání nejen restaurací, ale zejména jídel v nich podávaných. Princip vyhledávání by měl vycházet z možností fulltextového vyhledávání a vyhledávání v sémantických datech. Jelikož je vyhledávání restaurací poměrně specifický problém, je jedním z cílů vytvořenou vyhledávací metodu udělat dostatečně obecně, aby byla případně použitelná i pro jiné účely. Katalog restaurací bude prezentován formou webové a mobilní aplikace. 3

20

21 Kapitola 1 Úvodní studie V této kapitole popisuji business procesy webové a mobilní aplikace a vyhledávacího modulu. Dále se budu věnovat základnímu popisu fulltextového a sémantického vyhledávání. 1.1 Základní popis systému Celý systém bude funkčně rozdělen do tří hlavních částí, které jsou do jisté míry nezávislé. Nejdůležitější částí systému bude webová aplikace, která se bude starat zejména o prezentační část celého systému. Jednak bude zajišťovat webové rozhranní pro přístup uživatelů k vyhledávání a také administrační část pro správu vložených restaurací a informací o nich. Součástí této aplikace bude také poskytování webových služeb, které bude využívat mobilní aplikace. Jádrem celé aplikace je vyhledávací modul, který bude umožňovat vyhledávání restaurací a jídel pomocí pokročilých metod vyhledávání. Součástí tohoto vyhledávání bude i sémantická analýza informací o restauraci. Poslední částí bude mobilní aplikace pro systém Android, která bude sloužit hlavně jako podpůrná aplikace pro webové rozhranní. Hlavním účelem tedy bude zrcadlení některých hlavních služeb webové aplikace s ohledem na použitelnost v mobilním prostředí. 1.2 Business pohled na jednotlivé procesy systému Následující podkapitola má za účel podrobněji seznámit se systémem a popsat vymodelované procesy systému z business pohledu, tedy bez konkrétní 5

22 1. Úvodní studie specifikace technického řešení Webová aplikace Webová aplikace bude rozdělena do tří logických celků podle role uživatele uživatelská sekce, editace restaurace, globální administrace Uživatelská sekce Uživatelská sekce bude přístupná pro všechny návštěvníky webu. Jádrem této sekce bude spolupráce s vyhledávacím modulem, poskytování výsledků vyhledávání a procházení restaurací. Tato sekce bude také podporovat registraci uživatelů. Sekce bude navíc obsahovat některé služby, které budou dostupné pouze pro registrované například vkládání komentářů, posílání změn v jídelním lístku na apod Administrace restaurace Jednotlivé restaurace budou mít přístup k editaci svého profilu. Tento přístup musí být udělován na základě ověření majitele podniku, aby nedocházelo k administraci restaurace nepovolenými osobami. Součástí administrace bude editace základních informací o restauraci a jídelního lístku Globální administrace Globální administrace bude zahrnovat veškeré funkce administrace restaurace a správu celé webové aplikace. Součástí administrace by mělo být i propojení s vyhledávacím modulem, aby bylo možné provádět administraci vyhledávacího modulu a dále ho konfigurovat Vyhledávací modul Hlavním účelem vyhledávacího modulu bude obsluhovat požadavky na vyhledávání přicházející z webové a mobilní aplikace. Modul bude rozdělen na dvě hlavní části vyhledávání restaurací a vyhledávání konkrétních jídel z jídelního lístku (obr. 1.3). Při vyhledávání bude největší důraz kladen na hledání pomocí textových řetězců vložených uživateli, ale modul musí zvládat i následné hledání pomocí dodatečných parametrů (otevírací doba restaurace apod.). Cílem je navrhnout vyhledávání, které nebude fungovat jako jednoduchý fulltext na bázi porovnávání řetězců, ale zejména v případě jídel bude umožňovat vyhledávání na základě vlastností jídel, které nejsou přímo obsažené v textu a jsou tedy předmětem sémantické analýzy. 6

23 1.2. Business pohled na jednotlivé procesy systému Obrázek 1.1: Business procesy uživatelské části webové aplikace Mobilní aplikace Poslední částí systému bude mobilní aplikace pro systém Android. Hlavním účelem je poskytovat totožné služby jako uživatelská část webové aplikace (vyhledávání, procházení a komentování restaurací) ovšem v uživatelském rozhraní vhodném pro dotykové mobilní telefony. Business procesy této aplikace jsou tedy stejné, jako procesy uživatelské sekce webové aplikace. 7

24 1. Úvodní studie Obrázek 1.2: Business procesy administrační části webové aplikace 1.3 Fulltextové a sémantické vyhledávání V této podkapitole popisuji fulltextové a sémantické vyhledávání a základní rozdíly mezi nimy. 8

25 1.3. Fulltextové a sémantické vyhledávání Obrázek 1.3: Business procesy vyhledávacího modulu Fulltextové vyhledávání Součástí mé diplomové práce bude vyhledávací modul, který má nabídnout pokročilé možnosti vyhledávání. Rozhodl jsem se tyto pokročilé možnosti směrovat hlavně k sémantickému vyhledávání. Většina dnešních větších webových stránek obsahuje vyhledávání, většinou se ovšem jedná o varianty fulltextového vyhledávání. Fulltextové vyhledávání se většinou liší při implementaci přímo ve webové aplikaci nebo v případě vyhledávačů. Základní princip fulltextového vyhledávání spočívá v porovnání zadaného dotazu (řetězce) s daty obsaženými v databázi, zjednodušeně lze říci, že se jedná o porovnávání řetězců. Pokud je ovšem taková databáze velká, není možné při každém dotazu tuto databázi celou projít, v případě obecných vyhledávačů (Google) je tou databází totiž celý internet. V tomto případě je proto nutné provádět indexaci jednotlivých webových stránek, aby bylo možné následně rychleji prezentovat výsledky. Problémem klasického fulltextového vyhledávání je, že vyhledávač nemá žádné informace o vazbách mezi informacemi, dalo by se tedy říci, že nerozumí ani vloženému řetězci a ani databázi, kterou prohledává. Jedním z cílů sémantického vyhledávání je snaha tento problém vyřešit. 9

26 1. Úvodní studie Sémantické vyhledávání Sémantické vyhledávání má větší pochopení pro vazbu mezi informacemi a mapuje vztahy a význam jednotlivých slov. Ideální sémantický vyhledávač nevrací seznam relevantních výsledků ale přímo odpověď na otázku. Toto je samozřejmě zásadní krok, který by znamenal, že vyhledávací stroje musí rozumět dotazu a také rozumět datům, které prohledávají. V současnosti není vyhledávač, který by tuhle metodu byl schopen implementovat globálně pro celý internet. Přední světový vyhledávač Google se například snaží sémantické vyhledávání implementovat alespoň částečně. Pro určité vyhledávací dotazy tak vrací v první řadě přímo odpověď na zadanou otázku. Příkladem může být vyhledávání řetězce weather (počasí) (obr. 1.4), které vrátí předpověď počasí pro danou oblast. Dalším příkladem je zobrazování programu kin v dané oblasti nebo popis filmů při vyhledávání jména filmu. Obrázek 1.4: Google - předpověď počasí Existuje několik metod sémantického vyhledávání, které se vzájemně výrazně liší v celkovém přístupu[16]. Jedna z metod je například založená na RDF (Resource Description Framework), což je framework, který umožňuje popsat data zobrazovaná na webu. Tento přístup ovšem vyžaduje snahu také ze strany poskytovatelů obsahu, tedy majitelů webových stránek. V současnosti se tuto metodu pokouší rozšířit společnost Google. Jejich vyhledávač je uzpůsoben pro vyhledávání některých speciálních dat, jako jsou například hodnocení, události, organizace nebo osoby. Aby vyhledávač Google těmto datům správně rozuměl, je nutné, aby byly správně označeny a popsány majitelem webové stránky. Další metodou je využívání grafových vzorů, které vyhledávači umožňují získat zajímavé vztahy a spojení mezi jednotlivými 10

27 1.3. Fulltextové a sémantické vyhledávání zdroji. Tím je možné částečně porozumět vyhledávacím dotazům a tím i rozšířit možnosti vyhledávání. Tuto metodu jsem se rozhodl implementovat i ve své diplomové práci. 11

28

29 Kapitola 2 Požadavky na systém Následující kapitola má za úkol přesněji specifikovat jednotlivé funkce celého systému a to hlavně za pomoci modelování případů užití. Dále jsou v této kapitole obsaženy nefunkční požadavky, které specifikují hlavně základní použité technologie. Součástí této kapitoly není výpis funkčních požadavků, ty budou rozebírány v jednotlivých případech užití. 2.1 Případy užití V této podkapitole popisuji základní případy užití webové a mobilní aplikace a vyhledávacího modulu Webová + mobilní aplikace Vyhledávání Nejdůležitější částí webové aplikace bude vyhledávání restaurací a jídel. Primárně musí fungovat vyhledávání na základě zadaného řetězce. Součástí vyhledávání ovšem musí být také možnost zadat pokročilé parametry: Vyhledávání restaurací pouze v určitém okolí, zde bude možnost zadat pozici nebo využít automatické detekce pozice (v prohlížeči s podporou HTML 5 a hlavně v mobilní aplikaci pomocí lokačního systému). Vyhledávání podle otevírací doby restaurace Po zobrazení výsledků bude možné změnit pokročilé parametry vyhledávání a změnit klíčová slova a tím změnit výsledky vyhledávání. Všechny tyto případy užití budou dostupné ve webové i mobilní aplikaci. V mobilní 13

30 2. Požadavky na systém Obrázek 2.1: Případy užití popisující vyhledávání aplikaci ovšem bude více potlačeno pokročilé vyhledávání pro zjednodušení a větší pohodlí při ovládání mobilní aplikace Detail restaurace a vkládání komentářů Z výsledků vyhledávání bude možné zobrazovat detailní stránky jednotlivých restaurací. Detail restaurace musí obsahovat základní informace o 14

31 2.1. Případy užití restauraci, jídelní lístek a komentáře uživatelů (obr. 2.2). Obrázek 2.2: Případ užití vkládání komentářů Přihlašování uživatelů Jak jsem již nastínil v předchozí podkapitole, registrace uživatelů by měla být jednoduchá a co možná nejrychlejší. Povinné by mělo být pouze vložení u a hesla, aby byla registrace co možná nejjednodušší (obr. 2.3) Administrace restaurace Nepřihlášený uživatel bude moci požádat o vložení nové restaurace, ovšem součástí tohoto procesu bude i registrace uživatele. Součástí vložení restaurace je i ověření majitele restaurace, aby systém předešel nepovolenému vkládání restaurací. Toto ověření bude probíhat mimo hranice systému. V administraci restaurace bude možné editovat základní informace o restauraci, obsahující popis restaurace, otevírací dobu. Nejdůležitější částí této administrace bude vkládání jídel do jídelního lístku. Při vkládání jídel bude probíhat spolupráce s vyhledávacím modulem, úkolem bude identifikovat vložené jídlo a extrahovat co možná nejvíce vlastností o tomto jídle, které budou později použity při vyhledávání. Majitelům restaurací bude doporučeno vkládat standardní názvy jídel, které samozřejmě systém lépe rozpozná (obr. 2.4). 15

32 2. Požadavky na systém Obrázek 2.3: Případ užití přihlašování a registrace uživatele Administrace webové aplikace Pro globálního administrátora bude dostupná administrace webové aplikace, která bude zahrnovat tři logické celky. Další částí bude administrace vyhledávacího modulu, kterou popisuji v následující kapitole. Poslední částí bude správa restaurací, která bude zahrnovat správu restaurace z pohledu administrátora restaurace editace veškerých informací o restauraci Vyhledávací modul Důležitou částí celého systému bude vyhledávací modul. Jeho funkčnost bude rozdělena na dvě části vyhledávání jídel nebo restaurací a analýza jídel při vkládání do jídelního lístku. Celý vyhledávací model bude spolupracovat s ontologií jídel, která bude do systému předem vložená a bude možné jí obohacovat právě přidáváním nových jídel. Součástí této ontologie budou jednotlivá jídel a jejich vlastnosti. Při vyhledávání jídel bude prvním krokem analýza vstupního řetězce. Nejprve je potřeba analyzovat jednotlivá slova a odstranit z vyhledávání nízkovýznamová slova, jako třeba předložky nebo spojky. Následně se bude podle jednotlivých slov vyhledávat v onto- 16

33 2.1. Případy užití Obrázek 2.4: Případy užití administrace restaurace logii jídel v konkrétních jídlech, jejich vlastnostech a ve skupinách jídel. Modul bude také podporovat slovník synonym, který rozšíří možnosti vyhledávání. Pokud modul nerozpozná některý řetězec a nenalezne k němu příslušné jídlo, bude fungovat pouze na bázi porovnání řetězce Administrace vyhledávacího modulu Mimo samotného vyhledávání bude potřeba připravit možnost celý modul administrovat a upravovat slovník synonym a ontologii jídel. Administrace slovníku synonym bude obsahovat možnost vkládání nových slov, které bude poté možné vzájemně propojovat a tím vytvářet synonyma. Celá ontologie bude uložena jako graf uzlů a hran. Proto je nutné zajistit při editaci ontologie vkládání nových uzlů do grafu, jejich editaci a odstraňování uzlů z grafu. Stejně tak je nutné vytvářet nové hrany mezi existujícími uzly a tyto hrany editovat nebo mazat. 17

34 2. Požadavky na systém Obrázek 2.5: Případy užití administrace webové aplikace 2.2 Nefunkční požadavky Použitá platforma Webová aplikace včetně vyhledávacího modulu bude spuštěna na webovém serveru s podporou PHP 5.3 a databází MySQL. Velká část aplikace bude napsána v PHP s použitím frameworku Nette 2. Jak již bylo zmíněno v předchozí kapitole, mobilní aplikace bude implementována pro OS Android. Stanovení konkrétní verze OS Android je předmětem návrhu mobilní aplikace. Jelikož se jedná o poměrně jednoduchou aplikaci z hlediska požadavků na OS Android, měla by být použita co možná nejnižší verze, aby ovšem zároveň neporušila dopřednou kompatibilitu s nejnovější verzí OS Android. Zvolil jsem proto Android verzi

35 Kapitola 3 Analýza V této kapitole popisuji analýzu všech tří částí systému, zejména se zaměřuji na popis jednotlivých procesů pomocí aktivity diagramů. 3.1 Vyhledávací modul Ontologie jídel Jak již bylo nastíněno v předchozích kapitolách, vyhledávací modul bude obsahovat ontologii jídel, podle které bude vyhledávat. V tradičním pojetí sémantického webu jsou obvykle ukládána data do trojic, které jsou charakterizovány jako zdroj, vlastnost a hodnota vlastnosti. Přičemž zdroj a hodnota vlastnosti lze charakterizovat jako objekt. Pro účely vyhledávání by pravděpodobně stačilo použít pouze uspořádané dvojice, rozhodl jsem se ovšem v ontologii používat kompletní trojice pro lepší možnosti rozšíření systému v budoucnu. V naší reprezentaci tedy vytvoříme uspořádané dvojice typu potomek -> vlastnost -> předek, které budou znamenat, že potomek obsahuje vlastnost předka. Například pokud budeme chtít popsat následující větu Svíčková je podkategorie českého jídla. Budeme mít objekty svíčková a česká jídla a dvojice bude české jídlo-> podkategorie -> svíčková. Důležité je, že každý objekt může být v různých uspořádaných dvojicích zároveň potomek i předek, tím pádem lze objekty do sebe vzájemně vnořovat a vytvářet stromovou strukturu. Pokud tedy například přidáme vlastnost středoevropská jídla, můžeme vytvořit dvojici středoevropské jídlo->české jídlo, ale pouze v případě, že všechny potomci českého jídla jsou zároveň potomci středoevropského jídla. V dané struktuře je potřeba zamezit cyklům, které ovšem při dodržení logiky reálného světa nemohou nastat. Tyto cykly by mohly nastat pouze u dvou synonymních vlastností, tedy stejného 19

36 3. Analýza významu, pouze jinak zapsané. Vyhledávací modul ovšem bude obsahovat slovník synonym, aby předcházel vytvoření takových vztahů. Slovník synonym samozřejmě nemusí být kompletní a proto je potřeba jednak umožnit jeho rozšiřování a také kontrolovat případné cykly v dané struktuře Slovník synonym Důležitým krokem při sémantickém vyhledávání jsou také synonyma. Při porovnávání dvou řetězců podle skladby písmen se mohou synonyma jevit jako odlišná i když jejich význam je stejný. Aby vyhledávání v ontologii dobře fungovalo, je třeba mít slovník synonym. Slovník synonym bude pro ontologii jídel implementován na bázi kardinality 1:N. To znamená, že jedno slovo bude označeno za kmenové a ostatní synonyma budou k němu přiřazená, těch může být N. To ve výsledku znamená, že v ontologii jídel, se budou vyskytovat pouze slova kmenová. Tím se zjednoduší vyhledávání, protože pokud bude v systému například slovo, které má 5 synonym, vyhledávání použije pouze kmenové slovo a to prohledá v ontologii, nebude tedy potřeba 5 samotných vyhledávání pro každé slovo. Ontologie bude pro uživatele i pro administrátory restaurace skrytá, proto je možné tolerovat případné drobné prohřešky ve skloňování nebo přirozenosti českého jazyka, které mohou vzniknout nahrazováním synonym za jejich kmenová slova Vyhledávání jídla Nejdůležitější částí vyhledávacího modulu je vyhledávání jídel. Uživatel bude moci zadat vstupní řetězec a dále pokročilé parametry, kterými může specifikovat restaurace, které se budou prohledávat. Konkrétně bude možné zadat otevírací dobu restaurace, pozici na mapě a rádius, ve kterém se restaurace budou vyhledávat. Vstupní řetězec bude nejprve očištěn o nízkovýznamová slova jako jsou předložky a spojky. Následně budou převedeny speciální české znaky na znaky anglické abecedy, to protože stále velká část české populace nepoužívá při psaní na internetu háčky a čárky. Dále budou prohledávané jednotlivé uzly ontologie, nejprve se bude hledat shoda s celým vstupním řetězcem, a pokud nebudou nalezeny výsledky, budou se vyhledávat i jednotlivá slova Vyhledávání restaurací Vyhledávání restaurací bude do jisté míry podobné s vyhledáváním jídel. Při vyhledávání jídel je pravděpodobné, že budou uživatelé hledat některé výrazy, které budou obsažené v ontologii jídel, jako je například typ kuchyně, 20

37 3.1. Vyhledávací modul Obrázek 3.1: Aktivity diagram vyhledávání jídel druh točeného piva atd. Proto bude součástí vyhledávání také prohledání ontologie jídel, a pokud budou nalezeny některé vlastnosti, budou prohledány i jídelní lístky. Návratem ovšem nebudou jednotlivá jídla, ale pouze restaurace, které mají dané jídlo v nabídce. Dále bude prohledávána adresa restaurace, která bude velmi důležitá při vyhledávání. Proto je nutné specifikovat v adrese mimo ulice také město a případně čtvrť, ve které se restaurace nalézá. Při prohledávání restaurací bude také využit slovník synonym. 21

38 3. Analýza Obrázek 3.2: Aktivity diagram vyhledávání jídel 3.2 Webová aplikace Administrace aplikace Správa ontologie Administrace webové aplikace bude mimo jiné umožňovat správu ontologie jídel, která se bude v průběhu fungování aplikace pravděpodobně rozšiřovat. Rozšiřování by mělo vycházet hlavně z požadavků majitelů restaurací, kteří budou navrhovat nové vlastnosti při popisu jejich jídel. V administraci bude možné přidávat nové vlastnosti a přiřazovat je k jiným, již existujícím, vlastnostem. Jak jsem uváděl v předchozí kapitole, systém nebude rozlišovat mezi jídlem a vlastností jídla pro vyšší flexibilitu (viz předchozí kapitola). 22

39 3.2. Webová aplikace Obrázek 3.3: Aktivity diagram správy ontologie Správa slovníku synonym Součástí administrace bude také možnost spravovat slovník synonym, který bude součástí vyhledávacího modulu. Administrátor bude moci do slovníku přidávat nová slova nebo k již definovaným slovům přiřazovat synonyma. Při vložení nového synonyma je potřeba prohledat jednak ontologii jídel a také databázi jídel a nahradit nové synonymum za jeho kmenové slovo (viz podkapitola o slovníku synonym) Správa restaurací Správa restaurací bude obsahovat hlavně správu restaurace s pohledu majitele restaurace (administrátora restaurace), tato správa je popsána níže v této kapitole. Navíc bude mít administrátor právo povolit jednotlivé restaurace. 23

40 3. Analýza Administrace restaurace Vložení nové restaurace Prvním krokem administrace restaurace bude samotné vložení restaurace. Požádat o vložení restaurace bude moci pouze registrovaný uživatel. Pro zlepšení uživatelského rozhraní bude možné spojit registraci s vložením nové restaurace. Při vkládání nové restaurace bude uživatel vkládat pouze kontaktní údaje, které bude nutné následně ověřit administrátorem. K ověřování bude použit nebo telefon a v krajním případě poštovní adresa. Součástí ověření bude zkontrolování těchto údajů s některým z již ověřených záznamů, například v katalogu Firmy.cz aj. a následným potvrzením majitele restaurace přes zvolený komunikační kanál. Poté bude založena restaurace a majitel bude moci prostřednictvím svého uživatelského účtu přistupovat k editaci restaurace (obr. 3.4). Obrázek 3.4: Aktivity diagram vložení nové restaurace Editace základních informací Majitel restaurace bude moci editovat základní informace o restauraci. Mezi ty bude patřit jednoduchý popisek restaurace obsahující jeden až dva od- 24

41 3.2. Webová aplikace stavce, kontaktní informace (adresa, telefon, , webové stránky) a otevírací dobu (obr. 3.5). Obrázek 3.5: Aktivity diagram editace základních informací o restauraci Editace jídelního lístku Nejdůležitější částí bude editace jídelního lístku. Jídelní lístek bude moci majitel restaurace dělit do skupin (jídlo, pití, polévky atd.) podle svého uvážení. Důležitou součástí bude vkládání samotných jídel. Administrátor bude vyplňovat tři základní položky název jídla, gramáž a cenu v případě pití bude samozřejmě uváděn objem. Při vložení názvu jídla bude provedena analýza jídla pomocí ontologie jídel a budou mu přiřazené jednotlivé vlastnosti. Tento proces bude probíhat podobně jako vyhledávání jídla ve vyhledávacím modulu, kde jsou nejprve provedeny jazykové úpravy a následně je prohledána ontologie. Výsledkem bude sjednocení jednotlivých nalezených vlastností a vlastností, které budou z nalezených vlastností vycházet (například všechny pizzy spadají pod italskou kuchyni). Majitel bude 25

42 3. Analýza moci vložit do systému také nové vlastnosti, které budou k jídlu přiřazeny až po schválení administrátorem, který je musí zařadit do ontologie. 3.3 Webová + Mobilní aplikace V této podkapitole jsou popsány jednotlivé aktivity, které se vztahují pro webovou i mobilní aplikaci. Služby poskytované pouze ve webové aplikaci jsou uvedeny v předchozí podkapitole Vyhledávání Jak již bylo zmíněno, vyhledávání bude jádrem webové i mobilní aplikace. Jelikož celá aplikace obsahuje vyhledávací modul, úkolem webové a mobilní aplikace bude pouze obsluha uživatelského rozhranní, předání požadavků vyhledávacímu modulu a následné zobrazení výsledků. Uživatel bude moci vyhledávat v základní formě, při které bude vkládat pouze hledaný řetězec nebo bude moci využít rozšířené vyhledávání, jeho možnosti již byly popsány v předchozí kapitole. Výsledek vyhledávání bude uživateli prezentován formou seznamu nebo pomocí mapy, uživatel bude moci mezi těmito módy jednoduše přepínat. Způsob vyhledávání je popsán v předchozí podkapitole, která se věnuje vyhledávacímu modulu. Po zobrazení výsledků vyhledávání bude aplikace umožňovat uživateli změnit nebo specifikovat pokročilé parametry a tím změnit výsledky vyhledávání (například specifikací lokace restaurace, otevírací doby atd.). Z pohledu systému bude tento požadavek obsloužen jako nové hledání. Z pohledu uživatele bude vyhledávání restaurací a jídel velmi podobné a pokročilé parametry budou stejné, jelikož se týkají pouze filtrace restaurací Registrace a přihlášení Webová aplikace bude umožňovat registraci a přihlášení uživatele. Systém bude umožňovat registraci pomocí u a hesla Vkládání komentáře Pro přihlášené uživatele bude možnost vložit komentář k jednotlivým restauracím. Nepřihlášení uživatelé budou před zobrazením formuláře vyzváni k přihlášení nebo registraci. Součástí formuláře bude jednak číselné hodnocení na stupnici 1-5 a také možnost slovního hodnocení. Komentáře bude možné vkládat přes webovou i mobilní aplikaci. 26

43 3.3. Webová + Mobilní aplikace Obrázek 3.6: Aktivity diagram vyhledávání restaurací a jídel (uživatelská část) 27

44 3. Analýza Obrázek 3.7: Aktivity diagram registrace a přihlásení uživatele 28

45 3.3. Webová + Mobilní aplikace Obrázek 3.8: Aktivity diagram vkládání komentáře 29

46

47 Kapitola 4 Návrh V této kapitole budu podrobněji popisovat návrh webové aplikace. Jelikož je celá práce poměrně obsáhlá rozhodl jsem se v návrhu popsat pouze některé části aplikace, které mi přijdou zajímavější, zejména části spojené se samotným vyhledáváním. V závěru kapitoly se budu také věnovat návrhu mobilní aplikace. 4.1 Popis použitých frameworků Vývoj webových aplikací zažívá v posledních letech velký boom, aby probíhal celý vývoj rychleji, používá se většinou některý z frameworků, který umožní rychlejší vývoj celé aplikace. Jelikož jsem použil programovací jazyk PHP využil jsem také českého frameworku Nette 2[9] a jako ORM (Object Relational Mapper) jsem využil Doctrine 2[5]. Pro lepší pochopení celého návrhu webové aplikace je potřeba nejprve vysvětlit základní principy použitých frameworků Nette Framework Nette framework si v posledních letech získal popularitu zejména u české programátorské veřejnosti. Ač není příliš známý celosvětově, patří k velmi rychlým a kvalitním frameworkům, které ulehčují práci při programování webových stránek. Framework funguje na principu MVP (Model-View-Presenter) jako front-controller. V prvním kroku každého http požadavku se nejprve hledá vhodný presenter (controller) a akce pro zpracování požadavku. To probíhá na základě routování URL. Presenter se poté stará o zpracování každé akce a komunikuje s modelem a zároveň připravuje aplikaci pro zobrazování výstupu o který se primárně stará šablonovaní systém Latte. Každý 31

48 4. Návrh presenter obsahuje několik metod, které se postupně volají, od základní inicializace až po metodu, která se stará o renderování obsahu. Mimo základní implementace MVP obsahuje framework i několik podpurných knihoven, mezi nejzajímavější patří podpora komponent. Což jsou jednotlivé logické prvky na webu, které mohou samostatně fungovat, mezi tyto komponenty patří například formuláře, komponentou je ale i samotný presenter. Každá komponenta navíc může obsluhovat signály, což jsou zjednodušené akce. Díky těmto modifikacím je celý framework připravený i na moderní vývoj aplikací pomocí JavaScriptu a AJAXu. Umožňuje totiž překreslovat jednotlivé komponenty nebo pouze jejich části právě na základě akcí a signálů Doctrine 2 Samotný Nette framework obsahuje pouze základní databázovou vrstvu, proto se většinou používá ještě s některým ORM frameworkem. V tomto případě jsem zvolil ORM Doctrine 2, který je poměrně rychlý a v dnešní době velmi oblíbený. Úkolem každého ORM je mapování tabulek relační databáze na objekty, protože se v moderním programování pracuje s objekty. 4.2 Návrh databáze Jako databázi jsem zvolil MySQL, která se dnes standardně používá pro aplikace psané v jazyce PHP. Při návrhu webových aplikací je potřeba brát v potaz větší návštěvnost uživatelů. V případě katalogu restaurací se předpokládá velké množství uživatelů, kteří budou vyhledávat restaurace a zobrazovat je, naproti tomu bude minimum požadavků na ukládání dat do databáze. Proto se při návrhu databáze občas odchyluji od základních principů návrhů databází. Například v tabulce restaurace je předpočítaný průměrný rating každé restaurace a také počet hlasujících. Z pohledu návrhu databáze se jedná o redundantní informace, ovšem jedná se o data, která by se musela dopočítávat při mnoha požadavcích, a tím by se zvyšovalo zatížení serveru. Druhým příkladem je optimalizace pro vyhledávání. Jelikož pro vyhledávání se budou používat řetězce bez nízkovýznamových slov a bez diakritiky jsou v databázi uloženy dvakrát, jednou pro zobrazování a podruhé pro vyhledávání. Tím dochází k redundanci dat, jedná se o názvy uzlů ontologie, slova ve slovníku synonym a popisy a názvy restaurací a jídel. Tato redundance je ovšem ospravedlnitelná, jelikož významně urychlí vyhledávání. K celé databázi se bude následně přistupovat pomocí ORM Doctrine 2 pomocí tříd, které budou namapovány na konkrétní entity v databázi(obr. 4.1). 32

49 4.2. Návrh databáze Uložení ontologie Zajímavou částí návrhu databáze je uložení ontologie jídel, jejíž uzly a hrany tvoří orientovaný graf. Při vkládání nových jídel se budou z ontologie vybírat jednotlivé vlastnosti jídel, které se budou hledat při vyhledávání jídel a restaurací. Při tomto hledání se bude pracovat s rodiči a potomky každého uzlu, je proto nutné zvolit uložení, které umožní rychlé vyhledávání rodičů a potomků. Zvolil jsem proto uložení nazvané closure table[3]. Při tomto uložení nejsou uloženy pouze reálné hrany v grafu, ale každý uzel odkazuje na všechny své potomky, pro každého potomka je vytvořen speciální řádek grafu, každá hrana obsahuje ještě informaci o vzdálenosti dvou uzlů. Reálné hrany tedy mají vzdálenost 1 a další potomci, kteří nejsou přímý, mají větší vzdálenosti. Tím se lze jednoduše dotázat na všechny rodiče nebo potomky daného uzlu. Nevýhodou closure table je větší množství dat v databázi, protože stromová struktura může teoreticky obsahovat až n na druhou řádků a v mém případě, kdy ontologie nemusí být pouhý strom, ale jakýkoliv orientovaný acyklický graf, může být těchto řádků ještě více. V praxi je ovšem těchto řádků mnohem méně. Navíc s použitím klíčů se významně zrychlí vyhledávání. Obrázek 4.1: Uložení grafu metodou closure table Uložení jídel U každého jídla bude potřeba uložit několik jeho vlastností, které se extrahují z ontologie jídel. V databázi bude pravděpodobně velké množství 33

50 4. Návrh stejných jídel, protože mnoho restaurací nabízí podobná jídla. Proto jsem se rozhodl vytvořit jednu souhrnou tabulku jídel, která budou následně navázána na reálná jídla v jídelních lístcích, která mají rozdílné ceny apod. Dále jsem potřeboval vyřešit ukládání jednotlivých charakteristik každého jídla, které jsou charakterizované uzly z ontologie jídel. V ontologii jídel jsou rodiče každého uzlu jeho obecnější charakteristikou a naopak potomci jsou specifičtější varianty. Jídlo, které má tedy vlastnost určitého uzlu má vlastnost i všech jeho rodičů, jedná se o obecnější vlastnosti. Naopak při vyhledávání bude uživatel hledat i vlastnosti, které jsou potomky uzlů a nejen uzly samotné. Při ukládání vlastností jídel by tedy stačilo vybrat pouze několik nejspecifičtějších uzlů a veškeré obecnější vlastnosti by bylo možné dopočítat. To by ovšem zvyšovalo nutný výpočetní výkon při vyhledávání. Proto při extrahování vlastností z ontologie jídel bude aplikace vybírat všechny vlastnosti a tím pádem tedy všechny rodiče vybraných uzlů. Tím se zvýší objem dat uložených v databázi, ale zrychlí se vyhledávání, protože se bude vyhledávat pouze výskyt konkrétních uzlů a nebudou se muset brát v potaz jejich potomci. 4.3 Diagram tříd Nette framework umožňuje rozdělit jednotlivé presentery do logických celků, kterým se říká moduly, při vytváření této aplikace jsem tedy vytvořil tři základní moduly, stejně jako jsem to již prováděl v analýze. Aplikace tedy bude obsahovat modul pro administraci celé aplikace, modul administrace restaurace a prezentační modul, který bude sloužit pro návštěvníky webových stránek. V Nette frameworku jsou hlavní části aplikace umístěny v modelech a presenterech, které tvoří pomyslné jádro aplikace. Z návrhového vzoru MVC zbývá ještě část View, která je v případě Nette obsluhována šablonovacím systémem a částečně presenterem, který předává data právě šablonovacímu systému Modely Úkolem modelu je při použití klasického MVC hlavně komunikace s databází a obsluhování požadavků presenterů na změnu stavu celého modelu neboli business logiku. Při použití Nette frameworku společně s ORM Doctrine 2 zajišťuje samotnou komunikaci s databází přímo framework Doctrine 2, který celou databázi odstíní a na úrovni modelu se pracuje pouze s třídami a objekty jednotlivých entit. Úkolem modelu je tedy pouze provádět business logiku a pro komunikaci s databází se využívá Doctrine 2. Pro jednoduchost 34

51 4.3. Diagram tříd Obrázek 4.2: Návrh databáze webové aplikace a přehlednost aplikace řeším jednoduchou komunikaci s databází přímo v presenterech s jednoduchým využítím modelu, který pouze deleguje požadavek ORM vrstvě. Celý model jsem se rozhodl rozdělit do tří logických celků, a proto jsem vytvořil tři třídy modelu, přičemž každá se bude starat o část kompletního modelu (obr. 4.3). 35

52 4. Návrh SearchModel Tato třída bude zajišťovat business logiku spojenou s vyhledávacím modulem a ontologií jídel. Bude tedy obsluhovat veškeré události spojené s editací ontologie, jako je přidávání/mazání hran a uzlů k tomu bude potřeba několik pomocných metod jako je získávání rodičů a potomků uzlů apod. Součástí tohoto modelu bude také implementace samotného vyhledávání restaurací a jídel. RestaurantModel Tento model bude obsluhovat business logiku spojenou s editací restaurací. Zde bude například ověření nových restaurací, ověření možnosti editace restaurace uživatelem apod. Proces přidávání jídel do jídelního lístku bude částečně obsluhován třídou SearchModel, která se bude starat o vytváření objektu MealBase. Jelikož je administrace restaurace v několika případech velmi jednoduchý proces, který pouze ukládá data z formulářů do databáze, tak budou tyto akce řešené rovnou ve třídách formulářů, protože pro jejich obsloužení stačí pouze komunikace přímo s ORM. UserModel Třetí model bude sloužit pro požadavky spojené se správou uživatelských účtů. Obrázek 4.3: Diagram tříd modelů 36

53 4.3. Diagram tříd Presentery Presenter neboli controller zajišťuje komunikaci mezi modelem a view. V případě webových stránek je view reprezentován HTML stránkami se kterými uživatel ovládá daný systém. Jádro aplikace tedy obsahují presentery, které obsluhují jednotlivé HTTP požadavky. Jak jsem již nastínil výše, umožňuje Nette framework rozdělit presentery do logicky oddělených modulů. V tomto dokumentu se nebudu věnovat všem presenterům, ale obecně popíšu jejich fungování a popíšu několik příkladů. Detailní přehled presenterů je vidět na přiloženém obrázku Životní cyklus presenteru Pro pochopení celého fungování presenterů a následně i formulářů, kterým se budu věnovat v následující podkapitole, je potřeba popsat životní cyklus presenteru a celého http požadavku. Při odeslání http požadavku uživatelem nejprve framework vybírá presenter, který bude daný požadavek obsluhovat. Tento výběr probíhá na základě routování tj. porovnávání požadované URL s filtry jednotlivých presenterů a akci. Následně se vytvoří presenter, který daný požadavek obslouží. Nejprve se volá metoda startup, která slouží pro inicializaci celého presenteru a může například ověřit identifikaci uživatele. V druhém kroku se volá již konkrétní akce presenteru, tato metoda je spouštěna ještě před samotným začátkem vykreslování odpovědi (pomocí šablon). Do této metody je vhodné například umístit kód, který uloží nějaká data a dále provede přesměrování, bylo by tedy zbytečné tyto úkony dělat až ve fázi renderování odpovědi. V další fázi se obsluhují signály, které jak jsem již psal, fungují jako jednodušší varianta volání celé akce. Obsluha signálu nejčastěji zajišťuje drobnější úkoly a většinou se používá ve spojení s AJAXovým voláním. Dále se volá metoda beforerender a render. Metoda beforerender je společná pro všechny akce v daném presenteru, ale konkrétní metoda render je samostatná pro jednotlivé akce. Na závěr se volá metoda shutdown, která slouží například k uložení stavu presenteru (obr. 4.4) Ukázka presenteru Jako ukázku popíši fungování třídy RestaurantPresenter v modulu administrace restaurace. Účelem tohoto presenteru je obsluhovat akce spojené s editací restaurace jejím administrátorem. Každá akce, která je namapovaná na konkrétní URL může mít část URL jako parametr dané akce, tím můžeme například editovat určitou restauraci pomocí id, které je obsaženo v URL. Pro webové stránky, které používají běžní uživatelé je snaha vytvářet 37

54 4. Návrh Obrázek 4.4: Životní cyklus presenteru hezké URL, kterým uživatelé rozumí. Proto je vhodné například místo id restaurace použít hezký tvar URL složený například z názvu restaurace. V tomto případě je tedy každé akci předána část URL, která symbolizuje název restaurace, tato část URL musí být unikátní v databázi (v případě shody jmen restaurací se budou za jméno přidávat čísla). Na základě tohoto řetězce najdeme konkrétní restauraci, kterou budeme upravovat. Každá restaurace má administrátora, který má povolení restauraci upravovat, dále má povolení upravovat restauraci globální administrátor, před každou akcí je proto potřeba ověřit, že je uživatel přihlášen a má právo restauraci editovat. Přihlášení uživatele je možné kontrolovat již v metodě startup, ale kontrola povolení editace restaurace daným uživatelem se kontroluje až v následujících metodách, kterým už je předána daná část URL. Správně by se tato operace měla provádět v metodě action, tedy ještě před samotným vykreslováním. V tomto případě je ovšem vhodné přesunout danou kontrolu 38

55 4.3. Diagram tříd Obrázek 4.5: Class diagram presenterů uživatelské části aplikace až k metodě zajišťující samotné renderování, protože tím nebudeme muset v presenteru vytvářet dvojnásobný počet metod. Úkolem jednotlivých akcí je ve většině případů předávání dat pro šablonovací systém a také pro jednotlivé formuláře, podle toho, která stránka administrace se právě zobrazuje. Obsluha jednotlivých formulářů je řešena ve třídách samotných formulářů, protože celý kód je tím přehlednější a flexibilnější. Jednotlivé formuláře je poté možné použít kdekoliv v celé aplikaci. Součástí administrace bude například také mazání jídel z jídelního lístku, tohle je typický příklad pro použití signálu namísto celé akce. Celý požadavek pouze ověřuje povolení pro editaci dané restaurace a následné smazání jídla a zobrazení informační hlášky pro uživatele. Proto je vhodné použít signál, který není plnohodnotným požadavkem. Celé toto volání může být implementováno pomocí AJAXového volání a následně pouze překreslení některé části webové stránky. 39

56 4. Návrh Obrázek 4.6: Class diagram presenterů administrace restaurace Formuláře V této podkapitole představím fungování formulářů v Nette a popíšu ukázku jednoho formuláře. Formulář v Nette je pouze speciální komponentou, nejprve si tedy pojďme říci něco o komponentách. Komponentu lze považovat za samostatný logický prvek na webové stránce. Komponentou tak může být například formulář, stránkování nebo třeba vykreslování nějaké speciální tabulky. Komponenta se do jisté míry chová podobně jako presenter, mimo jiné také protože presenter samotný dědí od komponenty, takže každý presenter je vlastně komponentou. To také znamená, že je možné komponenty zanořovat do sebe. Nejčastější použití komponent je právě na formuláře, které jsou ve frameworku Nette velmi dobře vyřešené. Každý formulář 40