České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce. Bakalářská práce. Freeform CMS

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce

Bakalářská práce

Freeform CMS Jan Třešňák

Vedoucí projektu: Sedláček David Ing.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimédia 23. května 2013

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v seznamu literatury. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 23. května 2013

…...........................................................

Abstract The paper deals with web and content creating and managment technologies with the copy angle on the independence on other than web browser-available editors. It attempts to analyze and compare methods of content creation in estabilished applications with this purpose, to specify the principles of function of this application based on the results of the analysis and available knowledge and to design and implement such system.

Abstrakt Práce se zabývá technologiemi pro tvorbu a správu webových stránek a jejich obsahu, se zaměřením na nezávislost na editorech jiných, než dostupných z webového prohlížeče. Pokouší se analyzovat a porovnat postupy tvorby obsahu u zavedených aplikací s tímto účelem, pomocí výsledků analýzy a dostupných znalostí specifikovat principy fungování aplikace a navrhnout a implementovat takový systém.

Obsah Obsah 1 Úvod..................................................................................................................................................1 1.1 Problematika & Motivace..........................................................................................................1 2 Srovnání stávajících řešení................................................................................................................3 2.1 Výběr projektů...........................................................................................................................3 2.2 Návrh testů.................................................................................................................................3 2.3 Metodika testování.....................................................................................................................4 2.4 Use Cases a jejich scénáře.........................................................................................................4 2.4.1 Úprava a nastylování textu v hlavičce...............................................................................4 2.4.2 Úprava a nastylování textu v patičce.................................................................................4 2.4.3 Zobrazení vlastního menu v hlavičce.................................................................................4 2.4.4 Vytvoření vlastního panelu na stránce................................................................................5 2.4.5 Přidání boxu do vytvořeného panelu.................................................................................5 2.4.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je v druhém use case................5 2.5 Provedení testu na aplikaci Joomla............................................................................................5 2.5.1 Úprava a nastylování textu v hlavičce...............................................................................5 2.5.2 Úprava a nastylování textu v patičce.................................................................................5 2.5.3 Zobrazení vlastního menu v hlavičce.................................................................................6 2.5.4 Vytvoření vlastního panelu na stránce................................................................................6 2.5.5 Přidání boxu do vytvořeného panelu.................................................................................6 2.5.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case.................6 2.5.7 Shrnutí................................................................................................................................6 2.6 Provedení testu na aplikaci Drupal............................................................................................8 2.6.1 Úprava a nastylování textu v hlavičce...............................................................................8 2.6.2 Úprava a nastylování textu v patičce.................................................................................8 2.6.3 Zobrazení vlastního menu v hlavičce.................................................................................8 2.6.4 Vytvoření vlastního panelu na stránce................................................................................8 2.6.5 Přidání boxu do vytvořeného panelu.................................................................................8 2.6.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case.................8 2.6.7 Shrnutí................................................................................................................................9 2.7 Provedení testu na službě Google Sites...................................................................................11 2.7.1 Úprava a nastylování textu v hlavičce..............................................................................11 2.7.2 Úprava a nastylování textu v patičce................................................................................11 2.7.3 Zobrazení vlastního menu v hlavičce...............................................................................11 2.7.4 Vytvoření vlastního panelu na stránce..............................................................................11 2.7.5 Přidání boxu do vytvořeného panelu................................................................................11 2.7.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case...............11 2.7.7 Shrnutí..............................................................................................................................11 2.8 Provedení testu na službě Webnode.........................................................................................13 2.8.1 Úprava a nastylování textu v hlavičce.............................................................................13 2.8.2 Úprava a nastylování textu v patičce...............................................................................13 2.8.3 Zobrazení vlastního menu v hlavičce...............................................................................13 2.8.4 Vytvoření vlastního panelu na stránce..............................................................................13 2.8.5 Přidání boxu do vytvořeného panelu...............................................................................13 2.8.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case...............13 2.8.7 Shrnutí..............................................................................................................................14 2.9 Zpracování výsledků................................................................................................................16 3. Analýza problému a rozmyšlení, specifikace, a návrh řešení.........................................................17

3.1 Analýza problému....................................................................................................................17 3.1.1 Možnosti použití HTML5 elementů při vytváření struktur stránek.................................18 3.1.2 Další vlastnosti HTML5 vhodné pro uživatelské rozhraní..............................................20 3.1.3 Návrhy způsobu editace vzhledu ....................................................................................20 3.1.4 Návrh organizace stránek v prezentaci............................................................................21 3.1.5 Shrnutí analýzy................................................................................................................21 3.2 Specifikace projektu................................................................................................................22 3.1.1 Cílená skupina uživatelů..................................................................................................22 3.1.2 Uživatelské rozhraní.........................................................................................................22 3.1.3 Hlavní rysy aplikace.........................................................................................................22 3.3 Analýza projektu......................................................................................................................23 3.3.1 Funkční požadavky..........................................................................................................23 3.3.2 Nefunkční požadavky......................................................................................................24 3.3.3 Případy užití.....................................................................................................................24 3.3.3.1 Správa struktury webových stránek.........................................................................25 3.3.3.2 Správa vzhledu a rozložení na jednotlivých stránkách............................................26 3.3.3.3 Uživatelské možnosti...............................................................................................27 3.3.4 Model tříd.........................................................................................................................28 3.3.4.1 Uživatelé a role.........................................................................................................29 3.3.4.2 Sekce........................................................................................................................29 3.3.4.3 Menu.........................................................................................................................29 3.3.4.4 Layout a Elementy....................................................................................................30 3.3.4.5 Styly a themes..........................................................................................................30 3.3.4.6 Obsah........................................................................................................................30 3.3.4.7 Zbylé třídy................................................................................................................31 3.4 Technologie k realizaci projektu..............................................................................................31 3.4.1 PHP..................................................................................................................................31 3.4.2 MySQL.............................................................................................................................31 3.4.3 Nette framework..............................................................................................................31 3.4.4 JQuery..............................................................................................................................32 3.4.5 Shrnutí a diskuze..............................................................................................................32 3.5 Architektonický návrh..............................................................................................................32 3.5.1 Databázový model............................................................................................................32 3.5.2 Architektura skrze Nette framework................................................................................33 3.5.2.1 Sestavení prezentační stránky..................................................................................34 3.5.2.2 Sestavení editační stránky........................................................................................34 4 Implementace..................................................................................................................................35 4.1 Utilizace PHP 5.4 v architektuře..............................................................................................35 4.1.1 Traita TPropertyInjection, ModelLoader, DefaultModel, Entity.....................................35 4.1.1.1 TPropertyInjection....................................................................................................35 4.1.1.2 ModelLoader............................................................................................................36 4.1.1.3 DefaultModel............................................................................................................36 4.1.1.4 Entity........................................................................................................................36 4.1.2 Úskalí používání traity TPropertyInjection......................................................................36 4.2 Utilizace Nette frameworku.....................................................................................................37 4.2.1 DI kontejner a služby.......................................................................................................37 4.2.2 Komponenty.....................................................................................................................39 4.2.3 Přizpůsobení frameworku................................................................................................39 4.3 Způsob organizace kódu..........................................................................................................40 4.3.1 Caching............................................................................................................................40 4.3.2 Config...............................................................................................................................40 4.3.3 Control.............................................................................................................................40

4.3.4 Layout..............................................................................................................................40 4.3.5 Model...............................................................................................................................41 4.4 Implementace editačního rozhraní...........................................................................................41 4.4.1 Dělení javascriptové vrstvy..............................................................................................42 4.4.1.1 Ajax..........................................................................................................................42 4.4.1.2 Menu.........................................................................................................................42 4.4.1.3 Win...........................................................................................................................42 4.4.1.4 Tlačítka.....................................................................................................................42 4.4.2 Způsob editace elementů – hledání optimální cesty........................................................42 4.4.3 Způsob získávání a předávání informací o stavu dokumentu..........................................43 4.5 Dynamický obsah stránek........................................................................................................43 4.6 Efektivní editovatelnost...........................................................................................................44 5 Závěr................................................................................................................................................45 Literatura............................................................................................................................................47 Příloha A.............................................................................................................................................49 Seznam použitých zkratek.............................................................................................................49 Příloha B.............................................................................................................................................51 Schéma databáze............................................................................................................................51 Příloha C.............................................................................................................................................52 Ukázka editačního rozhraní s úpravou elementu...........................................................................52 Příloha D.............................................................................................................................................54 Obsah přiloženého CD...................................................................................................................54

Seznam Obrázků Obr. 1. Frontend aplikace Joomla.........................................................................................................7 Obr. 2. Backend aplikace Joomla.........................................................................................................7 Obr. 3. Frontend aplikace Drupal.......................................................................................................10 Obr. 4. Backend aplikace Drupal........................................................................................................10 Obr. 5. Hlavní stránka v Google Sites................................................................................................12 Obr. 6. Editace postranního panelu a komponenta organizace času v hlavním obsahu.....................12 Obr. 7. Hlavní stránka při editaci ve Webnode...................................................................................14 Obr. 8. Pokročilejší nastavení šablony...............................................................................................15 Obr. 9. Základní aktéři systému..........................................................................................................24 Obr. 10. Model tříd.............................................................................................................................28 Obr. 11. Activity diagram zachycující cyklus základní aplikace v Nette...........................................33 Obr. 12. Proces sestavení stránky v hlavním presenteru....................................................................34 Obr. 13: Schéma databáze..................................................................................................................51 Obr. 14: Vzhled stránky bez editačního rozhraní...............................................................................53 Obr. 15: Vzhled stránky s editačním rozhraním.................................................................................53 Obr. 16: Editace nadpisu sekce...........................................................................................................54

1 Úvod 1.1 Problematika & Motivace Vývojář webových aplikaci se při své práci alespoň párkrát dostane do chvíle, kdy potřebuje mít možnost editace různých částí webové stránky. Protože to není úplně triviální problém, návrh a implementace takového systému, který by onu požadovanou flexibilitu poskytoval, není snadný a vyžaduje čas. Obvykle není možné takový hotový produkt vzít, nasadit na další server a jenom vyměnit obsah. Různé weby se od sebe liší v mnoha věcech, od uspořádání nadpisů po strukturu business logiky. Proto se vytváří funkční řešení, která obvykle implementují spíše omezenější množinu vlastností (např. blog, jednoduchá webová prezentace, klasické internetové fórum, eshop apod.), a při ladění funkcionality v konkrétním případě se dané řešení přizpůsobuje programováním vlastních modelů, kontrolérů, pluginů, komponent, psaním šablon a stylů atp. V této práci se zaměřím na zbavení se nutnosti používat vývojářská prostředí a textové editory pro aplikaci složitějších úprav ve webových stránkách. Cílem bude co největší flexibilita výsledné prezentace při zachování srozumitelného uživatelského rozhraní pro její modifikaci. (Cílem tedy není vytvořit jednoduché až triviální ovládání aplikace, ale spíše robustní, umožňující co největší kontrolu nad webovou prezentací.) Nejprve provedu srovnání a test funkcí pár dostupných řešení, která slouží pro zobrazování a správu obsahu na webu (Content Management System), poté se pokusím na základě dostupných webových technologií vymyslet způsob, jakým by bylo možné pracovat se všemi částmi webové prezentace (vzhled, rozmístění prvků na stránce, data) v jednom uživatelském rozhraní, navrhnout vhodnou datovou strukturu a architekturu aplikace, definovat principy a postupy uživatelského rozhraní a pokusit se nálezy ověřit implementací.

1

2

2 Srovnání stávajících řešení Alespoň základní porovnání některých systémů pro správu obsahu nabídne povědomí o aktuálních trendech v oblasti jejich funkčnosti a ovládání. Nejprve vyberu projekty k otestování, navrhnu jednoduché testy, otestuji projekty, a pak zhodnotím výsledky.

2.1 Výběr projektů Při výběru projektů bylo prioritou, aby bylo možné je otestovat zdarma, snadno je zprovoznit, aby fungovaly jako hotové řešení a byly relativně flexibilní. Dále se výběr snaží zahrnout jak aplikace, které se nainstalují na server, tak aplikace, které běží na serveru třetí strany a kýženou funkcionalitu poskytují jako službu. Testování funkcí proběhlo bez rozšíření či pluginů, a to na čistých instalacích. Vybrány byly následující projekty:  Joomla (viz [10])  Drupal (viz [9])  Google Sites (viz [11])  Webnode (viz [12]) První a druhá aplikace jsou velice rozšířené CMS napsaná v jazyce PHP s velikou základnou uživatelů, které pohánějí mnoho webových stránek. Další volby jsou čistě webové aplikace, problém nutnosti použití IDE u nich tedy odpadá (alespoň v daleko větší míře než v případě prvních dvou řešení). Otázkou ovšem je, zda-li jsou dostatečně flexibilní. Google Sites slouží spíše na jednodušší prezentace, zatímco Webnode v placené verzi dovolí vytvořit i členitější firemní web či dokonce e-shop.

2.2 Návrh testů Každá z testovaných aplikací je ve stabilní verzi a dobře implementuje funkce, pro které byla navržena. Je tedy třeba dobře popsat, jakou funkcionalitu hledáme. Uvedu jednoduchý příklad úkolu z pracovní praxe: „na webové prezentaci je potřeba pozměnit text motta a přidat informaci o aktuální nabídce a nové telefonní číslo v rámečku.“ Celkem jednoduchý úkol. Často k jeho vyřešení stačí buď několik zásahů do šablon, přepsání pár textových polí v admin sekci, či nakonfigurování CSS ve WYSIWYG editoru textu hlavičky. Ve výsledku ale sebere poměrně mnoho času z mnoha různých možných důvodů, např.:  Editace šablon je ideální dělat ve vývojovém prostředí s nakonfigurovaným projektem webové prezentace, jinak je  práce se soubory velice nepřehledná. Je tedy nutné mít funkční IDE, úpravy dělat v něm a pak je nahrávat na ostrý server. V případě absence počítače s IDE se úkol zpracovává velice pomalu či nijak.  Pokud CMS umožňuje správu speciálních textových polí, které umisťuje na různá speciální místa na webu (hlavička, patička, boxy s obsahem, …), je dost pravděpodobné, že poskytované možnosti nebudou stačit na zadání klienta. (Např. v hlavičce lze pouze změnit nadpis a motto s pevnou pozicí, klient vyžaduje další blok textu)  Pokud máme k dispozici WYSIWYG editor, tak často ale ve skutečnosti zobrazuje text naformátovaný podle pravidel a stylů editoru (tedy zobrazuje odstavce, nadpisy, textové 3

vlastnosti, ale ne tak, jak budou přesně vypadat v prezentaci samotné). Takové styly se v kontextu hlavičky stránky mohou např. zobrazit jinak než v obsahové části a může být potřeba jim ručně připsat kaskádový styl a otestovat to na frontendu webu.  Výše zmíněné problémy jsou jen malou částí všech komplikací, které se u různých systémů mohou projevit. Dále se také mohou se prolínat nebo některé nemusí existovat vůbec. Faktem ale zůstává, že k nim v různé formě dochází. Tedy ve zkratce lze říct, že administrátor/programátor stráví hodně času děláním jednoduché úlohy, čímž se dostáváme k důvodům psaní této práce. Testy tedy musí obsahovat tématicky podobné scénáře, aby bylo možné analyzovat různé postupy, které aplikace nabízejí k jejich řešení a objevit případné nedostatky.

2.3 Metodika testování Způsob testování částečně vychází z metod používaných při testování uživatelských rozhraní. Ve scénáři testu je definováno, čeho se v daném scénáři snažíme docílit a tedy je z toho i jasný kýžený konečný stav testu (jedná se o popis změn na stránce). Případy užití (use cases) jsou navržené tak, aby co nejlépe prověřily možnosti přizpůsobení webu a každý z nich má sepsaný scénář. V průběhu testu se scénářem prochází z předchozího kroku do následujícího a výsledek testu scénáře je slovní popis událostí, které je nutné provést pro splnění zadání. Při testování nebyl kladen důraz na reálné splnění těchto kroků, to by se v některých případech zbytečně ztrácel čas. (To se týká hlavně změny vzhledu, ta téměř v žádném testovaném prostředí není možná provést rychle.) Spíše jde o zachycení procesů, které ke splnění úlohy vedou a jejich náročnosti. Poznámka: testování tohoto typu je poměrně složité. Každé prostředí je třeba se naučit a je možné, že některé akce lze provést lepším způsobem, např. stahováním dalších komponent a pluginů. K testování byl použitý prohlížeč Firefox ve verzi 17.0.1 v operačním systému Windows 7, běžící na poměrně výkonném notebooku (Core i7 720QM, 12GB RAM, grafická karta GeForce GTS 360M v rozlišení 1920x1200).

2.4 Use Cases a jejich scénáře Každá z testovaných aplikací obsahuje jednoduchou webovou prezentaci, na které se staví všechno ostatní. Budeme z toho vycházet i zde, počáteční stav bude výchozí stav pro první use case a ostatní use casy budou začínat na stavu těch předchozích. Primárně scénáře řeší změnu rozložení stránky a vzhledu.

2.4.1 Úprava a nastylování textu v hlavičce. Čeho se snažíme docílit: upravit text hlavního nadpisu stránky, smazat ostatní texty, vytvořit blok textu o pár slovech a napozicovat ho někam do zlatého středu hlavičky.

2.4.2 Úprava a nastylování textu v patičce. Čeho se snažíme docílit: přidat malý odstavec textu do patičky.

2.4.3 Zobrazení vlastního menu v hlavičce. Čeho se snažíme docílit: vytvořit kolekci statických stránek (klidně prázdných) a všechny je zobrazit uvnitř menu, které se vypíše zarovnané napravo dole v hlavičce. 4

2.4.4 Vytvoření vlastního panelu na stránce Čeho se snažíme docílit: rozdělit hlavní obsah stránky na blok s hlavním obsahem a plovoucí blok s alternativním obsahem. Ověřit, zda jde přidat více bloků a přidat obsah dovnitř.

2.4.5 Přidání boxu do vytvořeného panelu Čeho se snažíme docílit: do panelu z předchozího use casu přidat plovoucí box s vlastním obsahem.

2.4.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je v druhém use case Čeho se snažíme docílit: vytvořit celou novou stránku, která bude v rámci aplikace dostupná na nějaké adrese (ideálně např. z nějakého menu) a která bude obsahovat jiné menu v hlavičce. Nakonec stránky, na které se menu odkazuje by měly používat menu této nové sekce.

2.5 Provedení testu na aplikaci Joomla Aplikace Joomla spravuje sémantickou strukturu jednotlivých stránek v templatech. Templaty jsou PHP soubory se pomocnými programovacími metodami ze samotného frameworku. Obsah stránek poskytují komponenty, které v základní instalaci nejdou stahovat uvnitř administrace. Lze vytvářet vlastní kategorie a menu, do kterých lze vložit mnoho položek převážně z komponent od konkrétního článku po přihlašovací formulář. Skrze menu jde velmi robustně rozšiřovat jednotlivé jeho položky. Lze tak například změnit počet sloupců u článku, meta tagy, konfigurace rss zdroje, apod. Nastavení je tam opravdu mnoho ve formě selectboxu. Layout je rozčleněný napevno na několik sekcí (záleží na použitém templatu), do těch se vkládají vykreslitelné moduly, které lze řídit z administrace a také je tam vytvářet. Aplikace je nainstalována ve verzi 3.0.2 na lokálním serveru Apache 2.2.22 s PHP 5.4.3 a MySQL 5.5.24.

2.5.1 Úprava a nastylování textu v hlavičce. Joomla umožňuje u některých templatů jejich modifikaci pro konkrétní stránku, kterou je možné libovolně upravit ve vestavěném textovém editoru. Není však k dispozici žádné usnadnění, kód je prakticky nevysvětlený, takže uživatel má před sebou pouze mnoho textu, který obsahuje i vnitřní logiku aplikace a modifikace tedy může být riskantní. Naštěstí vytvoření odstavce textu a jeho umístění lze udělat pomocí čistého HTML. Vkládaný text ale není ze zbytku administrace dostupný (a tedy není např. přeložitelný nebo znovupoužitelný). Po vložení lze z administrace taktéž upravit ve stejném jednoduchém textovém editoru příslušné CSS styly. Namísto vkládání textu přímo lze použít např. modul Custom HTML a umístit ho do hlavičky. Styl je ale nutné upravit ručně v CSS, nebo vepsat do tagu style v dotyčném html elementu.

2.5.2 Úprava a nastylování textu v patičce. Základní nastavení se provádí v modulu Footer, pro konkrétnější editaci lze nahlédnout do templatu. Je ale také možné použít modul Custom HTML a připojit ho do patičky – na výběr je top, middle, bottom. Taková nastavení nemusí vyhovovat každému případu a pak je potřeba sáhnout po editaci CSS stylů.

5

2.5.3 Zobrazení vlastního menu v hlavičce. Problematika menu je v Joomle vyřešena pečlivě, menu lze v administraci inteligentně vytvořit a naplnit téměř libovolnými položkami z kontextu CMS. Umístění menu se pak provádí v modulech, je potřeba najít modul Top ze základní instalace, nebo si vytvořit vlastní modul, umístit ho a přiřadit mu vytvořené menu. Nastylování se provádí v interním editoru upravením CSS souboru templatu.

2.5.4 Vytvoření vlastního panelu na stránce K tomu je zapotřebí stáhnout/vytvořit vlastní template. To spolu s větším projektem může inklinovat k použití vývojového prostředí. Také je potřeba nastudovat dokumentaci, protože editace kódu vyžaduje znalost definice umisťovací sekce v templatu.

2.5.5 Přidání boxu do vytvořeného panelu Box se vytvoří v sekci modulů a po vybrání upraveného templatu lze zvolit chtěný panel.

2.5.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case Této funkcionality lze docílit např. následujícím postupem: Nejprve se duplikuje aktuální menu, jeho klonu se upraví položky a pak se pracuje s přiřazením Modulů do jednotlivých sekcí. Tím je možné vyřešit umístění obsahu v rámci sekcí. V druhém menu se použití pouze pro položky, které se v prvním menu vypnou.

2.5.7 Shrnutí Joomla je silný nástroj pro správu obsahu. Jeho systém menu a modulů umožňuje flexibilně řešit rozložení jednotlivých komponent obsahu v rámci daného templatu. Často lze v modulu částečně nakonfigurovat způsob vykreslování obsahu (počet sloupců, počet článků, apod.), pro složitější úpravy je ale potřeba sáhnout po editaci souborů se zdrojovými kódy, k čemuž sice lze použít interní textový editor se zvýrazňováním syntaxe, daleko efektivnější však je použití IDE. Interní editor dovoluje pouze jeden soubor otevřený naráz a editační okno je malé. Je velmi pravděpodobné, že tuto funkcionalitu bude možné rozšířit pluginem. Je také potřeba konstatovat, že administrační rozhraní Joomly má pomalejší odezvu (2-5 vteřin po kliknutí), což kazí dojem z užívání jinak obsáhlého menu. Změny je potřeba ověřit v dalším okně prohlížeče, mezi sekcemi je často dlouhá cesta klikání přes 3 až 5 menu. Základní vzhled frontend Joomly je k vidění na Obr. 1, pohled do administrátorské části je na Obr. 2, kde je zachycen robustní formulář pro vytvoření položky menu. Z něj je patrné, že při vytváření položky menu nemusíme vůbec znát tvar odkazované URL, protože rozhraní tento tvar samo vygeneruje podle výběru Menu Item Type, kde lze vybrat např. článek a specifikovat jeden konkrétní, nebo vybranou kategorii článků, profil konkrétního uživatele, nebo i správu uživatelských údajů. Dále umožňuje upravit viditelnost položky podle uživatelské role, jazyk, styl výsledné stránky (lze vybrat z nainstalovaných templatů), vybrat cíl odkazu, atd. Nevýhodou ale je, že podobně jako u ostatních položek administrátorského rozhraní, chybějí vysvětlivky jednotlivých možností.

6

Obr. 1. Frontend aplikace Joomla – hlavní stránka s několika bloky.

Obr. 2. Backend aplikace Joomla – editace položky menu.

7

2.6 Provedení testu na aplikaci Drupal Aplikace Drupal funguje trochu jinak než Joomla, ale též velice podobně. Obsah se plní pomocí menu Content, lze nastavovat různé druhy obsahu. Struktura stránek se řídí tzv. bloky (obdoba modulu z Joomly), menu lze vytvářet také ve vlastní kategorii, akorát jeho konfigurace je střídmější. Akce menu se nastaví pomocí parametru Path a ta vyžaduje znalosti routování url (což lze zjistit zjistit např v sekci content, ale spíše navádí k naučení se struktury stránek). Nastavení je tu obecně méně než v Joomle, ale jsou přehlednější a často k nim nechybí vysvětlivka. Obsah lze strukturovat dle vlastních slovníků, které mohou sloužit jako kategorie či tagy. Vzhled se ale kompletně upravuje v themes, a ty nelze v základní instalaci měnit uvnitř administrace (ale existují k tomu pluginy). Aplikace je nainstalována ve verzi 7.15 na lokálním serveru Apache 2.2.22 s PHP 5.4.3 a MySQL 5.5.24.

2.6.1 Úprava a nastylování textu v hlavičce. Na pokročilou úpravu hlavičky je potřeba použít externí editor. Drupal v základní instalaci neumožňuje templaty editovat uvnitř. Zkoušel jsem v rychlosti stáhnout Modul Template Editor, ale instalace selhala a bylo potřeba ho zase zpětně odstranit (důvod selhání jsem neřešil, není to předmětem testu). Rozšíření se podobně jako v Joomle instalovalo z administrátorského rozhraní, a to buď ze staženého balíku nebo z URL. Samotný úkol se pak tedy řeší vytvořením vlastního bloku s obsahem hlavičky a jeho umístění do části header (též shodné s Joomlou).

2.6.2 Úprava a nastylování textu v patičce. Též k patičce lze připojit vlastní bloky, lze vybrat umístění do jednoho ze čtyř bloků či mimo. Toto řešení opět obnáší editaci stylů.

2.6.3 Zobrazení vlastního menu v hlavičce. Menu lze vytvořit v sekci Structure, podsekci Menu, či přímo z modulu Menu. Vytvořené menu se stává blokem a lze v sekci bloků umístit na konkrétní část stránky, včetně hlavičky. Styl se musí editovat externě.

2.6.4 Vytvoření vlastního panelu na stránce Pro tento úkol platí verdikt z Joomly. Je možné, že pluginy umožní použití editoru uvnitř prostředí.

2.6.5 Přidání boxu do vytvořeného panelu Pokud se do rozhraní dostane nově definovaný panel (tedy místo, kam lze vkládat bloky obsahu na konkrétním místě v layoutu stránky), lze do něj snadno připojit nové či existující bloky.

2.6.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case Tento problém je podle mě lépe řešený v Drupalu. Využije se zde typů obsahu – Content Type. Pro blok lze totiž nastavit, pro jaké typy obsahu se má zobrazit. Ty je tedy potřeba mít správně nastavené, ale pak se viditelnost bloku řeší daleko snadněji. Označování typu obsahu 8

a následné využití této informace pro organizaci obsahu je flexibilnější než nastavovat viditelnost menu pro každou stránku, či nastavovat viditelnost pro jednotlivé templaty.

2.6.7 Shrnutí Drupal je více odlehčené řešení, neobsahuje příliš mnoho nastavení a spíše spoléhá na budoucí rozšiřování pomocí pluginů (kterých je v době psaní práce skoro 20 000). Rozhraní vyžaduje spíše pokročilejší přístup, je potřeba porozumět adresám na webu a zorientovat se v nich, a je také potřeba dobře využít funkčnost označování obsahu. Drupal také nemá administrační rozhraní natolik odtržené od zbytku webu. Administrační panel se po autorizaci ukáže přímo na stránce a je možné na provedené úpravy koukat rychleji. Na škodu je, že při takových možnostech nelze obsah po návrhové a grafické stránce skoro měnit. Na Obr. 3 je zachycen frontend aplikace Drupal a je z něj zřejmá změna typu uživatelského rozhraní – totiž horní dva pruhy patří administrátorskému panelu a frontendová prezentace začíná až pod nimi. Takový přístup mi přijde mnohem přirozenější, protože uživatel je s webem při jeho úpravě víc v kontaktu a může pozorovat provedené změny, kterých za na druhou stranu není v čisté instalaci tolik. Na Obr. 4 je zachycen formulář z administrátorského rozhraní, který slouží k vytvoření či úpravě bloku na stránce. Je možnost zvolit název bloku, umístění bloku (výběr z pevných pozic pro každý motiv) a nastavit, kde se blok zobrazuje, a to jak podle konkrétních stránek, tak i typů obsahu, privilegií i konkrétních uživatelů. Naopak zvláštní je, že např. takové menu je také blok – tedy umisťuje se v menu umisťování bloků a lze ho i jako blok upravit, nicméně položky toho menu se nastavují v jiném formuláři. Podobně jako Joomla, disponuje Drupal efektivními prostředky, pro výstavbu menu, dělení skupin stránek do různých sekcí, či ovlivňování vzhledů konkrétních stránek, které však dokáží pracovat pouze se zavedenými grafickými motivy a bloková struktura lze organizovat podle pevných částí. Též nastavení samotných bloků je velice jednoduché a neumožňuje komunikaci např. s modely. To ale v mnoha situacích plně dostačuje anebo dostačovat musí. Je třeba samozřejmě brát v úvahu, že oba projekty jsou velice úspěšné a určitě programátorské týmy odvedly mnoho hodin kvalitní práce, neboť se jim podařilo vytvořit velice robustní systémy na organizaci dat, u nichž není prioritní fungovat i jako HTML editor, ale přednostně poskytovat co nejlepší Content Management System. Tedy negativní hodnocení některých vlastností obou aplikací je způsobeno především rozdílnou metodikou hodnocení a zaměření na odlišné prvky.

9

Obr. 3. Frontend aplikace Drupal.

Obr. 4. Backend aplikace Drupal, vznášející se nad frontendem. Sekce nastavování menu. 10

2.7 Provedení testu na službě Google Sites Služba Google Sites [11] je zdarma poskytována k libovolnému účtu Google. Aplikace je celá online a způsob editace se blíží konceptu WYSIWYG. Při editaci je uživatel celou dobu na svém webu a změny v obsahu jsou vidět téměř okamžitě. Celá služba je spíše zaměřena na správu a sdílení než na vytváření graficky vyladěné prezentace, protože se vhled a rozložení jsou téměř fixní. Měnit lze pouze barvy a schémata, která podkreslí pevně danou strukturu: k dispozici je jeden levý panel, horní navigační panel, patička, hlavička a obsah. Do obsahového panelu lze přidat mnoho typu webového obsahu, od tabulek a obrázků přes dokumenty Google, grafy, výpisy sekcí, prezentace z fotek služby Google Picassa, vlastní HTML blok apod. Nastavení už je méně a spíše splňují nutné minimum na pohodlné využívání.

2.7.1 Úprava a nastylování textu v hlavičce. V Google Sites nelze přidat text přímo do hlavičky.

2.7.2 Úprava a nastylování textu v patičce. Do patičky lze vložit text a lze ho upravit po typografické stránce pomocí vestavěného WYSIWYG editoru.

2.7.3 Zobrazení vlastního menu v hlavičce. Menu lze zobrazit pouze v sekci navigace pod hlavičkou, tam mu lze nadefinovat jako prvky jednak stránky aplikace, ale také normální URL.

2.7.4 Vytvoření vlastního panelu na stránce Vytvořit vlastní panel v Google Sites nelze.

2.7.5 Přidání boxu do vytvořeného panelu Lze přidávat boxy do jediného možného levého panelu (který je možné posunout napravo). Boxů jemalý počet, je mezi nimi i libovolný text, dále pak např. autor stránky, poslední aktivita na webu apod. Boxy je možno posouvat v rámci panelu pomocí drag'n'drop.

2.7.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case Tento problém by se nejlépe řešil asi vytvořením dalších stránek na Google Sites, které by se pak prolinkovaly. Jinak to není možné.

2.7.7 Shrnutí Google sites je na rozdíl od předchozích dvou řešení poměrně lehká služba, která neobsahuje příliš mnoho nastavení, ale také se lehce ovládá. Pokud zadání stránek vyhovuje menší množině možností služby Google Sites, je možné stránky připravit opravdu velmi rychle. Na druhou stranu pak vypadají velmi podobně jako ostatní stránky z této služby. Na Obr. 5 je zobrazena hlavní strana Google Sites, na Obr. 6 je pak zachycena editace postranního panelu s komponentou pro organizaci v hlavní sekci stránek. Ideální využití této služby by mohlo být například při studiu, kdy je potřeba v rámci skupiny studentů spravovat nějaký projekt. 11

Obr. 5. Hlavní stránka v Google Sites.

Obr. 6. Editace postranního panelu a komponenta organizace času v hlavním obsahu.

12

2.8 Provedení testu na službě Webnode Služba Webnode [12] je poměrně zajímavé řešení problematiky správy obsahu. Umožňuje zdarma či s lepšími možnostmi za poplatek vytvořit a spravovat webovou prezentaci či e-shop, celá funguje na webu a poskytuje daleko více možností než Google Sites. Služba zejména integruje spolupráci s mnoha nástroji třetích stran, např. Google Metrics, Analytics a Checkout, Microsoft SkyDrive, různé online mapy, PayPal, YouTube, Facebook like tlačítko, Twitter, dotazníky Survio, formuláře Wufoo, mnoho komponent od BlueBoardu a další. Dále integruje články, katalog a jednoduché formuláře. Vzhled je opět řešený přes themes, jejichž kaskádové styly je možné editovat uvnitř aplikace pomocí vestavěného čistě textového editoru. Celá šablona lze též spolu se styly a různými variantami rozložení obsahu stáhnout a editovat ve vlastním vývojovém prostředí. V šablonách se používají XML značky, jejichž interpretaci lépe nastudovat v oficiálních materiálech. Rozložení prvků pak lze do jisté míry ovlivňovat, dokonce na některých částech stránky funguje drag'n'drop celých bloků s obsahem. Což se týká spodní části levého panelu a hlavního obsahu. Nelze ale zdaleka přetahovat všechno, takže po prvotním dojmu absolutní kontroly přijde rychlé vystřízlivění v podobě fixní hlavičky a horní části levého panelu, což lze ale snadno odůvodnit např. tím, že je to jednodušší a méně matoucí pro uživatel, či také tím, že drag'n'drop v tomto případě slouží hlavně jako nástroj jak snadno přeuspořádat části stránky s vlastním obsahem a lépe tak strukturovat a tím pádem i předávat obsaženou informaci.

2.8.1 Úprava a nastylování textu v hlavičce. Webnode podporuje jeden slogan do hlavičky. Jeho vypozicování se musí provést v CSS.

2.8.2 Úprava a nastylování textu v patičce. Text patičky je dělený na dvě části – levá a pravá. Do obou lze vložit vlastní krátký text, avšak v neplacené verzi se v pravé části nachází informace „Vytvořeno službou Webnode“. Více úprav s patičkou dělat nelze, alespoň ne ve standardní verzi (která je prvních 30 dní s prémiovými službami). Je možné, že možnosti úprav se mohou malinko lišit v e-shopové variantě.

2.8.3 Zobrazení vlastního menu v hlavičce. Menu lze zobrazit pouze v levém panelu nahoře a je jen jedno – tato verze tedy není zamýšlena pro velké prezentace.

2.8.4 Vytvoření vlastního panelu na stránce Vytvořit vlastní panel ve Webnode nelze (možná nějakým složitějším způsobem v layoutu ano). Je ale možné obsah stránky rozdělit na více částí – obvykle šablona podporuje 3-5 způsobů rozložení. Pak lze při dvousloupcovém rozložení použít jeden sloupec jako panel a do něj přetáhnout příslušný obsah. Vzhledově však zapadá mezi hlavní obsah a je to spíše poloviční řešení.

2.8.5 Přidání boxu do vytvořeného panelu Bloky lze přetahovat v rámci povolené oblasti libovolně. Jako základní blok lze považovat blok s formátovaným textem.

2.8.6 Vytvořit sekci, která bude mít jiné menu v hlavičce, než je ve třetím use case Toto není možné. Situace by šla jedině vyřešit pomocí více různých stránek, ale to je 13

poloviční řešení, které obsah dělí na více míst a při zachování stejného rázu prezentací je hůře udržitelné.

2.8.7 Shrnutí Webnode je působivý projekt, který do jisté míry opravdu funguje jako WYSIWYG pro webovou prezentaci. Všechna okna rozhraní jsou menšího rozměru a původní stránka je pod nimi dobře vidět. Použité změny jsou vidět okamžitě. Mezi jednotlivými stránkami se lze pohybovat jako normální uživatel a v případě nutnosti lze každou na místě změnit. Ve skutečnosti ale zdaleka není možné měnit cokoliv. Však podobně jako Google Sites, Webnode ve všech testech splnil jen malou část zadání. Služba se zdá být ideálním nástrojem pro schopné podnikatele a manažery, kteří pro svůj vzkvétající business hledají levné stránky, na kterých si mohou vše udělat po svém a takříkajíc „co nemohou oni, to nemůže nikdo“, nebo také pro každého, kdo chce jednoduché stránky snadno a rychle. Na Obr. 7 je vidět základní stránka aplikace s kontrolním panelem a rozhraním přímo v prezentaci samotné, umožňující interaktivní práci s obsahem.

Obr. 7. Hlavní stránka při editaci ve Webnode, menu ve vzoru ribbonu umožňuje modifikace obsahu. 14

Na Obr. 8 je pak k vidění sekce „Pokročilé nastavení šablony“, kde se trochu změnilo menu a v prezentaci se zobrazuje speciální stránka s přehledem formátovacích prostředků a jejich vzhledem. (Vzhled lze upravit tlačítkem „Upravit CSS“.)

Obr. 8. Pokročilejší nastavení šablony s jiným menu a přehledem formátovacích možností.

15

2.9 Zpracování výsledků Aplikace si v testech vedly různě. Projekty Joomla a Drupal předvedly velice robustní možnosti správy obsahu. V případě nutnosti správy žurnalistického či jiného rozsáhlého obsahu jsou určitě lepší volbou než druhé dvě služby. Mezi jejich výhody patří zejména veliké možnosti správy obsahu, rozšíření a možnost aplikace dále doprogramovat k obrazu svému. Na druhou stranu doprogramovat je nutné i vzhled. Nasazení aplikace, poháněné těmito CMS je tedy netriviální, stejně jako změna vizuální stránky. Za zmínku stojí historická srovnání těchto dvou CMS na [1] a [2], jejichž některé závěry dle mého názoru pořád platí. Na druhé straně stojí služby Webnode a Google Sites. Jejich možnosti správy obsahu a vzhledu nejsou zdaleka na úrovni projektů Joomly a Drupalu. To ale zřejmě ani není jejich cíl. Obě dvě poskytují relativně flexibilní možnosti vytvořit bohatý obsah v krátkém čase. Dominantou Googlu je propojení s vlastními službami a sady Google Documents, Webnode zase nabízí plno schémat a celkově umožňuje vytvořit na dojem bohatší firemní prezentaci či dokonce jednoduchý e-shop a integrace s webovými službami je hlubší. Nicméně tento test byl navržený pro prozkoumání oblasti, ve které se očekávalo, že žádný z projektů nezíská prim. Cílem této práce je prozkoumat možnosti z hlediska možnosti kompletní editace obsahu a vzhledu v prohlížeči. Z hlediska možnosti upravování obsahu dominovaly Drupal a Joomla. Mezi jejich přední výhody bych umístil následující:  Vytváření a správa libovolného počtu menu, které lze sestavit ze všemožných položek, včetně interních přihlašovacích formulářů či přímo odkazů na konkretní článek či výpis novinek – tyto menu pak lze v libovolném bloku umístit do libovolné části stránky. Bohužel jedině pomocí tabulek a formulářů v administračním rozhraní.  Konfigurovatelné komponenty v layoutu – možnost vytváření bloků obsahu a jejich umisťování do struktury stránky. Bloky mohou být též naplněny obsahem komponent a daty z jejich modelů.  Podpora funkcí pro návštěvníky – možnost přihlašování uživatelů a řízení pověření pro jednotlivé uživatelské role.  V případě Drupalu musím vyzdvihnout možnost kategorizování typu obsahu vedle kategorizování jeho náplně. Joomla skrze plugin určitě danou možnost podporuje taktéž.  Rozšiřitelnost. Možnost napsat vlastní business vrstvu nad aplikací či komplikovanější vykreslitelné komponenty. Naopak služby Webnode a Google Sites dobře demonstrovaly přístup k obsahu webu přímo, tedy editaci ve stylu WYSIWYG, konkrétněji:  Možnost přetáhnout (použít drag'n'drop) jednotlivé bloky v rámci stránky.  Úprava vlastních textových polí přímo ve stránce, tedy možnost vidět data v kontextu při práci s nimi.  Dynamické vkládání bloků, taktéž v duchu WYSIWYG, při přidání bloku s obsahem stačí přijít na chtěnou stránku, vložit blok, vyplnit v modálním okně pár parametrů a umístit/přemístit nově vytvořený blok na chtěné místo.

16

3. Analýza problému a rozmyšlení, specifikace, a návrh řešení V této kapitole se pokusím výsledky testů, vlastní pohled na věc a zkušenosti použít k navrhnutí aplikace, která bude umožňovat jak použitelnou správu obsahu stránek a jejich struktury, tak i možnost změnit vzhled za běhu aplikace přímo v její struktuře. V první řadě bude potřeba promyslet, jakým způsobem bude aplikace fungovat, jaké budou hlavní principy jejího ovládání, s jakými prvky se bude při editaci pracovat a jak tyto prvky ukládat. Vzhledem k rozsahu zadání je nutné počítat s iterativním přístupem, tedy opakovaný návrh, implementace a testování, případně ověření hypotézy správného, zda-li vůbec možného postupu. Poté se pokusím některé aspekty popsat pomocí metod modelování softwaru, jimiž jsou např. funkční a nefunkční požadavky, případy užití a model tříd. Také proberu technologii k realizaci a nastíním možnou architektonickou strukturu aplikace a možnosti realizace za pomoci dostupných technologií.

3.1 Analýza problému Je zřejmé, že problém je značně netriviální, protože webová prezentace sestává z velké řady technologií a s každou se pracuje jiným způsobem. Rekapituluji technologie, které definují vzhled stránky, tedy samotný výsledek viditelný v prohlížeči a zdůrazním jejich použití při správě obsahu v testovaných aplikacích: •

HTML: značkovací jazyk, který organizuje strukturu dokumentu. Struktura HTML stránky se řídí pravidly syntaxe a sémantiky a velice záleží na správném uspořádání elementů. Běžnou praktikou v dnešní době je HTML strukturu dokumentu z webového rozhraní neřešit a nechat serverovou vrstvu dokument správně poskládat (tedy vyplnit data v admin sekci, která se zobrazí podle pevně daných pravidel na frontendu). Všechny testované aplikace ale podporují možnost strukturu stránky přece pozměnit z admin rozhraní a to sice formou zmiňovaných „bloků“. Blok v podstatě označuje rámeček s nadpisem a nějakým obsahem, zpravidla obsahem nějaké komponenty nebo čistě textovým. A ve skutečnosti to bývá HTML element div s nadpisem pomocí elementu h2h6 a obsahem ve formě vnořeného divu, odstavce (p), či libovolné struktuře elementů vytvořené např. komponentou.

•

CSS: stylopisový jazyk, který se stará o skutečný vzhled HTML dokumentu a definuje pravidla pro grafickou reprezentaci všech elementů na stránce. Na většině webových aplikací se řeší vytvořením stylopisu, který přesně pasuje na konkrétní HTML strukturu a případně existuje více verzí, tedy více motivů. Stejně se to řeší i v testovaných CMS, kdy získání vyhovujícího motivu je základem vytvoření prezentace. Pro Joomlu a Drupal existuje mnoho různých motivů, vytvořených komunitou uživatelů a Webnode nabízí širokou škálu též, s možností vlastních úprav. Přirozená tendence ale bývá kvůli vytvoření dojmu jedinečnosti vzhled vytvořený třetí stranou modifikovat dle vlastních představ, což se samozřejmě netýká enterprise projektů pro velké firmy, kde se o každou část prezentace stará nějaký tým. Zmiňované bloky obsahu pak dědí stylopis motivu a díky jednotě jejich interpretaci v HTML se s nimi zachází podobně.

•

Javascript: programovací jazyk pro doplnění grafických efektů na stránce, ale mnohem spíše v dnešní době prostředek pro vytvoření komplexnější struktury aplikace a zlepšení 17

uživatelské zkušenosti pomocí vyřizování požadavků bez načítání stránky (tedy bez změny kontextu pro uživatele). Testované aplikace v základě javascript vůbec nezdůrazňují při editaci struktury a nejpravděpodobnější užití je ze speciálních komponent, z motivu, či ručně dopsaný, a vzhledem ke konkrétnosti potřeby javascript použít je to myslím zcela pochopitelné. Popsané použití technologií koreluje s tendencí nevystavovat tyto technologie na web. Je ale vysoce pravděpodobné, že pro vytvoření aplikace, která umožní daleko vyšší kontrolu nad celou strukturou dokumentu, bude potřeba některé postupy přehodnotit. Především možnost editovat celý dokument se neslučuje s principem každou část stránky řešit div elementem, protože výsledný dokument by výrazně nesémantický a možná i nevalidní. Je tedy potřeba do vytváření struktury vložit nějaký řád a jako dobré řešení se mi zdá být sémantika HTML5. Ta se totiž daleko pečlivěji věnuje struktuře dokumentu zavedením tagů section, article, header, footer, nav a aside, které by měly být schopné nahradit všechny hlavní kontejnery obsahu na běžné HTML stránce, což se samozřejmě netýká čistě vzhledově orientovaných elementů (různých divů a spanů).

3.1.1 Možnosti použití HTML5 elementů při vytváření struktur stránek Dle HTML5 (výborné zdroje: všechny články z [13], [14] a pokračování, [15] potvrzuje předchozí zdroje, [16]) lze celý dokument po vzoru tištěného dokumentu rozložit na hlavičku, obsah a patičku a toho rozložení lze rekurzivně aplikovat pro dílčí části dokumentu, tedy obsah se může skládat např. ze dvou sekcí (panelů), z nichž jedna poskytuje prostor pro malé „bloky“ a druhá zobrazuje hlavní obsah stránky, tedy např. článek. A tyto vnitřní bloky obsahují hlavičku, tělo a občas také patičku. Za povšimnutí stojí fakt, že této definici opravdu drtivá většina obsahu odpovídá. Bylo by tedy logické tyto charakteristiky použít jako východisko pro vytvoření struktury, která bude muset mít stromovou strukturu. Uchovávat v ní ovšem všechny HTML elementy by bylo datově náročné a nepraktické z hlediska ovládání – je potřeba simulovat možnosti „bloků“ a dobře se postarat o jejich náplň. Základní elementy, které by se staraly o sémantické dělení, případně o rozvržení sémantických částí, by byly ty uzly stromu, které by byly uloženy v databázi. Byly by to následující druhy elementů (u každého uvádím zdroje): •

section ([14], [15], [22]) – sekce dokumentu s vlastním významem, tedy základní typ bloku. Sekce musí mít nadpis a obsah. Příklady užití: blok s obsahem (anketa, výpis článku, zboží, reklamy, atp.), sémanticky je však též správně použít sekci jako členění nějakého textu (např. hlavního článku na stránce).

•

article ([14], [15], [26]) – speciální případ sekce, který obaluje samostatnou jednotku obsahu. Může tím být například článek, video, produkt, komentář ke článku, novinky, …, syndikovatelný obsah.

•

aside ([15], [20]) – další dělící prvek, mající dva hlavní významy v závislosti na kontextu. Pokud je prvek uvnitř článku (article), jeho obsah souvisí s článkem a doplňuje jeho informaci (například legenda, slovník pojmů, související články). Pokud je mimo článek, obsahuje další informace pro celou stránku, tedy vhodný element na realizaci „panelů“, obsahující bloky ze sekcí.

•

nav ([15], [21]) – element obalující navigaci stránky (jak menu sekcí celé prezentace tak osnovu článku). Jeho náplní bude nejčastěji seznam odkazů, poskytnutý tagem ul nebo ol. 18

•

header ([15], [18]) – tedy hlavička sekce/článku/dokumentu. Má primárně 2 druhy použití, jednak jako hlavička celého dokumentu obsahující hlavní nadpisy stránky, případné motto, nějaké navigace, a také jako obálka hlaviček všech dalších sekcí a článků, kde se hodí primárně pokud má obsahovat více informací, než jen nadpis (v tom případě by dostačoval element nadpisu h1–h6), jako např. datum, autor či seskupení více nadpisů. Použití elementu header není nutné v případě, že se hlavička skládá pouze z nadpisu (např. h1), což je detail, který by se od uživatele mohl odstínit – bylo by např. elementy nazvané srozumitelně jako „nadpis“ a „hlavička“ možné mezi sebou snadno konvertovat, tlačítko přidat podnadpis nebo odebrat by se staralo o přidání dalšího nadpisu.

•

footer ([15], [19]) – patička sekce/článku dokumentu. V hlavním dokumentu slouží jako klasická patička obsahující praktické rozcestníky, informace o licenci a další dodatečné informace, ale stejnou roli může plnit i u článků a sekcí, byť pravděpodobně méně častěji.

•

div ([15]) – nesémantický element, který se ale hodí jako kontejner v případech, kdy tu roli nemůže zastat sémantický element, tedy např. pro čistě účel uspořádání nebo obalení různých elementů (odstavce textu p, sloupcový design, apod.).

•

ul či ol ([15]) – seznam položek. Bylo by ideální po vzoru WYSIWYG editoru takový seznam řešit tlačítkem, výběrem způsobu číslování, apod.

Následující elementy jsou také blokové, nicméně jejich užití mimo již zmíněné struktury nemá ze sémantického hlediska smysl. Nejsou to tedy elementy tvořící struktury celé stránky, ale pouze obalují specifické druhy obsahu. •

p ([15]) – odstavec textu.

•

dl ([15], [28]) – list definicí, je sémantický vhodnější strukturou pro legendy a slovníky pojmů. Stejně jako v případě seznamu je režie tagů (dt, dd, dfn) docela náročná, a pro editaci by chtělo ji automatizovat. (Klávesa tabulátor by sloužila pro ukončení definice a začátek výkladu.)

•

blockquote ([15], [29]) – bloková citace. Nosič pro odstavce textu citace, ale může obsahovat i patičku se sémanticky označeným zdrojem citace v tagu cite (což musí být název práce, autora je možné vložit do tagu address).

•

figure ([15], [27]) – figura. Po vzoru prací, jako je např. tato, lze i v HTML dokumentu každý obrázek, tabulku, graf, ukázku kódu nebo i multimediální element doplnit popiskem, k čemuž slouží vnořený element figcaption.

•

img ([15]) – obrázek sám o sobě může sloužit např. jako atmosférická vložka či jako banner.

•

pre ([15]) – neořezávaný text, hodí se pro zdrojový kód.

V HTML5 existuje dále celá řada inline elementů, které nejenom dělají obsah lépe pochopitelný pro stroj, ale mohou usnadnit orientaci v dokumentu i pro čtenáře. Vlastně přímo obohacují jazyk standardních formátovacích prostředků (řezy fontů, odsazení, proklady) – místo „tučně“ či „kurzívou“ se nabízejí výrazy typu: zvýraznění (strong), důraz na zvuk/přízvuk (i), důraz na změnu nálady (em). Takové chápání je podle mě i velice odpovídající běžnému užívání tučného řezu, italiky a jejich kombinacím. Navíc použité elementy by bylo možné dostylovat podle potřeby. Inline elementy budou pravděpodobně dostupné při textové editaci náplně blokového elementu. •

a ([15]) – hypertextový odkaz, základní propojovací prvek webové prezentace. Možnost 19

zvolit zdroj odkazu a získat od aplikace odkazy na každou možnou stránku/sekci, nastavení cíle… •

h1–h6 ([15], [18]) – nadpisy, volně použitelné v textu a automatizovaněji doplňované do sekcí.

•

time ([15], [24]) – element značící časové označení. Vhodné jednak pro časy zveřejnění a úprav obsahu webu, ale i pro časové údaje v textu. Volitelný atribut pubdate může znázorňovat, že datum označuje vznik článku (mohlo by se zapnout automaticky), atribut datetime obsahuje samotné datum v normalizovaném tvaru (vyplnění např. javascriptovým widgetem) a obsah elementu by byl buď vlastní nebo vygenerovaný podle předdefinovaných šablon, či časově závislý (údaj typu „před hodinou“).

•

em, i, strong, b ([15], [17]) – významy byly nastíněny výše, dobrý příklad užití zmiňuje [poznámka].

•

cite ([15], [29]) – dle specifikace označuje název díla. Jasné místo má v blokových citacích a možné je i použití uvnitř dalšího obsahu.

•

q ([15], [29]) – citace v textu. Zde by šlo využít možnosti konfigurace uvozovek (což by nějak souviselo i s nastavením motivu). Nejen že by pak byly přímé věty byly správně sémanticky vyznačené, ale také by mohly mít korektní uvozovky (včetně vnořených) v závislosti na jazyce citace.

•

address ([15], [23]) – může to znít paradoxně, ale tag address neoznačuje fyzickou adresu, ale měl by označovat autora a případně obsahovat odkaz na kontakt nebo vlastní stránku. V rámci systému by tedy bylo možné u tohoto elementu nastavit odkaz na uživatele, v opačném případě vyplnit ručně.

•

small ([15], [25]) – blok textu často malým písmem, má význam vedlejšího textu k hlavnímu článku. Hodí se pro prohlášení, licenci a nebo např. pro informace o datu a autorovi v hlavičce.

•

hr ([15], [25]) – horizontální oddělovač má sémantický význam ukončení tématu a lze realizovat i formou ornamentů, jako je typické pro knihy a jiné tiskoviny.

•

span ([15])– nesémantický element čistě pro účely designu či chodu aplikace.

Elementů je opravdu mnoho a rozhraní, které by s nimi v této formě pracovalo, by bylo možné popsat desítkami, možná stovkami různých scénářů. Proto se dále pokusím přidat alespoň trochu abstrakce do principu rozhraní.

3.1.2 Další vlastnosti HTML5 vhodné pro uživatelské rozhraní V kombinaci s masivním javascriptovým enginem by se dalo relativně rychle dosáhnout editace elementu přímo na stránce za použití tagu contentEditable. Tag je podporovaný ve všech používaných prohlížečích [odkaz] a umožňuje umístit kurzor dovnitř elementu a textově editovat jeho obsah. Implementace v prohlížečích se v detailech trochu rozcházejí [odkaz] a proto by případné použití mělo být co nejvíce jednoznačné (tedy neentrovat v jiných elementech než paragraph, apod.).

3.1.3 Návrhy způsobu editace vzhledu Je třeba využít možností kaskádových stylů a zpřístupnit je při editaci stuktury. Po vzoru například panelů z tláčítky z aplikací typu grafické editory by mělo být možné označenému textu 20

a nebo celému bloku textu nastavit velikost písma, typ fontu, barvu, tloušťku, proklad, počáteční odsazení v odstavci (typické pro český text), přeškrtnutí/podtržení… Každá vlastnost má ekvivalent v kaskádových stylech a je navíc za běhu u každého elementu dostupná přes javascript. Důležité je ale rovněž správné strukturování těchto tříd vzhledu, aby pak stylopis neobsahoval stovky záznamů pro každý element. Element by určitě měl mít možnost přidat třídy vzhledu (tedy položky atributu class), ale celé zacházení se vzhledem se musí orientovat hlavně podle způsobu intepretace CSS prohlížečem. Tedy motiv stránky by obsahoval nějaké základní předpisy pro zobrazování (např. globální velikost textu, nadpisů, odsazení v poznámkách) a potom specifikované případy. Protože je možné, že některé elementy v datové reprezentaci HTML stromu nebudou uloženy jako uzly, ale pouze jako obsah jiných uzlů, lze usoudit, že jsou identifikováni svým rodičem z datové struktury. Nejrobustnější by tedy při změně stylu elementu bylo mít přehled o všech aplikovaných stylech a mít možnost vybrat, kterou skupinu upravit. Jednalo by se např. o skupiny „aplikovat pouze na tento element“ (vytvoření unikátní CSS třídy), aplikovat na elementy stejného typu (styl pro typ elementu), aplikovat na elementy stejného typu ve stejném typu rodiče (zápis by bral v potaz rodičovský element), apod. Ale to jsou komplexní úlohy a počáteční řešení by mělo být spíše jednodušší (hlavně pomocí tříd a elementů). Celý stylopis bude rovněž uložený v databázi, bude se cachovat a generovat pouze v případě změny v motivu.

3.1.4 Návrh organizace stránek v prezentaci Webové stránky jsou identifikovány svojí URL a její tvar často vypovídá o struktuře. V zájmu zachování tvaru adres vhodného pro SEO a i dobře čitelného uživatelem se používají slova oddělovaná lomítkem, připomínající adresářovou strukturu, ale ve skutečnosti obsahující názvy stránek, pojmenovaných podle hlavního objektu na stránce (tedy např. jména kategorií, zakončena jménem článku či produktu, jména tagů, sekcí apod.). Poslední řetězec může obsahovat za tečkou příponu souboru nebo název akce, možností je více. Ve webové aplikaci pak řízení požadavků zařizuje router, který obsahuje předpisy pro všechny typy sekcí a překládá jim parametry v závislosti na URL. Pro umožnění vytváření celé struktury stránek bude myslím vhodné vytvořit jednoduchá pravidla, trochu po vzoru služby Webnode, kde lze přidávat statické stránky do stromu a vnořené stránky jsou dostupné přes URL jejich rodičů. Na URL se bude aplikovat jedna hlavní routa, která uloží dostupné hodnoty do přednastavených polí a poté se dle těchto hodnot nalezne sekce na zobrazení. V zájmu zachování možnosti dynamických URL bude zpracování url brát v potaz i další parametry a při parsování je odloží stranou pro případné argumenty. Pro možnost zobrazit více podobných pohledů na část modelu, charakterizovanou podobnou URL, bude možnost za poslední parametr doplnit za tečku řetězec, který bude v dané sekci značit konkrétní cíl.

3.1.5 Shrnutí analýzy Tato analýza je výsledkem několika iterací upřesňování popisu problému, návrhu, částečné implementace. Navrhuje způsob fungování aplikace a hlavně jejího ovládání, které obsahuje prvky grafického editoru při práci s DOM. Téma je široké a realizovány budou pravděpodobně pouze malé fragmenty. Myslím ale, že vymyšlený způsob je snad dobrým kompromisem mezi zachováním široké možnosti editace, a zároveň vůbec umožněním dokument nějak rozumně sestavit a upravovat.

21

3.2 Specifikace projektu Zde se pokusím aplikaci upřesnit zadání aplikace z hlediska cílové uživatelské skupiny, uživatelského rozhraní a hlavních rysů celé aplikace, kde v rychlosti rekapituluji alespoň ty nejzákladnější.

3.1.1 Cílená skupina uživatelů Primární cílová skupina uživatelů jsou programátoři či weboví designéři, kterým by možnost spravovat celou webovou prezentaci z jejího administračního prostředí ulehčila práci. Ale není vyloučené, že rozhraní bude použitelné i pro člověka s minimální gramotností v oblasti výpočetní techniky. V takovém případě hrají samozřejmě roli i přehledné uživatelské rozhraní a nápověda, které v dobrém zpracování snadno pomohou chytřejšímu uživateli. Aplikace ale bude řešit strukturu stránek a prioritou bude robustnost této struktury, na úkor jednoduchosti. Navíc rozhraní typu grafického editoru je v dnešní době hodně rozšířené.

3.1.2 Uživatelské rozhraní Uživatelské rozhraní bude klást důraz na přehlednost a zároveň možnost docílit co největších změn. Celá administrace bude přístupná z frontendu a změny ve struktuře budou viditelné okamžitě, nebo téměř okamžitě. Důležité aspekty uživatelského rozhraní:  Možnost používat přetahování (drag'n'drop) pro změnu layoutu stránek.  Možnost změnit strukturu libovolné části stránky – obsah nebo jeho umístění.  Administrační panel, plovoucí nad stránkou musí být přehledný a dobře organizovat administrátorské funkce.  Uživatel by měl být schopen měnit vzhled jednotlivých součástí stránky ale i celku.  Uživatel by měl mít možnost snadno aktivovat vypnuté funkce stránky či získat další, aktivovat, nakonfigurovat a umístit.

3.1.3 Hlavní rysy aplikace Důležité základní vlastnosti aplikace, které definují její chování jsou následující:  Struktura webové aplikace je flexibilní a upravitelná. → Rozmístění stránek, propojení mezi nimi a navigace lze nastavit libovolně. (V rámci navržené struktury.)  Struktura jednotlivých stránek je flexibilní a upravitelná. → Lze vytvořit mnoho druhů stránek s různým rozmístěním obsahu, vzhledem či použitými komponenty nebo přístupovými právy. Tato rozmístění lze kombinovat a znovupoužívat.  Aplikace umí vytvářet různé druhy obsahu (články, statické stránky, blog, komentáře, apod.). → Aby též plnina funkci CMS, měla by aplikace ve výsledné formě být schopna vytvářet a organizovat různé druhy obsahu a to včetně příloh a multimédií. 22

 Aplikaci lze rozšířit na mnoha úrovních (komponenty, pluginy, šablony). → Aplikaci lze rozšířit vlastním vzhledem, business vrtvou či vykreslitelnou komponentou. (Rozšířitelná architekrura.)  Aplikace umožňuje přihlášení více druhů uživatelů a zobrazovat jim pouze autorizovaný obsah.  Aplikace podporuje vícejazyčnost. Naopak nebude kladen důraz na popis a implementaci konkrétních dalších typů obsahu či rozšíření.

3.3 Analýza projektu V této části formalizuji funkční požadavky, nefunkční požadavky, pokusím se načtrtnout případy užití a vytvořím návrh datového modelu.

3.3.1 Funkční požadavky Funkční požadavky popisují požadovanou funkčnost aplikace a staví na bodech zmíněných v hlavních rysech aplikace. Pokusím se je rozdělit do několika kategorií. •

Správa struktury webových stránek 1. Možnost ovlivnit celou hierarchii sekcí a stránek. 2. Provázání hierarchie stránek pomocí vytvořitelných navigací. 3. Kategorizace obsahu pomocí typu a tagů. 4. Přidávání základního typu obsahu: články, statické stránky, komentáře, …

•

Správa vzhledu a rozložení na jednotlivých stránkách 1. Vzhled každé stránky lze změnit přímo na ní. 2. Jednotlivé elementy na stránce lze přesouvat, pozicovat, roztahovat, zúžovat apod. 3. Výsledná prezentace je validní a sémantická. 4. Elementy lze ostylovat z nainstalovaných schémat buď globálně nebo lokálně a poté styl editovat a uložit jako jiný. 5. Elementy lze zobrazovat na stránce podmínečně (lze využít jednoduchých podmínek či porovnání)

•

Uživatelské možnosti 1. Systém podporuje nastavení správy uživatelů (typ registrace, práva uživatelů) 2. Uživatelské role lze použít pro omezování libovolných elementů stránky či sekcí.

3.3.2 Nefunkční požadavky Nefunkční požadavky vymezují chování systému a prostředí, ve kterém běží. 23

•

Výsledná prezentace bude responzivní na uživatelské akce. → Maximální čas od poslední identifikace stavu by neměl být větší než 3 vteřiny.

•

Bezpečnost → Odolnost proti známým metodám útoků.

•

Databáze → Systém bude používat databázi MySQL v aktuální páté verzi.

•

Server → Systém bude běžet na serveru Apache s PHP verze 5.4 s nejnovější aktualizací

•

Multijazyčnost → Systém umožňuje uchovávat co největší část obsahu ve vícejazyčné podobě

•

Rozšířitelnost → Systém umožňuje přes API doprogramovat do aplikace komponenty, které rozšiřují možnosti systému

3.3.3 Případy užití Pro zpracování případů užití je nejprve nutné definovat aktéry v systému. Aplikace Freeform CMS má podporovat vlastní vytváření uživatelských rolí a správy, není tedy uplně nezbytné se snažit zachytit všechny možné vztahy mezi aktéry. Jejich struktura bude známa z ACL a obecně bude platit, že uživatel může provést takovou akci, případ užití či jeho podmnožinu, na kterou bude mít dostatečné oprávnění.

Obr. 9. Základní aktéři systému Na Obr. 9 jsou vypsáni jednotliví aktéři systému. Nejširší okruh akcí zabere administrátor systému, jako správce stránek a budou se ho týkat nejdůležitější use-case v tomto systému. Editor systému pak je předpřipravená role pro uživatele, kteří budou mít též možnost spravovat obsah 24

webu. Celkově jsou však role spíše orientační, neb by systém měl umožňovat jejich vytváření podle potřeby. 3.3.3.1 Správa struktury webových stránek Zde jsou zachyceny případy užití týkající se vytváření a měnění struktury webových stránek. Rozhraní by mělo mít možnost většinu akcí týkajících se modifikace obsahu zobrazovat na více různých místech (např. editaci článku článku lze provést přímo v článku na webu nebo v administračním okně s výpisem článků), mnoho uvedených případů užití tedy může být pouze jakousi základní množinou operací, které se pak vzájemně setkávají a propojují. •

Vytvoření nové sekce (stránky) 1. Tato akce se provádí pouze z administračního panelu ze sekce věnované správě sekcí. 2. Uživatel klikne na vytvoření nové sekce. 3. Systém vytvoří nové okno (nebo použije stávající okno) s nastavením sekce. 4. Uživatel vyplňí informace o nastavení a obsahu a sekci uloží. 5. Uživatel může změnit pozici sekce v hierarchii sekcí přetahováním ve stromu sekcí.

•

Upravení sekce (tedy upravení stránky) 1. Aplikace poskytne seznam se strukturou sekcí a uživatel vybere sekci, kterou chce editovat NEBO uživatel přejde na stránku přímo v prezentaci a klikne na úpravu stránky. 1. Aplikace otevře okno s nastavením (nebo se použije stávající okno). 2. Uživatel provede změny a uloží.

•

Přidávání obsahu 1. Uživatel v administračním panelu v sekci věnované správě obsahu vybere volbu přidat obsah a aplikace poskytne seznam typů obsahu, které jsou momentálně používány NEBO uživatel přejde na stránku a nalezne možnost přidání konkrétního obsahu u elementu, který jej vykresluje. 2. Aplikace otevře okno s nastavením obsahu. 3. Uživatel vyplní základní data obsahu a obsah samotný může eventuálně dopsat přímo v elementu, který jej vykresluje (pokud takový element existuje).

•

Kategorizace obsahu 1. Uživatel vybere obsah 2. V nastavení obsahu přiřadí již vytvořené tagy nebo vytvoří nový a uloží obsah NEBO 1. Uživatel použije nástroj pro správu tagů a přetáhne tagy na obsah ve strukturovaném seznamu. Pozn.: Panel s tagy by měl být udělaný tak, aby šel použít ve spolupráci s ostatními administračními panely.

25

•

Přidání komentáře k obsahu 1. Uživatel použije blok pro přidání komentáře na stránce, která takový blok obsahuje, pokud k tomu je uživatel autorizovaný.

3.3.3.2 Správa vzhledu a rozložení na jednotlivých stránkách •

Změna celého rozložení stránky 1. Uživatel zapne okno s nastavením sekcí. Pro každou sekci může vybrat jakékoliv dostupné rozložení stránek.

•

Změna motivu stránky, tedy grafického vzhledu 1. Uživatel zapne okno s nastavením sekcí. Pro každou sekci může vybrat jakýkoliv dostupný motiv. NEBO 1. Uživatel zapne okno s nastavením motivů, kde si v seznamu motivů může prohlédnout případné náhledy. NEBO 1. Uživatel též může vybrat vzhled konkrétního bloku na stránce.

•

Změna pozice a velikosti bloku na stránce – editace struktury elementů 1. Uživatel zapne okno s nastavením rozložení, které obsahuje strom hlavních elementů stránky. 2. Uživatel aktivuje možnost označení elementu (zapne zvýrazňování všech elementů na stránce). 3. Uživatel najede na element a kliknutím ho označí. 4. Systém nabídne menu pro práci s elementem. 5. Uživatel aktivuje dotyčnou funkci, a pak pomocí táhnutí za okraj změní velikost, pozici či odsazení a nebo přetáhne element na jinou pozici (závisí na druhu elementu).

•

Vytvoření bloku na stránku dle správné sémantiky. 1. Uživatel z administračního nástroje vybere nový element z palety elementů, která bude ikonkou a popiskem značit, o jaký typ elementu se jedná. 2. Uživatel nastaví parametry a obsah nově vytvořeného elementu na stránce. Parametry se řeší v okně nastavení, textové obsahy lze editovat přímo uvnitř elementu. Pro textový obsah bude, v případě, že to bude možné realizovat, k dispozici šablonovací jazyk.

•

Změna vzhledu elementu 1. Uživatel může v nastavení elementu nebo přes pomocné ikonky okolo označení elementu nastavit některé parametry vzhledu – vybrané vlastnosti z kaskádových stylů. 2. Uživatel potvrdí provedené změny a nový vzhled se uloží.

•

Nastavení viditelnosti elementu 26

1. Uživatel může v nastavení elementu vybrat uživatelské role, pro které je element viditelný nebo může také použít podmínku pro zobrazení. Ta se zadá do pole jako logický výraz nebo bude realizována vizuálně.

3.3.3.3 Uživatelské možnosti •

Přihlášení do systému pro běžného uživatele Probíhá přes standardní přihlašovací formulář.

•

Vytvoření a editace uživatelů 1. Uživatel otevře panel se správou uživatelů. Tam může v seznamu uživatelů nějáké upravit či jinak administrovat (zaslat mail s novym heslem apod.) nebo může vytvořit nového uživatele jednoduchým formulářem. 2. Systém vytvoří nebo upraví uživatele a dle nastavení dialogu zašle email s informací či provede jinou akci.

•

Vytváření a editace rolí 1. Uživatel použije panel s uživatelskými rolemi. Tam může role zobrazit a upravit. V úpravě role má k dispozici seznam sekcí, bloků a akcí, které může pro danou roli povolit.

27

3.3.4 Model tříd Model tříd dává dobrý vhled do vnitřní struktury aplikace zachycením všech hlavních entit a popisem vztahů mezi nimi. Na obrázku 10 je zachycena jeho struktura.

Obr. 10. Model tříd. Některé vazby jsou z modelu vynechány, protože by pak byl velice nepřehledný, a ty jsou následující: •

Uživatel (User) má vazbu na téměř všechny ostatní položky, které lze měnit či vytvářet: 28

Section, Menu, MenuItem, Layout, Element, Content, ContentType, Tag, Asset, Theme, Style. Každá z těchto položek bude obsahovat odkaz na uživatele který ji vytvořil, datum vytvoření, odkaz na uživatele který ji naposledy změnil a datum poslední změny. Nabízí se též možnost tato data vložit do samostatné tabulky, která by mohla monitorovat i starší přístupy. Problém ale není prioritní. •

Původní myšlenka byla připojit Theme i na Layout, a Element, aby Layout, symbolizující jedno rozmístění elementů měl i definovaný motiv a v této kombinaci sloužil jako ucelená část prezentace. Motiv celého Layoutu by pak byl snadno jednotně zaměnitelný ze sekce a v případě potřeby použít jiný motiv pro dílčí části by bylo možné přiřazovat styly i konkrétním elementům. Avšak, jak se nakonec ukázalo i na dalších jiných místech návrhu, je to výrazně složitější na implementaci.

•

CustomField obsahuje údaje, které bude moci použít též mnoho entit, určitě pak Element a Content. Význam políčka viz níže.

Nyní stručně popíši jednotlivé třídy rozdělené do okruhů funkcionality. 3.3.4.1 Uživatelé a role •

User: Uživatel aplikace. Obsahuje autentizační údaje a základní data. Další údaje o něm se ukládají do UserData.

•

UserData: Údaj o uživateli. Skládá se ze jména údaje, hodnoty a typu. Takto lze u uživatelů povolit ukládat více různých informací (např. kontakt, zájmy, apod.).

•

Role: Uživatelská role. Atribut level značí ohodnocení role, priority se pak používá pro výběr role při konfliktu.

•

Resource: Zdroj. Označuje libovolnou instanci libovolného objektu. Atribut table definuje název zdroje (tabulka) a atribut key značí instanci (řádek tabulky). Pokud se však zdroj nevztahuje k řádku tabulky, lze použít name a namespace. Případy rozlišuje type.

3.3.4.2 Sekce •

Section: Sekce označuje stránku či skupinu stránek (tedy zpravidla jednu stránku, nebo více v případě stránky s článkem – různé články standardně obsluhuje jedna sekce). Nemusí však nutně zobrazovat jeden layout. V poli params obsahuje také data všech cílů sekce (cíl může použít jiný layout, data hlavicky apod.). Cíl je volem retezcem z URL a byl zaveden v pozdější fázi aby kompenzoval nemožnost užití více stránek pro podobně začínající URL. (Vysvětlení: Kategorie a články. URL pro kategorie je ve tvaru /cesta/[cislostranky] a pro článek /cesta/nazevclanku.html, kde cesta může být i více řetězců s lomítkem. Tyto URL mají společnou velkou část adresy a liší se jen koncem, což v běžné aplikaci vyřeší router, který postupně testuje všechny routy (ve správném pořadí), dokud nějaká nevyhovuje. V této aplikaci ale výsledné sestavení stránky probíhá na základě různých parametrů v URL, což řešení problému znemožňuje. Proto byl do návrhu přidán „cíl“ jako nepovinný parametr za tečkou, aby URL se stejným začátkem mohlo obsloužit více obsluh. Cíl je také nezávislý na množství parametrů před ním.)

3.3.4.3 Menu •

Menu: Menu. 29

•

MenuItems: Položky menu, obsahují vedle různých textových informací také přiřazenou sekci, kterou můžou vyvolávat, a to i s (možná zbytečnými) různými parametry (lze tak vytvořit odkaz na konkrétní článek či na editaci uživatele).

3.3.4.4 Layout a Elementy •

Layout: Rozložení elementů na stránce. Lze vytvářet v administraci a používá ho sekce. Layout lze použít ve více sekcích naráz. Layouty lze též dědit, a to následujícím způsobem: Dědící layout definuje rodiče a rodič mezi svými elementy definuje element (nebo více), které mohou být zděděny. Při sestavování stylu pak program sestavuje nejprve rodičovský layout a pokud přitom narazí na element, který je poděděný, nahradí ho a element a jeho potomky čerpá z dědícího Layoutu.

•

Element: Element je základní stavební kámen stránky. Je uložen ve stromové struktuře s ostatními elementy, a když se s ostatními správně vykreslí, vznikne DOM. Takové vykreslení je samozřejmě operace, která se musí cachovat. Element může využívat služeb od komponent, což jsou definované objekty, přes které lze získat data z komponentových modelů. Typy elementů víceméně odrážejí nejdůležitější elementy z HTML5 (jak bylo zmíněno v 3.1.1 Možnosti použití HTML5 elementů při vytváření struktur stránek), avšak strom neobsahuje všechny elementy, nýbrž jen ty co drží hlavní strukturu, nebo vyžadují speciální nastavení. O vykreslení elementů se mohou starat speciální třídy přizpůsobené vlastnostem konkrétního případu. U elementu se skrývá mnoho situací a stavů, které nemají jasně stanovený průběh, a pro získání dobrého povědomí bude třeba vlastnosti vyzkoušet. Jedná se např. o způsob editace vnitřku s ohledem na další elementy uvnitř, způsob vkládání elementu a výběru jeho pozice, nebo způsob přesouvání elementů. Všechny operace jednak mohou narušit validitu a sémantiku dokumentu, ale také vytvořit nový nečekaný stav.

3.3.4.5 Styly a themes •

Theme: Označuje celý soubor stylů. Lze vytvářet a ukládat. Nastavuje se pro sekci.

•

Style: Styl se váže na selektor (z kaskádových stylů) a je to soubor vlastností a hodnot. Přestože se jeho hodnota váže na Element, propojení probíhá přes selektorový zápis, a není tedy potřeba vytvářet vazby v databázi. (Původně měla databáze obsahovat i každý řádek přiřazení hodnoty vlastnosti.)

3.3.4.6 Obsah •

Content: Jednotka obsahu. Přestože je možné vkládat text přímo do elementů, takové řešení slouží k vytvoření prostředí a layoutu. Samotný obsah stránek se strukturovaný v těchto záznamech. Dle typu obsahu může Content být např. statická stránka, článek, blogový příspěvek nebo komentář.

•

Tag: Značka pro obsah. Obsah lze označit více značkami. Značky slouží pro kategorizaci obsahu a lze je strukturovat. Atribut type pak může posloužit pro použití tagu jako kategorie.

•

ContentType: Typ obsahu, na rozdíl od značky značí popisuje Content nikoliv z hlediska obsahu samotného, ale jeho typu. Počáteční typy mohou být: Statická stránka, článek, komentář. 30

•

Asset: Příloha slouží primárně k přiložení souboru k příspěvku.

3.3.4.7 Zbylé třídy •

Service: Služba se vytváří při vytváření Layoutu nebo Contentu v případě potřeby získání dat z nějakého modelu. Slouží tedy jako fasáda a její metody, vracející data pro čtení, lze použít v textu pomocí zástupných symbolů, uvozených procenty, nebo jinými pomocnými znaky. (např. %Article(47).name%, Article je fasáda pro Content s typem články, číslo v závorce vybere konkrétní kus a name za tečkou pouze jméno článku)

•

CustomField: V modelu osaměle vypadající vlastní pole je záznam sloužící pro ukládání různých krátkých hodnot. Aplikace v něm bude mít většinu proměnných z nastavení, ale bude možné tam taktéž uložit údaje, které potřebujeme na stránkách opakovat, ale pokud možno měnit pouze na jednom místě. Vlastní pole je pak dostupné z elementu i z obsahu přes službu (např. %CustomField(uvodnicitat)%) a funguje jako nejzákladnější nosič stejného obsahu napříč sekcemi.

3.4 Technologie k realizaci projektu Zde proberu vybrané technologie k realizaci práce a důvod k jejich výběru.

3.4.1 PHP Volím programovací jazyk PHP. I přes své nedostatky je to ve výsledku flexibilní jazyk s velice dostupnými cenami hostingů. Ve verzi 5.4 jazyk podporuje stále více atraktivnějších konstruktů z jiných jazyků a možná se v práci podaří některé z nich upotřebit (např. traits). Navíc konečně odstraňuje některé archaické bezpečnostní díry (register_globals).

3.4.2 MySQL Databáze je důležitou součástí aplikace. MySQL již dávno není amatérská databáze a při použití enginu InnoDB podporuje i cizí klíče a transakce, které jsou pro složitější aplikaci nutností.

3.4.3 Nette framework Samotný programovací jazyk je těžkopádný bez použití frameworku – ten implementuje větší množinu často potřebných funkcí a jeho volba pro aplikaci je důležitá. Nette framework si osvojil myšlenky DRY, KISS, podporuje SEO, AJAX, MVP a je velice výkonný ([4], test je ale hodně starý. Aktuální test jsem bohužel nenašel.). Podporuje objektové programování a umožňuje používat objekty s rozšířenými možnostmi z hlediska programovacího jazyka. Taktéž klade důraz na bezpečnost a automaticky ošetřuje vstupy proti hrozbám (XSS, CSRF). Mezi další pozitivní vlastnosti patří robustní šablonovací jazyk, inteligentně řešené obousměrné routování, kvalitní Dependency Injection a správa kontextového kontejneru. V neposlední řadě framework disponuje vlastní knihovnou pro přístup k databázi, která vychází z NotORM od Jakuba Vrány a měla by být též velice výkonná [5], ačkoliv programování s ní ukázalo určité nedostatky (nelze pomocí fluent skládání dotazu získat výsledek s LEFT JOIN). Framework také disponuje schopnými nástroji pro cachování dat a schopným komponentovým modelem, díky kterému lze na presenteru postavit hierarchickou strukturu různých druhů vykreslitelných komponent, což se upotřebí při vykreslování stromu elementů, ale i při 31

sestavování administrátorského rozhraní. Framework dále nativně pracuje s AJAX požadavky, při kterých dokáže odesílat pouze změněné části stránky.

3.4.4 JQuery Dle zadání je třeba vytvořit komplexní uživatelské rozhraní na straně klienta. Javascriptová knihovna JQuery tvorbu takového rozhraní značně zjednoduší. Zapouzdřuje rozdíly mezi prohlížeči a přidává mnoho užitečných konstruktů.

3.4.5 Shrnutí a diskuze Jazyk PHP je z hlediska webu nejvhodnější pro vznik malých projektů (resp. projektů vzniklých na malém zázemí), protože je nejdostupnější a nejlevnější. Volba alternativ (Java, Python, Ruby) by nedávala smysl, aplikace by nebyla tolik přenositelná a možnosti by byly podobné. Nutno dodat, že větší frameworky ostatních jazyků často přistupují k webových prvkům jako k hotové kapitole, nabízejí vlastní hotové komponenty pro elementy. Já však potřebuji tento systém nadefinovat jinak. Použití databáze není tolik omezující, protože v případě nutnosti jiného databázového stroje není problém vyměnit přístupovou vrstvu v aplikaci. Výběr serverového frameworku je lehce ovlivněn jeho českým původem, ale primárně jeho přístupem a možnostmi, kdy sází na výkon [4] a robustní rozšířitelnost. Alternativou by mohl být framework Symphony či CakePHP. Framework JQuery byl vybrán hlavně kvůli dobrým zkušenostem z užívání a veliké základně dokumentace a pluginů. Celý projekt pak je spravován vývojovým prostředím NetBeans, které dobře integruje jak jazyk PHP, tak framework Nette, ale i ostatní webové technologie (kaskádové styly, javascript, ve verzi 7.3 i nově HTML5…).

3.5 Architektonický návrh V této části se pokusím propojit zvolené technické zázemí s požadavky aplikace a tedy nastínit implementaci aplikace s pomocí zvolených technologií. Nejprve se zaměřím na databázový model a poté na některé okruhy aplikace ve spojení s frameworkem.

3.5.1 Databázový model Databázový model vychází přímo z modelu tříd a obsahuje ještě další rozšíření. Je možné, že se v průběhu vývoje pozmění, aby lépe reflektoval požadavky aplikace. Mezi jeho důležité aspekty patří následující: •

Tabulky využívají jak vlastní klíče tak cizí klíče. Primární klíč má tvar id_, což se zatím ukázalo být spíše zbytečné. V kontextu tabulky by bohatě stačil název id.

•

Vícejazyčnost bude implementována přímo v databázi za pomocí dodatečných jazykových tabulek, které fungují jednoduše: Každá taková tabulka obsahuje identifikátor řádku, identifikátor jazyku a název sloupce a následně jeho překlad. Lze tak přidávat libovolně jazykových polí.

•

Údaj o autorovi dané entity bude nutná součást téměř každé tabulky. Jak již bylo 32

zmíněno v 3.3.4 Model tříd, tyto údaje zřejmě budou součástí všech tabulek, kterých se to týká. •

Atribut params obsahuje konfigurační data pro programové prvky uložené ve formátu JSON, protože to je jednoduchý přehledný textový formát. Tato praktika možná porušuje první normální formu, nicméně serializovaná data se nevztahují ke zbytku dat v databázi a neměla by vůbec být v SQL používaná.

3.5.2 Architektura skrze Nette framework Nette framework staví na návrhovém vzoru MVP, což je velice podobné principu MVC [7]. Aplikace se tak dělí na vrstvu modelu, která obsahuje business logiku a stav aplikace, vrstvu presenteru, která zpracovává vstup a řídí tok dat a vrstvu view, která zobrazuje uživateli data a ovládání aplikace. Nicméně to je pouze teoretický nástin toho, jak by to mělo fungovat. Praxe ukazuje, že je to pouze dobrý způsob, jakým se při vývoji aplikace řídit, nikoliv ho brát jako dogma a tedy ho pak nešikovně aplikovat i na části aplikace, kam se nehodí. Nette framework dále pracuje s komponenty či jejich konkrétnějším případem ovládácí prvky (Control), které jsou na rozdíl od komponenty vykreslitelné. Mezi takovou komponentu patří mimochodem i Presenter. Framework je pak řízen třídou Application, která zpracovává průběh webové aplikace a používá velkou knihovnu dalších tříd pro splnění svého cíle. Za zmínku stojí robustní kontextový kontejner, který dokáže dynamicky načítat různé služby a třídy pro aplikaci. Důležitá součást (a pýcha) frameworku je též Router, který směřuje požadavky. V nejstandardnějším případě se na začátku aplikace dle sepsaných rout vybere presenter a ten se pak postará o výběr akce či signálu k provedení a o vykreslení správné šablony [3]. Tento postup však pro aplikaci Freeform není vhodný, protože její síla spočívá v tom, že obsah není

Obr. 11. Activity diagram zachycující cyklus základní aplikace v Nette 33

pevně daný. Je otázkou, zda-li vestavěný systém akcí neadaptovat pro aplikaci, či ho pozměnit, aby lépe vyhovoval potřebám aplikace. Zvolím ale druhou možnost a s akcemi budu zacházet jako se seznamem parametrů pro komponenty na stránce. Obrázek 11 jednoduše popisuje cyklus aplikace v Nette. Díky použití pouze jedné routy, není potřeba tento cyklus příliš měnit a lze sestavení stránky provést pouze v presenteru, jehož životní cyklus [6] se lehce pozmění. Bude pouze jeden a nebude pro vykreslování stromu potřebovat akce (v kombinaci s různými pohledy), protože jednotlivé pohledy jsou uloženy právě v různých layoutech. 3.5.2.1 Sestavení prezentační stránky

Obr. 12. Proces sestavení stránky v hlavním presenteru Na obrázku 12 je znázorněn proces sestavování stránky, který se odehrává v hlavním presenteru. Je z něj patrná posloupnost získávání dat z jednotlivých objektů. 3.5.2.2 Sestavení editační stránky Editační stránka má URL shodnou s prezentační stránkou, akorát začíná řetězcem admin/. Proces sestavení stránky pak probíhá identicky jako v čistě prezentační sekci a pouze přibude administrační panel a jeho ovládání. Administrační panel pro své části využívá komponenty a jejich šablony a komponenty pro vykonávání akcí používají signály, neboli subrequesty, což jsou požadavky v rámci jednoho pohledu v presenteru – což se přímo hodí pro strukturu této aplikace.

34

4 Implementace V této části se budu věnovat metodám implementace návrhu, iterace a vzniklým úskalím.

4.1 Utilizace PHP 5.4 v architektuře Použití PHP 5.4 přineslo zejména dvě hlavní výhody, jednak použití trait [41] a také dereferencování polí [34]. Druhá vlastnost ušetří množství kódu, a též vytváření pomocných proměnných. Horizontální dědičnost se (dle [35]) doporučuje použít zejména při používání rozhraní, které ale má pro všechny třídy, které jej implementují, stejnou implementaci. Rozhodl jsem se proto inspirovat se článkem Davida Grudla [36] a vyzkoušet používání anotací na značení vstřikování závislosti, přičemž implementace tohoto mechanizmu byla vložena právě do traity (pojmenované TPropertyInjection). Díky tomu pokud nějaká komponenta, model nebo presenter potřebuje získat závislosti, nemusí se o ně starat, ale traita se zaregistrovaným ModelLoaderem případné závislosti doplní v konstruktoru.

4.1.1 Traita TPropertyInjection, ModelLoader, DefaultModel, Entity Používání anotací v modelu je velmi běžné např. v Enterprise Javě, kde sice třídy, starající se o business vrstvu (nazývané Beany), jsou POJO, ale používají mnoho druhů anotací pro propojení s perzistentní vrstvou. Usoudil jsem tedy, že pro aplikaci, která bude vyžadovat mnoho různých modelových tříd, entit a pak komponent, které je používají, by bylo dobré mít jednoduchý systém jejich používání. Zavedl jsem tedy nejprve anotaci @inject a poté i @entity a @collection. Tyto anotace jsou uzpůsobeny na použití s třídami entit a modelů. Třída, která se rozhodne použít tuto metodu musí traitu použít pomocí klauzule use a dále je je potřeba ji se třídou propojit na třech místech – v konstruktoru je třeba traitu inicializovat, aby se postarala o anotované proměnné, a pak je ještě potřeba přetížit magické metody __get a __set. 4.1.1.1 TPropertyInjection Funguje tak, že její metoda TPI_setup, která se spouští v konstruktorech tříd, které ji používají, prozkoumá všechny anotace proměnných a pokusí se v některých vyhledat klíčová slova @inject, @entity a @collection (pozn. kolekce nakonec nebyla v kódu použita ve prospěch jiných metod) a v případě nálezu si ve třídě vytvoří interní pole s těmito hodnotami a taktéž se pokusí závislost načíst. V rámci toho pak použije metodu unset na veřejnou proměnnou, která tím pádem přestane existovat, a jakýkoliv pokus takovou proměnnou získat jde přes metodu __get, která metodu vrátí a jakýkoliv pokus proměnnou nastavit jde přes metodu __set, která vyhodí výjimku. Anotace @inject vkládá třídu modelu, který se stará o data týkající se převážně jedné entity, a pozná název vkládané třídy z anotace @var, přičemž se pokusí danou třídu modelu nahrát přes ModelLoader. Anotace @entity značí objekt jiné entity a je následována ještě řetězcem, který značí jméno cizího klíče (ve stejné entitě – tabulce), který v tabulce značí odkaz na danou další tabulku. Třída vkládané entity je též v anotaci @var. Tato anotace se velice hodí v objektech, které mají rodiče nebo jinou závislost. A nakonec anotace @collection slouží k načtení více prvků entity, přičemž následující řetězec značí cizí klíč ve vkládané entitě, tedy její závislost. Výsledkem je načtení všech prvků, které cizím klíčem odkazují na danou entitu. Nutno dodat, že zatímco @inject funguje kdekoliv, zatímco @entity a @collection jsou koncipované do entit a o jejich obsluhu se stará třída DefaultModel, resp. její potomci. 35

/** * layout model * @var \core\Model\Mappers\Layout * @inject */ public $layoutModel;

Ukázka kódu 1. Způsob získání přístupu k modelu Ukázka 1 zobrazuje, jak ve třídě, která užívá injekci, inicializovat objekt pro přístup k datům. /** * layout sekce * @var \core\Model\Entities\Layout * @entity id_layout */ public $layout;

Ukázka kódu 2. Automatické načítání závislostí Ukázka 2 je ze třídy entity a ukazuje automatické načítání souvisejících entit. Příslušné entitě se načte entita Layout podle klíče z pole id_layout. 4.1.1.2 ModelLoader Je třída, která se stará o načítání tříd modelů, potomků třídy DefaultModel. Je uložena v DI kontejneru, ale hlavní místo má v TPropertyInjection, odkud načítá vstříknuté modely. Zároveň funguje jako unikátní a též singletonový (jako každá služba v DI kontejneru) nosič všech instancí modelů, které načítá, až když je po nich poptávka (Lazy Loading). 4.1.1.3 DefaultModel Je abstraktní verze modelové třídy, která je koncipována tak, aby konkrétní implementaci modelu poskytovala co největší množinu připravených funkcí pro získávání dat, které předepisuje interface core\Model\IDataMapper. Dědící třídy tak pouze obsahují výčty databázových parametrů a pak modelové operace čistě jim charakteristické (například sekce nebo layout jsou více rozšířené). Primární účel je vracet Entity objektů se všemi náležitostmi. Platí, že každá entita má svůj model, který se stará o její načítání, inicializaci a ukládání. DefaultModel zapouzdřuje všechny základní dotazy nad databází (resp. nad \Nette\Database) a též dokáže volitelně registrovat entity mezi aktivní zdroje (což vzhledem k různé povaze zdrojů může mít různé implementace v potomcích). 4.1.1.4 Entity Entita reprezentuje řádek tabulky, objekt z modelu. Dokáže pracovat s vlastními daty, která při vzniku zpracovává (např. zpracování JSON pole) a též se umí serializovat a unserializovat.

4.1.2 Úskalí používání traity TPropertyInjection Protože traita sama je závislá na instancích ModelLoader a Authorizator (který se stará o registraci zdrojů pro ACL a který potřebují instance DefaultModel), je nutné ji v celé aplikaci 36

inicializovat spolu s ostatními potřebnými instancemi jako první. Proto v aplikaci existuje služba, která se stará o inicializaci ve správném pořadí a která zároveň je ve formě rozšíření pro DI kontejner inicializována v kontejneru jako první, ještě před načtením úložiště session. Pokud se totiž nějaká třída používající tuto traitu dostane do běhu programu ještě předtím, nemá závislosti a pozdější inicializace traity již načtené třídě závislosti nedodá. Metody a atributy traity je též dobré pojmenovávat s unikátním prefixem, aby se žádné vlastnosti ani metody nepřepsaly. Prefix pro TpropertyInjection jsem zvolil TPI_.

4.2 Utilizace Nette frameworku Nette framework se při programování osvědčil a to zejména v následujících případech.

4.2.1 DI kontejner a služby Framework umožňuje konfiguraci kontejneru jednoduše přes konfigurační soubor ve formátu NEON [8]. php: date.timezone: Europe/Prague session.save_path: "%tempDir%/sessions" zlib.output_compression: yes nette: application: errorPresenter: "Error" catchExceptions: false session: autoStart: smart database: default: options: [PDO::MYSQL_ATTR_COMPRESS = true] debugger: true explain: true reflection: discovered user: core\Security\User # nahrazení Nette třídy vlastní třídou services: database: @nette.database.default authorizator: core\Security\Authorizator modelLoader: core\Model\ModelLoader (@database, @authorizator) traitsInitializer: class: core\Model\TraitsInitializer setup: - initAuthorizator (@authorizator) - initModelLoader (@modelLoader) authenticator: class: core\Security\Authenticator(@modelLoader::getModel('User')) themeCacheStorage: class: core\Caching\Storages\ThemeFileStorage(%CSS_DIR%) autowired: no

Ukázka kódu 3. Výběr z konfiguračního souboru 37

Ukázka 3 zachycuje část konfiguračního souboru. Jsou zde části konfigurující samotné PHP, Nette framework a pak vlastní služby. Nette třída Configurator z tohoto zápisu vygeneruje kontejner s továrnami na služby a načítání služeb probíhá až v případě potřeby. To vyžaduje dobré promyšlení vzájemných závislostí. Služba traitsInitializer je např. poprvé použita přímo v samotné inicializační metodě kontejneru (kam se dostala díky rozšíření kontejneru, viz ukázka kódu 4). V tu chvíli se služba vytvoří a pak dle konfigurace volá metody pro inicializaci dvou závislostí, které se předají jako parametr, a tím pádem musí být také vytvořeny, čímž se docílí správného pořadí načítání. $configurator->onCompile[] = function ($configurator, $compiler) { $compiler->addExtension('FreeForm', new core\Config\Extensions\FreeFormExtension()); };

Ukázka kódu 4. Registrace rozšíření DI kontejneru Mezi další významné služby patří především třídy Authenticator a Authorizator, implementující stejnojmenná rozhraní. Ty se starají dle názvu o autentizaci a autorizaci uživatele. Authorizator svoji funkci ACL implementuje přes navrženou datovou strukturu a jako jediná třída používá databázi sama o sobě bez použití modelové vrstvy. Důvod je ten, že data s autorizací související nemají vůbec nic společného s entitou a jedná se o spojení několika tabulek s přejmenováváním sloupců apod. Používání entit by bylo naprosto zbytečné a zpomalující. Za zmínku stojí fakt, že přestože Authorizator používá službu pro přístup k databázi, není potřeba mu jí v konfiguračním souboru explicitně předat, protože konfigurátor se o to sám postará – zjistí jaký typ objektu je potřeba a nalezne ho podle jména třídy. Toto ovšem nelze aplikovat v případě více služeb se stejnou třídou (proto je služba speciální cache pro css soubory inicializovaná bez používání autowiringu1). Authorizator vyhodnocuje přístupová práva tak, že si nejprve načte všechna nastavení práv pro dané role a to včetně souvisejících zdrojů. Následně data zpracuje, zaregistruje všechny zdroje, zaregistruje role a načtená pravidla. Jeden uživatel může mít více rolí a proto mají role priority, přičemž platí, že role s vyšší prioritou má větší váhu než role s nižší prioritou. A tedy i pravidlo pro roli s nízkou prioritou podlehne pravidlu pro roli s vyšší prioritou. Pravidlo sestává z role, zdroje a typů oprávnění, které jsou povolené. Také existují speciální role, zdroje a oprávnění, které značí všechny objekty z dotyčné kategorie, a ty lze použít pro definici globálnějších pravidel. Takové pravidlo například může být, že všechny role mají povolenou akci read na prezentační části stránek. Zdrojů může být mnoho a když jsou identifikovány jménem a jmenným prostorem, lze v nich vytvářet hierarchii, kdy zdroj se jménem Layout a jmenným prostorem Admin:Windows, je potomkem zdroje se jménem Windows a jmenným prostorem Admin. To se následně využívá při zjišťování pověření – pokud totiž nelze dohledat pravidlo, protože neexistuje (neexistuje tak ani registrovaný zdroj), Authorizator zkontroluje zda-li není nastavené pravidlo alespoň pro jeho předka. Authenticator je implementace rozhraní, které presenter používá v metodě login. Její účel je ověřit uživatelské jméno a heslo a v případě správných údajů přihlásit uživatele, tedy vytvořit instanci třídy Identity a uložit ji do session úložiště. V této aplikaci jsou data uživatele též entita a tak byla třída Identity upravena tak, aby entitu mohla poskytnout. K ověřování hesla se používá sůl2, která se spojí s heslem a výsledný řetězec se teprve zahashuje a uloží. Tím se značně 1 2

Autowiring je název pro zmíněné automatické předávání závislostí podle typu parametru v konstruktoru. Náhodně generovaný řetězec pro každé heslo.

38

zkomplikuje útok na více hesel [37]. Jako hashovací funkce se používá crypt, která použije vestavěný nebo systémový hashovací algoritmus. Entita s uživatelem též předá Identitě uživatelské role, které jsou vitální pro zobrazování částí stránek. Standardní role je guest.

4.2.2 Komponenty Pro aplikaci vzniklo mnoho komponent, které všechny využívají komponentové možnosti frameworku. •

Komponenty pro sestavení stránky – starají se o vykreslení stromu elementů.

•

Komponenty pro ovládání administračního rozhraní – vykreslují administrační okna a řídí kontrolní akce.

•

Formuláře – v Nette nemusí být nutně komponenta, ale při užívání komponentového modelu se s nimi jako s komponentami zachází daleko lépe, resp. jako s ostatními vykreslitelnými prvky.

4.2.3 Přizpůsobení frameworku Framework Nette je z velké části koncipovaný tak, že vedle své kostry má ještě mnoho tříd, které implementují nějakou funkcionalitu základním způsobem a je na programátorovi, aby si dané třídy případně přizpůsobil. Zde došlo na třídy Identity a Presenter (ale bývá to i např. Application, User, Form, či Template). Nutno podotknout, že základní implementace je funkční a použitelná. Tyto třídy jsou obvykle ukázkovými implementacemi rozhraní, se kterými framework pracuje. Nicméně při potřebě aplikaci lépe uzpůsobit dojde na přepisování či rozšiřování těchto tříd. Vzhledem k charakteristice routování v aplikaci, kdy místo obvyklých povinných parametrů z URL (kterými jsou presenter a akce, tedy view) pracuji s dalšími šesti parametry, bylo potřeba upravit metody vytváření odkazů. Ty se používají pro generování odkazů a jejich práce se řídí nastavením rout a parametry. Bylo potřeba zajistit, aby vždy obsahovaly celou část URL. Další vhodný způsob změny chování Frameworku je extenze pro konfigurátor (zmíněná dříve). Ta dokáže ovlivnit tvar výsledného vygenerovaného kontejneru. FreeForm extension je jednoduchá extenze, která zasahuje do konfigurátoru po jeho kompilaci a upravuje jeho inicializační metodu. class FreeFormExtension extends \Nette\Config\CompilerExtension { public function afterCompile(\Nette\Utils\PhpGenerator\ClassType $class) { $methodInitialize = $class->methods['initialize']; $content = $methodInitialize->body; $methodInitialize->setBody('$this->traitsInitializer ->initPropertyInjection();'.PHP_EOL); $methodInitialize->addBody($content); $methodInitialize->addBody('$this->authorizator->setRoles($this->user ->getRoles());'); $methodInitialize->addBody('$this->authorizator->init();'); } }

Ukázka kódu 5. Třída FreeFormExtension.

39

4.3 Způsob organizace kódu V aplikaci využívám adresářovou strukturu Nette [40], v jejíž složce app koření v adresáři core jádro aplikace, tedy sada knihoven, které pohání aplikaci. Adresářová struktura jádra kopíruje jmenné prostory obsažených souborů3 a je členěna tématicky podobně jako složka s knihovnou Nette. Složky uvnitř adresáře core jsou následující.

4.3.1 Caching Kopíruje strukturu Nette\Caching a obsahuje třídu ThemeCache, která pozměňuje viditelnost klíče cache a v podadresáři Storages třídu ThemeFileStorage, která oproti FileStorage neskrývá název souboru s cache.

4.3.2 Config Kopíruje Nette\Config a obsahuje v podadresáři Extensions třídu (zmíněnou o pár řádků výše) FreeFormExtension.

4.3.3 Control Soubor tříd na ovládání editačního rozhraní. Obsahuje třídu DynamicPresenter, která se stará o sestavování stránek, třídu WindowControl, která slouží jako předek všech ovládacích oken a rozvržení šablony @WindowControl .latte, které používají šablony konkrétních oken. Dále jsou zde přítomné dvě třídy v raném rozpracovaném stádiu PanelControl a TableControl, z nichž ta první má sloužit jako předek tzv. panelů, vnitřních znovupoužitelných částí oken a druhá jako dynamická řaditelná tabulka. Dále je přítomna ještě BaseControl, která slouží jako předek všech ostatních komponent aplikace pro případ, že by bylo potřeba plošně rozšířit funkčnost komponent v aplikaci. Také všechny ostatní třídy zde jsou vykreslitelné komponenty4. V podadresáři WindowControls jsou pak třídy pro všechna administrační okna a jejich šablony (pohledy).

4.3.4 Layout Soubor tříd na vykreslování stromu elementů. Obsahuje rozhraní ITree pro předpis stromu (který umí vykreslit WindowControl, protože stromy jsou v ovládání aplikace minimálně dva – strom sekcí a strom elementů) a od něj dědící rozhraní ILayoutTree, které přidává metody pro vykreslení. Dále pak třídy:

3 4

•

Tree – datová struktura, která má svoje hodnoty uložené ve vícerozměrném poli, kde klíče jsou rodičovské prvky a hodnoty jsou pole jejich potomků. Tato struktura se snadno rekurzivně prochází.

•

Element – komponenta, která promění entitu s daty v HTML element. Obsah elementu je překládán Latte šablonovacím systémem a proto je možné vyjádřit vnořené elementy zápisem „{control element-2}“, kde číslo 2 je identifikátor entity elementu. Syntax vykreslí vnořenou komponentu se jménem „2“ v komponentě se jménem „element“. Když vykreslovací engine o tuto komponentu požádá, Element mu vrátí komponentu jménem ElementPool, která obsahuje všechny potřebné potomky na vykreslení. Každý

I když tedy tady mluvím o třídách WindowControl nebo ElementPool, v programu mají celé jméno core\Control\WindowControl nebo core\Layout\ElementPool. Zkrácenou verzi v textu používám kvůli přehlednosti textu. Vykreslitelná komponenta je potomek třídy Nette\Application\UI\Control.

40

Element tedy má vlastní ElementPool se svými dětskými Elementy. Element má odkaz na LayoutTree, který pro něj tuto kolekci vytváří. •

LayoutTree – komponenta, která vykreslí celý strom. Obsahuje všechna data a při renderování vytvoří první ElementPool, který obsahuje kořen stromu.

•

ElementPool – kontejner na elementy. Vytváří elementy, připojuje je do komponentového stromu a poskytuje rodičovským Elementům k vykreslení. Dále by zde měly být všechny třídy, které Element rozšiřují, tzn. konkrétnější implementace speciálních případů. Momentálně aplikace není v takové fázi, aby takové existovaly.

4.3.5 Model Soubor tříd pro přístup k datové vrstvě. Obsahuje kromě zmíněných (na str. 35) tříd ModelLoader, DefaultModel, Entity, traity TPropertyInjection a dvou rozhraní ještě zmiňovaný zavaděč TraitsInitializer a dále pak dva adresáře: 1. Entities – obsahuje konkrétní entity pojmenované podle názvů jejich tabulek. 2. Mappers – obsahuje třídy, které fungují jako modely a mappery5 pro dané entity. Kontroverzní se může zdát fakt, že název entity a jejího mapperu je shodný, nicméně úplný název třídy nahrnuje jmenný prostor6 a v tom se liší. Naopak díky tomu dobře spolupracují. Mappery jsou koncipované tak, aby mohly implementovat i složitější modelovou logiku. Případy takových Mapperů jsou např. Section (dokáže z předaných parametrů URL nalézt aktivní sekci) nebo Layout (umí vybranému Layoutu načíst celou strukturu elementů včetně dědících layoutů).

4.4 Implementace editačního rozhraní Editační rozhraní je rozdělené na 4 hlavní okna. •

Menu – obsahuje rozcestník na ostatní sekce.

•

Hlavní okno – obsahuje hlavní náplň menu, zobrazuje se až po vybrání menu.

•

Okno se zprávami – čistě informační okno zobrazující upozornění a chybové hlášky.

•

Debug výpis – okno pro zobrazování informací o běhu skriptu, používané pro vývoj.

•

DetailsWidget – okno, které se objevuje při označení elementu, obsahuje editační funkce.

Všechna okna lze přesouvat a měnit jim velikost a tyto údaje se ukládají do localStorage [zdroj] prohlížeče. Neměl by ale být problém data exportovat na server, aby byla přenosná napříč počítači.

5 6

Mappery v tomto případě implementují rozhraní IDataMapper, které předepisuje CRUD operace a je implementováno ve již třídě DefaultModel (takovým způsobem, že funguje pro konkrétní instance). Objekty jsem zkombinoval s pojmem model kvůli zjednodušení a přizpůsobení potřebám projektu. Inspirace z [38] a [39]. Např. volání metody get_class($this) vrací název i se jmenným prostorem. Osobně považuji variantu „core\Model\Mappers\Section“ čitelnější než „core\Model\Mapppers\SectionMapper“.

41

4.4.1 Dělení javascriptové vrstvy S vývojem větších javascriptových aplikací nemám tolik zkušeností, neboť jsem tento jazyk zatím používal spíše jako rozšíření UX a nebo na malé funkční okruhy a tak je tato část ještě více experimentální. Obslužnou vrstvu jsem programoval jako rozšíření jQuery s několika objekty, řešícími dílčí úlohy. Objekty, které mají i širší význam než pouhé bytí elementem (sekce menu, okna) jsou uloženy ve struktuře s parametry a obslužnými metodami. Celá vrstva je inicializována metodou init, která načte části rozhraní a jejich příslušné elementy, zaregistruje události a celé rozhraní uvede do chodu. 4.4.1.1 Ajax Nette má dobrou podporu pro používání ajaxu – při ajaxovém požadavku ukládá data do objektu payload, který odešle ve formátu JSON. V tomto objektu jsou jednak uložené tzv. snippety, tedy části šablony, které lze aktualizovat samostatně, ale lze do něj přidat libovolná další data. Javascriptovou obsluhu jsem udělal za pomocí jQuery, přičemž obsluhovací metoda nejprve spustí zpracování payloadu, z něhož dokáže obsloužit snippety, přesměrovat nebo spustit skript a potom ještě případný callback. Skript také indikuje běh ajaxového požadavku zobrazením žlutého rámečku s budoucí animací točícího kolečka. 4.4.1.2 Menu Menu se stará o obsluhu tlačítek menu a obsahuje objekty jednotlivých položek a jejich funkce a události. Úzce spolupracuje s obsluhou oken. 4.4.1.3 Win Obsluha oken, obsahuje všechna okna a metody pro jejich vykreslování a ovládání. 4.4.1.4 Tlačítka Jak objekt Menu tak objekt Win používají objekty s podobnou strukturou, které simulují tlačítka. Mají proměnné indikující stav (zda-li je povolené a zda-li je aktivní) a také provádějí nějakou akci. Momentálně tlačítka obsahuje sekce Layout, která jimi zapíná detekci elementů a okno DetailsWidget, které tlačítky ovlivňuje obsah elementu.

4.4.2 Způsob editace elementů – hledání optimální cesty Při hledání metody editace jsem zkoušel různými metodami vyzkoušet možnosti, např. aplikovat na všechny blokové elementy funkce z jQuery UI, mezi které patří možnost udělat element roztažitelný do výšky a šířky a možnost element přesouvat a nebo zapnout atribut contentEditable, který v některých prohlížečích dovolí elementy i přesouvat. Po vzoru rozhraní, kde uživatel pouhým táhnutím označí element a rovnou přesune jsem testoval, jestli jde něco podobného udělat i s HTML dokumentem. Bohužel výsledky nejsou jednoznačné, protože i za použití jQuery lze při takové činnosti dokument velice snadno dostat do neočekávaného stavu, kdy se element ocitne nečekaně mimo svého rodiče či ztratí vlastnost plovoucího obsahu. Hromadnější editace rozměrů či pozice elementů tedy asi může fungovat, nicméně zvolil jsem cestu editace pouze jednoho elementu zároveň. Jeden element se také dobře vizuálně označuje – použil jsem modrý obrys7 pro element ze stromu a zelený pro ostatní elementy. Důležitý je též způsob selekce, k jejíž aktivaci slouží volby, které způsobí, že při přejíždění myší po dokumentu 7

CSS vlastnost outline.

42

se označují elementy, nad kterými zrovna kurzor projíždí. To výběr usnadňuje. Po vybrání elementu se objeví menu, které na něm umožňuje zapínat jednotlivé editační funkce, včetně změny obsahu, kdy lze do obsahu elementu vložit kurzor a text editovat, dále lze momentálně změnit pozici a element roztáhnout. Editace obsahu elementu však má svá vážná úskalí, pokud se obsahově edituje element, který v sobě drží další. V takovém případě se pro vnořené elementy editace zas vypíná, což ale některým prohlížečům nezabrání ty vnořené elementy přesouvat – což lze teoreticky považovat za správné. Jako možné řešení mě napadá vypnout možnost editace textu u pole, které není čistě textové. To by se však nesmělo týkat případů s inline elementy, jenž v textu slouží jako formátovací značky. S těmi je také problém, protože ve WYSIWYG se obvykle vlastnosti textu aplikují na vybraný text. Vypadá to, že k tomuto účelu může posloužit javascriptová metoda execCommand a s ní související, která se též dostala do standardu HTML5 ([15], [31]). Tyto metody však nejsou jednoznačně implementované a např. dokumentace od Microsoftu [33] se lehce liší od dokumentace Mozzily [32]. Ale zatím jsem toto API nestihl nastudovat a aplikovat či alespoň otestovat. Další úskalí se skrývá u změny pozice elementu, kdy je z hlediska CSS několik možností, jak pozici měnit. Primárně jde o změnu CSS vlastností left a top, avšak v některých případech se může více hodit vnější odsazení, tedy vlastnost margin. Jako rozumné mi přijde mít možnost nastavit oboje. Výčet problémů lze zakončit případem změny pozice elementu v DOM, přitom lze dokument zcela zinvalidovat a dostat do nekonzistentního stavu. Při aktivaci takového přesunu by bylo zapotřebí pečlivě vybrat povolené cíle přesunu. V části Příloha C je k nahlédnutí rozhraní s těmito funkcemi a průchod scénářem editací elementu.

4.4.3 Způsob získávání a předávání informací o stavu dokumentu Elementy a kaskádové styly jsou uloženy v databázi a k jejich vykreslení dojde kompilací a připojením CSS souboru a sestavením HTML stromu. Problém nastává v případě nahrávání údajů o elementech zpět na server. Zde nemám promyšlenou metodu a jednoznačné řešení jsem ještě nestihl vymyslet. Je potřeba řešit ukládání různých druhů úprav, kdy při změně samotného CSS (ke které chybí editor) vlastně není potřeba přenos elementu samotného. Problém vyžaduje velice podrobnou analýzu, kterou jsem nestihl provést.

4.5 Dynamický obsah stránek Pouze pomocí zmíněných sekcí a layoutů by bylo možné vytvořit pouze statický obsah webu. Moje vize propojení s dynamickým obsahem spočívala v užití služeb v propojení s elementy (jedná se o služby ze str. 31) tímto způsobem: Element, který by v sobe obsahoval např. články, komentáře či jiná dynamická data by se z editačního rozhraní označil za kontejner a přiřadila by se mu data ze služby. Ta by se určila metodou z nějakého modelu a zapsala by se do nastavení elementu, resp. byla by vybrána se z dostupných metod onoho modelu. Element by pak vnořené elementy vypisoval metodou cyklu přes tato data a vypsal by jich tolik, kolik by mu jich metoda vrátila. Vnořený element by se pak přes editační rozhraní dále tvořil klasickým způsobem s tím rozdílem, že by se v jeho textových polích dala použít klíčová slova, přistupující k polím iterovaného zdroje. Tedy v případě předání článků by každý element měl k dispozici jeden článek a tedy i jeho datová pole. Ta by se v elementech získala řetězci %titul%, %autor%, %datumPublikace% apod.). Tímto způsobem by bylo možné přesně nadefinovat vzhled iterovaných elementů. Tyto služby by 43

byly schopné reagovat na změnu parametrů v URL. Avšak funkce typu stránkování by asi musela být řešena vyloženě přes speciální komponentu.

4.6 Efektivní editovatelnost Z popisu navržených vlastností editačního rozhraní vyplývá, že pokusit se v takovém prostředí postavit web od prvního elementu by bylo značně časově náročné, a to i přes případné podpůrné funkce elementů (chytré navrhování a doplňování sémanticky vhodných či povinných vnitřních elementů). Největší síla aplikace by pak spočívala ve velkém množství předpřipravených struktur, mezi které by patřily jak celkové rozložení stránek (rozmístění section bloků), tak menší podstruktury (předpřipravený seznam, blok s nadpisem a textem), ale hlavně použití těchto struktur s dynamickým obsahem (vzory pro článek s vyplněnou hlavičkou, komentáře, výpisy sekcí, souvisejících obsahů, komentářů, tabulek, …). Hlavní kostra aplikace by tak mohla vzniknout kombinací několika z těchto vzorů, a poté by se pouze doplnily a upravily menší dílčí části. Bohužel takové rozhraní obnáší programování desítek případů užití.

44

5 Závěr Tento projekt vznikl mou vlastní iniciativou, myšlenka maximálně editovatelného webu mě odjakživa fascinovala, ale vždy mi přišla komplikovaná a vzdálená. Poslední půlrok se ale nápady ohledně toho začaly formovat do konkrétnějších obrazů a postupně vznikalo větší a větší množství poznámek s návrhy a metodami. Rozhodl jsem se, že to musí být možné realizovat, a když se ukázala možnost věnovat mnoho hodin práce na projektu ve formě semestrálního projektu a bakalářské práce, navrhl jsem panu Ing. Davidu Sedláčkovi svoji ideu. Dostal jsem varování, že takové projekty často končí osekanou verzí a nebo se nepodaří je dokončit, ale nebral jsem to v úvahu. V práci se podařilo otestovat a analyzovat vybrané systémy pro správu a prezentaci dat na webu. Poté výsledky zpracovat a navrhnout způsob fungování aplikace dle zadání. Při implementaci se však objevovaly nové a další potíže, jak je patrné z konce předchozí kapitoly. Často se pak při práci stalo, že místo nových naprogramovaných funkcí vznikaly pouze nové poznámky do zápisníku a nové změny v dosavadním designu. Tyto problémy nakonec zabránily nejenom dokončení aplikace, ale i vytvoření funkčního prototypu. Výsledkem je rozpracovaná vrstva editačního rozhraní, fungující prototyp vykreslovače struktury a téměř žádná podpora pro dynamický obsah. Z toho tedy vyplývá, že se nepodařilo provést ani testování aplikace na uživatelích, protože není co testovat. Ve finále tedy musím konstatovat, že jsem si vybral zadání komplikované a bohužel příliš rozsáhlé a při jeho návrhu jsem si neuvědomil, kolik možných aspektů je třeba řešit. Po prvotních výsledcích jsem možná zbytečně dlouhou dobu strávil implementací modelové vrstvy, která tak sice dokáže aplikaci dodávat data, ale bez řadiče data v modelu nejen nelze změnit, ale ani zobrazit. Ukázalo se navíc, že některé části prvotního nejsou důkladně promyšlené a bylo potřeba je přepracovat a domyslet. V práci jsem rozlišil minimálně tři větší tématické celky, které by samy o sobě vyžadovaly důkladné zpracování, které bych nyní odhadl alespoň na rok práce. •

HTML5 editor v prohlížeči s editorem CSS

•

CMS využívající editor pro editaci statické struktury

•

rozšíření CMS o dynamický obsah

Není také jasné, zda-li by se v pokročilejší fázi zpracování projektu neukázalo, že je návrh úplně nefunkční, nebo že je tak implementačně složitý, že se nevyplatí dále jej rozvíjet. Osobně si však myslím, že realizace možná je a pokusím se na aplikaci dále pracovat. Na druhou stranu mi práce přinesla hlubší zkušenosti s webovými technologiemi a jejich možným propojením. Za zajímavé považuji především použití trait z PHP 5.4, způsob ukládání a vykreslování struktury elementů a přizpůsobitelné, byť zdaleka nekompletní uživatelské rozhraní pro editaci struktury.

45

46

Literatura [1] Bryan Ruby. Drupal and Joomla comparison [online]. 2006 [cit. 6. 1. 2013]. Dostupné z:

[2] Tim Stiffler-Dean. Wordpress vs Joomla vs Drupal [online]. 2009 [cit. 6. 1. 2013]. Dostupné z:

[3] Nette Foundation. Píšeme první aplikaci [online]. 2011 [cit. 6. 1. 2013]. Dostupné z:

[4] Petr Daněk. Velký test PHP frameworků: Zend, Nette, PHP a RoR [online]. 2008 [cit. 6.1.2013]. Dostupné z:

[5] Jakub Vrána. NotORM je rychlejší než Doctrine 2 i Dibi [online]. 2010 [cit. 6. 1. 2013]. Dostupné z:

[6] Nette Foundation. MVC aplikace & presentery [online]. 2011 [cit. 6. 1. 2013]. Dostupné z:

[7] David Grudl. Nette Framework: MVC & MVP [online]. 2009 [cit. 6. 1. 2013]. Dostupné z:

[8] Nette Foundation. NEON [online]. 2011 [cit. 6. 1. 2013]. Dostupné z: [9] Drupal. Drupal [online]. 2013 [cit. 6. 1. 2013]. Dostupné z: [10] Open Source Matters. Joomla [online]. 2013 [cit. 6. 1. 2013]. Dostupné z: [11] Google. Google Sites [online]. 2013 [cit. 6. 1. 2013]. Dostupné z: [12] Webnode. Webnode [online]. 2013 [cit. 6. 1. 2013]. Dostupné z: [13] HTML5Doctor (Rich Clark, Steve Faulkner, Bruce Lawson, Remy Sharp, Tom Leadbetter, Oli Studholme, and Ian Devlin). Všechny články týkající se HTML5 sémantiky [online]. 2009–2011 [cit. 24. 5. 2013]. Dostupné z:

[14] Oli Studholme. HTML5 structure—div, section & article a pokračování [online]. 2009 [cit. 24. 5. 2013]. Dostupné z:

[15] W3C.

HTML5.1 Nightly [online]. 2013 [cit. 24.

5.

2013].

Dostupné

z:

[16] Mark Pilgrim. What Does It All Mean? [online]. 2009–2011 [cit. 24. 5. 2013]. Dostupné z:

[17] Oli Studholme. The i, b, em, & strong elements [online]. 2010 [cit. 24. 5. 2013]. Dostupné z: [18] Richard Clark. The header element [online].

2009

[cit.

24.

5.

2013].

Dosupné

z:

[19] Jack Osborne. The Footer Element Update [online]. 2009 [cit. 24. 5. 2013]. Dostupné z: [20] Mike Robinson. Aside Revisited [online].

2009

[cit.

24.

5.

2013].

Dostupné

z:

[21] Tom Leadbetter. Semantic navigation with the nav element [online]. 2009 [cit. 24. 5. 2013]. Dostupné z:

47

[22] Bruce Lawson. The section element [online].

2009

[cit.

24.

5.

2013].

Dostupné

z:

[23] Jack Osborne. The Address Element [online]. 2009 [cit. 24. 5. 2013]. Dostupné z: [24] Bruce Lawson. The time element (and Microformats) [online]. 2010 [cit. 24. 5. 2013]. Dostupné z: [25] Oli Studholme. The small & hr elements [online]. 2010 [cit. 24. 5. 2013]. Dostupné z: [26] Tom Leadbetter. The article element [online]. 2010 [cit. 24. 5. 2013]. Dostupné z: [27] Richard Clark. The figure & figcaption elements [online]. 2010 [cit. 24. 5. 2013]. Dostupné z: [28] Mike Robinson. The dl element [online].

2010

[cit.

24.

5.

2013].

Dostupné

z:

[29] Oli Studholme. Quoting and citing with

, , , and the cite attribute [online]. 2011 [cit. 24. 5. 2013]. Dostupné z: [30] Ian Hickson. Web Storage [online].

2013

[cit.

24.

5.

2013].

Dostupné

z:

[31] W3C. HTML5 A vocabulary and associated APIs for HTML and XHTML [online]. 2012 [cit. 24. 5. 2013]. Dostupné z: [32] Doron Rosenberg. Rich-Text Editing in Mozilla [online]. 2007 [cit. 24. 5. 2013]. Dostupné z: [33] Microsoft. execCommand Method [online]. 2012 [cit. 24. [34] PHP Documentation. Arrays [online]. 2013

[cit.

24.

5. 5.

2013].

Dostupné

z:

2013].

Dostupné

z:

[35] Stackoverflow. PHP: Traits vs. Interfaces [online]. 2012 [cit. 24. 5. 2013]. Dostupné z: [36] David Grudl. DI a property injection [online]. 2012 [cit. 24. 5. 2013]. Dostupné z: [37] Wikipedia. Salt (cryptography) [online]. 2013

[cit.

24.

5.

2013].

Dostupné

z:

[38] Filip Procházka. Model: Entity-Repository-Mapper [online]. 2011 [cit. 24. 5. 2013]. Dostupné z: [39] Jan Tichý. Pět vrstev modelu [online]. 2010 [40] Nette Foundation. Začínáme [online].

[cit.

24.

5.

2013].

Dostupné

z:

2013

[cit.

24.

5.

2013].

Dostupné

z:

[41] PHP Documentation. Traits [online]. 2013

[cit.

24.

5.

2013].

Dosupné

z:

48

Příloha A Seznam použitých zkratek CMS

Content Management System

ACL

Access Control List

IDE

Integrated Development Environment

WYSIWYG

What You See Is What You Get

HTML

HyperText Markup Language

TAB

Tabulátor

UML

Unified Modeling Language

ERM

Entity-relationship model

PHP

PHP: Hypertext Preprocessor (rekurzivní zkratka)

MySQL

My Structured Query Language

CSS

Cascading Style Sheets

AJAX

Asynchronous JavaScript and XML

JSON

JavaScript Object Notation

DI

Dependency Injection

SEO

Search Engine Optimization

DRY

Don’t Repeat Yourself

KISS

Keep It Short and Simple

XSS

Cross-Site Scripting

CSRF

Cross-Site Request Forgery

URL

Uniform Resource Locator

POJO

Plain Old Java Object

49

50

Příloha B Schéma databáze

Obr. 13: Schéma databáze

51

52

Příloha C Ukázka editačního rozhraní s úpravou elementu

Obr. 14: Vzhled stránky bez editačního rozhraní Na Obr. 14 je základní vzhled stránky (elementy nejsou z časových důvodů nastylované).

Obr. 15: Vzhled stránky s editačním rozhraním

53

Připsání slova admin na začátek URL a přihlášení zapne editační rozhraní, jaké je na obr. 15 – přibyly plovoucí okna včetně menu. Kliknutím na tlačítko Layouts se vyvolá další okno, které zobrazuje možnosti editace. V něm lze identifikovat hlavní elementy přejížděním přes políčka zobrazeného stromu, nebo lze zapnout detekci elementů ve stránce při přejetí myší. Po výběru elementu se objeví menu s možnosti úprav. Na obrázku 16 je vidět přímá editace nadpisu sekce po výběru volby Upravit obsah. Odznačením se lze vrátit k výběru elementů a upravovat nějaký jiný.

Obr. 16: Editace nadpisu sekce

54

Příloha D Obsah přiloženého CD Na cd se nachází odevzdaná verze aplikace, návod na zprovoznění, SQL data a schéma a text této práce ve formátu pdf i původním. /db-schema.png..................................................... obrázek databázového schématu v plné velikosti /FreeForm.zip....................................................... zdrojové kódy aplikace /readme.txt............................................................ soubor popisující instalaci /Requirements-Checker.zip.................................. skript na kontrolu nastavení serveru /initial-data.sql...................................................... sql data pro aplikaci /tresnjan-bp-2013.pdf........................................... verze práce pro tisk /tresnjan-bp-2013.zip............................................ verze práce v původním formátu

55