Návrh a implementace lehkého CMS

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Návrh a implementace lehkého CMS BAKALÁŘSKÁ PRÁCE Václav Muzikář Brno, jaro 2015

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Jaroslav Bayer

3 Poděkování V první řadě bych chtěl poděkovat vedoucímu své bakalářské práce RNDr. Jaroslavu Bayerovi za vstřícnost, podporu a poskytnuté rady. Dále chci poděkovat své rodině za podporu a obětavost, bez nichž by mé studium, a tedy ani tato práce, nebylo uskutečnitelné. V neposlední řadě také děkuji společnosti Evaluate Dynamics s. r. o. za umožnění zpracování tématu této práce.

4 Shrnutí Tato práce se zabývá návrhem a implementací systému typu CMS. Při vývoji byl kladen důraz na lehkost výsledného řešení. Systém je navržen jako platforma pro vývoj a provoz webových portálů. Tato platforma tak poskytuje základní nástroje a implementaci, která je využitelná ve výsledných projektech, čímž je zrychlen a ulehčen jejich vývoj. Dále tato platforma poskytuje integrovanou podporu pro modulární administraci daného portálu.

5 Klíčová slova CMS, WCMS, PHP, Nette, framework, PHP, MySQL, modularita, kompaktnost, MVC, MVP

6 Obsah 1 Úvod CMS jako webová aplikace Cíle práce Struktura práce Analýza současného řešení Analýza požadavků Rešerše existujících CMS Návrh systému Použitý jazyk Návrhový princip SOLID MVC architektura MVP architektura Struktura návrhu v rámci MVP architektury Vrstva Model Vrstva View Vrstva Presenter Návrh rozhraní backend jako modulárního systému Návrh rozhraní frontend Implementace CMS Použitá platforma framework Vývoj na platformě Nette Framework Návrhový vzor Dependency Injection Vrstva Presenter Routing Vrstva View Rozšíření jazyka PHP HTML formuláře Adresářová struktura Datová vrstva

7 5.4.1 Třída BaseDbElement Třída BaseDbItemModel Třída BaseDbListModel Rozhraní backend Hierarchie tříd typu Presenter Registr modulů Řízení přístupu Užití CMS Vývoj komponent datové vrstvy Třídy Element Třídy Item Třídy List Použití datové vrstvy Vývoj modulů rozhraní backend Rozhraní frontend Závěr Reference Příloha A Příloha B

8 1 Úvod WCMS 1, obecněji CMS 2, je dnes nedílnou součástí mnoha webových projektů. Lze jej chápat jako koncept, který umožňuje bez znalosti programovacích a značkovacích jazyků komplexně spravovat a tvořit obsah, v tomto případě webových stránek, jako jsou texty, multimediální obsah, struktura a vzhled webu a další typy obsahu dle použitého CMS, resp. jeho rozšíření. Je takto možné výrazně snížit časové i finanční nároky na úpravu webu není třeba, aby ji prováděl odborník. Provozovat některé webové portály by tak bez použití CMS bylo výrazně náročné, např. zpravodajské weby s velkým množstvím nového denního obsahu. CMS může být implementováno různými způsoby. Nejčastější z nich jsou: Online webová aplikace, která je typicky rozdělena na frontend 3 a backend 4, např. Joomla [23]. Offline aplikace, která slouží pro vygenerování statického webu, např. Blatter [24]. Kombinace výše zmíněného. 1.1 CMS jako webová aplikace Jak bylo uvedeno, základní dělení aplikace bývá na veřejně přístupné rozhraní frontend a neveřejné backend [1]. Pro přístup k rozhraní backend je nutná autentizace a autorizace uživatele. Typické pro tento typ CMS je rozdělení přístupových práv do několika úrovní, čímž je zajištěna kooperace mezi uživateli při správě obsahu, přičemž je možné omezit přístup do určitých částí systému pro určité uživatele. Dále je také obvyklé formátování textů pomocí WYSIWYG 5 editoru a definice podporované funkcionality pomocí tzv. rozšíření 6. CMS jako webovou aplikaci používá i společnost Evaluate Dynamics s. r. o., která na tomto konceptu provozuje a vyvíjí několik vlastních webových projektů. Nejnavštěvovanějším 7 z nich je tematicky zaměřený portál 1 Web Content Management System, taktéž někdy označováno jako WCM 2 Content Management System 3 V kontextu této práce veřejná webová stránka 4 V kontextu této práce administrační část 5 What You See Is What You Get editace, která je vzhledově totožná s výslednou formou 6 Označováno také jako moduly plugin 7 Dle interních měření Google Analytics za rok

9 Slunečno.cz 8 se specializací na informace a předpověď počasí, který je na trhu od roku Za tu dobu prošel výrazným vývojem, co se týká obsahové i funkční složky. Tento portál i další portály výše uvedené společnosti se i nadále vyvíjí, avšak předchozí vývoj probíhal poměrně urychlenou formou bez správné analýzy a návrhu. Vyskytuje se v nich tak řada návrhových a implementačních nedostatků, a je tak vhodné provést analýzu a reengineering či úplné nahrazení stávajícího řešení. 1.2 Cíle práce Cílem této práce bude návrh a implementace systému typu webového CMS, který bude odpovídat požadavkům uvedené společnosti. Tento systém bude vyvinut s použitím a modifikací stávajícího řešení, příp. jiného konvenčního systému podobného typu. V případě, že nebude nalezen dostačující systém, který by posloužil jako základ požadovaného CMS, bude navrhnut a implementován systém nový. 1.3 Struktura práce V úvodních kapitolách je provedena analýza současného systému a vyvozeny požadavky, které by měl systém splňovat. Dále je proveden návrh systému v teoretické rovině včetně popisu některých použitých návrhových principů. Následující kapitola je věnována implementaci systému. Zde je přiblížena platforma, na které je systém postaven. Dále jsou zde popsány základní systémové třídy. V další částí následuje praktický příklad použití tohoto systému. V závěru jsou shrnuty výsledky této práce a je nastíněn další možný vývoj implementovaného systému

10 2 Analýza současného řešení Webové projekty uvedené společnosti jsou zejména postavené na platformě programovacího jazyka PHP a relační databáze MySQL. Pro tyto projekty je vyvinuto kompletně vlastní řešení, nepoužívá se žádný zavedený PHP framework ani CMS, zdrojový kód je psán čistě v základním PHP. Vzniká zde tak řada návrhových problémů, které sdílí prakticky všechny projekty této společnosti: Aplikace není robustně navržena. Není použita žádná vhodná struktura či návrhový vzor, části zdrojového kódu se často opakují. Naprostá většina je psána procedurálně, nikoli objektovým přístupem, což v tomto případě přispívá ještě k menší přehlednosti. Ve výsledku je tak zdrojový kód velmi nepřehledný a obsahuje pravděpodobně i množství bezpečnostních chyb. K aplikaci chybí jakákoliv dokumentace, komentáře v rámci zdrojového kódu jsou pouze ojedinělé. Vlastní kód ani šablony vzhledu webu nejsou od sebe nijak odděleny. Aplikační logika je v souborech PHP promíchána s HTML kódem, neexistuje zde žádná forma systému pro šablony 9. Jakákoliv změna aplikační logiky tak zpravidla ovlivní celou aplikaci, je zde vysoká míra závislosti všech částí mezi sebou. Dalším problémem je, že většinu minoritních změn, které se týkají vzhledu stránek či reprezentace dat, musí vykonávat odborník, programátor, z důvodu uvedené provázanosti kódu. Backend je řešen jako samostatná webová aplikace sdílející s rozhraním frontend pouze data v databázi aplikační logika je tedy roztříštěna a zdvojena mezi rozhraní frontend a backend. Přístup k databázi je řešen pomocí zastaralého MySQL API 10, a nepoužívá se tak žádný z obecných ovladačů, díky čemuž by při eventuální změně databázového serveru bylo nutné velkou část projektu přepsat. Další vývoj a údržba jsou díky uvedenému problematické a dále neudržitelné, zvláště s přihlédnutím k rostoucí velikosti projektu a s tím spojeným případným rozšířením vývojového týmu. 9 Aplikační vrstva oddělující uživatelské rozhraní aplikace od aplikační logiky. Označováno někdy též jako šablonovací systém či v angličtině template engine

11 Z výše uvedeného vyplývá, že stávající řešení nesplňuje požadavky na systém typu CMS [2] a není vhodné je kvůli uvedeným nedostatkům v jakékoliv formě zachovat pro budoucí, ani pro rozšiřující se stávající projekty. Reengineering tedy není dostačující volbou. Bude nutné najít nové řešení vyhovující pro webové portály této společnosti, které na něm budou dále stavět. 6

12 3 Analýza požadavků Požadavky na nový CMS do značné míry vyplývají z požadavků společnosti Evaluate Dynamics na provoz a integraci do současných systémů, avšak požadovaný systém by měl být jako platforma co nejvíce univerzální pro zachování variability pro budoucí projekty. Jejich ucelený seznam je: Serverová část systému musí být napsána v jazyce PHP [27] a kompatibilní s verzí 5 tohoto jazyka. Databázová část musí podporovat nejpoužívanější [3] relační databázové servery typu open source, konkrétně MySQL [22] (popř. jeho alternativní vývojovou větev MariaDB [25]) nebo PostgreSQL [26]. Systém bude provozován jako čistě webová aplikace, kompletně přístupná pouze pomocí současných webových prohlížečů. Měl by podporovat moderní standardy HTML5 [28]. Z části by se mělo jednat o platformu framework, která urychlí vývoj, ale zároveň nesníží kvalitu a přehlednost návrhu. Systém by měl být navržen objektově, čímž bude zajištěna robustnost a bude umožněno sdílení množství komponent mezi projekty. Systém bude obsahovat předpřipravený backend, který jako platforma bude společný pro všechny projekty. Jeho konkrétní funkcionalita by měla být definována modulárně, pomocí rozšíření. Systém bude koncipován jako lehký. Musí být kladen důraz rychlost, resp. nenáročnost systému, vzhledem k tomu, že na něm budou stavět funkčně náročné webové portály s vysokou mírou návštěvnosti. Systém by proto v základu měl být oproštěn od všech nadbytečných funkcí, které nejsou pro běh všech portálů kritické a společné. Užší specifická funkcionalita bude určena až pomocí rozšíření. Měl by tak sloužit zejména jako platforma. Vývoj portálů stavějících na tomto systému musí být snadný a rychlý, avšak při zachování robustního a přehledného návrhu. Dále musí být kladen důraz na pokud možno co nesnadnější konverzi stávajících portálů uvedené společnosti. Systém musí splňovat alespoň základní prvky ochrany proti nejběžnějším útokům. Systém bude podporovat SEO Search Engine Optimization 7

13 3.1 Rešerše existujících CMS Jako nový CMS je možné použít některý z již zavedených systémů, jako jsou např. WordPress [29], Drupal [30], Joomla [4], PHP-Fusion [31], CMS Made Simple [14] a mnoho dalších [39]. Tyto systémy však zpravidla nesplňují všechny uvedené požadavky, zejména co se týče náročnosti na systémové zdroje a vývojové schopnosti. Jak bylo zmíněno a jak je definováno i v názvu práce, systém musí být koncipován jako lehký. Ve výsledku by se tak mělo jednat spíše o platformu než v základu samostatně provozuschopnou aplikaci. Mělo by se tedy více jednat o systém typu framework, který bude splňovat požadavky společnosti, zejména co se týče rychlosti a snadnosti vývoje, a tedy i snadnost konverze stávajících projektů, a nad touto platformou postaveným společným rozhraním backend, přičemž frontend bude velice specifický pro každý projekt. Tento CMS má tedy sloužit zejména jako nástroj a platforma pro vývojáře konkrétního portálu. Konvenční CMS jsou zpravidla koncipovány jako bohatě vybavený nástroj pro uživatele bez hlubších technických znalostí k naplnění nějaké webové šablony vlastními daty. Jejich zaměření je tedy odlišné od vyvíjeného CMS. Z tohoto důvodu se jeví jako lepší alternativa navrhnout a vyvinout CMS nový, na míru potřebám a požadavkům této společnosti, avšak stále dostatečně univerzální. Budou tak splněny všechny požadavky, zejména co se týče snadnosti vývoje a konverze stávajících portálů. 8

14 4 Návrh systému Základní návrh CMS, a tedy i platformy framework, je klíčový, vzhledem k tomu, že na něm budou stát dále další rozšíření, a tedy ze své podstaty i celý webový portál. Je proto nutné dát na tento návrh zvlášť důraz a používat vhodné návrhové vzory. 4.1 Použitý jazyk Z požadavků vyplývá, že hlavním programovacím jazykem projektu bude PHP. Návrh proto musí brát v úvahu tento jazyk. PHP podporuje procedurální i objektově orientované paradigma. V tomto případě se jednoznačně jeví jako vhodnější použití objektově orientovaného paradigmatu, které umožní rozdělení celé aplikace na komponenty a jejich případné sdílení mezi projekty. 4.2 Návrhový princip SOLID Pro objektový návrh existuje pět základních návrhových principů souhrnně označovaných SOLID [7]: Single Responsibility Principle. Každá třída by měla mít pouze jedinou zodpovědnost, měla by být zodpovědná za plnění pouze jednoho funkčního požadavku. V případě změny požadavků na aplikaci by měl být důvod ke změně této třídy právě jeden. Open Closed Principle. Třída by měla být otevřená tak, aby umožnila pomocí dědičnosti modifikaci své funkčnosti. Zároveň by měla být ale uzavřena, aby nebylo nutné pro tuto modifikaci dělat úpravy přímo na této třídě. Nemělo by tak být nutné pro přidání nové funkčnosti, resp. splnění nových požadavků editovat stávající kód. Liskov Substitution Principle. Pokud nějaká třída používá třídu A, pak je možné třídu A nahradit třídou B, která je potomkem třídy A. Je tak tedy možné nahradit předka potomkem, který musí splňovat to, co bylo definováno v jeho předkovi. Ve výsledku by porušení tohoto principu znamenalo, že potomek nějak zásadně mění funkcionalitu svého předka, což by bylo v rozporu s konceptem dědičnosti. Interface Segregation Principle. Princip, který řeší problém příliš velkých rozhraní. Třída by neměla být nucena záviset na metodách, které nevyužívá. Třídy by měly být dostatečně diferencovány a rozděleny do 9

15 více tříd s menšími rozhraními, není tak vhodný koncept jedna třída pro všechno. Dependency Inversion Principle. Třída by měla být závislá pouze na třídách se stejnou nebo vyšší mírou abstrakce. V případě, že by např. vysoce abstraktní třída závisela na úzce specializované třídě, byla by díky tomu svázána pro pouze úzké použití. Vzhledem k tomu, že bude jazyk PHP použit v objektovém režimu, bude nutné se v zájmu kvalitního návrhu a jeho celkové robustnosti držet tohoto principu. 4.3 MVC architektura Dalším základním prvkem návrhu bude MVC 12 [5], resp. MVP 13 architektura, díky které bude umožněno rozdělení aplikační logiky (a její sdílení mezi rozhraním frontend a backend) a různých vzhledů, resp. pohledů na systém (rozhraní frontend a backend). Takto architektura staví na rozdělení aplikace do tří nezávislých vrstev: Model, View a Controller. Ačkoliv se konkrétní implementace může lišit, princip zůstává následující. Vrstva Model zde představuje aplikační logiku, která reprezentuje data. Nejedná se však o pouhý ovladač pro manipulaci s daty, např. v databázi, ale o jejich reprezentaci, typicky jako objekty s možností úpravy či čtení s pomocí metod. Tato vrstva tak obsahuje část aplikační logiky, data zde již mohou být např. do určité míry interpretovány, zpracovávány apod. Z pohledu ostatních vrstev přitom nezáleží, jak konkrétně jsou data ukládána, zda vůbec jsou perzistentně uložena či jsou např. úložiště kombinována, např. kombinace databáze a obrazových souborů přistupují k nim pouze pomocí rozhraní, které Model nabízí. Zároveň může být použit návrhový vzor Observer 14 [5], který umožní, aby aktualizaci ostatních vrstev inicioval přímo Model, např. při úpravě dat. Konkrétní interpretaci a výstup dat má na starosti vrstva View 15, která data získá z Modelu. Vrstva View zároveň nabízí možnost interakce s těmito daty, např. pomocí formulářů, avšak samotnou interakci zpracovává až Controller, viz dále. V případě webových aplikaci je vrstva View typicky implementována jako systém pro šablony, jehož výstupem je HTML. 12 Model-View-Controller 13 Model-View-Presenter 14 Česky označováno jako Pozorovatel, Vydavatel 15 Česky označováno jako Pohled 10

16 Vrstva Controller 16 přijímá a zpracovává požadavky od uživatele, např. stisk tlačítka nebo načtení stránky, a na základě nich upravuje data Modelu. Model upravuje aktualizuje Controller View interaguje Uživatel vidí 4.4 MVP architektura Obr. 1. Typický MVC návrh MVP architektura je speciální případ MVC architektury. Tyto architektury se liší ve způsobu implementace vrstvy Controller, kterou zde v tomto případě zastupuje Presenter [6]. Presenter zde typicky vystupuje jako prostředník mezi Modelem a vrstvou View, která je zde, na rozdíl od MVC, pouze pasivní. View tedy nedokáže získat data z Modelu přímo, ale pouze přes Presenter, který získá data, interpretuje je a předá vrstvě View pro výstup. V ostatních ohledech pracuje Presenter totožně jako v případě vrstvy Controller u MVC. 16 Česky označováno jako Řadič 11

17 Obr. 2. Typický MVP návrh Z uvedených důvodů je tato architektura vhodná pro webovou aplikaci, kde výstupem vrstvy View bude ve velké míře pasivní HTML. Pro její použití bude nutné vyvinout, resp. nasadit vhodný PHP framework, který ji bude podporovat. 4.5 Struktura návrhu v rámci MVP architektury Systém bude dělen do několika vrstev, což vyplývá z použití MVP architektury. Toto rozdělení umožní do značné míry nezávislost jednotlivých vrstev a sdílení komponent v rámci aplikace, ale i mezi různými projekty. Při návrhu těchto vrstev a jejich objektů je také nutné dbát na dodržení SOLID principu, čímž bude zajištěno, že aplikace bude dobře modifikovatelná a rozšiřitelná Vrstva Model Vrstva Model, která, jak bylo uvedeno, reprezentuje data aplikace, bude sdílená mezi rozhraními frontend a backend. Zároveň na ní bude stát klíčová část aplikace, je tedy nutné její návrh pečlivě zvážit. Naprostá většina datových návrhů v projektech uvedené společnosti sdílí obecnou strukturu, kterou je možné rozdělit do následujících podvrstev: Data jsou sdružena pod určitými datovými doménami, např. články. Tato vrstva bude dále v kontextu této práce a vyvíjeného CMS referována jako List. 12

18 Tyto domény pak seskupují konkrétní datové záznamy, např. konkrétní článek. Tyto záznamy dále ponesou označení jako vrstva Item. Každý ze záznamů se skládá z jednotlivých atributů, které nesou samotná data. Datové elementy mají každý své vlastnosti, která musí data, jež nesou, splňovat. Kromě typu, např. celočíselná hodnota nebo textový řetězec, se jedná např. i o konkrétní formát ( ová adresa). Jednotlivé položky této vrstvy se budou dále nazývat Element. Tato struktura se jeví ne nepodobná relačním databázovým systémům, na kterých jsou i portály uvedené společnosti založeny, avšak nejsou totožné. Vrstvy List, Item a Element nemusí (ale mohou) odpovídat skutečným tabulkám, řádkům a atributům databáze. Je tak možné, aby např. jeden objekt typu Element odpovídal ve skutečnosti několika nebo i žádnému atributu v databázi. Zároveň takto rozčleněná vrstva Model nemusí vůbec používat jakkoliv databázi. Návrh je tak univerzální, použitelný ve velkém množství případů, nejen v případě definované společnosti. Je vhodné přidat podporu pro tento datový návrh již do základního návrhu vyvíjeného CMS formou objektových předků. Objekty typu List, které odpovídají nějaké kolekci dat, budou vytvářet další dceřiné objekty typu Item, přičemž bude možné iterovat skrz tuto kolekci. Objekty Item dále vytváří a uchovávají ukazatele na své objekty typu Element, jež nesou samotná data. Budou zde tak do jisté míry využity návrhové vzory Factory a Iterator [5]. Zároveň zde bude dostupné veřejné rozhraní objektů typu List pro nastavení omezujících podmínek, které budou vyhledávané objekty Element splňovat. Díky tomu, že každá jednotlivá datová položka, např. název článku, je vyjádřena jako objekt, je možné s daty pracovat již na této úrovni daný objekt ví, jaká data nese, dokáže proto s nimi specificky manipulovat, příp. má i specifické rozhraní. Uvedené třídy List, Item a Element budou navrženy jen obecně, jako abstraktní. V systému tak budou existovat jejich instance pouze ve formě jejich konkrétních potomků, kteří zdědí základní funkcionalitu, např. pro iteraci nad objektem typu List, a zároveň specifikují další vlastnosti a metody specifické pro danou třídu, např. jaké konkrétní objekty typu Element, tedy jaké datové prvky přísluší např. článku Vrstva View Vrstva View zajišťující výstup a UI aplikace bude, jak již bylo nastíněno, rozčleněna do dvou nezávislých pohledů: frontend a backend. Tyto pohledy však budou sdílet stejnou vrstvu Model, díky čemuž bude sdílena i velká část aplikační logiky. V tomto případě bude tato vrstva implementována ve formě systému pro šablony, který bude zajišťovat výstup (ve většině případů) ve formátu HTML. Tento systém bude nutné implementovat, případě použít některý ze systému framework, jež jej podporuje. V případě MVP architektury 13

19 je tak tato vrstva do značné míry pasivní nemá k vrstvě Model přímý přístup, nezajišťuje autentizaci ani autorizaci uživatele apod. Z tohoto důvodu je vysoce podstatná vrstva Presenter Vrstva Presenter Presenter bude taktéž obsahovat část aplikační logiky. V navrhovaném CMS bude z většiny řídit běh celé aplikace, což zahrnuje mimo jiné zpracování přijatého požadavku, použití vhodných objektů vrstvy Model, interpretaci dat, předávání dat do vrstvy View, řízení činnosti HTML formulářů a následnou verifikaci uživatelsky zadaných dat, autentizaci a autorizaci uživatelů a další činnosti specifické pro danou funkcionalitu webu. Každá jednotlivá funkčně odlišená stránka webu bude mít vlastní třídu typu Presenter, přičemž budou mít společného objektového předka. 4.6 Návrh rozhraní backend jako modulárního systému Rozhraní backend bude implementováno na úrovni vrstev View a Presenter. Vrstvu Model bude sdílet s rozhraním frontend. Rozhraní backend bude dále členěno do jednotlivých sekcí, které budou zastřešovat jednu, příp. více komponent vrstvy Model, např. komponentu reprezentující články. Samotná vrstva Model bude vysoce diferencovaná jak vyplývá z uvedeného návrhu, jednotlivé komponenty této vrstvy budou v co největší míře nezávislé na zbytku systému a zcela nezávislé na ostatních vrstvách MVP. Tento návrh zde tak může sloužit jako uvažovaný modulární systém. Bylo by vhodné podobný princip uvažovat i v případě jednotlivých sekcí rozhraní backend. Tyto sekce, dále nazývané moduly, budou do jisté míry sdílet podobnou funkcionalitu: výpis položek, jejich editace, odstranění a přidávání. Samotnou specifickou manipulaci s daty přitom zajišťuje vrstva Model, jejíž jednotlivé komponenty jsou díky zachování Liskov Substitution Principle [7] do jisté míry vzájemně zaměnitelné. Nezáleží tedy, která z komponent bude použita aplikační logika pro práci s daty, jejich příp. konverzi apod. je obsažena přímo v těchto komponentách, resp. jejich rodičovských třídách. Každý modul tak bude umět např. vhodně vykreslit HTML formulář pro editaci údajů se správnými položkami pouze na základně dané komponenty vrstvy Model. Zároveň je však nutné zachovat určitou míru variability tak, aby jednotlivé moduly rozhraní backend byly svobodně modifikovatelné ve specifických případech ne vždy budou jednotlivé moduly zachovávat stejnou funkcionalitu, jak byla definována. To zahrnuje navrhnout objektovou strukturu 14

20 vrstvy Presenter těchto modulů tak, aby byla v případě nutnosti modifikovatelná bez nutnosti úprav zbytku systému a byl tak zároveň zachován SOLID princip [7]. Jako vhodný návrh se tak jeví takový, kde každý modul rozhraní backend bude mít vlastní třídu typu Presenter, která, jak bylo uvedeno, řídí běh aplikace, v tomto případě daného modulu. Všechny tyto třídy budou mít společného abstraktního předka, v němž bude definována výchozí funkčnost těchto modulů, jak byla definována: výpis položek, jejich editace, odstranění a přidávání. Zároveň však bude možné díky překrytí metod dosáhnout požadované úpravy funkčnosti, příp. při požadavku na radikálnější změny použít vyšší generaci objektového předka typu Presenter. Moduly budou používat taktéž společnou vrstvu View, kterou bude možné překrýt v závislosti na požadované funkcionalitě daného modulu. Zároveň bude možné tyto moduly řadit do určité logické hierarchie, dle níž budou mimo jiné i řazeny v rámci UI rozhraní backend. Každý modul tak může mít předka nebo potomky, např. modul Články může mít potomka Kategorie článků. Dále tyto moduly musí podporovat jistou formu ACL 17, resp. RBAC 18 [2], která bude v rámci rozhraní backend implementována. Je tedy nutné, aby byly moduly v systému jedinečně registrovány. Z tohoto důvodu bude každý modul reprezentován jako jedinečný objekt. Tento objekt ponese určité informace o konkrétním modulu, např. jeho jméno, jedinečný identifikátor, prioritu pro zmíněné hierarchické zařazení, odkazy na své potomky apod. I v tomto případě budou mít tyto objekty společného abstraktního objektového předka. V souhrnu je tedy rozhraní backend složeno z komponent, v tomto CMS nazývaných moduly. Tyto moduly obsahují vlastní objekty vrstev Presenter a View, avšak mohou, ale nemusí, upravovat výchozí funkcionalitu, kterou zdědili od objektových předků. Tato výchozí zděděná implementace umožňuje provádět základní funkce nad vybranou komponentou vrstvy Model. Výchozí implementace dynamicky reaguje na použitou komponentu a její položky typu Element. Dokáže tak např. korektně interpretovat data a zobrazit je jako seznam v tabulce či vykreslit patřičný HTML formulář pro jejich editaci. To vše bez jakékoliv další implementace v modulech rozhraní backend. Moduly ale neobsahují přímo žádné komponenty vrstvy Model, vzhledem k tomu, že je tato vrstva sdílená i s rozhraním frontend. Jedná se tak spíše jen o pohledy na jednotlivé komponenty vrstvy Model. 17 Access Control Lists metoda řízení přístupu k systému 18 Role-Based Access Control metoda řízení přístupu k systému na základě rolí 15

21 4.7 Návrh rozhraní frontend Vyvíjený CMS je koncipován jako lehký, bez nadbytečné funkcionality, s primárním účelem použití na webových portálech uvedené společnosti. Frontend všech těchto portálů je velmi specifický, příliš zde tedy nelze na všech aplikovat nějakou společnou funkcionalitu a šablonu UI je nutné jej vyvíjet na míru pro konkrétní portál. Jeví se proto jako vhodnější navrhnout a implementovat toto rozhraní zvlášť a individuálně pro každý portál. V CMS tak nebude implementována žádná forma WYSIWYG editoru pro návrh kompletního UI pro rozhraní frontend, jako tomu bývá zvykem v konvenčních CMS tohoto typu. Frontend však bude, stejně jako zbytek celé aplikace, používat MVP architekturu, bude postaven na systému pro šablony, který bude v CMS implementován a bude využíván i rozhraním backend, a bude používat komponenty vrstvy Model, které jsou společné i pro backend. Díky tomu naprostá většina aplikační logiky bude společná s rozhraním backend, a nebude zde tak docházet k redundanci zdrojového kódu. Frontend, stejně jako v případě modulů rozhraní backend, bude v podstatě sloužit jako další, veřejný pohled na vrstvu Model. Frontend tak nebude přímou součástí CMS, ale bude jej využívat jako platformu. 16

22 5 Implementace CMS V následujících kapitolách přiblížím implementaci některých z klíčových částí vyvíjeného CMS. 5.1 Použitá platforma framework Pro usnadnění vývoje je vhodné použít některou z dostupných platforem framework. Obecně se jedná systém, který řeší základní problémy a implementuje základní část funkcionality aplikace, a při jeho použití je tak možné se soustředit spíše na konkrétní specifika vyvíjené aplikace, přičemž není nutné se zabývat implementací základních komponent aplikace, např. základních objektových předků architektury MVP. Díky tomu nebude nutné implementovat základní strukturu aplikace zcela od počátku a bude i zajištěna ochrana proti nejběžnějším webovým útokům typu CSRF 19 [40], XSS 20 [41], session hijacking [42] a dalším. Zvolený framework by tak měl v co největší míře vyhovovat požadavkům vyvíjeného CMS, a tedy zejména poskytovat základní implementaci pro MVP architekturu a měl by být, vzhledem k celému konceptu tohoto lehkého CMS, ideálně také odlehčený, oproštěn od zbytečných komponent a funkcionalit, které by měly potenciálně dopad na výkon celého systému. Hledaný framework také musí mít kvalitní návrh, vzhledem k tomu, že se od něho bude dále odvíjet i podrobný návrh celého systému a bude na něm stavět zbytek aplikace. Jen velmi těžko by mohla mít aplikace kvalitní návrh, pokud by již samotný framework nebyl vhodně navržen. Dále by měl obsahovat již implementovaný systém pro šablony, který je v tomto CMS požadován. Tento systém by měl zapadat do celkového MVP návrhu, z čehož vyplývá, že by měl figurovat jako vrstva View. Jako samozřejmé požadavky se jeví, aby systém byl licencován pod některou ze svobodných licencí a byl v současné době aktivně vyvíjen. Na trhu je množství systémů framework, které by splňovalo uvedené požadavky. V úvahu by tak připadaly platformy Symfony [32], Lavarel [33], Zend Framework [34], Yii [35], CodeIgniter [36], Nette Framework [37] a další. Lze tak nalézt více alternativ, mezi nimiž jsou rozdíly ve výsledku méně patrné. Zvolil jsem Nette Framework, který je dle nezávislého průzkumu třetí nejoblíbenější framework pro jazyk PHP [8]. Mezi jeho hlavní výhody patří kompakt- 19 Cross-Site Request Forgery 20 Cross-Site Scripting 17

23 nost, např. v porovnání s nejznámějšími systémy Symfony a Zend Framework, kvalitní návrh, který je založen na návrhovém vzoru Dependency Injection a inovativní systém pro šablony Latte [38]. Dále díky své kompaktní povaze tak podporuje podmínku tohoto CMS je lehký. Jako zajímavost lze uvést, že tento systém je původem český a i nadále vyvíjen v České republice, kde je také mezi vývojáři oblíbený a často používaný. Vyvíjený CMS tedy bude postavený na platformě Nette Framework, díky čemuž bude tato platforma využívána napříč celým webovým portálem, tzn. i ve specifickém rozhraní frontend, které již není přímo součástí CMS apod. tedy ne jen v implementaci samotného CMS. Avšak jak již bylo několikrát uvedeno, CMS jako takový bude také sloužit jako platforma framework, která bude využívána pro moduly v rozhraní backend, pro datovou vrstvu atd. 5.2 Vývoj na platformě Nette Framework Vzhledem k tomu, že vyvíjený CMS bude postavený na platformě Nette Framework, bude tomu také přizpůsobena jeho konkrétní implementace, která z této platformy bude těžit. V dalších několika podkapitolách se proto budu stručně věnovat základním vývojovým principům specifickým pro Nette Framework, které jsou zároveň klíčové pro pochopení implementace CMS Návrhový vzor Dependency Injection Napříč celou platformou Nette Framework, a tedy i celým CMS, je využíván pokročilý návrhový vzor Dependency Injection (DI). Tento vzor řeší [9] problematiku závislostí jednotlivých tříd mezi sebou. Tento princip pracuje s konceptem kontejneru, což je objekt, ve kterém jsou registrované třídy, které vyžadují správu závislostí. Tyto třídy jsou označovány jako služby. V případě, že služba A potřebuje službu B, je tedy na ní závislá, kontejner poskytne službě A službu B. Objekty služeb jsou tedy vytvářeny pouze prostřednictvím kontejneru. Implementace tohoto vzoru v případě platformy Nette Framework ve formě třídy Nette\DI\Container zároveň zajišťuje, že se od každé služby vytváří pouze jedna instance, existuje tedy ve formě singleton. Tyto služby jsou přitom vytvářeny až v případě potřeby. Ne dříve a zbytečně, pokud by se např. na dané stránce vůbec nepoužily. V rámci platformy Nette Framework je možné použít obecně čtyři způsoby předávání závislostí [10]: předávání konstruktorem, předávání metodou set* nebo nastavením členské proměnné, 18

24 metodou inject*, u proměnné s typem přístupu public. Za předpokladu, že jsou v systému třídy Article a DataConnection registrovány jako služba v DI kontejneru, je tak možné použít např. následující konstrukci: class Article { private $database; } public function injectdb (DataConnection $database) { $this->database = $database; } DI kontejner sám díky této konstrukci zjistí závislost třídy Article a ihned po vytvoření jejího objektu zavolá metodu injectdb. Přitom se použije v systému již existující objekt typu DataConnection, a v případě že ještě neexistuje, bude vytvořena jeho nová instance. Stejným způsobem by bylo možné použít konstruktor třídy Article, přes který by se předal objekt typu DataConnection. Tento návrhový princip poskytuje výhodu v přehlednosti a čistotě zdrojového kódu, kdy jsou jednotlivé závislosti přehledně viditelné. Přitom se kód nekomplikuje dalšími konstrukcemi pro samotné předávání závislostí Vrstva Presenter Řídící vrstva Presenter architektury MVP je již formou objektových předků částečně implementována v rámci platformy Nette Framework. Každá funkčně odlišená část aplikace musí mít vlastní třídu, která je potomkem NetteApplication\UI\Presenter. Zároveň každá taková komponenta vrstvy Presenter má jednu nebo více tzn. akcí, např. komponenta starající se o zobrazení článků může mít akce detail a list pro zobrazení detailu daného článku, resp. seznamu článků. Těmto akcím pak odpovídá i struktura a názvy metod tříd typu Presenter. Existuje zde tak šest druhů metod [12], které jsou určeny k překrytí, resp. vytvoření. Jejich seznam v pořadí, ve kterém jsou prováděny, je následující: Metoda startup. Je určena k překrytí. Je provedena po vytvoření objektu, tzn. při každé akci. Používá se tak k provedení nějaké funkcionality či výpočtu společného pro celou třídu typu Presenter, a tedy všechny její akce. Metody action*, tedy např. actiondetail. Je nutné je vytvořit, ze své podstaty v předkovi neexistují. Jsou specifické pro danou volanou akci, v uvedeném případě akci s názvem detail. Každá další akce má 19

25 další svoji metodu tohoto typu. V těchto metodách by měl probíhat samotný výpočet či provedení funkcionality specifické pro danou akci. Metody handle*, tedy např. handlerefresh. Podobné jako metody action*, avšak provádí se pouze v případě, že daný požadavek je speciálního typu signál, v tomto případě označeného jako refresh. Využívá se tak zejména u požadavků typu AJAX. Metoda beforerender. Určena k překrytí, podobně jako startup. Provádí se před vykreslením šablony, slouží k jejímu nastavení. Metody render*, tedy např. metoda renderdetail. Podobné metodám action*, určené k vytvoření. Slouží ke specifickému nastavení šablony a předání dat do ní. Metoda shutdown. Určena k překrytí. Ekvivalent metody startup. Obr. 3. Životní cyklus třídy typu Presenter Zdroj: CC BY-SA 3.0, Nette Foundation Na objekty těchto tříd jsou pak směřovány jednotlivé požadavky na aplikaci. V daných metodách jsou pak typicky volány a používány služby vrstvy Model a takto získaná data jsou pak po vytvoření objektů vrstvy View, tedy objektů systému pro šablony, které typicky vykreslují UI, těmto objektům předány. 20

26 5.2.3 Routing Každý HTTP požadavek identifikován URL adresou musí být jistým způsobem přeložen a předán do správné komponenty řídící vrstvy Presenter. Zároveň je nutné, aby vrstva Presenter, resp. View měla možnost vytvořit URL adresu identifikující požadavek na konkrétní část aplikace. Překlad URL adres je tak oddělen do další samostatné podvrstvy, díky čemuž tvar URL není pevně zafixován napříč aplikací a lze jej snadno změnit. K tomuto účelu slouží v rámci Nette Framework slouží třídy [11] implementující rozhraní NetteApplication\IRouter. Tyto třídy tedy zastávají dvě funkce: překlad URL adresy na konkrétní komponentu vrstvy Presenter a její akci a překlad požadavku ve formě názvu komponenty Presenter a jeho akce na absolutní URL adresu. Např. následující volání v rámci komponenty vrstvy Presenter může být vyhodnoceno jako adresa /clanky/nejaky-konkretni-clanek : $this->link('articles:detail', $articleid); Vrstva View Vrstva View, která, jak bylo uvedeno, má na starosti výstup, což typicky zahrnuje vykreslení UI formou HTML. K tomuto účelu se v rámci platformy Nette Framework využívá zmíněný systém pro šablony Latte [13]. Tento systém pracuje se soubory typu.latte, přičemž je možné v těchto souborech používat dědičnost. Soubory tak lze rozdělit do bloků, přičemž potomci mají možnost tyto bloky upravovat, doplňovat apod. Díky tomu je možné dosáhnout toho, aby společný vzhled stránek byl v jednom společném souboru, kde budou vyznačené bloky pro proměnlivý obsah, např. text článku, přičemž potomci budou moci tento blok naplnit vlastním obsahem. Soubory.latte jsou dále kombinací standardního HTML, vč. všech jeho částí, jako např. vloženého kódu jazyka JavaScript, a speciálních maker specifických pro Latte, které nahrazují nepřehledný PHP kód. Např. následující kód by vypsal seznam článků (za předpokladu, že přes proměnnou $articles je možné iterovat): <ul n:if="$articles"> <li n:foreach="$articles as $article">{$article}</li> </ul> V případě, že by proměnná $articles např. měla nulový počet položek, nevypsala by se díky makru n:if ani značka ul. Dále systém Latte podporuje tzv. filtry, které mohou být aplikovány na proměnnou. Následující kód tak např. vypíše nadpis velkými písmeny: <h1>{$heading upper}</h1> Soubory.latte však skutečně pracují jen jako forma šablony ve skutečnosti jsou překládány (makra rozvíjena atd.) do jazyka PHP, přičemž tyto PHP 21

27 soubory jsou ukládány pomocí cache a k vlastnímu překladu tedy dochází pouze při změně šablony.latte souborů. Celý systém je tak rychlý Rozšíření jazyka PHP Nette Framework poskytuje univerzálního objektového předka Nette\Object, ze kterého dědí naprostá většina komponent této platformy. Tato třída je zároveň natolik abstraktní a univerzální, že ji lze použít (téměř) u všech tříd v projektech, které stojí na této platformě. V těchto třídách je pak k dispozici následující funkcionalita [15], která není standardní součástí jazyka PHP Striktní chování objektů PHP umožňuje dynamicky deklarovat vlastnosti objektu. Je tak tedy možná např. následující konstrukce, jejíž použití nevyvolá chybu ani varování žádné úrovně: class A {} $obja = new A; $obja->abc = 'Hello World'; Toto chování je potenciálně nežádoucí v případě, že by vývojář např. nezáměrně způsobil překlep v názvu vlastnosti, interpret jazyka PHP ho vůbec neupozorní, že daná vlastnost není definovaná a definoval by ji automaticky. Lokace chyby by pak mohla být poměrně těžko odhalitelná. V případě použití zmíněného objektového předka bude při pokusu o přístup k nedeklarované vlastnosti vyhozena výjimka Metody get* a set* Použití uvedeného objektového předka vylepšuje práci s metodami get* a set*. Tyto metody slouží pro manipulaci s vlastnostmi objektu vlastnosti tak mohou být nastaveny jako private, čímž je zajištěno zachování principu zapouzdření daného objektu. Je tak možné např. validovat vkládaná data. Jazyk PHP toto standardně také podporuje, avšak vývojář musí k přístupu k dané vlastnosti vždy používat zmíněné metody. Nette Framework umožňuje, aby k těmto vlastnostem bylo přistupováno podobně, jako kdyby byly nastaveny s viditelností public. Je tak možné následující použití: 22

28 class A extends Nette\Object { private $color; public function getcolor() { return 'The color is: '. $this->color; } } public function setcolor($value) { $this->color = $value; } $obja = new A; $obja->color = 'orange'; echo $obja->color; Uvedený blok zdrojového kódu nevyvolá dynamickou deklaraci popsanou výše, ale interně použije metody setcolor, resp. getcolor, což přispívá k lepší přehlednosti Události Nette Framework dále poskytuje vestavěnou implementaci mechanismu událostí. Je tak možné definovat spustitelné bloky kódu 21, které se provedou při určité akci, tedy události. Tyto bloky jsou uloženy ve formě pole jako vlastnost objektu, přičemž je pak možné v rámci daného objektu vyvolat danou událost. Při vyvolání události jsou pak provedeny všechny bloky uložené ve zmíněném poli. 21 Označováno též jako callback 23

29 class A extends Nette\Object { string */ private $color; array */ public $oncolorchange; } public function setcolor($value) { $this->oncolorchange($this, $this->color, $value); $this->color = $value; } $obja = new A; $obja->oncolorchange[] = function($obj, $oldvalue, $newvalue) { echo 'Color change!'; }; $obja->color = 'orange'; Rozšiřující metody Je možné definovat metodu nějakého objektu přímo za běhu. Tyto rozšiřující metody však neporušují princip zapouzdření mají přístup pouze k veřejným členům tříd Sebereflexe Předek Nette\Object dále umožňuje snazší přístup k sebereflexi dané třídy. Ta je k dispozici pomocí metody getreflection, resp. vlastnosti reflection. Na rozdíl od základního PHP tak není nutné vytvářet objekt typu ReflectionClass ručně Anotace Reflexe získané způsobem uvedeným v předešlé podkapitole disponují ještě další výhodou: je skrz ně možné získat přístup také k anotacím, tedy k částem dokumentace ve formátu PHPDoc 22. /** Václav Muzikář */ class A extends Nette\Object {} $obja = new A; echo $obja->reflection->getannotation('author');

30 5.2.6 HTML formuláře Platforma Nette Framework disponuje propracovaným systémem pro formuláře značkovacího jazyka HTML [16]. Každý formulář a zároveň každý prvek formuláře, jako např. textové pole nebo odesílací tlačítko, je reprezentován jako objekt. Tyto objekty mají své vlastnosti, přes které je např. možné nastavit omezující podmínky jednotlivých položek formuláře apod. Objekt formuláře je pak možné vykreslit, resp. interpretovat jako HTML kód. Předdefinovaná kontrola vložených dat umožňuje široké možnosti nastavení, včetně např. porovnání vůči regulárnímu výrazu. Pokud tato kontrola po odeslání neprojde, formulář je nově vykreslen i s chybovou hláškou a grafickým označením chybné položky. Výhodná je také integrovaná podpora pro kontrolu položek pomocí jazyka JavaScript. Kontrola tak proběhne nejprve na straně klienta, tedy webového prohlížeče, což je rychlé není nutné odesílat data na server. Po úspěšném proběhnutí této kontroly jsou teprve data odeslána, kde tato kontrola proběhne znovu již na úrovni serveru v rámci jazyka PHP. Odeslaný formulář je taktéž interpretovaný jako objekt, který také obsahuje uživatelem zadané hodnoty. Tyto hodnoty jsou přitom již validovány. Odpadá tak kontrola a použití hodnot globálních proměnných v PHP $_GET, $_POST a $_REQUEST. Příklad použití: $form = new Nette\Forms\Form; $form->addtext('name', 'Your name:') ->setrequired('enter your name!'); $form->addpassword('password', 'Your password:') ->setrequired('enter your password!') ->addrule(form::min_length, 'Min. %d chars', 3); $form->addsubmit('login', 'Register'); $form->onsuccess[] = function($form, $values) { // save data }; echo $form; 25

31 5.3 Adresářová struktura Následuje náhled na strukturu CMS v rámci souborového systému. Pro zjednodušení byly odebrány některé méně důležité adresáře. Document Root appdata -adresář s aplikací; nebude přístupný z webu libs -knihovny, např. Nette Framework log -uložená chybová hlášení platformy Nette Framework src -zdrojové soubory aplikace App -hlavní zdrojové soubory Admin -rozhraní backend Modules -moduly rozhraní backend... Front -rozhraní frontend Presenters Router templates... Model -společná datová vrstva aplikace Elements madminframework -část CMS, která představuje framework; je použitelná i nezávisle Admin -rodičovské třídy rozhraní backend Modules Presenters Misc -pomocné třídy Model -rodičovské třídy datové vrstvy Elements Router -hlavní třída typu Router, která rozděluje požadavky mezi rozhraními backend a frontend bootstrap.php -zaváděcí soubor celé aplikace config.neon -nastavení aplikace a platformy Nette Framework temp -pomocný adresář pro systém cache platformy Nette Framework css images js index.php -předává řízení do bootstrap.php 26

32 5.4 Datová vrstva Datová vrstva, v kontextu MVP nazývaná Model, nemá na platformě Nette Framework přímou podporu, např. formou objektových předků. Je tedy nutné ji od počátku implementovat. Jak vyplývá z požadavků, systém bude jako úložiště primárně používat relační databázi. Datová vrstva proto bude od počátku implementována s tímto úmyslem. Vyjma toho, že bude s daty v databázi pracovat, bude umět i vytvořit patřičnou databázovou strukturu bude umět vytvořit potřebné tabulky. Datová vrstva staví na následujících abstraktních třídách Třída BaseDbElement Elementárním prvkem této vrstvy, jak bylo nastíněno v podkapitole , bude třída Element, konkrétně označena jako BaseDbElement. Objekty této třídy představují jednu datovou položkou, tedy jeden atribut, např. název. Každý takový objekt ponese určitá elementární data. Ve většině případů jedna třída typu BaseDbElement také odpovídá jednomu atributu v databázi. Tato komponenta však nebude mít přímo přístup do databáze, nebude tedy přímo ukládat a načítat data to se děje na vyšších úrovních, na úrovni řádku, resp. více řádků, tedy ne na úrovni jednotlivých atributů. Na této úrovni však bude probíhat zpracování a konverze dat. Každý objekt typu BaseDbElement tedy uchovává nějaká data v určité vlastní interní formě, ať už např. jako prosté celé číslo či objekt, a tato data pak umí vrátit i uložit pomocí svého veřejného rozhraní. Avšak tato data je nutné interpretovat různými způsoby (nehledě na jejich formát uložení uvnitř objektu). Budou mít odlišnou formu pro uložení v databázi a odlišnou pro jejich manipulaci v rámci celé aplikace. Tedy např. datum a čas budou v databázi reprezentovány jako datový typ TIMESTAMP, ale v aplikaci se s nimi bude pracovat pomocí objektu typu DateTime. Rozhraní těchto tříd pro manipulaci s daty tedy bude rozděleno následovně: pro databázový formát metody todb a fromdb pro výstup, resp. vstup dat ve formátu pro databázi a pro pracovní formát tradiční metody getvalue a setvalue. Objekty této třídy dále uchovávají další vlastnosti, jako je systémový název dané datové položky, její název v databázi (tedy název sloupce), zda se jedná o položku pouze ke čtení apod. Ve výše uvedeném popisu je tedy definována abstraktní třída BaseDbElement, která slouží jako předek všem třídám reprezentujícím datovou položku. Takto odvozené třídy budou reprezentovat již konkrétní datovou položku, např. název článku. Některé z těchto položek je pak k dispozici v jisté formě 27

33 k uživatelské editaci. Tato editace probíhá typicky přes HTML formulář. Pro tento účel je k dispozici rozhraní IFormControl, které mohou tyto třídy implementovat. Třídy pak musí implementovat již konkrétní funkcionalitu, která ve výsledku vrátí objekt formulářové položky, který je definovaný přímo v platformě Nette Framework. Toto rozhraní zajišťuje a dalším komponentám systému tak oznamuje, že daná datová položka umožňuje svou přímou editaci pomocí formuláře. Díky tomu je možné tuto reprezentaci pomocí formuláře sdílet i mezi rozhraními backend a frontend Třída BaseDbItemModel Třída BaseDbItemModel reprezentuje určitou datovou n-tici skládající se z jednotlivých datových prvků tříd typu BaseDbElement. Objekty tedy reprezentují jeden záznam, jednu položku v tomto případě v určité tabulce v databázi. Opět se tedy jedná o abstraktního objektového předka, jehož potomci reprezentují nějaký určitý jeden prvek datové vrstvy, např. jeden článek. Tato třída je tak zodpovědná za vytváření objektů typu BaseDbElement, jejich naplnění daty a zároveň řídí přístup k nim existují zde tedy ve formě vlastností tříd BaseDbItemModel. Třída BaseDbItemModel již má přístup k databázi. Avšak nepřistupuje k ní přímo, např. pomocí nějakého ovladače jazyka PHP, ale zprostředkovaně pomocí databázové vrstvy, která je k dispozici v rámci platformy Nette Framework [17]. Konkrétně bude pracovat pouze s interpretací jednoho konkrétního řádku ve formě objektu typu Nette\Database\Table\ActiveRow. Skrze tento objekt tomu dokáže i tento řádek měnit, odstranit apod Třída BaseDbListModel Třída, která reprezentuje kolekci, resp. seznam dat, např. všechny články. Má již plný přístup k databázi skrze Nette Framework, tedy ne jen k jednomu řádku jako BaseDbItemModel. Stejně jako v předchozích případech se jedná o abstraktní třídu, jejíž potomci reprezentují až nějakou konkrétní kolekci. Základní funkcionalita této třídy spočívá ve vytváření a poskytování konkrétních potomků třídy BaseDbItemModel. Tyto položky lze získat jak iterací nad celým objektem typu BaseDbListModel, tak i pouze jeden pomocí metody get. V případě, že nebyla nalezena žádná vyhovující data, je vyhozena výjimka. Třída dále umožňuje použití určitých filtrů nad danou kolekcí dat (obdoba SQL příkazu WHERE). Jejich aplikace spočívá v zavolání určité metody, např. colequals pro test na ekvivalenci daného sloupce s danou hodnotou. Tento filtr zůstane aplikován do prvního pokusu o získání dat, např. do spuštění iterace nad touto třídou. Je však možné tento filtr nastavit jako permanentní 28

34 pomocí metody setpermanent. Právě nastavený filtr tak bude aktivní i při dalším získání dat. Další specifické filtry je možné vytvářet v potomcích. Objekty této třídy si dále uchovávají odkazy na objekty typu BaseItemModel, které již byly jednou vytvořeny, tedy byly již jednou požadovány např. v rámci iterace. Pokud je pak daná položka vyžádána znovu, bude poskytnut ten stejný objekt, nebude se vytvářet znovu. V některých případech tak ani není nutné posílat nový požadavek na databázi potřebná data jsou již uložena v objektech. Obr. 4. Zjednodušený UML graf základních tříd datové vrstvy Vložení nového záznamu do kolekce dat je prováděno skrze nový prázdný objekt typu BaseDbItemModel. Vytváření těchto objektů rovněž probíhá přes metodu třídy BaseDbListModel, vzhledem k tomu, že je v nich nutné nastavit vazby na jejich mateřský objekt BaseDbListModel. Objekty typu BaseDbItemElement tedy není možné vytvářet přímo bez použití objektu reprezentující danou kolekci dat. Po nastavení příslušných atributů v novém objektu, tedy po nastavení hodnot objektům BaseDbElement, je nový záznam možné vložit pomocí metody save, která je obsažena v tomto objektu. Tato metoda zároveň slouží i ke změně uložených dat v databázi. Díky tomu, že veškerá manipulace s daty je prováděna skrze tuto metodu, lze tak v potomcích např. jednoduše přidat nějakou další validaci. Jednotlivé položky BaseDbElement na sebe vzájemně nemohou vidět. Např. tedy kontrolu, zda je kombinace jejich hodnot validní, je nutné dělat na vyšší úrovni ve třídě BaseDbItemModel. Tuto kontrolu zle tedy provést překrytím metody save, přičemž tato kontrola bude provedena jak pro úpravu, tak pro uložení dat. Dále je pro třídy odvozené ze základní BaseDbListModel k dispozici rozhraní IInstallable. Implementace tohoto rozhraní zajistí, že tyto třídy podporují nějakou instalaci v systému, typicky vytvoření potřebných datových konstrukcí v databázi, např. tabulek. 29

35 Objekty typu BaseDbListModel budou v systému figurovat jako služby definované v podkapitole Rozhraní backend Rozhraní backend bude figurovat jako platforma pro moduly, jak bylo navrženo v podkapitole 4.6., přičemž tyto moduly budou definovat funkcionalitu tohoto rozhraní Hierarchie tříd typu Presenter Funkcionalita bude implementována v rámci tříd typu Presenter, přičemž bude rozdělena do několika objektových předků. Následuje seznam těchto abstraktních předků, přičemž každá úroveň má za předka třídu uvedenou v předchozím bodě. Z toho vyplývá, že každá úroveň zároveň dědí a zachovává funkcionalitu předchozí úrovně, tedy svého předka. Třída BasePresenter implementuje základní funkcionalitu společnou pro všechny částí rozhraní Backend, jako je nastavení chování a vzhledu pro všechny formuláře, kontrola kompatibility webového prohlížeče uživatele, definice šablony pro odesílání systémových ových zpráv apod. Přímým neabstraktním potomkem tohoto předka je např. třída zajišťující stránku s přihlášením uživatele do systému. Třída BaseLoggedInPresenter je použita v případě, že je uživatel již přihlášen. Tuto skutečnost také ověřuje, a v případě, že uživatel není přihlášen, je přesměrován na přihlášení. Nastavuje se zde také globální šablona, která je společná pro celou sekci po přihlášení. Třída BaseModulePresenter představuje předka již nějakého konkrétního modulu. Ověřuje tedy, zda je uživatel oprávněn k přístupu k danému modulu. Avšak neobsahuje žádnou další funkcionalitu. Může tedy sloužit jako předek vysoce specializovaným modulům, resp. pracovat s datovými komponentami, které musí mít vlastní specifickou implementaci. Třída BaseModuleActionsPresenter taktéž bude předkem konkrétního modulu. Oproti předchozí úrovni BaseModulePresenter však obsahuje již implementaci pro základní tři případy užití: zobrazení dat ve formě tabulky, přidání nových dat a editaci těchto dat. Dokáže tedy interpretovat datové komponenty a zobrazit je ve formě tabulky či HTML formuláře. Zároveň také tato třída nastaví patřičné šablony systému Latte pro správné vykreslení tabulky se seznamem uložených dat, vykreslení formulářů atd. 30

36 5.5.2 Registr modulů Dále bylo nutné vyřešit, jakým způsobem registrovat jednotlivé moduly v rámci systému. Jejich identifikace je nutná např. pro řízení přístupu k nim či pro zobrazení jejich odkazů na ně v navigaci. Samotné třídy typu Presenter přímo modul nepředstavují. Jak bylo nastíněno, tyto třídy jsou pouze řídící logikou, která se stará o zpracování požadavku na systém, tedy např. o zobrazení určité stránky. Z tohoto důvodu bude mít každý modul, kromě třídy Presenter, ještě svoji identifikační třídu, která ponese informace o daném modulu, tedy jeho jméno, systémový název, odkaz na rodičovský modul apod. Tato funkcionalita je rozdělena do dvou tříd: BaseModule a ModuleList. Abstraktní třída BaseModule bude předkem všech konkrétních modulů. Bude uchovávat základní informace o těchto modulech. Dále také vyhledá ve složce svého potomka, tedy konkrétního modulu, konfigurační soubor typu neon, ze kterého načte prioritu daného modulu ve formě celého čísla. Tato priorita bude později sloužit např. k zobrazení odkazů na tyto moduly ve správném pořadí. Vzhledem k tomu, že tato priorita může být poměrně variabilní, není vhodné ji napevno zakomponovat do zdrojového kódu. Klíčové je také umístění daného modulu v rámci jmenných prostorů. Výchozí umístění modulů je v prostoru App\Admin\Modules. Pokud však má být nějaký modul potomkem jiného modulu ve smyslu např. jejich seřazení (ne tedy ve smyslu objektového předka), je nutné jej umístit do další úrovně jmenných prostorů. Pokud je tedy např. modul se systémovým názvem Articles, a jeho potomek ArticleCategories, musí být tento podřízený modul umístěn ve jmenném prostoru App\Admin\Modules\Articles. Jednotlivé moduly, tedy potomci odvození z třídy BaseModule, v systému sami o sobě nevytvoří nijak své instance. K tomuto účelu bude sloužit třída ModuleList, která bude v systému figurovat jako služba, jak je definována v podkapitole Má na starosti právě nalezení tříd představující moduly, vytvoření jejich instancí a jejich uspořádání dle jejich priorit. Dále nastaví jejich rodičovské vztahy. Seznam všech modulů, tedy jejich forma registru, bude k dispozici přes objekt této třídy Řízení přístupu Integrovanou součástí CMS bude i řízení přístupu k rozhraní backend, což zahrnuje přihlášení, registraci, správu uživatelů atd. Základní podpora pro autentizaci a autorizaci uživatele je již součástí platformy Nette Framework [18], avšak její konkrétní implementace je v režii datové vrstvy. Z tohoto důvodu standardní součástí CMS tedy budou třídy pro manipulaci s uživateli a jejich přístupovými rolemi. Řízení přístupu tedy bude implementované jako forma RBAC. 31

37 Datová vrstva k tomuto účelu se tedy bude skládat ze tří komponent pro manipulaci s daty: uživatelé, role a konkrétní oprávnění spadající pod danou roli. Tyto komponenty jsou implementované jako standardní komponenty datové vrstvy CMS, tedy s použitím definovaných objektových předků. Avšak kromě toho třídy pro správu uživatelů UserList a rolí RoleList také implementují rozhraní platformy Nette Framework, které zajišťují autentizaci, resp. autorizaci uživatele. Díky tomu je v rámci této platformy registrována třída UserList jako tzv. autentikátor a třída RoleList jako autorizátor. Správa uživatelů a rolí je v rozhraní backend řešena jako standardní moduly, díky čemuž je také možné omezit přístup k těmto modulům pro určité uživatelské role. Uživatelé s nižšími oprávněními tak nemohou např. přidávat další nové uživatele. Všichni uživatelé, nehledě na svoji roli, však mohou přistupovat ke správě vlastního účtu. Tato správa již nebude fungovat jako standardní modul rozhraní backend, bude mít v systému vlastní implementaci v podobě další třídy UserPresenter. Zde uživatel může změnit své heslo a kontaktní Založení nového uživatelského účtu Vytváření uživatelského účtu probíhá mírně odlišně od vytváření záznamů jiného druhu. Nový účet je tak vytvořen v následujících krocích: 1. Uživatel s přístupem k modulu správy uživatelů vytvoří nového uživatele, přičemž tento uvede jeho uživatelské jméno a . Heslo nezadává. 2. Novému uživateli přijde s unikátním odkazem k aktivaci účtu. Tento unikátní odkaz má jen určitou časovou platnost. Díky tomu je i ověřena platnost ové adresy. 3. Po zobrazení obsahu na této adrese uživatel zadá své nové heslo a po potvrzení je přesměrován na přihlašovací obrazovku, kde mu je umožněno přihlášení. Podobný postup nadchází i při resetování hesla v případě, že jej uživatel nezná či zapomene. Při vytvoření požadavku na obnovení hesla se předchozí postup opakuje od bodu 2. 32

38 6 Užití CMS Vyvíjený CMS je zaměřením definován jako platforma. Z toho vyplývá, že v základu neposkytuje téměř žádnou funkcionalitu vyjma rozhraní backend, kde je implementován uvedený systém pro řízení přístupu. Pro užití tohoto CMS je tedy nutné implementovat konkrétní funkcionalitu, kterou má daný webový portál poskytovat. V následujících kapitolách přiblížím základní vývojové principy pro webové portály, které budou tento CMS využívat. Uvedené postupy však popisují pouze velice základní implementaci. Všechny dědící třídy lze doplnit o další specifickou funkcionalitu. Všichni objektoví předci zmínění v následujícím textu jsou umístěni ve jmenném prostoru madminframework. Předpokladem pro spuštění a použití tohoto CMS je splnění následujících podmínek: Splnění minimálních požadavků [21] pro běh platformy Nette Framework ve verzi 2.2. Webový server Apache [19] se zapnutou podporou mod_rewrite [20]. Relační databázový server, který je podporován v rámci tříd umístěných v Nette\Database\Table platformy Nette Framework [17]. Ideálně však server MySQL [22], pro který je CMS optimalizován. Pro běh aplikace je dále nutné v souboru appdata/src/config.neon specifikovat připojení k databázi dle [17]. 6.1 Vývoj komponent datové vrstvy Datová vrstva tvoří základní část aplikace. Z velké míry definuje funkcionalitu, kterou bude aplikace poskytovat. Je vhodné tedy zaměřit vývoj nejprve na tuto vrstvu Třídy Element Vývoj musí začít implementací (příp. použitím již některé z připravených) položek typu Element, které představují jednu datovou položku, např. název článku. Tyto položky tvoří nejnižší podvrstvu datové vrstvy, a mají tedy tak nejnižší míru závislosti z celé datové vrstvy. K tomuto účelu jsou v systému k dispozici tři abstraktní rodičovské třídy, které mají sloužit jako předci pro konkrétní třídy Element. Následuje jejich seznam seřazený od tříd s nejvyšší mírou abstrakce. Třída BaseDbElement představuje základní položku databáze. Při jejím použitím jako předka je nutné překrýt konstruktor a zavolat konstruktor předka s definovanými názvy dané položky Element. Dále je nutné 33

39 implementovat metodu getsqldefinition, která bude vracet SQL definici patřičného atributu ve formě textového řetězce. Třída BaseDbFormElement je potomkem třídy BaseDbElement. Platí pro ni tedy vše, co pro její rodičovskou třídu. Navíc ovšem přidává podporu pro implementaci HTML formulářů. Její potomci tedy musí navíc ještě implementovat metodu formcontrolfactory, která vrátí interpretaci dané třídy ve formě položky formuláře. Dále je k dispozici metoda addjslib, která se postará o načtení uvedeného soubor jazyka JavaScript v případě, že je vykreslena položka formuláře. Lze tak např. dosáhnout WYSIWYG editace textu. Třída BaseId představuje předka pro všechny třídy Element, které reprezentují jednoznačný identifikátor nějaké položky, např. článku, ve formě celého čísla. Její potomci musí, na rozdíl od předchozích dvou tříd, překrýt pouze konstruktor. Potomci těchto tříd dále mohou překrýt kterékoliv metody a dosáhnout tak např. konverze dat při ukládání do databáze apod Třídy Item Třídy Item představující jednu datovou položku, např. článek, mohou pro svoji implementaci využít třídu BaseDbItemModel. V případě, že tuto třídu použijí jako svého objektového předka, musí nutně implementovat vlastní konstruktor, ve kterém pomocí metody addelements definují své objekty Element. Např. v případě článku je tak v tomto konstruktoru nutné definovat, že článek obsahuje svůj identifikátor, název, text atd. Vše ostatní, např. ukládání, mazání položek, je již definováno v objektovém předku BaseDbItemModel Třídy List Třídy List reprezentují nějaký konkrétní seznam, resp. kolekci dat, např. články. Stejně jako v předchozím případě je pro ně vhodné využít objektového předka v tomto případě BaseDbListModel. Z něj odvozené třídy musí opět implementovat konstruktor, ve kterém nastaví název tabulky v databázi. Dále je v nich nutné implementovat metodu itemfactory, která vrací nový objekt Item, přesněji typu BaseDbItemModel např. objekt reprezentující článek. Další implementace funkcionality, např. práce s databází, získávání dat, je již součástí objektového předka BaseDbListModel. Dále je k dispozici pro implementaci rozhraní IInstallable. Je pak nutné implementovat metodu install, která má na starosti např. vytvoření patřičné tabulky v databázi v případě, že neexistuje. Tyto třídy nejvyšší úrovně datové vrstvy je nutné v rámci platformy Nette Framework registrovat jako služby, jak byly definovány v podkapitole Registrace služeb je prováděna přes hlavní konfigurační soubor appdata/src/config.neon ve formátu dle [10]. 34

40 6.1.4 Použití datové vrstvy V částech aplikace, které spravuje DI kontejner definovaný v podkapitole , je pak možné si vyžádat konkrétní objekt typu List. Data, tedy objekty typu Item, je pak možné získat např. skrze iteraci či metodu getbyid, příp. prázdnou položku pro vložení nového záznamu přes metodu createitem. K samotným datům je pak tedy možné přistupovat skrze objekt Item, který jednotlivé datové položky uvádí jako své vlastnosti. Je tak možná např. následující konstrukce, která vypíše názvy všech článků: foreach ($articlelist as $article) { echo $article->name; } Podobným způsobem je také možné data modifikovat: $article = $articlelist->getbyid(1); $article->name = 'Lorem Ipsum'; $article->save(); 6.2 Vývoj modulů rozhraní backend Správu datové vrstvy je nutné implementovat do rozhraní backend pomocí modulů, které jsou definovány v podkapitole 4.6. Každý modul se v základní implementaci skládá ze tří souborů: Soubor s potomkem třídy BaseModule, tedy např. ArticlesModule.php. Každý tento potomek musí překrýt konstruktor, ve kterém zavolá konstruktor svého předka. Přes toto volání nastaví modulu jeho název a systémové označení. Soubor module.neon. Tento soubor obsahuje nastavení priority daného modulu v rámci systému a potenciálně v dalších verzích CMS i jiná nastavení. Soubor je ve formátu: priority: int, kde int je nějaké celé číslo. Soubor presenters/[module]presenter.php, tedy např. presenters/articlespresenter.php. Třída v tomto souboru je potomkem BaseModulePresenter, resp. BaseModuleActionsPresenter. V případě prvního předka je veškerá implementace funkcionality v režii potomka. Ve druhém případě je již základní funkcionalita implementována, jak je uvedeno v podkapitole Potomek BaseModuleActionsPresenter musí implementovat následující: Musí naplnit vlastnosti itemsshow a itemsedit. Tyto vlastnosti definují, které z datových položek budou přístupné pro zobrazení, resp. editaci. Např. protected $itemsshow = array('date', 'name', 'text'); 35

41 Musí implementovat metodu s názvem injectmodel, která od DI kontejneru získá objet List datové vrstvy. Ukazatel na tento objekt vloží do vlastnosti model. Každý modul musí být veden jako následující podadresář: appdata/src/app/admin/modules 6.3 Rozhraní frontend Jak bylo uvedeno: vzhledem k povaze tohoto CMS není rozhraní frontend jeho přímou součástí. Je mu ale dispozici datová vrstva prostřednictvím služeb DI kontejneru, což zajistí sdílení většiny aplikační logiky. Avšak je nutné alespoň implementovat třídu typu Router definovanou v podkapitole , která se bude starat o směřování požadavků na rozhraní frontend. CMS počítá s tím, že bude existovat třída App\Front\Router\RouterFactory, jejíž metoda create vrací objekt typu IRouter. 36

42 7 Závěr Cílem této práce byl návrh a implementace nového systému typu CMS, který vyhovuje požadavkům společnosti Evaluate Dynamics pro nasazení v jejích produktech, avšak zároveň je dostatečně univerzální. Nový CMS splňuje požadavky uvedené v kapitole 3 a slouží tak jako platforma, která urychluje vývoj a nasazení webových portálů. Toho je dosaženo pomocí předpřipravené implementace nejpoužívanějších komponent, kterou může aplikace postavená na této platformě využít. Avšak nejsou zde kladena omezení aplikace nemusí této nabízené implementace využít, příp. ji může využít pouze z části. CMS je tak dostatečně rychlý, dynamický a flexibilní. Systém dále v základu obsahuje implementaci rozhraní backend, jehož součástí je i řízení přístupu k systému. Toto rozhraní je kompletně implementováno, tedy včetně grafického návrhu, který je součástí aplikace, a umožňuje tak jednoduchou správu obsahu na daném webu. Rozhraní backend neobsahuje však v základu žádnou nadbytečnou funkcionalitu, což podporuje požadavek na lehkost. Systém je postupně nasazován v produktech uvedené společnosti, přičemž probíhá také konverze stávajících produktů. I nadále však bude také pokračovat vývoj tohoto CMS, jehož součástí bude mimo jiné i optimalizace systému, snížení počtu požadavků na databázi díky využití cache, rozšíření výchozí implementace rozhraní backend o vyhledávání, volby třídění a stránkování dat. 37

43 Reference [1] VERENS, Kae. CMS Design Using PHP and jquery: Build and improve your in-house PHP CMS by enhancing it with jquery. Birmingham: Packt Publishing, s. ISBN [2] BRAMPTON, Martin. PHP 5 CMS Framework Development: Expert insight and practical guidance to create an efficient, flexible, and robust web-oriented PHP 5 framework. Second Edition. Birmingham: Packt Publishing, s. ISBN [3] solid IT gmbh. DB-Engines [online]. April 2015 [cit ]. DB- Engines Ranking. Dostupný z WWW: [4] TIGGELER, Eric. Joomla! 2.5 Beginner's Guide: An easy to use stepby-step guide to creating perfect websites with the free Joomla! CMS. Birmingham: Packt Publishing, s. ISBN [5] SARAY, Aaron. Professional PHP Design Patterns. Indianapolis: Wiley Publishing, s. ISBN [6] FREEMAN, Adam. Pro ASP.NET MVC 5. 5th Edition. New York: Apress, s. ISBN [7] MARTIN, Robert C. Agile Software Development: Principles, Patterns, and Practices. New York: Pearson Education, s. ISBN [8] SKVORC, Bruno. SitePoint [online]. March 28, 2015 [cit ]. Best PHP Framework for 2015 SitePoint Survey Results. Dostupný z WWW: [9] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Dependency Injection. Dostupný z WWW: [10] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Získávání závislostí. Dostupný z WWW: [11] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Routování URL. Dostupný z WWW: 38

44 [12] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. MVC aplikace & presentery. Dostupný z WWW: [13] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Šablony. Dostupný z WWW: [14] HAUSCHILDT, Sofia. CMS Made Simple 1.6: Create a fully functional and professional website using CMS Made Simple, Beginner s Guide. Birmingham: Packt Publishing, s. ISBN [15] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Rozšíření jazyka PHP. Dostupný z WWW: [16] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Formuláře. Dostupný z WWW: [17] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Databáze. Dostupný z WWW: [18] Nette Foundation. Dokumentace [online]. Verze 2.3 [cit ]. Přihlašování & oprávnění uživatelů. Dostupný z WWW: [19] The Apache Software Foundation. The Apache HTTP Server Project [online]. [cit ]. Dostupný z WWW: [20] The Apache Software Foundation. The Apache HTTP Server Project [online]. [cit ]. Apache Module mod_rewrite. Dostupný z WWW: [21] Nette Foundation. Nette Framework [online]. Verze 2.3 [cit ]. Požadavky Nette Framework. Dostupný z WWW: [22] Oracle Corporation. MySQL [online]. [cit ]. Dostupný z WWW: [23] Open Source Matters. Joomla! [online]. [cit ]. Dostupný z WWW: [24] KIRTLAND, Jason. Blatter [online]. [cit ]. Dostupný z WWW: 39

45 [25] MariaDB Foundation. MariaDB [online]. [cit ]. Dostupný z WWW: [26] The PostgreSQL Global Development Group. PostgreSQL [online]. [cit ]. Dostupný z WWW: [27] The PHP Group. PHP: Hypertext Preprocessor [online]. [cit ]. Dostupný z WWW: [28] W3C. HTML5 [online]. [cit ]. Dostupný z WWW: [29] WordPress Foundation. WordPress [online]. [cit ]. Dostupný z WWW: [30] BUYTAERT, Dries. Drupal [online]. [cit ]. Dostupný z WWW: [31] PHP-Fusion Inc. PHP-Fusion [online]. [cit ]. Dostupný z WWW: [32] POTENCIER, Fabien. Symfony [online]. [cit ]. Dostupný z WWW: [33] OTWELL, Taylor. Laravel [online]. [cit ]. Dostupný z WWW: [34] Zend Technologies. Zend Framework [online]. [cit ]. Dostupný z WWW: [35] Yii Software LLC. Yii [online]. [cit ]. Dostupný z WWW: [36] British Columbia Institute of Technology. CodeIgniter [online]. [cit ]. Dostupný z WWW: [37] Nette Foundation. Nette Framework [online]. [cit ]. Dostupný z WWW: [38] Nette Foundation. Latte [online]. [cit ]. Dostupný z WWW: [39] Wikipedia. List of content management systems [online]. Last modified on 10 May 2015, at 06:21 [cit ]. PHP. Dostupný z WWW: ms#php. [40] BURNS, Jesse. Cross Site Request Forgery: An introduction to a common web application weakness [online]. Version 1.2 [cit ]. Dostupný z WWW: 40

46 [41] The Web Application Security Consortium. Cross Site Scripting [online]. February 1, 2011 at 4:18:45 pm [cit ]. Dostupný z WWW: 20Scripting. [42] TICHÝ, Jan. Session hijacking aneb ukradení session ID [online] [cit ]. Dostupný z WWW: 41

47 Příloha A Obsah elektronické přílohy Přílohou této práce je funkční ukázka nasazení vyvíjeného CMS. Tato ukázka zahrnuje implementaci pro tyto účely zjednodušeného systému článků portálu Slunečno.cz. Z licenčních důvodů tak není součástí přílohy design rozhraní frontend. Pro správnou funkci tohoto rozhraní je tak třeba doplnit patřičné soubory.latte do následujícího adresáře: /appdata/src/app/front/templates Pro zprovoznění této ukázky je dále nutné splnit požadavky uvedené v kapitole 6. Před prvním použitím je nutné ve webovém prohlížeči otevřít adresu [DocumentRoot]/admin/install, kde [DocumentRoot] je URL adresa směřující na tuto ukázku, např. localhost. Přihlášení do rozhraní backend je poté k dispozici na adrese [DocumentRoot]/admin s výchozím uživatelským jménem admin a heslem madmin. 42

48 Příloha B Náhledy uživatelského rozhraní Rozhraní frontend detail článků CC BY-NC-ND 3.0 Evaluate Dynamics s. r. o. 43

49 Rozhraní backend přihlašovací dialog Rozhraní backend seznam článků 44