Posun funkčnosti Office Automation v éře Cloud

Posun funkčnosti Office Automation v éře Cloud

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 ′<img src="logo.gif" alt="logo">′.$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]:
<?php
//seznam potřebných pluginů uložených v poli
$required_plugins = array(
'plugin_fn1',
'plugin_fn2',
'plugin_fn3'
);
$missing = array();
foreach ($required_plugins as $plugin)
//oveření, zda požadvaný plugin existuje a je aktivní
if (!function_exists($plugin) && !class_exists($plugin))
$missing[] = $plugin;
//pokud některý z požadovaných pluginů není nainstalován, ukončí se
načítání stránky
if (!empty($missing)) {
header('Content-Type: text/plain');
foreach ($missing as $plugin)
echo "Required plugin '$plugin' is missing\r\n";
die();
}
?>
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
<?php
/*
Plugin Name: Název pluginu
URI: http://URI_kde_je_popsán_plugin_s_možností_stáhnutí_nové_verze
Description: Krátký popis pluginu.
Version: Verze pluginu, např.: 1.0
Author: Jméno autora pluginu.
URI: http://URI_s_licencí: např.: GPL2
*/
?>
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 "<h2>" . 'Moje Menu'. "</h2>";
}
// nastaveniMojePodmenu()obsah stranky pro menu „Moje Podmenu“
function nastaveniMojePodmenu() {
echo "<h2>" . 'Moje Podmenu'. "</h2>";
}
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