Na tomto míst bude ociální zadání va²í práce

Na tomto míst¥ bude ociální zadání va²í práce •

Toto zadání je podepsané d¥kanem a vedoucím katedry,

•

musíte si ho vyzvednout na studiijním odd¥lení Katedry po£íta£· na Karlov¥ nám¥stí,

•

v jedné odevzdané práci bude originál tohoto zadání (originál z·stává po obhajob¥ na kated°e),

•

ve druhé bude na stejném míst¥ neov¥°ená kopie tohoto dokumentu (tato se vám vrátí po obhajob¥).

i

ii

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£ové graky a interakce

Bakalá°ská práce

Internetový obchod autodílny

Aneta Svobodová

Vedoucí práce: Ing. Bure² Miroslav, Ph.D.

Studijní program: Softwarové technologie a management, Bakalá°ský Obor: Web a multimedia 27. kv¥tna 2011

iv

v

Pod¥kování Cht¥la bych pod¥kovat svému vedoucímu bakalá°ské práce Ing. Miroslavu Bure²ovi, PhD. za cenné rady, p°ipomínky a vedení práce, Tomá²ovi Jukinovi za poskytnutí licence k Chimera Frameworku a serveru, na kterém je systém nahraný, a také bych cht¥la tímto pod¥kovat své rodin¥ za velkou psychickou podporu b¥hem vývoje a psaní mé bakalá°ské práce.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracovala 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 Praze dne 27. 5. 2011

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

viii

Abstract The aim of this bachelor thesis is to design and implement System for a Car-repair-service's e-shop and Reservation system for date booking used by clients. The system is implemented in the PHP language using Nette Framework. This bachelor thesis belongs to the category of design-implement thesis.

Abstrakt Cílem této bakalá°ské práce je návrh a implementace systému pro internetový obchod autodílny a rezerva£ní systém pro objednávání termín· náv²t¥v klient·. Systém je implementovaný v jazyku PHP s pouºitím Nette Framework. Bakalá°ská práce se °adí do kategorie návrhov¥-implementa£ní.

ix

x

Obsah 1 Úvod

1

2 Popis problému

3

2.1

Popis sou£asného stavu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Existující systémy

3

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

3 Analýza a návrh °e²ení 3.1

3.2

3.3

3.4

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

7

3.1.1

Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.1.2

Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Funkcionality systému

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

7

3.2.1

Internetový obchod . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2.2

Diskuzní fórum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.2.3

Administra£ní rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.2.4

Registrace uºivatel· do systému . . . . . . . . . . . . . . . . . . . . . .

9

3.2.5

P°ihlá²ení uºivatel· . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.6

Rezervace termín· náv²t¥v . . . . . . . . . . . . . . . . . . . . . . . . .

9

Uºivatelé systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.3.1

Administrátor a mechanik . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.3.2

Nep°ihlá²ený uºivatel . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.3.3

P°ihlá²ený uºivatel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Návrh aplikace

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

10

3.4.1

Use Case diagramy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.4.2

Vybrané uºivatelské scéná°e . . . . . . . . . . . . . . . . . . . . . . . .

14

3.4.3

3.4.4

3.5

7

Vymezení cíl· BP a poºadavk· na systém

3.4.2.1

Scéná° k rezervaci termínu náv²t¥vy . . . . . . . . . . . . . .

14

3.4.2.2

Scéná° k p°idání produktu do ko²íku . . . . . . . . . . . . . .

14

Komunikace mezi klí£ovými objekty v systému

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

15

3.4.3.1

Sekven£ní diagram ke scéná°i rezervace termínu náv²t¥vy

. .

15

3.4.3.2

Sekven£ní diagram ke scéná°i p°idávání produktu do ko²íku .

15

Stavy klí£ových datových prvk· v systému . . . . . . . . . . . . . . . .

16

3.4.4.1

Stavy objednávky

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

16

3.4.4.2

Stavy rezervace termínu . . . . . . . . . . . . . . . . . . . . .

17

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

18

Gracký návrh

xi

xii

OBSAH

4 Implementace

21

4.1

Pouºité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.2

Architektura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.3

Vývoj projektu

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

25

4.4

Gracká stránka aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.5

Pouºité nástroje

31

4.6

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

4.5.1

Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.2

Capistrano

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

31

Problémy vy°e²ené b¥hem vývoje . . . . . . . . . . . . . . . . . . . . . . . . .

32

5 Testování

33

5.1

Testovací scéná°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2

Výsledky testování

33

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

34

5.2.1

Tester 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.2.2

Tester 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.2.3

Tester 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

6 Záv¥r

39

A Seznam pouºitých zkratek

45

B Databázový model

47

C Instala£ní p°íru£ka

51

D Obsah p°iloºeného CD

53

Seznam obrázk· 2.1

PrestaShop

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

4

2.2

OpenCart

2.3

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

4

Magento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4

Zen Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.1

UC administrátora - správa produkt· . . . . . . . . . . . . . . . . . . . . . . .

10

3.2

UC administrátora - správa e-shopu . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3

UC administrátora - správa obsahu webové prezentace

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

12

3.4

UC administrátora - správa ostatních prvk· v administraci . . . . . . . . . . .

12

3.5

UC uºivatel·

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

13

3.6

SD - Rezervace termínu náv²t¥vy . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.7

SD - P°idání produktu do ko²íku

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

16

3.8

Stavy objednávky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.9

Stavy rezervace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.10 Návrh graky v Adobe Photoshop CS3 . . . . . . . . . . . . . . . . . . . . . .

19

4.1

Architektura MVP v Nette Framework . . . . . . . . . . . . . . . . . . . . . .

23

4.2

Adresá°ová struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3

Graka webu (front end) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.4

Graka administrace (back end) . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.5

Graka administrace (back end) - správa produkt·

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

30

B.1

Databázový model

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

47

B.2

Databázový model 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

B.3

Databázový model 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

D.1

Obsah p°iloºeného CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

xiii

xiv

SEZNAM OBRÁZK

Seznam tabulek 5.1

Tabulka 1 - test 1/2

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

35

5.2


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

35

5.3


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

36

5.4


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

36

5.5


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

37

5.6


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

37

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Cílem této práce je navrºení a realizace systému pro internetový obchod autoopravny a jejího rezerva£ního systému, ve kterém si mohou uºivatelé zarezervovat termín své náv²t¥vy v autoopravn¥. Systém zahrnuje administra£ní rozhraní pro správu internetového obchodu, malé webové prezentace, diskuzního fóra a rezervací. V dob¥ ekonomické krize [7], která zasáhla eskou republiku v roce 2009 a která trvá dodnes, je t¥ºké se udrºet na stejné ekonomické úrovni, zvlá²t¥ pro men²í podnikatele. Mnohé rmy, podnikatelé a ºivnostníci z mého okolí je²t¥ prozatím v·bec ne°e²ili webové prezentace nebo e-shopy. A´ uº z d·vodu toho, ºe se domnívali, ºe není pot°eba mít webovou prezentaci nebo internetový obchod, nebo nem¥li na jejich vytvo°ení £as. Krize ale zp·sobila pokles zakázek, coº donutilo rmy a podnikatele k rychlému jednání, a tak za£al r·st po£et zakázek ve webdesignových rmách. Je velmi d·leºité být vºdy o krok nap°ed p°ed konkurencí. Konkurence je veliká, a tak hlavn¥ men²í podnikatelé musí v¥d¥t, jak p°ilákat zákazníky. K tomu pom·ºe vybudování internetového obchodu nebo profesionální webové prezentace. Pro internetový obchod je nezbytný profesionální design, který je p°ehledný, m¥l by na potenciální zákazníky p·sobit v¥rohodn¥ a díky tomu je upoutat a p°esv¥d£it ke koupi n¥kterého z produkt·. U webových prezentací by nem¥ly být informace p°íli² dlouhé, protoºe takové prezentace uºivatele nudí. Webové stránky by m¥ly náv²t¥vníka pobavit a m¥ly by být osobn¥j²í. Men²í rma £i podnikatel m·ºe p°edb¥hnout svými kvalitními webovými stránkami i velké rmy. V sou£asné dob¥ neustále stoupá prodej náhradních díl· do automobil· a také stoupá po£et webových prezentací r·zných autodílen, stejn¥ tak roste i po£et uºivatel· internetu, tudíº mají elektronický obchod a webová prezentace velký vliv na p°ilákání zákazník·. A práv¥ proto jsem se rozhodla pro navrºení a implementaci vlastního internetového obchodu s webovou prezentací na²í malé rodinné autoopravny.

1

2

KAPITOLA 1.

ÚVOD

Kapitola 2

Popis problému 2.1 Popis sou£asného stavu Prodej autodíl· probíhá jen v autoopravn¥ a náhradní díl se prodává zákazníkovi, jehoº auto je v tu dobu v autoopravn¥. Tedy náhradní díly se rovnou montují do automobil· a vyú£továvají se aº na faktu°e pro zákazníka. Autoopravna pot°ebuje jednoduchý internetový obchod, ve kterém lze prodávat autodíly i mimo samotné opravy aut. Sou£asný stav také neumoº¬uje mít p°ehled o v²ech náhradních dílech na sklad¥ a samotná databáze není p°íli² efektivní. Dnes uº velkým problémem je setkání více zákazník· v autoopravn¥ najednou. Ruku v ruce s tímto problémem jdou i neustálé telefonáty zákazník· s dotazy, kdy mohou p°ijet s autem, a cht¥jí v¥t²inou ihned po telefonu v¥d¥t, jaká je porucha na jejich aut¥. Navíc, kdyº se takových zákazník· najde nap°íklad 10 denn¥, jde produktivita práce stranou, protoºe si mechanik neustále musí zaznamenávat, kdo a kdy p°ijde, kdy musí jet na ²kolení apod. Proto bude vytvo°en men²í rezerva£ní systém, ve kterém si budou moci zákazníci rezervovat termíny náv²t¥v, zatímco mechanik m·ºe neru²en¥ pracovat. Zákazníci si ob£as cht¥jí koupit nové auto, tak se ptají v¥t²inou v na²í autoopravn¥ mechanika, jaké auto by jim doporu£il apod. K takovému ú£elu bude hlavn¥ slouºit diskusní fórum, kde budou moci zákazníci (uºivatelé systému) sm¥le psát r·zné dotazy a odpov¥di na jiné p°ísp¥vky.

2.2 Existující systémy Existuje °ada jednodu²²ích internetových obchod·, které jsou zdarma a které bych proto mohla pouºít pro na²i rodinnou autoopravnu. Mezi takové pat°í nap°íklad PrestaShop, OpenCart, Magento, Zen Cart atd. Existují také mnohem robustn¥j²í a placené internetové obchody, které také nabízejí mnoho dopl¬kových modul·. Chci ale vytvo°it vlastní internetový obchod, který bude co moºná nejjednodu²²í, bude mít základní funkce pot°ebné pro b¥h internetového obchodu. Pro na²i rodinnou autoopravnu se nehodí n¥jaký rozsáhlý internetový obchod, k provozu na²eho obchodu nám posta£í jen základní funkce. K rozhodnutí implementovat vlastní internetový obchod m¥ donutila také zv¥davost a chtí£ um¥t n¥jaký

3

4

KAPITOLA 2.

POPIS PROBLÉMU

internetový obchod vybudovat a rozum¥t jeho vnit°ní struktu°e. Níºe uvádím ukázky jiº zmín¥ných e-shop·.

Obrázek 2.1: PrestaShop

PrestaShop je moºné pouºít i pro komer£ní nasazení. N¥které £ásti (hlavn¥ administrace) nejsou v £eském jazyce.

Obrázek 2.2: OpenCart

OpenCart je dobrou alternativou k oblíbeným softwar·m jako je Zen Cart, ale oproti nim zatím neobsahuje tolik funkcí a plugin·. P·sobí v²ak mnohem elegantn¥ji a p°ehledn¥ji. eská lokalizace zatím není k dispozici.

2.2.

5

EXISTUJÍCÍ SYSTÉMY

Obrázek 2.3: Magento

Tento internetový obchod vyniká zejména svou moderností a uºivatelskou p°íjemností. K dispozici je zatím neúplný £eský p°eklad a prozatím malá £eská komunita.

Obrázek 2.4: Zen Cart

Zen Cart je nejpopulárn¥j²ím e-shopovým systémem. Poskytuje rozsáhlé moºnosti roz²í°ení p°i zachování jednoduchého nastavení a pouºívání.

6

KAPITOLA 2.

POPIS PROBLÉMU

Kapitola 3

Analýza a návrh °e²ení 3.1 Vymezení cíl· BP a poºadavk· na systém Krom¥ níºe uvedených poºadavk· má také prob¥hnout testování.

3.1.1

Funk£ní poºadavky

•

Administra£ní rozhraní bude centralizované pro v²echny prvky v systému.

•

Implementace importu a exportu dat z jiných aplikací.

•

Funkcionality systému:

3.1.2

Internetový obchod Diskuzní fórum Administra£ní rozhraní Registrace uºivatel· do systému P°ihlá²ení uºivatel· Rezervace termín· náv²t¥v

Nefunk£ní poºadavky

•

Systém by m¥l být implementován v jazyku PHP [4] s pouºitím Nette Framework [6].

•

P°ístup k databázi se bude °e²it pomocí MySQL.

3.2 Funkcionality systému 3.2.1

Internetový obchod

Internetový obchod je st¥ºejním bodem mé bakalá°ské práce. Základními prvky e-shopu budou produkty za°azené do kategorií produkt· zobrazených v levém panelu e-shopu. U produktu bude evidovaný název, cena, výrobce autodílu, pro jaký automobil je daný autodíl vhodný, popis a dále ke kaºdému produktu bude p°ipojen obrázek.

7

8

KAPITOLA 3.

ANALÝZA A NÁVRH EENÍ

P·vodním zám¥rem byla navíc evidence podkategorií produkt·, které by specikovaly jiº zmín¥né kategorie produkt· kv·li lep²í orientaci v obchodu. Tuto moºnost jsem ale nakonec vynechala z d·vodu moºné £asové tísn¥ b¥hem dokon£ování bakalá°ské práce.

3.2.2

Diskuzní fórum

Diskuzní fórum bude obsahovat jednotlivá diskuzní témata, do kterých se budou psát jednotlivé p°ísp¥vky. V diskuzním fóru bude implementována moºnost odpov¥dí s pouºitím unikátního identikátoru zprávy. Prohlíºení reakcí na p°ísp¥vky tak bude mnohem p°ehledn¥j²í neº v £astých stromových strukturách.

3.2.3

Administra£ní rozhraní

V administra£ním rozhraní bude moºné spravovat obsah webové prezentace, p°ísp¥vky a témata v diskusním fóru, produkty v e-shopu, uºivatele a jejich rezervace, jejichº správu bude vykonávat mechanik. V administra£ním rozhraní jsou tyto poloºky:

•

Uºivatelé

•

Uºivatelské role

•

Obrázky

•

Fotogalerie

•

Soubory

•

Certikáty

•

Výst°iºky

•

Produkty

•

Kategorie produkt·

•

Výrobci autodíl·

•

Automobilové zna£ky

•

Sluºby

•

Novinky

•

Objednávky

•

Stavy objednávek

•

Rezervace

•

Varianty DPH

3.3.

UIVATELÉ SYSTÉMU

•

Moºnosti plateb

•

Moºnosti dopravy

•

Téma diskuzního fóra

•

Zpráva v diskuzním tématu

3.2.4

9

Registrace uºivatel· do systému

Uºivatel se m·ºe zaregistrovat do systému zadáním n¥kolika údaj·: jméno a p°íjmení, uºivatelské jméno, heslo a e-mail. Tyto údaje se následn¥ uloºí do databáze MySQL spole£n¥ s datem registrace. V p°ípad¥ nákupu produktu z internetového obchodu je pot°eba p°i objednávce vyplnit faktura£ní adresu uºivatele.

3.2.5

P°ihlá²ení uºivatel·

Po registraci se bude moci uºivatel p°ihlásit do systému. P°ihlá²ení zp°ístupní uºivateli n¥kolik funkcí a také si m·ºe editovat informace o svém prolu. P°ihla²ování je jednotné v aplikaci pro diskusní fórum, internetový obchod a rezervace termín· náv²t¥v.

3.2.6

Rezervace termín· náv²t¥v

Systém bude uºivateli umoº¬ovat zarezervovat si termín své náv²t¥vy v autoopravn¥. Uºivatel bude mít k dispozici kalendá°, ve kterém si vybere termín a poºadavek pro schválení termínu se ode²le mechanikovi, který následn¥ termín schválí nebo odmítne prost°ednictvím administra£ního rozhraní. O p°ijetí £i odmítnutí termínu náv²t¥vy bude uºivatel informován e-mailem.

3.3 Uºivatelé systému 3.3.1

Administrátor a mechanik

Administrátor i mechanik mají p°ístup ke v²em prvk·m ve webovém a administra£ním rozhraní. Rezervace termín· náv²t¥v bude spravovat primárn¥ mechanik, které bude termíny p°ijímat £i odmítat. Dále budou moci mazat, upravovat a p°idávat p°ísp¥vky a témata v diskuzním fóru, mazat, editovat a p°idávat produkty, jejich kategorie. Budou spravovat, zejména pak administrátor, databázi uºivatel·, obsah jednotlivých výst°iºk·...

3.3.2

Nep°ihlá²ený uºivatel

Má p°ístup do v²ech sekcí systému s tím, ºe m·ºe v diskusním fóru jen prohlíºet diskusní témata a p°ísp¥vky, v internetovém obchod¥ má moºnost vyhledávání produkt· (pomocí vyhledávacího pole, t°íd¥ní nebo pomocí postranního panelu, kde jsou názvy kategorií) a jejich prohlíºení. Dále m·ºe jakýkoli uºivatel napsat dotaz mechanikovi prost°ednictvím formulá°e k tomu ur£enému. Pro zp°ístupn¥ní ostatních funkcí, které má p°ihlá²ený uºivatel, se musí p°ihlásit, p°ípadn¥ registrovat, pokud tak je²t¥ neu£inil.

10

3.3.3

KAPITOLA 3.


P°ihlá²ený uºivatel

P°ihlá²ený uºivatel má p°ístup do svého uºivatelského prolu, který si bude moci kdykoli upravit. P°ihlá²ený uºivatel navíc m·ºe v diskusním fóru vytvá°et diskusní témata a p°idávat nové p°ísp¥vky. M·ºe si v internetovém obchod¥ objednat produkt, p°i£emº b¥hem objednávání m·ºe editovat a mazat produkty v ko²íku. Také si m·ºe zarezervovat termín náv²t¥vy.

3.4 Návrh aplikace 3.4.1

Use Case diagramy

Use case diagram zobrazuje chování systému nebo jeho £ásti z hlediska uºivatele. Use case (p°ípad uºití) si lze p°edstavit jako soubor scéná°· pro pouºívání systému. Kaºdý ze scéná°· popisuje sekvenci událostí. Diagram p°ípadu uºití zobrazuje sluºby, které systém nabízí uºivateli.

Obrázek 3.1: UC administrátora - správa produkt·

3.4.

NÁVRH APLIKACE

Obrázek 3.2: UC administrátora - správa e-shopu

11

12

KAPITOLA 3.


Obrázek 3.3: UC administrátora - správa obsahu webové prezentace

Obrázek 3.4: UC administrátora - správa ostatních prvk· v administraci

3.4.

13

NÁVRH APLIKACE

Obrázek 3.5: UC uºivatel·

14

KAPITOLA 3.

3.4.2


Vybrané uºivatelské scéná°e

Tyto scéná°e jsem vybrala z d·vodu toho, ºe jsou pro hlavní funkcionality systému.

3.4.2.1 Scéná° k rezervaci termínu náv²t¥vy Precondition: Uºivatel je p°ihlá²en do systému. Postcondition: Uºivatel má zarezervovaný termín.

1. Scéná° za£íná, kdyº uºivatel klikne na sekci Rezervace. 2. Systém zobrazí webovou stránku s výb¥rem dnu a hodiny. 3. DOKUD uºivatel nep°ejde na jinou webovou stránku, DLEJ 3.1 Systém vyzve uºivatele ke zvolení data náv²t¥vy. 3.2 Uºivatel vybere z kalendá°e datum náv²t¥vy. 3.3 Systém zobrazí tabulku s jednotlivými £asy na vybraný den. 3.4 Systém vyzve uºivatele ke zvolení £asového období z tabulky. 3.5 Uºivatel vybere £asové období a potvrdí rezervaci. 3.6 Systém rezervaci uloºí do tabulky rezervací v databázi. 3.7 Systém po²le mechanikovi e-mail s poºadavkem na schválení nové rezervace od daného uºivatele. 3.8 Systém po²le uºivateli informa£ní e-mail s termínem rezervace.

3.4.2.2 Scéná° k p°idání produktu do ko²íku Precondition: Uºivatel je p°ihlá²en do systému. Postcondition: Produkt je v ko²íku.

1. Scéná° za£íná, kdyº uºivatel klikne na sekci E-shop. 2. Systém zobrazí úvodní stránku internetového obchodu. 3. POKUD uºivatel vyhledá produkt prost°ednictvím postranního panelu s kategoriemi, POTOM 3.1 Systém vypí²e produkty z dané kategorie. 4. POKUD uºivatel vyhledá produkt prost°ednictvím vyhledávání podle kritérií, POTOM 4.1 Systém zobrazí výsledky vyhledávání. 5. POKUD uºivatel najde hledaný produkt, POTOM 5.1 Uºivatel p°idá produkt do ko²íku. 5.2 Systém zobrazí obsah ko²íku. 5.3 POKUD uºivatel chce p°idat dal²í produkty do ko²íku, POTOM 5.3.1 Uºivatel klikne na sekci E-shop. 5.3.2 Systém zobrazí v²echny produkty v internetovém obchodu. 5.3.3 Uºivatel pokra£uje krokem 3.

3.4.

NÁVRH APLIKACE

3.4.3

15

Komunikace mezi klí£ovými ob jekty v systému

Sekven£ní diagram pat°í do skupiny interak£ních diagram·. Ukazují, jak objekty navzájem mezi sebou komunikují v závislosti na £ase. Skládají se zejména z objekt· a zpráv.

3.4.3.1 Sekven£ní diagram ke scéná°i rezervace termínu náv²t¥vy Tento diagram zobrazuje komunikaci uºivatele se systémem popsanou v prvním scéná°i 3.4.2.1.

Obrázek 3.6: SD - Rezervace termínu náv²t¥vy

3.4.3.2 Sekven£ní diagram ke scéná°i p°idávání produktu do ko²íku Na následujícím diagramu je znázorn¥na komunikace uºivatele se systémem podle druhého scéná°e 3.4.2.2.

16

KAPITOLA 3.


Obrázek 3.7: SD - P°idání produktu do ko²íku

3.4.4

Stavy klí£ových datových prvk· v systému

Stavový diagram je typ diagramu v jazyku UML. Diagram obsahuje stavový stroj (state machine), který vyjad°uje stavy ur£itého objektu a p°echody mezi t¥mito stavy.

3.4.4.1 Stavy objednávky Tento stavový diagram zobrazuje jednotlivé stavy objednávky produktu v internetovém obchod¥. Diagram ukazuje, ºe je moºné objednávku zru²it p°es administra£ní rozhraní.

3.4.

17

NÁVRH APLIKACE

Obrázek 3.8: Stavy objednávky

3.4.4.2 Stavy rezervace termínu Na tomto stavovém diagramu jsou znázorn¥ny stavy rezervace termínu náv²t¥vy. V p°ípad¥ odmítnuté rezervace uºivatel zkou²í zarezervovat jiný volný termín, který je jiº vyhovující pro mechanika.

18

KAPITOLA 3.


Obrázek 3.9: Stavy rezervace

3.5 Gracký návrh Vytvo°it gracký design pro webové stránky není nic sloºitého. D·leºité je, aby v n¥m barvy k sob¥ ladily, aby to nebyl n¥jaký gracký ký£, který by ve výsledku uºivatele spí²e odradil neº p°ilákal. A zvlá²t¥ není p°íli² jednoduché navrhnout design webu pro n¥jakou autodílnu, autoservis £i e-shop s autodíly. Graka takového webu musí být samoz°ejm¥ adekvátní k jeho obsahu. Také není ideální mít na webu p°íli² mnoho r·zných barev, aby z toho nebyl nakonec n¥jaký cirkus. Já osobn¥ neuctívám n¥jaký p°eplácaný design stránek, kde pak nevím, kam s o£ima. Rozhodla jsem se vytvo°it design elegantní a £istý a zárove¬ s barvami adekvátními k obsahu webu. Na hlavní stránce je layout klientského rozhraní jednosloupcový, s hlavi£kou, obsahem a pati£kou. Layout e-shopu se jiº trochu li²í obsahem, ve kterém jsou dva sloupce - první je menu a druhý je samotný obsah - tedy výpis produkt·.

3.5.

GRAFICKÝ NÁVRH

Obrázek 3.10: Návrh graky v Adobe Photoshop CS3

19

20

KAPITOLA 3.


Kapitola 4

Implementace 4.1 Pouºité technologie Svoji bakalá°skou práci jsem vyvíjela v jazyku PHP s pouºitím frameworku. PHP je skriptovací programovací jazyk, který pracuje na stran¥ serveru a je ur£ený pro tvorbu dynamického webu. Navíc je to jazyk zcela nezávislý na platform¥, tudíº nejsou problémy se skripty na r·zných opera£ních systémech. Pouºívám databázi MySQL. Na úplném po£átku vytvá°ení svého semestrálního projektu, který byl povaºován za po£átek bakalá°ské práce, jsem p°emý²lela o tom, jestli je výhodn¥j²í vyvíjet v £istém PHP anebo s podporou n¥jakého frameworku, a p°ípadn¥ jaký framework zvolit, aby mi co nejvíce vyhovoval a byla s ním co nejlep²í práce. Hledala jsem tedy na r·zných diskuzích a recenzích, které by mi mohly v hledání vhodného frameworku pomoci. Framework· dnes existuje nep°eberné mnoºství, ale ne jen tak kaºdý je snadno nau£itelný a pochopitelný, jeho adresá°ová struktura nemusí být srozumitelná a p°ehledná. Také záleºí na vlastní dokumentaci frameworku, jestli v·bec existuje, jestli je p°ehledná, jesli je pouºitelná... N¥které frameworky jsou pak bu¤ spí²e CMS systémy (Content Management System), tedy systémy pro správu obsahu, jako je nap°íklad Joomla!, anebo jsou to z v¥t²í £ásti samotné frameworky, jako jsou Symfony, CakePHP, Zend, Nette Framework a jiné. CMS systém je tedy software, který umoº¬uje správu dokument·, nej£ast¥ji pak webového obsahu. Takovými systémy jsou v dne²ní dob¥ zejména webové aplikace, které n¥kdy mají dopl¬kové programové vybavení u klienta. Tyto systémy jsou v odborné terminologii také známy jako redak£ní nebo publika£ní systémy. Mezi základní funkce CMS pat°í tvorba, editace a publikace dokument· v¥t²inou prost°ednictvím webového rozhraní, °ízení p°ístupu k dokument·m (zpravidla se správou uºivatel· a p°ístupových práv), správa diskuzí nebo komentá°·, správa soubor·, správa obrázk· £i galerií, kalendá°ní funkce a statistika p°ístup·. Mezi nejznám¥j²í p°edstavitele CMS systém· pat°í nap°íklad Drupal, Joomla!, WordPress, DokuWiki a jiné. Ale te¤ zp¥t k framework·m... Úpln¥ prvním frameworkem, nad kterým jsem uvaºovala, byl Zend Framework, jenº má velkou výhodu v obrovské komunit¥ a v mnoha publikacích o jeho pouºití, rozsáhlé online dokumentaci a také má jiº spoustu dopl¬k·. P°i pokusu o jeho instalaci m¥ ov²em zarazila nep°íli² p°ehledná adresá°ová struktura, tedy alespo¬ mn¥ nijak zvlá²t¥ nevyhovovala, i samotná instalace mi nep°i²la nijak p°íjemná a p°i prozkoumání

21

22

KAPITOLA 4.

IMPLEMENTACE

dokumentace jsem uváºila, ºe její prostudování a pochopení by mi v té dob¥ trvalo m¥síce, coº bylo pro m¥ nep°ípustné, kdyº jsem k tomu p°ipo£ítala navíc £as strávený nad samotným vývojem aplikace. Následn¥ jsem polemizovala nad frameworky Symfony, Nette a CakePHP a dosp¥la jsem k záv¥ru, ºe pro m¥ bude nejvhodn¥j²í Nette Framework, a to hned z mnoha d·vod·:

•

Je to p°edev²ím £eský framework, tudíº je pro m¥ snaz²í procházení dokumentace a pochopení samotného frameworku, pokud s n¥jakým frameworkem teprve za£ínám. Jeho k°ivka u£ení je strmá.

•

Dal²ím plusem je podpora návrhového vzoru MVC, AJAXu, SEO, DRY, KISS a znovupouºitelnost kódu.

•

Framework by správn¥ m¥l programátorovi usnad¬ovat práci, nikoli mu jí p°id¥lávat, jako tomu je nap°íkad u Zend Frameworku, a tuto vlastnost Nette Framework spl¬uje.

•

Samotné PHP má nep°íli² p°ehledné a srozumitelné chybové hlá²ky. A práv¥ Nette Framework má skv¥lý ladící nástroj, tzv. Lad¥nka (t°ída Nette/Debug), pomocí které lze v£as odhalit chyby aplikace.

•

Také má jiº spoustu dopl¬k·, které se mi skv¥le hodí do mé bakalá°ské práce.

Trochu nevýhodou tohoto frameworku je jeho nízkoúrov¬ovost, tudíº nemá v²echny pot°ebné prvky, které by programátorovi usnad¬ovaly práci, jako má nap°íklad Symfony Framework, který je nativn¥ vysokoúrov¬ový. B¥hem vývoje aplikace mi ale byla poskytnuta moºnost vyuºít Chimera Framework, který vyvinul m·j kamarád a kolega Tomá² Jukin, a nyní jsem také jeho spoluvývojá°ka. Tento framework je nadstavbou Nette Frameworku. V sou£asné dob¥ je v pozdním stadiu vývoje a není je²t¥ uveden pro ve°ejnost, ale jiº brzy bude kompletn¥ odlad¥n a otestován, tak se bude moci kone£n¥ prodrat na trh framework·. Nette Framework nemá v sob¥ nativn¥ modely, a tak je pot°eba je vytvo°it. Pro ORM (Object Relational Mapping) [3], coº je mapování (konverze) dat mezi rela£ní databází a objektov¥ orientovaným programovacím jazykem, v základu pouºívám open-source ORM nástrojRedBeanPHP [5], který vytvá°í schéma databáze uº za provozu. A práv¥ z RedBeanPHP a z Nette Frameworku je dopsáno v²e, co k tomu chybí, aby byl Chimera Framework vysokoúrov¬ový. Mormose v Chimera Frameworku v sob¥ pouºívá zmi¬ovaný RedBeanPHP. Mormose je vytvo°ený podle návrhového vzoru Active Record, který v roce 2003 publikoval Martin Fowler ve své knize Patterns of Enterprise Application Architecture. Tento vzor ukládá data do rela£ních databází. Nette Framework [2] je napsaný v PHP 5 s plným vyuºitím objektov¥ orientovaného programování. Kolem n¥j se vytvo°ila jedna z nejaktivn¥j²ích komunit £eských PHP vývojá°·. Nette je moºné pouºívat i v primitivních webových aplikacích, kterou m·ºe být nap°íklad £ist¥ informa£ní web o po£íta£ové h°e The Sims 3, nebo m·ºe být pouºit spole£n¥ s jiným otev°eným frameworkem, jako je t°eba Zend Framework. Teprve u sloºit¥j²ích aplikací - eshop·, wiki, blog· a CMS - je poznat moc frameworku. Eliminuje bezpe£nostní rizika a nutí £lov¥ka psát programy s £istým designem a klade d·raz na budoucí roz²i°itelnost. A enterprise aplikace uº v·bec nejde psát v £istém PHP, tam uº je framework nutností. Je²t¥ stojí za zmínku metoda Debug::dump(), která slouºí pro dumpování (výpis) prom¥nných.

4.2.

ARCHITEKTURA APLIKACE

23

Ve vý£tu klad· Nette Frameworku jsem se zmínila o návrhovém vzoru MVC (ModelView-Controller), kterou ve své práci pouºívám. Je to spí²e softwarová architektura, která rozd¥luje aplikaci do t°í vrstev: datový model (Model), uºivatelské rozhraní (View) a °ídicí logiku (Controller). Tato architektura je pot°ebná pro udrºení p°ehlednosti kódu. Model tedy zaji²úje p°ístup k dat·m a manipulaci s nimi, View p°evádí data prezentovaná modelem do podoby vhodné k prezentaci uºivateli a Controller reaguje na události, které p°icházejí od uºivatele, a zaji²úje zm¥ny v modelu nebo v pohledu. V Nette Frameworku je p°ejmenován Controller na Presenter. Presenter má podobnou roli jako Controller v MVC. Vybírá pohled (View) a p°edává mu model nebo data z modelu, Udrºuje stav persistentních prom¥nných. A zejména zpracovává reakce uºivatele, které se dají rozd¥lit na t°i typy:

•

zm¥na pohledu

•

zm¥na stavu

•

p°íkaz modelu

Obrázek 4.1: Architektura MVP v Nette Framework

B¥hem vývoje mé bakalá°ské práce jsem pouºívala verzovací nástroj Git [1], coº je SCM (Source Code Management) systém - tedy systém, který se za vývojá°e stará o správu a verzování zdrojového kódu. Mezi SCM nástroje také pat°í nap°íklad Subversion (SVN), Mercurial, CVS (Concurrent Version System). Práce s repozitá°em se provádí pomocí p°íkazové °ádky, nebo také je moºné pouºívat GUI rozhraní, tzv. SmartGit, který se mi ale v pr·b¥hu dokon£ování práce zhroutil a repozitá° projektu uº ani ne²el p°es GUI na£íst. Tedy d·v¥°uji uº jen p°íkazové °ádce, protoºe ta vºdy ud¥lá to, co poºaduji.

4.2 Architektura aplikace V p°edchozí podkapitole jsem psala o tom, ºe Nette Framework podporuje návrhový vzor MVC, respektive MVP, který ve svém projektu pouºívám. Nyní trochu nazna£ím adresá°ovou strukturu svého projektu. Obecn¥ dobrá adresá°ová struktura je klí£em i k pozd¥j²ímu pochopení kódu i jinými programátory, kte°í aplikaci t°eba ani neznají. A struktura v Nette Frameworku je velmi p°ehledná, coº opravdu zjednodu²uje práci.

24

KAPITOLA 4.

Nejprve stru£n¥ popí²u obsah hlavních adresá°·. V adresá°i

app

IMPLEMENTACE

je sloºka

controllers,

ve které jsou umíst¥ny jednotlivé presentery rozd¥lené do adresá°·, které ur£ují, pro jakou £ást aplikace jsou dané presentery ur£ené. Adresá°

app/controllers obsahuje adresá°e:

AdminModule, ApplicationModule a FrontModule. V AdminModule jsou presentery pro ad-

ministra£ní rozhraní a ve FrontModule jsou presentery pro webové rozhraní. V aplika£ní £ásti je nap°íklad presenter pro obrázky, pro p°ihlá²ení atd. V adresá°i chimé°í, které jsou ve sloºce

system,

controls

jsou umíst¥ny

a mé vlastní komponenty, které jsou mimo Chimera

Framework. Také jsem Chimeru obohatila o komponenty pro import a export dat, které byly

models se nacházejí jednotlivé modely aplikace views jsou pak pohledy rozd¥lené op¥t do t°í st¥ºejních adresá°· (AdminModule,

sou£ástí zadání mé bakalá°ské práce. Ve sloºce a ve sloºce

ApplicationModule, FrontModule). V nich jsou umíst¥ny jednotlivé ²ablony, které zobrazují výsledek viditelný pro uºivatele. Krom¥ hlavního aplika£ního adresá°e nit také o adresá°i

config,

ve které je nap°íklad soubor

r·zné kongura£ní soubory. V adresá°i

preprocess

routes.php

app je d·leºité se zmípro routování a dal²í

m·ºeme najít jednotlivé kaskádové a

javascriptové soubory a také soubory pro graku webu.

4.3.

25

VÝVOJ PROJEKTU

Zde je ukázka adresá°ové struktury mé práce:

Obrázek 4.2: Adresá°ová struktura

4.3 Vývoj projektu Nyní se p°esunu k nástinu postupu vývoje mé práce. V prvé °ad¥ jsem provedla analýzu a na£rtla si, co v²echno by m¥la aplikace um¥t a jak by m¥ly její £ásti p°ibliºn¥ fungovat. Pak jsem za£ala vytvá°et modely pro jednotlivé prvky aplikace. Ke kaºdému modelu bylo pot°eba vytvo°it p°íslu²nou administraci - presentery. To jsem provedla tak, ºe jsem zkopírovala jednoduché t°ídy, které mají základ v abstraktní t°íd¥, která je pro v²echny t°ídy

26

KAPITOLA 4.

IMPLEMENTACE

spole£ná a reprezentuje CRUD administraci (CRUD = Create, Read, Update and Delete - CRUD tedy p°edstavuje 4 základní operace pouºívané pro práci s daty) a díky tomu lze velmi snadno vytvá°et administra£ní presentery. Administrace, kterou si takto vytvo°ím, je jiº p°edp°ipravená z frameworku, je snadno vyrobitelná. Ale je moºné ji pro n¥jaký konkrétní model upravit, pokud je pot°eba, nebo lze vytvo°it administraci úpln¥ novou. Po vytvo°ení model· jsem tedy vytvo°ila pro administraci seznam presenter·. Kaºdý presenter má sv·j

master a sv·j layout. Master je ²ablona, ve které je uloºený obsah stránky krom¥ té samotné vnit°ní £ásti, která reprezentuje nap°íklad jednotlivé sloupce (nap°. vlevo je menu, uprost°ed obsah). Celá vnit°ní £ást stránky je pak layout. Layout je rozd¥lený na jednotlivé kontejnery a v kaºdém takovém kontejneru se m·ºe nacházet libovolné mnoºství chimé°ích komponent. Je vhodné si pro kaºdý prvek, který chci na stránce mít, vytvo°it komponentu. Tyto komponenty se následn¥ poskládají do jednotlivých kontejner· jednotlivých layout· v daných presenterech podle toho, jak chci mít web rozvrºený. Tímto zp·sobem se vytvá°í tzv. front end aplikace, coº je webová £ást pro uºivatele. Tedy vytvá°ení model· a vyrobení administrace díky frameworku zabere opravdu málo £asu. Díky ORM nástroji Mormose, o kterém jsem psala v druhé kapitole, framework za°ídí, ºe si sám po vytvo°ení soubor· model· vyrobí a posléze upravuje databázi. Aby to bylo výkonné, má dva reºimy - vývojový (development mode) a produk£ní reºim (production mode). Ve vývojovém reºimu je automaticky zapnuté spou²t¥ní Lad¥nky, která je sou£ástí Nette Framework, a v produk£ním reºimu je jiº defaultn¥ vypnutá, ale je moºné její spu²t¥ní vynutit - Debug production mode, kdy následn¥ mohu na serveru nap°íklad ladit, pro£ neb¥ºí projekt jen na serveru. Nevýhoda Mormose je omezení z hlediska výkonnosti v p°ípad¥ velkých webových aplikací £i sloºitých dotaz· apod. Nette Framework má v sob¥ dal²í 2 nástroje pro práci s databází. Prvním je Nette Database Connection, která je implementací star²í knihovny Dibi od autora Nette Frameworku Davida Grudla. Je to nízkoúrov¬ová vrstva pro p°ístup k databázi DBAL (Database Access Layer, nebo Database Abstraction Layer) vrstva abstrahující nad databází Nette Database Connection, která pak umoº¬uje psát SQL p°íkazy, zpracovávat je... Dal²í moºností je Nette Database Selector, který je implementací technologie od druhého PHP guru Jakuba Vrány, p·vodn¥ se jmenovala NotORM, protoºe to ORM nebylo. Je to nástroj, který velmi efektivn¥ umí na£ítat a mapovat na objekty záznamy z databáze. Kaºdý presenter má je²t¥ krom¥ svého master a layoutu také tzv. akce. Kaºdá akce má svoji vlastní ²ablonu, ve které je denice toho, které komponenty se zobrazí v jakém kontejneru v layoutu a v jakém to bude renderovacím reºimu. V administraci jsou 4 takové akce. Ty odpovídají jednotlivým renderovacím reºim·m detail,

edit

a

new

index zobrazí seznam, show zobrazí

zobrazí formulá° pro úpravu stávající/ p°idávání nové poloºky. Také to

umoº¬uje mazání poloºek. Ke komponentám je je²t¥ nutné °íci, ºe jsou to takové samostatné malé MVC. Kaºdá komponenta má své C, to je komponenta samotná - Controller, potom pouºívá M - Modely, a dále má kaºdá komponenta své V, tedy Pohledy (View). Komponenty mohou mít více jak jeden renderovací reºim a kaºdý renderovací reºim má práv¥ jednu svoji ²ablonu, p°i£emº výchozí renderovací reºim je

default.

P°i vytvá°ení n¥kterých komponent bylo pot°eba se hodn¥ zamyslet také na uºivatelskou p°ív¥tivost, zejména co se týkalo odpovídání v diskuzním fóru. Na mnoha diskuzích je totiº odpovídání na p°ísp¥vky °e²eno stromovou strukturou, která není zrovna ideální pro rozsáhlé

4.3.

27

VÝVOJ PROJEKTU

diskuze nad n¥jakým tématem, a to z toho d·vodu, ºe p°i neustálém odpovídání na dal²í a dal²í p°ísp¥vek ve vláknu se postupn¥ z p°ísp¥vk· stanou dlouhé nudle, které jsou jednak velmi nep°ehledné a jednak jsou neestetické. Pokud nap°íklad v n¥jaké takové diskuzi reaguji na ne úpln¥ poslední p°ísp¥vek ve vláknu, sice je m·j p°ísp¥vek správn¥ odsazen v dané úrovni, ale pokud jsou ty dva na sebe reagující p°ísp¥vky hodn¥ daleko od sebe, je pro náv²t¥vníka diskuze minimální ²ance najít p°ísp¥vek, na který se takto reagovalo. Jako ukázku takového diskuzního fóra bych uvedla web abclinuxu.cz. Tento problém s p°ehledností jsem vy°e²ila velmi jednodu²e. Jelikoº kaºdý p°ísp¥v¥k má své

id,

tak by byla ²koda toho nevy-

uºít. V²e je vid¥t v následujícím kódu z ²ablony zobrazení zpráv diskuzního tématu - °e²í se to pomocí $message->id a metody parseReplies ve t°íd¥ ForumHelpers.php. U p°ísp¥vku, který je reagující na jiný je p°ed zprávou zobrazeno, na jaký p°ísp¥vek reaguje, resp. zobrazuje jeho

id

s odkazem na daný p°ísp¥vek. Toto moje °e²ení je inovativní a p°ehledné, je

lineární, narozdíl od jiº zaºité a nep°ehledné stromové struktury.

Framework také obsahuje routování, jak jiº jsem zmínila na za£átku této kapitoly, kdy existují výchozí routy, které vedou na jednotlivé presentery. Routování je proces, který mapuje HTTP poºadavky na jednotlivé presenter requesty, coº je poºadavek na konkrétní presenter a ten vyústí v zobrazení n¥jaké konkrétní akce n¥jakého konkrétního presenteru. Chimera Framework má velkou výhodu v tom, ºe zjednodu²uje mnoho v¥cí, coº ale ob£as m·ºe vést k omezení. Kdykoli by vadilo n¥jaké chimé°í omezení, lze se vrátit zp¥t k nízkoúrov¬ovému frameworku, který je pod Chimerou, Jelikoº Chimera vnit°n¥ pouºívá Nette Framework, tak v²echno, co jde ud¥lat v Nette, je moºné ud¥lat i v Chimé°e. Chimera jen °íká, ºe n¥které v¥ci jde d¥lat jednodu²eji, usnad¬uje programátorovi práci, ale svým zp·sobem je v tomto trochu omezující. Dal²ím velkým obohacením Chimery je preprocessing na kaskádové (*.css) a javascriptové (*.js) soubory, které framework dovede v rámci preprocessingu jednak komprimovat (compress) a jednak spojovat (shrink) do jednoho souboru. To v²echno dokáºe zrychlit na£ítání aplikace, protoºe kaºdý includnutý soubor znamená nový HTTP poºadavek a je dobré jich mít pokud moºno co nejmén¥. Krom¥ javascriptového a kaskádového preprocessingu má Chimera také preprocessing obrázk· na webu. Tedy t¥ch, které jsou v tagu

img

a jednak

28

KAPITOLA 4.

i t¥ch, které jsou v CSS souborech - tomu se °íká CSS souborech na pozadí, tzn. jako

background.

gfx,

IMPLEMENTACE

a jsou to ty soubory, které jsou v

V sou£asné dob¥ umí Chimera Framework

minimalizovat (komprese a spojení soubor·) jen javascriptové a kaskádové soubory, ale do budoucna se po£ítá s vývojem a rozvojem automatického vytvá°ení tzv. CSS sprites. CSS sprites je technika, pomocí které se také sníºí po£et HTTP poºadavk·, které uºivatel vy²le k získání prvk· na stránce. Funguje to tak, ºe se obrázky slou£í do jednoho v¥t²ího obrázku a umístí se v n¥m na ur£ených sou°adnicích. P°i vykreslování na stránce se pak v CSS pouºije atribut

background-position,

pomocí kterého se umístí poºadovaný podobrázek onoho velkého

obrázku na správnou pozici na stránce. Tato technika je velmi efektivní p°i zvy²ování výkonu stránek, zejména v situacích, kdy je na stránce pouºito velké mnoºství malých obrázk·. V budoucnu by se tedy m¥la tato technika objevit i v Chimera Frameworku, kde bude tyto obrázky generovat. Z oblasti vylep²ování výkonu zobrazování stránek je ve frameworku je²t¥ na£ítání javaScript· jQuery od Google, které se na£ítají pouze v produk£ním reºimu. Z localhostu se tyto javaScripty na£ítají jen ve vývojovém reºimu. Tato vlastnost uº by ale m¥la být ve v²ech webových aplikacích zaji²t¥na, nebo´ si myslím, ºe dnes uº je toto nutností, nikoli jen n¥jakou vlastností navíc.

4.4 Gracká stránka aplikace Design klientského webového rozhraní jsem nakódovala podle svého návrhu v Adobe Photoshop (viz. podkapitola 3.5). Jsem tedy plnou autorkou celé klientské gracké £ásti aplikace. Administra£ní rozhraní ale m¥lo jiº vytvo°ené základní stylování (pozadí stránky, hlavi£ka, pati£ka) v Chimera Frameworku, tudíº jsem £áste£nou autorkou grackého designu administrace. Po vstupu do administrace jsou vid¥t v²echny prvky systému a jejich správa. Odkazy na jednotlivé správy prvk· jsou pln¥ modikovatelné, jsou vytvo°ené jako seznam, tedy sta£í jen zm¥nit obrázek pat°ící danému prvku. Pokud ukazatelem my²i p°ejdeme na tuto oblast s odkazy, objeví se k nim popisky daných prvk· a p°i najetí ukazatelem my²i na n¥jaký odkaz se obrázek odkazu i popisek ztmaví a ostatní z·stanou stále sv¥tlé. V levé £ásti layoutu se nachází menu se stejnými odkazy, které umoºní rychlý p°esun ze správy jednoho prvku na druhý. Na toto menu je pouºit jQuery plugin jCarousel [9], který práv¥ umoº¬uje posun obrázk· bu¤ ve vertikální nebo horizontální poloze. Pro administraci jsem tedy pouºila verzi s vertikálním posouváním seznamu poloºek. Navíc se jeho vý²ka nastavuje dle velikosti okna prohlíºe£e, coº je²t¥ více zrychluje práci v administraci tím, ºe uºivatel nemusí rolovat aº na konec stránky, aby kliknul na ²ipku posouvací dané poloºky, v tomto p°ípad¥ obrázky odkaz·. Jednotlivé ikonky jsem vytvo°ila na základ¥ staºení voln¥ dostupné sady ikonek. Prohlíºení fotograí ve fotogalerii a certikátech na klientské £ásti je vy°e²eno pomocí jQuery pluginu lightBox [8].

4.4.

GRAFICKÁ STRÁNKA APLIKACE

A zde je výsledek mé práce na designu webové prezentace s internetovým obchodem:

Obrázek 4.3: Graka webu (front end)

29

30

KAPITOLA 4.

IMPLEMENTACE

Ukázka administra£ního rozhraní:

Obrázek 4.4: Graka administrace (back end)

Obrázek 4.5: Graka administrace (back end) - správa produkt·

4.5.

31

POUITÉ NÁSTROJE

4.5 Pouºité nástroje 4.5.1

Git

Pro verzování projektu jsem pouºívala verzovací systém git, o kterém jsem jiº psala ve druhé kapitole. Je to velmi pokro£ilý a rychlý systém a jeho pouºití p°es p°íkazovou °ádku je skute£n¥ jednoduché. Mezi základní p°íkazy gitu pat°í tyto:

• git add -A

(tímto p°íkazem je projekt p°ipraven na ukládání do lokálního repozitá°e)

• git commit -m "Commit message."

(tímto se kopírování na lokální repozitá° potvrdí

a p°ipojí se k n¥mu komentá°, který se nahradí za commit message)

• git push, v p°ípad¥ submodulu se pouºívá git push origin master (tímto p°íkazem se projekt kopíruje do vzdáleného repozitá°e

• git pull

(tímto se ze vzdáleného repozitá°e dá získat aktuální verze, která tam je, a

nahraje se do mého projektu na lokálním serveru) Pokyny k práci s repozitá°em pomocí gitu jsou potom následující:

1. Ke kaºdému commitu se pí²e jiº zmín¥ná commit message, ve které se stru£n¥ a jasn¥ popí²e, co se kde zm¥nilo. Commit message je v angli£tin¥, za£íná velkým písmenem a kon£í te£kou (p°ípadn¥ vyk°i£níkem nebo otazníkem) a také m·ºe obsahovat seznam odráºek. 2. Základem je d¥lat v¥t²í mnoºství malých commit·, neº-li commitovat po velkých £ástech. M·ºe se pak stát, jako se to stalo mn¥ p°i necht¥ném p°ekliknutí a p°esunutí adresá°e

app/controls/System

do rootu projektu, £ímº se v²echno rozbilo a musela

jsem znova d¥lat velké mnoºství náro£ných úprav systému, které jsem nestihla commitovat p°ed touto nehodou. 3. Commituje se jen pln¥ funk£ní kód, tzn. ºe se naimplementuje kus, který funguje, commitne se a pak se m·ºe vyvíjet dál. P°ed commitem se aplikace musí otestovat na localhostu. 4. M¥l by se commitovat vºdy jen ucelený celek kódu. 5. Nikde se necommituje kód, který hází vyjímky, nebo o kterém víme, ºe nefunguje.

4.5.2

Capistrano

Capistrano je open source nástroj pro b¥h skript· na serverech. Jeho hlavním pouºitím je deployování webových aplikací na serveru. Zautomatizuje proces vytvá°ení nové verze aplikace, která je dostupná na serveru. Za°izuje tedy deployování aplikace na serveru, coº se za°ídí p°íkazem kazové °ádce, který se provádí po vý²e zmín¥ných p°íkazech v gitu.

cap deploy

v p°í-

32

KAPITOLA 4.

IMPLEMENTACE

4.6 Problémy vy°e²ené b¥hem vývoje Vyvíjení bakalá°ské práce se samoz°ejm¥ neobe²lo bez r·zných problém·, a´ uº to byly problémy s frameworkem nebo se serverem, na který jsem nahrála svoji práci. Ale °íká se, ºe v²echno zlé je k n¥£emu dobré, a to se zde také splnilo, protoºe díky výskytu n¥kterých chyb se mohl Chimera Framework trochu vylep²it. Není totiº je²t¥ pln¥ odlad¥n, a tudíº byly n¥které chyby v mojí aplikaci zp·sobeny chybou v kódu n¥jakého frameworkového souboru. Chimera se tak díky mé bakalá°ské práci posunula ve svém vývoji o krok dop°edu. Nejv¥t²í a nejzáke°n¥j²í problém, se kterým jsem se setkala b¥hem vývoje, nastal v nejmén¥ vhodnou chvíli, a to týden p°ed odevzdáním práce. B¥hem manipulace s NetBeans se ne²ástnou náhodou jedním kliknutím p°esunul adresá°

app/controls/system

do rootu celé

aplikace. Jenºe i po zp¥tném p°esunutí sloºky celá aplikace p°estala fungovat. Bohuºel jsem nestihla vytvo°ené zm¥ny (a ºe jich nebylo málo) commitnout do repozitá°e nebo alespo¬ kopírovat celý projekt n¥kam na disk jako zálohu, takºe po vytvo°ení analogického projektu a jeho na£tení z repozitá°e jsem musela v²echny ty zm¥ny ud¥lat znovu, coº dohromady trvalo je²t¥ 2 dny po této zdánliv¥ nepatrné chyb¥. P°esv¥d£ila jsem se, ºe je opravdu velmi d·leºité pravideln¥ aktualizovat obsah repozitá°e, klidn¥ i n¥kolikrát za den. Posledních pár problém· se objevilo p°i pokusu o nahrání projektu na server. Prvním problémem bylo to, ºe se aplikace na serveru ani nena£etla, ani se nevytvo°ily databázové tabulky. Nebylo lehké najít jádro problému, ale nakonec se mi poda°ilo zjistit, ºe chyba byla ve verzovacím systému git, který nerozli²uje velká a malá po£áte£ní písmena adresá°· (pouºívá jen malá písmena). A práv¥ ta velká po£áte£ní písmena byla nutná ve 3 sloºkách ve frameworku. Sta£ilo tyto 3 sloºky p°ejmenovat - první písmeno velké a na konci názvu se napí²e t°eba velké X, to v²e se nahraje na server a pak se z názv· t¥chto sloºek jen umaºe písmeno X, op¥t se celý projekt nahraje na server a pak uº je v²e v po°ádku. Posledním problémem byla chyba v na£ítání javaScript· na serveru. Problém byl hlavn¥ v na£ítání jQuery javaScript· od Google, sta£ilo p°idat k jeho na£ítání dal²í podmínku.

Kapitola 5

Testování Úkolem je otestovat funk£nost aplikace pomocí sady jednoduchých test·. Testování je velmi d·leºité pro zaji²t¥ní správné funk£nosti systému. P°ipravila jsem tedy seznam jednoduchých testovacích scéná°· pro uºivatelské testování. Testování m¥lo dv¥ £ásti:

•

Nejprve uºivatel otestoval webovou aplikaci pro zákazníky.

•

Poté otestoval aplikaci na úrovni administra£ního rozhraní, ke kterému byly uºivateli poskytnuty p°ihla²ovací údaje uºivatele s právy (uºivatelskou rolí) administrátora.

Testování prob¥hlo b¥hem jednoho dne a testovali 3 r·zní nezávislí uºivatelé. Dv¥ testování prob¥hla v prost°edí testujícího uºivatele. T°etí testování bylo vykonáno na dálku a komunikace mezi mnou a participantem probíhala pomocí telefonního hovoru. V²ichni t°i uºivatelé m¥li zku²enosti s objednáváním zboºí z internetových obchod·.

5.1 Testovací scéná°e Testovací scéná°e pro klientskou £ást:

1. Rezervuj(te) si termín náv²t¥vy podle pracovní doby uvedené na webu. 2. Objednej(te) si n¥jaký autodíl z internetového obchodu. 3. Napi²(te) 2 p°ísp¥vky do diskuzního fora - první bude normální, tzn. nebude reagovat na ºádný jiný p°ísp¥vek, a druhý uº bude reagovat na libovolný p°ísp¥vek ve foru. 4. Obsah daného diskuzního tématu exportuj(te) do souboru csv.

33

34

KAPITOLA 5.

TESTOVÁNÍ

Testovací scéná°e pro administra£ní £ást:

1. P°idej(te) do systému 3 libovolné obrázky. 2. Do fotogalerie 2 p°idej(te) jeden z práv¥ nahraných obrázk·. 3. P°idej(te) nový produkt do systému, nastav(te) mu hodnotu DPH na 5% a zkontroluj(te), jestli se také zobrazuje v e-shopu na webu. 4. Schval(te) si svoji rezervaci odeslanou v první £ásti testování (testování webové aplikace pro klienty). 5. Zm¥¬(te) stav svojí objednávky op¥t z první £ásti testování na stav probíhá zpracování. 6. Vytvo°(te) nový certikát a p°i°a¤(te) mu jeden ze 3 nahraných obrázk· v 1. úkolu. 7. Vytvo°(te)nový obsah pro stránku Sluºby pomocí výst°iºk· (nápov¥da: její systémové jméno je services_header) a ten p·vodní ud¥lej(te) pro web neviditelným. 8. Vytvo°(te) nového imaginárního uºivatele a p°i°a¤(te) mu roli uºivatel. 9. V administraci vytvo°(te) novou objednávku a p°i°a¤(te) jí zp·sob platby kartou a zp·sob dopravy PPL. 10. Smaº(te) 1 libovolný p°ísp¥vek v diskuzním fóru.

Poznámky k testování:

•

Nejd°íve zkou²ej(te) formulá°e vyplnit nesprávnými údaji a v p°ípad¥ výskytu chyby aplikace si danou chybu poznamenej(te).

•

P°ístup do administra£ního rozhraní je: jméno je tester, heslo je také tester.

5.2 Výsledky testování P°i testování jsem kladla d·raz na funk£nost systému, ale také jsem se následn¥ ptala na uºivatelskou p°ív¥tivost.

5.2.

35

VÝSLEDKY TESTOVÁNÍ

5.2.1

Tester 1

Klientská £ást:

íslo úkolu Problém Uºivatelská p°ív¥tivost 1

-

V po°ádku.

2

-

P°i registraci na web jsem jiº vypl¬oval n¥které své údaje, nevím pro£ po p°ihlá²ení musím v eshopu znovu tyto údaje zadávat.

3

-

V po°ádku.

4

-

Soubor v excelu obsahuje ne£itelé znaky.

Tabulka 5.1: Tabulka 1 - test 1/2

Administra£ní £ást:


-

V po°ádku.

2

-

V po°ádku.

3

-

V po°ádku.

4

-

O£ekával bych, ºe mi p°ijde email se schválením rezervace.

5

-

O£ekával bych, ºe mi p°ijde email se zm¥nou stavu rezervace.

6

-

V po°ádku.

7

-

V po°ádku.

8

-

V po°ádku.

9

-

V po°ádku.

10

-

V po°ádku.


36

5.2.2

KAPITOLA 5.

TESTOVÁNÍ

Tester 2

Klientská £ást:


-

V po°ádku.

2

-

V po°ádku.

3

-

V po°ádku.

4

-

V po°ádku.




-

V po°ádku.

2

-

V po°ádku.

3

-

V po°ádku.

4

-

ekal jsem email se schválením rezervace.

5

-

ekal jsem email se zm¥nou stavu rezervace.

6

-

V po°ádku.

7

-

V po°ádku.

8

-

V po°ádku.

9

-

V po°ádku.

10

-

V po°ádku.


5.2.

37

VÝSLEDKY TESTOVÁNÍ

5.2.3

Tester 3

Klientská £ást:


-

V po°ádku.

2

-

V po°ádku.

3

-

V po°ádku.

4

-

V po°ádku.




-

V po°ádku.

2

-

V po°ádku.

3

-

V po°ádku.

4

-

V po°ádku.

5

-

V po°ádku.

6

-

V po°ádku.

7

-

V po°ádku.

8

-

V po°ádku.

9

-

V po°ádku.

10

-

Kdyº smaºu n¥jaký p°ísp¥vek1, na který je reagováno, tak bych £ekal, ºe po kliknutí na odkaz u reakce v n¥jakém p°ísp¥vku2 se zobrazí hlá²ka, ºe p°ísp¥vek, na který bylo reagováno (p°ísp¥vek1), byl jiº smazán.


Z názor· na uºivatelskou p°ív¥tivost m¥ nejvíce zaujal komentá° t°etího testovacího uºivatele, a to v 10.úkolu administra£ní £ásti. Díky n¥mu jsem si uv¥domila, ºe by bylo opravdu vhodné tuto funkci v budoucnu implementovat. Zvý²í to p°ehlednost a orientaci v diskuzním foru. Dále bych ur£it¥ p°idala odesílání emailu po kaºdé zm¥n¥ stavu rezervací a objednávek.

38

KAPITOLA 5.

TESTOVÁNÍ

Kapitola 6

Záv¥r Tuto bakalá°skou práci jsem pojala jako projekt s vyuºitím v praxi a moºností jej pozd¥ji roz²í°it o mnoho dal²ích funkcionalit. Vyuºila jsem toho, ºe na²e rodinná autoopravna by pot°ebovala trochu p°ilákat zákazníky, nebo aby si udrºela alespo¬ ty doposud stávající zákazníky. Zárove¬ bylo pot°eba n¥jakým zp·sobem si ut°ídit, jaké autodíly jsou na sklad¥, které pak m·ºeme prodávat, protoºe ºádnou databázi autodíl· prozatím nemáme a nebylo by p°íli² pohodlné po kaºdém prodaném produktu vyhledat v databázi daný produkt a sníºit jeho mnoºství na sklad¥ podle po£tu jiº prodaných kus·. Sice tento systém je²t¥ neumí ode£ítat prodané produkty ze skladu, ale po£ítá se s tím do budoucna, ºe bude tato funkce (a i mnoho jiných funkcí) implementována. O dal²ích moºných vylep²eních se zmíním pozd¥ji. Zadání své bakalá°ské práce jsem splnila, tedy navrhla a implementovala jsem systém pro internetový obchod autoopravny a rezerva£ní systém pro objednávání termín· náv²t¥v. Dále jsem splnila poºadavek na centralizovanou administraci ke v²em prvk·m v systému a také se mi nakonec poda°ilo naimplementovat import a export dat z/do jiných aplikací, v mé práci se jednalo konkrétn¥ o formát csv. Na konci tvorby bakalá°ské práce jsem vytvo°ila testovací scéná°e pro uºivatele, které mají otestovat funk£nost systému. Na PHPUnit testy uº bohuºel nezbyl £as. Navíc p°i d°ív¥j²ím pokusu o instalaci PHPUnit test· se nejspí²e ne v²echno provedlo tak, jak má, takºe ani pak ne²ly v NetBeans po jejich konguraci spustit. Jak jsem se jiº zmínila, po£ítám do budoucna s roz²í°ením a vylep²ením celé aplikace, tedy odevzdání bakalá°ské práce neznamená v mém p°ípad¥ ukon£ení práce na tomto projektu. Tento projekt sice momentáln¥ b¥ºí na serveru, takºe je p°ístupný z internetu, ale p°ístup na daný server mám jen pro ú£ely bakalá°ské práce, tudíº bude pak pot°eba vyhledat vhodný webhosting. Ale je²t¥ p°ed ociálním spu²t¥ním této webové aplikace bude nutné ji vylep²it. Nejprve bych cht¥la zmínit moºnosti na vylep²ení e-shopu, které m¥ napadly b¥hem dokon£ování bakalá°ské práce. 1. V jiº implementovaném e-shopu vyhledávání produkt· funguje, ale zobrazené výsledky jsou zde jen jako seznam, nikoli s odkazy na dané produkty. 2. Sou£asný stav dovoluje p°idávat jen produktové kategorie, ve kterých budou dané produkty, ale vzhledem k tomu, ºe testovací verze e-shopu obsahuje jen n¥kolik málo

39

40

KAPITOLA 6.

ZÁVR

produktových kategorií a ve skute£nosti by se jich muselo v e-shopu zobrazovat víc, coº by vedlo k neskute£n¥ dlouhému seznamu kategorií v levé £ásti zobrazení e-shopu, tak by bylo dobré vytvo°it je²t¥ podkategorie produkt·, které by pak byly sou£asnými kategoriemi a samotné kategorie produk· by byly nap°íklad motor, brzdy, karoserie, apod. Vzhled e-shopu by se zm¥nil tak, ºe by byly vypsány jen kategorie a po kliknutí na danou kategorii by pod ní vyjela nabídka s podkategoriemi a v p°ípad¥ rozkliknutí dal²í kategorie by se ta p°echázející op¥t sbalila. 3. Dále jsem uvaºovala také nad vylep²ením zobrazování informací o produktu, ºe by se také mohly zobrazovat zna£ky aut, pro které je daný autodíl ur£ený a mohla bych pak implementovat ltrování, kde by nap°íklad bylo ltrování dle zna£ky automobilu nebo dle výrobce autodílu apod. U produkt· bych pak zp°ístupnila moºnost mít více p°idruºených automobilových zna£ek, aby se nemusel vytvá°et v podstat¥ stejný produkt jen s tím rozdílem, ºe by p°i°azený typ auta byl jiný. Co se tý£e konkrétních typ· aut, jestli je to diesel nebo benzin a jaký je objem motoru apod., tak by se v rámci jednoduchosti systému tyto informace psaly výhradn¥ jen do popisu k produktu, a to vºdy ve stejném formátu. 4. Také po kliknutí na tla£ítko Koupit by se mohla stránka p°esm¥rovat rovnou do ko²íku, kde by byla dv¥ tla£ítka, první by bylo nap°íklad Pokra£ovat v nákupu a druhé by bylo P°ejít k objednávce. 5. Jak jsem se jiº zmínila v p°edchozí kapitole ve výsledcích testování, vhodným vylep²ením by bylo odeslání informa£ního emailu uºivateli po kaºdé zm¥n¥ stavu objednávky, coº by se také týkalo zm¥ny stavu rezervace termínu. 6. Objednávání produkt· má nyní jednu nevýhodu - není je²t¥ implementovaná funkce na smazání poloºky z ko²íku a moºnost editace mnoºství produkt·. 7. Také bych mohla e-shop roz²í°it o ode£ítání mnoºství kus· na sklad¥ po dokon£ení objednávky. Systém by p°ípadn¥ uºivateli p°ímo ohlásil, ºe produkt jiº není na sklad¥. V takovém p°ípad¥ by bylo uºivateli doporu£eno napsat mechanikovi dotaz prost°ednictvím kontaktního formulá°e na webu, zda by mohl daný produkt objednat od dodavatele.

Dal²í moºná roz²í°ení:

1. U rezervací termín· by bylo zjednodu²ením pro klienty, kdyby m¥li v¥t²í jistotu schválení termínu jiº b¥hem rezervování, a to tak, ºe by mechanik mohl v systému na ur£itý termín vypsat nap°íklad ²kolení, coº by se na webovém rozhraní projevilo tak, ºe by se v kalendá°i daný termín znep°ístupnil. A také pokud by byl jiº termín obsazený jiným klientem, vypsala by se uºivateli hlá²ka p°ímo v registra£ním formulá°i, ºe termín od-do je jiº obsazen jiným uºivatelem. 2. V uºivatelském prolu jsou nyní jen základní informace o uºivateli. Cht¥la bych ale do budoucna zprovoznit, aby kaºdý uºivatel m¥l takovou malou databázi v²ech svých objednávek, která by byla vid¥t i z webového rozhraní po p°ihlá²ení daného uºivatele.

41

3. Uºite£nou funkcí také bývá odeslání zapomenutého hesla na základ¥ zaslání uºivateského jména a emailu. Tato funkce je²t¥ není implementovaná, ale op¥t s ní po£ítám do budoucna. 4. U uºivatele také bude pozd¥ji moºnost zabanování. Bu¤ by uºivatel dostal ban za nevhodné p°ísp¥vky v diskuzním fóru, kdy by se mu znep°ístupnila moºnost p°ispívat ve fóru, nebo za opakované nezaplacení objednávky by dostal ban na objednávání. Bany by byly na dobu ur£itou. 5. Kdyº uº jsem se dostala k diskuznímu fóru, tak bych zde také vid¥la estetické vylep²ení jednak v podob¥ podpory smajlík·, jednak v moºnosti si vloºit do svého uºivatelského prolu avatar, který by se objevoval u p°ísp¥vku ve fóru. 6. Posledním roz²í°ením, které m¥ je²t¥ napadlo, by mohl být vyskakovací lehce pr·hledný banner, který by se zobrazil p°i vstupu na hlavní stránku klientské £ásti. V takovém banneru by se mohly zobrazovat r·zné slevové akce apod.

42

KAPITOLA 6.

ZÁVR

Literatura [1] Git, 2011.

http://git-scm.com/.

[2] Nette Framework, 2010. [3] ORM, 2010. [4] PHP, 2010.

http://zdrojak.root.cz/serialy/zaciname-s-nette-framework/.

http://en.wikipedia.org/wiki/Object-relational_mapping. http://www.php.net. http://redbeanphp.com/.

[5] MOOIJ, G. RedBean, 2010.

[6] GRUDL, D. Nette Framework, 2010. [7] MEDIA,

N.

Obraz

http://www.nette.org/.

hospodá°ské

krize

v

eské

republice,

2009.

http://www.mediainfo.cz/temata/1611.html. [8] PINHO, L. V. lightBox, 2011.

http://leandrovieira.com/projects/jquery/lightbox/.

[9] SCOTT, B. jCarousel, 2011.

http://sorgalla.com/projects/jcarousel/.

[10] VRANA, J. Adminer, 2010.

http://www.adminer.org/.

43

44

LITERATURA

P°íloha A

Seznam pouºitých zkratek AJAX

Asynchronous JavaScript and XML

Apache CMS CSS

Softwarový webový server

Content Management System Cascading Style Sheet

CRUD

Create, Read, Update and Delete

DBAL

Database Access Layer (Database Abstraction Layer)

DRY GUI

Don't repeat yourself Graphical user interface

HTML

HyperText Markup Language

HTTP

Hypertext Transfer Protocol

jQuery

Javascriptová knihovna

KISS

Keep it short and simple

MVC

Model-View-Controller

MVP

Model-View-Presenter

MySQL ORM PHP

Multiplatformní databáze pouºívající jazyk SQL

Object Relational Mapping Hypertext Preprocessor

PHPUnit

Framework pro jednotkové testování v jazyce PHP

SCM

Source Code Management

SEO

Search Engine Optimization

45

46

SQL . . .

PÍLOHA A.

Structured Query Language

SEZNAM POUITÝCH ZKRATEK

P°íloha B

Databázový model

Obrázek B.1: Databázový model

47

48

PÍLOHA B.

Obrázek B.2: Databázový model 1/2

DATABÁZOVÝ MODEL

49

Obrázek B.3: Databázový model 2/2

50

PÍLOHA B.

DATABÁZOVÝ MODEL

P°íloha C

Instala£ní p°íru£ka Jelikoº se nejedná o nijak moc náro£nou webovou apllikaci, není pot°eba ºádná sloºit¥j²í instalace. Prvním krokem k úsp¥²nému nainstalování aplikace je staºení XAMPPu a jeho následné instalaci. XAMPP je balí£ek, který obsahuje instalace MySQL databáze a server Apache s PHP, pomocí n¥hoº lze rychle a snadno vytvo°it a zprovoznit lokální server. Pr·b¥h instalace je tedy následující:

•

Na domovské stránce projektu XAMPP doporu£uji stáhnout p°ímo instalátor (na webu je tento soubor uveden pod názvem Installer), který ud¥lá prakticky v²echnu práci za uºivatele.

•

Na za£átku instalace se instalátor zeptá na adresá°, kam má XAMPP nainstalovat.

•

Po instalaci je pot°eba najít a spustit XAMPP Control Panel, ve kterém se zejména spou²tí £i vypínají v²echny servery a je moºné servery (Apache, MySQL, FilaZilla a Mercury) nainstalovat jako sluºby.

•

Poté je nutné nastavit adresá°, ve kterém se budou moci spou²t¥t PHP aplikace. Ve sloºce

xampp/apache/conf

se nachází soubor

httpd.conf,

který se otev°e v n¥jakém

textovém editoru, nejlépe v PSPadu. V tomto souboru vyhledáme nastavení DocumentRoot - p°íklad nastavení je

DocumentRoot "C:/WEBING/",

p°i£emº adresá° WEBING

je zde onen výchozí adresá° pro PHP aplikace. Kousek pod tímto nastavením je £ást

To je v²e, co

je zapot°ebí nastavit. Typicky po nastartování Apache a MySQL bývá pot°eba p°ejít na http:/localhost/ a zm¥nit tam r·zná nastavení. To ale není nutné, protoºe v bakalá°ské práci pouºívám Adminer [10], coº je pln¥ vybavený nástroj pro správu databáze napsaný v PHP. D°íve se jmenoval phpMinAdmin a oproti klasickému phpMyAdmin se li²í tím, ºe obsahuje jen jeden jediný soubor, který je p°ipraven pro nahrání aplikace na cílový server. Je k dispozici pro MySQL, PostgreSQL, SQLite, MS SQL a Oracle. Po spu²t¥ní admineru (http://autoopravna.local/adminer.php) a p°ihlá²ení (uºivatelské jméno: root, heslo: svoboane) je zapot°ebí vytvo°it prázdnou databázi se jménem

autoopravna_jukin_cz. Po spu²t¥ní aplikace se databáze naplní tabulkami.

Momentáln¥ se tato bakalá°ská práce nachází na serveru http:/www.autoopravna.jukin.cz/, tudíº není pot°eba ºádná instalace.

51

52

PÍLOHA C.

INSTALANÍ PÍRUKA

P°íloha D

Obsah p°iloºeného CD Na p°iloºeném CD je uloºena dokumentace, samotná aplikace a obrázky, které se pozd¥ji v administraci mohou na£íst.

Obrázek D.1: Obsah p°iloºeného CD

53

Na tomto míst bude ociální zadání va²í práce

Recommend Documents