Č ESKÉ V YSOKÉ U ČENÍ T ECHNICKÉ V P RAZE Fakulta Elektrotechnická Katedra počítačů
Bakalářská práce Systém pro tvorbu internetových stránek
Vojtěch Svoboda
Vedoucí: Ing. Michal Voráček Studijní program: Elektrotechnika a informatika, strukturovaný, bakalářský Obor: Výpočetní technika
Květen 2010
4|Systém pro tvorbu internetových stránek
|5
Poděkování Na prvním místě bych chtěl poděkovat rodině a přítelkyni za vytvoření prostředí, které mi umožnilo pracovat na této práci a za trvalou podporu. Dále bych chtěl poděkovat vedoucímu práce Ing. Michalu Voráčkovi za jeho trpělivost a cenné rady, kterými významně podpořil kvalitu této práce.
6|Systém pro tvorbu internetových stránek
|7
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne ..................................
…………………………………………………..
8|Systém pro tvorbu internetových stránek
|9
Obsah Poděkování ....................................................................................................................................... 5 Prohlášení ......................................................................................................................................... 7 Obsah................................................................................................................................................ 9 Seznam obrázků.............................................................................................................................. 13 Abstrakt .......................................................................................................................................... 15 1.
Úvod ....................................................................................................................................... 17 1.1.
1.1.1.
Požadavek na webovou stránku ............................................................................. 17
1.1.2.
Realizace webových stránek ................................................................................... 18
1.1.3.
Uložení webových stránek...................................................................................... 18
1.2.
Co je CMS? ...................................................................................................................... 18
1.2.1.
Proč je potřeba mít CMS? ....................................................................................... 19
1.2.2.
Výhody a nevýhody ................................................................................................ 19
1.2.3.
Požadavky na provoz CMS ...................................................................................... 19
1.2.4.
Uchytilo se CMS? .................................................................................................... 19
1.3.
Katalog požadavků.......................................................................................................... 19
1.3.1.
Obecné nefunkční požadavky ................................................................................. 20
1.3.2.
Specifické funkční požadavky ................................................................................. 20
1.4.
2.
Webové prezentace........................................................................................................ 17
Rešerše existujících řešení .............................................................................................. 21
1.4.1.
Nasazení volně stažitelného redakčního systému přímo uživatelem .................... 21
1.4.2.
Nasazení volně stažitelného redakčního systému internetovou agenturou .......... 22
1.4.3.
Bezpečnostní rizika ................................................................................................. 22
1.4.4.
Možná uživatelská znalost ...................................................................................... 22
1.4.5.
Rychlá reakce na změny ......................................................................................... 23
1.4.6.
Implementace jen potřebného............................................................................... 23
1.4.7.
Shrnutí rešerše........................................................................................................ 23
Analýza ................................................................................................................................... 25 2.1.
Uživatelské role .............................................................................................................. 25
2.2.
Rozdělení systému na jednotlivé části (moduly) ............................................................ 26
1)
Správa administrátorů ............................................................................................ 26
2)
Správa kategorií ...................................................................................................... 29
3)
Správa logů ............................................................................................................. 32
4)
Správa článků.......................................................................................................... 33
5)
Správa fotogalerií.................................................................................................... 36
2.2.1.
Konceptuální diagram tříd ...................................................................................... 38
10 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k 2.2.2. 3.
Návrh...................................................................................................................................... 41 3.1.
Výběr programovacího jazyka........................................................................................ 41
3.2.
Vývojové prostředí ......................................................................................................... 41
3.2.1.
Základní analýza ..................................................................................................... 41
3.2.2.
Tvorba grafického vzhledu ..................................................................................... 42
3.2.3.
Programování aplikace........................................................................................... 42
3.2.4.
Vývoj na lokálním počítači ..................................................................................... 42
3.2.5.
Přenos souborů ...................................................................................................... 42
3.2.6.
Verzování aplikace ................................................................................................. 43
3.2.7.
Unit testování ......................................................................................................... 43
3.3.
Grafika administrace ...................................................................................................... 43
3.3.1.
Rozvržení stránek ................................................................................................... 43
3.3.2.
Hlavní menu ........................................................................................................... 44
3.3.3.
Prototyp návrhu ..................................................................................................... 44
3.3.4.
Grafický návrh ........................................................................................................ 45
3.3.5.
Kódování šablony ................................................................................................... 46
3.3.6.
Stylování šablony ................................................................................................... 48
3.4.
Výběr návrhového vzoru pro aplikaci ............................................................................ 50
3.4.1. 3.5.
MVP – Model View Presenter ................................................................................ 50
Databáze ........................................................................................................................ 51
3.5.1.
Komunikace s databází........................................................................................... 51
3.5.2.
Abstraktní databázová vrstva dibi.......................................................................... 51
3.5.3.
Databázový jazyk SQL............................................................................................. 51
3.5.4.
Vytvoření databáze ................................................................................................ 52
3.6.
Výběr frameworku ......................................................................................................... 52
3.6.1.
Nette Framework ................................................................................................... 52
3.6.2.
Základní vlastnosti.................................................................................................. 53
3.6.3.
Výhody Nette ......................................................................................................... 53
3.7.
4.
Ostatní moduly....................................................................................................... 39
Požadavky na hostingové služby .................................................................................... 53
3.7.1.
.htaccess ................................................................................................................. 53
3.7.2.
mod_rewrite .......................................................................................................... 54
3.7.3.
Shrnutí požadavků na hosting ................................................................................ 54
3.7.4.
Diagram nasazení ................................................................................................... 54
Implementace ........................................................................................................................ 55 4.1.
Adresářová struktura ..................................................................................................... 55
4.2.
Připojení frameworku a databázové vrstvy ................................................................... 56
| 11 4.3.
Základní konfigurace....................................................................................................... 56
4.4.
Konfigurace databáze ..................................................................................................... 57
4.4.1.
Připojení k databázi ................................................................................................ 57
4.5.
Start základní aplikace .................................................................................................... 58
4.6.
Vytvoření jednotlivých částí aplikace ............................................................................. 59
4.6.1.
Tvorba aplikační logiky (presenterů) ...................................................................... 59
4.6.2.
Tvorba šablon aplikace (view) ................................................................................ 61
4.6.3.
Tvorba modelů........................................................................................................ 63
4.7.
Vlastní implementace ..................................................................................................... 65
4.7.1.
Správa kategorií ...................................................................................................... 65
4.7.2.
Správa článků.......................................................................................................... 71
4.7.3.
Správa fotogalerií.................................................................................................... 73
4.7.4.
Správa administrátorů ............................................................................................ 75
4.7.5.
Správa logování a správa chyb................................................................................ 76
4.8.
Shrnutí ............................................................................................................................ 77
4.8.1. 5.
Instalace hotového redakčního systému ................................................................ 77
Závěr ....................................................................................................................................... 79 5.1.
Možnosti dalšího rozšíření.............................................................................................. 79
6.
Seznam použité literatury ...................................................................................................... 81
7.
Seznam použitých zkratek ...................................................................................................... 83
8.
UML diagramy ........................................................................................................................ 85
9.
Instalační příručka .................................................................................................................. 87
10.
Obsah přiloženého CD ........................................................................................................ 89
12 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
| 13
Seznam obrázků Obrázek 1 – Popis získání webové stránky ..................................................................................... 17 Obrázek 2 - Případy užití modulu Administrátorů.......................................................................... 27 Obrázek 3 - Diagram aktivit modulu Administrátorů ..................................................................... 28 Obrázek 4 - Konceptuální diagram třídy modulu Administrátrů .................................................... 29 Obrázek 5 - Případy užití modulu Kategorií .................................................................................... 30 Obrázek 6 - Diagram aktivit modulu Kategorií ............................................................................... 31 Obrázek 7 - Konceptuální třída modulu Kategorií .......................................................................... 31 Obrázek 8 - Případy užití modulu Logování .................................................................................... 32 Obrázek 9 - Diagram aktivit modulu Logování ............................................................................... 33 Obrázek 10 - Konceptuální třídy modulu Logování ........................................................................ 33 Obrázek 11 - Případy užití modulu Články...................................................................................... 34 Obrázek 12 - Diagram aktivit modulu Články ................................................................................. 35 Obrázek 13 - Konceptuální třída modulu Články ............................................................................ 36 Obrázek 14 - Případy užití modulu Fotogalerie .............................................................................. 36 Obrázek 15 - Diagramy aktivit modulu Fotogalerie........................................................................ 37 Obrázek 16 - Konceptuální třídy modulu Fotogalerie .................................................................... 38 Obrázek 17 - Celkový konceptuální diagram tříd ........................................................................... 38 Obrázek 18 - Prototyp návrhu grafického rozhraní ........................................................................ 45 Obrázek 19 - Grafický návrh uživatelského rozhraní ...................................................................... 46 Obrázek 20 - Ukázka základní HTML šablony ................................................................................. 48 Obrázek 21 - Ukázka CSS souboru .................................................................................................. 49 Obrázek 22 - Schéma komunikace návrh.vzoru MVP..................................................................... 50 Obrázek 23 - Ukázka rozhraní PhpMyAdmin.................................................................................. 52 Obrázek 24 - Diagram nasazení systému........................................................................................ 54 Obrázek 25 - Adresářová struktura ................................................................................................ 55 Obrázek 26 - Ukázka základní konfigurace cest ............................................................................. 56 Obrázek 27 - Konfigurace databáze................................................................................................ 57 Obrázek 28 – Spuštění aplikace souborem bootstrap.php ............................................................ 58 Obrázek 29 - Adresářová struktura presenterů.............................................................................. 60 Obrázek 30 - Ukázka presenteru .................................................................................................... 60 Obrázek 31 - Ukázka šablony.......................................................................................................... 62 Obrázek 32 - Propojení šablon ....................................................................................................... 62 Obrázek 33 - Ukázka třídy modelu ................................................................................................. 63 Obrázek 34 - Ukázka ActiveRecord................................................................................................. 64 Obrázek 35 - Funkce pro hledání všech kategorií........................................................................... 66 Obrázek 36 - Předání kategorií do šablony..................................................................................... 66 Obrázek 37 - Výpis všech kategorií v šabloně................................................................................. 66 Obrázek 38 - Ukázka výpisu všech kategorií ................................................................................... 67 Obrázek 39 - Vložení formuláře ...................................................................................................... 67 Obrázek 40 - Ukázka kódu vytvoření formuláře ............................................................................. 68 Obrázek 41 - Ukázka kódu zpracování formuláře........................................................................... 68 Obrázek 42 - Generování unikátní URL .......................................................................................... 69 Obrázek 43 - Ukázka vykreslení formuláře ..................................................................................... 70 Obrázek 44 - Ukázka zachycení signálu pro smazání kategorie ..................................................... 71
14 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k Obrázek 45 - Stránkování výpisu .................................................................................................... 72 Obrázek 46 - Výpis se stránkováním .............................................................................................. 72 Obrázek 47 - Komponenta výběru data ......................................................................................... 73 Obrázek 48 - Vykreslení všech vložených fotografií....................................................................... 75 Obrázek 49 - Nastavení zachycení chyb ......................................................................................... 77 Obrázek 50 - Celkový diagram případů užití .................................................................................. 85 Obrázek 51 - Finální logický diagram tříd....................................................................................... 86 Obrázek 52 - Finální ER diagram .................................................................................................... 86
| 15
Abstrakt Cílem této bakalářské práce implementace elektronického systému pro správu obsahu webových prezentací. Součástí je vstupní analýza, kde definuji základní požadavky na implementovaný systém, následované vlastní implementací a zakončené uživatelským testováním. Práce je rozdělena na tři části, které částečně korespondují s tradičním životním cyklem softwarového produktu. V první části s názvem Úvodní část, je popsáno, co to vůbec nástroj pro správu obsahu je, jaké jsou jeho výhody a nevýhody, co to může přinést klientům a co autorovi webových stránek. Jsou zde detailně popsány požadavky na výsledný produkt a návrh řešení, kterým to budu implementovat. Rovněž zde zmíním některá již hotová řešení, volně dostupná na internetu a výhody vlastní implementace. Další část pojmenovanou jako Analýza jsem si vyhradil na detailní rozdělení aplikace na jednotlivé moduly a jejich analýzu až na nejnižší úroveň. Je zde popsáno, jak jednotlivé moduly fungují, s jakými daty pracují a jaké je jejich dynamika. V neposlední části Implementace je popsáno již vlastní implementace aplikace. Je zde popsán výběr programovacího jazyka, databáze, frameworků a dalších potřebných prostředků pro zdárnou implementaci. Je zde popsán rámcově základní postup a hlavní problémy při implementaci. V poslední části je uvedeno uživatelské otestování aplikace pomocí několika vybraných uživatelů, které se pokusím vybrat tak, aby jejich znalosti pokrývali určitě spektrum znalostí práce s počítačem. Výsledné řešení implementuji na reálné webové stránce, která bude přes tento systém modifikovatelná a upravovatelná. Při psaní práce jsem vycházel především ze znalostí, které jsem nabyl tvorbou několika desítek webových prezentací s redakčním systémem a mám tedy již určitě zkušenosti s tím, co opravdu lidé vyžadují a co je již zbytečné implementovat. Důraz je kladen na modulární vývoj, tak aby implementovaný systém byl co nejvíce znovupoužitelný a nebyl problém dodatečně naprogramovat jakoukoli funkčnost.
16 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
| 17
1.
Úvod
V dnešní době, kdy je internetová síť rozšířená po celém světě, se z Internetu stal velice významný komunikační a reklamní kanál. Pokud chce být jednotlivec nebo firma vidět, chce prezentovat sebe, nebo své produkty, je takřka nezbytné mít na Internetu umístěnu svojí webovou prezentaci. Vytvoření takové prezentace se pohybuje již v řádech tisíců korun, takže je dostupné většině firem i jednotlivců.
1.1.
Webové prezentace
Název webová prezentace je vlastně označení sady několika málo až několika tisíců souborů, které jsou uložené na webovém serveru. Těmto souborům se říká webové stránky a jsou doplněny dalšími soubory, např. obrázky, kaskádovými styly pro popis vzhledu a dalšími soubory nezbytnými pro kompletnost webové prezentace. Tyto stránky jsou propojeny hypertextovými odkazy, takže je možno se z jedné stránky dostat na druhou pouhým klikáním ve webovém prohlížeči. Toto je vlastní podstata internetové sítě. 1.1.1. Požadavek na webovou stránku Pokud tedy například zadáme do webového prohlížeče www.seznam.cz, vytvoříme tím požadavek na webovou stránku. Tento požadavek nejdříve putuje na DNS server. Ten má za úkol to, že naší adresu www.seznam.cz přeloží na IP adresu. IP adresa je čtveřice 8mi bytových čísel zapsaných v dekadické soustavě. Příklad takové IP adresy je např. 77.75.76.3 (toto je reálná IP adresa serveru seznam.cz). Tuto IP adresu můžeme zjistit i ze svého počítače, pokud v příkazové řádce napíšeme „ping www.seznam.cz“ bez uvozovek. Když už máme IP adresu cílového serveru, požadavek doputuje na webový server, ten ho zpracuje a jako odpověď odešle požadovanou webovou stránku. Webové servery jsou většinou umístěny na páteřní síti ve web-hostingovém centru, kde mají speciální napájení, chlazení a
Obrázek 1 – Popis získání webové stránky
18 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k různé zálohovací a podpůrné technologie, pro bezpečný non-stop provoz. 1.1.2. Realizace webových stránek Firem zabývajících se tvorbou webových prezentací je nespočet, proto nebývá problém najít někoho, kdo takové stránky vytvoří. Komplikace nastávají v okamžiku, kdy se majitel stránek rozhodne změnit obsahovou část stránek, nahrát nové fotografie, přidat nový produkt, nebo pouze upravit telefonní číslo v kontaktních informacích. Teď je potřeba vysvětlit, jak jsou vlastně takové webové stránky uloženy na webovém serveru. Těchto způsobů je mnoho, já vysvětlím pouze dva základní způsoby, které postačí k popisu problému. 1.1.3. Uložení webových stránek Jedna z možností je mít vlastní text webových stránek uložen přímo v kódu stránky. Takto je celá webová stránka uložena jako jeden HTML dokument a je přímo zobrazitelná ve webovém prohlížeči. Je to nejjednodušší možnost uložení webových stránek. Většinou není potřeba nic programovat a vystačíme si se šablonami, které nám dodá přímo kodér. Kodér je člověk, který převádí graficky návrh do HTML šablon. Pokud ale chceme změnit nějaký obsah, musíme se nejdříve připojit na webový server, nejčastěji pomocí FTP protokolu, přes FTP klienta. Dále musíme danou HTML stránku najít a zkopírovat jí na svůj počítač. Když máme stránku zkopírovanou, tak jí již můžeme editovat, ale needitujeme čistý text, ale text, který je proložený HTML značkami, takže musíme dávat pozor, abychom zachovali sémantiku značek a jejich správnou posloupnost. Takto může upravovat stránky pouze člověk, který HTML jazyku rozumí a ještě navíc musí projít procesem stažení stránky a po skončení úprav zase nakopírováním zpět na server. Každá taková úprava zadaná přímo tvůrci stránek by byla nejenom relativně finančně nákladná, ale také by ho zbytečně zatěžovala. Další možností je mít obsah stránek uložen v nějakém datovém úložišti, například textovém souboru, anebo nejlépe v databázi. Pokud máme text uložen v databázi, již máme daleko větší možnosti jak s ním pracovat, počínaje řazením, úpravami a jiné. Můžeme tak již vyrobit redakční systém, který se umí na tuto databázi připojit a editovat cílové texty zde uložené. Tato varianta je sice náročnější, protože se redakční systém musí nasadit, upravit šablony, navrhnout databázovou strukturu a další, ale odpadá nutnost administrovat stránky po dobu provozu, což má za následek snížení nákladů na provoz a ušetření času. Z tohoto důvodu je vhodné nasazovat klientům redakční systémy, neboli CMS[1] a proto se tím také budu zabývat v této bakalářské práci.
1.2.
Co je CMS?
CMS je zkratka pro Content Management System, neboli nástroj pro správu obsahu. Nejčastěji je s touto zkratkou spojován nástroj pro správu obsahu webových stránek, nebo webových aplikací. Dále se tento systém označuje také jako redakční systém, administrace, publikační systém a jiné. Ať již je pojmenování jakékoli, vždy se jedná o webovou aplikaci, která umožňuje nějakým způsobem upravovat data, která se ve výsledku zobrazují na cílových webových stránkách. Může se jednat jak o formátovaný text, tak i obrázky, různé dokumenty např. PDF, tak i jiné soubory, které budou dostupné jako odkazy na cílový soubor na disku serveru, kde webové stránky běží.
| 19 1.2.1. Proč je potřeba mít CMS? Jak již sem zmínil v úvodu, pokud narazíme na problém, že potřebujeme upravit nějaký text na stránce, nebo třeba nahrát novou fotografii naší nové reference, je relativně finančně náročně a zdlouhavé kontaktovat autora stránek. V tomto směru nám CMS výrazně pomůže, protože si všechny úpravy můžeme dělat sami a tyto úpravy jsou ihned viditelné na spravovaných webových stránkách. 1.2.2. Výhody a nevýhody Výhodou nástroje pro správu obsahu je jednoznačně zjednodušení úpravy obsahu webových stránek. Pokud je systém dobře navržen, zvládne tuto úpravu každý, kdo zvládá základní práci s počítačem. Jsou zde zřejmé časové i finanční úspory. Navíc pro práci v CMS není potřeba znát žádné programovací ani skriptovací jazyky. Vystačíme si naprosto se základní znalostí práce na počítači a práci v nějakém textovém editoru, např. Microsoft Word, nebo Google Docs. Takový redakční systém musí ovšem být navržen tak, aby byl uživatelský přívětivý a srozumitelný. Měl by co nejméně zatěžovat uživatele a pomáhat mu s prací v systému. Navíc nejsme vázáni na konkrétní počítač, přihlásit se můžeme odkudkoli kde je možnost připojení k internetu a nainstalovaný webový prohlížeč. Nevýhodou by mohl být vyšší rozpočet na tvorbu celé webové prezentace. CMS nám tento rozpočet jistě navýší, v budoucnu nám ale přinese nemalé úspory, pokud bude potřeba editace výsledných stránek. Další nevýhodou je bezpečnost celého řešení. Vzhledem k tomu, že systém umožňuje modifikaci webových stránek, je to také rizikové místo pro různé útoky osobami, které do systému nesmí mít přístup. 1.2.3. Požadavky na provoz CMS Jak již bylo uvedeno výše, provoz CMS vyžaduje pro svůj běh databázový systém. Databáze bývá u všech hostingových tarifů již běžnou součástí, ale u levnějších tarifů bychom mohli narazit na problém, že v sobě nebude zahrnovat provoz databáze a bude nutné buď stránky přesunout, nebo si připlatit za zpřístupnění databáze. Dalším požadavkem bude podpora programovacího jazyka a dalších modulů, které upřesníme až v implementační části. 1.2.4. Uchytilo se CMS? CMS je výborné řešení, jak za relativně nízkou počáteční investici získat nástroj, pomocí kterého můžete dlouhodobě spravovat obsah a strukturu vašich stránek. Z vlastních zkušeností vím, že je dnes takřka samozřejmostí nasazovat nové webové prezentace s redakčním systémem a proto jsem se také rozhodl pro toto téma pro zpracování bakalářskou prací.
1.3.
Katalog požadavků
V této práci se tedy budu zabývat návrhem redakčního systému, který nám bude umožňovat spravovat naše webové stránky. Ale co všechno od něho budeme požadovat? Když jsem před několika lety začal nasazovat klientům redakční systém, snažil jsem se jít cestou kvantity a implementoval jsem jim tam vše, co šlo zpracovat. Například, že jsem po uživateli vyžadoval, aby při vytváření nové stránky zadávali URL adresu vkládané stránky. Byl jsem v domnění, že pokud bude mít uživatel možnost zadat svojí URL, bude tak URL nejvýstižnější a zajistí tak správné zařazení do indexu vyhledávacích robotů. Toto vše bylo krásně funkční, nicméně většina uživatelů vůbec nevěděla k čemu je to dobré a vyplňovali položku URL,
20 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k jenom „protože to bylo potřeba“. Byl to tak pro ně další zbytečný krok navíc. V tomto systému se proto budu snažit co nejvíce zjednodušit práci v systému. 1.3.1. Obecné nefunkční požadavky V tomto CMS, nejenom že bude napsán kompletně od začátku a čistě objektově jsem se také rozhodl napsat systém tak, aby po uživateli vyžadoval co nejméně věcí, ale zároveň funkčnost zůstala zachována. Pokud bych vzal jako příklad vkládání URL, jde to udělat například tak, že při vkládání nové stránky nebudeme po uživateli URL požadovat, budeme jí generovat automaticky a pokud si bude chtít URL adresu uživatel upravit, bude tak mít možnost v editaci stránky. V systému musí být možnost pracovat intuitivně, přehledně a rychle. CMS bude navrženo tak, aby bralo ohledy na SEO[2] optimalizaci, což znamená, že systém musí dát na výběr měnit ty požadavky, které jsou pro SEO optimalizaci klíčové, jako například meta tagy title, keywords a description. Tato optimalizace zaručí, že budou webové stránky správně zaindexovány vyhledávacími roboty. Systém bude navržen modulárně, aby nebyl problém doplnit do systému skoro jakoukoli funkcionalitu, nebo chování. Dále bude systém dbát na dodržení pravidel přístupného[3] a použitelného webu. 1.3.2. Specifické funkční požadavky Základní požadavek pro každý CMS je editace jednotlivých webových stránek, které nám tvoří webovou prezentaci. Nástroj by měl umožňovat, aby si správce stránek sám vytvořil, nebo editoval jednotlivé sekce, do těchto sekcí vložil, nebo upravil text, popřípadě proložil tento text obrázky. Toto by měl umět každý CMS a můj nástroj pro správu obsahu to bude umět také. Všechny funkční požadavky na můj systém vypíši přehledně, pro snadnou orientaci. 1. Systém bude umožňovat navržení hierarchie stránek a. Pro každou stránku bude možno vyplnit parametry, např. nadpis, nebo text a dále nutné položky pro tvorbu SEO optimálních stránek. b. Stránky budou mít svoje pořadí v menu a toto pořadí půjde změnit. c. Stránky bude možno přidávat, upravovat a mazat. d. Bude možnost vložit podstránku k existující stránce. 2. Do systému se bude možno přihlašovat, přes unikátní uživatelské jméno a. Uživatelské účty bude možno vytvářet, upravovat a mazat b. Každému uživateli bude možno přidělit určitá práva c. Bude umožněno vytvořit různé uživatelské profily, které budou zahrnovat určitě nastavení práv 3. Systém bude ukládat provoz do logů a přehledů a. Bude evidovat požadavky na stránky, které budou vracet chybový kód 404 b. Umožní evidovat přístupy do administrace c. Bude vypisovat shrnutí o počtu uživatelů, počtu vložených fotogalerií, článků atp. 4. Systém bude umožňovat spravovat články a. Do systému bude možno vložit nový článek, upravit ho a smazat b. Články se budou schvalovat uživatelem, který pro to bude mít oprávnění c. Článek bude zobrazitelný až po schválení oprávněným uživatelem
| 21 d. Do článků půjdou vkládat obrázky a odkazy na přílohy 5. V systému bude možno spravovat fotogalerie a. Bude možno zobrazit existující fotogalerie b. Půjde přidat galerii, editovat jí anebo smazat c. Do této galerie bude možno vkládat obrázky a mazat je d. Každý vložený obrázek bude mít svoje pořadí, které půjde měnit e. Každý obrázek bude mít svůj popisek a alternativní popis, který půjde změnit f. Jeden z vložených obrázků půjde označit jako „úvodní fotka galerie“ g. Fotografie půjde připojit ke kategorii, nebo k existujícímu článku, takže se na spravovaných stránkách zobrazí pod zvolenou kategorií, nebo článkem Toto je základní výčet požadavků, které by náš systém měl splňovat a umožňovat. Vzhledem k modulárnosti systému bude možno naprogramovat jakoukoli novou funkčnost, nebo rozšíření existující funkčnosti.
1.4.
Rešerše existujících řešení
Redakční systém není žádnou novinkou, ani převratným vynálezem, na internetu lze najít desítky a možná i stovky různých redakčních systémů[4], z nichž některé jsou i od českých tvůrců. Pokud z pomyslného seznamu redakčních systémů vyškrtneme komerční řešení a dále systémy, které se moc neuchytily, a nikdo je nepoužívá, zůstane nám jich možná jedna desítka. Ze seznamu záměrně vyškrtávám všechna komerční řešení, protože většinou není možnost volného testování těchto produktů a tyto produkty ani nelze použít pro vlastní úpravu a prodej zákazníkům. Nasazením komerčních RS se zabývají přímo autoři systému, nebo společnost, která tento produkt vlastní. Mezi nejznámější redakční systémy, které jsou volně ke stažení, bych jmenoval Wordpress, Drupal, Joomla a Blog: CMS a těmito systémy se budu zabývat v následující rešerži. Poslední ze seznamu jsou z české dílny. V následující tabulce uvedu hlavní výhody a nevýhody, které následné jednotlivě rozeberu. Výhody vlastního RS neomezená rozšiřitelnost rychlá reakce na jakoukoli změnu zkušenosti s vývojem implementace jen nejpotřebnějšího přizpůsobení firmě (logo) vlastní prověřené řešení
Výhody hotového open-source zdarma, již hotové řešení mnoho rozšíření široká komunita možná uživatelská znalost nasazení přímo uživatelem
Tabulka 1 - Výhody a nevýhody vlastního řešení
1.4.1. Nasazení volně stažitelného redakčního systému přímo uživatelem Volně stažitelné redakční systémy jako např. WordPress mohou lákat uživatele zdánlivou jednoduchostí. Uživatelé jsou přesvědčeni, že pouze stáhnou instalační balíček z internetu,
22 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k nahrají na server a vše bude běžet. Nicméně pokud nechceme mít vytvořeny stránky podle standardního vzhledu jako to má stovka ostatních uživatelů, chceme mít stránky s vlastním vzhledem a rozmístění prvků, již jsou nutné úpravy. Další problém nastává, pokud chceme do systému přidat určitou funkčnost. Je potřeba vědět, jak se taková rozšíření instalují, toto rozšíření vyhledat a pak teprve nainstalovat a nakonfigurovat. Toto rozšíření třeba ani nemusí být k dispozici. Většina zákazníků nemá čas učit se, jak se volně stažitelný systém instaluje, nastavuje a je to pro ně i zbytečné, protože to budou potřebovat pouze jednou pro prvotní nasazení. 1.4.2. Nasazení volně stažitelného redakčního systému internetovou agenturou Výhodnější v tomto případě je, pokud se nasazení volně stažitelných redakčních systémů zabývá přímo internetová agentura. Znalost nasazení se jim zúročí několikrát a již to nabývá určitého smyslu. Jsem přesvědčen, že pro určitá řešení je nasazení již hotového redakčního systému ta správná volba, ale jistě se najdou i řešení, kdy je potřeba systém navrhnout kompletně od začátku vzhledem k vysokým požadavkům zákazníka, nebo velice specifickému zadání, např. internetové aukce, rozsáhlé portály, věrnostní programy, mediální průzkum. Pro tyto případy je nejvhodnější mít připraveno jádro vlastního redakčního systému, s hotovou objektovou analýzou. Na tomto řešení se dá velice pohodlně stavět a nemusíme výsledný systém skládat z různých volně stažitelných rozšíření, u kterých nemáme ani záruku správného chování, ani přesně definované funkce. Je tu však možnost naučit se některý volně stažitelný systém velice dobře a požadované rozšíření si psát sám. Nicméně pořád budeme závislý na ostatních součástech systému, které jsme nevyvíjeli my a nebudeme tak moct pohotově reagovat na případné změny, nebo na právě objevenou bezpečností díru. 1.4.3. Bezpečnostní rizika Jednou z možných bezpečnostních rizik může být to, že volně stažitelné redakční systémy mají také volné přístupové zdrojové kódy. Každý si tak může podívat přímo na to, jak aplikace funguje a tak manipuluje s daty uživatele. Samozřejmě, pokud je systém navržen opravdu bezpečně, tak zveřejnění zdrojových kódů nevadí, ale stejně tak platí, že každý softwarový produkt obsahuje chyby. Dalším bezpečnostním rizikem by mohl být fakt, že čím je software rozšířenější, tím je častějším terčem pro různé útoky uživatelů, nebo i robotů, kteří mají na starosti přímo vyhledávání stránek, které jsou administrovány konkrétními široce známým redakčním systémem. Pokud robot ví, o jaký redakční systém se jedná, může tak i automaticky rozpoznat, kde se nachází pole pro vložení komentářů, jak je potřeba ho obejít a vkládat tak automaticky odkazy na jiné stránky. 1.4.4. Možná uživatelská znalost „Možná uživatelská znalost" značí, že s daným redakčním systémem se mohl uživatel již v minulosti setkat a zná, jak se ovládá a je na něj zvyklý. Základní požadavek našeho systému je, že by měl být natolik intuitivní a použitelný, aby nebylo pro uživatele těžké se zorientovat, i když se systémem v životě nepracoval.
| 23 1.4.5. Rychlá reakce na změny Jen s vlastním řešením můžeme rychle reagovat na změny zadání, rychle objevit bezpečnostní chybu, nebo jakoukoli chybu v systému. Nemůžeme si dovolit čekat 14dní v případě volně stažitelného systému, až někdo z jeho komunity, zmiňovanou bezpečnostní díru opraví. Pro tyto případy je vždy nejlepší mít vlastní systém, který bude navržen přímo na míru a nebude složen s volně dostupných rozšíření. 1.4.6. Implementace jen potřebného Pokud do systému implementuji jenom to, co zákazník opravdu potřebuje a využije, nebude v systému desítky voleb a možností a uživatel nebude mít tak velký problém se se systémem naučit pracovat. Systém pro něho bude přehlednější a práce v něm efektivnější. 1.4.7. Shrnutí rešerše Mým záměrem není vytvořit konkurenci výše zmiňovaných redakčních systémů, které jsou vhodnější spíše pro nasazení na blog, nebo magazín, kde se budou uveřejňovat nové články každý den a tyto systémy jsou na toto použití přímo vytvořeny. Mým cílem je vytvořit základní jádro systému, ke kterému budu mít hotovu objektovou analýzu a budu moct kdykoli na tento základ postavit jasně definovanou funkčnost, dle zadání klienta. Základní jádro systému bude akorát vybaveno moduly, které jsou většinou vyžadovány, jako např. správa obsahu stránek, připojitelných fotogalerií, anebo správa aktualit. Ostatní moduly bude možno, vzhledem k modulárnímu návrhu, rychle dopsat. Pokud k výhodám vlastního systému připočtu fakt, že chci tento systém napsat sám od začátku z důvodu získání zkušeností s vývojem, je toto řešení jasnou volbou.
24 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
| 25
2.
Analýza
V předchozí kapitole jsem popsal, co je cílem mé práce, co to má umět. V této části musíme blíže specifikovat, jací uživatelé budou mít do systému přístup, a podrobněji se podíváme na jednotlivé funkční požadavky systému, jaké položky přesně budou uchovávat, jak se budou chovat a jak budou komunikovat s ostatními. Popíši to za pomocí modelovacího jazyka UML[5], kterým vytvořím diagramy popisující strukturu a chování systému. Tyto diagramy pomohou lépe pochopit chování aplikace. Již v úvodu jsem si specifikoval, že systém bude navržen objektově a modulárně. Nabízí se tedy požadavky rozdělit na jednotlivé moduly a tyto moduly popsat jednotlivě, aby byl popis přehlednější. Musím se také snažit mezi moduly zachovat tenkou vazbu, vzhledem k tomu, že některé moduly nebudou muset být v systému vůbec přítomny. Na moduly, které budou v systému přítomny vždy, takzvané jádro systému se mohou vztahovat ostatní moduly, aniž by počítali s tím, že by mohly být odebrány a v systému nebýt dostupný.
2.1.
Uživatelské role
Vzhledem k tomu, že do našeho systému bude mít přístup více uživatelů a ne každý bude mít možnost např. schvalovat články, nebo vytvářet další administrátory, je potřeba v systému definovat různé uživatelské role a jejich práva. Toto bude mít na starosti modul administrátorů. Ve výsledném systému budou tyto role implementovány jako „šablony práv“. Budou to přednastavené profily, které bude stačit přidat k vytvářenému administrátorovi a odpadne nutnost nastavovat práva jednotlivě. Základní uživatelské role, které bych chtěl do systému implementovat jsou: 1) Writer: a) Přihlašovat se do registrace b) Vytvořit článek c) Vkládat obrázky k článkům d) Prohlížet všechny schválené články e) Editovat, nebo smazat svůj článek, který není schválen Writer bude úplně základní profil uživatele, který bude mít přístup do administrace. Bude mít možnost akorát vytvořit nový článek, editovat pouze svoje články a vkládat do nich obrázky. Po schválení takového článku redaktorem již nebude Writer mít možnost tento článek editovat. 2) Redactor – může všechno co Writer a dále: a) Schvalovat všechny články, nebo naopak zablokovat b) Editovat úplně všechny články c) Editovat všechny fotogalerie d) Připojovat všechny galerie k jakémukoli článku, nebo kategorii Redactor bude mít ty samá práva co Writer, ale navíc bude mít možnost schvalovat napsané články a provádět korekturu. Editace článků nebude omezena na autory, bude mít možnost editovat úplně všechny články i ty schválené. K takovému článku bude moct připojit fotogalerii.
26 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k 3) Administrator – může všechno co Redactor a navíc: a) Vytvářet, editovat a mazat uživatele i) Nastavování profilů práv ii) Změna práv uživatele iii) Blokování uživatele b) Přístup k modulu Správa kategorií i) Vytváření, editace a mazání kategorií ii) Připojování fotogalerií ke kategoriím c) Přístup do modulu Logování a shrnutí i) Zobrazení a mazání logů ii) Nastavení co se má logovat Administrátor bude mít nejvyšší možná oprávnění. Bude moct to samé co Redactor a Writer, ale ještě navíc bude mít možnost tvořit hierarchii stránek a editovat vlastní webové stránky. Také bude spravovat všechny uživatele, co jsou v systému, takže je bude moct vytvářet a upravovat jim přidělená práva. Poslední z možností bude přístup do logů a shrnutí, kde bude mít přehled o provozu systému a shrnutí vloženého obsahu. Toto budou přednastavené profily práv a při vytváření nového uživatele bude moct administrátor vybrat již přednastavený profil, s tím, že pokud by mu nastavení práv nevyhovovalo, může tyto práva detailně nastavit v editaci uživatele. Rovněž bude moct administrátor vytvářet nové profily práv, pokud bude potřeba vytvořit v systému více uživatelů, kteří budou mít specifická práva. Tyto základní přednastavené profily doplňuji diagramem případů užití (Use-case diagram), který graficky shrnuje práva a možnosti jednotlivých uživatelů. Vzhledem k tomu, že aplikaci navrhuji pomocí modelů, je tento diagram jen jeden z mnoha UML diagramů, které budu v mojí práci používat. Tento diagram je součástí přílohy B.
2.2.
Rozdělení systému na jednotlivé části (moduly)
Některé z modulů budou tvořit jádro systému, to budou neměnné moduly, které budou vždy přítomny. Bude se jednat o správu kategorií stránek, přihlašování do systému a logování. U těchto modulů nemusí být dodržena tenká vazba, protože se vychází z jejich permanentní přítomnosti. Ostatní moduly budou doplňkové a budou se připojovat jen v případě nutnosti. Je zde vysoký požadavek na dodržení nezávislosti. 1) Správa administrátorů Úplně nejzákladnější modul, který bude součástí jádra a bude v systému přítomen vždy, je modul Správa administrátorů. V tomto modulu budeme spravovat všechny uživatele, kteří budou mít do redakčního systému přístup. Tyto uživatelé budou mít nastavená práva, která jim umožňují provádět různé akce v systému. Od modulu Správy administrátorů budu vyžadovat tyto funkcionality, které vychází jak z úvodních požadavků, ale také jsem je doplnil, kvůli zajištění pohodlného ovládání systému: • • •
Přihlášení uživatelů do systému Přidání, editace a mazání uživatelů systému Výpis všech uživatelů s jejich stavem
| 27 • •
Nastavení jednotlivých práv Editace přednastavených profilu práv (např. Writer, Redactor)
Tyto akce shrneme do případu užití a dále vyznačíme, kteří uživatelé budou mít pro danou akci přístup a kteří nikoli. Vycházím z toho, že máme definovány tři základní profily práv a to Writer, Redactor a Administrator.
Obrázek 2 - Případy užití modulu Administrátorů
Dále je potřeba uvést, jaké akce se budou při jednotlivých případech užití vykonávat a jaké bude jejich pořadí. Které kontroly se budou provádět a jaký to bude mít vliv na systém. Toto nejlépe popíšeme opět UML diagramem, ale tentokrát diagramem aktivit.
28 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
Obrázek 3 - Diagram aktivit modulu Administrátorů
Při přihlášení do systému je potřeba kontrolovat, jestli údaje, které zatím neznámý uživatel zadává, jsou správně. Kontroluje se existence uživatelského jména a správnost zadaného hesla. Pokud tyto údaje nesouhlasí, uživatelovi není povolen vstup do administrace a je mu zobrazeno hlášení o neplatném pokusu o přihlášení zároveň s doporučením, aby se pokusil zadat heslo opětovně a zkontroloval si přitom, jestli nemá náhodou zapnutý Caps Lock na své klávesnici. Dále je možno zobrazit informaci o tom, že může v případě problému s přihlášením kontaktovat administrátora systému. Při vkládání, nebo editaci uživatele, se akorát testuje, jestli se zadané uživatelské jméno již v systému nevyskytuje, vzhledem k tomu, že uživatelské jméno musí být unikátní, kvůli možnosti rozpoznání více uživatelů. Při editaci bude možnost také uživatele zablokovat a to nezaškrtnutím volby „aktivní“. Tuto možnost bude mít ale pouze uživatel s právy administrátor.
| 29 Dále je potřeba si pro tuto část systému definovat, jaké všechny položky budeme chtít uchovávat. Z těchto údajů pak sestavíme příslušnou třídu. Co všechno je potřeba evidovat u modulu Správa administrátorů: • • • • • •
Přihlašovací jméno – login Jméno a příjmení administrátora – name Heslo – password, passwordSalt Příznak active, který nám určí, jestli je uživatel aktivní anebo zablokován Údaj o tom, jestli může být administrátor smazán, nebo nikoli – immortal Jednotlivé příznaky nastavených práv – právo pro psaní článků, právo pro schvalování, právo pro editaci a vytváření kategorií, právo pro vytváření fotogalerií a nakonec právo pro vytváření administrátorů a sledování logů. Všechny tyto příznaky budou mít prefix rule
Výsledný konceptuální diagram třídy, neboli Class Diagram bude vypadat následovně, s tím, že v implementační části ho ještě doplníme, podle potřeb programovacího jazyka a použitých technologií.
Obrázek 4 - Konceptuální diagram třídy modulu Administrátrů
S největší pravděpodobností dojde k odstranění položky passwordSalt, která je potřebná jako doplněk s položce password, ale je možno místo této položky použít i uživatelské jméno. O významu této položky se zmíním až v implementační části. 2) Správa kategorií Modul Správa kategorií bude mít na starosti vytváření hierarchie stránek a bude rovněž součástí „jádra systému“. Tyto stránky budou reprezentovány jako strom, takže každá stránka bude mít svého rodiče. Tyto stránky už přímo reprezentují zobrazitelné stránky na webových stránkách, které budeme přes redakční systém spravovat. Uživatel si tímto bude moct stránky vytvářet a pomocí URL odkazů, nebo přímo odkazem v menu na tyto stránky odkazovat. Menu se bude tvořit automaticky, podle toho, jestli u vytváření kategorie zvolíme, že chceme stránku zobrazit v menu, či nikoli. Tímto půjde sestavit přímo strukturu hlavního menu stránek a jeho obsahu.
30 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k Pro tyto kategorie budeme potřebovat následující možnosti: • • •
Přidání, editace a mazání kategorií Výpis všech kategorií s vyznačení jejich hierarchie Přesun pořadí každé stránky v rámci své větve ve stromu hierarchie
Tyto možnosti modulu Správa kategorií shrneme do případu užití a dále vyznačíme, kteří uživatelé budou mít pro danou akci přístup a kteří nikoli.
Obrázek 5 - Případy užití modulu Kategorií
Z případu užití pro Správu kategorií vidíme, že jediný, kdo bude mít právo pro tyto akce, bude Administrátor. Jedná se o akce, které se většinou provádí při prvotním plnění a tvorbě stránek a mají přímý vliv na výslednou podobu a funkčnost stránek, proto je velice důležité, aby právo k těmto modifikacím měl pouze hlavní administrátor systému. I pro tuto kategorii sestavím diagram aktivit, ale zde to bude jednoduché, protože kategorie potřebujeme pouze vytvářet, editovat a mazat.
| 31
Obrázek 6 - Diagram aktivit modulu Kategorií
Při vytváření nebo editaci kategorie, je potřeba sledovat duplicity a to hlavně při vyplňování položky URL. To je jedinečný identifikátor stránky, který lze přímo adresovat jednotlivé stránky. Každá stránka se vytváří buď jako nová, anebo jako potomek nějaké existující stránky, čímž se zařadí hierarchicky pod tuto stránku. Změna pořadí se bude provádět přímo ve výpise kategorií kliknutím na šipku nahoru a dolů a změna se přímo projeví, není tak potřeba pro tuto akci sestavovat scénář. Pro modul Správa kategorií bude důležité uchovávat tyto informace: • • • • • •
Informace dané stránky. HTML tagy Title, Description, Keywords. Nadpis stránky – headings Obsah stránky – text URL adresa stránky – url Pořadí stránky - order A nakonec příznaky, jestli bude stránka indexovatelná a jestli bude zobrazena v menu, to budou položky isIndexable a isInMenu
Obrázek 7 - Konceptuální třída modulu Kategorií
32 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k Základní položky jako nadpis stránky a text není třeba více vysvětlovat. Za vysvětlení stojí položka isInMenu, která bude mít binární hodnotu a bude nám definovat, jestli se má položka zahrnou při vykreslování menu stránky. Pokud tuto volbu nezaškrtneme, stránka se v menu neobjeví, což můžeme využít například pokud chceme vytvořit jen nějakou informační podstránku, na kterou budeme odkazovat v jiném textu. Pokud by volba nebyla zaškrtnutá a ani se nikde v jiném textu nenacházel odkaz na tuto stránku, tak nebude stránka přes samotnou webovou prezentaci dostupná. Toho můžeme využít například i pro koncepty stránek a podobně. Pokud bude volba zaškrtnutá, stránka bude vykreslena jako položka menu a její pořadí v menu bude určeno právě položkou order. 3) Správa logů Tato kategorie nám bude sloužit k logování provozu stránek. Bude sice součástí jádra, ale ne vždy bude tato funkce přístupná. Například na obyčejných stránkách nemá smysl administrátora stránek zatěžovat informacemi o tom, když se do systému přihlásil a jaká komponenta stránek vygenerovala jakou chybu. Tyto chyby budou ošetřeny tak, že se bude například jednou denně zasílat email o vygenerovaných chybách výrobci stránek, který dostane informace o nefunkčnosti a opraví je, bez vědomí majitele stránek. Pokud bude funkce zpřístupněna, mělo by zde být vidět, kdy se který uživatel přihlásil do systému, nebo chybové požadavky, které budou vracet chybový HTTP kód č. 404 [6]. Dále by zde mohlo být shrnutí, kde bude zobrazeno, kolik je v systému uživatelů, článků a fotogalerií. Pro tento modul budeme požadovat: • • •
Seznam logů a jejich vymazání Nastavení co se všechno bude logovat Zobrazení shrnutí o používání systému, nebo spravovaných stránek
Obrázek 8 - Případy užití modulu Logování
Pro prohlížení logů, nebo nastavení, které akce se mají logovat, bude moct přistupovat vždy jenom administrátor. Pro tuto kategorii bude jednoduchý scénář popisující pouze nastavení toho, co se bude v systému logovat.
| 33
Obrázek 9 - Diagram aktivit modulu Logování
Pro tuto kategorii budeme mít pro začátek dvě třídy. První bude reprezentovat ukládání chyb, které bude vracet systém a druhá třída bude reprezentovat ukládání přístupu redaktorů, autorů článků a administrátorů do systému.
Obrázek 10 - Konceptuální třídy modulu Logování
Třída LogError se nám bude starat o ukládání chybových zpráv. Bude se evidovat URL adresa, z které tato chyba vznikla, IP adresa uživatele na stránkách a datum vzniku chyby. V druhé třídě LogAccess se bude akorát ukládat přístup do systému, tj. jaký uživatel se přihlásil, z jaké IP adresy a datum přístupu. 4) Správa článků Pomocí modulu správa článku, bude moct administrátor s příslušnými právy vkládat a upravovat články. Do těchto článků také půjdou vkládat obrázky, nebo připojovat celé fotogalerie. Administrátor s rolí Writer, bude moct psát články, editovat a mazat svoje články. Administrátor s rolí Redactor bude moct článek přečíst, opravit chyby a označit jako schválený. Pokud bude článek označen jako schválený, nepůjde již editovat Writerem ani jím mazat. Výčet možností modulu článků: • • •
Přidání, editace a mazání článků Zobrazení existujících článků Schvalování článku (je vyžadováno právo redaktora)
34 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k •
Připojení fotogalerií
Pro tento modul si opět namodelujeme diagram použití, aby bylo zřetelné, kteří uživatelé mají jaká práva.
Obrázek 11 - Případy užití modulu Články
K diagramu doplním jen to, že Writer má stejná práva jako Redactor, pokud je článek ve stavu konceptu. To znamená, že může být kýmkoli upravován. Pokud ho Redactor označí jako schválený, je článek zveřejněn a již pro něj Writer ztrácí veškerá práva. Tyto scénáře použití zobrazím dalším diagramem, kterým se přesně popíše scénář úpravy a schvalování článků.
| 35
Obrázek 12 - Diagram aktivit modulu Články
Při vytvoření článku, se vyplní všechny potřebné údaje o článku, vyplní se text a vloží se potřebné obrázky. Po kontrole duplicit URL adresy se článek uloží jako koncept. Postup při editaci a schvalování článku je stejný. Nejdříve se článek otevře pro editaci, aby měl autor článku, nebo redaktor možnost článek projít a zkontrolovat. Pokud uživatel není autorem článku, nebo redaktor, není mu přístup umožněn. Pokud má uživatel dostatečná práva, může článek uložit jako schválený, čímž se zveřejní a uloží jako zveřejněný. Článek již pak může editovat pouze redaktor, anebo hlavní administrátor. Při mazání se opět kontrolují dostatečná práva. Pokud je článek jako koncept, může ho smazat buď autor, redaktor nebo administrátor. Pokud je článek již schválený, může ho smazat pouze redaktor, nebo administrátor. Pro každý článek budeme potřebovat ukládat tyto údaje: • • • • •
Název článku – položka title Unikátní URL adresu – položka url Autor a datum a vytvoření – položky author a date Status článku, jestli je koncept, nebo schválený – položka status Vlastní text článku – položka text
36 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k Teď když mám všechno potřebné sepsané, můžu vymodelovat konceptuální třídu pro modul Články.
Obrázek 13 - Konceptuální třída modulu Články
Připojování fotogalerií k článkům se bude řešit až přímo v třídě pro fotogalerií, na kterou se podívám v následující kapitole. 5) Správa fotogalerií Správa fotogalerií nám pomůže s vytvářením fotogalerií, do kterých budeme nahrávat fotografie, které se budou automaticky upravovat pro zobrazení na webových stránkách. Bude se ukládat miniatura fotografie a velká fotka. Obě fotky budou mít ale stejné jméno souboru, jen budou uloženy v jiném adresáři, proto stačí pro jméno fotky udržovat pouze jeden název souboru. V tomto modulu systému je vyžadováno: • • • • •
Zobrazení existujících fotogalerií Přidání, editace a mazání fotogalerií Přidání, editace, změna pořadí a mazání jednotlivých fotografií Zvolení jedné fotografie jako úvodní fotky, neboli „fotka alba“ Připojení fotogalerie k článku, nebo kategorii
Opět bude nejlepší, když si vytvoříme diagram užití.
Obrázek 14 - Případy užití modulu Fotogalerie
| 37 Z diagramu je patrné, že přikládání fotogalerií k článkům má na starosti pouze redaktor, nebo hlavní administrátor. Je to myšleno tak, jako že autor článku napíše článek, uloží článek do systému a o víc se nestará. Redaktor článek zkontroluje, vyžádá si od fotografa fotogalerií a vloží je do systému. Vloženou fotogalerií následně připojí k článku a celý článek schválí. Fotogalerie bude možno připojit i ke kategoriím stránek. Vzhledem k tomu, že vytváření a editaci kategorií stránek má na starosti buď redaktor, nebo administrátor, mohou připojit fotogalerií pouze oni. Všechny tyto činnosti opět namodelujeme diagramem aktivit.
Obrázek 15 - Diagramy aktivit modulu Fotogalerie
38 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k Průběh pro vkládání nové fotogalerií, pro editaci i pro přidávání fotek bude ten samý. Bude možnost přidání více fotek k dané fotogalerií. Fotogalerie půjde přiřadit k jednomu, nebo více článkům, nebo kategoriím. Každá fotografie vložená do fotogalerií bude mít i číslo pořadí, takže bude možnost měnit pořadí jednotlivých fotografií v galerii. Pro mazání fotogalerií je potřeba kontrolovat práva uživatele, který chce fotogalerií smazat a zároveň se nesmí zapomenou na odstranění fotografií ve fotogalerií a propojení přiřazení ke stránkám a článkům. I pro tento poslední modul stránek si vymodeluji třídy reprezentující uložení fotogalerií a fotografií v nich obsažených.
Obrázek 16 - Konceptuální třídy modulu Fotogalerie
Každá fotogalerií bude obsahovat titulek galerie – headings, její popis – description a nakonec unikátní URL adresu. Do fotogalerií se budou přiřazovat fotografie, které budou mít alternativní text, jméno souboru, které bude společné pro miniaturu i velkou fotku a nakonec číslo pořadí – order, které bude určovat pořadí fotek ve fotogalerii. 2.2.1. Konceptuální diagram tříd Pokud nyní dáme všechny třídy k sobě, můžeme si namodelovat kompletní konceptuální diagram tříd (Class Diagram), jak bude přibližně vypadat kompletní jádro systému. Pomocí tohoto modelu tříd jsem již schopen vygenerovat SQL kód pro vytvoření databáze, ale toto generování provedeme až při samotné implementaci systému.
Obrázek 17 - Celkový konceptuální diagram tříd
| 39
Z diagramu tříd je nyní vidět, jak se budou fotogalerie přiřazovat k článkům a kategoriím. Toto by mělo tvořit jádro systému, který je navíc obohacený o systém článků, které normálně v jádru systému nejsou přítomny. Tento diagram je nezávislý na platformě, tak zvaný Platform Independent Model a v kapitole Implementace bude ještě v případě potřeby programovacího jazyka, nebo databáze doplněn. 2.2.2. Ostatní moduly Toto samozřejmě není konečný výčet modulů, které můžeme v redakčním systému implementovat. Je to jenom výčet modulů, které bych chtěl v mém redakčním systému mít. Co se týče funkčnosti systému, je výběr takřka neomezený. Vzhledem k požadavku modularity celého systému, nebude do systému v budoucnosti problém doplnit například tyto moduly, nebo rozšíření stávajících modulů: • • • • • • •
Diskuze ke článkům (rozšíření modulu článků) Zasílání zpráv mezi uživateli (rozšíření modulu uživatelů) Anketa (vkládání anket s různým počtem odpovědí, nastavování aktivních anket) Správa bannerů (s možností výběru pozice banneru na stránce, priority zobrazení atp.) Správa faktur (s automatickým generováním faktury do PDF) Správa zákazníků neboli CRM (Content Relationship Management - nástroj pro správu zákazníků) Správa uživatelů, kteří se budou moct registrovat na stránkách a budou se moci na ně přihlašovat
40 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
| 41
3.
Návrh
Nyní když mám hotovou analýzu řešení, je na řadě vlastní implementace. Na mojí aplikaci mám určité požadavky a bude potřeba najít nejvhodnější řešení. Základním požadavkem je, že systém má být napsán plně objektově v jazyku PHP 5 a bude běžet pouze online a bude dostupný pouze přes webový prohlížeč. V následujících kapitolách vyberu nejvhodnější framework[7], pro zajištění základních funkcí systému, vhodný databázový systém pro uložení našich dat a také shrnu požadavky pro hostingové služby, které bude potřeba zajistit pro běh naší aplikace.
3.1.
Výběr programovacího jazyka
Ačkoli je programovací jazyk, který pro můj redakční systém použiji již zanesen v samotném zadání bakalářské práce, napíši zde pár odstavců, proč jsem si tento jazyk vybral a rozhodl se v něm webovou aplikaci napsat. Jednou z kladných vlastností jazyka PHP je to, že je velice snadno pochopitelný a naučitelný. Což je i nevýhodou, protože tak dovoluje psát aplikace každému s minimálními znalostmi. Pokud ovšem chceme psát aplikace na úrovni, čistě objektově, podpořené důkladnou analýzou, tak je to i v tomto jazyce možné. Vzhledem k rozšířenosti a toho, že je PHP volně dostupné, je tento jazyk nasazen prakticky na všech serverech hostingových společností ať už u těch, kteří svoje služby poskytují zdarma, tak i u těch placených. Toto byl z další důvodů výběru tohoto jazyka. Aktuální verze PHP je 5.3, což je verze, která již plně podporuje objektový přístup, jmenné prostory, anonymní funkce, late static binding, což jsou všechno věci známé spíše z modernějších a propracovanějších programovacích jazyků. K PHP existuje také mnoho volně stažitelného software, ať už se jedná o vývojová prostředí, přes nespočet knihoven a frameworků.
3.2.
Vývojové prostředí
V této kapitole bych chtěl sepsat seznam programů a prostředků dostupné pro platformu osobních počítačů, které mi bude při implementaci mého redakčního systému pomáhat. Co se týče implementační části mé práce, je to pouhé psaní zdrojového kódu. To by se dalo kompletně realizovat v tom nejjednodušším textovém editoru, který je dostupný pro všechny operační systémy již v základní výbavě. Pokud si ale práci chci usnadnit a zefektivnit, je vhodné použít programy k tomu určené. Vzhledem k omezeným finančním možnostem jsem vždy vybral volně dostupný software a nebo využil zkušebních verzí jinak placených produktů. 3.2.1. Základní analýza Analýzu zadání a sepsání požadavků jsem celou prováděl v programu Enterprise Architect 7.5 pro kterou nám škola poskytla akademickou licenci a tímto jí děkuji. Tento nástroj umí vytvářet UML diagramy, pomocí kterých se dá aplikace namodelovat a částečně i vygenerovat zdrojové kódy našeho vybraného programovacího jazyka. Ostatní analýzu a textový soupis jsem prováděl v aplikaci Microsoft Word.
42 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k 3.2.2. Tvorba grafického vzhledu Grafický vzhled jsem si nejdříve připravil na papír a na tvorbu wireframů použil zkušební verzi nástroje Adobe Fireworks. Pro finální navrhnutí grafiky jsem použil zkušební verzi produktu Adobe Photoshop. Pro navržení a sepsání základní šablony aplikace v jazyku HTML a zápis stylu CSS sem použil volně stažitelný program PSPad od českého tvůrce. 3.2.3. Programování aplikace Vzhledem k tomu, že programování bude probíhat v jazyce PHP, není potřeba žádný překladač na počítači, kde se bude zdrojový kód psát. Kompletní překlad probíhá až na serveru, kde bude webová aplikace běžet. Na zápis zdrojového kódu by nám postačil pouhý textový editor. Já však použiji přímo vývojové prostředí, které bude mít pro můj vývoj několik výhod, které vyjmenuji. Vývojových prostředí neboli IDE, což je zkratka pro Integrated Development Environment, neboli v překladu integrované prostředí pro vývoj existují pro jazyk několik. Pokud vybereme pouze volně stažitelné a ty nejvíce používané, zbudou mi dvě IDE a to Eclipse a NetBeans. Asi nemá cenu rozepisovat pro a proti jednotlivých prostředí, oboje jsou velice vyspělá a pro náš účel postačí jakékoliv z nich. Já jsem si vybral Eclipse, protože za dobu vývoje jiných systému mi přišlo, že pro toto prostředí existuje daleko více doplňků, například podpora šablon Smarty, nebo PHPUnit knihovny pro unit testování. 3.2.4. Vývoj na lokálním počítači Pokud nechceme každou změnu ve zdrojovém kódu nahrávat na vzdálený server, na který je nasměrována doména a běží na něm webový server, bylo by vhodné mít takový server nainstalován na vlastním počítači a webovou aplikaci spouštět lokálně. Na to potřebujeme mít nainstalovaný webový server Apache, databázový systém MySql a programovací jazyk PHP. Buď si můžeme tyto tři věci nainstalovat samostatně, pak musíme počítat s tím, že každou s částí musíme nakonfigurovat anebo můžeme stáhnout balík aplikací s názvem XAMPP, který obsahuje všechny výše zmíněné programy, dokáže vše nainstalovat a i nastavit. Tímto si na lokálním počítači vytvořím složku, například c:/www/ kam budu ukládat mojí vyvíjenou webovou aplikaci a přímo přes webový prohlížeč zadáním http://localhost/aplikace/ mohu aplikaci spustit a testovat. Dále budeme potřebovat mít nainstalovaný program PhpMyAdmin, který se umí připojit na databázi běžící na lokálním počítači a zobrazit v grafické podobě data v ní uložená. Umí také vykonávat SQL dotazy a s daty pracovat. Toto se mi bude velice hodit při vývoji, ať už na začátku, při vytváření databáze, tak i dále pro modifikaci a kontrolu uložených dat. 3.2.5. Přenos souborů Abychom mohli zdrojové kódy nějak na server přenést, potřebujeme nějaký nástroj, který tato data přenese. Na většině webových serverů je v základu nainstalován nějaký FTP démon. To je program, který umí komunikovat s FTP klientem pomocí protokolu FTP, který slouží k přenosu souborů. Proto nám bude stačit, když si na lokální počítač nainstalujeme nějakého FTP klienta. Já si vyberu samozřejmě volně stažitelného klienta Mozilla FileZilla, který je od společnosti Mozilla, známého výrobce například webového prohlížeče Mozilla Firefox, nebo poštovního klienta Mozilla Thunderbird.
| 43 3.2.6. Verzování aplikace Pokud chceme mít data v bezpečí, tím že budou redundantně uložena na jiném počítači a chceme mít zároveň možnost vrátit se k jiné verzi zdrojového kódu, je velice výhodné používat nějaký nástroj pro verzování obsahu. Těchto systémů existuje několik, z nich nejpoužívanější je Subversion a Git. Já jsem si vybral Subversion, protože s ním mám dlouholetou zkušenost a je možnost využít volně dostupných privátních repozitářů na internetu. Využiji proto služeb na stránkách www.projectlocker.com, kteří umožňují uložení privátního repozitáře na jejich serverech. Moje data tak budou uloženy na jejich serveru, takže to bude sloužit za prvé jako záloha a dále budu mít přístup ke starším verzím zdrojového kódu. Takto budu verzovat jak samotnou aplikaci, tak i textové soubory vlastní bakalářské práce. Pro přenos souborů na vzdálený server budu používat klienta TortoiseSVN, který se umí připojit k vzdálenému repozitáři a data tam přenést, nebo naopak je stáhnout. Tímto budu zároveň udržovat aktuální data mezi stolním počítačem a notebookem. 3.2.7. Unit testování Abychom si zajistili, že každá samostatná součást systému bude funkční a bez chyb, budu ke každé třídě a ke každé funkci psát tzv. Unit Testy. Toto jsou speciální soubory, které obsahují příkazy přímo napsané na testovanou třídu a testují, jestli třída vrací správné výstupy na testovací vstupy. Tímto si budu udržovat webovou aplikaci bez chyb a budu mít jistotu, že jakákoli změna jedné funkcionality, nebude mít vliv na ostatní části systému. Pro Unit testování budu využívat třídu PHPUnit, která je dostupná buď jako samostatná třída anebo jako doplněk do vývojového prostředí Eclipse. Výhoda doplňku do Eclipse je ta, že vývojové prostředí umí automaticky tyto testy dávkově spouštět a umožňuje i grafické zobrazení chybových hlášek s propojením přímo na zdrojový kód.
3.3.
Grafika administrace
Teď když již víme, jaké moduly budeme chtít implementovat, jak se budou chovat a co budou umět, můžeme navrhnout grafickou podobu administrace. Musíme samozřejmě počítat s tím, že je možnost v našem redakčním systému přidávat a ubírat jednotlivé moduly, takže by to nemělo být limitující. Například nemůže se stát, že pokud přidáme 5 nových modulů, tak se již nevejdou do menu. 3.3.1. Rozvržení stránek Vzhledem k tomu, že redakční systém budu využívat také pro svou vlastní potřebu a nějaké systémy znám, pokusím se navrhnout rozložení stránek, tak aby to bylo ideální pro komfortní práci a žádná sekce stránek nebyla omezující pro zobrazení obsah jednotlivých kategorií. Zde uvedu několik hlavních klíčových vlastností grafického rozložení administrace: •
•
Plná šířka zobrazení. Administrace bude zobrazena přes celou viditelnou plochu webového prohlížeče. Nebudeme tak omezeni pro zobrazení širokých tabulek s více položkami. Menu umístěno vlevo. Takto umístěné menu, nám nebude zabírat místo na horní části stránek a budeme tak mít možnost zobrazit opravdu dlouhé tabulky (například seznam článků). Navíc většina dnešních monitorů je širokoúhlých, takže nás nebude menu vlevo omezovat.
44 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k •
•
•
Kontrastní barvy. Celý systém bude navržen v odstínech šedé, s tím, že akční prvky, jako jsou tlačítka nebo odkazy by měli mít zářivou kontrastní barvu, nejlépe odstín oranžové, nebo světle modré. To by mělo pomoct tomu, aby byl systém přehlednější a uživatel hned věděl, kam má kliknout. Plovoucí šířky. Zobrazené tabulky a formuláře nebudou mít pevnou šířku, takže se budou zobrazovat na plné šířce obrazovky. Takto nebude záležet, jestli má uživatel malý monitor, webovou stránku zobrazenou v okně, nebo monitor s velkou úhlopříčkou. Výstražné barvy a ikony. Pro zobrazení chybových hlášek a informací o úspěšném či neúspěšném uložení dat budu používat výstražné barvy s patřičnými ikonami.
3.3.2. Hlavní menu Hlavní moduly, které do našeho systému implementujeme, nám zároveň pomůžou při sestavení hlavního menu administrace: • • • • •
Správa kategorií – v menu označeno jako „Kategorie“ Správa článků – v menu označeno jako „Články“ Správa fotogalerií – v menu označeno jako „Fotogalerie“ Správa administrátorů – v menu označeno jako „Administrátoři“ Nápověda – bude směřovat na stránku, kde budou informace o podpoře, telefonní čísla a důležité odkazy
3.3.3. Prototyp návrhu Pokud již znám požadavky na grafický vzhled, je potřeba udělat prototyp návrhu pomocí wireframe. Wireframe je návrh rozvržení webových stránek pomocí jednoduchých grafických tvarů, například čar, nebo obdélníků. Tyto wireframe se tvoří proto, aby bylo vidět rozvržení stránky ještě před vlastní tvorbou grafického vzhledu, která bývá podstatně nákladnější než tvorba prototypu. Prototyp lze také využít jako předloha k tvorbě grafického vzhledu, nebo například pro generování HTML a CSS souborů. Tento prototyp si navrhnu v nástroji Adobe® Fireworks®, který je přímo navržen pro prototypování a návrh webových stránkek. Využiji volně stažitelnou 30ti denní zkušební verzi tohoto produktu, v kterém nakreslím prototyp vzhledu redakčního systému.
| 45
Obrázek 18 - Prototyp návrhu grafického rozhraní
Jak je z prototypu vidět, je to opravdu velice jednoduchý návrh, který mi akorát popisuje, kde se budou nacházet ovládací prvky a kde hlavní obsahová část. Tento wireframe použiji v následujícím odstavci pro návrh grafického návrhu. 3.3.4. Grafický návrh Grafický návrh udělám ve zkušební verzi programu Adobe® Photoshop® CS4 Extended, který jee volně ke stažení na internetových stránkách Adobe. Jedná se o grafický program, program a ačkoli má firma Adobe ve svém portfoliu program Fireworks, který je přímo určen k vytváření webové grafiky, lze použít i Photoshop. Kreslení zde probíhá v takzvaných vrstvách ch a pro každou vrstvu lze definovat různý styl, nebo efekt. Grafický vzhled si navrhnu, dle výše sepsaných požadavků, nicméně je důležité dodržovat několik doporučení, které se týkají přístupného webu, tak aby nám vzniknulo použitelné uživatelské rozhraní,, které bude přehledné a čitelné. Tyto pravidla jsou volně dostupná na stránce www.pravidla-pristupnosti.cz pristupnosti.cz[2] a jsou dle zákona na povinná pro webové stránky státní správy. Některé důležité body vypíšu v následujícím edujícím seznamu a při grafickém návrhu je budu respektovat: •
•
„Informace sdělované barvou musí být dostupné i bez barevného rozlišení.“ Což pro mě znamená, že cokoliv budu chtít odlišovat barevně, musí mít stejný význam i kdyby byla webové stránka zobrazená černobíle. „Barvy popředí a pozadí textu musí být vůči sobě dostatečně kontrastní. Toto ovšem neplatí pro dekorativní text a text bez informačního významu.“ V našem redakčním systému bude pouze text informačního významu, takže se budu snažit v obsahové části
46 | S y s t é m p r o t v o r b u i n t e r n e t o v ý c h s t r á n e k
•
•
používat černý text, na bílém pozadí. Kombinace těchto dvou barev má maximální kontrast. „Navigace musí být srozumitelná a konzistentní na všech webových podstránkách. Od ostatního obsahu musí být zřetelně oddělena.“ To pro mě znamená, že na všech stránkách nkách se musí menu nacházet na stejném místě a mít stejný obsah. „Každá webová stránka musí mít výstižný název odpovídající jejímu obsahu.“
Pravidla přístupnosti mají samozřejmě daleko více pravidel, ale grafické vzhledu se týkají pouze tyto čtyři. Ostatními mi pravidly se budu řídit až při převodu grafického vzhledu do zdrojového kódu. Výsledný grafický vzhled zobrazím na následujícím obrázku.
Obrázek 19 - Grafický návrh uživatelského rozhraní
Grafický návrh není pevný, plno věcí co co se týče vzhledu lze dodatečně upravovat přímo ve zdrojovém kódu, nicméně je dobré mít takový návrh připraven, abychom abychom měli určitě pevné vodítko. 3.3.5. Kódování šablony Když máme grafický návrh hotový, je potřeba ho převést do zdrojového kódu. Pro zápis šablonyy budu používat značkovací jazyk HTML a pro zápis stylu zobrazení budu využívat jazyk CSS pro zápis stylu HTML prvků.. Oba tyto jazyky jsou nejčastěji používanými jazyky pro tvorbu šablon webových stránek a systémů. Prvním krokem při převodu do zdrojového kódu je vytvoření HTML šablony. Tuto šablonu vytvořím validně dle platných pravidel s ohledem na sémantický význam značek. Při tvorbě HTML kódu stránek je opět jako při tvorbě grafiky důležité dbát na pravidla přístupnosti a
| 47 použitelnosti[2]. Nechci zde zdlouhavě popisovat, jak se pomocí HTML jazyka označkuje text a jaký tag, má který význam. Toto je sice pro moji aplikaci potřeba znát, ale místo toho zde vypíšu několik pravidel přístupného webu, pomocí kterých lze zdůraznit nejdůležitější věci, na které se při kódování šablon nesmí zapomenout. Pro tvorbu HTML kódu musíme dávat pozor především na tyto pravidla: •
•
•
•
•
•
• •
„Každý netextový prvek nesoucí významové sdělení musí mít svou textovou alternativu.“ Což znamená, že například každý obrázek, musí mít vyplněn parametr alt, který udává alternativní popis. „Obsah ani kód webové stránky nesmí předpokládat ani vyžadovat konkrétní výstupní či ovládací zařízení.“ Webová stránka musí být použitelná jak na 14“ malém monitoru, tak i na velikém. Musí být ovladatelná i pouze klávesnicí. „Rozsáhlé obsahové bloky musí být rozděleny do menších výstižně nadepsaných celků.“ Znamená to správné sémantické rozdělení textu do odstavců, které budou označeny příslušným HTML tagem
a
. „Každý formulářový prvek musí mít popisek vystihující požadovaný obsah.“ Ke každému HTML prvku input, což je vstupní políčko, musí náležet prvek label, který je popiskem pro tento prvek. Tyto dva prvky se propojí tím, že se u jednoho vyplní parametr for a u druhého parametr name. „Text odkazu nebo jeho přímo souvisejícího text musí výstižně popisovat cíl odkazu. Jestliže odkaz vede na jiný typ souboru, než je webová stránka, musí být odkaz doplněn sdělením o typu, případně velikosti tohoto souboru.“ „Sémantické značky, které jsou použity pro formátování obsahu, musí být použity ve zdrojovém kódu tak, aby odpovídaly významu obsahu.“ Toto je jedno z nejdůležitějších pravidel, které občas nebývá u webových stránek dodrženo. Každý HTML tag musí být použit tak, jak je určeno dle specifikace tohoto jazyka. Pro nadpisy se používají tagy
