VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor: Aplikovaná informatika
We b o v á p l a t f o r m a p ro k o o r d i n a c i v z á j e m n é spolupráce VŠPJ a Fachhochschule Te c h n i k u m Wi e n bakalářská práce
Autor: Kamil Havlíček Vedoucí práce: Ing. Zbyněk Bureš, Ph.D. Jihlava 2011
Abstrakt Bakalářská práce se zabývá návrhem webové platformy pro koordinaci vzájemné spolupráce mezi Vysokou školou polytechnickou Jihlava a Fachhochschule Technikum Wien. Na základě zmapování potřeb zadavatele je provedena datová a funkční analýza. V realizační praktické části bakalářské práce je implementován redakční systém a vybrané funkce systému. Součástí bakalářské práce je dokumentace zdrojového kódu webové aplikace a je popsán způsob, jak lze systém do budoucna jednoduše rozšířit o další součásti. Na tuto práci lze také nahlížet jako na případovou studii, která může být užitečná všem vývojářům, kteří se rozhodnou vyvíjet vlastní redakčního systému s podporou vícejazyčných verzí.
Klíčová slova redakční systém, vícejazyčné verze, PHP, MySQL, CMS, JavaScript
Abstract This bachelor thesis describes design of a web platform for coordination of cooperation between College of Polytechnics Jihlava and Fachhochschule Technikum Wien. On the basis of mapping submitter’s requirements, a data and functional analysis was carried out. In the implementation part of this bachelor thesis a content management system is designed. In this thesis there is also included documentation about the web application source code and description of extension possibility. The reader can view this work as a kind of a case study, which can be useful for every developer, who is determined to make their own multilingual content management system.
Keywords content management system, multilanguage website, PHP, MySQL, JavaScript
Poděkování Na tomto místě bych velmi rád poděkoval vedoucímu své bakalářské práce Ing. Zbyňku Burešovi, Ph.D. za pomoc a čas, který mi věnoval při konzultacích, i za jeho cenné rady.
Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu 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ů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutím licence. V Jihlavě dne 7.6.2011 ...................................................... Podpis
Obsah 1
Úvod .......................................................................................................................... 5
2
Popis zadání ............................................................................................................... 6
3
2.1
Popis projektu Elektronicko - biomedicínské kooperace ................................... 6
2.2
Analýza základních potřeb zadavatele ............................................................... 6
2.2.1
Pro koho je systém určen – popis uživatelů ................................................ 7
2.2.2
Rozdělení systému na sekce ....................................................................... 7
2.2.3
Systém na rezervaci laboratoří .................................................................... 8
2.2.4
Základní případy užití ................................................................................. 9
Návrh systému ......................................................................................................... 10 3.1
3.1.1
Požadavky kladené na redakční systém .................................................... 10
3.1.2
CMS třetích stran - Wordpress, Joomla, Drupal a jiné ............................. 12
3.1.3
Výhody vlastního řešení (oproti řešení třetích stran)................................ 13
3.1.4
Rozhodnutí: vlastní redakční systém ........................................................ 13
3.2
4
Redakční systém (CMS) vlastní či cizí aplikace? ............................................ 10
Datová a funkční analýza ................................................................................. 14
3.2.1
Návrh databáze ......................................................................................... 14
3.2.2
Ukládání vícejazyčných dat ...................................................................... 16
3.2.3
Rozdělení uživatelů do skupin podle oprávnění ....................................... 17
Realizace.................................................................................................................. 19 4.1
Popis základní struktury webové aplikace ....................................................... 19
4.2
Znaková sada webu a databáze ........................................................................ 19
4.3
Vytvoření struktury databáze............................................................................ 20
4.4
Psaní kódu ........................................................................................................ 20
4.5
Tvorba webové části redakčního systému........................................................ 21
4.6
Tvorba šablony pro frontend ............................................................................ 22
4.7
Systémové proměnné ....................................................................................... 23
4.8
Realizace jazykových mutací v redakčním systému ........................................ 24
4.8.1
Rozlišení jazykových verzí ....................................................................... 24
4.8.2
Systém vícejazyčných verzí ...................................................................... 25
4.8.3
Obsahové stránky ...................................................................................... 26
4.8.4
Překlady pomocí systému slovníkových frází .......................................... 26
4.8.5
Automatické přesměrování podle požadovaného jazyku ......................... 27
4.9
Systém pro registraci a přihlášení uživatele ..................................................... 29
4.10 Možnost napojení vlastních skriptů do redakčního systému ............................ 31 4.11 Administrační část webu .................................................................................. 31
4.11.1
WYSIWYG editor textu ........................................................................... 32
4.12 Vizualizace harmonogramu projektu ............................................................... 32 4.13 Adresářová struktura ........................................................................................ 34 4.14 Testování funkčnosti webové aplikace ............................................................. 35
5
4.14.1
Uživatelské testování ................................................................................ 35
4.14.2
Automatizované testování pomocí různých nástrojů ................................ 35
4.14.3
Vytváření logů ........................................................................................... 36
Nástroje použité při vývoji ...................................................................................... 38 5.1
XAMPP ............................................................................................................ 38
5.2
PSPad ............................................................................................................... 39
5.3
Gvim ................................................................................................................. 39
5.4
phpMyAdmin ................................................................................................... 40
6
Závěr ........................................................................................................................ 41
7
Seznam použité literatury ........................................................................................ 43
8
Seznam obrázků....................................................................................................... 45
9
Seznam tabulek ........................................................................................................ 46
10 Seznam zkratek ........................................................................................................ 47 Příloha ............................................................................................................................. 48
1 Úvod V roce 2010 jsem absolvoval tříměsíční zahraniční praxi v Rakousku díky projektu Studentské Odborné Praxe, který organizuje Vysoká škola polytechnická Jihlava ve spolupráci s vídeňskou Fachhochschule Technikum Wien. Při výběru tématu své bakalářské práce jsem si proto zvolil téma "Webová platforma pro koordinaci vzájemné spolupráce Vysoké školy polytechnické Jihlava a Fachhochschule Technikum Wien." Toto téma je mi blízké mimo jiné proto, že bych se rád návrhem a tvorbou webových aplikací zabýval i při své další profesionální specializaci. Hlavním cílem mé bakalářské práce je především navrhnout webovou platformu, která bude plnit mnoho různých funkcí vycházejících z požadavků zadavatele. Stěžejním pilířem této práce bude provedení analýzy možných řešení za účelem dosažení potřebné funkcionality. Výstupem této práce bude navržení základního pilíře celé této webové platformy – bude navržen rozšiřitelný redakční systém s podporou vícejazyčných mutací. Při tvorbě návrhu jsem rozhodnut postupovat metodicky tak, že v každém důležitém kroku bude prozkoumáno více myslitelných variant (pokud to bude možné). Dalo by se říct, že návrh bude proveden formou prohledávání stavového prostoru možností s cílem najít v každém kroku nejoptimálnější variantu nejlépe splňující dané požadavky. Díky argumentům ospravedlňujícím zvolené varianty lze předpokládat, že výsledný návrh jako celek bude možné rovněž označit jako „optimální řešení“. Po provedení teoretického konceptuálního návrhu budu systematicky pokračovat dále k realizační části. V této praktické části bude podle návrhu vytvořeno jádro redakčního systému a budou také implementovány vybrané části webové platformy. Samotné jádro bakalářské práce bude založeno na dvou základních pilířích a tím je jak návrh, tak i realizace redakčního systému, který bude tvořit základ pro vybudování celé webové platformy. Ta bude od počátku navrhována s podporou možných úprav a rozšíření. Část práce pak bude tvořit dokumentaci řešení webové aplikace tak, aby bylo možné podle tohoto popisu co nejjednodušeji provádět zásahy a doprogramovávat různé doplňky. 5
2 Popis zadání 2.1 Popis projektu Elektronicko - biomedicínské kooperace Výzkumný projekt s názvem „Elektronicko - biomedicínská kooperace“ (zkratka ElBiK) je přeshraničním projektem Vysoké školy polytechnické Jihlava (VŠPJ) a Fachhochschule Technikum Wien (FHTW) v Rakousku. Tato spolupráce umožní vybudovat na VŠPJ nové specializované experimentální centrum pro snímání signálů a zapojit se do výzkumného projektu vídeňské vysoké školy v oblasti biomedicíny. Tento přeshraniční projekt „Elektronicko-biomedicínská kooperace“ otevírá VŠPJ cestu k vlastní výzkumné práci, k napojení na výzkumné aktivity vídeňské školy a i budoucímu rozvoji nových oborů na jihlavské vysoké škole. [9] Součástí tohoto projektu je vybudování webového portálu pro koordinaci spolupráce mezi VŠPJ a rakouskou FHTW. Návrh této platformy je předmětem právě této bakalářské práce.
2.2 Analýza základních potřeb zadavatele Analýza potřeb byla provedena na základě informací poskytnutých zadavatelem (vedoucí řešitelského teamu projektu ElBik) a to jak osobně při konzultacích, tak i pomocí emailové komunikace. Postupem času jsem získával čím dál tím více přesnější vizi celého problému. Získané informace jsem pak na základě svých zkušeností s tvorbou webu vyhodnotil a shrnul v podobě textového zápisu, který obsahuje základní popis zahrnující všechny hlavní požadavky zadavatele. Pro potřeby této bakalářské práce, jsem text upravil do podoby souvislého textu, což je v tomto případě srozumitelnější než výpis v jednotlivých bodech. Zde je tedy souhrn nejhlavnějších požadavků zadavatele: Webová platforma se bude z pohledu nepřihlášeného uživatele jevit jako statický informační web, který bude 6
poskytovat základní informace o projektu. Pro přihlášeného uživatele pak bude poskytovat mnohem více funkcí a to na základě práv, které bude mít tento uživatel přidělen. Díky tomu je možné se na webovou platformu dívat jako na aplikaci, která bude rozdělena do pomyslných zón podle oprávnění uživatelů. Webová platforma bude podporovat vícejazyčné verze (jazyk webu bude možné přepínat) a tomu musí být přizpůsobena i administrační sekce. Webová platforma by měla být od začátku navržena tak, aby bylo možné ji kdykoliv rozšířit a jednoduše upravovat.
2.2.1 Pro koho je systém určen – popis uživatelů Jak už bylo řečeno, web by se měl jevit odlišně různým uživatelům podle toho, jaká budou mít oprávnění. Pro základní představu byly definovány tyto typy uživatelů:
Nepřihlášený uživatel
Student
Lektor
Člen řešitelského teamu
Aby byl web do budoucna rozšiřitelný, je třeba počítat s tím, že se v budoucnu může vyskytnout potřeba přidat další typy uživatelů. S tímto požadavkem se musí při následném návrhu počítat – řešení uživatelských oprávnění by nemělo počítat s konečným množstvím různých druhů uživatelů, ale naopak by neměl být problém kdykoliv do systému zavést nový typ uživatele.
2.2.2 Rozdělení systému na sekce Webová platforma projektu El-BiK by měla sloužit jednak jako nástroj pro usnadnění komunikace mezi účastníky projektu, tak i jako informační kanál pro veřejnost. Za tímto účelem bude webová aplikace rozdělena do několika sekcí. Zde jsou pro představu zmíněny případné součásti webu:
Obsahové stránky – informační podstránky rozdělené do kategorií. Některé kategorie budou viditelné jen pro přihlášené uživatele.
7
Nabídka seminářů a workshopů
Diskusní fórum
SOP – systém na sjednávání zahraniční studentské odborné praxe
Studentské projekty
Systém na rezervaci laboratoří
Pro studenty
Vědecká úroveň
Remote access (vzdálený přístup) do laboratoří
Informace o projektu El-Bik
Obsah projektu (výchozí situace, cíle projektu, cílové skupiny, výstupy projektu)
Milníky projektu, harmonogram, stav řešení
Celkový přehled financování
Informace pro veřejnost (inzeráty, nabídka seminářů apod.)
Automatizovaný newsfeed (seznam důležitých novinek, které se udály na webu)
2.2.3 Systém na rezervaci laboratoří Tato část webu bude umožňovat oprávněným uživatelům zarezervování laboratoře pro měření. Rezervace bude možná jen ve chvíli, kdy bude dostatečně volná kapacita laboratoře. Tato část systému bude tedy obsahovat sekce:
Seznam možných úkolů pro měření
Detailní popis úkolu
Možnost rezervace
Bude tedy muset existovat databáze místností, kde bude zanesena jejich vytíženost. Do této databáze bude muset být zanesena například vytíženost kvůli běžné semestrální výuce. Tato část bude do systému přidána jako doplňující modul (plug-in), bude využívat hlavních rysů redakčního systému jako je například možnost poskytování práv. 8
2.2.4 Základní případy užití Pro znázornění je dobré použít tzv. „use-case diagramy“, které jsou součástí UML (Unified Modeling Language). UML slouží jako grafický jazyk pro vizuální návrh softwarových systémů. [8] Níže je možné vidět use-case diagram, který znázorňuje základní případ užití redakčního systému pro web Elbik.eu. V roli aktérů (uživatelů) jsou základní uvažované typy uživatelů. Rovněž jsou zmíněny pouze nejdůležitější funkce systému.
Obrázek 1 – Diagram základních případů užití pro redakční systém Elbik.eu
9
3 Návrh systému Při návrhu celé webové platformy budu postupovat metodou shora-dolů, tedy se budu nejprve zabývat problémem jako celkem a poté se budu snažit proniknout do hlubších detailů. Nejprve problém budu mapovat formou obecnější analýzy potřeb zadavatele a postupně se budu dostávat k řešení jednotlivých dílčích komponent.
3.1 Redakční systém (CMS) vlastní či cizí aplikace? CMS (Content Management System) neboli redakční systém je software pro správu dokumentů, nejčastěji webového obsahu. Nejčastěji je pod tímto pojmem myšlena aplikace běžící na webovém serveru, která umožňuje publikovat obsah na webu, editovat a vydávat články apod. V tomto projektu bude redakční systém tvořit jádro celé aplikace. Základním požadavkem pro výběr našeho redakčního systému je především snadná rozšiřitelnost (možnost přidat vlastní či již vytvořené moduly). Pro výběr redakčního systému je ale potřeba zvážit mnoho dalších aspektů a je třeba si rozmyslet, zda si rozhodnutím pro nějakou variantu zbytečně nezkomplikujeme cestu při vývoji celého webového projektu. To je důvod, proč je zde tento rozhodovací proces tak detailně rozebrán.
3.1.1 Požadavky kladené na redakční systém V této kapitole bych rád definoval požadavky kladené na redakční systém – ať už se jedná o obecné požadavky vyplývající z dnešních moderních trendů panujících na internetu, tak i speciální požadavky, které jsou potřebné pro náš konkrétní příklad (web Elbik.eu). Na redakční systém pro web Elbik.eu jsou kladeny tyto požadavky:
Snadná rozšiřitelnost – podpora pluginů čili zásuvných modulů. Redakční systém by měl být rozšiřitelný o moduly (vlastní či případně vytvořené třetí stranou). Je velmi důležité, aby přidaný doplněk nenarušoval správný chod jiných modulů či aplikace jakožto celku. Vytváření potřebných modulů by mělo 10
být usnadněno dostatečnou dokumentací celého redakčního systému.
Podpora jazykových mutací – dalším z hlavních požadavků na náš redakční systém je možnost publikovat jednoduše články ve více jazykových verzích (například anglicky, německy a česky).
Různá práva pro uživatele – uživatelé budou mít v rámci redakčního systému různá oprávnění. Systém udělování uživatelských oprávnění by měl počítat s faktem, že systém bude v budoucnu rozšiřován o nové funkce a tak bude čas od času zapotřebí přidat i různá další oprávnění. Navíc po nějaké době může být v systému zaregistrováno velké množství uživatelů, takže by systém měl umožňovat nastavení práv pro více uživatelů najednou, tak aby nebylo nutné přenastavovat práva jednotlivě pro každého uživatele zvlášť.
„Přátelská“ licence – redakční systém by měl mít takovou licenci, která umožňuje zdrojový kód měnit a rozšiřovat. Pokud bude tento požadavek splněn, bude možné redakční systém libovolně měnit a rozšiřovat podle případných potřeb zadavatele. V případě vývoje vlastního redakčního systému je tento problém elegantně vyřešen.
Stabilita do budoucna – systém by měl počítat s dynamicky se měnícím prostředím, které je zvlášť v oblasti internetových technologií velmi proměnlivé. Systém by neměl být „rozhozen“ následkem aktualizací systémových komponent (ať už se jedná o aktualizace součástí webového serveru, tak i aktualizace redakčního systému). Dále by měl být co nejvíce stabilní i vzhledem k rychlému vývoji webových prohlížečů. Avšak díky dodržování webových standardů a snahy o zachování validního zdrojového kódu by tento problém měl být minimalizován. Nicméně je potřeba, aby systém umožňoval rychlé „servisní“ zásahy tak, aby případné problémy způsobené modernizací technologií mohly být velmi rychle a efektivně odstraněny.
Uživatelská přívětivost a jednoduchá správa obsahu – redakční systém by neměl být příliš složitý a komplikovaný. Minimalizují se tím náklady na zaškolení pracovníků, kteří budou editovat obsah webu.
Optimalizace pro vyhledávače – redakční systém by měl být co nejlépe přístupný pro indexovací roboty vyhledávačů. Měl by umožňovat generování sitemapy webu (sitemap.xml) a také podporu „pěkných“ URL adres. 11
Pojmem „pěkné URL“ je označován způsob strukturování adres v rámci webu, při němž jsou adresy dobře čitelné člověkem, obsahují klíčová slova, nepoužívají zbytečné parametry, jsou v čase neměnné a splňují další podobná praktická pravidla. Název vychází z anglického pojmu „fancy URLs“ či „cool URIs“. O této problematice se lze dočíst více například v dokumentu [1].
3.1.2 CMS třetích stran - Wordpress, Joomla, Drupal a jiné Hotových
redakčních
systémů,
které
si
může
uživatel
stáhnout
v podobě
předpřipraveného instalačního balíčku a pak jej následně provozovat na vlastním hostingu je opravdu mnoho. V této části jsem vybral několik známých a populárních redakčních systémů, které se v oblasti českého internetu velmi hojně vyskytují. Jsou to například:
Wordpress – open source redakční publikační systém fungující na platformě PHP+MySQL. Díky jeho rozšířenosti a otevřenému kódu vyvstává riziko, že na tento systém budou cíleny útoky využívající zranitelná místa tohoto softwaru, proto je nutné systém aktualizovat [10]. Wordpress je velmi populární a má širokou uživatelskou základnu.
Joomla! – open-source redakční systém. Je postaven na technologiích PHP + MySQL. Jedná se o poměrně velmi rozšířený redakční systém. Vyznačuje se svou rozšiřitelností a jednoduchým používáním. [6]
Drupal – multiplatformní redakční systém napsaný v jazyce PHP s podporou databáze MySQL a PostgreSQL. Systém je možné rozšířit, existuje již více než 6000 různých modulů. [3]
phpRS – český redakční systém napsaný v jazyce PHP a založený na MySQL. Systém umožňuje podporu pluginů a přizpůsobení vzhledu. Jeho autorem je Jiří Lukáš.
United-Nuke – další český redakční systém, jehož autorem je Jiří Stavinoha. Je postaven na jazyku PHP a umožňuje použití různých databázových systémů (MySQL, PostgreSQL, MSSQL, a další)
Typo3 – open source CMS vydávaný pod licencí GNU General Public License. K tomuto redakčnímu systému existuje rozsáhlá knihovna různých rozšíření a pluginů.
12
3.1.3 Výhody vlastního řešení (oproti řešení třetích stran) Mezi výhody vlastního řešení redakčního systému patří především lepší možnost přizpůsobení potřebám pro náš konkrétní případ. Dalo by se říci, že systém je pak šitý na míru podle potřeb zadavatele a od začátku se dá aplikace stavět se zřetelem na různá speciální přání a požadavky. Naproti tomu řešení třetích stran jsou často realizovány pro široký a obecný okruh uživatelů a pokud jej chceme přizpůsobit našim potřebám, musíme ho pak upravit a s tím jsou často spojené různé komplikace. Výhody vlastního řešení v bodech:
Lepší možnosti variability.
Vývojář má projekt více pod kontrolou.
Z hlediska bezpečnosti je menší riziko napadení systému než při použití nějakého populárního CMS, na který jsou útoky často cíleny (například pokud nemá člověk redakční systém aktualizovaný).
Za předpokladu, že je zdrojový kód dobře zdokumentován, je možné bez obav zasáhnout i do "jádra" systému. U hotových redakčních systémů se úpravy často dají dělat jen pomocí doplňků (za předpokladu, že chceme zachovat možnost jádro aktualizovat na nové verze).
Vývojáři nemusí mít strach z nekompatibility při aktualizací přicházející ze strany vývojářů CMS, neboť si systém vytvářejí sami a nemusí se tak přizpůsobovat novým verzím jádra.
Lepší možnosti přizpůsobení z hlediska SEO (Optimalizace pro vyhledávače) – například lepší využití metod mod_rewrite, dynamicky generovaných titulků stránky apod. Pokud se například objeví chyba v kódu třetí strany, není lehké přijít s řešením, které by přežilo aktualizaci.
Robustnost cizího řešení se po čase může ukázat jako překážka pro rozšiřování z hlediska složitosti.
3.1.4 Rozhodnutí: vlastní redakční systém Z výše uvedených důvodů jsem se rozhodl pro vytvoření vlastního redakčního systému. Argumenty formulované v této kapitole dostatečně podporují rozhodnutí pro vytvoření vlastního redakčního systému.
13
3.2 Datová a funkční analýza 3.2.1 Návrh databáze Data budou ukládána do databázového systému MySQL, který společně s jazykem PHP a webovým serverem Apache tvoří celkem solidní triádu, které je možné svěřit takový zodpovědný úkol, jakým je pohánění redakčního systému. „MySQL je světově nejoblíbenější databáze s otevřeným zdrojovým kódem.“ [4] Pro tento systém jsem se rozhodl hlavně proto, jelikož s ním mám dobré zkušenosti, zvláště při používání ve spojení s jazykem PHP. Datový model vychází z požadavků, které musí splňovat redakční systém. Jedním z takových požadavků je umožnění publikace obsahu. Musí tedy existovat tabulka, která ponese informace o tom, co se zobrazí po zadání konkrétní URL ze strany klienta, jenž očekává příslušný obsah. Bude tedy existovat tabulka „pages“, která bude rozhodovat o tom, jaký obsah se zobrazí na základě příchozího požadavku v podobě adresy URL (dále také označuji slovem „permalink“). Dalším požadavkem na redakční systém je podpora uživatelských účtů s možností nastavovat uživatelům různá oprávnění. To obstarají tři speciální tabulky (users, users_groups, users_capabilities). Uživatelé (users) spadají do jedné či více uživatelských skupin (user groups), přičemž tyto skupiny mají přidělenou množinu uživatelských oprávnění (user capabilities). Bližšímu popisu tabulek obstarávající systém uživatelských účtů se věnuji v samostatné kapitole. Tabulka „pages“ ponese informace, které uživatelské skupiny z tabulky „users_groups“ budou mít možnost stránku editovat a číst. To bude jakési logické propojení mezi uživatelskými účty a stránkami. Uživatelská oprávnění však budou sloužit i ke zpřístupnění jiných funkcí. Navíc bude možné množinu možných uživatelských oprávnění libovolně rozšiřovat v případě potřeby (například při přidání nové funkce, která by měla být přístupná jen některým uživatelům). Důležitou tabulkou bude tabulka „dictionary“, která bude tvořit srdce překladového systému pro umožnění jazykových mutací. Obsah tabulky je pak využíván při generování slovníkových souborů. 14
Další
tabulky
v systému
budou
logovací
tabulky
(např.
„log_errors_404“,
„log_searchbox“, „log_login“ apod.), do nichž se budou zaznamenávat různé události. Tyto tabulky budou většinou sloužit pouze k diagnostickým účelům a testování.
Obrázek 2 – Diagram vazeb mezi hlavními databázovými tabulkami
Je třeba zmínit, že vazby mezi tabulkami budou řešeny pomocí cizích klíčů. Pokud bude třeba, aby například uživatel spadal do více skupin zároveň, tak bude mít tento uživatel v tabulce
users
ve
sloupci
member_of_groups
textovou
hodnotu
„LECTOR|STUDENT|TRANSLATOR“, tedy více cizích klíčů zřetězených pomocí znaku „|“ (pipe). Takový řetězec se pak z pohledu programátora celkem pohodlně parsuje na jednotlivé části a zároveň je to celkem přehledné i v případě administrace přes nástroj phpMyAdmin. Podobný případ realizace vazby N:M je v případě tabulek „users_groups“ a „users_capabilities, uživatelské skupiny mají oprávnění vypsány 15
ve sloupci „capabilities“ v podobě řetězce, kde jsou stejným způsobem zřetězeny identifikátory oprávnění. Například: Capabilities=“ADMIN_ENTRY|ADMIN_MANAGE_PAGES|ADMIN_MANAGE_DICTIO NARY|ADMIN_MANAGE_USERS|ADMIN_MANAGE_HARMONOGRAM“
3.2.2 Ukládání vícejazyčných dat Jedním z požadavků na redakční systém je podpora vícejazyčných mutací. Je tedy potřeba navrhnout systém, jak ukládat do databáze textové řetězce ve více verzích (ve více překladech). Takový způsob ukládání hodnot by měl být jednotný pro celou aplikaci redakčního systému – ale i pro vytvářené doplňky. Pro ukládání vícejazyčných hodnot jsem zvolil takovouto strukturu vycházející z technologie XML: Obecný zápis:
hodnota_1 hodnota_2 …
hodnota_n Přičemž
hodnota_1
udává
překlad
v jazyce
udaném
identifikátorem
jazyku
(identifikátor_jazyku_1) v atributu lang, který náleží tagu
, jenž obaluje celý překlad. Takovéto překlady je pak možné řetězit za sebe. Konkrétně je možné vidět na příkladu: Project objectives Ziele des Projektes Cíle projektu Celou takovouto strukturu bude možné ukládat do databázového řetězcového pole (u MySQL tabulek se jedná o pole s nastaveným datovým typem „TEXT“). K notaci vycházející z XML jsem sáhnul z toho důvodu, že je možné během programování výhodně využít funkce pro práci s XML řetězci, které dnes bývají v základní výbavě 16
moderních skriptovacích jazyků (například funkce pro parsování XML struktur). Navíc je tento způsob zápisu na první pohled celkem přehledný a snadno pochopitelný. Pro účely dokumentace a psaní komentářů zdrojového kódu tento způsob ukládání překladů
označuji
i při pojmenování
názvem funkcí,
„multivalue“ které
s tímto
(z
tohoto
druhem
dat
označení zacházejí
pak
vycházím
–
například
funkce multivalue_to_array).
3.2.3 Rozdělení uživatelů do skupin podle oprávnění Z analýzy potřeb vyplývá, že bude nutné nějak systémově zajistit, aby uživatelé měli přidělena různá oprávnění. Podle těchto oprávnění budou mít uživatelé zpřístupněny (či naopak zablokovány) různé části a funkce webu. Například přihlášený akademický pracovník bude oprávněn editovat obsah webu, zatímco přihlášený student tuto možnost mít nebude. Uživatel, který nebude přihlášen vůbec, bude z tohoto hlediska považován za neprivilegovaného uživatele. Rozdělení uživatelů do skupin se tedy projeví tím, že pro každou skupinu uživatelů bude web poskytovat různé funkce (některé budou skryté). V případě, že je nějaká část webu pro uživatele zapovězená, není nutné na ni zobrazovat odkaz. Stejně tak se nebudou zbytečně zobrazovat odkazy na funkce, pokud nemá uživatel oprávnění je použít (například odkaz "Editovat obsah této stránky"). Rozhodl jsem se sáhnout k modelu, při kterém se práva udělují na úrovni uživatelských skupin a uživatel získává práva na základě členství v těchto skupinách. Odebrání práv celé skupině se pak projeví na všech jeho členech (konkrétních uživatelích) – všichni pak přijdou o právě odebrané oprávnění. Tento model přidělování uživatelských oprávnění je znám například z linuxových operačních systémů, kde se tento koncept velmi osvědčil. Systém jsem navrhnul tak, aby každý jednotlivý uživatel mohl být zařazen do více skupin najednou (a to do libovolného množství). Pokud je uživatel členem více skupin, pak získává práva (capabilities) všech těchto skupin, což představuje jakési sjednocení množin oprávnění ze všech skupin, jejíž je uživatel členem. 17
Pro implementaci tohoto modelu použiji 3 databázové tabulky:
users – tabulka uživatelů, uživatel je členem nějaké skupiny (z tabulky users_group)
users_groups – uživatelské skupiny, tyto skupiny mají ve sloupci capabilities seznam identifikátorů, které určují, jaké oprávnění budou mít členové skupiny.
users_capabilities – seznam možných oprávnění. Jedná se o seznam identifikátorů oprávnění a jejich popisu. Využívá se hlavně v administračním rozhraní, kde je pak možné z tohoto seznamu vybírat oprávnění při nastavování práv pro celou skupinu.
18
4 Realizace 4.1 Popis základní struktury webové aplikace Webová aplikace bude tvořena z webové části, kterou uvidí běžný návštěvník, a administrační části, do níž bude mít přístup jen k tomu oprávněný uživatel. Webová část bude uživatelům poskytovat různý obsah na základě jejich oprávnění.
Obrázek 3 – Koncept struktury redakčního systému
4.2 Znaková sada webu a databáze Jako znakovou sadu používanou pro uložení dat v databázi jsem zvolil kódování "utf8_general_ci", protože jsem chtěl zachovat možnost případně přidat v budoucnu nějakou další jazykovou mutaci a kódování UTF8 v tomto ohledu bezproblémově poskytuje široké možnosti (velká podpora různých znaků a symbolů). Při tvorbě skriptů komunikujících s databází je výhodné zachovat jednotnost kódování. (předejde se tím mnoha problémům, například s ukládáním českých diakritických znaků). Jedno a totéž kódování by mělo být zachováno v těchto bodech:
Kódová stránka XML (ve zdrojovém kódu HTML):
Meta tag v sekci HEAD (ve zdrojovém souboru HTML): <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
HTTP hlavička odpovědi by měla obsahovat stejné kódování v části Contenttype: 19
Content-Type: text/html; charset=UTF-8
Nastavení kódové stránky pro komunikaci s MySQL: @mysql_query ('SET NAMES UTF8')
Databázové tabulky by měly mít nastaveno stejné kódování porovnávání. Týká se to jak celých tabulek, tak i jednotlivých textových sloupců.
Při
práci
s databázovými
administračními
nástroji
jako
je
například
phpMyAdmin by se mělo pracovat rovněž v režimu se stejnou kódovou stránkou, aby se při editaci nepoškodila uložená data.
Zdrojové kódy PHP skriptů by měly být ukládány také ve stejném kódování.
4.3 Vytvoření struktury databáze Na základě návrhu jsem vytvořil několik databázových tabulek v databázovém systému MySQL. Tyto tabulky se budou starat o uchování informací zadávané uživateli redakčního systému. Popisu těchto tabulek se věnuji v návrhové části této bakalářské práce.
4.4 Psaní kódu K tvorbě samotného zdrojového kódu v jazyce PHP je možné použít jakýkoliv editor čistého textu (plain text editor). V tomto případě jsem používal PSPad a Gvim. Při tvorbě zdrojového kódu jsem měl na paměti, že musí být snadno pochopitelný a editovatelný pro jiné programátory, kteří budou aplikaci v budoucnu upravovat a rozšiřovat o další funkce. Takový přístup by však měl být samozřejmostí pro každého slušného programátora. Jelikož nebylo možné dopředu vyloučit, že se vzniklým zdrojovým kódem bude v budoucnu pracovat i člověk, který nezná český jazyk – rozhodl jsem se používat názvy funkcí a proměnných v anglickém jazyce. V angličtině jsou psané i případné komentáře.
20
Struktura kódu je rozčleněna tak, aby v budoucnu nevznikaly zbytečné komplikace v případě, že bude nutné do aplikace doplnit nové funkce. Je tedy kladen velký důraz na rozšiřitelnost aplikace.
4.5 Tvorba webové části redakčního systému Jelikož díky vypracovanému návrhu víme, jakou podobu budou mít data v databázi, můžeme vytvořit v tabulkách testovací řádky. Potom nám nic nebrání začít s tvorbou frontendové části – tedy té, která se bude zobrazovat veřejnosti a bude zobrazovat data načítané z databáze. Obsah poskytovaný webovým serverem se vygeneruje na základě požadované URL adresy. Je tedy nutné si nejprve „na vstupu“ přečíst požadovanou URL adresu – tu máme v PHP zpřístupněnou v proměnné
$_SERVER['REQUEST_URI']. Tuto
proměnnou rozparsujeme a poté zjistíme, jestli k požadované adrese máme v databázi přiřazen nějaký obsah. Pokud adresu neznáme, upozorníme na to klientskou stranu pomocí chybové hlášky a vrácené HTTP hlavičky se stavovým kódem 404, který indikuje chybu „Not Found“ (stránka nebyla na serveru nalezena). Pokud však k požadované adrese nalezneme v tabulce pages potřebný řádek, znamená to, že klient žádá správnou adresu a můžeme mu pro ni vygenerovat stránku s potřebným obsahem. V tabulce pages rozlišujeme dva typy stránek podle hodnoty nastavené ve sloupci „type“:
Pokud je hodnota nastavena na řetězec „NORMAL“ – jedná se o stránku čistě staticky obsahovou a data se načítají přímo z ostatních sloupců této tabulky (title, h1, content). Tato načtená data nastaví potřebné systémové proměnné, které jsou pak zpracovány při zobrazení na frontendu.
Hodnota „INCLUDE“ značí že, obsah stránky bude generován inkludovaným PHP skriptem. Tato volba rozšiřuje schopnosti redakčního systému o možnost načtení nějakého dalšího externího modulu v podobě PHP skriptu. Adresa pro inkluzi takového skriptu je určena obsahem sloupce content. Tento skript nastavuje globální systémové proměnné a ovlivňuje tak podobu výsledné stránky. 21
Ve chvíli, kdy máme nastavené proměnné $engine_title, $engine_content, $engine_h1 a další, tak přijde na řadu inkluze šablony, která udává vizuální podobu frontendu. V této šabloně jsou definována místa, kam se přesně vloží obsah těchto proměnných. Díky tomu se na výstup vygeneruje stránka s požadovaným obsahem. Systémové proměnné popisuji v samostatné kapitole, neboť tvoří velmi důležitou součást redakčního systému. Tyto proměnné se nachází v globálním jmenném prostoru hlavního PHP skriptu a mohou být využity například v modulech, které jsou do redakčního systému inkludovány.
4.6 Tvorba šablony pro frontend Podoba webu je určená její grafickou šablonou. Tato šablona je nakódována v souboru „/content/_template.php“ a s pomocí CSS souboru určuje, jak bude výsledný web vypadat. Díky této šabloně lze modifikovat rozvržení stránky (grafický layout). Tato šablona je ve skutečnosti PHP skript, takže je možné v ní používat funkce jazyka PHP (hlavně pro doladění některých funkcí frontendu).
Obrázek 4 – Grafická šablona určuje podobu webu
22
4.7 Systémové proměnné Následuje popis systémových proměnných, které jsou používány ve webové části. Tyto proměnné se nachází v globálním jmenném prostoru a mohou být využity například při tvorbě externího skriptu, který bude případně inkludován jako modul. Prefix „engine_“ značí, že jde o systémovou proměnnou. Systémové proměnné poskytují rozhraní, kterým mohou externí skripty ovlivňovat frontem a mohou tak od jádra redakčního systému získávat informace o zpracování hlavního skriptu. Tabulka 1 – Popis systémových proměnných
Název proměnné
Popis proměnné
$engine_url_array
Pole obsahující rozparsovanou URL adresu pocházející z proměnné $_SERVER['REQUEST_URI']. Jedná se o pole řetězců. Je- li například požadována adresa http://elbik.eu/retezec1/retezec2/retezec3/ bude pak v proměnné $engine_url_array[1] uložena hodnota „retezec1“. V případě, že je v proměnné $engine_url_array[1] uložen identifikátor jazykové mutace, posune se obsah pole tak, aby byl tento identifikátor nahrazen další položkou. Identifikátor jazykové mutace je uložen do proměnné $engine_lang.
$engine_title
Jedná se o řetězcovou proměnnou, která nastavuje titulek výsledné stránky (na výstup je ve frontendové šabloně vypsána pomocí funkce "echo"). V případě potřeby je možné pomocí inkludovaného modulu titulek měnit za chodu, což umožňuje lepší optimalizaci pro vyhledávače.
$engine_lang
Tato proměnná určuje v jakém jazyce je stránka vypsána.
$engine_languages
Pole obsahující seznam podporovaných jazyků. Obsahem pole jsou jazykové identifikátory ("cs", "en", "de" a podobně). Toto pole je načítáno ze souboru /config/languages.php
$engine_language_default
Nastavuje výchozí jazykovou verzi.
$engine_error
Textová proměnná. V případě odchycené závažné chyby frontendu je do této proměnné uložen identifikátor chyby. Díky tomu se na výstupu objeví chybová hláška. Za závažnou chybu je například považována situace, kdy se nedaří navázat spojení s 23
databází. Proměnná sloužící jako "handle" pro navázané spojení s databází MySQL.
$engine_db_connection
$engine_translated_permalinks Asociativní pole obsahující permalinky pro všechny dostupné jazykové mutace aktuálně vybrané stránky. Pokud jsme například na stránce "/cile-projektu/", bude odkaz na anglickou variantu stránky "/projectobjectives/" a na německou mutaci "/ziele-desprojektes/". Toto pole používá jako index identifikátory jazyka (cs, en, de apod.) Pole obsahující přeložené slovníkové fráze.
$engine_dictionary
$engine_content_available_lang Pokud je žádána jazyková mutace stránky, která není uages přeložená – naplní se toto pole identifikátory jazyků, ve kterých je stránka dostupná. To se poté využije při vypisování chybové hlášky odkazující na dostupné jazykové mutace. ID aktuálně načtené stránky
$engine_page_id
4.8 Realizace jazykových mutací v redakčním systému Jedním z požadavků na redakční systém pro tento projekt byla možnost podpory jazykových mutací.
4.8.1 Rozlišení jazykových verzí Jak pozná server, že uživatel vyžaduje stránku v určitém jazyce? Z požadavku klienta server získá tzv. požadované URL. Rozhodl jsem se tedy do struktury systému adresování webu zanést informaci o jazykové verzi webu.
http://elbik.eu/project-objectives/ – anglická verze nebude mít v adrese přímo za doménou nic, neboť je angličtina nastavena jako výchozí verze redakčního systému
http://elbik.eu/de/ziele-des-projektes/ – německá verze webu je určena jazykovým identifikátorem „de“
http://elbik.eu/cs/cile-projektu/ – česká jazyková verze je určena jazykovým identifikátorem „cs“
Jazykové verze webu
bude možné přepínat
–
k tomu pomáhá
proměnná
$engine_translated_permalink, která obsahuje pole s permalinky na ostatní dostupné 24
jazykové verze konkrétní aktuálně načtené podstránky.
4.8.2 Systém vícejazyčných verzí Jak jsem již zmínil v kapitole týkající se návrhu ukládání dat pro vícejazyčné hodnoty, budou data nesoucí hodnoty ve vícejazyčných verzích ukládány v podobě jakési XML struktury. Například: Project objectives Ziele des Projektes Cíle projektu
Takovouto strukturu označuji jako „multivalue“. V podobě multivalue jsou například ukládány texty pro obsahové stránky, titulky stránek, nadpisy, permalinky atd. Stejným způsobem jsou ukládány i hodnoty tzv. překladových frází pro použití na frontendu. Pro práci s těmito daty jsem navrhnul funkce, které je možné v kódu používat:
multivalue_extract($mutlivalue, $lang) – tato funkce vytáhne konkrétní překlad ze struktury multivalue. Jazyk požadovaného překladu je udán proměnnou $lang a celá prohledávaná struktura je do funkce předána parametrem $var. Funkce vrací vyextrahovaný řetězec v požadovaném překladu – tedy konkrétní překlad z celé struktury multivalue.
multivalue_to_array($mutlivalue) – funkce sloužící k převedení struktury multivalue Výsledné
na proměnnou obsahující asociativní pole obsahující překlady. navrácené
pole
má
jako
indexy
jazykové
identifikátory
(cs, en, de,...) a hodnotami pole jsou příslušné překlady. Takto například vypadá pole obsahující hodnoty použité z předchozího příkladu (zápis je v notaci PHP funkce var_dump(), jež je používána pro zobrazení obsahu proměnných): array(3) { ["cs"]=> string(13) "Stav projektu" ["en"]=> string(14) "Project status" ["de"]=> string(13) "Projektstatus" }
25
4.8.3 Obsahové stránky U stránek, které jsou přímo načítány z tabulky pages a tvoří statický obsah webu, systém funguje v praxi tak, že na vícejazyčné hodnoty načtené z této tabulky jsou aplikovány potřebné výše popsané funkce (především multivalue_extract) a tím se vyextrahují data pro aktuální jazykovou mutaci webu.
4.8.4 Překlady pomocí systému slovníkových frází Jak zajistit překlad u částí, které nebudou mít podobu statické stránky, ale bude to například registrační formulář či nějaký jiný skript? S tímto problémem jsem se vyrovnal tak, že jsem zavedl databázovou tabulku „dictionary“ a zavedl jsem systém tzv. slovníkových frází. Tabulka dictionary má tyto sloupce:
id – číslo, jednoznačný identifikátor slovníkové fráze
dictionary_group – skupina, do níž spadá slovníková fráze. Jedná se o textový řetězec definující název skupiny. Díky tomuto řetězci jsou pak slovníkové fráze rozděleny do skupin.
value – překlady slovníkové fráze ve formátu „multivalue“ (popsáno výše)
internal_note – interní poznámka, která nese doplňkové informace o slovníkové frázi (vysvětlení účelu slovníkové fráze). Pomáhá překladatelům pochopit, jak je fráze zamýšlena, na jaké stránce a v jakém kontextu je užita.
Slovníkové fráze však nejsou načítány přímo z databáze, což by ji zbytečně zatěžovalo, ale z vygenerovaných cache souborů. Díky rozdělení do skupin jsou vytvořeny slovníkové cache soubory obsahující slovník pro celou skupinu (podle sloupce $dictionary_group). Tyto soubory jsou vygenerovány do adresáře „/cache/dictionaries/“. Ve skriptech poté inkludujeme slovník pro danou skupinu a nenačítáme zbytečně všechny
slovníkové
fráze.
Název
slovníkového
souboru
má
podobu
„jazyk_skupina.php“, kde jazyk je identifikátor jazyku a skupina označuje název skupiny. Vygenerovaný PHP soubor pak obsahuje pole $engine_dictionary[], kde indexem pole jsou jednoznačná ID čísla pro konkrétní slovníkové fráze. 26
Slovníkové fráze je pak možné v kódu jednoduše použít za pomocí funkce obstarávající překlad. Funkci jsem nazval krátce „t()“, a to z důvodu ulehčení při psaní kódu. Funkce t($phrase_id, $alternative_text) má dva parametry - proměnná $phrase_id určuje číslo (identifikátor) slovníkové fráze, parametr $alternative_text určuje, jaká fráze se použije v případě, že nebude nalezena slovníková fráze s požadovaným $phrase_id (tento parametr je nepovinný). Ukázka na příkladu – úryvek PHP kódu: include 'cache/dictionaries/' . $engine_lang . '_test.php'; $r .= t(17); $engine_content = $r;
Vysvětlení úryvku: tento příklad načte slovník „test“ pro aktuálně požadovaný jazyk (podle URL adresy), do proměnné $r se zřetězí překlad slovníkové fráze s číslem 17. Proměnná $r se promítne na výstup frontendu, neboť právě tam se zobrazuje proměnná $engine_content. Tímto způsobem je tedy možné překládat vlastní inkludované skripty, stejně tak lze používat funkci t() i pro texty užité v šabloně (_template.php) – pro přeložení (v šabloně jsou takto překládány různé fráze jako například odkaz „přihlásit se / login / anmelden“). Slovníkové fráze je možné editovat v administračním rozhraní – v sekci „Dictionary“. Kdykoliv proběhne nějaká aktualizace, zavolá se skript mající na starosti přegenerování cache souborů se slovníky (tento skript se jmenuje cache_generator_dictionaries.php a je k nalezení v adresáři „/engine/admin/“).
4.8.5 Automatické přesměrování podle požadovaného jazyku Při realizaci jazykových mutací jsem řešil otázku, zda návštěvníka automaticky přesměrovávat na jinou jazykovou verzi například podle jazyku prohlížeče, v němž je stránka načtena či podle IP adresy návštěvníka. Další zvažitelnou možností je přesměrování na základě HTTP hlavičky „Accept-Language“, pomocí níž klient sděluje serveru podporované jazyky [7].
27
Automatické přesměrování může usnadnit orientaci uživatele, kterému se zobrazí web přímo v požadovaném jazyce. Omezí se tím riziko, že se návštěvník lekne a odejde, protože si například nevšimne možnosti přepnutí jazykové mutace. Celkem rozumnou alternativou k automatickému přesměrování je řešení, při kterém se zobrazí výrazný odkaz vyzývající k přepnutí jazyku (v případě, že se podle nějaké metody vyhodnotí, že uživatel nejspíše potřebuje přepnout na jinou jazykovou mutaci webu). Je třeba zvážit riziko, že mohou nastat případy, kdy automatické přesměrování na nejvhodnější jazykovou verzi může být pro návštěvníka matoucí. Například si lze představit českého uživatele používajícího prohlížeč v angličtině. Zároveň je potřeba myslet na skutečnost, že web kromě "živých" lidí navštěvují také indexovací roboti vyhledávačů – takže je potřeba zajistit, aby jim zvolené řešení zbytečně neblokovalo přístup. Po zvážení všech aspektů týkající se této problematiky jsem se rozhodl pro následující řešení:
Automatické přesměrování bude probíhat pouze na úvodní stránce. Pokud by totiž uživatel přišel na nějakou konkrétní podstránku, tak by přesměrování na jinou jazykovou verzi stránky mohlo být velmi matoucí (například pokud uživatel přichází z vyhledávače či pomocí odkazu na konkrétní URL).
Uživatel bude přesměrováván podle jazyku použitého internetového prohlížeče. Tedy podle vlastnosti „language“ javascriptového objektu „window.navigator“, který nese informaci o jazykové verzi prohlížeče. [2]
Uživatel
bude
přesměrováván
JavaScriptem,
nikoliv
pomocí
zaslání
HTTP hlavičky pro přesměrování klienta. Díky tomu nebude docházet ke zmatení indexovacích robotů vyhledávačů. Řešení pomocí JavaScriptu by nemělo mít negativní dopad z hlediska SEO.
Pokud uživatel ručně přepne jazykovou verzi kliknutím na odkaz pro změnu jazyka, tak se požadovaná jazyková varianta uloží do paměti pomocí technologie cookies. Pokud uživatel jednou nastaví používání nějaké jazykové varianty, 28
při příští návštěvě bude stránka opět ve stejné jazykové verzi, neboť dojde k přesměrování podle hodnoty uložené v cookies (cookie proměnná ponese název „lang“). Přesměrování je tedy řešeno tak, že po načtení webové stránky se zavolá JavaScriptová funkce language_redirect(), která má na starosti v případě potřeby přesměrovat stránku na jinou jazykovou verzi webu.
Obrázek 5 - Vývojový diagram javascriptové funkce language_redirect()
4.9 Systém pro registraci a přihlášení uživatele Registrační podstránka (stejně tak jako podstránka pro přihlášení) je do redakčního systému přidána v podobě inkludovaného skriptu. To je řešeno tak, že v tabulce pages je záznam nesoucí informaci že pod URL adresou „/registrace/“ (v české verzi) bude inludován skript na vnitřní cestě „/content/registration.php“ (inkluze je určena sloupcem type, který nese hodnotu „INCLUDE“ a cesta ke skriptu je uvedena ve sloupci „content“). 29
Uvnitř inkludovaného PHP skriptu umožňující registraci nového uživatele se vytvoří registrační formulář v podobě HTML kódu a ten se poté zobrazí na frontendu, jelikož vygenerovaný HTML kód je do šablony předán pomocí proměnné $engine_content. Obsah této proměnné je pak vypsán na určitém místě uvnitř šablony. U registrace uživatele je volána funkce na překlad – výše zmíněná funkce t(). Díky použití této funkce není nutné programovat více verzí skriptu pro různé jazykové mutace, neboť se použije technologie slovníků překladových frází, které se vypisují pomocí překladové funkce. Při registrování uživatele je nutné vyplnit políčko, které indikuje, do které skupiny bude uživatel spadat (lektor, student, člen řešitelského teamu, ostatní). V případě, že jsou správně vyplněny i ostatní části registračního formuláře, je uživatel přidán do databáze. Vyplněné heslo se do databáze uloží „zahashované“ pomocí hashovací funkce využívající metodu MD5, díky čemuž nebude heslo viditelné při administraci databáze. Pro přihlášení uživatele slouží jiný skript. Ten je k nalezení pod cestou „/content/login.php“ a načítá se pokud uživatel přejde na přihlašovací stránku (například po kliknutí na odkaz „login“). Tento inkludovaný skript má na starosti zajištění autentizace uživatele, poté co zadá přihlašovací údaje. Zadávané přihlašovací údaje si uživatel zvolil při registraci. Pokud proběhne verifikace těchto údajů v pořádku, dokončí se úspěšně proces přihlášení uživatele s použitím technologie $_SESSION proměnných. V těchto proměnných je uchována i informace o všech možných oprávněních (capabilities) uživatele – na základě jeho příslušnosti v uživatelské skupině. Pokud pak potřebuji ověřit zda uživatel má nějaké konkrétní oprávnění (například „ADMIN_MANAGE_PAGES“), použiji jednoduché ověření: if ($_SESSION['USER_CAPABILITIES']['ADMIN_MANAGE_PAGES'] == '1') { //uživatel má oprávnění "ADMIN_MANAGE_PAGES" //a můžeme mu na základě toho zpřístupnit konkrétní akci //... } else { //uživatel nemá oprávnění "ADMIN_MANAGE_PAGES" //... }
30
4.10 Možnost napojení vlastních skriptů do redakčního systému Vlastní skripty je možné napojit do redakčního systému podobným způsobem, jaký byl popsán u předchozí kapitoly o přihlašovací a registrační části webu. Je tedy nutné zajistit, aby v databázové tabulce „pages“ byl ve sloupci „type“ nastavena hodnota „INCLUDE“. Skript, jehož cesta je definovaná sloupcem „content“ je inkludován hned před jakýmkoliv výstupem. Je tedy potřeb zajistit, aby načtený skript neměl žádný vlastní výstup (funkce echo, HTML kód, mezery a odřádkování na začátku a konci inkludovaného PHP souboru). Tento skript ovlivňuje výstup pomocí systémových proměnných popsaných (ty jsou popsány v tabulce č. 1). Načtený vlastní plugin má přístup i k „session“ proměnným, takže může ovlivňovat svůj obsah na základě informací o přihlášeném uživateli.
4.11 Administrační část webu Administrační část redakčního systému bývá zpřístupněna vždy jen oprávněným uživatelům. Můžeme tedy navázat na výše zmíněný systém, kdy přihlášený uživatel má přidělenou „session“ proměnnou, která nese informaci o tom, jaká veškerá oprávnění mu byly přiděleny. Díky tomu můžeme do administrační sekce vpustit pouze k tomu pověřené osoby. Díky množině oprávnění můžeme personalizovat i administrační sekci. Různí uživatelé budou mít různé pravomoci v rámci administrační sekce. Ne každý uživatel s přístupem do administrace bude moci například spravovat překladové slovníky (to mohou pouze uživatelé s oprávněním „ADMIN_MANAGE_DICTIONARY“). Administrační část webu je od webové části částečně oddělena – její uživatelské rozhraní nevyužívá překladové funkce (je pouze v angličtině), jelikož nebyl kladen požadavek, aby administrační část byla vícejazyčná. Díky tomu je z vývojářského pohledu možné administrační část upravovat a rozšiřovat mnohem pohodlněji. Pro vstup do administrace je nutné mít
oprávnění
s identifikátorem
„ADMIN_ENTRY“.
Poté se uživateli zpřístupní další administrační funkce. 31
4.11.1
WYSIWYG editor textu
Obsah stránek je v databázi ukládán formou HTML kódu – ten nese informace o formátování a vizuální podobě obsahových stránek. Aby bylo umožněno text editovat pohodlně a bez nutnosti znalosti HTML značek, bylo potřeba použít vizuální editor, který umožňuje text editovat podobně jako se například edituje text v prostředí moderních textových editorů jakým je například Microsoft Word. Zkratka WYSIWYG vyhcází z anglického „What You See Is What You Get“, což doslova znamená „co vidíš, to dostaneš“, což přesně vystihuje princip takovýchto editorů. Použil jsem hotové řešení známé pod názvem TinyMCE, který je naprogramován v JavaScriptu a vydáván pod open source licencí, což je pro účely této bakalářské práce vhodné. Autorem TinyMCE je firma Moxiecode Systems AB. Editor TinyMCE jsem propojil s dalším externím pluginem, který umožňuje správu a uploadování obrázků na server – ten se nazývá KCFinder a je taktéž vydáván pod open source licencí. Autorem KCFinder je Pavel Tzonkov.
Obrázek 6 – Vizuální editor TinyMCE
4.12 Vizualizace harmonogramu projektu Celý projekt Elbik má ze své podstaty dopředu jasně definovaný časový harmonogram. V rámci tohoto projektu jsou určeny milníky, které jsou svázány s předem určeným časovým okamžikem, v němž by měly být splněny. 32
Harmonogram lze popsat textově, ale mnohem srozumitelnější je v podobě jednoduchého tabulkového diagramu. Za tímto účelem byl naprogramován externí skript umožňující zanesení základních dat do databáze a následné vygenerování vizualizace takového harmonogramu. Výsledný harmonogram umožňuje větší interaktivitu v podobě vysvětlujících popisků, které se objeví po najetí myší na jednotlivé milníky. Z dat zanesených v databázi je možné vygenerovat vizualizaci harmonogramu. Jako velmi srozumitelný způsob zobrazení se ukázalo zobrazení v podobě tabulky, která vychází z tzv. Ganttova diagramu. Na vodorovné ose je zanesen čas (jako číslo měsíce) a na vertikální ose jsou zaneseny jednotlivé milníky harmonogramu.
Obrázek 7 – Zobrazení časového harmonogramu projektu Elbik
Uložené textové informace jsou zaneseny v databázové tabulce „harmonogram“. Textové informace jsou uloženy v podobě „multivalue“, jelikož bylo nutné zajistit vícejazyčné verze pro každý text. Informace zobrazované v harmonogramu jsou citovatelné skrze administrační rozhraní a to ve speciální sekci, do níž mají právo vstupovat pouze uživatelé s oprávněním (capability) označovaným jako „ADMIN_MANAGE_HARMONOGRAM“.
33
4.13 Adresářová struktura Aplikace redakčního systému běží na systému PHP, takže je na serveru uložena v podobě PHP skriptů. Navíc jsou na serveru uloženy i další potřebné soubory (obrázky, javascriptové zdrojové kódy a podobně). Tyto soubory jsem pro přehlednost rozdělil do několika složek: Tabulka 2 – Legenda adresářové struktury
/
V kořenovém adresáři jsou uloženy soubory, které tam běžně bývají (sitemap.xml, robots.txt, index.php, favicon.ico atd.)
/cache/
Složka obsahující „cache“ soubory, které jsou vytvořeny za účelem urychlení běhu skriptu či optimalizace množství databázových dotazů.
/config/
Složka obsahující konfigurační skripty (lze v nich například nastavit spojení s databází)
/content/
Zde jsou uloženy skripty mající na starost obsah webové části. Zde jsou uloženy i inkludované skripty (například skript pro přihlášení login.php apod.)
/css/
Kaskádové styly pro webovou i administrační část.
/engine/admin/
Skripty obstarávající činnost administrační části webu.
/engine/lib/
Složka, kde jsou k dispozici užitečné funkce (například funkce pro práci se strukturou multivalue).
/external_plugins/
Externí pluginy vytvořené třetí stranou, například editor TinyMCE či plugin KCFinder (jejich autorem je někdo jiný, viz kapitola o vizuálním WYSIWYG editoru).
/img/
Obrázky a grafické soubory.
/javascript/
Javascriptové soubory.
/uploaded_files/
Soubory nahrané pro publikaci obsahové části, jsou to soubory uploadované přes
administrační
rozhraní
v rámci editace
obsahových stránek.
34
4.14 Testování funkčnosti webové aplikace Testování jako takové tvoří nedílnou a nepomíjitelnou součást při vývoji jakýchkoliv aplikací - ať už se jedná o desktopové programy, tak i aplikace fungující na webové platformě.
4.14.1
Uživatelské testování
Po spuštění funkční verze jsem se snažil požádat co nejvíce lidí, aby aplikaci otestovali. Vždy jsem zmínil požadavek, aby se na web podívali i skrze jiné prohlížeče (případně s použitím různých platforem a operačních systémů). Chtěl jsem, aby se vyjádřili k rozložení webu, ptal jsem se, zda jim vše připadá dostatečně intuitivní. Podle získané zpětné vazby jsem postupně web upravoval. Při testování webových formulářů je nutné vyzkoušet funkčnost velmi detailně a pečlivě. Je potřeba vyzkoušet, zda se ukládání informací do databáze nezhroutí při použití speciálních metaznaků používaných u SQL dotazů (například uvozovky a apostrofy). Stejně tak je třeba vyzkoušet, zda nedělají problémy znaky s diakritikou. Při testování webových formulářů je třeba se také zaměřit na otestování jejich bezpečnosti, jelikož se jedná o rozhraní, kterým získává aplikace vstupní data. A to hlavně v případě, kdy data putují dále do subsystémů (databáze, shell, operační systém apod.), protože s nimi často komunikujeme tak, že vytváříme řetězce obsahující řídící informace a data, získaná ze vstupu. [5] Otestování bezpečnosti se však netýká jen webových formulářů, ale i dalších prvků, které představují možné zranitelné místo. Je potřeba mít na paměti, že bezpečnost vytvářeného softwaru by měla být brána důrazně na zřetel nejen ve fázi vývoje aplikace, ale hlavně také při jejím testování.
4.14.2
Automatizované testování pomocí různých nástrojů
Abych odhalil například chybné odkazy, použil jsem program, který umožňuje tzv. „web crawling“, což znamená, že program dokáže projít celý web a zjistit, zda někde neexistuje odkaz vedoucí na nefungující stránku, případně jestli někde není linkován obrázek či soubor (například CSS tabulka stylů), která neexistuje. 35
U webu jsem také testoval validitu výsledného HTML kódu a byl úspěšně zvalidován jako „XHTML 1.0 Transitional“. Také jsem testoval validitu vygenerovaného souboru sitemapy („sitemap.xml“), která je velmi důležitá pro vyhledávací roboty. Jelikož vykreslovací jádra prohlížečů se často liší ve způsobu zobrazení webové stránky, často se stane, že v některém z nich se něco nezobrazí tak, jak bylo zamýšleno při návrhu. Z toho důvodu je nutné web prohlédnout a otestovat funkčnost v co největším množství různých webových prohlížečů (v různých verzích a na různých platformách). V tom nám mohou pomoci speciální nástroje, které vytvoří screenshoty webu v různých prohlížečích a tyto vytvořené snímky je pak možné stáhnout k pečlivému prohlédnutí.
Obrázek 8 – Validátor webových stránek (http://validator.w3.org)
4.14.3
Vytváření logů
Při
aplikace
tvorbě
jsem
zavedl
v databázi
tabulky,
jež
jsou
používány
pro zaznamenávání různých akcí, které je vhodné mít někde zaneseny pro případné diagnostické účely. Díky těmto logům je možné při zpětné analýze odhalit případné problémy. Například se logují informace o žádostech na neexistující stránky, tedy kdykoliv dojde k chybě se stavovým kódem 404 („Page not found“). Díky tomu je pak možné například odhalit, že na stránce je umístěn nějaký nefunkční odkaz, který vede na neexistující podstránku. Do tohoto logu se zanese záznam i v případě, že je někde nesprávně uvedený zdroj obrázku v tagu img (prohlížeč se pak snaží načíst obrázek na našem serveru, avšak ten neexistuje, což vede k chybě „404“). 36
Mezi další akce, jež jsou logovány patří například přihlašování či vyhledávání (kdykoliv se někdo přihlásí nebo použije vyhledávací tlačítko, vytvoří se záznam v databázové tabulce). Vytváření logů může být velmi dobrým pomocníkem při testování aplikace a odhalování případných chyb.
37
5 Nástroje použité při vývoji 5.1 XAMPP Aplikace XAMPP je open source, multiplatformní balíček programů umožňující snadnou instalaci webového serveru Apache a databázového systému MySQL. Webový server po instalaci podporuje použití jazyka PHP a Perl. Součástí balíčku jsou i různé další
praktické
nástroje
a
doplňky
(phpMyAdmin,
FileZilla
FTP
Server,
SQLite apod.). [12] Samotný název naznačuje, že se jedná o balík aplikací pro instalaci HTTP serveru, neboť je složeninou z prvních písmen jednotlivých součástí Apache (A), MySQL (M), PHP (P), Perl (P). Počáteční písmeno „X“ značí, že se jedná o multiplatformní balíček, neboť celý název je variací na běžně používané označení „LAMP server“ (pro Linux) či „WAMP server“ (pro operační systém Windows). Díky XAMPPu je možné pohodlně a rychle nainstalovat na desktopovém počítači balík programů
potřebných
pro
vývoj
webové
aplikace
používající
technologie
PHP+MySQL, takže není nutné skripty spouštět na vzdáleném hostingu, nýbrž na lokálním webovém serveru. Díky používání virtuálního serveru může vývojář aplikaci lépe odladit, neboť má většinou více možností pro nasimulování různých podmínek
a
konfigurací
serveru.
Aplikaci
XAMPP
lze
stáhnout
z adresy
http://www.apachefriends.org, kde je možné nalézt i potřebnou dokumentaci.
Obrázek 9 – „Control Panel“ balíčku XAMPP
38
5.2 PSPad Pro psaní zdrojového kódu skriptů v jazyce PHP je nutné použít textový editor ukládající text v podobě prostého textu (neboli tzv. plain text editor). PSPad je volně šiřitelný textový editor českého původu (autorem je Jan Fiala) pro operační systém Microsoft Windows. Tento populární editor umožňuje práci s více textovými soubory najednou, podporuje zvýrazňování syntaxe pro mnoho programovacích jazyků a obsahuje mnoho užitečných funkcí, které ocení každý programátor. Oficiální stránky programu jsou na adrese http://www.pspad.com/.
Obrázek 10 – Screenshot programu PSPad
5.3 Gvim GVim je grafická verze open-sourceového programu Vim, což je velmi populární pokročilý textový editor známý především z prostředí operačního systému Linux. Tento program je opravdu mocný nástroj s nespočetně velkým množstvím praktických funkcí. Editor Vim je vysoce konfigurovatelný, takže si ho může každý uživatel velmi rozsáhle přizpůsobit svým potřebám a zvyklostem. Za nevýhodu tohoto programu může být považována náročnost na zaučení nezkušeného uživatele, neboť z pohledu běžného člověka má tento program poněkud netypický a trochu komplikovaný způsob ovládání.
39
Vim umožňuje velmi rychlou a efektivní práci s textovými soubory a může být používán jako plnohodnotné vývojové prostředí pro psaní zdrojových kódů i velmi rozsáhlých webových aplikací. Stáhnutí tohoto programu je možné na jeho oficiálních stránkách http://www.vim.org/.
Obrázek 11 – Screenshot programu GVim (v prostředí MS Windows)
5.4 phpMyAdmin PhpMyAdmin je velmi populární nástroj na správu databází MySQL pomocí webového rozhraní. Tato aplikace umožňuje vcelku pohodlnou administraci databází. Ke svému fungování potřebuje na webovém serveru přítomnost PHP. [11] Tento nástroje je často využíván i jako systém na zálohování dat z databáze, jelikož poskytuje funkci „export“ a to do různých formátů (SQL, CSV, XML, PDF, Excel a jiné). Oficiální web tohoto nástroje je možné nalézt na URL http://www.phpmyadmin.net.
Obrázek 12 – Screenshot nástroje phpMyAdmin ve verzi 2.11.11.3
40
6 Závěr Cílem mé bakalářské práce bylo navrhnout webovou platformu pro koordinaci vzájemné spolupráce mezi Vysokou školou polytechnickou Jihlava a Fachhochschule Technikum Wien. Součástí tohoto cíle bylo provedení datové a funkční analýzy a následná implementace vybraných částí systému. Tyto zadané cíle jsem při vypracování své bakalářské práce splnil. Provedl jsem analýzu potřeb zadavatele a následně vypracoval návrh webové aplikace. S pomocí tohoto návrhu
jsem
poté
realizoval
webovou
aplikaci
založenou
na architektuře
PHP + MySQL. Vytvořil jsem vlastní redakční systém, který splňoval požadavky definované zadavatelem, přičemž byl kladen důraz na možnost rozšiřitelnosti do budoucna. Výsledný redakční systém umožňuje editaci obsahu s podporou jazykových mutací. Součástí webové aplikace je systém umožňující přidělování uživatelských práv, takže je možné výslednou aplikaci rozdělit do několika zón podle uživatelského oprávnění. Velkou pozornost věnuji otázce, zda zvolit vlastní redakční systém, či zda je výhodnější vyvíjet nový na míru šitý redakční systém, který bude od začátku vytvářen přesně podle předem definovaných požadavků zadavatele. Uvádím argumenty, proč jsem se rozhodl pro vývoj vlastního systému a jaké to nese výhody. Redakční systém je připraven na další možná rozšíření, poměrně jednoduše je možné doprogramovat ve skriptovacím jazyce PHP další možné funkce webu. Vlastní moduly je možné do systému implementovat tak, že se jeví jako přirozená součást redakčního systému. Do dokumentační části této práce jsem rovněž zahrnul i návod, jak takový vlastní modul vytvořit. Součástí této práce je i popis řešení systému jazykových mutací webu, který je navržen tak, aby bylo v případě potřeby možné systém rozšířit o další jazyky. Redakční systém je připraven na to, aby bylo možné použít i vícejazyčné verze i u vlastních doprogramovaných skriptů, jelikož bylo připraveno rozhraní, které je možné za tímto účelem použít.
41
V textu bakalářské práce jsem popsal základní součásti systému tak, aby se podle této dokumentace bylo možné rychle zorientovat ve struktuře zdrojového kódu. To by mělo usnadnit práci vývojářům, kteří budou případně zdrojový kód v budoucnu upravovat a rozšiřovat o vlastní doplňky. Na výslednou bakalářskou práci je možné také nahlížet jako na případovou studii, která může být užitečná vývojářům, kteří se rozhodnou tvořit vlastní redakční systém s podporou jazykových mutací. Redakční systém je v tuto chvíli nasazen do plného provozu na adrese http://elbik.eu. Webová aplikace je připravena na jakákoliv rozšíření a do budoucna se s nimi počítá (například systém na rezervaci laboratoří). Taková rozšíření mohou být předmětem jiné bakalářské práce.
42
7 Seznam použité literatury [1] BERNERS-LEE, Tim. W3.org [online]. 1998 [cit. 2011-06-02]. Cool URIs don't change. Dostupné z WWW: . [2] DELLWIG, Elmar; DELLWIG, Ingo. JavaScript : příručka programátora. První vydání. 2003 : Grada Publishing, a.s., 2003. 276 s. ISBN 80-247-0298-3.
[3] Drupal - Open Source CMS [online]. 2011 [cit. 2011-06-02]. About Drupal. Dostupné z WWW: . [4] GILFILLAN, Ian. Myslíme v MySQL 4. První vydání. Praha : Grada Publishing, a.s., 2003. 752 s. ISBN 80-247-0661-X. [5] HUSEBY, Sverre. Zranitelný kód. Vydání první. [s.l.] : Computer Press, a.s., 2006. 207 s. ISBN 80-251-1180-6.
[6] Joomla! [online].Open Source Matters, Inc., 2011 [cit. 2011-06-02]. What is Joomla?. Dostupné z WWW: . [7] KABELOVÁ, Alena; DOSTÁLEK, Libor. Velký průvodce protokoly TCP/IP a systémem DNS. 5. aktualizované vydání. [s.l.] : Computer Press, a.s., 2008. 488 s. ISBN 978-80-251-2236-5. [8] KANISOVÁ, Hana; MÜLLER, Miroslav. UML srozumitelně. 2. aktualizované vydání. [s.l.] : Computer Press, a.s., 2006. 176 s. ISBN 80-251-1083-4. [9] Kraj Vysočina : Oficiální internetové stránky kraje Vysočina [online]. 8.6.2010 [cit. 2011-05-24]. Přeshraniční spolupráce i nadále přispívá k rozvoji Vysočiny. Dostupné z WWW:
43
[10] MCNULTY, Scott. WordPress : efektivní publikování na webu. [s.l.] : Zoner Press, 2009. 256 s. ISBN 978-80-7413-042-7.
[11] PhpMyAdmin.net [online]. 2010 [cit. 2011-06-02]. PhpMyAdmin 3.5.0-dev Documentation. Dostupné z WWW: .
[12] SEIDLER, Kai. Apache friends : very easy apache, mysql, php and perl installation without hassles [online].Apache Friends, 2011, last modification: Thu Jan 27 13:52:12 2011 [cit. 2011-06-02]. Apache friends - xampp. Dostupné z WWW: .
44
8 Seznam obrázků Obrázek 1 – Diagram základních případů užití pro redakční systém Elbik.eu ................. 9 Obrázek 2 – Diagram vazeb mezi hlavními databázovými tabulkami ........................... 15 Obrázek 3 – Koncept struktury redakčního systému ...................................................... 19 Obrázek 4 – Grafická šablona určuje podobu webu ....................................................... 22 Obrázek 5 - Vývojový diagram javascriptové funkce language_redirect() .................... 29 Obrázek 6 – Vizuální editor TinyMCE ........................................................................... 32 Obrázek 7 – Zobrazení časového harmonogramu projektu Elbik .................................. 33 Obrázek 8 – Validátor webových stránek (http://validator.w3.org) ................................ 36 Obrázek 9 – „Control Panel“ balíčku XAMPP ............................................................... 38 Obrázek 10 – Screenshot programu PSPad .................................................................... 39 Obrázek 11 – Screenshot programu GVim (v prostředí MS Windows) ......................... 40 Obrázek 12 – Screenshot nástroje phpMyAdmin ve verzi 2.11.11.3.............................. 40
45
9 Seznam tabulek Tabulka 1 – Popis systémových proměnných ................................................................. 23 Tabulka 2 – Legenda adresářové struktury ..................................................................... 34
46
10 Seznam zkratek
CSV - Comma-separated values – textový soubor typu *.csv je formát pro uložení tabulkových dat. Data jsou uloženy v podobě textu, hodnoty jsou oddělené čárkou.
FHTW - Fachhochschule Technikum Wien
HTTP - Hypertext Transfer Protocol – internetový protokol používaný pro přenos hypertextového obsahu
HTML - HyperText Markup Language – značkovací jazyk pro zápis webových stránek
PDF - Portable Document Format – formát souboru pro zpracování dokumentů
SEO - Search Engine Optimization – optimalizace pro vyhledávače
SQL - Structured Query Language – dotazovací jazyk používaný u relačních databázových systémů
UML - Unified Modeling Language – grafický jazyk pro vizuální návrh softwarových systémů
URL – Uniform Resource Locator – řetězec definující adresu zdroje informace na internetu
VŠPJ – Vysoká škola polytechnická Jihlava
WYSIWYG – „What you see is what you get“ – označení pro editory, kde editovaný obsah vidíme přímo v konečné výsledné vizuální podobě (tak jak bude výsledek vypadat v prohlížeči či vytištěný)
XML – Extensible Markup Language – formát pro výměnu dat, rozšiřitelný značkovací jazyk
47
Příloha Obsah přiloženého CD Na CD jsou k dispozici zdrojové kódy webové aplikace tvořící redakční systém. Zároveň je na přiloženém médiu umístěn soubor představující SQL export databáze.
Dostupnost aplikace na internetu Webová aplikace je přístupná na URL adrese http://elbik.eu (v době odevzdání této bakalářské práce.
48
