Webové komponenty v open source CMS

Masarykova univerzita Fakulta informatiky Webové komponenty v open source CMS Diplomová práce Bc. Tomáš Svoboda Brno, jaro 2016

Masarykova univerzita Fakulta informatiky Webové komponenty v open source CMS Diplomová práce Bc. Tomáš Svoboda Brno, jaro 2016

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

Poděkování Rád bych tímto poděkoval RNDr. Jaroslavu Ráčkovi, Ph.D. za vedení mé diplomové práce. Dále bych rád poděkoval i Mgr. Jiří Kadlecovi za vedení práce po technické stránce a za věcné připomínky v oblasti testování. V neposlední řadě bych rád poděkoval mé rodině a všem, kteří mě během mého studia podporovali. iii

Shrnutí Hlavním cílem diplomové práce je porovnat vybrané soudobé open source systémy pro správu obsahu z hlediska rozšiřitelnosti webovými komponentami z různých pohledů. Vedle samotné analýzy rozšiřitelnosti, která tvoří hlavní část práce, jsem u vybraných komponent analyzoval i jejich složitost a výkonnost, což je jedním z faktorů pro srovnání systémů z hlediska rozšiřitelnosti. Druhým cílem této práce je vytvoření několika ukázek vybraných komponent v systému, který je vyhodnocen jako nejlepší. Dále pro tyto implementované komponenty vytvořit test, který bude srovnávat jejich výkonnost. Celkem jsem provedl dvě sady měření výkonnosti mezi skupinou vhodných webových komponent testující různé typy obsahu, pro které je daná komponenta určena. Pro účely měření jsem připravil testovací sady dat, vytvořil jednotlivé komponenty a vytvořil skript, s jehož pomocí jsem testování prováděl. iv

Klíčová slova Systém pro správu obsahu, open source, CMS, Liferay, Joomla, webové komponenty, komponenty, srovnání, výkonnost v

Obsah 1 Úvod................................ 1 2 Systémy pro správu obsahu................... 3 2.0.1 Vlastnosti CMS................... 3 2.0.2 Historie CMS.................... 7 3 Současné CMS.......................... 9 3.1 Kritéria hodnocení...................... 9 3.2 WordPress........................... 10 3.3 Liferay............................. 11 3.4 JBoss Portal.......................... 13 3.5 Joomla............................. 14 3.6 DotNetNuke.......................... 16 3.7 Výběr systémů pro podrobné srovnání............ 16 4 Liferay............................... 19 4.1 Portlety............................ 19 4.1.1 Životní cyklus portletu............... 19 4.1.2 Módy a stavy portletu............... 21 4.1.3 Konfigurace portletů................ 21 4.1.4 Meziportletová komunikace............ 22 4.2 Hook.............................. 24 4.3 Šablona ADT......................... 26 4.4 Modul EXT.......................... 28 4.5 Téma a šablony rozložení................... 29 4.6 Srovnání komponent v Liferay................ 30 5 Joomla............................... 33 5.0.1 Šablony....................... 33 5.0.2 Komponenty.................... 35 5.0.3 Moduly....................... 37 5.0.4 Plugin........................ 38 5.1 Srovnání komponent v Joomle................ 39 vii

6 Výsledné srovnání obou systémů............... 41 7 Rozšiřující komponenty Liferay................ 43 7.1 Portlet Dokumenty...................... 44 7.2 Portlet Zprávy........................ 46 7.3 Hook třídy........................... 48 7.4 Plugin EXT.......................... 49 7.5 Shrnutí implementace komponent Liferay.......... 49 7.6 Postupy a doporučení pro začleňování komponent v Liferay. 50 8 Závěr................................ 51 A Příloha A.............................. 59 Rejstřík................................. 61 viii

Seznam tabulek 7.1 Srovnání statistických hodnot pro portlet Dokumenty se šablonou ADT a s výchozím zobrazením......... 45 7.2 Srovnání statistických hodnot pro agregátor obsahu a pro portlet Zprávy se šablonou ADT a s výchozím zobrazením 47 ix

Seznam obrázků 6.1 Ohodnocení kritérií systémů Liferay a Joomla...... 42 7.1 Srovnání doby vykreslení pro portlet Dokumenty.... 45 7.2 Srovnání doby vykreslení pro portlet Zprávy....... 48 xi

Seznam příkladů kódů 4.1 Jedna z možných podob vytvoření render URL 20 4.2 Jedna z možných podob vytvoření action URL 20 4.3 Jedna z možných podob vytvoření resource URL 20 4.4 Definice veřejného parametru entityid 23 5.1 Příklad kostry stránky a umístění pozic v souboru index.php 34 5.2 Příklad nastavení parametru akce kontroleru komponenty 36 5.3 Příklad části url odkazující na komponentu a požadovanou akci 36 5.4 Příklad kontroleru modulu volajícího pomocnou třídu 38 5.5 Příklad vytvoření události vyhledání obsahu a získání výsledku 39 xiii

1 Úvod Systémy pro správu obsahu (CMS content management system) jsou informační systémy umožňující efektivní vytváření, úpravu a následnou administraci nejrůznějších forem obsahu. Tyto systémy, na rozdíl od předchozích způsobů správy obsahu, usnadňují práci s obsahem svým uživatelům, protože poskytují jednoduché rozhraní pro přístup do systému, díky čemuž může obsah spravovat kdokoliv i bez pokročilých technických znalostí, které byly vyžadované před nástupem těchto systémů. Portál Liferay je portálový systém s otevřeným zdrojovým kódem vytvořeným společností Liferay. Liferay není jen systém pro správu obsahu, ale na rozdíl od mnohých jiných open source systémů poskytuje například i funkce pro spolupráci uživatelů. Liferay tak představuje digitální platformu integrující moderní technologie jako jsou například cloudové služby nebo mobilní technologie. Systém pro správu obsahu Joomla je systém s otevřeným zdrojovým kódem vytvořený na platformě PHP. Systém Joomla cílí na malé a středně velké systémy. Stejně jako Liferay má i Joomla komunitní podporu, s tím rozdílem, že není zaštítěna žádnou společností. Vedle základních mechanismů pro správu obsahu poskytuje i komponenty pro implementaci například blogů nebo diskuzních fór. Tato práce má několik cílů. Hlavním cílem je srovnání open source systémů pro správu obsahu z hlediska rozšiřitelnosti, protože je v současné době tato část informačních technologií hojně využívána a je důležité znát možnosti jednotlivých systémů z hlediska rozšiřitelnosti a personalizace. Druhým cílem práce je srovnání systémů mezi různými platformami, protože na poli open source systémů dochází často ke srovnávání systémů pouze v rámci jedné platformy a mnohdy pouze systémy na platformě PHP. V neposlední řadě je cílem této práce i porovnání výkonnosti použitých řešení, protože v posledních letech dochází k nárůstu objemu spravovaných dat, a proto je kladen důraz i na výkonnost systému. První kapitola obsahuje úvod diplomové práce. Druhá kapitola je věnována definici a popisu systémů pro správu obsahu obecně, včetně 1

1. Úvod určení hlavních vlastností. V rámci tohoto popisu je zařazena i historie těchto systémů. Třetí kapitola obsahuje základní porovnání soudobých systémů pro správu obsahu, včetně definice srovnávacích kritérií, které jsem v této práci využíval. Čtvrtá kapitola je zaměřena na systém pro správu obsahu Liferay. V rámci této kapitoly jsou analyzovány jednotlivé webové komponenty Liferay více do hloubky. Závěr kapitoly je věnován krátkému shrnutí a porovnání jednotlivých komponent. V páté kapitole popisuji systém pro správu obsahu Joomla jakožto druhý nejlepší systém na základě vyhodnocení ve třetí kapitole. V jednotlivých podkapitolách se věnuji možným webovým komponentám, kterými lze rozšířit stávající systém a jeho základní funkcionalitu. V poslední části kapitoly opět stručně vyhodnocuji možnosti, které Joomla poskytuje skrze tyto komponenty. Šestá kapitola stručně shrnuje klady a zápory mezi oběma systémy. Na základě tohoto porovnání následně vybírám jeden systém CMS konkrétně Liferay, kterému se věnuji v rámci implementací komponent více do hloubky v sedmé kapitole. V rámci sedmé kapitoly mimo jiné porovnávám i výkonnost určitých řešení, které vykonávají stejnou funkcionalitu, ale je ji dosaženo jiným způsobem. V závěru sedmé kapitoly uvádím několik doporučení, kterými by se mohly komponenty rozšiřující systém Liferay zlepšit. Poslední osmá kapitola obsahuje závěr diplomové práce. Výsledkem mé diplomové práce je porovnání řady soudobých open source systémů pro správu obsahu a detailní porovnání dvou nejlepších systémů z hlediska rozšiřitelnosti webovými komponentami a následná evaluace výkonnosti několika implementací různých komponent ve vybraném systému. 2

2 Systémy pro správu obsahu Content management system (CMS), neboli systém pro správu obsahu, je systém, který slouží pro správu obsahu, jeho vytváření, editaci nebo publikaci. Takovéto systémy je možné vytvořit a provozovat na libovolné platformě. Hlavním cílem systémů pro správu obsahu je poskytnutí jednoduchého uživatelského rozhraní, které umožní komukoliv vytvářet a následně publikovat informace i bez potřebných technických znalostí. Tuto skutečnost ocení především správci obsahu a jeho autoři [1]. Systémy pro správu obsahu se skládají ze dvou nezbytných částí. První aplikace pro správu obsahu (content management application, CMA) je určena pro autory a správce obsahu, jímž poskytuje jednoduché prostředí pro tvorbu obsahu i jeho administraci. Druhou částí je aplikace pro dodání obsahu (content delivery application, CDA), která slouží pro publikování informací vytvořených v CMA v požadované podobě [2]. Vedle základních funkcí pro administraci, vytváření či publikování informací, systémy pro správu obsahu často disponují funkcemi jako je například podpora pro verzování obsahu nebo indexování dat a jejich následné vyhledávání. Některé pokročilejší systémy umožňují i podporu pro určitou formu marketingu [2]. 2.0.1 Vlastnosti CMS Jak již z názvu vyplývá, tyto systémy se zabývají správou obsahu. Různé systémy obsahují různou funkcionalitu a různé vlastnosti. Mezi základní vlastnosti související s administrací obsahu, které by měly poskytovat všechny systémy, patří především vytváření a publikování obsahu, jeho editace a případně i odstranění. Aby se usnadnilo vytváření publikovaného obsahu, CMS využívají šablony, do kterých autor vkládá například pomocí formuláře příslušná data. Systém poté předkládá uživateli obsah v takové podobě, v jaké byl zadefinován v šabloně. Některé pokročilejší systémy umožňují vedle přímého zadávání informací autorem i automatické a dynamické vkládání určitého typu dat z databáze. Využívání šablon 3

2. Systémy pro správu obsahu sebou přináší ještě jednu zásadní výhodu, a to sjednocení vizuální podoby souvisejících informací. Další důležitou vlastností moderních systémů je i možnost verzování dat a tudíž i revize provedených změn nad daným obsahem. Jednotlivé verze mohou obsahovat vedle změn i informace o tom, kdy byly provedeny nebo kým. To umožňuje správcům obsahu a administrátorům udržet si přehled o prováděných změnách a v případě neautorizované úpravy chybu napravit navrácením do předchozí verze. Zřejmě jednou z nejvíce klíčových součástí systému je publikace obsahu, protože právě díky publikaci je vytvořený obsah přístupný koncovým uživatelům. Pokud by tedy měla organizace nevhodně nastavený proces publikace, nemusel by se obsah v požadované podobě a ve správný okamžik dostat k uživateli a organizace by tak mohla ohrozit svůj zisk. Systémy pro správu obsahu dovolují vedle okamžité publikace obsahu i zpožděnou publikaci, kdy systém automaticky sám vypublikuje daný obsah na základě zvoleného času a data. Obě tyto vlastnosti usnadňují práci správcům obsahu, protože mají možnost publikovat jak aktuální obsah, tak předpřipravený obsah pro zachování průběžného přidávání obsahu. Publikaci obsahu často provází i jistá podoba pracovního postupu workflow při kterém každý vytvořený obsah prochází stanoveným procesem dané organizace. Jelikož si proces volí každá organizace sama, mj. i v závislosti na podpoře ze strany systému, bývá často různý. V klíčových bodech je však shodný napříč jednotlivými systémy. Typický postup od vzniku obsahu k jeho publikaci spočívá ve třech krocích. Nejprve autor vytvoří prvotní podobu obsahu, která však ještě není určena k publikaci. Ve druhém kroku dojde k přezkoumání vytvořeného konceptu, na jehož základě je koncept buď přijat a tedy i připraven k publikaci, nebo je zamítnut a vrácen autorovi k přepracování dle připomínek. V posledním kroku se schválený koncept předá nejčastěji správci obsahu, který je zodpovědný za publikaci. Ten poté může schválený obsah publikovat, nebo vrátit k přepracování v závislosti na nastavení procesu v organizaci. Rozdělení procesu publikace do těchto kroků zvýší kvalitu publikovaných informací, mj. i proto, že každý obsah musí schválit více lidí. Vedle těchto základních stavů procesu publikace mohou například existovat i mezikroky, ve kterých dojde k překladu obsahu do jiných jazyků nebo jen korektuře textu. 4

2. Systémy pro správu obsahu Aby nedocházelo k zahlcení systému i uživatele irelevantními a zastaralými informacemi, které již neplatí, musí systém obsahovat určitou službu pro mazání nebo archivaci dat. Archivace obsahu má nespornou výhodu v porovnání s pouhým smazáním, a to možnost opětovného přístupu k archivovaným datům a v případě, že se týkají tématu, který se periodicky opakuje, i znovu použít. Tento způsob má ale i jistou nevýhodu v podobě neustálého navyšování potřebné kapacity úložných zařízení. Z toho důvodu je ideální kombinace obou vlastností, kdy nepodstatná data správce maže a důležité archivuje. S přibývajícím množstvím dat v systému roste důležitost správného indexování informací, například pomocí štítků nebo členěním do kategorií. Správná indexace poskytne uživatelům při vyhledávání relevantnější obsah a tudíž může přilákat i více nových návštěvníků. Často také systémy pro správu obsahu poskytují vedle svého mechanismu pro indexaci i službu pro lepší popis obsahu pomocí klíčových slov, která pomáhá webovým vyhledávačům [3]. Tato služba se označuje jako tzv. Search Engine Optimization (SEO) optimalizace pro vyhledávače a s její pomocí dojde k zařazení dané webové stránky na vyšší pozici ve vyhledávači. Z toho důvodu se často uvádí technika SEO ve spojení s marketingem organizace [4]. Správa uživatelů v systému je natolik klíčová, že si zaslouží větší pozornost. Pokud uvažujeme nasazení systému v situaci, kdy ho bude spravovat větší počet administrátorů, přispívat do něj větší počet autorů nebo chceme omezit některým uživatelům přístup do daných sekcí, musíme použít netriviální subsystém pro administraci uživatelů [3]. Současné systémy obsahují vedle vlastního řešení autorizace a autentizace i podporu pro další způsoby správy uživatelů. Mezi ně patří například připojení LDAP serveru k systému, podpora protokolu OAuth nebo OpenID. Využívání systémů pro správu obsahu sebou přináší řadu výhod. Patrně nejvýraznější je kontrast mezi využitím nějakého již stávajícího systému pro správu obsahu a implementací vlastního řešení systému. Nejen že je použití existujícího CMS systému ekonomicky výhodné, ale také zaručuje i jistou kvalitu služeb. To z toho důvodu, že nemusíme znovu a znovu vyvíjet části systému, které jsou obecné a společné napříč různými systémy. Díky opětovnému používání komponent se zvyšuje pravděpodobnost odhalení skrytých chyb a systém se stává stabilnější. 5

2. Systémy pro správu obsahu Nejčastějšími komponentami, které se mohou používat opětovně, jsou různé šablony, rozložení stránky do sloupců, celkový vzhled systému nebo správa uživatelů, která se opakuje nejčastěji. U velkých a populárních systémů CMS často existuje i určitá forma online obchodu s komponentami, které mohou poskytnout jejich tvůrci zdarma i za peníze dalším provozovatelům tohoto systému. Ti tak nemusejí sami vytvářet danou funkcionalitu a ušetřené finance mohou vynaložit na jiném místě. Další výhodou související se systémy pro správu obsahu je oddělení obsahu od jeho vzhledu, a to především díky využívání šablon a šablonovacího systému. Vedle oddělení obsahu a formy jeho zobrazení dochází i k oddělení obou částí od samotné logiky systému. To například umožňuje další vývoj systému i během jeho provozu bez ohrožení integrity již publikovaných informací [3]. Právě oddělením jednotlivých částí dovoluje souběžnou práci v systému na obsahu, který se zobrazí uživateli na jedné stránce. To je například, kdy autoři obsahu mohou napsat nebo vytvořit svůj příspěvek, grafik může vytvořit šablonu, do které se následně zasadí jednotlivé příspěvky a správce obsahu vloží tento obsah na správné místo na stránce. Existují i další způsoby souběžné práce v systému, záleží pouze na možnostech poskytovaných daným systémem. Využívání již existujících systémů pro správu obsahu však přináší i řadu nevýhod a problémů. Nejvýraznějším problémem je bezpečnost systému. Pokud totiž dojde k prolomení bezpečnosti u daného systému, jsou ohroženi všichni, co daný systém používají. Avšak touto hrozbou trpí především menší řešení, které nejsou vhodné pro nasazení v komerční sféře. Pokud bychom chtěli mít jistotu, že nedojde k takové situaci, nezbývá, než si implementovat vlastní systém. To ovšem nezaručuje, že se zde neobjeví žádné chyby v zabezpečení [3]. Druhý a zároveň poslední závažný problém spočívá v možnosti rozšiřování funkčnosti systému. Způsobů, jak lze rozšířit konkrétní systém pro správu obsahu je více, avšak existuje různá míra náročnosti, jak daný úkol provést. Pokud se jedná o speciální funkcionalitu, často nezbývá nic jiného, než zasáhnout přímo do zdrojového kódu systému a upravit příslušný kód [3]. Ještě bych zmínil jeden problém týkající se výkonnosti. U systémů pro správu obsahu totiž dochází ke generování výsledných stránek zobrazeným uživateli až při daném požadavku, který systém zpraco- 6

2. Systémy pro správu obsahu vává. Tento způsob však může být někdy pomalý, a proto je možné generování stránek částečně optimalizovat pomocí kešování dat na serveru [3]. 2.0.2 Historie CMS Stav před vytvořením prvních systémů pro správu obsahu byl z hlediska efektivního využívání technologií kritický. Jedinou možností, jak publikovat obsah uživatelům, bylo vytvoření jednotlivých souborů HTML, kde každý soubor reprezentoval konkrétní webovou stránku. Tento způsob publikace byl velice neefektivní, protože každý, kdo chtěl něco publikovat, musel znát webové technologie, především jazyk HTML. Nejen, že toto tvořilo určitou bariéru pro tvůrce obsahu bez patřičných znalostí, ale také to zabraňovalo souběžné editaci obsahu na jedné stránce. To mimo jiné i snižovalo rychlost od napsání k prezentaci informace uživateli, čímž daná organizace přicházela o zisk [5]. První systémy pro správu obsahu se začaly objevovat v druhé polovině devadesátých let. Nejprve se jednalo o vlastní řešení, které si každá organizace vyvíjela sama. Postupem času se některé z těchto společností rozhodly začít poskytovat své vlastní implementace těchto systémů druhým, včetně případné podpory. Na přelomu tisíciletí se vedle těchto proprietárních systémů začínají ve větší míře objevovat i open source implementace, které během několika let začaly úspěšně konkurovat již zaběhlým systémům. Mezi tyto open source systémy patří například Liferay, Drupal a nespočet dalších [6] [7]. V současnosti se systémy pro správu obsahu rozdělily na dva hlavní typy systém pro správu dokumentů a systém pro správu webového obsahu, který dnes převládá [8]. 7

3 Současné CMS V současné době již existuje velké množství systému pro správu obsahu na různých platformách i s různou škálou možností, které poskytuje svým uživatelům. Nejčastěji používané systémy poskytují vedle základních služeb pro správu obsahu i další jako je například pokročilá správa uživatelů, webové služby pro manipulaci s obsahem nebo rozšiřitelnost systému o vlastní komponenty. Právě poslední zmiňovaný bod představuje v současnosti jedno z hlavních rozhodovacích kritérií pro výběr systému. Z tohoto důvodu je hlavním tématem této práce rozšiřitelnost systémů pro správu obsahu o vlastní webové komponenty. Pro účely srovnání systémů pro správu obsahu v této práci jsem vybral systémy, které mají otevřený zdrojový kód, nejsou všechny na stejné platformě a poskytují různé komponenty, kterými je možné daný systém rozšířit o požadovanou funkcionalitu. Pro základní porovnání jsem zvolil WordPress, Liferay, Red Hat JBoss Portal, Joomlu a DotNetNuke jako systémy pro správu obsahu splňující výše uvedený typ systémů. 3.1 Kritéria hodnocení Pro účely srovnání jednotlivých systémů jsem vybral několik kritérií, které nejlépe vykreslují možnosti daných systémů a na jejichž základě následně vyhodnotím jednotlivé systémy pro správu obsahu. Prvním a nejvýraznějším kritériem je rozšiřitelnost systému o vlastní komponenty. S tímto bodem souvisí i obecná rozšiřitelnost systému a úroveň modifikací vestavěných služeb a vlastností samotného systému. Jedná se o klíčový parametr při výběru vhodného systému, protože se od něj odvíjí mnoho dalších aspektů v pozdějším využívání a především jeho personalizaci. Druhé kritérium, které jsem zvolil, představuje výkonnost zvolené komponenty. Toto kritérium je relevantní pouze v případě, kdy je daný úkol možné provést více způsoby, respektive s využitím různých komponent. Jelikož je pojem výkonnosti obsáhlý, zúžil jsem ho primárně na dobu, po kterou trvá zobrazení dané komponenty včetně jejího ob- 9

3. Současné CMS sahu uživateli. Takto definované kritérium zahrnuje i keše na různých úrovních, které by v případě odlišně stanovené definice výkonnosti mohly vyústit v nepřesné závěry. Třetí a poslední parametr pro srovnání systémů je sice marginální, nicméně v určitých situacích může být rozhodujícím kritériem pro výběr vhodné komponenty. Jedná se o složitost komponenty konkrétně jde o složitost implementace dané komponenty a o složitost následného nasazení této komponenty do příslušného systému. Zvolil jsem právě tyto tři kritéria, neboť se jedná o běžné parametry používané pro srovnávání systémů pro správu obsahu. V neposlední řadě při vyhodnocování jednotlivých systémů zohledňuji i podporované technologie, nicméně se nejedná o parametr, který by měl zásadní vliv na výběr systému pro další rozbor. 3.2 WordPress Systém pro správu obsahu WordPress se řadí mezi jedny z nejpoužívanějších systémů tohoto typu na světě. WordPress je vybudován na platformě PHP, vznikl v roce 2003 pod licencí GPLv2 a nejnovější verze je 4.5 [9]. Vývoj tohoto systému je zaštítěn pouze komunitním vývojem, což se negativně podepisuje na mnohých aspektech systému jako je například bezpečnost, struktura interních prvků nebo škála poskytovaných služeb. Systém WordPress je možné vedle klasického systému pro správu obsahu použít i například jako portálový nebo blogovací systém. Word- Press bývá v mnoha případech využíván pouze jako blogovací systém, neboť pro toto základní nastavení není nutné znát jazyk PHP ani mít jiné pokročilé znalosti. WordPress oficiálně podporuje pouze některé webové servery, nicméně lze jej spustit na libovolném serveru, kde je možné provozovat systém vytvořený v jazyce PHP. Co se týče databází, jediné dva podporované databázové systémy jsou MySQL a MariaDB, jelikož jsou vybudovány na podobných principech a stejnými autory [9]. Značně omezená škála podporovaných databází často vylučuje WordPress v mnoha případech, kdy je nutné například vytvořit rozsáhlý systém nebo naopak vybudovat nový systém na základě původního, který silně integruje nepodporovanou databázi. 10

3. Současné CMS Systém WordPress poskytuje několik typů komponent, o které je možné rozšířit základní systém. Jedná se o pluginy a témata. Pluginy představují jedinou možnost, jak lze systém WordPress rozšířit o novou funkcionalitu. Vedle přidání nových služeb je možné i modifikovat existující. Nicméně tento mechanismus je velmi limitovaný a je vybudován na sadě definovaných událostí [10]. Při každé události dojde ke kontrole, zdali neexistuje plugin registrující tuto událost a případně provede tuto službu namísto původní. Pluginy umožňují i práci s databází skrze vlastní rozhraní nazvané options, nicméně neposkytuje takové možnosti jako SQL. Z toho důvodu je dostupné i běžné rozhraní, které umožňuje práci přímo s SQL. Jako poslední zajímavý prvek ve spojení s pluginy jsou tzv. štítky šablony. S jejich pomocí je možné volat funkce definované v pluginy uvnitř šablony. Na místě, kde je štítek v šabloně umístěn, dojde ke vložení výstupu z dané funkce [10]. Témata reprezentují možnost úpravy vzhledu webové stránky. Téma je možné vytvořit na základě již existujícího, nebo vytvořit zcela nové. V rámci této komponenty je možné definovat šablony rozložení webové stránky, vlastní kaskádové styly, javascriptové skripty a obrázky. Dále je možné přidat speciální skript PHP, který vystupuje jako běžný plugin [11]. V příloze je umístěna ukázková implementace pluginu pro WordPress. Tento plugin jsem využil i v rámci výsledného vyhodnocení systému Wordpress na základě stanovených kritérií. Kvůli zaměření samotného WordPressu na systémy menšího rozsahu, omezenému množství podporovaných technologií a především kvůli omezeným možnostem komponent rozšiřovat systém, nebudu dále porovnávat systém Wordpress více do detailu v další části této práce. 3.3 Liferay Portál Liferay (dále jen Liferay) je open source implementací portálového systému vytvořeného společností Liferay, Inc. Tento portálový systém vznikl již v roce 2000 jako produkt pro neziskové organizace [12]. Sama společnost byla pod tímto jménem založena až o čtyři roky později. Portál Liferay není jen systém pro správu obsahu, ale 11

3. Současné CMS poskytuje i podporu pro spolupráci a sociální interakci v podobě diskuzních fór, blogů, wiki stránek nebo kalendáře. Společnost Liferay poskytuje dvě verze svého portálového řešení, a to komunitní edici pod LGPL licencí a enterprice edici, která na rozdíl od komunitní edice poskytuje svým klientům mimo jiné i plnou podporu, školení atp. O kvalitách portálu Liferay svědčí i ocenění za nejlepší open source portál organizací InfoWorld z roku 2007 [13]. Liferay je vytvořen v programovacím jazyce Java, a tak může být provozován na libovolné platformě disponující běhovým prostředím Javy. Samotný Liferay je poté možné spustit na většině moderních aplikačních serverech i servletových kontejnerech. Vedle samotného portálu je Liferay dostupný i v balíčku s přednastavenými aplikačními servery a kontejnery, který usnadní konfiguraci portálu administrátorům [14]. Nová verze Liferay bývá pravidelně vydávána každých 12 až 18 měsíců. Krátce po vydání komunitní edice portálu přibližně jeden až dva měsíce je dostupná i enterprice edice. Zpoždění mezi oběma edicemi má za cíl především zabezpečení stability nové verze. Současná stabilní verze portálu nese označení 6.2 CE [15]. V současnosti se vyvíjí 7 verze portálu, která s sebou přináší řadu vylepšení, jako například podpora pro OSGi [16], což je nová technologie na platformě Java umožňující vytváření dynamických komponent [17]. Vedle portálu společnost Liferay zaštiťuje i další komunitní projekty, které následně integruje se službami portálu a vytváří tak jednu digitální platformu složenou z open source projektů. Mezi těmito projekty je například vlastní Liferay IDE vystavěné nad Eclipse IDE, moderní framework uživatelského rozhraní AlloyUI nebo Liferay Screens integrující mobilní technologie a portál. Liferay obsahuje řadu předpřipravených komponent, které slouží pro vytvoření základního systému spravujícího obsah i bez nutnosti tvořit vlastní komponenty portlety. Tyto komponenty pokrývají nejrůznější funkční aspekty od navigace přes zobrazení obsahu až po diskuzní fóra a blogy. Vedle těchto portletů, distribuovaných spolu s portálem Liferay, existuje možnost získat další skrze Liferay marketplace vlastní online repozitář, kde je možné nabízet své portlety ostatním. Liferay podporuje několik způsobů, jak rozšířit nebo pozměnit standardní chování služeb portálu. Nejběžnějším způsobem rozšíření 12

3. Současné CMS je pomocí portletů, neboli komponent, které tvoří základní strukturu webové stránky portálu. Další možností, jak změnit chování již existujících komponent, je pomocí tzv. hooku, který je technologickým nástupcem rozšiřovacího modelu EXT. V obou těchto komponentách dochází k modifikaci již existujících služeb portálu nebo portletů. Vedle těchto základních způsobů předefinování nebo rozšíření funkcionality systému existuje i množina komponent, které mění podobu zobrazovaného obsahu. Mezi ně patří tzv. témata (themes), šablony rozložení (layouts) a šablony pro zobrazení aplikace (ADT application display templates). Pro systém Liferay jsem vytvořil komponentu, která je pro tento systém typická portlet. Tuto komponentu jsem zahrnul do celkového zhodnocení systému Liferay a umístil ji do přílohy. 3.4 JBoss Portal Red Hat JBoss Portal je portálové řešení společnosti Red Hat, které lze mimo jiné provozovat i jako systém pro správu obsahu [18]. Tento portál vznikl v roce 2005 pod licencí LGPL a v současnosti je ve verzi 6.2. JBoss Portal je součástí platformy JBoss, to znamená, že podporované technologie tohoto systému odpovídají technologiím, které jsou nutné pro fungování JBossu. JBoss Portal poskytuje dva hlavní mechanismy pro rozšiřování systému. Podobně jako Liferay, i JBoss Portal implementuje specifikaci Portlet 2.0, tj. prvním způsobem jsou portlety jako v Liferay. Druhý způsob představují vlastní komponenty, nazývané obecně Portal Extensions. Tyto komponenty mají podobný účel jako hooky v Liferay, tj. přepsání základních webových zdrojů, jako jsou zobrazované stránky, obrázky, atp. Co se týče modifikace samotného systému obdoba EXT v Liferay JBoss Portal nic takového neposkytuje [19]. Vedle těchto dvou rozšiřujících komponent JBoss Portal podporuje i definici vlastního vzhledu webové stránky portálu a portletů označované jako skins [19]. Nicméně ve srovnání s tématy v Liferay je implementace těchto komponent složitější, protože se skládají z několika částí a podčástí a především, na rozdíl od témat Liferay neposkytují takové možnosti pro tvorbu výsledné podoby stránky. 13

3. Současné CMS Pro JBoss Portal jsem implementoval jednoduchý portlet, který jsem následně zahrnul do celkového zhodnocení systému. Na základě podobnosti komponent mezi JBoss Portal a Liferay a tím, že tyto komponenty mají omezenější možnosti rozšiřování než komponenty v Liferay, jsem se rozhodl v další části této práce detailněji porovnávat jiné systémy pro správu obsahu. 3.5 Joomla Systém pro správu obsahu Joomla jsem si vybral z toho důvodu, že je vybudován na platformě PHP, která bývá často využívána v open source projektech. Druhým důvodem, proč jsem si vybral právě tento systém, je ten fakt, že na rozdíl od populárnějšího systému pro správu obsahu WordPress je Joomla lépe navržena pro zvládání většího množství obsahu. Posledním důvodem je množství a škála webových komponent, které je možné používat v systému, a které se rozsahem použití blíží webovým komponentám v systému Liferay. Systém Joomla byl poprvé vydán pod licencí GPL v roce 2005 na základě odštěpení od projektu Mambo. Podobně jako Liferay je možné systém Joomla použít i pro další typy informačních systémů, například blogy, diskuzní fóra nebo složitější portálové řešení. V současnosti je Joomla ve verzi 3.5 [20]. Stejně jako u dalších větších systémů, má i Joomla silnou základnu komunitních vývojářů, kteří se podílí jak na vývoji systému, tak na tvorbě webových komponent, které jsou následně dostupné v knihovně komponent. Joomla má omezenější paletu funkcí z hlediska škály služeb, které doplňují standardní webové komponenty. Mezi tyto funkce, které na rozdíl od Liferay neobsahuje nebo jen v omezené míře, patří například SEO mechanismus. Vestavěné SEO v Joomle poskytuje uživatelům pouze omezené možnosti, a proto je nutné přidat některý externí plugin rozšiřující práci se SEO [21]. Na rozdíl od Liferay je množství podporovaných technologií, se kterými je možné Joomlu provozovat, značně omezené. Joomla je kompatibilní se třemi základními databázovými systémy (MySQL, PostgreSQL a SQL Server) a pouze s některými webovými servery [22]. 14

3. Současné CMS Co se týče minimálních požadavků na systém, Joomla má několikanásobně nižší nároky než Liferay. To je ovšem zapříčiněno rozsahem vestavěných funkcí v Liferay a velikostí systémů, na které je Liferay navržen. S tímto faktem do určité míry souvisí i statistika vzniku nových a zaniknutí stávajících systémů na jednotlivých systémech provedená organizací Datanyze. Podle této studie bylo zjištěno, že v únoru tohoto roku vzrostl počet webových systémů na Liferay o 75. V případě Joomly vzniklo přibližně 9600 webových stránek, nicméně více než polovina z tohoto počtu také zanikla. Uvedené hodnoty však mohou být ve skutečnosti ještě vyšší, protože data v analýze byla získána na základě webových crawlerů, které neměly přístup do interních sítí, kde se Liferay často vyskytuje [23]. Systém Joomla obsahuje několik způsobů, jak lze rozšířit nebo upravit standardní chování systému. V zásadě lze jednotlivé komponenty rozdělit do tří skupin, podle toho, čeho se týkají šablony upravující vzhled a rozložení, jazyky a v neposlední řadě komponenty, moduly a zásuvné moduly, které přidávají určitou funkcionalitu spojenou s vykreslením obsahu. Rozšíření komponentou jazyky, tj. přidání nových překladů textací ostatních komponent, není rozšiřující komponentou na stejné úrovni jako ostatní, a proto se často ani neuvádí jako komponenta rozšiřující systém Joomla. Jejím jediným účelem je přidání lokalizace do nového jazyka nebo změna stávajících zpráv v komponentě. Jazykový balíček obsahuje instalační soubor popisující mj. názvy komponent, které rozšiřuje a samotné lokalizované texty v souborech ini. Dále může obsahovat i skript, který se stará například o různé tvary slov v množném čísle. V tomto směru je práce s lokalizací obtížnější než v Liferay, který využívá standardizované prostředí pro internacionalizaci v Javě. V příloze práce je umístěná šablona Joomly, kterou jsem vytvořil pro srovnání systémů z hlediska složitosti implementace a rozšiřitelnosti systému. 15

3. Současné CMS 3.6 DotNetNuke Jako poslední systém pro správu obsahu jsem vybral systém Dot- NetNuke, protože se řadí mezi nejpoužívanější systémy pro správu obsahu na platformě.net. Tuto platformu jsem zvolil záměrně, protože právě na.netu se často upřednostňují proprietární systémy před systémy open source. Systém DotNetNuke (DNN) vznikl v roce 2003 pod licencí MIT a v současnosti má již osmou verzi. Vedle základní verze poskytuje společnost vlastnící DNN platformu i další dvě placené verze, které poskytují širší škálu služeb a technické podpory. Vedle systému pro správu obsahu je možné DotNetNuke použít například i pro menší portálové systémy a webové aplikace. Vývoj systému DotNetNuke je již od počátku zajišťován komunitním vývojem a později po založení organizace DNN je vývoj zaštítěn i společností DNN. Stejně jako řada ostatních systémů pro správu obsahu, ani DotNet- Nuke nepodporuje všechny technologie související se systémy pro správu obsahu. Jelikož je vystavěn na platformě.net, jediné oficiálně podporované technologie jsou ty, které pochází od Microsoftu, tj. IIS jako webový server a MS SQL jako databáze [24]. DotNetNuke poskytuje dvě hlavní komponenty rozšiřující základní systém. Jedná se o moduly a komponenty měnící vzhled tzv. skins. Moduly umožňují pouze funkcionalitu přidávat, nikoliv měnit již existující implementaci [25]. V rámci komponenty skins je možné definovat kaskádové styly a další webové zdroje a především šablonu rozložení webové stránky [26]. Vytvořil jsem komponentu skin, kterou jsem zahrnul do celkového vyhodnocení systému DotNetNuke v porovnání s ostatními systémy. Kvůli omezenému množství podporovaných technologií a omezeným možnostem těchto komponent jsem se rozhodl dále nepokračovat v podrobné analýze tohoto systému. 3.7 Výběr systémů pro podrobné srovnání Primárně na základě definovaných kritérií jsem zvolil dva systémy pro správu obsahu, které byly vyhodnoceny jako nejlepší. Vedle samot- 16

3. Současné CMS ných kritérií jsem do úvahy při evaluaci jednotlivých systémů zahrnul i rozsah podporovaných technologií daného systému. Jako nejlépe hodnocený systém jsem vybral Liferay, protože nejlépe vyhovuje těmto kritériím. Systém Joomla jsem zvolil z toho důvodu, že poskytuje více typů komponent i větší počet podporovaných technologií ve srovnání s ostatními systémy a bude tedy vhodným systémem při detailním porovnání se systémem Liferay. 17

4 Liferay Na základě prvotního vyhodnocení vybraných systémů pro správu obsahu jsem zvolil Liferay jako hlavního kandidáta pro podrobnější analýzu systému z hlediska rozšiřitelnosti komponentami a vyhodnocení ostatních kritérií. 4.1 Portlety Nejsnazší a nejčastější způsob, jak rozšířit základní služby portálu Liferay, představují právě portlety. Liferay podporuje oba portletové standardy JSR168 a JSR286 [27] a aktivně se podílí na specifikaci verze 3.0 [28]. Portlet reprezentuje základní webovou komponentu, jejímž výstupem je úsek HTML kódu zasazený na předem určené místo na webové stránce. Portlety poskytují různé služby na základě jejich implementace zobrazení obsahu, služby nad ním a nebo další administrativní úkony. 4.1.1 Životní cyklus portletu Životní cyklus portletů je řízen portálem portletovým kontejnerem a na základě stavu, v jakém se portlet nachází, generuje svůj výstup. Specifikace portlet 2.0 rozšiřuje předchozí verzi a definuje několik nových stavů, ve kterém se portlet může nacházet. Základními stavy nelišících se od stavů servletů, ze kterých portlety vychází jsou stavy inicializace a zničení portletu. Kontejner volá příslušné metody v okamžiku, kdy má být portlet nasazen nebo naopak odstraněn ze služby. Tyto dvě metody jsou volány právě jednou za celý životní cyklus portletu. První verze specifikace definovala dva základní stavy portletu tzv. fáze render a action [29]. Fáze render je určena pro vykreslení určitého obsahu portletu na základě dané render metody. Výstupem této metody je fragment HTML kódu s požadovanými daty, který je vložen do webové stránky na místo vyhrazené portletem. Konkrétní render metodu můžeme volat pomocí tzv. render URL. Tato URL může obsahovat různé parametry od módu portletu přes parametr specifikující 19

4. Liferay generovaný výstup až po stav okna, v jakém se má portlet nacházet. Render URL je možné vytvořit jak v rámci controlleru, tak uvnitř JSP stránek, které definují podobu, v které se informace předají uživateli. < portlet:renderurl var =" myrenderurl " > < portlet:param name =" page " value =" formpage "/> </ portlet:renderurl > Příklad kódu 4.1: Jedna z možných podob vytvoření render URL Fáze action slouží pro provedení nějaké akce. Typickou akcí je například odeslání formuláře nebo smazání dat z databáze jinými slovy akce, která má jiný účel, než jen zobrazení informací. Po dokončení metody asociované s danou akcí následuje fáze render. Pokud je na jedné portálové stránce více portletů, tak po dokončení akce dojde k vyvolání příslušných render metod u všech těchto portletů. < portlet:actionurl var =" actionurl " name =" myaction "/> Příklad kódu 4.2: Jedna z možných podob vytvoření action URL Ve druhé verzi specifikace došlo k přidání dvou nových metod serveresource a processevent. Fáze resource souvisí s poskytováním dat, které mají často jinou než HTML podobu nejčastěji binární, XML nebo JSON. Jelikož přijatá data mají tento charakter, nedochází k novému překreslení a opětovnému načtení portletu a k jejich zpracování musí dojít na straně klienta. Z těchto důvodů je vhodné volat resource metody skrze resource URL například v rámci implementace AJAXu [29]. < portlet:resourceurl var =" myresourceurl "/ > Příklad kódu 4.3: Jedna z možných podob vytvoření resource URL Fáze event byla přidána z důvodu rozšíření škály způsobů implementace meziportletové komunikace [29]. Fáze render následuje po dokončení vykonání metody spjaté s danou událostí. Některé URL fází životního cyklu portletu je možné rozšířit o parametry obsahující název portletu a tzv. plid (portal layout ID), který obsahuje unikátní ID stránky v Liferay. Přidáním těchto dvou parametrů je možné vykonat metodu související s danou URL v jiném portletu, než ze kterého je volána. 20

4. Liferay 4.1.2 Módy a stavy portletu S životním cyklem portletu je spjat i stav a mód, v jakém se portlet nachází. Specifikace portlet 2.0 definuje tři základní stavy portletu normální, minimalizovaný a maximalizovaný stav okna portletu a tři standardní módy portletu VIEW, EDIT a HELP. Specifikace umožňuje přidat i vlastní stavy a módy, jen je nutné, aby byly podporované i ze strany portálu [30]. Liferay tedy poskytuje dva vlastní stavy POP_UP a EXCLUSIVE, které zobrazí portlet v tzv. pop-up okně nebo vykreslí pouze tento portlet. Liferay rozšiřuje základní množinu o dalších šest módů portletů. Mezi nimi je například mód pro tisk, náhled nebo konfigurace. Módy portletu poskytují určitý pohled na portlet. Základní VIEW mód musí implementovat každý portlet, protože zobrazuje běžný výstup portletu. Pohled editace (EDIT) slouží pro konfiguraci portletu podle preferencí uživatele nebo administrátora v závislosti na konfiguraci oprávnění a situaci [30]. Uživatel si tak například může definovat, jaký typ obsahu nebo v jakých intervalech se má zobrazovat. Jednotlivé atributy klíč a příslušná hodnota se ukládají v databázi v tabulce portletpreferences a Liferay je zpřístupňuje skrze stejnojmenné rozhraní. Bez ohledu na typ módu portletu je vždy nutné, aby byl vytvořen buď kontroler zajišťující patřičný výstup pohledu, nebo přímo JSP stránka s totožným výstupem. Jednotlivé pohledy, které portlet podporuje, jsou definované v konfiguračním souboru. 4.1.3 Konfigurace portletů Konfigurace portletů v Liferay je prováděná na základě vyhodnocení konfiguračních souborů umístěných ve složce WEB-INF. Prvním z nich je soubor portlet.xml, který je jediným povinným souborem vyplývajícím ze specifikace portlet 2.0. Tento konfigurační soubor definuje jednotlivé portlety, které jsou poté dostupné v rámci portálu. Každý záznam tak obsahuje základní informace o portletu, jako například jeho název, inicializační parametry, podporovaný jazyk, sdílené parametry a mnoho dalšího. Ostatní konfigurační soubory jsou proprietární a pomáhají s dalším nastavením portletů v Liferay. Prvním z těchto proprietárních souborů 21

4. Liferay je liferay-portlet.xml. Konfigurace v tomto souboru upravuje některé obecné vlastnosti portletů v Liferay a dále tak rozšiřuje jejich JSR286 definici z portlet.xml. V rámci tohoto konfiguračního souboru je možné upravit mimo jiné zdali má být portlet instanciovatelný, tj. zdali může být více instancí daného portletu na jedné stránce, nastavit tzv. frienldy URL upravenou URL pro lepší čitelnost uživatelem nebo je možné přidat specifické javascriptové a kaskádové soubory, které definují dynamické chování na straně klienta a vzhled komponent v rámci daného portletu [31]. Soubor liferay-display.xml přidává možnost tvůrcům portletů rozčlenění jednotlivých portletů do kategorií, ve kterých se posléze zobrazují v Liferay při přidávání portletů na stránku. Soubor liferay-plugin-package.properties je posledním konfiguračním souborem portletů. Tento soubor se od předchozích liší v tom, že neslouží pro popis jednotlivých portletů v rámci portletového pluginu, ale obsahuje metadata a další informace, které se využívají při překladu a nasazení pluginu do Liferay nebo i při publikaci pluginu v Liferay marketplace. Vedle základních popisných dat název, autor, licence, podporovaná verze Liferay se zde může například definovat, na jakých knihovnách tento plugin závisí a tedy jaké knihovny se mají přidat na tzv. classpath [31]. 4.1.4 Meziportletová komunikace Meziportletová komunikace slouží pro výměnu dat mezi více portlety, tj. jeden nebo více portletů se bude chovat na základě dat z jiného portletu. Vedle základních mechanismů, jako jsou tzv. cookies a portletové relace (session), poskytuje Liferay i další způsoby, jak předávat data mezi portlety. Obecně lze hovořit o jednom portletu, který data posílá (Sender portlet) a o portletech, kteří data přijímají (Receiver portlets). Prvním mechanismem jsou veřejné parametry (public render parameters [32]. Tyto parametry propagují běžné neveřejné render parametry i mezi další portlety, které mají nakonfigurovanou podporu pro konkrétní veřejné parametry. Definice parametrů i podpora ze strany portletů je nastavena v souboru portlet.xml pomocí jednoduchých deklarací v jazyce XML. 22

4. Liferay <public - render - parameter > < identifier > entityid </ identifier > <qname xmlns:x =" http: // liferay. com ">x:entityid </ qname > </ public - render - parameter > Příklad kódu 4.4: Definice veřejného parametru entityid Na základě nastavení atributu portlet.public.render.parameter.distribution v portálu je možné určit rozsah platnosti veřejných parametrů. Vedle základního chování, kdy jsou všechny veřejné parametry platné pouze v rámci portletů na jedné stránce, lze rozsah platnosti parametrů rozšířit i na všechny stránky portálu. Vlastní hodnotu jednotlivým parametrům lze přiřadit ve fázi action pomocí metody response.setrenderparameter(... ) a pokud již nechceme, aby tato hodnota zůstala nadále přístupná portletům, můžeme ji odstranit pomocí metody response.removepublicrenderparameter(...). Druhým mechanismem meziportletové komunikace je tzv. událostmi řízená komunikace [32]. Tento způsob komunikace vychází z klasického konceptu událostmi řízeného informačního systému a je proto snažší na pochopení ve srovnání s ostatními způsoby. Stejně jako v případě veřejných parametrů je možné nastavit, aby byly události platné pouze v rámci jedné stránky nebo aby se propagovaly mezi portlety na jiných stránkách. Deklarace definice událostí, publikace a zpracování ze strany portletů je obdobná jako u veřejných parametrů. Portlet opět publikuje danou událost v rámci fáze action pomocí metody response.setevent(... ). Událost je poté zpracována dalšími portlety uvnitř příslušné metody obsluhující daný typ události. Po zpracování události přejde každý z těchto portletů do fáze render. Posledním způsobem meziportletové komunikace je komunikace na straně klienta. Liferay pro tento způsob komunikace poskytuje mechanismus, který dovoluje publikovat nebo naopak zpracovávat události na straně klienta za pomoci javascriptu bez nutnosti serveru v roli prostředníka jako v předchozích mechanismech [33]. Veřejné parametry poskytují jednu velkou výhodu oproti událostem, a to v podobě sjednocení veřejných i neveřejných parametrů do jedné množiny. To usnadňuje práci s veřejnými parametry, protože k nim můžeme přistupovat jako k obyčejným parametrům a do jisté míry tak skrývají mechanismus meziportletové komunikace. 23

4. Liferay Na druhou stranu, události mohou zapouzdřovat data různých datových typů včetně složitějších objektů na rozdíl od parametrů obsahující pouze řetězce, které je nutné parsovat do požadovaného datového typu. Další výhodou událostí je to, že nezůstávají aktivní mezi více průchody portletem. 4.2 Hook Hooky reprezentují nejjednodušší způsob, jakým lze upravit standardní chování a přepsat tak hlavní funkce portálu. Koncept hooků se objevil až v pozdějších verzích Liferay, konkrétně od páté verze. Hooky vznikly za účelem nahrazení dosavadního konceptu úprav portálu modelem EXT. Každý hook má svůj vlastní konfigurační soubor liferay-hook.xml, ve kterém je možné nastavit, co daný hook upravuje. Obecně platí, že v jedné instanci portálu by měly hooky upravovat konkrétní soubor nebo atribut v souboru jen jednou, aby nedošlo k nekonzistentnímu stavu, kdy by Liferay nevěděl, která hodnota nebo soubor je ten správný. Existují však výjimky, které dovolují přepisovat jak soubory (např. rozšíření vícejazyčných hlášek), tak atributy (např. atributy definující akce na události v portálu) [34]. Nejčastějším případem, kdy se hook používá, je situace, kdy je zapotřebí upravit stávající podobu některého webového zdroje, tj. změna konkrétní JSP stránky, javascriptového kódu nebo třeba obrázky. Liferay k tomuto účelu poskytuje snadný mechanismus, kdy stačí vytvořit stromovou strukturu reprezentující umístění originálního souboru v portálu. Do tohoto umístění poté stačí pouze vložit upravený soubor a Liferay se sám postará o nahrazení staré verze za novou. Tato aktualizace spočívá ve vložení nového souboru do složky portálu, kde se nachází originální soubor a přidání postfixu portal k názvu původního souboru. Díky tomu je možné snadno odebrat příslušný hook a vrátit funkcionalitu do původního stavu. Od šesté verze Liferay umožňuje omezit platnost hooku jen na některé kolekce webových stránek (tzv. sites). Tyto omezené hooky jsou označované jako application adapters [35]. V současnosti jimi lze omezit působnost pouze hooky upravující JSP stránky, a to nastavením atributu vynucujícím vypnutí globálního rozsahu hooku v konfigu- 24

4. Liferay račním souboru. Aplikovat jednotlivé hooky lze poté v konfiguraci skupin stránek v portálu. Vedle úprav JSP webových zdrojů je možné s hooky měnit i přidávat vlastní tzv. strust actions nebo přidat vlastní reakce na události vyvolané uvnitř portálu. Rozdíl mezi akcemi strust a těmi vyvolanými událostmi je právě v původu, který je vyvolá. Je zřejmé, že akce vyvolané událostmi spustí událost portálu, jako je například přihlášení uživatele do systému. Naopak akce strust jsou vyvolané na základě textového řetězce v URL, který odpovídá definovanému řetězci nějaké akce. V obou případech však stačí rozšířit některou z generických Java tříd akcí Liferay a rozšířit konfiguraci přidáním příslušného záznamu do správného konfiguračního souboru. S reakcemi na události souvisí i tzv. model listenery komponenty, které odposlouchávají události (vytvoření, změny,...) nad entitami modelu a podle typu události provést adekvátní reakci. Uvnitř hooku je možné vytvořit vlastní listener, který je buď přidán ke stávajícím, nebo zcela nahradí standardní, který má asociovaná každá entita modelu [34]. Implementace vlastního listeneru je snadná, stačí pouze implementovat generické rozhraní ModelListener a přidat příslušný atribut odkazující na plné kvalifikované jméno listeneru do konfiguračního souboru portal.properties uvnitř hooku. Implicitně se nový listener přidá k ostatním, pokud bychom tedy chtěli ty standardní odstranit, musíme nastavit uvnitř souboru portalext.properties atribut související s danou entitou na prázdnou hodnotu. Jedním z konfiguračních souborů, který lze rozšířit, je portal.xml. Jediný problém, který může nastat, je, že bychom měnili hodnotu jednoho atributu z více hooků a tento atribut je definován tak, že smí být změněn pouze jednou. Mezi takové atributy patří například aktivace podmínek použití. Dalším typem změn je přepsání libovolných textových hlášek a štítků. Veškeré soubory s texty v různých jazykových mutacích jsou umístěny ve složce content v příslušné knihovně portálu. Když chceme upravit některý text zprávy, stačí vytvořit soubor Language_*.properties s označením požadovaného jazyka, do kterého se vloží nová zpráva. Jednotlivé jazykové soubory je poté nutné vložit do konfiguračního souboru liferay-hook.xml. Liferay poté zcela automaticky vkládá nové textové zprávy namísto původních. 25