Podpora prodeje osobní elektroniky. Jiří Brhel

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Podpora prodeje osobní elektroniky Jiří Brhel Vedoucí práce: Ing. Miroslav Balík Ph.D. Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 27. května 2010

2 iv

3 v Poděkování Chtěl bych poděkovat zaměstnancům společnosti mivvy a.s. za spolupráci při tvorbě i finálním nasazení tohoto informačního systému.

4 vi

5 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). VPrazedne

6 viii

7 Abstract The goal of this bachelor thesis is to analyse, project and create aplication for sales promotion of personal electronics via Internet. Primary objective is to satisfy the requirement for multilinguality, expandability and utilisation of system of warranty control. Abstrakt Cílem této bakalářské práce je analyzovat, navrhnout a vytvořit aplikaci pro podporu prodeje osobní elektroniky prostřednictvím Internetu. Mezi hlavní požadavky patří multijazyčnost, rozšiřitelnost a využití systému pro správu reklamací. ix

8 x

9 Obsah 1 Úvod 1 2 Popis problému, specifikace cíle Základní popis problému a jeho řešení Obecné požadavky na systém Cílová skupina Popis struktury ve vztahu k vytyčeným cílům Rešerše CMS aplikace WordPress AiPublisher jnetpublish Analýza a návrh řešení Životní cyklus produktu Dosavadní přístup k životnímu cyklu produktu Přístup k životnímu cyklu produktu po zavedení systému Katalog požadavků Požadavky pro prezentaci produktů Požadavky pro podporu prodeje Nefunkční požadavky kladené na systém Vícejazyčný systém Autorizace koncových prodejců Rozdělení do modulů Případy užití Uživatelské role Everyone Vendor Admin Editor Seller Servis Supervisor Diagram aktivit průběhu reklamace Implementační prostředí xi

10 xii OBSAH 3.10 Dostupné frameworky Nette CakePHP Zend framework Výběr frameworku Wysiwyg editor Statistiky Realizace Využité technologie Adresářová struktura Rozdělení layoutů Modularita systému Controllery Funkce controllerů Použité komponenty Zend frameworku Zend_Auth Zend_Acl Zend_Controller_Router Zend_PDF Zend_Validate Implementace nestandardních řešení Zjištění stavu reklamace Zjištění dostupné lokalizace Genrerování čísla RMA protokolu Implementace wysivygového editoru Implementace Mootools LightBox Implementace grafického rozhraní Problémy během implementace Implementace instalátoru Testování Testování front-end části Validace dle standardů W3C Zobrazení prezentace Přístupnost formuláře registrace koncového prodejce Přístupnost formuláře pro vložení nové reklamace Fulltextové vyhledávání Přístupnost vyhledávačů Testování back-end části Korektnost zobrazení uživatelského rozhraní Testování uživatelského rozhraní Přínosy testování back-end části Formulář lokalizace produktu Vyhledávání reklamací Ukládání nastavení filtrů

11 OBSAH xiii 6 Závěr Naplnění cíle práce Další rozvoj projektu Literatura 33 7 Seznam použitých zkratek 35 8 UML diagramy 37 9 Instalační a uživatelská příručka Zkopírování souborů na server Spuštění instalace Nastavení služby Cron Spuštění systému Vývojové prostředí Obsah přiloženého CD Obrázky ze systému 45

12 xiv OBSAH

13 Seznam obrázků 3.1 Typický životní cyklus produktu na Internetu Uživatelské role v systému Řešení požadavku na vícejazyčný systém Diagram aktivit průběhu reklamace USE-CASE diagram správy produktu USE-CASE diagram správy reklamace Obsah přiloženého CD Úvodní stránka administračního rozhraní Přehled produktů Úvodní vzhled stránek mivvy a.s. - EN verze Výstupní reklamační protokol xv

14 xvi SEZNAM OBRÁZKŮ

15 Kapitola 1 Úvod Zadání práce vzniklo na podnět společnosti mivvy a.s. [1], jež se zabývá distribucí a prodejem výpočetní a komunikační techniky nejen v České republice, ale také v zahraničí. V dnešní době je součástí úspěchu bezesporu také kvalitní webová prezentace společnosti, s jejíž pomocí jsou prezentovány jak samotné produkty, tak další důležité informace pro spotřebitele i distributory. Z tohoto důvodu je potřeba vytvořit systém, jež umožní spravovat obsah prezentace s důrazem na informace o produktech. Nedílnou součástí je i využití systému k evidenci koncových prodejců a jejich možnou bonifikaci, v rámci této podpory je zahrnuta i možnost vyřizování reklamací prostřednictvím Internetu. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Popis problému, specifikace cíle 2.1 Základní popis problému a jeho řešení Výsledný systém by ve své podstatě měl fungovat jako CMS z hlediska správy obsahu, navíc však obohacený o prvky obstarávající podporu prodeje. Cílem pak je navrhnout a implementovat systém, který bude nejenom splňoval požadavky ze strany mivvy a.s., ale bude jednoduše přizpůsobitelný požadavkům jiných klientů. 2.2 Obecné požadavky na systém Celá architektura systému by měla být navržena s ohledem na rozšiřitelnost a možnou variabilitu použití dle konkrétních požadavků. Z tohoto důvodu by měl být systém navržen tak, aby přidání jakéhokoli dalšího funkčního prvku neovlivňovalo stávající prvky systému. Systém tohoto typu je pak možné označit za modulární. Dalším základním požadavkem je možnost prezentovat obsah v tzv. front-end části systému ve více jazycích. Tento systém bude především zaměřen na produkty jako jsou mobilních zařízení, mini-notebooky, MP4 přehrávače, apod. Z tohoto důvodu je potřeba spravovat také položky související s těmito produkty. Do této kategorie spadají například ovladače, software ke stažení a další. Je důležité, aby vytvoření produktové stránky, která bude popisovat daný produkt spolu s jeho příslušenstvím bylo pokud možno co nejjednodušší a celý proces působil intuitivně. Nedílnou součástí tohoto systému budou také moduly pro podporu prodeje. Tyto moduly musí umožnit registraci koncových prodejců, jejich evidenci a vyhledávání v seznamech prodejců. Úkolem systému také bude možnost zadávání a zprávy reklamací. Tyto reklamace budou zadávány on-line a mimo uložení informací o reklamaci, je nutné také zajistit generování reklamačních protokolů. Systém podpory prodeje pak bude dostupný pouze pro koncové prodejce, jejichž místem podnikání je Česká republika a Slovenská republika. Díky tomto požadavku pak odpadá nutnost lokalizace sekce podpora prodeje do jiného než českého jazyka. 3

18 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 2.3 Cílová skupina Cílovou skupinu můžeme rozdělit na dvě části. První skupinou jsou návštěvníci, kteří prohlížejí webovou prezentaci firmy, tzv. front-end. S ohledem na ně musí systém splňovat určité základní požadavky, především na přístupnost a na snadnou orientaci. Do této skupiny patří i koncoví prodejci, kteří do systému budou zadávat různá data. S tímto faktem je nutno počítat během implementace. Druhou skupinou jsou pak uživatelé, kteří budou využívat administračního rozhraní, tzv. back-end (typicky zaměstnanci mivvy). U těchto uživatelů se předpokládá znalost základních principů na poli internetových aplikací. Proto při návrhu administračního rozhraní budu vycházet ze standardních návrhových vzorů. 2.4 Popis struktury ve vztahu k vytyčeným cílům V první části práce popisuji analýzu daného problému, možná řešení a odůvodňuji volbu implementačního prostředí. V druhé části se pak popisuji realizaci a samotnou implementaci ve zvoleném implementačním prostředí, navíc se zaměřením na nestandardní části řešení. 2.5 Rešerše Aplikací CMS existuje v současné době celá řada a to jak ve formě placených, tak i volně šiřitelných systémů. S ohledem na požadavky však bylo nutné použít vlastní řešení, neboť tyto požadavky na funkční prvky podpory prodeje jsou natolik specifické, že jdou zcela nad rámec možností standardních CMS systémů. Přesto jsem pracoval také s dostupnými CMS systémy nebo pouze analyzoval jejich práci s obsahem, tak abych mohl s jistotou říct, že můj systém dává uživateli nadstandardní možnosti přizpůsobení uživatelského rozhraní se zachováním jednoduchosti editace CMS aplikace K analýze jsem využil následujících aplikací: WordPress[2] AiPublisher[3] jnetpublish[4] WordPress WordPress patří mezi velmi populární blog systémy. Tento systém patří mezi volně šiřitelné a jak z podstaty blogů vyplývá, je zaměřen především na textový obsah. V rešerši mi tento systém pomohl z hlediska uživatelského rozhraní - GUI. Jednoduché a přehledné rozhraní tohoto systému přispělo k finálnímu minimalistickému vzhledu kompletního administračního rozhraní.

19 2.5. REŠERŠE AiPublisher AiPublisher patří do skupiny placených aplikací. Za cenu cca Kč představuje poměrně silný nástroj pro správu obsahu. Avšak za velkou nevýhodu považuji nepřiměřenou složitost elementárních operací a také nepříliš propracované uživatelské prostředí. Na druhou stranu lze prostřednictvím administračního rozhraní změnit kompletní vzhled webové prezentace, což považuji za neoddiskutovatelnou přednost jnetpublish Aplikace jnetpublish již spadá do kategorie nadstandardních a poměrně nákladných systémů. Je pravděpodobné, že by se bylo možné dohodnout s firmou Et netera s.r.o. na implementaci nových funkcionalit pro potřeby podpory prodeje, neboť jnetpublish stojí za prezentacemi firem jako např. TicketPro, Siemens, Staropramen a dalších. Tento systém také disponuje širokými možnostmi modifikace prezentovaného obsahu. Avšak klade také nadstandardní požadavky na ovládání a jeho cena přesahuje finančními požadavky společnosti mivvy a.s.

20 6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

21 Kapitola 3 Analýza a návrh řešení 3.1 Životní cyklus produktu Po analýze požadavků ze strany mivvy a.s. jsem byl schopný vytvořil diagram popisující typický životní cyklus produktu na Internetu. Obrázek 3.1: Typický životní cyklus produktu na Internetu Dosavadní přístup k životnímu cyklu produktu V současné době jsou všechny procesy, které jsou na obrázku 3.1 vyobrazeny zelenou barvou prováděny přímým zásahem do zdrojového kódu. To znamená, že administrátor stránek vytváří pro každý produkt novou statickou stránku. S tím souvisí nutnost editovat stránky, které na tento produkt odkazují (tzn. menu apod.). Tento přístup je velmi náročný na čas, přehlednost a validitu kódu Přístup k životnímu cyklu produktu po zavedení systému Po zavedení systému do provozu bude uživatel, pokud mu to jeho systémová role umožní, moci jednoduše přidat produktovou kartu s podrobnými informacemi. Tvorba produktové karty bude podřízena produktovému formuláři, který bude obsahovat veškeré potřebné údaje určené k publikaci. Mimo jiné bude na produktové kartě k dispozici možnost výběru souborů ke stažení (ovladače, manuály, apod.). 7

22 8 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Uživatel tak bude moci každému produktu jednoduše přidat soubor či soubory, jež se ve výsledku zobrazí spolu s informacemi o vlastním produktu. V souvislosti s životním cyklem produktu bude také potřeba zajistit možnost dočasného skrytí produktu nebo přesunutí produktu do archívu. 3.2 Katalog požadavků Katalog požadavků rozdělím do dvou sekcí a to podle toho, zda jde o požadavky na prezentaci produktů, nebo oblast podpory prodeje. V níže uvedením katalogu považuji za editaci možnost danou položku vytvořit, smazat nebo upravit Požadavky pro prezentaci produktů Systém musí umožnit nastavení jazykových verzí, správu sekcí, možnost editace a změny pozice položek, správu produktů, editaci produktů, přesunutí produktu do archívu a zpět, nastavení produktu jako neviditelný, správu lokalizací produktů, vyhledávání produktů v administrační části, fulltextové vyhledávání, správu položek ke stažení a jejich editaci, lokalizaci položek ke stažení, základní editace stylů produktových karet, vkládání krátkých zpráv (novinek) na úvodní stránku, editaci vybraných statických stránek (kontakt, o nás, atd.), částečnou editaci vzhledu prezentovaných dat, vkládání krátkých aktualit, správu úvodní stránky - reklamních ploch, rozdělení do rolí a jejich oprávnění k přístupu, správu uživatelů

23 3.2. KATALOG POŽADAVKŮ Požadavky pro podporu prodeje Systém musí umožnit evidenci koncových prodejců, přihlášení prodejců do zabezpečené sekce, on-line vkládání reklamací, generovaní reklamačního PDF na straně prodejce, generovaní reklamačního PDF na straně servisního centra, generovaní přístupových údajů prodejcům, správu reklamací a jejich vyhodnocování, vyhledávání v reklamacích Nefunkční požadavky kladené na systém Mezi nefunkční požadavky lze zařadit, tzv. SEO optimalizaci. Na bázi návrhu a implementace systému je jedním z hlavních požadavků využití tzv. hezkých URL, které napomáhají k správné indexaci obsahu internetovými vyhledávači. Grafická reprezentace dat musí odpovídat webovému manuálu společnosti mivvy a. s. a systém musí být přizpůsoben stávajícímu vzhledu prezentační části. Dalším požadavkem je vytvoření přístupné prezentace (front-endu). Zde patří také korektní vykreslení webové prezentace v internetových prohlížečích Internet Explorer 7/8, Firefox, Opera, Safari a Chrome. Spolu s tím je nutné zajistit také validní kód prezentace a využití netabulkového layoutu. Systémové nároky byly stanoveny s ohledem na běžné hostingové služby: PHP a vyšší, MySQL , phpmyadmin, Cron, zálohování databázi, diskový prostor 5 GB a vyšší, rozsáhlé možnosti administračního prostředí, dostupnost on-line podpory

24 10 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 3.3 Vícejazyčný systém Jedním ze základních požadavků bylo zobrazení obsahu ve více jazykových verzích. Původní verze měla nastaveny pevně tři jazyky (čeština, angličtina a němčina). Nový systém by měl řešit tento problém mnohem komplexněji a bez ohledu na počet jazykových rozhraní. Bylo tedy nutné nalézt řešení tohoto problému, a to stále s ohledem na zachování dalších požadavků (především na SEO). Rozhodl jsem se tento požadavek vyřešit pomocí separace obsahu, který se neliší mezi jednotlivými jazykovými verzemi (kategorie produktu, fotografie, soubory ke stažení) a obsahu, který se mění v závislosti na zvoleném jazyku (specifikace a další textové informace). V implementační rovině toto rozdělení zajistí dvě tabulky, kdy jedna bude uchovávat informace textového charakteru, tedy závislé na jazykovém nastavení a druhá bude uchovávat pouze informace nezávislé na zvoleném jazyku. Toto řešení zjednodušeně popisuje diagram na obrázku 8.1. Na základe požadavků společnosti je možné využít přístupu, kdy produkty v jednom jazyce jsou množinou všech dostupných produktů v systému. Tento jazyk můžeme označit za primární. To znamená, že pokud bude uživatel chtít přidat produkt v jiném než primárním jazyce, bude muset pro tento produkt nejprve existovat vzor v jazyce primárním. Od tohoto vzoru pak dědí informace další jazykové mutace. Při nasazení systému pro společnost mivvy a.s. je tímto jazykem čeština. Tato volba však nebude v systému implementována nastálo, ale lze ji změnit dle požadavků klienta. 3.4 Autorizace koncových prodejců Autorizace koncových prodejců je zavedena z důvodu omezení přístupu uživatelů nespadajícím do kategorie koncových prodejců společnosti mivvy a.s. do sekce podpory prodeje. Každou žádost o zařazení do seznamu prodejců bude ověřovat pracovník společnosti mivvy. Po autorizaci prodejce budou vygenerovány přihlašovací údaje a tyto pak budou odeslány prostřednictvím u koncovému prodejci. 3.5 Rozdělení do modulů Pro další analýzu a následnou implementaci je potřeba všechny požadavky rozdělit do modulů, ke kterým bude možné přistupovat jako k samostatným prvkům. Toto rozdělení nám také pomůže při určení uživatelských rolí vyskytujících se v systému. Rozdělení do modulů je tedy následující: Informační stránka Sekce Produkty Soubory ke stažení

25 3.6. PŘÍPADY UŽITÍ 11 Vzhled Prodejci Servis Nastavení Koncoví prodejci Default 3.6 Případy užití Některé z uvedených případů užití jsou zobrazeny v příloze v kapitole USE-CASE diagramy. Pro snadnější orientaci jsem také rozebral možnosti jednotlivých rolí slovně. 3.7 Uživatelské role Pro správu systému je potřeba rozdělit uživatelské role tak, aby uživatelé systému měli přístup pouze do těch modulů, které jsou schopni a zároveň oprávnění spravovat. Systém bude tedy obsahovat následující role: everyone, vendor, seller, servis, editor a supervisor. Vztahy mezi jednotlivými rolemi a jejich přístup do modulů popisuje obrázek 3.6. Navíc je zde role Zákazníka (Customer), která zde znázorňuje nutnost kontaktovat Prodejce (Seller) pro vyřízení reklamace. V diagramu na obrázku 3.6 nemá uživatel zákazník žádnou roli, jde o osobu která může reklamovat produkt bez nutnosti interakce se systémem Everyone Toto je základní role, která umožňuje komukoliv prohlížet front-end část webu, vyhledávat produkty, stahovat soubory ke stažení, prohlížet statické stránky a také umožňuje přístup k formuláři pro registraci koncového prodejce. Tato role je generována systémem automaticky a je přidělena každému uživateli systému, který do systému není přihlášen Vendor Tato role dědí vlastnosti role Everyone a zároveň opravňuje uživatele pro přístup do sekce koncového prodejce. V této sekci může koncový prodejce zadávat nové reklamace, kontrolovat stav zadaných reklamací a může si zde změnit své osobní údaje vedené v systému.

26 12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Admin Základní administrační role systému opravňující uživatele k přístupu do administrace a samozřejmě prohlížení front-end části, jelikož dědí vlastnosti Everyone. Tento uživatel má možnost pouze editovat své osobní údaje, prohlížet si informační stránku a vidí informace o tom, kdo mu může změnit jeho přístupová privilegia. Oproti zažitým pravidlům nedisponuje tato role neomezeným přístupem k administračnímu rozhraní Editor Tato role dědí vlastnosti role Admin, poskytuje uživateli přístup do modulů Sekce, Produkty, Soubory ke stažení. Uživatel s touto rolí má možnost přidávat nové sekce, editovat jejich názvy a měnit pozici (řadit položky menu). Dále umožňuje přidávat produkty a jejich následnou editaci či lokalizaci. Také je uživateli s touto rolí umožněno přidávat nové položky ke stažení a k dispozici má také správu kategorií položek ke stažení Seller Tato role dědí vlastnosti role Admin, navíc umožňuje uživateli přístup do modulu Prodejci. Zde může uživatel prohlížet prodejce, prohlížet nové registrace a následně tyto registrace autorizovat nebo odstranit Servis Tato role dědí vlastnosti role Seller a umožňuje uživateli přístup do modulu Servis. V modulu Servis má uživatel k dispozici přehled reklamací zadaných uživatelem s rolí Vendor. V těchto reklamacích může vyhledávat, prohlížet zadané reklamace, případně tyto reklamace řešit. Přístup do modulu Seller je povolen z praktických důvodů. Je totiž možné, že servisní technik bude potřebovat získat některé informací o koncovém prodejci, které nejsou uvedeny v reklamačním protokolu. Zavedením této role jsem omezil nutnost komunikace mezi servisním a obchodním oddělením společnosti Supervisor Tato role má přístup do všech modulů. Jde o roli která má mimo jiné možnost editace vzhledu webové prezentace a zároveň jí je umožněno přidávat a mazat uživatele. Jako jediná má možnost přidávat nové lokalizace webu.

27 3.7. UŽIVATELSKÉ ROLE 13 Obrázek 3.2: Uživatelské role v systému

28 14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 3.8 Diagram aktivit průběhu reklamace Pro potřebu analýzy průběhu reklamace byl vytvořen diagram aktivit, obrázek 8.2, znázorňující vložení a průběh on-line reklamace. Reklamaci ukládá do systému uživatel s rolí vendor. Při uložení do systému se zároveň vygeneruje reklamační protokol, který je pak odeslán spolu se zásilkou. Od této chvíle je možné reklamaci sledovat v systému. Tato reklamace může mít hned několik stavů: Čeká se na doručení Reklamace se zpracovává Reklamace vyřízena Stav čeká se na doručení je stav, který nastane bezprostředně po vyplnění RMA formuláře a trvá až do doby, kdy bude zásilka od prodejce doručena do servisního střediska. Zde ji servisní technik přijme a změní její stav na reklamace se zpracovává. Tento stav indikuje prodejci, že zásilka úspěšně dorazila do servisního centra. Po dokončení reklamace již může technik zvolit stav reklamace vyřízena a reklamaci odeslat. Při tomto procesu systém zároveň vygeneruje reklamační protokol o provedené reklamaci. 3.9 Implementační prostředí Implementační prostředí volím z řady PHP frameworků, které podporují práci z databázemi MySQL. Implementace pomocí frameworku má hned několik výhod: Frameworky poskytují velké množství užitečných knihoven Frameworkový přístup udržuje logickou architekturu systému Frameworky nabízejí dobrý základ pro modulární systémy Pro tento projekt využiji některého z frameworků založeného na architektuře typu MVC, která rozděluje datový model aplikace, uživatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. Mezi tyto komponenty patří model, view a controller. K dispozici je několik MVC frameworků, mezi volně šiřitelné patří například Nette, CakePHP či Zend Framework Dostupné frameworky Nette [5] Nette framework patří k open-source projektům. Za vývojem stojí v současné době skupina Nette Foundation, která je složena převážně z českých vývojářů. Mezi výhody tohoto frameworku patří čistě objektový návrh využívající interface, vysoká výkonnost a také existence českého fóra.

29 3.11. VÝBĚR FRAMEWORKU CakePHP [6] Framework distribuovaný pod licencí MIT patří taktéž k oblíbeným frameworkům. Dokumentace k tomuto frameworku je většinou v anglickém jazyce. Co se týče rychlosti je vesměs srovnatelná s Zend frameworkem Zend framework [7] Zend framework je distribuován pod licencí BSD. Jde o velmi rozšířený a v současné době populární framework. Jeho nespornou výhodou je rychlý vývoj a velmi kvalitní dokumentace. Dokumentace se nesoustředí jen na vysvětlení základních pojmů, ale vše podstatné demonstruje na příkladech. V poslední verzi frameworku se také podstatně zvýšila rychlost práce s databází. k nimž lze přístupovat pomocí knihovny PDO Výběr frameworku Pro implementaci jsem nakonec zvolil Zend framework a to především z toho důvodu, že v něm již delší dobu pracuji a po čas jeho vývoje od verze 1.5 až po dnešní jsem zaznamenal velký pokrok nejenom v rychlosti, ale také ve snaze držet se doporučených standardů. Další výhodu je kvalitní IDE vývojové prostředí s nativní podporou Zend frameworku. Jde o Zend Studio 6[8], které je z dílny společnosti Zend. Podobnost v názvu frameworku a názvu společnosti Zend není náhodná, právě tato silná společnost stojí za vývojem Zend frameworku, což mimo jiné zaručuje stabilní vývoj tohoto frameworku Wysiwyg editor Dalším důležitým krokem je umožnit uživateli základní modifikaci textového výstupu. Jelikož však není možné klást na uživatele požadavky na modifikaci textů pomocí tagů nebo CSS stylů je třeba zahrnout do systému wysivigový editor. Mezi nejběžněji používané volně dostupné wysivigové editory patří TinyMCE nebo FCKeditor. Oba z těchto editorů poskytují široké možnosti a jsou prakticky srovnatelné. Osobně jsem zvolil TinyMCE z důvodu, že s ním mám dlouhodobé zkušenosti Statistiky Jedním z požadavků bylo zajištění statistik návštěvnosti webové prezentace pro marketingové účely. Nejprve jsem chtěl tento požadavek implementovat do systému svépomocí. Avšak v době kdy jsem na systému začal pracovat se do podvědomí dostávala aplikace Google Analytics. Tato služba je poskytována zdarma a nabízí mnoho užitečných informací prostřednictvím přivětivého rozhraní. Jelikož už systém samotný poskytuje vcelku široké možnosti rozhodl jsem se pro účely evidence statistik využít právě Google Analytics.

30 16 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

31 Kapitola 4 Realizace 4.1 Využité technologie Implementaci jsem prováděl s aktuálními verzemi následujících technologií: Zend framework 1.8[7] PHP MySQL Adresářová struktura Prvním důležitým krokem bylo navržení vhodné adresářové struktury. V tomto směru práci ulehčí použitý framework, který má doporučenou adresářovou strukturu. Použité IDE prostředí Zend studio 6 navíc tuto strukturu generuje vždy při vytváření nového Zend framework projektu. Poté stačilo již jen doplnit adresáře, jež budou potřeba navíc. Adresářová struktura projektu je následující: /application /admin /default /htdocs /index.php /styles /images /library /MyLibrary /Zend 17

32 18 KAPITOLA 4. REALIZACE 4.3 Rozdělení layoutů Layoutem se dá nazvat uspořádání stránky. Stránky, které se skládají z administračního a prezentačního rozhraní většinou vždy potřebují minimálně dva takovéto layouty. V tomto systému tedy rovněž využívám dvou layoutů, jeden pro sekci default a druhý pro sekci admin. Součástí každého layoutu je kostra stránky obsahující základní konstrukční elementy jako jsou tagy, definice css stylů a externích javascriptů. Tato kostra má pak jednotný vzhled v celém systému a mění se pouze obsah uvnitř této kostry. 4.4 Modularita systému Oproti předchozí verzi systému, kdy jsem s každým modulem vytvářel novou složku modulu ve složce application jsem se nyní rozhodl reprezentaci modulů ponechat pouze na zvolených controllerech. Systém tedy obsahuje složky admin a default. Ve složce admin soustřeďuji skripty společné pro back-end a ve složce "default"pak skripty společné pro front-end. Rozdělení modulů na controllery zpřehlednilo systém a umožnilo jednodušší zprávu uživatelských rolí, resp. jejich přístupu do jednotlivých sekcí. 4.5 Controllery V části back-end se vyskytují tyto controllery: IndexController SectionsCotrnoller ProductsController DownloadController AppeareanceController SellerController ServisController SupervisorController UserController Z názvů controllerů je celkem zřejmá jejich souvislost s moduly. Oproti rozvržení do modulů je zde ještě jeden interní controller User, který se stará o záležitostí týkající se uživatelského nastavení (jméno, heslo, atd.). Výchozím controllerem je IndexController jež reprezentuje modul s názvem informační stránka.

33 4.6. FUNKCE CONTROLLERŮ 19 V části front-end se vyskytují tyto controllery: IndexController VendorController Z názvů je opět zřejmá souvislost s modulem pro koncové prodejce Vendor a s prezentačním modulem Index. Controller Vendor je vlastně rozšířením prezentační části o funkce potřebné k podpoře prodeje. 4.6 Funkce controllerů Většinu controllerů administrační části reprezentuje standardní funkce správy obsahu jimiž je přidání, editace a mazání položek. Velkou výhodou během implementace byla možnost znovupoužití kódu. Tyto funkce pracují většinou se vstupy zadanými uživateli prostřednictvím formulářů. Zde se osvědčí použití frameworku, neboť ten disponuje řadou tříd sloužících k omezení bezpečnostních rizik, které vznikají při získávání dat z formulářů. Do těchto tříd patří především třídy z komponenty Zend_Filter. Pro představu uvádím funkci ošetřující uživatelský vstup od nežádoucích znaků. $filter = new Zend_Filter_StripTags(); $username = $filter->filter($this->_request->getpost( username )); $vocative = $filter->filter($this->_request->getpost( vocative )); 4.7 Použité komponenty Zend frameworku V této kapitole se chci zaměřit na komponenty, které mi výrazně zjednodušily implementaci nebo zvýšily kvalitu systému. Většina z těchto komponent patří k hojně užívaným, proto k nim lze nalézt dostatek zdrojů, ze kterých lze při práci s těmito komponentami čerpat Zend_Auth Užitečná komponenta, kterou využívám v procesu přihlašování uživatelů. Tento interface je použit v IndexControlleru a VendorControlleru pro přihlášení buď do administrace, nebo do sekce pro podporu prodeje, to vše v závislosti na zvoleném controlleru. Interface Zend_Auth by bylo možné zapsat pouze v IndexControlleru a umožňoval by totéž, pouze by bylo třeba ověřovat uživatelskou roli a na jejím základě uživatele přesměrovat do příslušné sekce (administrace nebo podpora prodeje). Důvod, proč jsem zvolil tuto metodu použití prakticky totožné funkce v obou controllerech je především v použítí funkce Zend_Auth. Tomuto interface se zadávají informace o tabulce v níž máme uživatele uloženy, typicky uživatelské jméno a heslo, a on sám se již postará o výběr dat a jejich vyhodnocení. Může

34 20 KAPITOLA 4. REALIZACE se tedy stát, že uživatele rozdělíme do dvou tabulek na správce systému a koncové prodejce. Pokud by jsem tedy použili tuto funkci v pouze v IndexControlleru, museli bychom před samotným provedením autorizace vyhodnotit, kterou tabulku má Zend_Auth pro porovnávání použít. Tento způsob by pak byl již velmi nepřehledný a také by zvýšil délku samotného přihlašování. Z tohoto důvodu jsem tuto komponentu využil v obou controllerech. Další výhodnou Zend_Auth je fakt, že informace o přihlášeném uživateli máme k dispozici po celou dobu přihlášení v session. K těmto údajům se pak můžeme dostat jednoduše pomocí následujícího kódu: $auth = Zend_Auth::getInstance(); $identity = $auth->getidentity(); $this->view->user = $identity; Objekt user, který máme nyní dostupný v šabloně view je vlastně reprezentací řádku tabulky na němž se nachází daný uživatel. Informaci o uživatelském jméně pak v šabloně zobrazíme například takto: <h1>uživatel - <?php echo $this->user->username;?></h1> Zend_Acl Zend_Acl řeší jednoduchým způsobem definici uživatelských rolí a jejich oprávnění. Protože systém, který implementuji využívá hned několik typů uživatelských rolí, bylo použití přístupu pomocí Zend_Acl opravdu výhodné. Na Zend_Acl mi především vyhovuje jednoduchý přístup k dědění rolí. Tímto jsem jednoduše dosáhl požadavku na vzájemné vztahy mezi rolemi, vizte diagram rolí na obrázku 3.2. Ukázka dědění rolí: $this->addrole(new Zend_Acl_Role( everyone )); $this->addrole(new Zend_Acl_Role( admin ), everyone ); $this->addrole(new Zend_Acl_Role( seller ), admin ); $this->addrole(new Zend_Acl_Role( servis ), array( admin, seller )); $this->addrole(new Zend_Acl_Role( editor ), servis ); $this->addrole(new Zend_Acl_Role( supervisor ), editor ); //role koncového prodejce $this->addrole(new Zend_Acl_Role( vendor ), everyone ); Zend_Controller_Router Jedním z požadavků bylo také použítí hezkých URL. K tomuto účelu je možné využít abstraktní třídy Zend_Controller_Router_Abstract s níž jsem si vytvořil potomka MivvyRouter. Tomuto routeru jsem nadefinoval pravidla, podle nichž hezké URL zaměňuje za volání action a controllers.

35 4.7. POUŽITÉ KOMPONENTY ZEND FRAMEWORKU 21 Výsledná adresa URL pak může vypadat následně: prehravace/mivvy-record-h2/47. Oproti zažitému trendu uvádím v adrese také ID přístroje. Může totiž nastat nejednoznačnost ve jméně zobrazovaného produktu a právě pro tyto případy uvádím id produktu na konci adresy. Podobný systém užívá například server novinky.cz. Systém pravidel pak vypadá takto: switch ($path[2]) { case LOGIN: $actionname = "login"; break; case PRODUKTY: $actionname = "products"; break; case "..." Při implementaci této záležitosti jsem však narazil na problém, který byl v rozporu s požadavkem na vícejazyčný systém. Obsah stránek se sice generoval v závislosti na zvoleném jazyce, ale URL zůstávala stále ve stejném jazyce. Proto musely být definovány sady jazykových konstant. Tyto sady se pak mění v závislosti na zvoleném jazyce. Nevýhodou tohoto řešení je to, že v případě kdy je třeba přidat další jazyk, je nutné pro tento jazyk vytvořit soubor obsahující kromě původní i novou sadu konstant, a tato se pak musí přepsat stávajícím souborem Zend_PDF Jedním z požadavků bylo také vytvoření reklamačního protokolu v PDF (ukázku tohoto PDF protokolu naleznete v příloze). Pro tento účel jsem tedy využil komponenty Zend_PDF. Postup vytváření PDF je podobný jako pro dvou-dimenzionální kreslící programy. Výsledné PDF je totiž sledem příkazů určujících pozici prvků. Nejlépe však tento postup vyjádří ukázka kódu: $PDF1 = new Zend_PDF(); $PDF1->pages[] = ($page1 = $PDF1->newPage( A4 )); $width = $page1->getwidth(); $height = $page1->getheight(); $page1->drawline(40,$height-90,40,$height-198); $page1->drawline($width-40,$height-90,$width-40,$height-198); Problém se však vyskytl v podpoře češtiny, jejíž znaková sada není zcela optimálně podporována. Z tohoto důvodu je nutné nadefinovat i typ použitého písma plně podporujícího české znaky. Toto písmo je pak exportováno společně s výsledným PDF.

36 22 KAPITOLA 4. REALIZACE Nevýhodou tohoto postupu je velikost výsledného PDF souboru. Původní systém generoval PDF soubory o velikosti 480 kb, což bylo opravdu mnoho. Zvolením optimálního písma pak klesla velikost souboru na 250 kb Zend_Validate Další užitečnou komponentou je Zend_Validate. Tato slouží k validování uživatelských vstupů, v případě chybného vstupu pak systém vrátí chybovou zprávu. Zde jsem si z třídy Zend_Validate_Abstract vytvořil potomka PasswordStrength pro kontrolu hesla. U hesla kontroluji minimální délku a shodu zadaných hesel. Této metody jsem užil také v některých dalších controllerech. 4.8 Implementace nestandardních řešení V systému se vyskytlo několik méně standardních řešení. K takovým patří například ty, ve kterých je nutno použít fragment logické vrstvy ve vrstvě prezentační. Pro tyto účely slouží v zendu tzv. view helpery. Jádrem view helperu je funkce, která vrací hodnoty na základě parametrů získaných z views. Těchto helperů jsem pak využíval především při výpisech dat z databáze (typicky v přehledu produktů) Zjištění stavu reklamace Tento helper má za úkol na základě vstupní hodnoty, kterou představuje informace o stavu objednávky, vrátit objekt, který říká jaký obrázek se má použít a také obsah atributu alt a title. Volání tohoto helperu z views vypadá následovně: $status = $this->getstatusicon($rma[ status ]); <img src="<?php echo $status->file.$i;?>.gif" alt="$status->alt" title="$status->title" /> Proměnná i zajišťuje také načtení obrázku na základě aktuálního řádku. Obrázky jsou totiž uloženy ve formátu edit_0.gif a edit_1.gif a každý z těchto obrázků má jiné pozadí. Cílem je zvýšit přehlednost tabulky Zjištění dostupné lokalizace K zobrazení dostupných lokalizací opět využívám view helperu. Funkci tohoto helperu předávám ID a tabulku, v níž se má vyhledávat.

37 4.9. IMPLEMENTACE WYSIVYGOVÉHO EDITORU Genrerování čísla RMA protokolu K účelům rychlé orientace a možnosti zakládání reklamačních protokolů dle daného pravidla bylo potřeba jednoznačně určit číslo protokolu. Tento požadavek jsem zajistil vygenerováním čísla, jež se skládá z data zadání reklamace spojeného a pořadím reklamace v daném měsíci. Označení RMA protokolu pak může vypadat například takto: /13. Problémem bylo vynulování tohoto pořadí vždy prvního dne v měsíci. V úvahu přicházela různá, avšak poměrně složitá řešení v podobě kombinace MySQL dotazů, čemuž jsem se vyhnul poměrně zajímavým a jednoduchým řešením. Pořadí reklamací uchovávám ve zvláštní tabulce kterou vynuluji pomocí skriptu spouštěného službou Cron, jež běží na webovém serveru. Cron tedy spustí skript, vždy první den nového měsíce. Z důvodu tohoto řešení pak plyne požadavek na dostupnost služby Cron na hostovaném serveru. 4.9 Implementace wysivygového editoru Implementace wysivygového editoru spočívá ve zkopírování souborů do adresáře v nichž uchovávám javascriptové skripty. Následně pak v definici javascriptového odkazu v hlavičce layoutu. Jedním z problému byl fakt, že wysivigový editor nebyl potřebný na všech stránkách a na některých přímo vadil. Tento editor totiž explicitně využívá elementu textarea a každý takovýto element měl v systému poté vlastnost wysivigového editoru. Toto působilo problém především v části servis, kde textarea předávala kromě vlastního obsahu i strukturu HTML kódu, který nebylo možné odfiltrovat, následkem čehož se tento kód vytiskl jako prostý text do reklamačních protokolů. Wysivygový editor je však v podstatě potřeba pouze v modulu produktů. Proto byl do layoutu administrace doplněn následující kód: <script type="text/javascript"> tinymce.init({ <?php if ($controllername!= products ) echo mode : FALSE, ; else echo mode : "textareas", ;?> Parametr mode nastavuje v jakém režimu se má wysivyg použít. V případě, že je mód nastaven na FALSE se nebude editor vůbec inicializovat.

38 24 KAPITOLA 4. REALIZACE 4.10 Implementace Mootools LightBox Jelikož se na stránce budou prezentovat produkty, u nichž hraje vzhled a tudíž i ilustrační fotografie velkou roli, bylo žádoucí implementovat některý z nástrojů pro slideshow obrázků. K tomuto účelu jsem využil LightBox postavený na frameworku Mootools. Instalace tohoto nástroje je podobná jako u instalace TinyMCE. Nejprve je třeba zkopírovat zdrojové soubory Mootools a LightBox do adresáře s javascripty a poté inicializovat tento skript v hlavičce šablony. Pakliže chceme obrázek zobrazit pomocí LightBox je potřeba uvést do odkazu následující kód: <a href="obrazek" rel="lightbox" " >LighBox</a> 4.11 Implementace grafického rozhraní Nedílnou složkou systému je grafické prostředí. Zde jsou požadavky kladeny především na přehlednost a intuitivní ovládání. Důležitým faktorem je také rychlost načítání stránek, která je nepřímo úměrná počtu bitmapové grafiky použité na stránkách. Vzhled tohoto prostředí jsem navrhl v grafickém programu Adobe Photoshop CS4. Následně jsem tento design převedl do XHTML šablony s využitím kaskádových stylů. Pro administrační rozhraní jsem volil standard CSS 3. Tento umožňuje vytvářet například stíny a kulaté rohy kontejnerů, to vše bez použití bitmapové grafiky. Tímto se výrazně zmenší velikost načítaných stránek a zvýší se celková rychlost. Bohužel tyto vlastnosti standardu CSS 3 zatím není možné použít ve front-endu, jelikož mnoho dnes používaných prohlížečů tento standard zatím nepodporuje a na rozdíl od administračního rozhraní nelze podmínit používání určitého typu prohlížeče Problémy během implementace Největší problémy během implementace jsem měl s některých javascriptovými funkcemi. Většinu funkcí se mi podařilo zprovoznit na testovacích statických stránkách avšak po přesunutí do frameworku se tyto funkce nepovedlo zprovoznit. A tak se systém musel obejít bez náhledu obrázků během uploadu, vyjíždějících tooltip nabídek a validace vstupních dat. Naštěstí stěžejní funkce jako TinyMCE a LightBox byly implementovány bez problémů Implementace instalátoru Instalace aplikace je prvním setkáním uživatele se systémem. Proto je důležité zjednodušit tento postup na přijatelnou úroveň. Instalátor je řešen pomocí dynamické PHP stránky s formulářem, kterou jsem postavil mimo Zend framework. Tato stránka má za úkol získat data o databázi, kterou bude systém využívat jako uložiště dat.

39 4.13. IMPLEMENTACE INSTALÁTORU 25 Tento instalátor ověří zda-li zadaná databáze existuje, v případě že ano připojí se k této databází a vytvoří v ní potřebné tabulky s počátečním nastavením. Dále provede změnu přístupových privilegií u adresářů, do kterých musí mít aplikace právo zapisovat data. Dalším krokem je také vytvoření konfiguračního souboru na základě zadaných informací o databázi. Tento konfigurační soubor pak využívá systém k přístupu do databáze. Po ukončení instalace se tato stránka odstraní a to proto, aby nedošlo k další instalaci, čímž by byla přepsána stávající databáze.

40 26 KAPITOLA 4. REALIZACE

41 Kapitola 5 Testování 5.1 Testování front-end části Jelikož byl kladen požadavek na využití stávajícího grafického rozhraní webové prezentace zaměřil jsem se pouze na faktory, které přímo neovlivňovaly vzhled prezentace Validace dle standardů W3C Tato validace probíhala prostřednicím on-line nástroje konzorcia W3C dostupného na adrese validator.w3.org. Stránky dostupné ve front-end části, které byly po provedených testech nevalidní, dle standardu XHTML Strict 1.0 (UTF-8), byly opraveny a validovány znovu, dokud neprošly úspěšně testem validace Zobrazení prezentace Ověřování korektnosti zobrazení prezentace probíhalo testováním prezentace ve většině hlavních webových prohlížečích. Webová prezentace se zobrazuje korektně na běžně používaných prohlížečích jako jsou Internet Explorer 7/8, Mozilla Firefox 3, Google Chrome 2, Opera 9/10 a Safari 3/ Přístupnost formuláře registrace koncového prodejce Na vzorku deseti uživatelů bylo testováno zda-li formulář působí srozumitelně a požadováné položky jsou jednoznačné. Zde muselo dojít k několika úpravám. Pro zajištění větší přehlednosti byl výsledný formulář rozdělen do několika části. Dále bylo třeba jednoznačně rozdělit vstupní položky. A to na položky prezentované na Internetu v rámci seznamu koncových prodejců a na položky sloužící pouze pro interní účely společnosti. Bylo nutné zavést javascriptovou kontrolu vstupních dat. 27

42 28 KAPITOLA 5. TESTOVÁNÍ Přístupnost formuláře pro vložení nové reklamace Tento formulář byl odladěn během ostrého provozu, dále doplněn o javascriptovou validaci a o položky, které během analýzy a v době implementace nebyly známy Fulltextové vyhledávání Jedním z požadavků byla implementace fulltextového vyhledávání. Během testování se však tato metoda vyhledávání příliš neosvědčila, jelikož vracela příliš velké množství dat, což snižovalo relevanci. Toto si vysvětluji tím, že databáze produktů, ve které se vyhledává, obsahuje příliš mnoho stejných řetězců, zejména pak ve specifikacích. Tato metoda se v praxi využívá především u systémů se značným množstvím textových dat, a to zejména pro její rychlost. Tato výhoda zde nehraje velkou roli, jelikož se nepočítá s velkým objemem textů v databázi. Z tohoto důvodu bylo místo této metody vyhledávání implementován jednoduchý princip vyhledávání pomocí operátoru Like Přístupnost vyhledávačů Grafické zpracování prezentace bohužel příliš neodpovídá požadavkům na SEO optimalizaci, jelikož obsahuje malé množství relevantního textu (např. úvodní stránka) a velké množství obrázků. Ve vyhledávačích Google a Seznam jsem tedy testoval zejména řetězce charakteristické pro jména produktů a to cca 5 týdnů po ostrém spuštění systému, kdy již bylo možné předpokládat že již proběhlo indexování stránek v databázích prohlížečů. Výsledky byly přinejmenším uspokojivé. Na rozdíl od staré verze stránek vyhledávaly prohlížeče odpovídající výsledky. Úspěch v tomto testu přikládám především optimalizaci URL adresy na hezká URL a automatickém generování atributů alt a title ze jména produktu. 5.2 Testování back-end části Během vývoje systému se na testech a konzultacích podílel pracovník společnosti mivvy primárně zodpovědný za webovou prezentaci. To napomohlo k celkové optimalizaci systému dle přání zadavatele. 5.3 Korektnost zobrazení uživatelského rozhraní Tento test probíhal stejně jako při testování front-end části. Uživatelské rozhraní se zobrazuje korektně v prohlížeči Safari. Na tento prohlížeč byl kladen důraz se strany pracovníka zodpovědného za webovou prezentaci.

43 5.4. TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ 29 S menšími rozdíly se pak stránky zobrazují v prohlížečích Chrome, Firefox 3, Opera 9.6. Vliv na odlišné zobrazení mají především grafické prvky samotných prohlížečů (typicky tlačítka, výběrová menu, aj.) Hlavním požadavkem na prohlížeč je podpora standardu CSS 3. V prohlížečích nepodporujících tento standard není zajištěno vykreslení kulatých rohů a celkový vzhled se může mírně lišit. 5.4 Testování uživatelského rozhraní Tento test probíhal tak, že jsem pozoroval práci uživatele se systémem aniž bych jej podrobně seznámil s funkcionalitou systému. Na základě získaných informací jsem pak upravil průchody mezi jednotlivými stránkami a provedl potřebné změny v popisech sekcí, formulářů atd. Dále bylo třeba některé vstupní formuláře doplnit o tlačítko zpět a ve formulářích, které obsahují více prvků, bylo třeba odlišit hlavní tlačítko, které vyvolává požadovanou akci. 5.5 Přínosy testování back-end části V následujících podkapitolách popíši některé příklady změn, ke kterým došlo na základě testování pracovníkem společnosti mivvy Formulář lokalizace produktu Během lokalizace produktu do jiného jazyka bylo vždy třeba opětovně zadat kompletní specifikaci produktu v daném jazyce. Pro zjednodušení práce načítám do formuláře produktu v další lokalizaci data primárního jazyka (češtiny). Lokalizovaný text technických specifikací se totiž mnohdy liší jen v předložkách. Vložením vzoru specifikace v českém jazyce se tak podstatně zjednodušila práce při přidávání dalších lokalizací Vyhledávání reklamací Oproti původní myšlence filtrování zobrazených reklamací pouze podle jejich stavu se objevil požadavek na vyhledávání podle zadaného řetězce. Shoda s tímto řetězcem se pak vyhledává v RMA i sériových číslech. Mnohdy je totiž třeba vracet se k zadaným reklamacím, případně může nastat situace, kdy má technik k dispozici opravený výrobek z továrny, kde jediným jednoynačným údajem je sériové číslo produktu Ukládání nastavení filtrů Další záležitostí, která vyšla na povrch až během testování byla nutnost uchovat stav třídících filtrů i během práce s produktem.

44 30 KAPITOLA 5. TESTOVÁNÍ Často vykonávaným úkolem je například změna parametrů u všech produktů splňující určité kritérium. Pro efektivitu tohoto úkolu bylo třeba zajistit, aby se uživatel po úspěšné editaci produktové karty vrátil zpět na výpis produktů, který si v předešlém kroku dle zadaných parametrů vyhledal.

45 Kapitola 6 Závěr 6.1 Naplnění cíle práce Z hlediska zadání bakalářské práce se domnívám, že systém splňuje veškeré požadavky na tuto práci kladené. Výsledný systém, jak se zdá, bude také spolehlivě splňovat požadavky společnosti mivvy a.s.[1], a co více, především na úrovní zpracování jde daleko za rámec těchto požadavků. Celý projekt jsem se snažil řešit tak, aby výsledek tvořil kvalitní platformu pro další případná použití systému. Během implementace systému jsem se naučil pracovat s mnoha novými technologiemi, což osobně považuji za největší přínos této práce. 6.2 Další rozvoj projektu Další rozvoj projektu spatřuji zejména v jeho směřování k uživatelsky přivětivému a jednoduchému CMS, s nímž bude možné najít mnoho uplatnění na trhu. Jako ideální příležitost pro využití systému se mi jeví právě ty, které mimo běžnou správu obsahu vyžadují další funkční prvky - podobně jako mivvy a.s. sekci pro podporu prodeje. V implementační rovině se nachází celá řada vylepšení, která ještě plánuji do systému zahrnout, jde především o zapracování technologií hromadného odběru, dokonalejší editaci vzhledu stránek či širší možnosti ve správě sekcí. 31

46 32 KAPITOLA 6. ZÁVĚR

47 Literatura [1] mivvy a.s. oficiální stránky zadavatele projektu. [2] Wordpress 2.8 populární blogovací systém šířený pod GPL licencí. verze 2.8., ke dni [3] AiPublisher redakční CMS systém verze Standard, ke dni [4] jnetpublish Profesionální web content management systém pro realizaci a snadnou správu dynamických www prezentací. verze 2.8., ke dni [5] Nette 0.8 MVC framework z dílny Nette Foundation šířený pod GPL licencí verze 0.8 stable, ke dni [6] Cake 1.2 MVC framework verze 1.2 stable, ke dni [7] Zend oficiální stránky použitého frameworku. verze 1.8.1, ke dni [8] Zend Studio 6 výkonné IDE s přímou podporou Zend frameworku. verze 6.1.2, ke dni