Fulltextové vyhledávání v online katalogu zakázník

eské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

Bakalá ská práce

Fulltextové vyhledávání v online katalogu zakázník Petr Dvo ák

Vedoucí práce: Ing. Klíma Martin, Ph.D.

Studijní program: Softwarové technologie a management, Bakalá sk˝ Obor: Softwarové inûen˝rství 23. kv tna 2012

iv

v

Pod kování Na tomto míst bych rád pod koval Ing. Martinu Klímovi za cenné rady p i psaní této práce a Tomáöi Sm lému – externímu zadavateli – za konstruktivní p ístup.

vi

vii

Prohláöení Prohlaöuji, ûe jsem práci vypracoval samostatn a pouûil jsem pouze podklady uvedené v p iloûeném seznamu. Nemám závaûn˝ d vod proti uûití tohoto ökolního díla ve smyslu §60 Zákona . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorsk˝m a o zm n n kter˝ch zákon (autorsk˝ zákon).

V P ezleticích dne 23. 5. 2012

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

viii

Abstract Design and implement a system enabling full text search of the commercial catalog in the field of materials for the garden using the web interface. Design and implement content management system that will complement the search for the possibility of writing articles, registration of new customers and advertising operations. Search will take into account a number of parameters such as customer activity, paid advertising, promotions, date of registration, etc. Test it with appropriate method.

Abstrakt Navrhn te a implementujte systém umoû ující fulltextové vyhledávání pomocí webového rozhraní nad komer ním katalogem v oboru materiál pro zahradu. Navrhn te a implementujte redak ní sytém, kter˝ bude vyhledávání dopl ovat o moûnost psaní lánk , registraci nov˝ch zákazník a provoz inzerce. Vyhledávání bude brát v úvahu adu parametr , jako je aktivita zákazníka, placená inzerce, promo akce, datum registrace, atd. Systém otestujte vhodnou metodou.

ix

x

Obsah 1 Úvod 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Prost edek k dosaûení cíle . . . . . . . . . . . . . . . . . . . . . . . . 2 Anal˝za 2.1 V˝chozí situace . . . . . . . . . . . . . 2.2 Funk ní poûadavky . . . . . . . . . . . 2.2.1 Role neregistrovan˝ návöt vník 2.2.2 Role registrovan˝ uûivatel . . . 2.2.3 Role administrátor . . . . . . . 2.3 Nefunk ní poûadavky . . . . . . . . . . 2.4 Vyhledávání . . . . . . . . . . . . . . . 2.4.1 Oblasti vyhledávání . . . . . . . 2.4.2 Kritéria vyhledávání . . . . . . 2.4.3 Rating . . . . . . . . . . . . . . 2.4.4 Fulltext . . . . . . . . . . . . . 2.4.4.1 Like . . . . . . . . . . 2.4.4.2 Index . . . . . . . . . 2.4.4.3 Vestav né . . . . . . . 2.4.4.4 Samostatné . . . . . . 2.4.4.5 P esnost vyhledávání . 2.4.4.6 Stemming . . . . . . . 2.4.4.7 Lemmatizace . . . . . 2.4.4.8 Webové vyhledava e . 2.5 Existující eöení . . . . . . . . . . . . . 2.5.1 Frameworky . . . . . . . . . . . 2.5.2 Porovnání vyhledávacích stroj 2.5.2.1 Lucene . . . . . . . . . xi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 1 1 1 3 3 3 3 5 6 8 8 8 9 9 9 10 10 11 11 12 12 12 12 13 13 13 14

xii

OBSAH

2.6

2.5.2.2 Solr . . . . . . 2.5.2.3 Sphinx Search . 2.5.2.4 Elastic Search . Platformy . . . . . . . . . . . . 2.6.1 Opera ní systém . . . . 2.6.2 Nároky na hosting . . . 2.6.3 Diagram nasazení . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 Návrh 3.1 Architektura . . . . . . . . . . . . . . . . . 3.1.1 Model . . . . . . . . . . . . . . . . 3.1.2 View . . . . . . . . . . . . . . . . . 3.1.3 Presenter . . . . . . . . . . . . . . 3.1.4 Moduly . . . . . . . . . . . . . . . 3.2 Pouûité technologie . . . . . . . . . . . . . 3.2.1 Nette Framework . . . . . . . . . . 3.2.1.1 Lad ní . . . . . . . . . . . 3.2.1.2 Formulá e . . . . . . . . . 3.2.1.3 Routování a tvorba odkaz 3.2.2 Dibi . . . . . . . . . . . . . . . . . 3.2.3 Sphinx Search . . . . . . . . . . . . 3.3 Návrh eöení n kter˝ch funk ních problém 3.3.1 Vyhledávání . . . . . . . . . . . . . 3.3.2 Správa kategorií . . . . . . . . . . . 3.3.3 lánky . . . . . . . . . . . . . . . . 3.4 Deployment . . . . . . . . . . . . . . . . . 3.5 Datov˝ model . . . . . . . . . . . . . . . . 3.5.1 Kategorie . . . . . . . . . . . . . . 3.5.2 Redak ní systém . . . . . . . . . . 3.5.3 Zápisy . . . . . . . . . . . . . . . . 3.6 Frontend . . . . . . . . . . . . . . . . . . . 3.6.1 CSS . . . . . . . . . . . . . . . . . 3.6.1.1 LESS . . . . . . . . . . . 3.6.1.2 Twitter Bootstrap . . . . 3.6.2 HTML . . . . . . . . . . . . . . . . 3.6.3 Javascript . . . . . . . . . . . . . . 3.6.4 Grafika . . . . . . . . . . . . . . . 3.6.4.1 Cufón . . . . . . . . . . .

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

14 14 14 15 15 15 16

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

17 17 17 18 18 18 18 18 19 19 19 20 21 22 22 22 22 23 24 25 25 25 26 26 26 27 27 27 28 28

OBSAH

xiii

4 Implementace 4.1 Konkrétní poûadavky na systém . . . 4.2 Implementa ní zajímavosti . . . . . . 4.2.1 P ístup k modelov˝m t ídám 4.2.2 Ohodnocování firem . . . . .

. . . .

29 29 30 30 30

. . . . . .

33 33 33 33 33 34 36

6 Záv r 6.1 Budoucí práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 37

A Seznam pouûit˝ch zkratek

41

B P vodní podoba stránek

43

C Nová podoba stránek

45

D Datov˝ diagram

49

5 Testování 5.1 Beta testování . . . . . . . . 5.2 Nette\Diagnostics\Debugger 5.3 Testování v˝konu . . . . . . 5.3.1 Nette debugger bar . 5.3.2 Apache stress test . . 5.4 Shrnutí testování . . . . . .

E Instala ní a uûivatelská E.1 Instalace . . . . . . . E.2 Konfigurace . . . . . E.3 Spuöt ní . . . . . . . F Obsah p iloûeného CD

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

p íru ka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53 53 53 55

xiv

OBSAH

Seznam obrázk 2.1 2.2 2.3 2.4 2.5 2.6

Role v systému a jejich generalizace . . . . . . . . . . . . . . . . . . P ípad uûití pro roli neregistrovan˝ návöt vník . . . . . . . . . . . . P ípad uûití pro roli registrovan˝ uûivatel . . . . . . . . . . . . . . . P ípad uûití pro roli administrátor . . . . . . . . . . . . . . . . . . . Porovnání rychlosti operátoru LIKE a fulltextového vyhledávání rela báze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . ní data. . . . . . . . . .

4 5 6 7 10 16

3.1 3.2

Architektura Model–View–Presenter v Nette Frameworku . . . . . . . . . . . Architektura Model–View–Controller . . . . . . . . . . . . . . . . . . . . . .

17 18

5.1

Nette debugger bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

B.1 P vodní vzhled stránek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

C.1 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2 V˝sledky vyhledávání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.3 Profil firmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46 47 48

F.1 Obsah p iloûeného CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

Seznam tabulek 2.1 2.2 2.3

Porovnání fulltextového vyhledávání databáze MySQL a samostatného vyhledávacího stroje Sphinx. 7,5GB dat . . . . . . . . . . . . . . . . . . . . . . . . Porovnání vyhledava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Srovnání n kter˝ch funkcí vyhledava . . . . . . . . . . . . . . . . . . . . .

xv

11 13 15

xvi

SEZNAM TABULEK

Kapitola 1 Úvod 1.1

Motivace

Tato práce vznikla na základ poûadavku externí firmy – Hortiflora s.r.o., která je od roku 1991 vydavatelem katalog firem pro obor okrasného zahradnictví a vöechny související obory. Vlastní a systematicky udrûuje oborovou databázi – cca 5 000 zápis . Dále udrûuje web www.hortiflora.cz s vöeobecn˝m informa ním servisem pro okrasné zahradnictví. Tém 100% p íjmu spole nosti plyne z placené inzerce v tiöt n˝ch katalozích.

1.2

Cíle

Hlavním cílem je zásadním zp sobem zv˝öit podíl trûeb plynoucích z reklamy na www.hortiflora.cz, resp. postupn p evést trûby plynoucí z tiöt n˝ch katalog na web.

1.2.1

Prost edek k dosaûení cíle

Vybudování nového portálu www.hortiflora.cz, kter˝ bude pro oborovou ve ejnost slouûit jako centrální vyhledava – jako nap . vyhledava Google pro öirokou ve ejnost a oborové informa ní médium. Aby se portál stal centrálním vyhledava em, musí: • B˝t sám úsp ön vyhledáván na obecn˝ch vyhledava ích (Google, Seznam) pro klí ová slova z oboru okrasného zahradnictví. • Nabídnout uûivatel m co nejrelevantn jöí v˝sledky hledání. • Nabídnout uûivatel m öirokou ökálu aktuálních informací ze sledovan˝ch obor . 1

2

KAPITOLA 1. ÚVOD

Kapitola 2 Anal˝za 2.1

V˝chozí situace

V dob , kdy firma oslovila fakultu s poûadavkem na vytvo ení nového informa ního portálu, m la jiû na adrese www.hortiflora.cz b ûící webové stránky (jejich podoba je k vid ní v p íloze na obrázku B.1), které sestávaly z jednoduchého redak ního systému a nahlíûení do katalogu firem zab˝vajících se okrasn˝m zahradnictvím a p íbuzn˝mi obory. Tento systém byl ale velice nefunk ní a nespl oval nároky, které na n j firma m la, a proto bylo nutné vytvo it portál nov˝. Velk˝m problémem byla nutnost katalog firem na web importovat, tudíû nebyla databáze na webu nikdy zcela aktuální. Jako datové úloûiöt pouûívala firma Microsoft Access databázi, vöe tedy fungovalo offline na po íta ích administrátorek. V systému budeme rozliöovat celkem t i role. První bude b ûn˝ neregistrovan˝ návöt vník stránek. Druhou rolí bude registrovan˝ uûivatel, tzn. firma, která si bude spravovat svoje data v katalogu. T etí rolí bude administrátor, kter˝ bude mít kontrolu nad vöemi katalogy a redak ním systémem.

2.2 2.2.1

Funk ní poûadavky Role neregistrovan˝ návöt vník

1. Uûivatel zadá hledanou frázi a systém mu nabídne v˝sledky hledání. 2. Vyhledava bude brát v potaz vlastnosti eského jazyka. Bude schopen zobrazit odpovídající v˝sledky i pro slova, která nejsou v základním tvaru. 3

4

KAPITOLA 2. ANAL›ZA

Obrázek 2.1: Role v systému a jejich generalizace

3. V˝sledky hledání nabídne vyhledava na jedné obrazovce ve t ech hledacích reûimech – po adí firem ve v˝sledku hledání je definováno odliön˝mi prioritami pro jednotlivé reûimy. Priority definuje portál – uûivatel nemá moûnost do nich zasáhnout. 4. Portál uûivateli p ednostn nabídne firmy s aktualizovan˝mi údaji, inzerující firmy atp. 5. Vyhledava nabídne moûnost rozöí eného vyhledávání podle katalogu, obchodního modelu a okresu. 6. Návöt vník bude moci nahlíûet do ve ejn˝ch profil firem. 7. Návöt vník se bude moci zaloûit nov˝ ú et. 8. Návöt vník s existujícím ú tem se bude moci p ihlásit. 9. Portál nabídne uûivateli aktuální informace na homepage a v sekcích: • inzerce práce,

2.2. FUNK NÍ POéADAVKY

5

Obrázek 2.2: P ípad uûití pro roli neregistrovan˝ návöt vník

• veletrhy, v˝stavy, konference, • práv vychází – periodika, • práv vychází – knihy, • spolky a svazy, • ökoly,

• zpravodaj – firemní lánky, • dotace, • apod.

2.2.2

Role registrovan˝ uûivatel

1. Firma bude moci zapsat údaje do databáze a zve ejnit údaje na portálu. 2. Firma bude moci aktualizovat údaje v databázi, tj. opravit údaje na portálu. 3. Firma bude moci objednat zve ejn ní údaj z databáze do tiöt ného katalogu. 4. Trvalé zve ejn ní údaj je podmín no dodate n˝m schválením údaj administrátorem – tj. vöechny zm ny v DB jdou p es administraci portálu.

6


Obrázek 2.3: P ípad uûití pro roli registrovan˝ uûivatel

5. Opravuje-li nebo registruje-li uûivatel – firma údaje, musí mít moûnost zvolit: • od kdy chce údaje zve ejnit

• pro jakou úrove údaje uvádí (bezplatn˝ zápis, placen˝ zápis bez inzerce, placen˝ zápis s inzercí) 6. Prost ednictvím standardního formulá e musí mít uûivatel – firma moûnost publikovat lánek – zaslat text, foto, text k foto, dopl ující komentá , poûadované datum zve ejn ní (nejmén aktuální datum + 7 dn )

2.2.3

Role administrátor

1. Administrátor musí mít moûnost nahlíûet, upravovat a schvalovat uûivatelem zapsaná data do databáze nebo sám data zapisovat 2. V systému musí b˝t evidovány údaje vztahující se k zápis m do DB: • datum, identifikace uûivatele • schváleno / neschváleno

2.2. FUNK NÍ POéADAVKY

7

Obrázek 2.4: P ípad uûití pro roli administrátor

• datum, identifikace schvalovatele 3. Administrátor musí b˝t automaticky informován o vloûení dat ze strany uûivatele 4. Portál bude evidovat odkazy na obrazovou inzerci (vûdy je vztaûena ke konkrétnímu placenámu zápisu) 5. Portál musí mít moûnost p es uûivatelské rozhraní definovat kategorie podkategorie hlavního katalogu (hortiflora registr) i speciál (hortiflora registr speciál) 6. Prost ednictvím standardního formulá e musí mít portál moûnost vkládat reklamní bannery na p edem ur ené pozice 7. Prost ednictvím redak ního systému musí mít administrátor moûnost vkládat lánky, obrázky a odkazy do sekcí, v . jednoduché typografické úpravy – p edvolené styly apod. a dopl kov˝ch funkcí

8

KAPITOLA 2. ANAL›ZA 8. Prost ednictvím redak ního systému musí mít administrátor moûnost p ehledn t ídit lánky a obrázky 9. Prost ednictvím redak ního systému musí mít administrátor moûnost vytvá et nové sekce / ruöit staré 10. Z databáze musí b˝t moûno standardn importovat data do InDesignu pro p ípravu tiöt n˝ch katalog .

2.3

Nefunk ní poûadavky

1. Administrace hesel musí b˝t uûivatelsky p ív tivá. 2. Datová vrstva bude p evedena z MS Access databáze do jiné databáze vhodné pro nasazení na web. 3. Technologie musí b˝t zvolena s ohledem na p ípadné pokra ování jin˝m programátorem. 4. Databáze musí mít alespo jednou denn zálohována.

2.4

Vyhledávání

Vzhledem k tomu, ûe vyhledávání na portálu byla zákazníkem poptávána jako jedna ze zt ûejních funkcionalit, rozhodl jsem se ji v novat jednu kapitolu.

2.4.1

Oblasti vyhledávání

Poûadavkem zákazníka bylo vytvo it vyhledávání, které bude fungovat podobn jako Google, nad celou databází, nebo alespo tam, kde to dává smysl. Coû znamená, ûe vyhledávat se bude zejména nad mnoûinou vöech firem a p idruûen˝mi entitami (telefony, emaily, provozovny, zápisy, adresy atd.). Dalöí velkou oblastí vyhledávání je cel˝ redak ní systém. Vyhledávat se tedy bude jeöt v láncích a aktualitách.

2.4. VYHLEDÁVÁNÍ

2.4.2

9

Kritéria vyhledávání

Kritéria vyhledávání se mohou zdát z ejmá, ale v tomto p ípad se v˝sledky ne adí jen dle relevance, jak je tomu na v töin webov˝ch stránek zvykem. Poûadavkem bylo, aby se do po adí firem ve v˝sledcích vyhledávání promítl i jak˝si rating neboli ohodnocení firmy, které udává hodnotu zápisu firmy v databázi (neautorizovan˝ zápis, bezplatn˝ zápis, placen˝ zápis, placen˝ zápis s inzercí). Dalöími parametry ovliv ující po adí v˝sledk vyhledávání jsou: celková cena zápisu a inzerce (draûöí má p ednost), datum zve ejn ní (mladöí má p ednost) a nakonec abecední azení názvu firmy.

2.4.3

Rating

Na ratingu ili hodnocení firmy je zaloûena velká ást business modelu spole nosti Hortiflora. Jak jiû bylo e eno, rating rozhoduje o po adí ve v˝sledcích vyhledávání (ostatní parametry se uplatní aû p i jeho shodnosti), proto jsou firmy motivovány platit kaûdoro n placen˝ zápis, objednávat inzerci, promo akce atd. Krom zv˝hodn ného po adí ve vyhledávání se platící firma dostane i do tiöt ného katalogu, kter˝ vychází jednou ro n a ze kterého plynula doposud v töina p íjmu spole nosti. Zájímav˝ je ovöem dopad pro návöt vníka stránek, kter˝ chce vyhledat n jaké klí ové slovo. Vyhledava mu totiû nenabízí co moûná nejrelevantn jöí v˝sledky na prvních místech, ale v˝sledky, které alespo áste n odpovídají hledanému v˝razu a t˝kají se firem, které mají vysok˝ rating a hodne utrácí. Z tohoto modelu tedy t ûí hlavn dob e platící firmy, spole nost Hortiflora, mén pak koncov˝ uûivatel.

2.4.4

Fulltext

Fulltextové vyhledávání je speciální druh vyhledávání v textov˝ch dokumentech nebo SQL databázích i v jin˝ch textov˝ch datech. Setkat se s ním m ûeme prakticky vöude – od vyhledávání soubor na disku p es vyhledávání v textov˝ch procesorech aû po vyhledávání v rela ních a nerela ních databázích [4]. U tohoto typu vyhledávání se postupn prohledávají vöechny slova kaûdého dokumentu a testuje se shoda s vyhledávanou frází. Shodou v tomto p ípad nemyslíme úplnou rovnost, nap íklad jin˝ tvar téhoû slova bude rovn û vyhodnocen jako shoda. P i malém mnoûství dokument posta í prohledávat originální dokument p i kaûdém dotazu. V ostatních p ípadech je toto ale neúnosné z hlediska v˝konu, a proto je nutné vytvá et tzv. index. Z toho plyne, ûe neû m ûeme za ít vyhledávat, musíme nejd íve vytvo it index a udrûovat ho co moûná nejvíce aktuální.

10 2.4.4.1

KAPITOLA 2. ANAL›ZA Like

V SQL databázích m ûeme pro vyhledávání pouûít také operátor LIKE. Je vöak nutné si uv domit, ûe v tomto p ípad se nejedná o fulltextové vyhledávání, ale o pouhé hledání textové shody v jednom dlouhém textovém et zci. Neumoû uje tedy ûádnou lexikologickou anal˝zu. P i v töím mnoûství záznam je také oproti fulltextu pomalé, jak ukazuje obr. 2.5.

Obrázek 2.5: Porovnání rychlosti operátoru LIKE a fulltextového vyhledávání rela ní databáze, zdroj: [2]

2.4.4.2

Index

K zajiöt ní rychlého vyhledávání i ve velkém mnoûství dokument , je nutné tyto dokumenty nejd íve p edzpracovat a uloûit do speciální datové struktury – indexu. Vnit í reprezentace indexu je zna n sloûitá a závisí na implementaci konkrétního indexovacího stroje. Veskrze obsahuje r zné hashovací tabulky, prefixové a sufixové vyhledávací stromy a podobn . V˝sledná datová velikost indexu je asto mnohonásobn v töí neû velikost p vodních textov˝ch dat. To zejména p i pouûívání hledání v pod et zcích (operátor hv zdi ka), kdy je nutno kaûdé slovo rozkouskovat po n kolika písmenech a uloûit do indexu vícekrát. Dále se do indexu ukládá indexovací stroj dalöí pomocná metadata, která urychlují vyhledávání, ale zvyöují datovou náro nost. P i startu vyhledávacího stroje se typicky na te index do opera ní pam ti.

2.4. VYHLEDÁVÁNÍ

operátor LIKE fulltext MyISAM fulltext InnoDB Sphinx Search

11 vytvo ení indexu 0 53:28 39:25 n/a

vloûení do indexu 0 52:28 63:04 9:56

velikost 0 2310MB 2545MB 3487MB

dotaz 101000ms 3-150ms 306-691ms 16ms

Tabulka 2.1: Porovnání fulltextového vyhledávání databáze MySQL a samostatného vyhledávacího stroje Sphinx. 7,5GB dat, zdroj: [9] Indexy a vyhledávací enginy obecn m ûeme rozd lit na dva typy – vestav né a samostatné. Jak ukazuje tabulka 2.1, samostatné stroje jsou p i v töím po tu dat nedostiûné.

2.4.4.3

Vestav né

Index najdeme v b ûn pouûívan˝ch rela ních databázích celou adu. Nejznám jöí je bezesporu primární index neboli primární klí , dále unikátní index nebo vedlejöí index. Nás ale bude nejvíce zajímat fulltextov˝ index. Nap íklad v rela ní databzí MySQL vytvo íme index následovn [3]: CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [index_type] ON tbl_name (index_col_name,...) index_col_name: col_name [(length)] [ASC | DESC] index_type: USING {BTREE | HASH}

Fulltextové vyhledávání v MySQL m ûeme pouûít tam, kde jiû operátor LIKE nesta í. Má vöak svá úskalí, a proto není v praxi p íliö vyuûíváno. V esko-slovensk˝ch vodách je nejv töím problémem nepodpora oh˝bání slov a öpatná práce s diakritikou (dle zvoleného kódování). Aû do verze MySQL 5.6.4 byl dostupn˝ fulltextov˝ index pouze u tabulek enginu MyISAM, od verze 5.6.4 ho m ûeme pouûít i u tabulek InnoDB [9]. V MySQL fulltextu nelze ani vytvo it index z více neû jedné tabulky. 2.4.4.4

Samostatné

Samostatné vyhledávací stroje jsou trvale b ûící sluûby (podobn jako databázov˝ stroj), o které se musíme starat nezávisle na databázi. V závislosti na typu indexovacího stroje je musíme plnit daty bu jiû p i ukládání do databáze (real time index) nebo data periodicky

12


dumpovat z databáze a posílat indexeru. Odm nou nám bude mimo ádn˝ v˝kon v porovnání s vestav n˝mi indexy v databázích a podpora pokro il˝ch funkcí. 2.4.4.5

P esnost vyhledávání

V töina vyhledávacích stroj umoû uje do jisté míry ladit parametry vyhledávání tak, abychom dosáhli co nejp esn jöích v˝sledk a zárove aby se zbyte n nevy azovaly ty relevantní. K zp esn ní v˝sledk slouûí nap íklad tzv. stop words. To jsou slova, která se neza azují do indexu, protoûe nenesou ze sémantického hlediska v˝znam. Pat í mezi n nap íklad p edloûky nebo anglick˝ len the apod. Minimální délku slov, která se budou indexovat m ûeme také omezit, v töinou to b˝vají t i znaky. 2.4.4.6

Stemming

Abychom ve v˝sledcích naopak získali i dokumenty, které obsahují slova v jiném neû základním tvaru (infinitiv, 1. pád podst. jm.,. . . ), podporuje v töina vyhledáva tzv. stemming. Tato operace vrací pro asované, odvozené nebo vysklo ované slovo jeho ko en. P i stemmingu se odstraní morfologické koncovky a p edpony, nap . ne-. Stejn˝m zp sobem se musí p ed vyhledáváním oöet it i hledané slovo a teprve poté se testuje shoda. Velk˝m problémem jsou ale slova, která p i sklo ování m ní sv j kmen. 2.4.4.7

Lemmatizace

Lepöí metodou je tzv. lemmatizace, coû je p evod slov na základní (slovníkov˝) tvar (nikoliv kmenov˝ tvar jako u stemmingu). V angli tin jsou v˝sledky t chto metod stejné, v eötin nikoliv. Problém je, ûe lemmatizace je dosti pokro ilá metoda, kterou pouûívají hlavn velké internetové vyhledava e a voln dostupné vyhledávací stroje pro nasazení na vlastní projekty ji nepodporují. Lemmatizaci podporuje nap íklad Jyxo, Morfeo a samoz ejm Seznam.cz a Google [8]. 2.4.4.8

Webové vyhledava e

Je t eba si uv domit, fulltextová sloûka vyhledávání je pouze malou ástí sloûit˝ch algoritm , kter˝mi internetové vyhledava e typ Google disponují. Pokud by byl takov˝ vyhledava zaloûen pouze na fulltextu, byl by vzhledem k mnoûství shromaû ovan˝ch dat naprosto nepouûiteln˝. Za podobu moderních vyhledava vd íme zejména pán m Larrymu Pageovi a Sergeyi Brinovi, kte í p iöli v roce 1998 s myölenkou ohodnocování webov˝ch stránek podle po tu

2.5. EXISTUJÍCÍ

EäENÍ

Rok vzniku Licence Jazyk Opera ní systém

Lucene 1999 Apache 2.0 Java n/a

13 Solr 2004 Apache 2.0 Java Cross-platform

Elastic Search 2010 Apache 2.0 Java Cross-platform

Sphinx Search 2001 GPLv2 C++ Linux, Solaris, FreeBSD, NetBSD, Mac OS, AIX

Tabulka 2.2: Porovnání vyhledava odkaz , které na ni vedou a také hodnocení t chto odkazujících stránek. Toto ohodnocení se naz˝vá PageRank a stalo se ochrannou známkou spole nosti Google.

2.5

Existující eöení

Jiû v prvních fázích projektu bylo z ejmé, ûe se bude muset vytvo it na míru podle p ání zadavatele. Zadání je natolik specifické, ûe existující eöení zkrátka neexistuje. Nicmén nejprve se zdálo, ûe budu moci pouûít n kter˝ z redak ních systém (Drupal, Wordpress), ale i poûadavky na n j byly dosti specifické. Proto bylo v˝hodn jöí ho naprogramovat tzv. „from the scratch“, coû nakonec zabralo mén asu, neû oh˝bání Wordpressu i Drupalu.

2.5.1

Frameworky

Vzhledem k tomu, ûe jeden z poûadavk byl, aby po mn mohl aplikaci p evzít jin˝ programátor, bylo nejlepöí vybírat z PHP framework . T ch se nabízí celá ada. Mezi nejznám jöí pat í ur it Zend Framework, Kohana, Cakephp nebo Nette Framework. Poslední jmenovan˝ má velkou v˝hodu, ûe je eského p vodu a je u nás nejvíce rozöí en˝, nyní má jiû dobrou dokumentaci a aktivní komunitu.

2.5.2

Porovnání vyhledávacích stroj

Hned v po átcích práce na aplikaci jsem musel prozkoumat, které open source vyhledavací enginy jsou k dispozici. Vybral jsem ty i nejpouûívan jöí a pokusil se je porovnat. Jak ukazuje tabulka 2.2, t i z nich jsou napsány v jazyce Java. To je z toho d vodu, ûe Solr i Elastic Search jsou postaveny nad Lucene a vyuûívají tak vöech jeho v˝hod. Tabulka 2.3 pak obsahuje srovnání n kter˝ch funkcí vyhledava .

14 2.5.2.1

KAPITOLA 2. ANAL›ZA Lucene

Lucene se liöí od ostatních vyhledava – nejedná se totiû o aplikaci, kterou bychom mohli nainstalovat a pouûívat, n˝brû o knihovnu, kterou nejprve musíme do své aplikace za lenit. To je v˝hodné pro programy psané v Jav , pro PHP je to problém. Existují ale porty do jin˝ch jazyk (Delphi, Perl, C#, C++, Python, Ruby a PHP). PHP port se jmenuje Zend Lucene. Tyto porty jsou ale asto problematické, nedolad né a vûdy zaostávají za hlavní v˝vojovou v tví. Vzhledem ke svému stá í má Lucene velkou uûivatelskou základnu. 2.5.2.2

Solr

Solr je stejn jako Lucene napsán v Jav a b ûí uvnit servlet kontejneru jako je nap íklad Tomcat. Solr má REST HTTP/XML a JSON API, a proto je snadné ho pouûívat z jakéhokoliv programovacího jazyka. M ûeme do n j ukládat dokumenty ve form XML, JSONu nebo binárních dat p es HTTP protokol. Dotazujeme se pomocí metody GET a jsou nám navráceny v˝sledky v XML, resp. JSONu, resp. binárn . Solr se konfiguruje pomocí XML soubor a m ûeme jej ovládat a spravovat pomocí webového administra ního rozhraní. Je také jednoduöe rozöi iteln˝ pomocí plugin . Zajímavostí je moûnost indexovat proprietární formáty jako PDF nebo Microsoft Word. Jiû v základu obsahuje spellchecker. 2.5.2.3

Sphinx Search

Sphinx se od ostatních zna n liöí. Vznikl krátce po Lucene a nemá s ním nic spole ného. Není napsán v Jav , ale v C++ a naprosto exceluje ve v˝konu. Nejzajímav jöí je ovöem úzka vazba na rela ní databáze (momentáln MySQL, PostgreSQL a databáze podporující ODBC). Indexer se sám p ipojí k databázi a pomocí SQL dotazu si vyexportuje pot ebná data a ty zindexuje a uloûí. Ostatní zdroje m ûeme indexovat v XML formátu. V˝sledky vyhledávání dostaneme stejn jako z rela ní databáze v result setu, coû velmi usnad uje práci. Pro práci s vyhledava em máme k dispozici knihovnu v PHP a od verze 0.9.9 i tzv. SphinxQL, coû je podmnoûina SQL [1]. Pomocí tohoto SQL dialektu se dotazujeme serveru velice podobn jako klasické databáze a m ûeme vyuûít i nap íklad MySQLi nebo PDO i jinou Database Abstraction Layer. 2.5.2.4

Elastic Search

Elastic Search je na poli open source vyhledava úpln˝ nová ek. Sv tlo sv ta spat il v roce 2010 a jeho autorem je Shay Banon. Stejn jako Solr je postaven nad Lucene a je psán v

2.6. PLATFORMY

Typ Rozhraní Vyûadováno schéma Vno ené dokumenty Distribuované vyhledávání Distribuované indexování Uûivatelská základna

15 Lucene Knihovna Java Ano Ne n/a n/a Velká

Solr Server Java, REST Ano Ne Ano Ne V töí

Sphinx Server SQL Ano Ne Ano Ne V töí

Tabulka 2.3: Srovnání n kter˝ch funkcí vyhledava

Elastic search Server Java, REST Ne Ano Ano Ano Malá

[10]

Jav . Je distribuovan˝ a velice dob e ökálovateln˝. Komunikace probíha obousmern pomocí JSON dat p es RESTful HTTP. Narozdíl od Sphinx má naprosto volné schéma a m ûeme do n j ukládat prakticky cokoliv. Domnívám se, ûe v sou asné dob je Elastic Search nejlépe vybaven˝ vyhledávací stroj, nicmén kolem n j probíhá bou liv jöí v˝voj a nev˝hodou je, ûe má pouze jednoho hlavního v˝vojá e. Ukázka vloûení a získání dokumentu: curl -XPUT http://localhost:9200/twitter/tweet/2 -d ’{ "user": "kimchy", "post_date": "2009-11-15T14:12:12", "message": "You know, for Search" }’ curl -XGET http://localhost:9200/twitter/tweet/2

2.6 2.6.1

Platformy Opera ní systém

P i volb opera ního systému vhodného pro provoz webového serveru máme na v˝b r mezi Microsoft Windows nebo systémy typu Unix. Vzhledem k pot eb instalace vyhledávacího stroje Sphinx Search nejsou Windows v bec vhodné. A koliv existují hotové balí ky, vhodn jöí je Sphinx nejprve ru n zkompilovat a nainstalovat. Dob e fungovat bude jist prakticky jakákoliv distribuce Linuxu nebo FreeBSD.

2.6.2

Nároky na hosting

Jiû z nutnosti kompilace a instalace vyhledava e vypl˝vá, ûe pot ebujeme VPS neboli virtual private server s pln˝m rootovsk˝m p ístupem. Ostatní nároky nejsou velké, p i pouûití

16


webovehé serveru Apache a databázového serveru MySQL posta uje p i sou asné velikosti aplikace a návöt vnosti jedno procesorové vlákno, zhruba 512MB opera ní pam ti a alespo 15GB místa na disku pro zálohování apod.

2.6.3

Diagram nasazení

Na obrázku 2.6 vidíme základní model nasazení. Jedná se o klasickou klient-server architekturu (jiû z principu HTTP); webov˝, databázov˝ a vyhledavací server pob ûí na stejném fyzickém stroji. Komunikace probíhá na transportní vrstv p es TCP protokol, na aplika ní vstv poté pomocí HTTP protokol. Na serveru se vyuûívají pro komunikaci mezi databází, vyhledávacím strojem a webov˝m serverem sí ové sockety.

Obrázek 2.6: Diagram nasazení

Kapitola 3 Návrh 3.1

Architektura

Aplikace vyuûívá PHP frameworku Nette, proto jsem nem l p i volb architektury na v˝b r. Jedná se o architekturu MVC, respektive MVP. MVP neboli model-view-presenter je odvozen˝ návrhov˝ vzor od MVC, kter˝ více odpovídá skute né architektu e Nette Frameworku.

Obrázek 3.1: Architektura Model–View–Presenter v Nette Frameworku, zdroj: [6]

3.1.1

Model

Model reprezentuje doménu aplikace. Obsahuje veökerou business logiku a navenek poskytuje pevné rozhraní. Model by o existenci presenteru a view nem l v d t. 17

18

KAPITOLA 3. NÁVRH

Obrázek 3.2: Architektura Model–View–Controller, zdroj: [6]

3.1.2

View

View neboli pohled je vrstva, která p evádí data z modelu do podoby, ve které jseou prezentována uûivateli. Obvykle se jedná o öablonovací systém.

3.1.3

Presenter

Presenter je jak˝si adi , kter˝ je zodpov dn˝ za zpracování poûadavk klienta a kontaktuje model pro získání dat, která dále p edává view pro vykreslení.

3.1.4

Moduly

Aplikace je rozd lena do dvou hlavních ástí (v Nette názvosloví modul ) – AdminModule a FrontModule. Kaûd˝ tento modul obsahuje pouze odpovídající presentery a öablony. Dovoluje nám to p ehledn odd lit uûivatelskou a administra ní ást webu a nemíchat je dohromady. Zp ehled uje to také tvorbu odkaz . Pro oba moduly máme vlastní homepage a m ûeme také implementovat autorizaci a autentifikaci pro kaûd˝ modul odd len .

3.2 3.2.1

Pouûité technologie Nette Framework

Nette je PHP MVP framework, kter˝ je distribuován pod licencí New BSD nebo GNU General Public License ve verzi 2 nebo 3. Nette se snaûí usnadnit práci programátorovi p i

3.2. POUéITÉ TECHNOLOGIE

19

eöení ast˝ch problém a öet it mu tak as pro programování business logiky a nenutit ho znovu vynalézat kolo. Aplikace psané v Nette jsou typicky p ehledn jöí a istöí neû ty, které jsou psané bez frameworku. Nette je v eské republice velice rozöí eno a pouûívají ho v˝znamné spole nosti jako Internet Info, s.r.o., Vltava-Labe-Press nebo Mladá fronta. Nejnov jöí verzí Nette je 2.0.3, která byla vydána 4. 4. 2012 [5]. Zde bych cht l uvést n kolik ástí Nette, které mi nejvíce öet í as: 3.2.1.1

Lad ní

Jednou z velk˝ch p edností Nette Frameworku je jeho debugovací nástroj p ezdívan˝ Lad nka. Nic obdobného jsem doposud v jiném frameworku nevid l. Tento nástroj nám velmi öet i as. Namísto stroh˝ch chybov˝ch hláöek PHP nám servíruje p ehlednou stránku i se zobrazením úryvku kódu, ve kterém se stala chyba. Samoz ejmostí je pln˝ call stack. V produk ním reûimu se p i v˝skytu chyby z pochopiteln˝ch d vod nezobrazuje, místo toho v˝jimky loguje do soubor a informuje o nich administrátora e-mailem. 3.2.1.2

Formulá e

Vytvá ení a zpracování formulá je v Nette velice p kn vy eöeno. Definice formulá e je v presenteru nebo komponent a vykreslujeme ho v latte öablon . Nette se automaticky stará o zabezpe ení vöech formulá p ed útoky XSS, CSRF i Mass Assignment. Umoû uje polí ka formulá e jednoduöe validovat a data z nich dále zpracovávat. 3.2.1.3

Routování a tvorba odkaz

Odkazování v Nette není eöeno standardn na konrétní URL. Místo toho odkazujeme na konkrétní presenter a jeho akci. Podoba URL nás de facto nezajímá. To má v˝hodu, ûe úpravou routovacích pravidel m ûeme v˝slednou podobu URL lehce zm nit kdykoliv se nám zachce. P ehled hlavních vlastností, kter˝mi se na sv˝ch webov˝ch stránkách framework chlubí [7]: • Dokonalé zabezpe ení Nette pouûívá revolu ní technologii, která eliminuje v˝skyt bezpe nostních d r a jejich zneuûití, jako je nap . XSS, CSRF, session hijacking, session fixation atd. Chcete v d t více? • Ladicí nástroje Disponuje bezkonkuren ními ladicími nástroji, které vám pomohou zav asu odhalit vöechny chyby aplikace.

20

KAPITOLA 3. NÁVRH • Exceluje ve v˝konu Dle nezávislého testu je Nette Framework jedním z nejrychlejöích framework v bec. • Nejaktivn jöí komunita v R Nebudete v tom sám! Komunita kolem frameworku radí, vytvá í dopl ky a rozöí ení, sdílí své zkuöenosti. • Strmá k ivka u ení Nau íte se tvo it webové aplikace za velmi krátk˝ as. • Dobré návyky Nette Framework vás vede k istému návrhu aplikace s d razem na budoucí rozöi itelnost. • Moderní framework AJAX / AJAJ, Dependency Injection, SEO, DRY, KISS, MVC, Web 2.0, cool URL – propracovaná podpora vöech moderních technologií a koncepcí. • Vyzrál˝ objektov˝ návrh Promyölen˝ a ist˝ objektov˝ návrh vyuûívající nov˝ch vlastností PHP 5, komponent a událostmi ízeného modelování. • Pluginy a rozöí ení Neustále se rozr stající nabídka dopl k Oce te v˝hody znovupouûitelného kódu.

pro snadné pouûití ve vaöich aplikacích.

• Open-source licence Licence BSD pat í k t m nejvoln jöím. Framework m ûete zdarma pouûívat i v komer ních projektech. • Práce v t˝mu V˝born rozd luje práci mezi více programátor a HTML kodér . • Dává vám volnost Nette Framework vás nijak neomezuje. Dokonce jej lze v˝hodn kombinovat nap íklad se Zend Frameworkem.

3.2.2

Dibi

Dibi je DBAL (database abstraction layer), která je napsaná v PHP. Jejím cílem je uleh it práci p i psaní SQL dotaz a tím eliminovat riziko chyby. Podporuje databáze MySQL, PostgreSQL, SQLite, MS SQL, Oracle, Access, PDO a ODBC. Obsahuje n kolik uûite n˝ch

3.2. POUéITÉ TECHNOLOGIE

21

metod, které nám vrací data z databáze ve form PHP polí. Stará se také o konverzi datov˝ch typ na odpovídající typy databáze. Vöechny vstupy jsou escapovány, coû znemoû uje útok SQL injection. Autorem Dibi je David Grudl.

3.2.3

Sphinx Search

Vzhledem k perfektnímu v˝konu a snadné spolupráci s rela ními databázemi – zejména MySQL – jsem se rozhodl pouûít vyhledava Sphinx Search. Jeho instalace je moûná pomocí debianovského balí ku, jedná se vöak o staröí verzi. Proto jsem volil cestu kompilace. Vyhledava nastavujeme pomocí konfigura ního souboru sphinx.conf. type = mysql sql_host = localhost sql_user = ... sql_pass = ... sql_db = hortiflora sql_port = 3306 sql_sock = /tmp/mysql.sock sql_query_pre = SET NAMES utf8 sql_query = SELECT *, UNIX_TIMESTAMP(posledni_aktualizace) AS " posledni_aktualizace_timestamp", s.ulice AS "s_ulice", s.mesto AS "s_mesto", k. ulice AS "k_ulice", k.mesto AS "k_mesto" FROM firmy LEFT JOIN adresy s ON firmy. adresa_sidla_id = s.id LEFT JOIN adresy k ON firmy.korespondencni_adresa_id = k.id JOIN vyhledavani ON vyhledavani.firma_id = firmy.id AND katalog_id = 1 WHERE deleted = FALSE sql_joined_field = telefony from query; SELECT firma_id, cislo FROM telefony ORDER BY firma_id ASC sql_joined_field = emaily from query; SELECT firma_id, CONCAT_WS(" ", email, poznamka) FROM emaily ORDER BY firma_id ASC sql_joined_field = odpovedne_osoby from query; SELECT firma_id, jmeno FROM odpovedne_osoby ORDER BY firma_id ASC sql_joined_field = webove_adresy from query; SELECT firma_id, url FROM webove_adresy ORDER BY firma_id ASC sql_joined_field = provozovny from query; SELECT firma_id, CONCAT_WS(" ", telefon, fax , email, poznamka, stary_text) FROM provozovny ORDER BY firma_id ASC sql_joined_field = kategorie from query; SELECT firma_id, CONCAT_WS(" ", nazev, komentar) FROM kategorie_modely_firmy JOIN kategorie ON kategorie.id = kategorie_modely_firmy.kategorie_model_kategorie_id AND katalog_id = 1 ORDER BY firma_id ASC ...

Ukázka 3.1: Ukázka ásti konfigura ního souboru vyhledava e Sphinx Samotn˝ vyhledava b ûí jako démon searchd na pozadí. Pro testování a debugování vyhledávání m ûeme pouûít shellovskou utilitu search. Abychom mohli vyhledávat, musíme vyhledava i nejprve nechat zindexovat data z databáze. To provádíme pomocí programu indexer. Je vhodné spouöt t indexer nap íklad pomocí cronu periodicky, abychom m li indexy

22

KAPITOLA 3. NÁVRH

co moûná nejaktuáln jöí. Volba intervalu indexování závisí na konkrétní aplikaci. V mém p ípad jsem volil indexování kaûdou hodinu.

3.3 3.3.1

Návrh eöení n kter˝ch funk ních problém Vyhledávání

Aplikace obsahuje dva typy vyhledávání. Jednoduché a rozöí ené. V˝sledky jedoduchého vyhledávání jsou rozd leny do t í ástí – v˝sledky z hlavního katalogu, v˝sledky z ostatních katalog a v˝sledky z lánk . Tyto t i ásti jsou nezávisle stránkovány. V˝sledky z hlavního katalogu navíc obsahují na prvních pozicích firmy, které mají zaplacené promo. V rozöí eném vyhledávání m ûeme volit poûadovan˝ katalog, kategorie, které chceme, aby m la firma p i azeny, a p ípadn okres, ve kterém firma p sobí. Z implementa ního hlediska je vyhledávání eöeno jedním presenterem a samostatn˝m modelem, kter˝ sdruûuje vöechny metody, které pro dotazování vyhledava e pouûíváme. Vzhledem k tomu, ûe vyhledava je moûné dotazovat pomocí podmnoûiny SQL, rozhodl jsem se pro to pouûít knihovnu Dibi, která je pouûívána i pro komunikaci s MySQL databází.

3.3.2

Správa kategorií

Kategorie kaûdého katalogu jsou organizovány do b ûné stromové struktury. V databázi jsou navrûeny pomocí jedné tabulky a vazby sama na sebe. Kaûdá kategorie má jeöt vazbu na obchodní model. Velk˝m o íökem bylo, jak navrhnout správu t chto kategorií tak, aby byla uûivatelsky p ív tivá. Vzhledem k tomu, ûe editaci m ûe provád t jen n kolik administrátor , rozhodl jsem se rezignovat na p ístupnost této ásti s vypnut˝m javascriptem. Editace kategorií zaloûená na javascriptu je velice snadná a u administrátor se dá p edpokládat JS zapnut˝. Kategorie jsou vykresleny jako vno ovan˝ ne íslovan˝ odráûkov˝ seznam. U kaûdé kategorie jsou ty i checkboxy pro obchodní modely. Kategorie m ûeme uchopením a taûením myöi libovoln p esouvat (drag&drop). Úpravu názvu provedeme dvojklikem. D leûité je, ûe po kaûdé zm n se provede asynchronní AJAXov˝ dotaz pro uloûení aktuálního stavu. Zm ny tedy nemusíme potvrzovat tla ítkem jako p i pouûití formulá .

3.3.3

lánky

Dlouho jsem se rozhodoval, jak˝ zvolit editor pro psaní lánk . Nabízí se plejáda WYSIWYG editor (nejznám jöí TinyMCE, CKEditor), nebo n které zna kovací jazyky pro formátování textu. Oba p ístupy mají sv v˝hody a nev˝hody.

3.4. DEPLOYMENT

23

WYSIWYG editory jsou jist jednoduööí a intuitivn jöí na pochopení. Uûivatelé jsou na n zvyklí z textov˝ch procesor jako je Microsoft Word. Na druhou stranu HTML kód, kter˝ tyto editory generují, je asto nevalidní a navíc n kdy není ani well formed (obsahuje p ek íûené tagy apod.). To m ûe mít za následek celkové rozpadnutí stránky. Zna kovací jazyky pro formátování textu, tabulek a obrázk jsou pro laiky pravd podobn zprvu h e stravitelné. Existují ale javascriptové editory, které jsou podobné t m WYSIWYGov˝m. Nap íklad tu né písmo v nich ovöem nevidíme tu n , ale text nám obalí do p ísluön˝ch zna ek. Uûivatel si je tedy nemusí pamatovat. V˝hodou zna kovacích jazyk , jako je Markdown, Textile nebo Texy!, je jejich flexibilita a perfektní v˝stup. Nakonec jsem se rozhodl pouûít nástroj Texy!, kter˝ je implementován v jazyce PHP. Jeho syntaxe je podle mého názoru velmi intuitivní a p ehledná.

3.4

Deployment

Jedna z nej ast jöích obtíûí, které lidé p i v˝voji webov˝ch aplikací elí, je jejich nasazování na produk ní server. Zejména v PHP sv t je stále b ûné soubory ru n kopírovat na server p es FTP. To je nejenom pomalé, ale zárove se zvyöuje riziko, ûe na n kter˝ zm n n˝ soubor zapomeneme. Naöt stí existují sofistikovan jöí eöení jako je Capistrano, které jsem se rozhodl pouûít já. Capistrano je opensourcov˝ nástroj pro spouöt ní skript na vzdálen˝ch servrech. Jeho hlavním uûitím je nasazování aplikací. Umoû uje nám automatizovat proces vytvá ení nov˝ch verzích aplikace, které jsou dostupné na jednom i více webov˝ch servrech. Je napsané v Ruby a stalo se de facto standardem pro deployment Ruby on Rails aplikací. Distribuováno je pomocí tzv. RubyGems, coû je obdoba distribu ního kanálu PEAR v PHP. M ûe b˝t vöak pouûito i pro deploy aplikací, které nejsou psány v Ruby a frameworku Ruby on Rails, a proto ho za le ují i n které PHP frameworky. Capistrano je ovládáno pouze z p íkazové ádky, existuje ale nástavba Webistrano, která zp ístup uje ovládání p es webové rozhraní. Základní premisou je, ûe kód aplikace je verzován pomocí systému GIT nebo SVN. Capistrano se p es SSH p ipojí na server, kód si z GIT/SVN repozitá e stáhne, provede p edem definované kroky a vytvo í z n j novou verzi aplikace. Vöe je naprosto p izp sobitelné a skriptovatelné. Capistrano se p vodn jmenovalo SwitchTower, ale bylo v roce 2006 p ejmenováno kv li potíûím s ochrannou známkou.

24

KAPITOLA 3. NÁVRH

require ’capistrano_colors’ set :stages, ["staging", "production"] set :default_stage, "production" require ’capistrano/ext/multistage’ set :application, "hortiflora" server "hortiflora.cz", :app, :web, :db, :primary => true ssh_options[:port] = ... set :use_sudo, false set :repository, ... set :scm, :git set :deploy_via, :remote_cache set :copy_exclude, [".git", ".gitignore"] set :keep_releases, 10 namespace :deploy do task :start do end task :stop do end task :restart, :except => { :no_release => true } do end task :compile_less do system "lessc -x #{release_path}/www/css/bootstrap.less > #{release_path}/www/css/ bootstrap.css" end after ’deploy:update_code’, ’deploy:compile_less’ end namespace :log do task :clean do run "rm -rf #{shared_path}/log/*" end end

Ukázka 3.2: Ukázka konfigura ního souboru Capistrana pro pohodln˝ deployment

3.5

Datov˝ model

Datov˝ model aplikace je zna n rozsáhl˝. Obsahuje dvacet ty i tabulek t˝kajících se databáze firem a sedm tabulek redak ního systému. Pro svou velikost jsem samotn˝ obrázek vytiskl ve formátu A3 a umístil do p ílohy, zde bych cht l diskutovat n které zajímavosti i problémová místa, na která jsem p i jeho modelování narazil.

3.5. DATOV› MODEL

3.5.1

25

Kategorie

Nejv töím o íökem bylo správn navrhnout strukturu kategorií tak, aby pokud moûno dodrûovala normální formy a odpovídala skute nosti. V databázi existují jisté kategorie (agrochemie, substráty a zemina, ná adí, sadovnické pot eby, rostliny atd.) a ty mohou mít podkategorie (cibulnaté, hrnkové, jehli nany, vodní a bahení atd.). Tato skute nost je standardn modelována jako rekurze – vazba parent-child – v jedné tabulce kategorie. Dále evidujeme ty i obchodní modely: velkoobchod, maloobchod, v˝roba a sluûby. Pro kaûd˝ obchodní model jsou definovány jiné kategorie, ovöem v töina je shodná. Firma si tedy m ûe zapsat definovanou dvojici model-kategorie. Z t chto poûadavk vypl˝vá nutnost hned p ti tabulek. Tabulky firmy, modely a kategorie jsou z ejmé. Vazební tabulka kategorie_modely obsahuje definované dvojice obchodních model a kategorií. Vztah firmy ke dvojici kategorie-model poté evidujeme ve vazební tabulce kategorie_modely_firmy. Zajímavostí je, ûe se nám primární klí e z tabulek kategorie, firmy a modely propagují aû do této vazební tabulky.

3.5.2

Redak ní systém

Jádro struktury redak ního systému tvo í p irozen tabulka lánky. Tabulky diskuse, autori i sekce jsou standardní a jsou asi ve v töin redak ních systém . Problém byl ovöem, jak eöit situaci, kdy pot ebujeme evidovat data zahájení a ukon ení veletrh a v˝stav a ökolení a seminá . Jedna moûnost je mít atributy veletrh_od, veletrh_do a skoleni_od, skoleni_do p ímo v tabulce lánky. lánk t˝kajících se veletrh a v˝stav, respektive ökolení a seminá , je vöak jen zlomek a ostatní by m ly v t chto sloupe cích vûdy NULL. Lepöí volbou, kterou jsem pouûil, je de facto d di nost. Pro veletrhy, v˝stavy a ökolení, seminá e jsem vytvo il samostatné tabulky s vazbou 1:n. Tyto tabulky p ebírají veökeré atributy lánku a dále k nim dopl ují dalöí.

3.5.3

Zápisy

Zápisy firmy do katalogu je nutno evidovat zp tn . Proto jsem pro n vy lenil vlastní tabulku zápisy s vazbou m:n na firmu. Ta obsahuje prakticky vöechny objednávky (placené i neplacené), které firma u inila. Na tuto tabulku je navázána i inzerce (obrazová) a promo (dalöí zv˝hodn ní ve vyhledava i).

26

KAPITOLA 3. NÁVRH

3.6

Frontend

Aplikace je na frontendu d sledn len na do t í vrstev. Kaskádové styly jsou eöeny extern , nejsou míchány spolu s HTML kódem. Stejn tak javascript je odd len od HTML a odkazování na HTML elementy probíhá p es jejich ID nebo class, v ûádném p ípad nejsou handlery javascriptov˝ch událostí psány p ímo v HTML tagu v jeho atributu onclick, onmouseover atd.

3.6.1

CSS

3.6.1.1

LESS

Pro kaskádové styly jsem se rozhodl pouûít knihovnu Less. Ta rozöi uje CSS o uûite né konstrukce a chování jako jsou nap áklad prom nné, funkce nebo vno ená pravidla. Less je napsáno v javascriptu a pro v˝voj posta uje p ekládat less do CSS za b hu. Pro produkci se doporu uje less soubory zkompilovat do CSS a uöet it tak n jak˝ as p i na ítání stránek. Ukázka n kter˝ch vlastností [11]:

@nice-blue: #5B83AD; @light-blue: @nice-blue + #111; #header { color: @light-blue; }

Ukázka 3.3: Prom nné

.bordered { border-top: dotted 1px black; border-bottom: solid 2px black; } #menu a { color: #111; .bordered; }

Ukázka 3.4: Mixiny

3.6. FRONTEND

27

#header { h1 { font-size: 26px; font-weight: bold; } p { font-size: 12px; a { text-decoration: none; &:hover { border-width: 1px } } } }

Ukázka 3.5: Vno ená pravidla

3.6.1.2

Twitter Bootstrap

Dalöí knihovnou, kterou hojn vyuûívám je Twitter Boostrap. Jedná se o CSS framework, kter˝ usnad uje tvorbu uûivatelského rozhrají. Obsahuje grid system neboli m íûku, do které m ûeme HTML elementy pozicovat, dále eöí typografii, stylování tabulek, formá , tla ítek a velké mnoûství dalöích v cí.

3.6.2

HTML

äablony jsou v aplikaci tvo eny za vyuûití HTML verze 5 obohaceného o vykreslovací logiku. Tuto logiku nám zp ístup uje öablonovací systém Nette Frameworku nazvan˝ Latte. äablony jsou rozd leny do sloûek podle presenteru, kterému náleûí. Kaûd˝ modul obsahuje jednu hlavní öablonu – layout. Ten obsahuje nem nné ásti stránky a ostatní öablony do n j vkládáme pomocí {include #nazev-bloku}. V töina öablonovacích systém n co podobného podporuje, protoûe bychom se jinak pot˝kali s opakujícím se kódem (zejména HTML hlavi ka) v kaûdé öablon .

3.6.3

Javascript

Javascriptu není v aplikaci mnoho. V töinou se t˝ká formulá a AJAXu. Rozhodl jsem se pouûít populární knihovnu jQuery, kter˝ se dnes stává prakticky standardem pro základní práci s javascriptem a modifikaci DOM stromu. JQuery je také závislost CSS frameworku Twitter Bootstrap, resp. jeho javascriptové ásti jako jsou modální okna, rozbalovací menu, záloûky apod.

28

3.6.4

KAPITOLA 3. NÁVRH

Grafika

Grafick˝ návrh uûivatelské ásti byl dodán grafikem spole nosti Hortiflora ve formátu PSD. Mojí prací bylo tento návrh rozst íhat a nakódovat v HTML tak, aby byl p ístupn˝ ve vöech moderních internetov˝ch prohlíûe ích. Administra ní rozhraní je vytvo eno pomocí frameworku Twitter Bootstrap, coû velmi usnadnilo práci. 3.6.4.1

Cufón

Zajímavostí je vyuûití nástroje Cufón pro nahrazování font . Narozdíl od CSS3 vlastnosti font-face podporuje prakticky vöechny b ûné prohlíûe e. Nev˝hodou je, ûe fonty jsou po zobrazení rastrovány, proto vypadají p i zv töní stránky nehezky. Jako hlavní font nadpis byl vybrát Titillium Text, jehoû licence nasazení na web umoû uje zdarma.

Kapitola 4 Implementace 4.1

Konkrétní poûadavky na systém

Obecné poûadavky na hosting byly jiû diskutovány v kapitole Platformy. Aplikace byla vyvíjena a vyzkouöena na následujících technologiích:

• Ubuntu 10.04 Lucid Lynx LTS pro servery • PHP 5.3 • MySQL 5.5.14 • Apache 2.2.21 • Sphinx Search 2.0.1-beta • Nette Framework 2.0 • Dibi 2.0.1 V˝öe uvedené verze PHP, Sphinx, Nette a Dibi jsou minimální poûadované, distribuci GNU/Linuxu lze pouûít libovolnou. Stejn tak by vöe m lo fungovat i na MySQL a Apache staröích verzí. 29

30

KAPITOLA 4. IMPLEMENTACE

4.2

Implementa ní zajímavosti

4.2.1

P ístup k modelov˝m t ídám

Pro p ístup k model m z presenter je vyuûíván jednoduch˝ model loader. Ten je v kaûdém presenteru v instan ní prom nné $this->models a umoû uje nám volat nap íklad $this->models->users. Jak je vid t v ukázce níûe, samotn˝ loader vyuûívá magické PHP metody __get(). Ta je volána p i pokusu o p ístup k neexistující prom nné. V tomto p ípad dále volá metodu getModel, která vrací hotovou instanci poûadovaného modelu, nebo ji nejprve vytvo í. private $models = array(); public function getModel($name) { $lname = strtolower($name); if (!isset($this->models[$lname])) { $class = ’Models\\’ . ucfirst($name); if (!class_exists($class)) { throw new \InvalidArgumentException("Model ’$class’ not found"); } } }

$this->models[$lname] = new $class($this->modelContainer);

return $this->models[$lname];

public function __get($name) { return $this->getModel($name); }

Ukázka 4.1: Model loader

4.2.2

Ohodnocování firem

Zde uvádím p íklad metody, která je volána kaûdou hodinu Cronem a slouûí k p epo tu hodnocení firem a jejich utracen˝ch ástek. Tento p epo et trvá cca minutu a pravd podobn jiû nelze dále optimalizovat. V˝po et se provádí u vöech firem pro vöechny katalogy, tzn. celkem po et firem ◊ po et katalog pr chod . Pro p ípad, ûe by n která z databázov˝ch operací skon ila nezdarem a vyhodila v˝jimku, je cel˝ obsah metody obalen databázovou transakcí.

4.2. IMPLEMENTA NÍ ZAJÍMAVOSTI

31

public function evaluateAll() { try { $this->dibi->begin(); $firmy = $this->dibi->select("*") ->from("firmy") ->where("deleted = %b", FALSE) ->fetchAll(); $katalogy = $this->dibi->select("*") ->from("katalogy") ->where("aktivni = %b", TRUE) ->fetchAll(); foreach ($firmy as $firma) { foreach ($katalogy as $katalog) { $update = array( "let_od_posledniho_zapisu" => $this->letOdPoslednihoZapisu($firma->id, $katalog->id), "rating" => $this->spocitatRating($firma->id, $katalog->id), "aktualne_utraceno" => $this->utracenaCastka($firma->id, $katalog->id), "aktualne_utraceno_s_promem" => $this->utracenaCastka($firma->id, $katalog-> id, TRUE) ); $this->dibi->insert("vyhledavani", $update + array("firma_id" => $firma->id, " katalog_id" => $katalog->id))->on("DUPLICATE KEY")->update($update)-> execute(); } } $this->dibi->update("vyhledavani", array("let_null" => FALSE)) ->execute(); $this->dibi->update("vyhledavani", array("let_null" => TRUE)) ->where("let_od_posledniho_zapisu IS NULL")->execute();

}

$this->dibi->commit(); } catch (\Exception $exception) { $this->dibi->rollback(); throw $exception; }

Ukázka 4.2: Kód pro periodick˝ p epo et hodnocení firem

32

KAPITOLA 4. IMPLEMENTACE

Kapitola 5 Testování 5.1

Beta testování

Po dokon ení implementace byl systém nasazen do zkuöebního provozu. Po dobu dvou m síc byl intenzivn testován klientem. V tomto mezidobí klient nadále pouûíval svou stávající offline aplikaci spolu s m˝m nov˝m systémem. Poda ilo se odhalit místa, která se zprvu zdála bezproblémová, dále chyb jící funkcionalita, která nebyla klientem poptávána, ale ukázala se b˝ti pot ebná a také celkem 14 chyb (bug ). Vöechny tyto podn ty byly diskutovány s klientem 43 e-maily.

5.2

Nette\Diagnostics\Debugger

O tom, jak uûite n˝ je Nette\Diagnostics\Debugger alias Lad nka p i v˝voji jsem jiû psal. Lad nka je vöak moûná jeöt uûite n jöí v produk ním reûimu. Informace o jakékoliv chyb , která nastane, loguje do p ísluöného adresá e. Následn o ni informuje administrátora emailem. Aby nezaplavovala e-mailovou schránku, odeöle vûdy jen jeden e-mail pro kaûdou v˝jimku. Lad nka tak v˝znam˝m zp sobem dopomáhá rychlé oprav chyb, které by byly asto jen t ûce odhalitelné.

5.3

Testování v˝konu

5.3.1

Nette debugger bar

Jiû p i v˝voji bylo nutné pe liv kontrolovat dobu na ítání jednotliv˝ch stránek, zejména pak t ch, které pracují s databází. Vzhledem k tomu, ûe se prakticky na kaûdé stránce k 33

34

KAPITOLA 5. TESTOVÁNÍ

databázi p istupuje, vyuûíval jsem hojn Nette debugger baru. Jedná se o trvale zobrazen˝ panel, kter˝ ukazuje n které d leûité informace o stránce. V základu to jsou:

• Doba na tení stránky • Velikost zabrané RAM v MB • Pouûité pravidlo routeru • Vöechny SQL dotazy a jejich asy Zejména poslední údaj mi umoûnil odhalit n kolik öpatn napsan˝ch SQL dotaz , které trvaly p íliö dlouho. Po jejich optimalizaci doölo k v˝znamnému zrychlení na ítání p ísluön˝ch stránek.

Obrázek 5.1: Nette debugger bar

5.3.2

Apache stress test

V˝kon samotného webového serveru jsem se rozhodl otestovat pomocí nástroje AB (Apache HTTP server benchmarking tool). Jedná se o program pro simulaci zát ûe web serveru pomocí zasílání poûadavk na danou stránku. AB je velice komplexní a je moûné ho spouöt t s celou adou p epína . Já jsem si vysta il volbami -c 10 a -n 1000. P epína -c nastavuje po et soub ûn˝ch spojení a p epína -n pak celkov˝ po et testovan˝ch spojení. V následujících dvou v˝stupech jsou vid t v˝sledky testování. První testování je pro homepage, zatímco druhé je pro jednoduchou stránku, kter˝ obsahovala jen v˝pis funkce phpinfo(). Pro homepage bylo vy ízeno v pr m ru 14 poûadavk za sekundu p i simulaci p ipojení 10 klient . Vzhledem k tomu, ûe web b ûí na sdílenem virtuálním stroji s nejlevn jöím tarifem, je to v˝sledek odpovídající. Portál Hortiflora.cz také nedosahuje zatím návöt vnosti, pro kterou by bylo 14 request za sekundu nedosta ující.

5.3. TESTOVÁNÍ V›KONU

Server Hostname: hortiflora.cz Server Port: 80 Document Length: 99 bytes Concurrency Level: 10 Time taken for tests: 7.123 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Non-2xx responses: 100 Total transferred: 37500 bytes HTML transferred: 9900 bytes Requests per second: 14.04 [#/sec] (mean) Time per request: 712.250 [ms] (mean) Time per request: 71.225 [ms] (mean, across all concurrent requests) Transfer rate: 5.14 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.6 1 3 Processing: 417 707 71.0 717 819 Waiting: 417 705 71.6 717 819 Total: 418 707 70.9 718 820 Percentage of the requests served within a certain time (ms) 50% 718 66% 744 75% 752 80% 765 90% 785 95% 808 98% 818 99% 820 100% 820 (longest request)

Ukázka 5.1: V˝sledky benchmarku – homepage

35

36

KAPITOLA 5. TESTOVÁNÍ

Server Software: Apache/2.2.14 Server Hostname: hortiflora.cz Server Port: 80 Document Length: 288 bytes Concurrency Level: 10 Time taken for tests: 0.108 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Non-2xx responses: 100 Total transferred: 49100 bytes HTML transferred: 28800 bytes Requests per second: 925.73 [#/sec] (mean) Time per request: 10.802 [ms] (mean) Time per request: 1.080 [ms] (mean, across all concurrent requests) Transfer rate: 443.88 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.5 1 2 Processing: 2 9 3.0 9 18 Waiting: 2 9 2.9 9 18 Total: 4 10 2.9 10 19 Percentage of the requests served within a certain time (ms) 50% 10 66% 10 75% 11 80% 11 90% 17 95% 17 98% 19 99% 19 100% 19 (longest request)

Ukázka 5.2: V˝sledky benchmarku – phpinfo()

5.4

Shrnutí testování

Systém byl úsp ön otestován ve zkuöebním provozu a v sou asné dob by jiû ûádné zásadní chyby obsahovat nem l. V˝konnostní testy prokázaly, ûe je aplikace p i sou asné návöt vnosti a na stávajícím hardwaru dob e pouûitelná. V budoucnu plánuji pokr˝t aplikaci akcepta ními testy, které usnadní implementaci nov˝ch funkcí a refaktorizaci.

Kapitola 6 Záv r Hlavním cílem mé práce bylo vytvo it portál, kter˝ bude sdruûovat vyhledávání v katalogu firem a informa ní servis, a zv˝öit tak trûby plynoucí z webu na úkor trûeb z reklamy v tiöt n˝ch katalozích. Obchodní aspekt mi není znám, nicmén systém se mi vytvo it poda ilo. V sou asné dob obsahuje cca 5 000 firem, 500 lánk a je nadále pln n dalöími daty. Zákazník je se systémem pln spokojen a odpovídá jeho prvnotním p edstavám. Jiû nyní je z ejmé, ûe systém mu zjednoduöil velkou ást agendy a mimo jiné vy eöil problém se sdílením offline MS Access databáze mezi více administrátory p echodem na pln online eöení. Systém je moûno dále rozöi ovat o dalöí funkcionalitu a pravd podobn se tak bude v nejbliûöí dob dít. Zprvu se tento projekt nezdál nikterak sloûit˝, snad krom fulltextového vyhledávání. Postupem asu vöak za ínal bobtnat, tak jako v töina softwarov˝ch produkt . Celkem jsem nad ním strávil zhruba 400 hodin práce.

6.1

Budoucí práce

A koliv byla v töina poûadavk zákazníka implementována, zb˝vají ásti funkcionality, které byly z r zn˝ch d vod odloûeny i shledány mén d leûit˝mi. Na ty se bude zam ovat budoucí v˝voj, stejn jako na dalöí rozöi ování systému a opravy p ípadn˝ch chyb. V nejbliûöí dob budu pracovat na propojení v˝sledk vyhledávání s vyhledáváním Googlu, d sledné pokrytí aplikace akcepta ními testy a vytvo ení rozhraní pro rozesílání hromadn˝ch vyûádan˝ch e-mail firmám.

37

38

KAPITOLA 6. ZÁV R

Literatura [1] Sphinx reference manual [online]. 2012. [cit. 16. 5. 2012]. sphinxsearch.com/docs/current.html>.

Dostupné z:
[2] Embedded Full-Text Search Sample [online]. 2008. [cit. 12. 5. 2012]. Dostupné z: . [3] MySQL CREATE INDEX Syntax [online]. 2006. [cit. 13. 5. 2012]. Dostupné z: . [4] Full text search [online]. 2012. [cit. 12. 5. 2012]. Dostupné z: . [5] GRUDL, D. Kdo pouûívá Nette Framework? [online]. 2012. [cit. 17. 5. 2012]. Dostupné z: . [6] GRUDL, D. Nette Framework: MVC & MVP [online]. 2009. [cit. 17. 5. 2012]. Dostupné z: . [7] GRUDL, D. Hlavní p ednosti Nette Frameworku [online]. 2012. [cit. 17. 5. 2012]. Dostupné z: . [8] JANOVSK›, D. Co je lemmatizace? [online]. 2003. [cit. 13. 5. 2012]. Dostupné z: . [9] KARWIN, B. Full Text Search Throwdown [online]. 2009. [cit. 12. 5. 2012]. Dostupné z: . [10] RUSSAKOVSKII, A. Comparison Between Solr And Sphinx Search Servers [online]. 2009. [cit. 16. 5. 2012]. Dostupné z: . [11] SELLIER, A. The dynamic stylesheet language [online]. 2012. [cit. 19. 5. 2012]. Dostupné z: .

39

40

LITERATURA

P íloha A Seznam pouûit˝ch zkratek AJAX Asynchronous JavaScript and XML API Application Program Interface CSRF Cross-Site Request Forgery CSS Cascading Style Sheet DBAL Database Abstraction Layer DOM Document Object Model DRY Don’t Repeat Yourself FTP File Transfer Protocol HTML Hyper Text Markup Language HTTP Hypertext Transfer Protocol JSON JavaScript Object Notation KISS Keep it simple, Stupid! MVC Model View Controller MVP Model View Presenter ODBC Open Database Connectivity PEAR PHP Extension and Application Repository PSD Photoshop Document 41

42

P ÍLOHA A. SEZNAM POUéIT›CH ZKRATEK

REST Representational State Transfer SEO Search Engine Optimization SQL Structure Query Language TCP Transmission Control Protocol URL Uniform Resource Locator VPS Virtual Private Server WYSIWYG What You See Is What You Get XML Extensible Markup Language XSS Cross-Site Scripting

P íloha B P vodní podoba stránek

43

44

P ÍLOHA B. P VODNÍ PODOBA STRÁNEK

Obrázek B.1: P vodní vzhled stránek

P íloha C Nová podoba stránek

45

46

P ÍLOHA C. NOVÁ PODOBA STRÁNEK

Obrázek C.1: Homepage

47

Obrázek C.2: V˝sledky vyhledávání

48

P ÍLOHA C. NOVÁ PODOBA STRÁNEK

Obrázek C.3: Profil firmy

P íloha D Datov˝ diagram

49

)

)

2

(

(

%&

%&

#(

(

(

" #)

$ %&

&+

(

(

#(

( %&,&

"' (

(

(

)

*&+

(

)

(%&,&

(

(&+

# %&

'

#(

)

)*

$ $ $ )

(

(

(

(

$

#

) $

(

#(

(

.

( ( $

$

!&/,000 1 (

(

(

%& %&

!" # $ %&

)

! *&+

&+

)

)

(

$

%&

#

$ #

(

# $ %&

!

# $ %&

(#1

)

#

(&+

*#&+ (!

*&+

( #)

1

! %&

!&/,000

(

' '

(

" '

#(

$

*&+

$

-

%&,&

-

* %&

(

(

)

( (

* %&,&

(

( (

%&

%& %&

52

P ÍLOHA D. DATOV› DIAGRAM

P íloha E Instala ní a uûivatelská p íru ka E.1

Instalace

Abychom mohli aplikaci pouûívat, musíme nejprve splnit její veökeré závislosti. To znamená naistalovat pot ebn˝ software: Apache, PHP, MySQL, Sphinx Search. Instalaci provedeme standardn pomocí balí kovacího nástroje. Pouze vyhledava Sphinx se musí kompilovat ru n , staûení zdrojov˝ch soubor provedeme z oficiálních stránek a postupujeme dle p iloûen˝ch instrukcí. Následn nahrajeme do webrootu webového serveru vöechny soubory p iloûené na CD. Spustíme SQL instala ní skript pro vytvo ení pot ebné struktury databáze.

E.2

Konfigurace

Po instalaci provedeme úpravu konfigura ních soubor . V souboru config/config.neon upravíme hesla pro p ístup do databáze. Konfigura ní soubor Sphinx (/etc/sphinx.conf) p ehrajeme p iloûen˝m souborem z CD a upravíme v n m uûivatelské jméno a heslo.

E.3

Spuöt ní

Vzhledem k tomu, ûe aplikace je webového typu, nemusíme ji nijak spouöt t. Pouze do prohlíûe e zadáme (v p ípad spouöt ní na lokálním stroji) adresu localhost i ip adresu 127.0.0.1 a p ísluönou cestu k sloûce aplikace a podsloûce www, ve které je umíst n soubor index.php.

53

54

P ÍLOHA E. INSTALA NÍ A UéIVATELSKÁ P ÍRU KA

P íloha F Obsah p iloûeného CD

Obrázek F.1: Obsah p iloûeného CD

55

Fulltextové vyhledávání v online katalogu zakázník

Recommend Documents