VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA. Katedra elektrotechniky a informatiky Obor: Aplikovaná informatika

Transkript

1 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor: Aplikovaná informatika Webová platforma pro koordinaci vzájemné spolupráce VŠPJ a Fachhochschule Technikum Wien bakalářská práce Autor: Kamil Havlíček Vedoucí práce: Ing. Zbyněk Bureš, Ph.D. Jihlava 2011

2

3 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

4 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.

5 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 Podpis

6 Obsah 1 Úvod Popis zadání Popis projektu Elektronicko - biomedicínské kooperace Analýza základních potřeb zadavatele Pro koho je systém určen popis uživatelů Rozdělení systému na sekce Systém na rezervaci laboratoří Základní případy užití Návrh systému Redakční systém (CMS) vlastní či cizí aplikace? Požadavky kladené na redakční systém CMS třetích stran - Wordpress, Joomla, Drupal a jiné Výhody vlastního řešení (oproti řešení třetích stran) Rozhodnutí: vlastní redakční systém Datová a funkční analýza Návrh databáze Ukládání vícejazyčných dat Rozdělení uživatelů do skupin podle oprávnění Realizace Popis základní struktury webové aplikace Znaková sada webu a databáze Vytvoření struktury databáze Psaní kódu Tvorba webové části redakčního systému Tvorba šablony pro frontend Systémové proměnné Realizace jazykových mutací v redakčním systému Rozlišení jazykových verzí Systém vícejazyčných verzí Obsahové stránky Překlady pomocí systému slovníkových frází Automatické přesměrování podle požadovaného jazyku Systém pro registraci a přihlášení uživatele Možnost napojení vlastních skriptů do redakčního systému Administrační část webu... 31

7 WYSIWYG editor textu Vizualizace harmonogramu projektu Adresářová struktura Testování funkčnosti webové aplikace Uživatelské testování Automatizované testování pomocí různých nástrojů Vytváření logů Nástroje použité při vývoji XAMPP PSPad Gvim phpmyadmin Závěr Seznam použité literatury Seznam obrázků Seznam tabulek Seznam zkratek Příloha... 48

8 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

9 2 Popis zadání 2.1 Popis projektu Elektronicko - biomedicínské kooperace Výzkumný projekt s názvem Elektronicko - biomedicínská kooperace (zkratka El- BiK) 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í ové 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

10 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 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 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

11 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) 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

12 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

13 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 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

14 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

15 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] 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

16 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 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

17 3.2 Datová a funkční analýza 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

18 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

19 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 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: <value lang="identifikátor_jazyku_1">hodnota_1</value> <value lang="identifikátor_jazyku_2">hodnota_2</value> <value lang="identifikátor_jazyku_n">hodnota_n</value> 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 <value>, 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: <value lang="en">project objectives</value> <value lang="de">ziele des Projektes</value> <value lang="cs">cíle projektu</value> 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

20 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 názvem multivalue (z tohoto označení pak vycházím i při pojmenování funkcí, které s tímto druhem dat zacházejí například funkce multivalue_to_array) 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

21 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

22 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): <?xml version="1.0" encoding="utf-8"?> 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

23 Content-Type: text/html; charset=utf-8 Nastavení kódové stránky pro komunikaci s ('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

24 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

25 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

26 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é $engine_url_array Popis proměnné 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 bude pak v proměnné $engine_url_array[1] uložena hodnota retezec1. $engine_title $engine_lang $engine_languages $engine_language_default $engine_error 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. 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. Tato proměnná určuje v jakém jazyce je stránka vypsána. 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 Nastavuje výchozí jazykovou verzi. 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

27 $engine_db_connection databází. Proměnná sloužící jako "handle" pro navázané spojení s databází MySQL. $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.) $engine_dictionary $engine_content_available_lang uages $engine_page_id Pole obsahující přeložené slovníkové fráze. Pokud je žádána jazyková mutace stránky, která není 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 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í 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. 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 německá verze webu je určena jazykovým identifikátorem de č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

28 jazykové verze konkrétní aktuálně načtené podstránky 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: <value lang="en">project objectives</value> <value lang="de">ziele des Projektes</value> <value lang="cs">cíle projektu</value> 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 na proměnnou obsahující asociativní pole obsahující překlady. Výsledné 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

29 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 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

30 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/ ) 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

31 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

32 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

33 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

34 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 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

35 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

36 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