Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Student
:
Pavel Sklenář
Vedoucí bakalářské práce
:
Ing. Luboš Pavlíček
Oponent bakalářské práce
:
doc. Ing. Alena Buchalcevová, Ph.D.
TÉMA BAKALÁŘSKÉ PRÁCE
KOMPONENTOVÝ VÝVOJ WEBOVÝCH APLIKACÍ
ROK :
2010
Prohlášení
Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a ţe jsem uvedl všechny pouţité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 23. 6. 2010
................................ podpis 2
Poděkování
Rád bych zde poděkoval Ing. Luboši Pavlíčkovi za trpělivé vedení mé bakalářské práce a za cenné rady a připomínky.
3
Abstrakt Práce popisuje moţnosti vývoje webové aplikace a zaměřuje se na komponentový přístup při vývoji
komponent do redakčního systému
komponenta, rozhraní
komponenty
Wordpress. Jsou vysvětleny pojmy
jako
a komponentová architektura, aby byly posléze
komponentové principy dokázány u tohoto redakčního systému srovnáním s jinou, na komponentách zaloţenou platformou Eclipse RCP. Jsou popsány principy fungování Wordpressu a v jedné z dalších kapitol jsou vysvětleny i moţnosti tvorby vlastních komponent a jejich následné nasazení. V praktické části je popsáno konkrétní nasazení systému na Vysoké škole ekonomické v Praze a jeho zhodnocení. V závěru autor navrhuje doporučení přispívající ke zlepšení současného stavu na škole.
This work describes the possibility of development web applications and focuses on component approach in developing components for CMS Wordpress. There are explained a component, component interface and component architecture, that were later proven principles of this content management system compared to another, component-based platform Eclipse RCP. In one of the chapters are explained the possibilities to create custom components and their subsequent deployment, which could be problematic under certain conditions. The practical part describes the specific use of this system on The University of Economics in Prague and its evaluation. In conclusion, the author proposes recommendations of contributing to improve the present state.
4
Obsah Obsah ....................................................................................................................... 5 Úvod ......................................................................................................................... 7 1.
Webová aplikace .................................................................................................. 8
1.1. Bezpečnost komunikace a další rizika ...................................................................... 8 1.2. Moţnosti tvorby webové aplikace ............................................................................ 8 1.2.1.
Psaní prostého kódu bez jakékoli další podpory. ................................................. 8
1.2.2.
Vyuţití frameworků ........................................................................................ 9
1.2.3.
Vyuţítí CMS pro vytváření vlastních webových aplikací ...................................... 10
1.3. Přehled CMS ...................................................................................................... 12 2.
Komponentový vývoj .......................................................................................... 15
2.1. Komponenta ...................................................................................................... 15 2.1.1.
Definice komponenty .................................................................................... 15
2.1.2.
Rozdíl mezi komponentou a objektem ............................................................. 16
2.1.3.
Rozhraní komponenty ................................................................................... 17
2.1.4.
Komponentová architektura ........................................................................... 19
2.1.5.
Vlastnosti komponent v závislosti na pouţité architektuře .................................. 19
2.1.6.
Nasazení komponenty v komponentové architektuře......................................... 20
2.2. Metody a přístupy k vývoji komponentové architektury ........................................... 22 2.1. Technologické standardy pro komponentový vývoj ................................................. 23 2.2. Porovnání Eclipse RCP s redakčním systémem Wordpress ........................................ 24 3.
Pouţití redakčního systému Wordpress .................................................................. 27
3.1. Instalace Wordpressu ......................................................................................... 27 3.2. Struktura adresáře s instalací Wordpressu ............................................................. 27 3.3. Administrace ...................................................................................................... 29 3.3.1.
Správa uţivatelů .......................................................................................... 29
3.4. Wordpress hooks ................................................................................................ 30 3.5. Tagy a funkce .................................................................................................... 33 3.6. Zkratky pro funkce neboli „Shortcode API― ............................................................ 34 3.7. Automatické zjišťování nových verzí ..................................................................... 35 3.8. Pluginy .............................................................................................................. 35 3.9. Tvorba vlastních pluginů...................................................................................... 42 3.9.1.
Název pluginu .............................................................................................. 42
3.9.2.
Soubory pluginu ........................................................................................... 42 5
3.9.3.
Ukládání dat pluginů do databáze ................................................................... 43
3.9.4.
Vyuţití pluginu na stránce ............................................................................. 44
3.9.5.
Umístění nastavení v administrativní části ....................................................... 45
4.
Popis současného stavu redakčních systémů na Vysoké škole ekonomické v Praze ..... 48
4.1. Popis distribuované verze .................................................................................... 48 4.1.1.
Školní pluginy .............................................................................................. 49
4.1.2.
Další nainstalované pluginy ........................................................................... 49
4.2. Úpravy v oddělení .............................................................................................. 51 4.3. Zhodnocení současného řešení ............................................................................. 52 4.4. Doporučení a návrh budoucího řešení .................................................................... 53 Závěr ...................................................................................................................... 54 Seznam pouţité literatury .......................................................................................... 55 Terminologický slovník .............................................................................................. 58
6
Úvod Webové aplikace si získávají v dnešní době stále větší popularitu díky novým technologiím, které tak přispívají k tomu, ţe tyto aplikace jsou plně interaktivní a dokáţou mnoha způsoby reagovat na činnosti uţivatele, který nečeká a má pocit, ţe se stále něco děje. Klasickým tahounem na poli webových aplikací je v dnešní době např. e-mailová schránka na serveru Gmail1 nebo velmi oblíbená sociální síť Facebook 2. Samozřejmě, ţe existuje i řada dalších vynikajících webových aplikací, ale tyto nejznámější dvě můţeme nazvat weby, které určují trendy a hranice, kam aţ lze ve světě webových aplikací zajít. Podle těchto trendů se řídí ať uţ přímo či nepřímo tvorba ostatních vznikajících aplikací kopírujících velmi často například vzhled a chování jednotlivých prvků na stránce. Vysoká oblíbenost webových aplikací je i z důvodu malých nároků na jejich provoz, protoţe ve většině případů si vystačíme pouze s webovým prohlíţečem. Nejsme tedy omezeni ţádnou konkrétní platformou, coţ můţe být v mnoha případech klíčové. Protoţe je pojem webová aplikace příliš rozsáhlý jak z hlediska desítek technologií, tak i oblastí, ve kterých se s nimi můţeme setkat, zaměřil jsem se ve své práci na komponentové webové aplikace, tzn. aplikace poskládané z různých částí. I komponentová webová aplikace můţe být implementována různými technologiemi, a proto jsem se ve své práci zaměřil na komponentové aplikace postavené na redakčním systému Wordpress, se kterým mám dost zkušeností a který je v kategorii redakčních systémů jeden z nejpouţívanějších a nejoblíbenějších. Pro praktickou ukázku bych uvedl jeho konkrétní nasazení na Vysoké škole ekonomické v Praze v Oddělení síťové infrastruktury Výpočetního centra, kde jsem se podílel na jeho zavedení. Moje práce by tedy měla na začátku nastínit moţnosti tvorby webových aplikací, poté bych objasnil pojem komponenta a komponentový vývoj. Dále bych chtěl na příkladu a porovnání s jinou
komponentovou
architekturou
dokázat,
ţe
i
systém
Wordpress
pouţívá
komponentové principy. Na závěr bych popsal jeho nasazení na škole a doporučení, která vyplývají z mých zkušeností a znalostí získaných z literatury.
1
http://mail.google.com
2
http://www.facebook.com/ 7
1. Webová aplikace Webová aplikace je aplikace přístupná přes webový prohlíţeč. Díky novým technologiím jako např. AJAX (Asynchronous JavaScript and XML) vzrůstá obliba interaktivních webových aplikací, které jsou pouţitelné kdekoli, kde je k dispozici prohlíţeč. S webovými aplikacemi se tak dnes setkáváme při posílání e-mailů z webového klienta, nakupování v internetovém obchodě nebo při nahrávání fotek do naší on-line fotogalerie. Vedle výhod v podobě ţádné nutnosti instalace klienta (webový prohlíţeč je většinou součástí operačního systému) musíme zváţit před vývojem takové aplikace i negativa, která s sebou přináší její pouţívání.
1.1. Bezpečnost komunikace a další rizika Protoţe veškerá komunikace klienta a serveru probíhá přes síť (většinou Internet), existuje zde reálné riziko odposlechu dané komunikace v podobě přenášených hesel nebo jiných citlivých údajů. V horším případě můţeme komunikovat s úplně někým jiným, neţ s kým chceme. Napsat konzistentní aplikaci fungující naprosto stejně napříč všemi (alespoň nejvíce pouţívanými) prohlíţeči bývá často nelehký úkol. Na vině je nejen programátor, ale hlavně různé specifikace prohlíţečů při interpretaci jazyka HTML, kaskádových stylů nebo JavaScriptu. Mezi další problémy při pouţívání webových aplikací patří i pomalost JavaScriptu, který při hojném pouţití na stránce můţe práci velmi zpomalit i na relativně silném stroji (klientském počítači). Při tvorbě aplikace je programátor omezen i skutečností, ţe uţivatel je nucen pro ovládání pouţívat převáţně myš. Pokud si i přesto si zvolíme za cíl napsat webovou aplikaci, nabízí se několik moţností, jak ji vytvořit.
1.2. Možnosti tvorby webové aplikace 1.2.1.
Psaní prostého kódu bez jakékoli další podpory.
Tento způsob "tvorby na zelené louce" s sebou přináší výhodu psát aplikaci na míru konkrétním poţadavkům, ale obnáší také nutnost naprogramovat si i nejzákladnější prvky aplikace, jako můţe být např. práce se souborem nebo s databází. Při této variantě a špatném počátečním návrhu se můţeme zbavit moţnosti snadné rozšiřitelnosti aplikace 8
v budoucnu. I kdyţ můţe být aplikace zpočátku zamýšlena jako malá, časem se mohou poţadavky změnit nebo rozšířit a následná úprava můţe být dosti nákladná.
1.2.2.
Využití frameworků
Framework je softwarová struktura obsahující programy, knihovny nebo i návrhové vzory, které poskytují funkcionalitu celé aplikaci. Zatímco knihovny poskytují většinou pouze specifickou funkci, framework nabízí širší moţnosti pouţití a zahrnuje větší funkcionalitu. Vyuţití některého z frameworků, které jiţ nabízí knihovny a sluţby pro práci s databází, můţe pomoci programátorovi zabývat se programováním aplikace na vyšší úrovni. Frameworky se liší programovacím jazykem, ve kterém byly vytvořeny, a sluţbami, které nabízejí. V praxi se tak můţeme setkat s frameworky, které jsou zaměřeny na bezpečnost, na práci s databázemi, nebo se snaţí nabídnout celou škálu sluţeb a aţ programátor si vybere, které balíčky (komponenty) bude pouţívat. Výhody vyuţití frameworků v porovnání s předchozím způsobem vývoje aplikace jsou zřejmé, opět se ale můţeme setkat s rozšířením
poţadavků
na
aplikaci.
Můţe například
později
vyvstat
poţadavek
na
implementaci uţivatelských úrovní (rolí) do aplikace. Nezbývá nám tedy nic jiného, neţ poţadovanou funkcionalitu doplnit (ať jiţ za pomoci daného frameworku, pokud to podporuje). Příklady frameworků Programovací jazyk JAVA: Většina frameworků v Javě je postavena na platformě Java EE (Enterprise Edition) nebo s ní spolupracují. Nejznámější z nich jsou JavaServer Faces, Spring nebo Struts. Společným jmenovatelem Java framworků je oddělení uţivatelského interface od aplikační logiky. Definice uţivatelského rozhraní je postavena na jazyku XML. Programovací jazyk C# a VB.NET Velmi populární způsob vytváření webových aplikací je za pomoci Microsoft ASP.NET platformy. Ta umoţňuje programátorům vyuţívat celé portfolio podporovaných jazyků z .NET. Programovací jazyk PHP Velmi oblíbený a často pouţívaný jazyk pro psaní webových aplikací, i přestoţe kvůli svým charakteristikám se na rozsáhlejší projekty příliš nehodí. Nevýhody nejen v podobě příliš benevolentních pravidel při psaní kódu se snaţí částečně eliminovat frameworky. Mezi 9
nejznámější patří objektově orientovaný Zend Framework, robusní framework Symfony a například český Nette Framework, který je zaměřen na rychlost a bezpečnost. Ostatní jazyky Při psaní aplikace můţeme vyuţít i frameworky napsané v programovacích jazycích Perl (Catalyst), Python (framework web2py) nebo Smalltalk a JavaScript.
1.2.3.
Využítí CMS pro vytváření vlastních webových aplikací
CMS (Content Managment System) neboli systém pro správu webového obsahu (někdy také nazýván redakčním systémem) slouţí primárně pro publikování a správu dokumentů. Pokročilé redakční systémy obsahují nebo je moţno přidat celou řadu funkcí, jako například řízení přístupu k dokumentům (řízení přístupových práv), správu obrázků, galerií, moţnost moderování diskuzí pod obsahem stránky. Rozdíl oproti frameworkům je v tom, ţe v případě CMS jsme omezeni jeho konkrétní implementací. V praxi to můţe znamenat, ţe nemůţeme pouţívat libovolnou databázi, ale pouze např. MySQL. I samotná struktura ukládání dat je jiţ předem stanovena a máme pouze omezené moţnosti vycházející z konkrétního systému. Pokud jsme schopni akceptovat daná omezení, odměnou nám bude jiţ hotová implementace systému s okamţitou moţností pouţití. V praxi se můţeme setkat s CMS, které vyuţívají různé frameworky a jejich funkčnost z nich vychází. (např. systém DotNetNuke pouţívá .NET Framework) Při vývoji rozšíření pro tyto systémy je tedy nutná i znalost práce s daným frameworkem. Moderní redakční systémy mohou být rozšířeny o mnoho komponent (často nazývány jako moduly nebo pluginy, ale vţdy se jedná o totéţ). Význam slova komponenta bude blíţe objasněn v následující kapitole. Mezi běţně dostupné komponenty pak patří statistiky přístupů, elektronické obchody nebo optimalizování pro webové vyhledávače. Tvorba sloţitějších komponent s sebou přináší i nutnost vytvořit dostatečně kvalitní prostředí pro jejich integraci do systému. Některá CMS jsou dnes proto povaţována za jakýsi framework, protoţe samy o sobě jiţ nabízí mnoho sluţeb a funkcí, které mohou nově implementované moduly/komponenty vyuţívat. Moţnost tvořit vlastní kompomenty s vyuţitím funkcí nabízených redakčním systémem se proto jeví jako další moţnost psaní vlastních webových aplikací. Snadná rozšiřitelnost v budoucnu je zajištěna moţností doplnění vlastních pluginů nebo vyuţití funkcí nabízených samotným CMS. Pokud by stejně jako v předchozím příkladu vznikl poţadavek na rozšíření aplikace o správu uţivatelských účtů, řešení jiţ máme skoro hotové, protoţe většina těchto systémů jiţ správu účtů obsahuje. 10
Řada těchto velmi kvalitních CMS je nabízena jako svobodný software, existují však i komerční řešení implementovaná aţ podle poţadavků zákazníka. V mé práci bych se chtěl věnovat pouze open source systému Wordpress, který je zdarma dostupný ke staţení jako hotový produkt. Výhody open source řešení:
Jsou zdarma.
V případě rozšířených redakčních systému existuje velká jak programátorská, tak i uţivatelská základna.
Přístupné zdrojové kódy a moţnost jejich editace v rámci licence, pod kterou jsou vydané.
Můţeme vyuţít modulů, které jiţ jednou někdo naprogramoval.
Jsou napsané většinou v programovacím jazyku PHP a vyuţívají MySQL databázi.
Nevýhody open source řešení:
Protoţe nejsou vyrobené na míru poţadavkům, mohou být některé příliš rozsáhlé s mnoţstvím nepotřebných funkcí.
Můţe se stát, ţe některá součást systému nebude pracovat jak má. V takovém případě máme pouze moţnost zvolit si jiný CMS nebo pročítat fóra, která se věnují problémům s konkrétním systémem. Nemůţeme se obrátit na podporu s urgentním poţadavkem na vyřešení.
Nemusí pokrývat všechny naše poţadavky. V případě potřeby lze právě proto tvořit vlastní moduly. U komerčních CMS by tato situace, zdůrazňuji, neměla vůbec nastat vzhledem k implementaci na míru. Zde je tvorba vlastních modulů ovlivněna ať uţ pozitivně či negativně smlouvou, ve které můţe být dána povinnost nezasahovat do programového kódu či vůbec jejich neuveřejnění zadavateli.
Vývoj nemáme ve vlastních rukách, proto nám aplikace nebo celý systém můţe po čase přestat fungovat. Pokud vyuţíváme zdarma nabízený plugin, v novějších verzích se můţe změnit rozhraní a přestat fungovat. Naopak pokud si vyvíjíme vlastní pluginy, nemusí v novějších verzích CMS pracovat správně. S oběma problémy se můţeme samozřejmě setkat i v případě komerčních řešení.
Není zaručena zpětná kompatibilita s našimi stávajícími aplikacemi. V případě komerčních řešení můţe být opět problém řešen povinností kompatibility vyplývající 11
ze smlouvy. Musíme si však uvědomit, ţe s těmito poţadavky roste i cena poţadovaného softwaru a konečnou, byť i jedinou a tím zásadní nevýhodou můţe být právě
vysoká
cena
komerčního
systému
v porovnání
se
zdarma
nabízeným
softwarem. Proto je vţdy potřeba zváţit, zda výhody, které nám přináší komerční řešení, nejsou vykoupeny příliš vysokou cenou. Pro vývoj webové aplikace, u které uvaţujeme o moţnosti rozšíření do budoucna, připadá tedy pouţití frameworku nebo řešení vyuţívající CMS. Pro detailnější analýzu v následujících kapitolách jsem si vybral druhou moţnost, tedy vývoj komponent do stávajícího CMS.
1.3. Přehled CMS Podle databáze DMOZ3 shromaţďující redakční systémy je 80 procent z celkového počtu napsáno v programovacím jazyku PHP. Většina z nich pouţívá databázi MySQL a díky tomu (pokud nemají nějaké speciální poţadavky) je lze snadno nainstalovat i na běţný, zdarma nabízený webhosting. Můţeme se setkat se specifickými CMS, které se věnují například pouze blogům 4, psaním diskusních fór nebo obrázkovým galeriím. Vedle úzce profilovaných systémů existují i komplexní systémy, které jednak obsahují základní podporu pro psaní příspěvků, vkládání obrázků, ale jsou i připraveny pro další rozšiřování a přizpůsobování. Jejich funkčnost můţe být snadno rozšířena o další dostupné komponenty. Server PACKT PUBLISHING5, který mj. vydává zatím v podstatě veškerou literaturu týkající se redakčních systémů, zvolil jako „Best Open Source CMS 2009― systém Wordpress. V kategorii „Hall of Fame Award 2009―, tedy něco jako síň slávy zvítězily redakční systémy Joomla a Drupal. Drupal navíc získal cenu „Best Open Source PHP CMS 2009―, coţ můţe být volně přeloţeno jako velmi kvalitně udělaný systém v jazyce PHP.
3
http://www.dmoz.org/Computers/Software/Internet/Site_Management/Content_Manageme nt/ 4
Aplikace zobrazující příspěvky jednoho nebo více autorů většinou v chronologickém pořadí.
5
http://www.packtpub.com/ 12
Krátce bych zmínil jejich hlavní přednosti: Drupal Naprogramován v jazyce PHP umoţňuje pouţívat nejen MySQL databázi, ale i PostgreSQL a plánu je i databáze Oracle. Drupal je známý pro svoji přehlednost v kódu a otevřenost svého API (rozhraní pro další moduly). Joomla Další z oblíbených redakčních systémů umoţňující na základní kostře postavit např. zpravodajský portál, internetový obchod nebo rezervační systém. O velké uţivatelské základně svědčí její lokalizace do 50 jazyků včetně češtiny. Wordpress Původně blogovací systém napsaný v PHP vyuţívající MySQL se stal díky rozšiřitelnosti v podobě komponent, zde nazývané jako pluginy, velmi oblíbenou variantou při vytváření webových aplikací. Díky systému trvalých odkazů, dodrţování standardů XML, XHTML a CSS, moţnosti pingback6 a trackback7 je velmi dobře hodnocen nejen mezi uţivateli, ale i mezi webovými vyhledávači, které ho tak řadí na první místa ve výsledcích hledání. Další předností je i snadná instalace, údrţba a moţnost automatické aktualizace celého systému. Administrátor můţe tak pomocí pár kliknutí aktualizovat nejen Wordpress, ale i všechny nainstalované pluginy společně. Pokud k tomu připočteme moţnost vytváření vlastních vzhledů, máme tu nejen skvělý blogovací nástroj, ale i systém potencionálně pouţitelný pro firemní weby. Server Technorati.com8 udrţuje pravidelně aktualizovaný seznam 100 nejlepších9 blogů celosvětově. Ze seznamu vyplývá, ţe 27 blogů z celkového počtu vyuţívá Wordpress a tím se tato platforma umístila jednoznačně na prvním místě. Zajímavé je, ţe pouze 8 blogů ze 100 vyuţívá vlastní systém. Jaké konkrétní weby se umístily na špici uţ tak zajímavé není, protoţe se jedná o cizí weby. Pro příklad, jakým způsobem lze získat popularitu a dostat se na přední příčky, mohu uvést, ţe na druhém místě je v tuto chvíli server Gizmodo10
6
Redakční systém shromaţďuje weby (stránky), které se na naši stránku odkazují.
7
Podobné jako u pingback, méně odolný vůči spamu.
8
http://technorati.com/
9
K určení pořadí pouţívá vlastní metriku, která mj. zahrnuje mnoţství odkazů zvenčí na daný blog, mnoţství diskuzí a je vyjádřena na stupnici 10
http://www.gizmodo.com 13
uveřejňující pravidelně novinky převáţně ze světa mobilních technologií. Popularitu mu nepochybně i přineslo předčasné zveřejnění nové podoby mobilního telefonu iPhone od firmy Apple, kdy se nenašel snad ţádný domácí zpravodajský server, který by tuto zprávu s odvoláním na server Gizmodo nezveřejnil. Wordpress pouţívá i Vysoká škola ekonomická v Praze pro jednotlivé fakultní weby, proto bych se chtěl dále věnovat pouze tomuto systému a ukázat moţnosti tvorby komponent do tohoto systému.
14
2. Komponentový vývoj Komponentový vývoj přímo souvisí s cílem mé práce, tedy bliţšího prozkoumání redakčního, na komponentách zaloţeného systému Wordpress. V této kapitole bych chtěl proto blíţe definovat komponentu a moţné přístupy k jejich vývoji a aţ poté se věnovat samotným komponentám ve Wordpressu.
2.1. Komponenta 2.1.1.
Definice komponenty
V softwarové oblasti se pouţívá pojem komponenta v mnoha souvislostech. Často je pouţívána ve smyslu dílčí část neboli součást. Také bývá dávána do souvislostí s jejími vlastnostmi, tedy moţnost sestavení a výměny. Různé definice komponenty: „Komponenta je kus zkompilovaného kódu nabízející službu určitého druhu.“ [1] “V metodice RUP se pod pojmem komponenta rozumí zapouzdřená, v ideálním případě netriviální, nezávislá a vyměnitelná část systému, která plní svoji funkci v rámci předem definované architektury”. [2] „Komponenta je fyzický kus implementace systému, zahrnujícího programový kód (zdrojový, binární nebo spustitelný) či jeho ekvivalenty jako skripty nebo příkazové soubory.“ [3 str. 29] „Komponenta je netriviální, téměř nezávislá a nenahraditelná část systému, plnící funkci v kontextu stanoveném architekturou.“ [4 stránky 42-50] „Softwarová komponenta je jednotka z celku s určitým vyspecifikovaným rozhraním a jednoznačnými závislostmi. Softwarová komponenta může být nasazena nezávisle a tím podléhat kompozici od třetí osoby.“ [5] „Komponenta je část systému a zároveň jednotkou designu, konstrukce, konfigurace, řízení a substituce.“ [6 str. 2] „Softwarová komponenta je dynamicky svázaný balík jednoho nebo více programů, daných do jednoho celku v jednotku, která je přístupná přes zdokumentovaná rozhraní, která mohou být volána za běhu programu.“ [7] „Komponenta je znovupoužitelný softwarový balíček, který je nezávislé vyvinutý a může být kombinován s ostatními komponentami, aby vznikly větší jednotky.“ [8] „Komponenta je definovaná jako nejmenší samostatně fungující nezávislá část systému, který může být nasazena v různých prostředích.“ [9 str. 13] „Business komponenta jako softwarová implementace anonymního business konceptu nebo procesu, která se skládá ze softwarových artefaktů nezbytných pro jejich reprezentaci, implementaci a nasazení.“ [10]
15
„Komponenta je modulární jednotka systému se zapouzdřeným obsahem, který je dostupný přes rozhraní. Jako samostatná jednotka je během svého běhu vyměnitelná.“ [11] Různé definice mají společnou snahu definovat komponentu jako zásuvný objekt, jehoţ struktura a chování se odvíjí od pouţité technologie. Historický vývoj komponent začal pouţíváním grafických doplňků pouţitelných v různých kombinacích beze změny jejich zdrojových kódů. Komunikace mezi komponentami probíhá přes volání procedur. Příkladem technologie vyuţívající popsané principy je Java Beans. O krok dále jsou komponenty vyvinuté ze samostatných aplikací, které získaly API (Application Program Interface) pro vzdálené volání komponenty. Umoţňuje to psaní komponent v různých jazycích a přidělení vlastního vlákna procesoru pro jednotlivé komponenty.
V tomto
případě
komunikace
mezi
komponentami
probíhá
na
úrovni
operačního systému. Příkladem technologií vyuţívajících API pro své komponenty můţe být COM (Component Object Model), OLE (Object Linking and Embedding), Apple Events nebo Unix pipes. Nejpokročilejší jsou v tomto směru distribuované komponenty pracující na různých strojích v různých lokalitách. Komunikace probíhá přes síť většinou s vyuţitím protokolu TCP/IP na spodní vrstvě v kombinaci s tradičními protokoly na horní vrstvě, např. protokolu FTP. Další moţností je vyuţití RMI (Remote Method Invocation), která umoţňuje volat vzdálené komponenty a jejich procedury jako by byly místní. Při komunikaci se také vyuţívá protokol TCP/IP, ale na vyšší vrstvě jsou pouţity vlastní protokoly jednotlivých technologií. Příkladem takové technologie můţe být Java RMI, která pro komunikaci pouţívá vlastní protokol JRMP (Java Remote Method Protocol). Novější verze Java RMI se nazývá RMI/IIOP. Prakticky jde o RMI přes protokol IIOP (Internet Inter-Orb Protocol) a má za cíl kompatibilitu při komunikaci a spolupráci s platformou nezávislým systémem CORBA (Common Object Request Broker Architecture), který vyuţívá distribuované, objektově orientované aplikace.
2.1.2.
Rozdíl mezi komponentou a objektem
Komponenta má některé podobné vlastnosti s objekty, a proto bývají tyto dva pojmy občas zaměňovány. Komponenty i objekty poskytují své sluţby přes rozhraní a své vnitřní implementace mají ukryty. Komponentový vývoj má být další krok v přístupu k vývoji po objektově orientovaném programování [12]. 16
Szyperski [5] uvádí, ţe „komponenty přichází k životu skrze objekty―, protoţe obsahují jednu nebo více tříd či statických objektů. Tento vztah ovšem nemusí být klíčový a v komponentách můţeme najít i jiné odlišnosti od tříd. Komponenty mohou být například realizovány jako více objektů z různých tříd. Komponenty navíc vyuţívají stálá úloţiště dat (soubory, databáze), objekty naopak vyuţívají pro svá data výhradně hlavní paměť určenou pro běh aplikace. Komponenty mohou obsahovat tradiční procedury, globální proměnné realizované nejen pomocí objektového přístupu, ale i funkcionálního [13]. Z toho plyne, ţe komponenta můţe být implementována pomocí jedné nebo více tříd, které jsou součástí objektového programování, nebo tradičními procedurami s pouţitím neobjektově orientovaného programovacího jazyka. Komponenty mají navíc všeobecně širší sadu dorozumívacích mechanismů, objekty vyuţívají většinou
pouze
mechanismus
zaloţený
na
posílání
zpráv
jednotlivým
(konkrétním)
objektům. V definici UML (Unified Modeling Language) standardu [14] mají komponenty mnoho společného s třídami, existují však i určité rozdíly:
Třídy představují logickou abstrakci, komponenty jsou spíše fyzická záleţitost.
Komponenty představují fyzické zabalení logických elementů a jsou proto na jiné úrovni abstrakce neţ třídy.
Třídy mají atributy a operace přístupné přímo, komponenty mají operace přístupné pouze přes rozhraní.
Třída můţe být komponentou tehdy, pokud splňuje pravidla pro pouţití v nějaké komponentové technologii.
Je tedy zřejmé, ţe i přes mnoho podobností nacházíme několik zásadních rozdílů a konfliktů mezi komponentami a objekty. Ve skutečnosti je ale opak pravdou, protoţe objektově orientovaná analýza, návrh a implementace se velmi často pouţívá při vývoji komponent.
2.1.3.
Rozhraní komponenty
Rozhraní komponenty umoţňuje její pouţití i přes neznalost její implementace. Rozhraní tak separuje vnitřní a vnější část a při pouţití komponenty se ptáme pouze, co dělá, ale ne jak to dělá. Vnitřek komponenty je skrytý a není důleţitý pro její nasazení. Nejdůleţitější jsou sluţby, které komponenta poskytuje navenek.
17
V UML je rozhraní definováno jako „pojmenovaná kolekce operací použitých ke specifikaci služeb třídy nebo komponenty.― [14] Szyperski [5] definuje rozhraní jako specifikaci přístupových bodů komponenty. Klienti přistupují ke sluţbám skrze definované přístupové body. Pokud komponenta nabízí více přístupových bodů, nabízí tím i více sluţeb a má tudíţ i více rozhraní. Je důleţité podotknout, ţe rozhraní
nenabízí
ţádnou
z implementací
jeho sluţeb. Poskytuje pouze seznam
dostupných operací s jejich jmény a definicemi. Toto umoţňuje změnu vnitřní implementace komponenty beze změny rozhraní a celého systému vyuţívajícího tuto komponentu. Dle [13] můţeme rozlišovat dva druhy rozhraní. Komponenta můţe nabízet nebo naopak poţadovat rozhraní ve vztahu k systému, ve kterém běţí a který můţe zahrnovat i další komponenty. Poskytované rozhraní reprezentuje sluţby a operace poskytované systému. Naopak poţadované rozhraní ukrývá sluţby a operace, které komponenta poţaduje pro svůj běh.
Poţadované
rozhraní
nemusí
být
uspokojeno
pouze
systémem,
ale
i
jinou
komponentou, na které tím vzniká závislost a je nutná její bezpodmínečná přítomnost v systému pro správnou funkčnost instalované komponenty. Pro popis rozhraní se pouţívají speciální jazyky Interface Definition Language (IDL). Pro platformu COM je to například Microsoft Interface Definition Language11. Podle [12] jsou nejdůleţitější elementy definované v rozhraní následující:
Názvy dostupných operací
Jejich parametry
Přijatelné typy parametru
Szyperski [5] zmiňuje ještě nutnost standardizace komunikačních zpráv, schémat a protokolů z důvodu různých kombinací vyuţívání internetových (IP, UDP, TCP, SNMP a dalších)
a
webových
(HTTP,
HTML)
standardů.
Pro
dosaţení
sémantické
jistoty
a
jednoznačnosti zasílaných zpráv je vhodné vyuţít XML formátu, který umoţňuje i vyuţití schémat pro kontrolu validity zpráv. Validace je proces ověření shody XML dokumentu nebo XML zprávy se schématem. „Umožňuje odhalit nekonzistenci dat, které by pak mohly vadit při dalším zpracování.― [15]
11
http://msdn.microsoft.com/en-us/library/aa367091(VS.85).aspx 18
2.1.4.
Komponentová architektura
Koncept komponent, jejich skládání, nebo naopak rozklad a pouţití rozhraní dává za vznik komponentové architektury. Stojanovic [13] definuje komponentovou architekturu jako organizovanou strukturu a k ní asociované chování, kdy je moţné celý systém rekurzivně rozloţit na části (komponenty) komunikující spolu pomocí rozhraní. TOGAF (Open Group Architecture Framework) 12 definuje architekturu dvěma způsoby podle kontextu [16]:
Formální
popis
systému
nebo
jeho
detailní
plán
na
komponentové
úrovni
pro pochopení implementace celého systému.
Struktura komponent, znázornění vztahů mezi nimi, principů a pravidel pro jejich návrh a vývoj v budoucnu.
V materiálech [2] o metodice RUP (Rational Unified Process) zaměřených na popis vývoje komponentové architektury je architektura definována jako sada významných rozhodnutí o organizaci softwarového systému, výběru dílčích komponent a jejich rozhraní, ze kterých se systém skládá. Společně s jejich chováním je specifikována spolupráce mezi komponentami, jejich skládání ve větší podsystémy.
2.1.5.
Vlastnosti komponent v závislosti na použité architektuře
Podle [13] můţeme rozdělit vlastnosti komponent na základní a pokročilé.
Základní
vlastnosti jsou konkrétní komponentovou technologií vyţadovány, pokročilé naopak u moderních komponent očekávány. Komponentové technologie vyuţívají při svém návrhu a vývoji komponentovou architekturu. Základní vlastnosti:
Nezávislost pouţití - komponenta je spjata s konkrétní technologií a v rámci této technologie je vyměnitelná.
12
Definované rozhraní - kapitola 2.1.3.
Uznávaný mezinárodní standard pro řízení Enterprise architektury 19
Znuvupouţitelnost - komponenta je pouţitelná v různých systémech, které však pouţívají stejnou komponentovou technologii a stejnou architekturu (např. klientserver)
Některé pokročilé vlastnosti
Umoţnit
tvorbu
balíčků
poskládaných
z různých
komponent
(zvyšuje
se
znuvupouţitelnost)
Snadnost nasazení - komponenta můţe být nasazena, pokud existuje definovaný postup pro její individuální sestavení, nastavení, instalaci a pouţití.
Moţnost nasazení v jednom systému vícekrát, pokaţdé s jinou úlohou.
Interoperabilita - pokud komponenta vyuţívá standardní mechanismy, např. pro výměnu dat, můţe snadno komunikovat i s jinými komponentami a systémy.
Mezi vlastnostmi můţeme nalézt několik implikací. Pokud má být komponenta nezávisle nasaditelná, měla by být zároveň i dobře oddělitelná od prostředí, ve kterém běţí, a od ostatních komponent. Pokud má být komponenta nasazená v prostředí třetí strany (stále však v rámci jedné architektury), měla by být dostatečně samostatná s jednoznačnou definicí poţadavků na běh a definicí poskytovaných sluţeb.
2.1.6.
Nasazení komponenty v komponentové architektuře
Nasazení komponenty neboli deployment je jednou z klíčových vlastností při pouţití komponentové architektury. Jde vlastně o integraci jednotlivých komponent do systému. Uţ při vývoji by měl být proto kladen důraz na aktivity spojené s nasazením komponenty do systému tj. [17]:
Vydání – jde o shromáţdění všech potřebných instalačních, konfiguračních a ostatních souborů potřebných pro instalaci do systému.
Instalace – konfigurace a sestavení všech příslušných úkonů potřebných pro běh komponenty v konkrétním systému a zaevidování do tohoto systému.
Aktivace – úkon, kterým se komponenta stane pouţitelná. Kontroluje se například, zda jsou uspokojeny závislosti na jiných pluginech.
Deaktivace – uvolnění všech pouţívaných zdrojů systému a uvedení do stavu, kdy nemůţe být komponenta pouţita. 20
Rekonfigurace
–
změna
v nainstalované/aktivované
konfiguraci
dle
vlastních
poţadavků.
Adaptace – změna v nainstalované/aktivované konfiguraci dle změn v prostředí systému, ve kterém je nasazena.
Aktualizace – změna v nainstalované verzi komponenty se zachováním původních nastavení
Odinstalace – odebrání nainstalovaných součástí ze systému.
Odebrání – vydání komponenty se stane nedosaţitelné.
Součástí nasazení komponenty jsou i jednoznačně definované závislosti, neboli poţadovaná rozhraní. [5] Komponenta poţaduje jinými slovy určité sluţby a operace po prostředí, ve kterém je (má být) nasazena. Závislosti mohou být uspokojeny buďto samotným systémem nebo dalšími nainstalovanými komponentami. Samotná instalace je tak provedena ve dvou fázích (Obrázek 1) [18]. První fáze ověří, zda je instalace moţná ověřením závislostí na komponentách (D) v konkrétním prostředí (C). Tato fáze zajistí tedy validitu výrazu C+D v prostředí instalovaného systému. Pokud je instalace moţná, přecházíme do druhé fáze, vlastní instalace, ve které je ovlivněno vlastní prostředí systému (C’), a proto je nutná jeho aktualizace.
Obrázek 1: Instalační fáze [18]
21
Obrázek 2: Nasazení komponenty [19]
2.2. Metody a přístupy k vývoji komponentové architektury I přestoţe jsou technologie nezbytnou součástí jakéhokoli řešení, samy o sobě nestačí. Nutné jsou i metody a techniky pro vývoj komponentních aplikací vycházejících z obchodních poţadavků. Při vývoji systému nebo jako v našem případě webové komponentové aplikace je nutné, aby byly na úvod stanoveny základní poţadavky na systém z pohledu managmentu, uţivatelů a v neposlední řadě moderních trendů. Je tedy nutné si stanovit, jak by měla výsledná aplikace vypadat [20]:
cíle systému (co má aplikace, komponenta vykonávat)
všechny uţivatelské poţadavky podporující dosaţení stanovených cílů
integrace o
datová - jednou uloţená data by měla být dostupná v rámci celého systému, nemělo by docházet k zbytečné redundanci dat.
o
softwarová - jednotlivé komponenty by měly být vzájemně propojeny v rámci navazujících procesů a naopak je také ţádoucí se vyvarovat zbytečné závislosti v rámci implementace, aby nebyla porušena podstata komponentové architektury. 22
o
hardwarová - jednotlivé hardwarové komponenty by měly být propojitelné např. v rámci celopodnikové sítě.
otevřenost systému - architektura by měla snadno akceptovat parametrické změny nebo změny v podobě nových komponent.
aplikace by měla být snadno pochopitelná pro uţivatelskou sféru, design zaměřený na uţivatele.
Architektura tedy představuje celkový koncept budoucího systému. Zachycuje jednotlivé komponenty a jejich vazby. Podle úplnosti a oblasti pokrytí jednotlivých dimenzí se rozlišuje na architekturu sluţeb, aplikační a technologickou architekturu [21]. Definování architektury a její následná dokumentace usnadňuje nejen samotný vývoj ale i znovupouţití navrţeného designu a vzorů v budoucích projektech. Jednou z mnoha metodik zajišťujících pokrytí výše uvedených bodů s důrazem na komponentovou architekturu je např. metodika Rational Unified Process (RUP) nebo Select Perspective.
2.1. Technologické standardy pro komponentový vývoj V současné době je k dispozici několik implementačních modelů pro vytváření komponentové architektury.
Modely
jsou
často
nazývány
jako
komponentový
middleware
nebo
implementační standardy pro komponenty, které definují „sadu norem pro implementaci, pojmenovávání, efektivní spolupráci uvnitř systému, individuální změny, kompozici, vývoj a nasazení.― [12] Zahrnuje i standardy pro definici rozhraní a spolupráci s ostatními komponentami. Mezi oblíbené komponentové implementační modely patří Microsoft COM+/.NET a Enterprise Java Beans (EJB) od firmy Sun nebo velmi obecný CORBA Components [13]. Zatímco zmíněné implementační modely jsou velmi rozsáhlé a dosti obecné (ať uţ úplně, nebo z větší části), existují i konkrétnější řešení pro psaní aplikací. Příkladem můţe být Eclipse RCP (Rich Client Platform) nebo Netbeans RCP, které mají např. k systému Wordpress o poznání blíţe, proto jsem si na komponentách zaloţenou platformu Eclipse RCP vybral pro porovnání s tímto redakčním systémem, abych tím dokázal komponentový přístup i v systému Wordpress.
23
2.2.
Porovnání Eclipse RCP s redakčním systémem Wordpress
Open source platforma Eclipse RCP vznikla v roce 2004 původně z Java IDE (vývojové prostředí pro psaní Java aplikací). Aby si vývojáři zjednodušili práci, vytvořili si z něj Framework IDE, tedy framework pro psaní vývojového prostředí. Poté jiţ vznikl Application Framework (framework pro psaní aplikací), tedy výsledná RCP platforma a v současné době je IDE distribuován
pouze jako modul. Vytvořená
aplikace je tak poskládána ze
znovupouţitelných komponent, které jsou součástí platformy (např. správce oken), a z komponent, které jsou charakteristické pro konkrétní účel aplikace (např. komponenty pro zdravotnictví, školství apod.). Wordpress má s Eclipse RCP společné nejen datum vzniku (také 2004), ale i mnoho principů komponentového přístupu. I přesto, ţe systém Wordpress není ještě tak vyzrálá platforma jako Eclipse, můţeme jej s trochou nadsázky nazvat také aplikačním frameworkem, který nám pomáhá při tvorbě našich aplikací. Jeho rozsáhlá základna nám poskytuje mnoho funkcí, které můţeme vyuţít pro psaní dalších komponent a ve výsledku nové aplikace. Rozdíl mezi oběma platformami ukazují následující 2 obrázky.
Obrázek 3: Princip Eclipse RCP [22]
24
Obrázek 4: Princip systému Wordpress
V Eclipse RCP vidíme, ţe i samotná platforma se skládá z několika komponent. Pravdou je, ţe je nutné mít alespoň nainstalované a aktivované dva základní pluginy [23] (org.eclipse.ui a org.eclipse.core.runtime). Ve Wordpressu působí základní platforma jako jeden celek, i kdyţ je zřejmá její implementace s pouţitím všech funkcí a sluţeb, které platforma nabízí i pro komponenty (pluginy). Můţe to být proto pouze mezikrok k fungování na stejném principu, jako u platformy Eclipse, tj. moţnost poskládat si základní systém dle svých potřeb a vynechat tak například jeden z moţných budoucích pluginů „Správa uţivatelů―, „Psaní komentářů―, které jsou teď přímo součástí instalace (ne v podobě samostatných pluginů). V obou platformách je tedy moţnost doinstalovat si komponenty vlastní nebo od třetích stran. Eclipse RCP pro správu komponent pouţívá vlastní implementaci standardu OSGi 13 pod názvem Equinox a nabízí navíc oproti Wodpressu následující sluţby:
Komponentě nabízí moţnost definovat poţadovanou verzi komponent, na kterých je daná komponenta závislá.
Při aktivaci komponenty se automaticky nahrají i komponenty, na kterých je daná komponenta závislá (Pokud jsou k dispozici).
13
http://osgi.org 25
Lze
jednoznačně
definovat
třídy
a
funkce,
které
budou
viditelné
ostatním
komponentám. Obě platformy nabízí řešení pro případ, ţe chceme, aby dvě libovolné komponenty, které o sobě neví, spolu mohly spolupracovat. Například existuje komponenta, ve které můţe uţivatel něco vybírat, a komponenta, která na výběr reaguje. První komponenta proto začne vysílat nějakou událost a druhá z komponent se k této události registruje a naslouchá. Samozřejmě naslouchající komponenta musí oznámeným událostem rozumět. Shodně jsou také na tom Wodpress a Eclipse v moţnostech, jak přidat novou poloţku do některého z existujících (nebo i nového) menu. V obou případech můţe jedno menu obsahovat poloţky z různých pluginů a lze určovat i jejich pořadí. Rozdíl je pouze v tom, ţe ve Wordpressu nelze definovat na poloţku různé akce dle aktuálního kontextu. Smysl by to mělo například tehdy, pokud bychom měli v administraci klasické menu „Soubor―, ve kterém by bylo tlačítko „Smazat―. Pokud bychom měli aktuálně otevřené komentáře, tímto tlačítkem by se dal smazat komentář. Pokud bychom měli právě otevřený seznam našich příspěvků, stejným tlačítkem „Smazat― bychom mohli smazat i příspěvek. Samozřejmě, ţe se jedná o ukázkový příklad, ale moţnost vyuţít kontext by byla přínosem i v jiných případech. Jednou z hlavních výhod Eclipse RCP oproti CMS Wordpress, která ale přímo nesouvisí s pokročilostí implementace komponentových principů, je přítomnost vlastního vývojového prostředí (jako jedné z moţných z komponent) pro tvorbu např. vlastních pluginů. Z menu pouhým kliknutím myši můţeme vytvořit plugin, jehoţ vývojem nás provede přítomný vizuální
průvodce.
Během
několika
okamţiků
tak
můţeme
pracovat
na
konkrétní
implementaci poţadovaných funkcí a nemuset se zaobírat implementací vedlejších úkonů, jako např. instalace a aktivace komponenty apod. V případě Wordpressu jsme odkázáni na některý z PHP editorů, které nejsou většinou tak vyspělé14 jako vývojová prostředí pro jazyk Java a v kaţdém případě si musíme vţdy celý kód napsat sami.
14
Mám zkušenosti s Eclipse PDT (http://www.eclipse.org/pdt/) a Netbeans s PHP modulem (http://netbeans.org/features/php/). Obě prostředí by měla patřit ke špičkám na trhu, avšak nenabízí tolik komfortu např. při krokování atd. 26
3. Použití redakčního systému Wordpress Wordpress stejně jako ostatní CMS pomáhá snadno vytvářet a aktualizovat obsah webových stránek. Funkčnost systému můţe být rozšířena o mnoţství pluginů, které si buďto sami vytvoříme nebo vyuţijeme a pouţijeme jiţ hotového pluginu staţením z globálního úloţiště15.
3.1. Instalace Wordpressu Jak uţ bylo řečeno v přehledu CMS, Wordpress vyniká jednoduchou instalací. Poţadavky na provozování Wordpressu jsou velmi základní. Server pro verzi Wordpressu 2.9 by měl minimálně podporovat:
PHP ve verzi 4.3 nebo vyšší (doporučena je verze 5.2 a vyšší nejen z důvodu vyšší bezpečnosti)
MySQL databáze ve verzi 4.1.2 nebo vyšší (doporučena verze 5.0 a vyšší)
Pro samotnou instalaci potřebujeme přístup (např. pomocí protokolu FTP) k webovému adresáři pro nakopírování sloţek a souborů, které jsme si předtím stáhli ze stránek Wordpress.org16. Pokud chceme provozovat web na doméně http://example.com, stačí nakopírovat soubory do kořenového adresáře webového serveru. Pro konfiguraci můţeme buď přejmenovat soubor wp-config-sample.php na wp-config.php a zeditovat
jej
konfigurační
(doplnit soubor
především z webu,
přihlašovací
v našem
údaje
případě
na
k databázi), adrese
nebo
vygenerovat
http://example.com/wp-
admin/setup-config.php. V konfiguračním souboru jde mj. i nastavit jazyk nebo vynutit, aby administrativní rozhraní komunikovalo přes zabezpečený protokol HTTPS. Posledním krokem je otevření adresy http://example.com/wp-admin/install.php, na které dojde k dokončení instalace (vytvoření tabulek v databázi a vloţení dat).
3.2. Struktura adresáře s instalací Wordpressu Kořenová sloţka obsahuje vedle souborů jako např. index.php i tři sloţky.
wp-admin – sloţka se soubory pro administrativní rozhraní.
15
http://wordpress.org/extend/plugins/
16
http://wordpress.org/download/ 27
wp-content – důleţitá sloţka obsahující sloţku s pluginy a sloţku s tématy (vzhledy).
wp-includes – sloţka s knihovnami, které jsou v různých částech Wordpressu pouţívány.
Výchozí instalace obsahuje dva pluginy:
akismet – modul chránící náš web před spamem.
hello – ukázkový plugin s velmi typickou hláškou „Hello World―.
Výchozí ukázková témata jsou také dvě, ale samozřejmě se předpokládá pouţití vlastních. Témata slouţí pro potřeby aplikace vlastního vzhledu na provozovaný web.
Během
okamţiku tak můţe být web vzhledově stylizovaný do podoby odpovídající jeho obsahu.
Obrázek 5: Struktura adresáře s instalací Wordpressu
28
3.3. Administrace Z administrativního rozhraní máme moţnost psát příspěvky na web, měnit vzhled webu, instalovat a nastavovat pluginy nebo zakládat nové uţivatele. Moţnosti vkládání příspěvků obsahujících obrázky, hudbu či dokonce video nejsou témata mojí práce. Stejně tak zde není prostor pro popis, jakým způsobem fungují jednotlivá témata a jakým způsobem si lze vytvořit vlastní. Proto bych se chtěl z této oblasti zmínit krátce pouze o uţivatelských právech v administrátorské části, které se dají vyuţít i při tvorbě pluginů.
3.3.1.
Správa uživatelů
Nastavení práv ostatně souvisí i s aplikacemi, které na webu poběţí. Za uţivatele nebudu v následujícím textu (pokud neuvedu jinak) povaţovat návštěvníka webové stránky, ale osoby, které mají určitá privilegia související se správou webového obsahu. Protoţe Wordpress klade důraz na snadnou obsluhu, je zřejmé, ţe vkládat a editovat stránky nemusí pouze zkušený administrátor, ale i uţivatel bez znalostí jazyka HTML. Právě z nutnosti odlišit práva jednotlivých uţivatelů na vertikální úrovni vznikly role s jiţ definovanými právy a omezeními, díky kterým například nezkušený a neznalý uţivatel nemůţe záměrně (či bez něj) poškodit fungování Wordpressu nějakým nekorektním zásahem. Přístupové úrovně a k nim uţivatelské role ve Wordpressu jsou:
Administrátor
Redaktor
Autor
Přispívající
Návštěvník
Administrátor je osoba, která má absolutní práva, tedy neexistuje nic, co by nemohl. V praxi jako jediný můţe měnit nastavení, aktivovat a deaktivovat plugin, zakládat a mazat uţivatele nebo měnit témata (vzhled) webu. Redaktorovi je povoleno psát vlastní příspěvky, navíc má moţnost editovat příspěvky ostatním uţivatelům, moderovat diskuzi nebo spravovat jednotlivé kategorie. 29
Autor můţe psát pouze vlastní příspěvky, nemůţe je v ţádném případě editovat ostatním. Přispívající má povoleno napsat příspěvek s tím, ţe před publikováním bude muset být tento příspěvek schválen administrátorem, redaktorem, nebo autorem. Návštěvník je sice registrovaným uţivatelem v administrátorské části, ale jeho práva jsou stejná s cizím návštěvníkem webu. Oba mají dovoleno pouze číst si jednotlivé příspěvky. Smysl role Návštěvník má pouze v případě, ţe chceme například někomu krátkodobě odebrat všechna práva, ale zároveň si jej uchovat jako registrovaného uţivatele. Není bohuţel moţné definovat si vlastní role. Z popisu vlastností rolí je zřejmé, ţe jednotlivé role nemají svá speciální práva, typická pouze pro ně a které by jejich nadřazená role neměla. Proto například autor má všechna práva přispívajícího a svá vlastní. Redaktor má všechna práva autora včetně svých vlastních. Administrátor má mj. právo na cokoli, co se objevilo v definici předchozích práv u jednotlivých rolí. Při psaní aplikace (v tomto případě pluginu) můţeme proto nastavit i určitá omezení, která mohou zamezit vkládání např. anket, formulářů nebo galerií s fotografiemi do stránky určitým rolím.
3.4. Wordpress hooks Různé funkce a pluginy potřebují pro svoji činnost moţnost reagovat na činnosti uţivatele nebo spíše na činnosti vyvolané samotným Wordpressem. Bude se jednat o jakési rozhraní vyţadované pluginem po prostředí, ve které běţí, aby mohly vykonávat svoji úlohu. V oficiálním dokumentu [24] se označují jako „hooks― tedy jako háčky. Ze slova je patrný tedy i jejich význam, na háčky zavěsíme naše funkce. Já bych je spíše nazval událostmi, u kterých je moţno registrovat funkce, které budou při vyvolání určité události vykonány. Wordpress pouţívá události dvojího typu: filtry – „filter― a akce - „action―. Paleta jejich pouţití je opravdu široká, současná aktuální verze Wodressu 2.9.2 obsahuje na 1142 (dle [25]) různých událostí ve formě akcí a filtrů. Pokud by nám z nějakého důvodu nestačily, můţeme si vytvořit a vyvolat vlastní události ve formě jak akcí, tak i filtrů. Filtry Filtry se pouţívají v případě, ţe chceme modifikovat základní chování Wordpressu, především se pouţívají pro modifikaci většinou textového obsahu. 30
Pokud bychom chtěli přidat logo ke všem titulkům u všech článků zobrazujících se návštěvníkovi, máme dvě moţnosti. Poţadovanou změnu můţeme promítnout přímo do šablony stránky s pouţívaným tématem vzhledu. Řešení je velmi jednoduché s pouţitím základních znalostí HTML, ale můţe nám to způsobit problémy v budoucnu, kdyţ bychom chtěli změnit vzhled webu změnou tématu nebo pouţívat více témat. V prvním případě bychom ztratili veškeré změny a provedené úpravy, v druhém případě bychom museli znovu zeditovat novou šablonu. Druhou moţností, jak docílit poţadované změny titulku, je vyuţití filtru, který zajistí změnu titulku před jeho zobrazením v prohlíţeči (v našem případě to bude přidání obrázku k textovému titulku). před
posláním
registrované
Vyuţijeme filtru s názvem the_title. Funguje tak, ţe Wordpress
samotného
k události
titulku
prohlíţeči
k zobrazení
pošle
titulek
kaţdé
funkci
the_title. Jednotlivé funkce modifikují titulek dle vlastní
implementace a vrací vţdy upravený titulek. Prohlíţeči je pak poslán výsledek zpracování všech těchto funkcí. Za určitých okolností je nutné stanovit pořadí volání jednotlivých funkcí, proto je moţné při registraci uvést i prioritu s jakou jsou volány. Definice funkce add filter pro registraci určité funkce k události [24]:
add_filter( $nazev_filtru, $nazev_registrujici_funkce, $priorita, $poce t_akceptovatelnych_argumentu ); $nazev_filtru Povinný parametr typu String udává název události, ke které bude registrována funkce, v našem případě bude the_title.
$nazev_registrujici_funkce Povinný parametr obsahující název funkce, ve které má být titulek před posláním prohlíţeči modifikován. Funkce by měla samozřejmě existovat a obsahovat návratovou hodnotu typu String. Tyto poţadované atributy však nejsou testovány Wordpressem, proto by mělo být na programátorovi zajistit a ošetřit případné chyby.
$priorita Nepovinný parametr typu integer bývá pouţit pro upřesnění priority. Defaultní hodnota je 10, pokud chceme větší prioritu, nastavíme menší hodnotu a naopak. Funkce se stejnou prioritou jsou volány v pořadí přidání do seznamu registrovaných funkcí. 31
$pocet_akceptovatelnych_argumentu Nepovinný parametr typu integer definuje počet parametrů registrované funkce. Defaultní hodnota je nastavena na 1. Příklad uţití filtru – následující kód lze vloţit do nového pluginu, nebo do souboru
functions.php,který je umístěn ve sloţce s tématem vzhledu a při kaţdém zobrazení jakékoli stránky dojde k jeho spuštění.
/* Přidání obrázku logo.gif před každý titulek */ function MujTitleFilter($title) { return ′
′.$title; }
/* Registrace funkce k události */ add_filter('the_title', 'MujTitleFilter'); Příklady dalších filtrů
the_content – filtr je aplikován na text příspěvku před jeho zobrazením comment_text – filtr je aplikován na komentář před jeho zobrazením Akce Akce jsou události vyvolané určitou činností, jakou můţe být zaloţení nového příspěvku, vloţení komentáře k příspěvku nebo změna zobrazení administrátorské stránky. Jejich pouţití je stejné jako u filtrů pouze s tím rozdílem, ţe parametr předávaný registrovaným funkcím není modifikován a slouţí pouze pro předání určité informace. Funkce nemusí proto obsahovat ţádnou návratovou hodnotu. Akce mohou být pouţívány například pro zasílání emailů při vloţení komentáře k příspěvku nebo pro úpravu vzhledu Wordpressu při určité události. Definice funkce add_action pro registraci funkce k určité události typu akce:
add_action( $tag, $function_to_add, $priority, $accepted_args ); Význam jednotlivých parametrům je naprosto analogický jako u funkce add_filter. Ukázkovým příkladem pouţití události akce můţe být poslání e-mailu v případě publikování nového příspěvku a jeho komentování. E-mail se bude posílat definovaným uţivatelům. 32
Nejprve si vytvoříme funkci, která bude posílat email. Příklad uţití akce – následující kód lze vloţit do nového pluginu, nebo do souboru
functions.php,který je umístěn ve sloţce s tématem vzhledu a při kaţdém zobrazení jakékoli stránky dojde k jeho spuštění.
//Parametr předaný událostí (ID příspěvku) function posliEmail($post_ID){ //Seznam e-mailů, na které se má e-mail poslat. $komu = '
[email protected],
[email protected]'; //S využitím funkce mail() zašleme e-mail s URL stránkou změny. mail($komu, 'Aktualizace mého blogu', 'Můj blog byl '?p='.$post_ID);
aktualizován
na
stránce:
'.get_settings('home').
} Poté registrujeme tuto funkci u poţadovaných akcí:
add_action('publish_post', 'posliEmail'); add_action('comment_post', 'posliEmail'); Jak u filtrů, tak i u akcí lze v průběhu běhu programu určitou funkci odhlásit z odběrů těchto událostí. Je důleţité poznamenat, ţe pokud ve funkci add_action/add_filter uvedeme více parametrů jako například prioritu nebo počet argumentů, je nutné při odhlašování uvést opět tyto všechny parametry ve volání funkce remove_action/remove_filter. Můţeme také globálně aktivovat/deaktivovat spouštění událostí určitého typu.
3.5. Tagy a funkce Často je potřeba v tématu nebo i v pluginech získat dynamické informace týkající se aktuální stránky nebo statické informace ohledně celého webu. Pro tyto případy Wordpress definuje tzv. tagy, které usnadňují přístup spíše ke statickým proměnným a funkce pro přístup k dynamickým proměnným. Příklady tagů [24]
get_header(), get_footer() – při zavolání vloţí záhlaví/zápatí na místo, odkud byla funkce volána. Zjednodušeně jde o vloţení obsahu souboru header.php/footer.php umístěného ve sloţce s tématem vzhledu.
33
bloginfo('name'), bloginfo('url') – vloţí název/URL adresu blogu. the_time(get_option('date_format'))
–
vypíše
aktuální
čas
dle
formátu
argumentu
můţeme
nastaveného v administraci.
wp_list_pages($args)
–
vypíše
seznam
stránek,
pomocí
specifikovat určitá omezení týkající se např. zobrazení autora stránky, data vytvoření. Můţeme také určit stránky, které se nezahrnou do výpisu.
is_admin() – zda je zobrazena stránka s administrací. Příklady funkcí [24]
get_post_meta($post_id, $key, $single) – získání meta dat k příspěvku pomocí ID a názvu proměnné. Třetím parametr parametrem si můţeme určit, zda chceme vrátit data v poli, nebo v řetězci.
get_page_uri( $page_id ) – získání URI adresy konkrétní stránky. is_page($page) – V systému Wordpress můţeme vkládat buďto statické stránky nebo příspěvky, které mohou být dynamicky přiřazeny určitým kategoriím. Funkce is_page vrací boolean hodnotu true v případě, ţe je právě zobrazena stránka. Zajímavostí u této funkce jsou moţnosti pouţití parametru. Parametr můţe obsahovat id stránky, její titulek, nebo její jedinečný název (post_name).
3.6. Zkratky pro funkce neboli „Shortcode API“ Zkratky pro funkce v podstatě znamená něco jako zkratky pro volání k nim přiřazených metod. Pouţívají se při editaci jednotlivých příspěvků a jejich přítomnost je v podstatě nutností, protoţe z principu bezpečnosti není moţné vkládat do příspěvku vedle obyčejného textu i kód php. Zásadní nevýhodou je omezení pouţití pouze na editaci obsahu příspěvku (z editoru). Zkratky nemůţeme pouţít ve vlastním PHP kódu (například při definici šablony vzhledu), zde se musí i nadále pouţívat klasické volání metod. Pokud bychom vytvořili aplikaci generující fotogalerii, můţeme ji poté vloţit do příspěvku následujícím kódem [gallery id="123" size="medium"].
34
Definice vlastní zkratky:
//Neprve definujeme funkci pro zobrazení fotogalerie function ZobrazFotogalerii($atts) { //Vnitřní implementace funkce, zobrazující jako výstup fotogalerii } //Přidání zkratky do evidence add_shortcode('gallery', 'ZobrazFotogalerii'); Pokud značka není zanesena do systému, nebude zpracována a bude vytištěna jako slovo.
3.7. Automatické zjišťování nových verzí Systém Wordpress uţ dlouho nabízí automatické oznamování o nové verzi u nainstalovaných pluginů a samotného systému. V posledních verzích přibyla i moţnost automatické aktualizace těchto součástí systému. V dotazech se porovnává naše verze s aktuální verzí dostupnou na webu. Bohuţel neexistuje ţádná dokumentace a podle oficiálního webu17 se dokumentace připravuje. Ze zdrojových kódů jsem však zjistil, ţe pomocí HTTP ţádosti se odešle na server api.wordpress.org
data,
ve
kterých
je
obsaţena
verze
nainstalovaného
systému.
18
Komunikace probíhá v obou směrech metodou POST . Detailnější pohled na systém automatického zjištění nové verze bude uveden v následující kapitole o pluginech. Proces zjištění aktuální verze systému je stejný jako zjišťování nové verze u jednotlivých pluginů.
3.8. Pluginy Pouţívání pluginu v sobě zahrnuje několik činností, které jsou nutné pro správné fungování nejen samotného pluginu, ale i celého systému. Jedná se především o proces instalace, aktivace, deaktivace a odinstalování. Kvalitní zpracování uvedených procesů má za výsledek stabilitu systému při chybách, které mohou vzniknout při instalaci, pouţívání či odinstalaci pluginů.
17
http://wordpress.org
18
Vedle metody GET je to další metoda poţadavku HTTP protokolu. Slouţí pro předávání a výměnu dat. 35
Instalace pluginu Instalací libovolného pluginu není myšleno nic jiného, neţ nakopírování sloţky s pluginem, popř. souboru do sloţky wp-content/plugins. Wordpress sloţku s pluginy prochází
pokaţdé, kdyţ administrátor načte stránku v administrátorském rozhraní se seznamem pluginů. Nově nainstalovaný plugin se objeví mezi neaktivními. Jeho pouţití není v tuto chvíli ještě moţné a jeho načtení mezi ostatní pluginy neznamená, ţe je se současnou verzí Wordpressu kompatibilní a bude fungovat. Ověření, zda je plugin schopen pracovat se ověřuje aţ při aktivaci. Aktivace pluginu Aktivací přejde plugin do stavu pouţitelného a fungujícího. Při aktivaci dochází:
Ke kontrole poţadované verze Wordpressu.
K inicializaci tabulek, které plugin bude vyuţívat, v databázi.
K inicializaci dalších bezpodmínečně nutných náleţitostí pro chod pluginu, např. vytvoření sloţky pro pluginem nově vytvářené soubory.
Ke kontrole poţadovaných oprávnění jako jsou právo zapisovat do určitých sloţek nebo např. moţnost odesílat emaily, pokud je to vyţadováno.
Pokud nejsou splněny povinné náleţitosti, plugin se neaktivuje. V případě nedostatečných práv pro vytváření sloţek se můţe plugin aktivovat, ale upozorní, ţe pro svou plnou funkčnost musí uţivatel vytvořit poţadované sloţky ručně. Aktivace nekompatibilního či
poškozeného
pluginu
můţe způsobit
pád
a
dočasnou
nefunkčnost celého systému. V takovém případě lze plugin deaktivovat pouze smazáním jeho zdrojových souborů, popř. celé jeho sloţky a Wordpress opět naběhne. Vyřešení závislostí Wordpress neumoţňuje svými mechanismy deklarovat závislost jednoho pluginu na druhém. V současné verzi není ani moţné definovat pluginy nutné pro správný běh samotného webu. Z mého úsudku předpokládám, ţe v některé z budoucích verzí se tato funkcionalita objeví. V oficiální dokumentaci se uvádí pouze odkaz na blog jednoho z vývojářů [26], který problém potřebnosti konkrétních pluginů pro zobrazení určité stránky vyřešil následujícím, velmi elegantním způsobem.
36
Na začátek stránky se umístí následující kód [26]:
Deaktivace pluginu Při deaktivaci pluginu z administrátorské části dojde k jeho přesunu mezi neaktivní. Je důleţité poznamenat, ţe nedojde ke smazání jeho dat z databáze, proto při opětovné aktivaci bude plugin pracovat se svými stejnými daty jako před svou deaktivací. Odinstalování pluginu Odinstalování pluginu se skládá z opačného úkonu neţ při instalaci. Provede se smazáním sloţky, popř. souboru s pluginem ze sloţky
wp-content/plugins. Plugin následně
zmizí se seznamu neaktivních pluginů.
37
Automatické zjišťování nové verze pluginu Pro nasazení ve firemním, nebo jako v našem případě školním prostředí by bylo vhodné při více instalacích systému a pouţívání stejných vlastních pluginů umoţnit ověřování verze pluginu i vůči jinému neţ globálnímu úloţišti. Neexistence jakékoli dokumentace mě donutila nahlédnout do zdrojových kódů, abych zjistil, jak samotný proces zjištění nové verze probíhá.
Kdy?
Aktualizace se provádí v intervalech 12 hodin. Pokud je načítána stránka v administraci se seznamem pluginů, dochází k dotazu kaţdých 60 minut.
Jak?
Pomocí HTTP ţádosti se odešle na server api.wordpress.org data ve formě POST. Odpověď je opět ve formě POST.
Kde?
Soubor s generováním dat k ţádosti update.php je umístěn ve sloţce wp-includes. Vlastní ţádost je umístěna v souboru http.php ve stejné sloţce. V obou souborech můţeme najít i zdrojový kód ke zjišťování aktualizací témat a samotného Wordpressu.
Co?
V ţádosti je uveden seznam pluginů s názvem sloţky a hlavního souboru. Dále je zasláno název pluginu, URI adresa na stránku pluginu a autora, verze, popis, titulek a další informace dostupné o pluginu. V odpovědi je naopak uvedena mj. nová verze pluginu a odkaz na její stáhnutí.
38
Ukázka žádosti k jednomu pluginu:
[nextgen-gallery/nggallery.php] => Array ( [Name] => NextGEN Gallery [PluginURI] => http://alexrabe.de/?page_id=80 [Version] => 1.4.3 [Description] => A NextGENeration Photo gallery for the Web 2.0. [Author] => Alex Rabe [AuthorURI] => http://alexrabe.de/ [TextDomain] => [DomainPath] => [Title] => NextGEN Gallery ) Ukázka odpovědi k jednomu pluginu:
[nextgen-gallery/nggallery.php] => stdClass Object ( [id] => 592 [slug] => nextgen-gallery [new_version] => 1.5.3 [url] => http://wordpress.org/extend/plugins/nextgen-gallery/ [package] => http://downloads.wordpress.org/plugin/nextgen-gallery.zip ) Při jedné provozované instalaci systému s mnoha aktivními pluginy nám tento proces můţe výrazně ulehčit práci a udrţet náš web aktualizovaný. Existují však i situace, kdy zjišťování nové verze nám můţe způsobit problémy. Představme si ukázkový modelový příklad: Škola provozuje 25 instalací systému Wordpress. Jedná se o fakultní a katedrální weby, dále o weby jednotlivých celoškolských pracovišť. Pro přihlašování uţivatelů se do všech instalací nainstaluje plugin, který ověřuje uţivatelská jména a hesla vůči vzdálenému LDAP 19 (Lightweight Directory Access Protocol) serveru. Díky tomu si není nutné pamatovat nová hesla a plugin se tak stal velmi oblíbeným. Bohuţel by plugin dostupný z globálního úloţiště musel být před svým nasazením modifikován z důvodu různých implementací místního LDAP
19
Protokol pro ukládání a přístup k datům na adresářovém serveru, kde jsou záznamy
ukládány do stromové struktury. Pouţívaný zejména pro ukládání informací o uţivatelích. 39
serveru. Správci jednotlivých webů jsou povinni nejen z důvodu bezpečnosti udrţovat celou instalaci
včetně
pluginů
aktualizovanou
a
při
vydání
nové
verze
upravený
plugin
aktualizovali, tzn., nahradili modifikovaný za novou, s místním LDAP serverem nefunkční verzi. Tímto byly ztraceny veškeré změny a plugin přestal fungovat. Nabízí se tři základní cesty, kterými se můţeme ubírat.
Zakázání aktualizace
Prvním řešením problému by mohlo být zamezení moţnosti aktualizace našeho autorizačního pluginu. Pokud bychom smazali základní informace o pluginu (například verzi), při zjišťování nové verze by nebyl způsob, jak zjistit naši aktuální verzi, a proto by se v administrátorské části nová verze k dispozici neobjevila. Pokud však rozšíříme ukázkový příklad, můţe se nám po čase stát, ţe v pluginu objevíme kritickou chybu s moţností obejít nějakým způsobem přihlašování. Jiným příkladem by mohla být změna nastavení LDAP serveru a následná nutná změna způsobu ověřování. Oba dva případy nás nutí aktualizovat plugin na ověřování uţivatelů, coţ při několika desítkách instalací můţe být problém s kontaktováním kaţdého správce webu a poprosit ho, aby si ze zaslaného odkazu stáhl novou verzi. Tento problém by však šel řešit na doposud nezmíněné, vyšší úrovni. Jednoduše by existoval jeden globální administrátor pro všechny weby a aktualizovaný a přizpůsobený plugin by nahrál na všechny současně. V našem konkrétním případě však naráţíme na vnitřní politiku a jiţ zavedená pravidla, kdy ţádný globální administrátor neexistuje a zavedení jej zpětně by bylo velmi náročné.
Úprava aktualizačních procesů převážně na straně jednotlivých instalací.
Cílem bude nejprve vytvořit vlastní místní úloţiště s upravenými pluginy. Tento server bude odpovídat na konkrétní dotazy z jednotlivých instalací Wordpressu. Ţádná aplikace ani návod na její implementaci neexistují, proto je nutné ji naprogramovat a nakonfigurovat takovým způsobem, aby na dotazy odpovídala stejnou formou jako server api.wordpress.org. Úprava na straně jednotlivých instalací Worpressu spočívá v nastavení dotazu pro určité pluginy pouze na místní server. Správce webu tedy uvidí aktualizaci pouze v případě, ţe na místní „aktualizační― server umístíme novou verzi. Pokud shrneme nabízené řešení, bude nutné zřídit sever s webovou sluţbou a napsat nový plugin, který bude pozměňovat dotazy od „klientů―.
40
Problém nastane, pokud se objeví nová verze Wordpressu, správce aktualizuje svoji instalaci, a plugin kvůli špatné kompatibilitě s novou verzí přestane fungovat. Samozřejmě, ţe autor místního autorizačního pluginu by měl okamţitě zareagovat a upravit jej, aby byl funkční i s nejnovější verzí. Existují však případy, a to i příklad s LDAP pluginem, kdy si nemůţeme dovolit ani krátkodobý výpadek jeho funkčnosti. Při výpadku by se totiţ nikdo do systému nepřihlásil.
Úprava aktualizačních procesů převážně na straně místního serveru
Další varianta řeší nedostatek s nekompatibilitou pluginu a systému. Nebudeme odkazovat na místní server pouze ţádosti ohledně našeho pluginu, ale dotazy ohledně celé instalace, včetně všech pluginů. Řešení nám zjednoduší úpravy na straně klientů, kdy pouze vyměníme adresu api.wordpress.org na api.mistniserver.cz. Varianta má ale za následek potřebu sloţitější implementace na straně serveru, kdy na něm musíme udrţovat nejen aktuální verzi našeho pluginu, ale i verze ostatních pouţívaných pluginů a samotného Wordpressu. Pokud budeme
pouze
přesměrovávat
ţádosti
na
aktualizaci
ostatních
pluginů
na
server
api.wordpress.org, dojdeme k dobrému, ale velmi náročnému řešení nejen na počáteční implementaci, ale i na pozdější údrţbu.
Konečné řešení?
Kaţdá z nabízených variant má svá pozitiva, ale bohuţel i negativa. Konečné řešení bych rozlišil dle počtu provozovaných instalací. V případě menšího počtu se jeví jako výhodnější první varianta, tedy zakázání aktualizací pro určité pluginy a snaha o definici globálního uţivatele, tedy správce, který bude dohlíţet nad společně pouţívanými pluginy. V případě, ţe by se počet instalací zvýšil nebo by nebylo moţné globálního správce definovat, jako další by se nabízela druhá varianta. Nejrobustnější, ale i nejnáročnější je poslední varianta, která je především náročná na implementaci serveru. Nakonec bych navrhl ještě jedno řešení, které je opět pomyslně na vyšší úrovni. Jde o změnu celého redakčního systému na jiný, který umoţňuje, aby existovala pouze jedna instalace systému, pluginy byly uloţeny fyzicky pouze jednou a data by byla uloţena pouze v jedné databázi. Myslím si, ţe v případě naší instituce byla podceněna právě fáze výběru redakčního systému a další nabízená řešení pro správu lokálních pluginů pouze hasí poţár,
41
který byl zaloţen jiţ zmíněným podceněním situace. Na trhu existuje řada redakčních systémů i z řad open source, vhodných pro nasazení v naší instituci daleko více.
3.9. Tvorba vlastních pluginů Plugin je program napsaný ve skriptovacím jazyku PHP, přidávající nebo rozšiřující základní funkcionalitu, vyuţívající Wordpress plugin API (Application Program Interface - aplikační programové rozhraní). Před napsáním vlastního pluginu je uţitečné vyuţít globálního úloţiště všech pluginů a zkusit najít jiţ hotový plugin, odpovídající našim poţadavkům a předejít tak zbytečné práci. Pokud ţádný nevyhovuje našim poţadavkům, musíme si vytvořit vlastní.
3.9.1.
Název pluginu
Při vytváření vlastního pluginu, pokud máme v záměru jej později hostovat v globálním úloţišti, je důleţité zvolit unikátní název. K ověření jedinečnosti můţe poslouţit hledání na http://wordpress.org/extend/plugins/ nebo jednoduše nám můţe pomoci hledání ve vyhledávači google20. Pokud bychom uvaţovali pouze o místním úloţišti, máme při výběru názvu volnější ruku.
3.9.2.
Soubory pluginu
Název souboru by měl být opět unikátní, protoţe uţivatelé si všechny pluginy umisťují do stejné sloţky (wp-content/plugins/) a při kolizi jmen by mohlo dojít k přepsání jiného. Pokud náš plugin obsahuje více souborů, můţeme je umístit do nové sloţky, u které platí podobné pravidlo s unikátním názvem. Z formálního hlediska, zvláště pokud bude plugin nabízen veřejně, je nutné přiloţit i readme soubor (dle konvencí http://wordpress.org/extend/plugins/about/readme.txt). Na začátku hlavního PHP souboru (jeho název je stejný jako název pluginu) by měly být také uvedeny základní informace ohledně názvu, základního popisu, verze, pouţité licence a URI samotného pluginu a autora.
20
http://google.com 42
3.9.3.
Ukládání dat pluginů do databáze
Při vytváření pluginů dříve nebo později vznikne potřeba ukládat data do databáze. Wordpress definuje tři základní způsoby, jak si plugin můţe uchovávat data v databázi. Liší se v podstatě pouze v tom, do jaké tabulky se ukládají. Vţdy se jedná o jednu a tu samou databázi, kterou pouţívá i celý systém.
Využití ″option″ mechanizmů
Data ukládají do stejné tabulky jako samotné nastavení systému Wordpress. Řešení je určené
především
pro
ukládání
menšího
počtu
jednotlivých
proměnných.
Ukládání
konkrétních dat se provádí přes funkci add_option. Pokud se jiţ proměnná se stejným názvem
v
databázi
vyskytuje,
je
potřeba
místo
add_option,
zavolat
metodu
update_option. add_option($name, $value, $deprecated, $autoload); $name Povinný parametr typu String udává, pod jakým názvem bude proměnná v databázi uloţena.
$value Hodnota, která má být uloţena do databáze. Defaultně je nastavena na prázdný String.
$deprecated Parametr, který jiţ není vyuţívaný, ale pro zpětnou kompatibilitu je zachován. Pokud bychom chtěli pouţít následující parametr $autoload, musíme tento uvést jako prázdný String nebo null. 43
$autoload Při nastavení na 'yes' budou data nahrána automaticky funkcí get_alloption. V opačném případě při pouţití 'no' je nutné pro získání dat zavolat metodu get_option($name).
Využití meta dat
Meta data21 neboli ″Custom Fields″ jsou data uloţená v databázi ve stejné tabulce jako stránky a příspěvky. Vţdy přísluší ke konkrétní stránce nebo příspěvku.
Vytvoření nové vlastní tabulky
Je vyuţíváno v případě potřeby uloţit větší mnoţství dat. Ve své podstatě se jedná pouze o SQL příkazy, s jejichţ pomocí jsou tabulky vytvářeny. Wordpress neobsahuje ţádné vlastní mechanismy pro zaloţení tabulek v databázi a je na autorovi pluginu, jaké tabulky s jakými atributy si vytvoří. Návod se základními pravidly je uveden v dokumentaci [24].
3.9.4.
Využití pluginu na stránce
Wordpress jako platforma nenabízí pro vývoj svých pluginů moţnost definice rozhraní, přes které je moţno přistupovat k vnitřní implementaci. Samozřejmě, ţe při dodrţování základních principů objektově orientovaného programování jako je maximální pouţití modifikátoru přístupu „private― lze částečně zajistit bezpečnost vnitřní implementace. Na vině nepřítomnosti rozhraní můţe být i nemoţnost realizace základních vlastností komponent v prostředí jazyka PHP. I přesto však máme moţnost, jak částečně rozhraní definovat, a to pomocí zkratek, neboli „Shortcode API―. Ke kaţdé funkci, která má být volána zvenku, přiřadíme zkratku, pomocí které pak konkrétní funkci voláme. Jak bylo řečeno v kapitole o zkratkách, jejich pouţití je pouze omezeno na editor příspěvků. Pokud bychom chtěli přidat funkci pluginu do šablony vzhledu, musíme přes klasické volání funkcí.
21
Meta data jsou v podstatě data o datech. Máme například stránku s nějakým obsahem a
k tomu obsahu si chceme uloţit své poznámky, a tak pouţijeme meta data. 44
3.9.5.
Umístění nastavení v administrativní části
Jako poslední nás při psaní pluginu napadne, jakým způsobem zajistit, aby administrátor mohl měnit nastavení pluginu. Pokud se budeme drţet jiţ jednou zmíněného příkladu s LDAP pluginem, musíme umoţnit administrátorovi (ten, kdo instaluje pluginy) nastavit své místní LDAP servery, vůči kterým se budou uţivatelé ověřovat. Samozřejmě lze řešit editací souborů pluginu, ale Wordpress nabízí elegantnější způsob. Kaţdý aktivovaný plugin si můţe vytvořit a umístit do administrativní časti své menu, ve kterém lze nastavovat hodnoty pro jeho správné nastavení. Stránky s nastavením lze umístit do všech jiţ existujících menu (například Nástroje, Nastavení, Pluginy) nebo si lze vytvořit v nejvyšší úrovni své vlastní menu. Ukázka vloţení vlastního menu do nejvyšší úrovně
//Pro zavolání naší funkce při zobrazení administrace použijeme akci 'admin menu' add_action('admin_menu', 'zobrazMenu'); function zobrazMenu() { // Přidání menu do nejvyšší úrovně add_menu_page('Moje Menu', 'Moje level-menu', 'nastaveniMojeMenu' );
Menu',
'manage_options',
'top-
// Přidání další položky pod menu „Moje Menu“ add_submenu_page('top-level-menu', 'Moje Podmenu', 'Moje Podmenu', 'manage_options', 'sub-page', 'nastaveniMojePodmenu'); } // nastaveniMojeMenu() zobrazi obsah stranky pro menu „Moje Menu“ function nastaveniMojeMenu() { echo "
" . 'Moje Menu'. "
"; } // nastaveniMojePodmenu()obsah stranky pro menu „Moje Podmenu“ function nastaveniMojePodmenu() { echo "
" . 'Moje Podmenu'. "
"; }
45
Obrázek 6: Nově vytvořené menu
Definice funkce add_menu_page()
add_menu_page(
$page_title,
$menu_title,
$capability,
$menu_slug,
$function, $icon_url, $position ) $page_title Název, který bude zobrazen v titulku při zobrazení stránky s nastavením.
$menu_title Nápis zobrazený přímo v menu jako odkaz na stránku s nastavením.
$capability Poţadovaná způsobilost pro zobrazení stránky uţivateli. Kaţdá z uţivatelských rolí má stanovenou způsobilost pouze k určitým akcím. U administrátora můţeme např. najít
install_plugins, install_themes. U návštěvníka naopak jenom read. $menu_slug Unikátní jméno potřebné například pro přidání další poloţky pod menu.
$function Funkce, která se zavolá pro zobrazení obsahu stránky s nastavením.
$icon_url Nepovinný parametr pro nastavení vlastní ikony pro menu.
46
$position Nepovinný parametr pro určení pozice poloţky v menu. Funkce add_submenu_page() obsahuje navíc pouze první parametr odkazující se na unikátní jméno menu, pod kterým má být tato poloţka zobrazena.
47
4. Popis současného stavu redakčních systémů na Vysoké škole ekonomické v Praze Vysoká škola ekonomická, jak uţ bylo řečeno na začátku, pouţívá pro své weby redakční systém Wordpress. V praxi se jedná řádově o 25 instalací, které provozují jednotlivé fakulty, jejich katedry a ostatní celoškolská pracoviště a jejich oddělení. Původním záměrem, s jakým se zaváděl redakční systém, bylo sjednotit vzhled jednotlivých pracovišť podle hlavního webu školy22. Protoţe web školy nepouţívá redakční systém Wordpress ani ţádný jiný, bylo nutné vytvořit nové téma (vzhled) a aplikovat ji na redakční systém. Volba redakčního systému padla na velmi oblíbený blogovací systém Wordpress, který vyniká v jednoduchosti publikování nových příspěvků a je tím schopen přispět ke snadné dostupnosti informací na internetu. Proč byl zvolen právě Wordpress nevím, ale odhaduji několik důvodů:
Zmíněná snadnost publikování
Snadná tvorba témat
Rozšiřitelnost v podobě pluginů
V základní verzi (bez dalších pluginů) je velmi rychlý s nízkými nároky na provoz
Existuje kvalitně zpracovaná dokumentace
Člověk pověřený vytvořením vzhledu pro redakční systém měl předchozí zkušenosti pouze právě s Wordpressem (Samozřejmě, ţe se jedná o moji spekulaci, ale je velmi pravděpodobné, ţe tento důvod byl moţná i nejdůleţitější.)
4.1. Popis distribuované verze Z první verze, kterou jsem měl moţnost instalovat jako web Oddělení síťové infrastruktury23 ve Výpočetním centru Vysoké školy ekonomické, jsem příliš nadšen nebyl, protoţe téma vzhledu nebylo distribuováno samostatně, ale i včetně celé instalace. Problém byl tedy v tom, ţe téma nebylo vytvořeno samostatně nezávisle na systému, ale ţe systém byl jemu přizpůsoben. To mělo několik fatálních následků, z nichţ nejdůleţitějším byla nemoţnost
22
http://www.vse.cz
23
http://osi.vse.cz 48
aktualizace samotného Wordpressu. Pokud i přesto jsem ho aktualizoval, web oddělení uţ ani vzdáleně nepřipomínal vzhled webu školy a hlásil mnoho chyb. Příčinou bylo nedodrţení konvencí pro psaní témat. Další verze jiţ podobnými neduhy netrpěly, i kdyţ je stále instalace distribuována jako celek. Naopak ale přibyly i některé pluginy určené pouze pro Vysokou školu ekonomickou.
4.1.1.
Školní pluginy
VSE data Plugin umoţňující nastavení proměnných webu z administrace, tzn. název pracoviště, telefonní číslo na pracoviště, email a podobně. Pro správnou funkčnost webu je nutné, aby zůstal plugin aktivovaný. VSE konzultacky Plugin určený spíše pro jednotlivé katedry, neţ pro celoškolská pracoviště. Plugin získává z Informačního systému školy24 seznam pracovníků (učitelů) a jejich konzultačních hodin a poté je zobrazí. VSE termíny RSS Plugin odebírá informace o dalších termínech z jiných webů a dodává je pro plugin Event Calendar. Termíny jsou budoucí akce jednotlivých pracovišť a jsou zobrazeny na kaţdé stránce nahoře. Příkladem termínu můţe být „17.5.2010 - 25.6.2010 - Zkouškové období―.
4.1.2.
Další nainstalované pluginy
Většina z nich byla pouţita pro tvorbu šablony, proto je nutné je nedeaktivovat. Bohuţel Wordpress neumoţňuje deklarovat seznam pluginů nutných pro správnou funkci a vzhled webu, a proto je v tomto ohledu zodpovědnost na správci webu. Jedná se o volně dostupné pluginy25 bez úprav, proto je moţné je aktualizovat bez následků na správné fungování webu.
24
http://isis.vse.cz
25
http://wordpress.org/extend/plugins/ 49
All in One SEO Pack Plugin má za úkol SEO (Search Engine Optimization) optimalizaci webu pro vyhledávače. V praxi upravuje odkazy na stránky, generuje automaticky META informace o stránce nebo se podílí na kanonizaci26 URL odkazů. Breadcrumb Navigation XT Z názvu je patrné, ţe se jedná o drobečkovou navigaci, která návštěvníkovi pomáhá se zorientovat, kde se právě nachází vzhledem k jednotlivým úrovním webu. Příklad drobečkové navigace na webu oddělení: Právě prohlíţíte: Hlavní stránka oddělení / Eduroam / Nastavení Eduroam Event Calendar Modul zobrazuje v horní části kaţdé stránky celoškolské termíny a termíny související s daným pracovištěm. Jejich editace je moţná z administrace. Google Analyticator Přidá nutný kód pro sledování návštěvnosti. Data se poté ze stránky posílají do systému Google Analytics27, kde jsou interpretována a umoţňují mít přehled o počtech návštěvníků, pouţívaných prohlíţečích nebo nejvíce navštěvovaných stránkách. Pro vyuţívání sluţby je nutné mít účet na serveru Google. Současný stav je takový, ţe kaţdý správce webu si zřídí svůj účet, pokud chce tuto sluţbu vyuţívat a mít přehled o návštěvnících. Neexistuje proto ţádná centrální statistika pro sledovanost a porovnání jednotlivých webů. Google XML Sitemaps Plugin vygeneruje XML soubor, který se umístí do kořenové sloţky a následně pomáhá při indexaci webu vyhledávači. V souboru je obsaţena mapa stránek
celého webu. Plugin
umoţňuje i automatické upozorňování vyhledávačů, ţe byl vygenerován nový soubor (XML soubor se generuje např. při zveřejnění nového příspěvku). Jedná se o oboustranně prospěšnou sluţbu, protoţe nám to pomáhá okamţitě informovat „svět― o změnách na našem webu a vyhledávačům pro jejich kvalitnější výsledky a sníţení zátěţe při indexaci. 26
Vyhledávače nepoznají, pokud více odkazů odkazuje na stejnou stránku. V takovém případě ji povaţují za novou. Klasickým příkladem chyby můţe být pouţití doménového jména s prefixem www a bez něj. Řešení je pomocí HTTP přesměrování typu 301. 27
https://www.google.com/analytics/ 50
Search Pages Modul pro pokročilejší vyhledávání v příspěvcích. TinyMCE Advanced Dokonalejší verze editoru příspěvků nabízející více moţností pro práci s tabulkami nebo obrázky. Mimo to je ve školní distribuci umoţněno zvolit, aby se příspěvek zobrazoval pouze po přihlášení, a to buď pouze studentům, pouze zaměstnancům, všem, anebo definovaným uţivatelům.
4.2. Úpravy v oddělení Jako první vznikl poţadavek od zaměstnanců našeho oddělení na změnu přihlašování. Je nutné, aby si uţivatel nemusel pamatovat nové heslo do systému, ale aby byl vyuţit některý z LDAP serverů pro ověřování. Tento typ ověřování pouţíváme i v jiných aplikacích a velmi se nám osvědčil. Z globálního
úloţiště
jsem
vyzkoušel
několik
pluginů,
ale
ţádný
z nich
nefungoval
s nastavením, které bylo k dispozici. Vţdy byl nutný zásah do zdrojových kódů, a proto pro přihlašování přes naše LDAP servery jsem upravil plugin Simple LDAP Login. Dále z našeho oddělení vzešel poţadavek na aplikaci Vstupy, která by měla umoţnit uţivatelům po přihlášení na webu vyplnit a odeslat e-mailem formulář s poţadavkem o nastavení vstupů do určitých místností. Pro tento případ jsem nainstaloval plugin Contact Form 7, který umoţňuje vkládat do stránky předem nadefinovaný formulář a odeslat ho emailem. Zde jsem také musel zasáhnout do zdrojových kódů, protoţe jako odesílatele ţádosti bylo potřeba uvést e-mail přihlášeného uţivatele. Pro potřeby dostupnosti našeho webu i v jiných jazycích, neţ jen českém, jsem doinstaloval plugin Google Translator. Na kaţdé stránce si můţe návštěvník zvolit jazyk, do kterého má být pomocí sluţby Google Translate28 přeloţena. Kvůli zvyšujícímu se trendu pouţívání webového prohlíţeče v mobilních telefonech jsem nainstaloval plugin WordPress Mobile Edition. Návštěvníkům přistupujícím z mobilního telefonu se zobrazí jiný, pro mobilní telefony přívětivější vzhled. Současné téma je totiţ pro
28
http://translate.google.com/ 51
mobilní přístroje velký problém zobrazit jak z hlediska samotného vzhledu, tak i z mnoţství potřebných dat pro jeho zobrazení. Ze zkušenosti se na některých zařízeních nezobrazí vůbec. Web mj. provozujeme na serveru webhosting.vse.cz, kde jsou nainstalovány i další např. fakultní weby. Od prvního dubna vzešla platnost nového předpisu [27] stanovujícího pravidla provozování webů na serveru webhosting.vse.cz. V bodě 16 se píše „Zálohování dat provádí správce domény ve své režii.― Pro zálohování databáze s daty jsem proto nainstaloval plugin WordPress Database Backup, který umoţňuje v pravidelných intervalech zaslat zálohu databáze na email. Protoţe změn na webu se neděje tolik, máme nastavenou zálohu jednou týdně.
4.3. Zhodnocení současného řešení Současný stav hodnotím pouze jako dobrý. Zavedení jednotného vzhledu kladně přispělo ke snadnější orientaci návštěvníků na jednotlivých webech a k celkově lepšímu pohledu na školu jako celek například pro nové uchazeče o studium. Dříve měla jednotlivá pracoviště a fakulty vlastní weby s vlastním, naprosto odlišným vzhledem. Protoţe je cílem, aby jednotný vzhled pouţívala všechna celoškolská pracoviště, lze poté jednodušeji poznat, zda se jedná opravdu o oficiální stránky oddělení nebo pouze o stránky nějakého zaměstnance. Pro administrátory a přispívající se také zjednodušila situace, protoţe nyní je velmi snadné uveřejnit novou aktualitu nebo pozměnit stávající stránku tak, aby byly na webu stále aktuální informace. Problém ale vidím v tom, ţe změna na jednotný vzhled nebyla provedena s dlouhodobějším výhledem. Škola začala pouţívat svůj stávající vzhled v lednu roku 2007. První redakční systém s centrálním vzhledem určený pro ostatní pracoviště se objevil za rok a půl, tedy na podzim 2008. Přechod byl velmi postupný, můţeme říci aţ pomalý a aţ koncem roku 2009 byla většina ostatních webů předělána do nového vzhledu. Přitom stále mluvíme o vzhledu, který, dle mého názoru, neodpovídá dnešním trendům a době plně interaktivních webových prezentací. A navíc se s další změnou vzhledu nedá v blízké době příliš počítat, protoţe většina webů jej změnila aţ v posledních měsících. V kapitole o automatických aktualizacích jsem nastínil další problém při pouţívání společných pluginů určených a upravených pouze školu. Jejich distribuce je kvůli oddělené administraci 52
jednotlivých instalací velmi sloţitá a nelze ani zajistit, aby jednotlivý správci udrţovali svůj web aktualizovaný. Centrálnější řízení více instalací není bohuţel při pouţití systému Wordpress moţné. Bylo by třeba zvolit úplně jiný systém, určený pro podobný typ nasazení a ne blogovací systém typu Wordpress, primárně určený pro oddělenou, na sobě nezávislou instalaci.
4.4. Doporučení a návrh budoucího řešení
Vytvořit nový design webu školy nejlépe formou zakázky profesionální firmě, která vytvoří i šablonu pro provozovaný redakční systém (není podmínkou Wordpress, většina redakčních systémů počítá se změnou a personalizací vzhledu).
Zvolit jiný redakční systém, který více odpovídá nasazení pro jednotlivá pracoviště jedné instituce z důvodu lepšího centrálního řízení a sledování. Na konci psaní mé práce (17. Června 2010) vyšla nová verze redakčního systému Wordpress (verze 3.0), která v sobě nese moţnost centrálního řízení více webů, které budou součástí pouze jedné instalace. V praxi jsem však nestihl otestovat moţnosti centrálního přístupu, jehoţ zavedení vzhledem k současné situaci by samozřejmě přineslo dost práce.
Pokud nebude moţno splnit předchozí bod, navrhoval bych definovat ve všech instalacích pouze jednoho administrátora, který bude pro všechny weby stejný a bude zodpovídat za funkční a aktualizovaný systém.
53
Závěr V mé práci jsem se pokusil v teoretické části popsat moţnosti vývoje webové aplikace s vyuţitím komponentového přístupu a dokázat komponentovou architekturu v redakčním systému Wordpress. Mimo to jsem popsal moţnosti tvorby vlastních komponent v tomto redakčním systému. V poslední praktické kapitole jsem popsal současný stav provozování redakčních systémů na Vysoké škole ekonomické v Praze a pokusil se shrnout výhody a nevýhody, které z něj plynou. Mezi výhodami bych zmínil snadnost v publikování nových příspěvků a stejný vzhled webových stránek jednotlivých pracovišť. Mezi nevýhodami bych však uvedl nemoţnost centrálního řízení jednotlivých instalací. Došel jsem proto k závěru, ţe současný typ redakčního systému (jedná se o blogovací systém) je nevhodný pro nasazení v institucích s více samostatnými pracovišti jako například škola, protoţe je primárně určen pouze pro samostatné nasazení jedné instalace. Dále jsem navrhl doporučení pro současný stav a snaţil se tak přispět nejen svými, ale i nápady z literatury k problematice nasazení redakčního systému v instituci s více pracovišti. Klíčovým poznatkem, ke kterému jsem došel, je důraz na počáteční fázi v zavádění redakčního systému, především pak na správnou volbu tohoto systému. Kritériem výběru by měla být mj. především jiţ zmíněná moţnost centrální správy jednotlivých instalací. Počáteční fáze je také důleţitá proto, ţe pokud později naráţíme na problémy, tak je pouze řešíme jako dílčí, ale neuvědomujeme si, ţe hlavní příčina byla právě na začátku. Důraz by měl být kladen také na design, který musí v dnešní době upoutat, aby si web získal nové návštěvníky. Myslím si však, ţe moje závěry a doporučení nejsou v naší instituci v současné chvíli uskutečnitelné, protoţe naráţí na jiţ zavedený a provozovaný systém, se kterým jsou uţivatelé a samotné vedení do jisté míry spokojeni. I přes všechny mnou vyjmenované nedostatky se totiţ jedná v kaţdém případě o krok vpřed oproti dřívějšímu stavu. Jako rozšíření mé práce do budoucna bych si představoval detailnější návrh řešení nebo podrobnější srovnání jiných dostupných redakčních systémů, vhodnějších pro podobné nasazení. Na uvedeném srovnání bych ukázal výhody, které by přineslo nové řešení.
54
Seznam použité literatury 1. WILLIAMS, Sara a KINDEL, Charlie. The Component Object Model: A Technical Overview. COM General Technical Articles. [Online] Microsoft Corporation, 1994. [Citace: 12. Duben 2010.] http://msdn.microsoft.com/en-us/library/ms809980.aspx. 2. IBM. Rational Unified Process - oficiální příručka k metodice. [Online] IBM, 1987-2005. [Citace: 10. Březen 2010.] http://kitscm.vse.cz/RationalUnifiedProcess/. 3. OMG. OMG Unified Modeling Language. [Online] Object Management Group, Březen 2000. [Citace: 4. Červen 2010.] http://www.omg.org/spec/UML/1.3/PDF/index.htm. 4. KRUCHTEN, Philippe. Architectural Blueprints—The ―4+1‖ View. [Online] Rational Software Corp., Listopad 1995. [Citace: 5. Červen 2010.] http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf. 5. SZYPERSKI, Clemens. Component Software: Beyond Object-Oriented Programming. Great Britain : Pearson Education Limited, 2002. ISBN: 0-201-74572-0. 6. KOZACZYNSKI, Wojtek. Composite Nature of Component. [Online] USA : Rational Software, 1999. [Citace: 5. Červen 2010.] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.4634&rep=rep1&type=pdf. 7. GARTNER, Group. Component Ware: Categorization and Cataloging. [Online] Gartner Group, 1997. http://www.gartnergroup.com. 8. D'SOUZA, Francis a WILLS, Alan Cameron. Objects, Components and Frameworks with UML: the Catalysis Approach. www.catalysis.org. [Online] Addison Wesley Longman, 1999. [Citace: 5. Červen 2010.] www.catalysis.org/books/ocf/Front-Matter.pdf. 9. LEWANDOWSKI, Scott M. Frameworks for Component Based. [Online] Brown University : Department of Computer Science, 1998. [Citace: 5. Červen 2010.] http://www.cs.brown.edu/~scl/files/ClientServerComponents.pdf. 10. HERZUM, Peter a SIMS, Oliver. Business Components Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. New York, NY (USA) : John Wiley & Sons, Inc., 2000. ISBN:0471327603. 11. OMG. OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2. [Online] OMG, Listopad 2007. [Citace: 5. Červen 2010.] http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/. 12. HEINEMAN, George T. a COUNCILL, William T. Component-Based Software Engineering: Putting the Pieces Together. [Online] Boston (USA):Addison-Wesley Longman Publishing Co., Inc., 2001. [Citace: 25. Duben 2010.] http://books.google.com. ISBN:0201-70485-4. 13. STOJANOVIC, Zoran. A Method for Component-Based and Service-Oriented Software Systems Engineering. [Online] Scientific Commons, 2005. [Citace: 28. Březen 2010.] http://www.scientificcommons.org/1416494. 14. BOOCH, Grady, RUMBAUGH, James a JACOBSON, Ivar. The unified modeling language user guide. [Online] Addison Wesley, 1998. [Citace: 5. Červen 2010.] http://www.dcc.fc.up.pt/~zp/aulas/0607/es/geral/bibliografia/Addison%20Wesley%20%20The%20UML%20User%20Guide.pdf. ISBN: 978-0201571684. 15. KOSEK, Jří. Validace dokumentů XML. XML pro každého. [Online] Jiří Kosek, 2005. [Citace: 29. Duben 2010.] http://www.kosek.cz/xml/2005vecery/. 55
16. The Open Group Architecture Framework. TOGAF information web site. [Online] The Open Group, 2009. [Citace: 29. Duben 2010.] http://www.togaf.info/togaf9/chap02.html. 17. HEIMBIGNER, Dennis, a další. An Architecture for Post-Development Configuration Management in a Wide-Area Network. [citeseerx.ist.psu.edu] Colorado : University of Colorado, 1997. ISBN:0-8186-7813-5. 18. BELGUIDOUM, Meriem a DAGNAT, Fabien. Analysis of deployment dependencies in software components. [ACM Portal] France : ENST Bretagne, 2006. 19. CRNKOVIC, Ivica, a další. Specification, Implementation, and Deployment of COMPONENTS. [ACM Portal] 2002. 20. KONEČNÝ, Vladimír. Materiál k výuce předmětu Informační systémy. [Online] Mendelevova univerzita v Brně, 2006. [Citace: 28. Březen 2010.] https://akela.mendelu.cz/~loucka/studium/7sem/IIS/p%f8edn%e1%9aky/kapit3.doc. 21. BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. Praha : Grada, 2005. str. 163. ISBN: 80-247-1075-7. 22. BARŤOŇ, Lukáš. CZJUG - Eclipse RCP vs. NetBeans RCP. Audiovizuální centrum studentů ČVUT. [Online] Czech Java User Group, 2007. [Citace: 15. Červen 2010.] http://www.avc-cvut.cz/avc.php?id=4875. 23. VOGEL, Lars. Rich Client Platform. [Online] The Eclipse Foundation, 21. Prosinec 2009. [Citace: 15. Červen 2010.] http://wiki.eclipse.org/index.php/Rich_Client_Platform. 24. WORDPRESS.ORG. Wordpress Codex - Developer Documentation. Wordpress.org. [Online] Wordpress.org, 2009. [Citace: 22. Duben 2010.] http://codex.wordpress.org/Developer_Documentation. 25. BROWN, Adam. WordPress Hooks Database. [Online] Brigham Young University: Department of Political Science, 28. Srpen 2009. [Citace: 22. Duben 2010.] http://adambrown.info/p/wp_hooks/version/2.9. 26. LEIGHTON, Jonathan. WordPress: Plugin dependencies. Blog. [Online] 13. Září 2005. [Citace: 22. Duben 2010.] http://jonathanleighton.com/blog/2005/09/13/wordpress-plugindependencies/. 27. ŠESTÁKOVÁ, Eva Cirkvová. Pravidla pouţívání serveru webhosting.vse.cz. Předpisy VŠE. [Online] Vysoká škola ekonomická v Praze, 1. Duben 2010. [Citace: 15. Červen 2010.] http://www.vse.cz/predpisy/232. 28. W3SCHOOLS. AJAX Tutorial. W3Schools. [Online] Refsnes Data. [Citace: 22. Červen 2010.] http://www.w3schools.com/ajax/default.asp. 29. ATKINSON, Colin a BAYER, Joachym. Component-based product line engineering with UML. [Online] London (Great Britain) : Personal Education Ltd, 2002. [Citace: 9. Červen 2010.] http://www.google.com/books?hl=cs&lr=&id=o4rYM7aqJQoC&oi=fnd&pg=PR17&dq=Compo nent-Based+Product+Line+Engineering+with+UML&ots=daVr9k8Dsr&sig=ptdyswZLZzMuIPMP2sDyNSfbPM#v=onepage&q&f=false. 30. IBM, staff. Rational Unified Process: Best practices for software development teams. IBM - Technical library. [Online] 1998. [Citace: 15. Březen 2010.] http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best practices_TP026B.pdf.
56
31. FIELDING, R. a další. POST - Method Definitions. Hypertext Transfer Protocol. [Online] The Internet Society, 1999. [Citace: 13. Červen 2010.] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html. 32. BĚHÁLEK, Marek. COM vs .NET komponenty. Komponenty COM a distribuované aplikace. [Online] Vysoká škola báňská, Technická univerzita Ostrava, 2007. [Citace: 11. Duben 2010.] http://www.cs.vsb.cz/behalek/vyuka/pcsharp/text/ch10s03.html. 33. BELLISSARD, Luc, a další. Component-based programming and application management with olan. Object-Based Parallel and Distributed Computation. Heidelberg : Springer Berlin, 1996, stránky 290-309. 34. WILLS, Alan Cameron. Component Based Development. Software practice advancement. [Online] TriReme International Ltd, 1998. [Citace: 8. Červen 2010.] http://www.bcs-spa.org/resources/BCSOOPSNL/Issue34Summer1998/Articles/wills.pdf. 35. MICROSOFT. .NET Framework. [Online] Microsoft corporation, 2004. [Citace: 11. Duben 2010.] http://www.microsoft.com/net/.
57
Terminologický slovník Webová aplikace Asynchronous JavaScript and XML
Webová aplikace je aplikace přístupná přes webový prohlíţeč. [autor] AJAX
Framework
Component object model
Je způsob vyměňování dat se serverem pro změnu obsahu stránky bez nutnosti její aktualizace. [28] Framework je softwarová struktura obsahující programy, knihovny nebo i návrhové vzory, které poskytují funkcionalitu celé aplikaci.
COM
Java
„Component object model (COM) je jazykově nezávislý binární standard uvedený firmou Microsoft v roce 1993.― [1] Objektově orientovaný programovací jazyk.
Hypertext Preprocessor
PHP
Skriptovací programovací jazyk.
Content Managment System
CMS
Systém pro správu webového obsahu (někdy také nazýván redakčním systémem). [autor]
HyperText Markup Language
HTML
Jeden z jazyků pro vytváření webových stránek. [autor]
Application Program Interface
API
Aplikační programové rozhraní.
Common Object Request Broker Architecture
CORBA
Platformě nezávislá komponentová architektura. [autor]
Unified Modeling Language
UML
Jazyk pro grafický návrh a vizualizaci systémů. [11]
Rich Client Platform
RCP
Komponentová platforma umoţňující tvorbu i vlastních komponent. [23]
Lightweight Directory Access Protocol
LDAP
Protokol pro ukládání a přístup k datům na adresářovém serveru, kde jsou záznamy ukládány do stromové struktury. Pouţívaný zejména pro ukládání informací o uţivatelích. [autor]
Rational Unified Process
RUP
Metodika pro vývoj software s komponentovým přístupem. [2]
58
