České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Systém pro správu obsahu Zdeněk Janura
Vedoucí práce: Ing. Božena Mannová, M. Math. Studijní program: Informatika a výpočetní technika leden 2008
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu § 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Radeníně dne 14.1.2008
.................................................................
2
Abstract This master thesis deals with Content Management System (CMS). The requirements and features of the system are defined. The several other products with same properties are presented. Behavior, functionalities and user interface are specified. The analysis results are described by UML diagrams. The implementation environment and tools are selected. The program was design, implemented and tested. The evaluation of the work and couple of improvements are presented at the end of thesis.
Abstrakt Tato diplomová práce se zabývá systémem pro správu obsahu. Jsou předloženy požadavky na tento systém a na jejich základě jsou stanoveny jeho vlastnosti. Je představeno několik podobných produktů. Je provedena analýza systému. Chování, funkce a uživatelské prostředí jsou popsány pomocí UML diagramů. Na základě analýzy je vybráno implementační prostředí a nástroje k realizaci. Program byl navržen, implementován a následně otestován. Práce obsahuje i pojednání o přínosu realizované webové aplikace a možných směrech jejího vývoje a dalšího zdokonalování.
3
1. Úvod ........................................................................................................ 10 1.1. Motivace ............................................................................................. 10 1.2. Cíle práce ............................................................................................ 11 2. Popis systému .......................................................................................... 13 2.1. Obecné požadavky uživatelů .............................................................. 13 2.2. Obecné vlastnosti ................................................................................ 14 2.3. Využití aplikace z pohledu práva ....................................................... 14 3. Srovnání stávajících řešení na trhu .......................................................... 17 4. Analýza .................................................................................................... 25 4.1. Požadavky a vlastnosti systému.......................................................... 25 4.2. Kontextový diagram ........................................................................... 27 4.3. Model jednání ..................................................................................... 28 4.4. Stavový diagram ................................................................................. 29 4.5. E-R schéma databáze .......................................................................... 31 4.5.1. cms_admingroups ............................................................................... 32 4.5.2. cms_forms........................................................................................... 32 4.5.3. cms_menulab ...................................................................................... 34 4.5.4. cms_fieldlab ........................................................................................ 34 4.5.5. cms_structform ................................................................................... 35 4.5.6. cms_authors ........................................................................................ 35 4.5.7. cms_seting .......................................................................................... 35 4.5.8. cms_usergroup .................................................................................... 36 4.5.9. cms_htmlpart ...................................................................................... 36 4.5.10. cms_structtable .............................................................................. 36 4.6. Architektura ........................................................................................ 36 5. Návrh ....................................................................................................... 38 5.1. Výběr platformy.................................................................................. 38 5.2. SQL vrstva .......................................................................................... 39 5.3. Aplikační a prezentační vrstva............................................................ 40 6. Realizace ................................................................................................. 42 6.1. Tvorba struktury databáze .................................................................. 42 6.2. SQL vrstva .......................................................................................... 43 6.3. Session ................................................................................................ 46 6.4. Autentizace ......................................................................................... 47 6.5. Konfigurační soubor ........................................................................... 47 6.6. Odkaz webové aplikace ...................................................................... 49 6.7. prezentační vrstva webové aplikace ................................................... 49 6.7.1. Konstruktor table třídy table ............................................................... 50 6.7.2. Funkce get_fieldlabels ........................................................................ 50 6.7.3. Funkce data ......................................................................................... 50 6.7.4. Funkce selectform............................................................................... 50 6.7.5. Funkce screenform.............................................................................. 51 6.7.6. Funkce screen ..................................................................................... 51 6.7.7. Funkce show ....................................................................................... 52
4
6.8. Dokumentace ...................................................................................... 52 7. Testování ................................................................................................. 53 7.1. Explorativní technika testování .......................................................... 53 7.2. Jednotkové testování ........................................................................... 53 7.3. Zátěžové testy ..................................................................................... 54 7.4. Závěr z testování ................................................................................. 55 8. Závěr ........................................................................................................ 56 8.1. Přínos .................................................................................................. 56 8.2. Možné zlepšení webové aplikace ....................................................... 57 8.2.1. Automatická tvorba odkazu pro menu v tabulce cms_admingroups .. 57 8.2.2. Dynamická kontrola vstupních dat a maska pole ............................... 58 8.2.3. Tvorba reportu .................................................................................... 59 8.2.4. Přidání dalších dávek pro databáze..................................................... 60 8.2.5. Autentizace za pomoci úložné procedury ........................................... 60 8.2.6. Trigger pro změnu záznamu ............................................................... 61 8.2.7. Ajax pro vyhledávání a nápovědu ...................................................... 62 8.3. Závěr ................................................................................................... 62 Použitá literatura ............................................................................................... 63
5
Struktura diplomové práce Diplomová práce se skládá z deseti kapitol, které popisují postupný vývoj webové aplikace. Následně uvádím stručný přehled kapitol a jejich obsahů:
Kapitola 1 – Úvod Kapitola popisuje stávající stav v oblasti systémů pro správu obsahu. Zároveň vymezuje cíl diplomové práce a uvádí motivaci.
Kapitola 2 – Popis systému Tato kapitola se soustřeďuji na popis vlastností, které by měl systém mít, a které očekává uživatel. Následně provádím sumarizaci těchto požadavků a nastiňuji směr, kterým se budu při dalším vývoji ubírat. Zároveň zde upozorňuji na právní hlediska v souvislosti s využitím aplikace a na konflikty, které by mohly nastat při jejím používání.
Kapitola 3 – Srovnání stávajících řešení na trhu Zde popisuji, jak je definována CMS ( Content Management System ) aplikace, představuji několik existujících řešení, která se blíží funkčností a stavbou mé budoucí aplikaci. Konkrétně se jedná o aplikace Drupal, Joomla a RS2. V závěru provádím celkové zhodnocení výše jmenovaných a srovnávám je s mými očekáváními.
Kapitola 4 – Analýza V této kapitole začínám s tvorbou vlastní aplikace. Je zde několik UML schémat, z kterých jsem vycházel a která jsem použil při vývoji. Jmenovitě jsou to kontextový diagram, model jednání, stavový diagram, E-R schéma databáze a v neposlední řadě i architektura systému.
Kapitola 5 – Návrh Na základě výsledků analýzy přistupuji k hledáním vhodného programového vybavení, které bych mohl použít pro webovou aplikaci. Zvoleným systémem je EasyPHP. Představuji třídu sql pro komunikaci s databází a prezenční vrstvu aplikace.
Kapitola 6 – Realizace V této kapitole jsou popsány jednotlivé kroky realizace. Instalace programové
6
vybavení pro implementaci - webový server s podporou PHP a databázi MySQL, tvorba struktury databáze podle E-R schématu a tvorba sql třídy, která při patřičném rozšíření komunikuje s většinou dnešních databázi. Tuto třídu využívám při tvorbě modulárního systému.
Kapitola 7 – Testování V této části popisuji testy, které jsem prováděl buď v průběhu aplikace , nebo až po jejím vytvoření. Na jejich základě byla webová aplikace postupně upravována a vylepšována až do stávající podoby.
Kapitola 8 – Závěr Závěrečná kapitola shrnuje výsledek mé práce na systému pro správu obsahu. Uvádím zde i další možnosti, jak by se aplikace mohla v budoucnu vylepšit, aby se stala kvalitnějším a konkurenceschopnějším produktem.
7
Seznam zkratek CMS - Content Management System UML - Unified Modeling Language PHP - Personal Home Page WWW - Word Wide Web PHP - Personal Home Page SOA - Service Oriented Architecture WSDL - Web Service Description Language SOAP - Simple Object Access Protocol HTTP - Hypertext Transfer Protocol HTTPS - Hypertext Transfer Protocol Secured HTML - HyperText Markup Language ECM - Enterprise Content Management GNU/GPL – akronym GNU's Not UNIX /General Public License RSS - Rich Site Summary SQL - Structured Query Language URL - Uniform Resource Locator CSS – Cascading Style Sheets ASP - Active Server Pages .NET - „dotnet“ - network CGI - Common Gateway Interface IIS - Internet Information Services
8
Seznam obrázků obr. 1 - Systém Drupal 1 obr. 2 - Systém Joomla obr. 3 - Systém RS2 obr. 4 - Kontextový diagram obr. 5 - Model jednání obr. 6 - Stavový diagram obr. 7 - E-R schéma databáze obr. 8 - Architektura systému obr. 9 - Layout systému obr. 10 - Úvodní obrazovka systému s menu obr. 11 - Zobrazení záznamů po výběru položky menu obr. 12 - Detail záznamu v dvou sloupcovém layoutu
9
1. Úvod V dnešní době je k internetu připojen téměř každý a využívá ho k vyhledání nebo sdílení informací. Je tedy třeba mít nějaký předpřipravený software, který pomůže umístit data na web a dovolí je dále zpracovávat. Takovýmto typem je Content Management System (CMS). Momentální situace je taková, že je možné si vybírat z velké množiny produktů a budoucí uživatel takového systému musí vědět, co od něho bude požadovat a podle těchto požadavků vybrat vhodný model. Jednou z nejdůležitějších vlastností CMS je možnost organizovat si obsah, který může být různého druhu, od obyčejného textu, přes nějaký formátovaný dokument až k audio vizuálním dílům. Při častém používání se databáze postupně rozrůstá a uživatelé začínají oceňovat další funkce typu vyhledávání a filtrace záznamů, tvorbu reportů nebo rychlost s jakou systém pracuje při vyšším vytížení Pokud vynechám základní funkčnost, která se dnes již od systému pro správu obsahu očekává, tak hlavním motorem jsou přídavné moduly, tedy modularita. Pak možnost vystavět takový CMS, který nejlépe vyhovuje požadavkům a potřebám. Právě tímto směrem se dnes většina těchto systémů ubírá, zájemcům je nabídnuto jádro a dlouhý seznam s rozšířeními, které je k němu možno přidat. Pravděpodobně bych ještě měl zmínit fakt, že s růstem internetu se přestěhovaly tyto aplikace z intranetových sítí na WWW (Word Wide Web), kde je k nim pak možno přistupovat z celého světa.
1.1. Motivace Webové aplikace používají pro zobrazení dat prezenční vrstvu. Ta má pod sebou vrstvu datovou, z které čerpá informace pro zobrazení. Pro větší dynamičnost a možnosti je dobré prezenční vrstvu rozdělit na bloky, které by měly být vzájemně autonomní tak, aby byla podpořena modularita a možnost libovolného uspořádání webové aplikace jako celku. Pak může z modulů vzniknout několik podobných, ale funkčně odlišných aplikací velmi rychle, protože všechny moduly jsou předpřipravené a jediné, co musíme udělat, je tyto moduly patřičným způsobem uspořádat. Webové aplikace, které splňují tyto parametry, jsou nazvány Service Oriented Architecture (SOA) aplikace. Velký přínos má SOA u velkých společností, kde již implementovali tyto principy do svých podnikových procesů a informačních systémů.
10
I když je to již delší dobu, co se začalo o tomto přístupu diskutovat, je nasazení SOA inkrementální postup. Klienti jsou v různých fázích připravenosti na SOA a ti, kteří se již rozhodli pro její nasazení, jsou v různé fázi její implementace. Na SOA můžeme mít náhled jako na životní cyklus, a to z toho důvodu, že při implementaci se pokračuje po fázích, čili inkrementálně. Proto byl zaveden model označující připravenost, tzv. SOA maturity model, definující úroveň implementace. Při použití tohoto přístupu nedosáhneme okamžitě výsledků, ty se nám projeví až po delší době, musí se hodnotit po delším čase po změnách a úpravách, které je nutné provést. Samozřejmě je dobré sledovat průběh změn a mít možnost je ovlivňovat správným směrem. Tedy vědět o tom, co se ve firmě děje. V naší republice je implementace SOA v raných fázích a je třeba ještě počkat, než i u nás „vyspěje“. Při pohledu na SOA jako technologii se jedná o nový způsob návrhu a implementaci aplikací. Celková aplikace je poskládána z jednotlivých částí služeb, které jsou vzájemně nezávislé. Jsou to tedy komponenty mající přesně definované rozhraní pro určitou funkčnost. Tyto služby jsou bezstavové a jsou popsané pomocí standardizovaného rozhraní WSDL (Web Service Description Language) a komunikace probíhá za pomoci protokolu SOAP, v transportním kanálu uvedeném v rozhraní. WDSL a SOAP jsou základem webových služeb. Pro transport na internetu se používají dnes nejčastěji protokoly HTTP a jeho zabezpečená forma HTTPS. Pokud máme připraveno dostatečně velké množství nezávislých služeb, můžeme na jejich základě vytvářet celkovou aplikaci. Často jsou jednotlivé služby implementací fungujícího procesu, který se často používá a je snaha o jeho zrychlení při nasazení. Při tomto způsobu konstrukce aplikace za pomoci architektury zaměřené na služby (Service Oriented Integration) získáme mnoho výhod a dojde k ušetření velkých nákladů při dalším vývoji. Dokud byl obsah webu statický, tak nebylo možno tento způsob použít a vývoj firemních aplikací byl nákladný. Bylo potřeba stvořit protokoly pro přenos a datové slovníky, které se budou schopny navzájem dorozumět. Teprve když se objevila možnost použít služby a s ní spojenou architekturu SOA, odpadly tyto přebytečné náklady a zrychlil se tím vývoj celé aplikace.
1.2. Cíle práce Cílem práce je vytvořit webovou aplikací, která by napomohla k rychlému vývoji vzájemně podobných webových aplikací pro uchovávaní dat. K jejím
11
dobrým vlastnostem by mělo přispět to, že bude platformově nezávislá a tedy budu mít možnost ji použít na dnes běžných operačních systémech. Další výhodou, kterou bude obsahovat, bude možnost použít velké množství dnes používaných databází. To jí zajistí širokou datovou základnu oproti dnešním systémům pro správu obsahu, které jsou omezeny na používání jedné a jen výjimečně více aplikací. Zároveň pro zajištění jejího budoucího vývoje se bude skládat z komponent a nebude tedy problém nějakou přidat a začít ji používat. Bude se jednat o systém typu CMS - systém pro správu obsahu. Jednou z komponent bude vrstva pro komunikaci s databází, kde se nadefinuje pro jednu třídu několik jejích potomků. Každý z nich bude schopen komunikovat s jinou databází. Z pohledu aplikace bude přístup k datům stejný, pouze bude nadefinováno, s jakou databází chceme komunikovat, a vrstva již vše obstará sama. Další komponenta bude obsahovat seznam jednotlivých modulů, jejich parametrů a hodnot. Z nich znovu sestaví obsah stránky, který bude prezentovat uživateli. Tudíž se jedná o centrální jednotku a srdce systému. Jak bude vypadat vzhled stránky, bude řečeno v jednotlivých fragmentech HTML kódu, jež se uloží do databáze. Tyto fragmenty se dají nazvat stavebními prvky stránky, jejichž kombinacemi získáváme celkovou stránku. Správce bude mít možnost tyto fragmenty HTML kódu měnit a upravovat dle potřeb. Jejich změny se pak okamžitě promítnou do celého systému. Sestavený systém pro správu obsahu zajistí dobrou škálovatelnost a nabídne řadu možností jeho využití, včetně budoucích rozšíření o další potřebné komponenty, které přispějí k větší spokojenosti uživatelů a ke zvýšení efektivity jejich činnosti.
12
2. Popis systému V této kapitole popíši požadavky, jež jsou kladeny ze strany uživatelů na systém pro správu obsahu. Poté navrhnu takové vlastnosti systému, které budou splňovat jejich potřeby. A nakonec zjistím, jak je to z právního pohledu na tento systém, protože tato webová aplikace může schraňovat i citlivá data v databázi.
2.1. Obecné požadavky uživatelů Pro uživatele je systém vyhovující, pokud mu napomáhá při jeho každodenní činnosti a ulehčuje mu práci. Základním problémem je však samotný uživatel. Každý jedinec je jiný a má různé požadavky a představy. To se následně promítá do jeho nároků a potřeb. Nejhorší jsou případy, pokud jsou požadavky naprosto odlišné od ostatních. Je pak velmi těžké, někdy až nemožné, vyhovět všem. Proto je potřeba nalézt jistý kompromis mezi všemi těmito požadavky. Již program sám o sobě je velkou změnou, protože jsou lidé, kteří tráví svůj čas raději s perem v ruce a šetří svůj organismus od sezení u monitoru. Na druhou stranu ani jedinci, jež uvítají takovýto systém, nemusí být příliš spokojení. Jsou zvyklí používat jiné programy, mají v nich zavedené své postupy a naučené zkratky k šetření času. Pokud tedy přijde úplně nový systém, není zde dostatečná důvěra ani pochopení. Přináší s sebou problémy spojené s porozuměním a zavedením do každodenního použití. Teprve po čase se plně projeví jeho přednosti a užitečnost při řešení daných úkolů. Aplikace musí umožňovat několik úrovní přístupu uživatelů, aby to do jisté míry kopírovalo hierarchii ve firmě či společnosti. Zároveň musí nabídnout přívětivé a intuitivní rozhraní, možnost použít již existující databázový systém ve firmě tak, aby se zbytečně nezvýšily pořizovací náklady na zavedení systému. S tím souvisí i rychlé nasazení a možnost vícenásobného nasazení do budoucna, pokud se systém pro správu dat osvědčí. Vkládání a úprava dat by měly být jednoduché a přehledné. Stejně tak možnost prohlížet již vytvořené záznamy. Konfigurace a instalace musí být snadné a jednoduše nastavitelné. Aby byla možnost seznámit uživatele s aplikací, je třeba mít pro jednotlivé uživatelské role dokumentace k použití systému s jasnými instrukcemi a ukázkami.
13
2.2. Obecné vlastnosti Na základě informací z minulé kapitoly se nyní pokusím navrhnout aplikaci pro správu obsahu , která by vyhověla všem přáním. Systém bude obsahovat 4 uživatelské role pro operace se systémem. Těmito rolemi budou aplikační správce, který bude mít na starost chod celé aplikace, administrátor pro operace ke správě uživatelských dat s možností nejen editovat, přidávat záznamy, ale i je mazat. Zbylé dvě uživatelské role - editor a čtenář - budou jen podmnožinou předcházejících. Editor, jak už z názvu vyplývá, bude moci měnit záznamy v databázi bez možnosti jejich mazání. Roli čtenáře může dostat každý, kdo si potřebuje číst informace obsažené v datové databázi. Dalším požadavkem je platformová nezávislost, čili možnost nasazení systému prakticky kdekoliv. Tuto vlastnost splňuje nejlépe webové rozhraní jako takové, protože všichni lidé, kteří v dnešní době používají ke své práci počítač, mají přístup na internet nebo alespoň na intranet a webový prohlížeč je již standardem v každém novém operačním systému. O dalších specifických detailech tohoto provedení se budu zmiňovat ve 4. kapitole. V dnešní době již většina firem používá databázový systém pro ukládání svých dat a s ním spojenou aplikaci. Často je vyhrazen jeden počítač pouze pro skladování užitečných informací a je dimenzovaný i pro budoucí použití s dalšími produkty. Pokud mají zájem o vývoj nového či dalšího systému pro správu dat, tak by rádi plně využili kapacitu databázového serveru, aby nezvyšovali náklady na pořízení nového, dokud to není nutné. Proto bude snahou vytvořit pro spojení s databází takovou vrstvu, která by se již sama postarala o spojení s jakoukoliv dnes běžnou databází a zároveň s možností přidání další. Ta by poté byla z samotné aplikace volána stále stejným způsobem a pouze parametrem či nastavením se rozhodlo, s jakým databázovým strojem se bude komunikovat.
2.3. Využití aplikace z pohledu práva Vzhledem k tomu, že naše webová aplikace bude spravovat určitý obsah který může být prakticky jakýkoliv co se týče dat, pravděpodobně nastane situace, kdy se budou skladovat i citlivá data. Těmi mohou být například pouze kontakty na zákazníky nebo v případě lékaře záznamy pacientů, které jsou „tajné“. Je tedy nutné vědět, jak se s danými daty může či nemůže nakládat. V následujících odstavcích se tedy podívám na to, jak tuto problematiku řeší zákony České republiky.
14
Největšími zdrojem je elektronická sbírka zákonů[19] a zákoník práce[20]. V těchto rozsáhlých zákonících jsem nenašel příliš mnoho údajů, přesněji zákonů předpisů nebo nařízení, podle nichž bych mohl rozhodnout o citlivosti těchto informací a způsobu nakládání s těmito informacemi. Pokud však pozměníme trochu náš problém na úvahu o tom, že jde o shromažďování dat při pracovní činnosti. Pak se můžeme odvolat na zákon o ochraně osobních údajů[21] . Ten zní následovně: „Osobním údajem se rozumí jakákoliv informace týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze subjekt údajů přímo či nepřímo identifikovat na základě čísla, kódu nebo jednoho či více prvků, specifických pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturní nebo sociální identitu“. Pokud plně pochopíme tuto definici, lze na jejím základě určit, že v určitých případech se musí uživatel a provozovatel systému řídit zákonem o ochraně osobních údajů Tím jsme vyřešili otázku, zda budeme mít v naší databázi uložena citlivá data. Ale stále nevíme, jestli je to v rozporu se zákonem. Prohledal jsem ještě další zdroje, ale ani v nich jsem moc nenalezl. Stále jsem narážel na fakt, že neexistuje příliš zákonů, jež by tyto vztahy v počítačovém světě řešily. Zákony o některých službách informační společnosti[22] a o elektronických komunikacích[23] popisují elektronickou poštu, spam a odposlechy sítí a současně vycházejí ze směrnice Evropského parlamentu a Rady o zpracovávání osobních údajů a ochraně soukromí [24]. Protože vstupem České republiky do Evropské unie v roce 2004 došlo k tomu, že právo evropské unie se stalo součástí práva České republiky, je tedy třeba se řídit i právě zmiňovanou směrnicí o zpracovávání osobních údajů a ochraně soukromí [24], z které cituji pro objasnění otázky o citlivosti dat. „Koncové zařízení uživatelů sítí elektronických komunikací a jakékoliv informace uchovávané na takovém zařízení tvoří součást soukromí uživatelů, které vyžaduje ochranu v souladu s Evropskou úmluvou na ochranu lidských práv a základních svobod. Tzv. Špehovací software („spyware“), webové štěnice („web bugs“), skryté identifikátory a jiné podobné nástroje mohou pronikat do koncového zařízení uživatele bez jeho vědomí, s cílem získat přístup k informacím, uchovávat skryté informace nebo sledovat činnost uživatele, a mohou vážně narušit soukromí těchto uživatelů. Požití takových nástrojů by mělo být povoleno pouze k oprávněným účelům a s vědomím uživatelů, kterých se dotýká.“ Toto bylo převzato z neúředního revidovaného
15
překladu směrnice Evropského parlamentu, obsažené v Informačním systému pro aproximaci práva [25] Zde ke konci je zodpovězena naše otázka. Chceme-li ukládat citlivá data do našeho systému pro správu dat, tak jedině se souhlasem osob, jichž se to týká. V zásadě můžeme říci, že webová aplikace jako taková nebude porušovat zákon a k jeho porušení může dojít pouze ze strany uživatelů nedbajících nebo neznalých zákona. Potvrzením mého stanoviska je ÚOOU [26]: „Zaměstnavatel má právo sledovat u svých zaměstnanců dodržování pracovní doby a její využití“, to vychází ze zákoníku práce [20] § 9 odst. 3: „Vedoucí zaměstnanci zaměstnavatele, jimiž se rozumějí jeho orgány (odstavec 1), jakož i jeho další zaměstnanci, kteří jsou pověřeni vedením na jednotlivých stupních řízení u zaměstnavatele, jsou oprávněni stanovit a ukládat podřízeným zaměstnancům úkoly, řídit a kontrolovat práci a dávat jim k tomu účelu závazné pokyny.“. Provoz takového systému bude v souladu s právem, pokud ze strany uživatele bude vysloven informovaný souhlas se shromažďováním, archivací a zpracováním dat , která lze z jeho pohledu považovat za citlivá z pohledu ochrany osobních údajů či soukromí.
16
3. Srovnání stávajících řešení na trhu CMS: k čemu slouží? CMS (Content Management System) systémy, někdy pojmenovávané i jako ECM (Enterprise Content Management), jsou připraveny ke správě strukturovaných i nestrukturovaných dat. Jejich zdrojem jsou jiné aplikace používané v podnicích a firmách, potom také dokumenty, které mohou být v různých formátech. Nemusí to být tedy pouze čistý text ,ale i videa, zvuk, obrázky, kusy kódu a jiné elektronické dokumenty.[5] CMS podle META Group S pokusem přesněji popsat, co představuje CMS, přišla společnost META Group[4], která se zabývá výzkumem a poradenstvím v oboru informačních technologií. Zmíněná společnost vytvořila následující definici tohoto typu systému: "ECM/CMS je technologie, která poskytuje prostředky pro vytváření a sběr, správu a zabezpečení, ukládání, uchovávání a likvidaci, publikování a distribuci, prohledávání, personalizaci a prezentaci, prohlížení a tisk veškerého digitálního obsahu (tj. fotografií, obrázků, textu, zpráv, videa, audia, dat o transakcích, katalogu, kódu). Tyto systémy se primárně soustředí na sběr, ukládání, vyhledávání a distribuci digitálních souborů pro podnikové užití."
DRUPAL
Drupal[5] je jedním ze systémů pro správu obsahu (Content Management System - CMS). Nabízí modularitu a s tím spojenou jednoduchou rozšiřitelnost. Řadí se mezi velmi dobře propracované aplikace svého druhu. Jeho velkým plusem je možnost bezplatně si ho stáhnout, včetně zdrojových kódů, a zároveň obsahuje velké množství připravených modulů.
17
obr. 1 - Systém Drupal
Historie Webová aplikace Drupal byla vyvinuta holandským studentem Driese Buytaerta. Vznikla na základě nutnosti sdílení dat s dalšími studenty na vysokoškolských kolejích, a tak se roku 2001 objevila první verze nesoucí jméno Drop. Její název vznikl zkomolením slova Dorp, které v holandštině znamená vesnice. Avšak první veřejná verze této aplikace se jmenovala Drupal, a to proto, že při výslovnosti slova Drop se to v angličtině blížilo slovu druppel. Postupnou mutací tedy vznikl již zmíněný název Drupal. V té době na
18
aplikaci DRUPALU pracovalo již více vývojářů, několik hlavních a více než 400 externích. Hlavní slovo však nadále zůstávalo autorovi myšlenky - Driesu Buytaertovi. Vzhledem k tomu, že šlo o projekt nesmírného rozsahu, nebylo možné, aby práci na něm zvládl jeden člověk ,a tak byli vybráni schopní spolupracovníci, kteří mu začali se správou Drupalu pomáhat. To, co z Drupalu dělá tak vynikající aplikaci, je založeno na tom, že je sestaven z modulů. Těch je obrovské množství a na stránkách modulů [7] jsou ke stažení, včetně jejich vylepšení. Mám-li vyzdvihnout nějaké přednosti tohoto systému pro správu dat, vybírám následující.: Modularita – nezáleží na tom, zda potřebujeme Fórum, blog, Eshop anebo víceméně jakýkoliv existující druh webu na internetu, vše z toho nám Drupal dovolí postavit ze svých modulů. Jádro systému je vcelku malé, to přináší výhody v tom, že je rychlé, má dobré rozhraní a přídavné moduly, s kterými se stává mocnějším a šikovnějším. Zároveň je dána možnost vytvořit si vlastní modul podle potřeby, není-li již implementován, to se můžeme dozvědět na domovské stránce Drupalu[6]. Zároveň zde nalezneme postup, jak si svůj vlastní modul vytvořit a co musíme udělat pro to, aby ho bylo možné použít v systému. Kvalita – již od začátku bylo cílem projektu, aby v budoucnu nezanikl, kvůli nedostatkům anebo kvůli chybám do něho vneseným. Již samotná modularita mu zaručuje, že každý z modulů se dá otestovat samostatně. Proto v případě nalezení nedostatku již uvolněného modulu jsou vydávány patche, ty jsou velmi kvalitně odzkoušeny a otestovány. A protože samotné jádro systému má také velmi dobře rozvrženou strukturu, je připraveno i do budoucna. Z Drupalu to tak dělá bezpečný a stabilní systém, který ocení mnoho uživatelů. Zároveň na jeho domovských stránkách nalezneme podporu a řešení problémů, jež se čas od času vyskytnou, buď při jeho instalaci ,anebo při změnách kódu. Open Source – Drupal je šířen pod licencí GNU/GPL, k vývoji byl použit programovací jazyk PHP s databází MySQL a PostgreSQL. Ty je možné si zdarma stáhnout a provozovat na svém počítači. A tím, že se stal Drupal velmi populární, bylo rozhodnuto rozšířit jeho databázovou základnu o další databáze, konkrétně o MS SQL a Oracle. Díky všem těmto vlastnostem se domnívám, že je to jeden z nejlepších systémů pro správu obsahu, který se dá na trhu nalézt. Svědčí o tom též fakt, že je nepřeberné množství webových stránek, které ho používají. Pro představu, zde některé uvádím: http://phpmyadmin.cz/ , http://www.fotozpravy.cz , http://hw.cz , http://ecodesign.sk , http://www.extrahardware.cz , http://www.602office.cz , http://www.suseserver.cz
19
Joomla Název této aplikace pochází z arabského jazyka. Joomla[8] v tomto jazyce znamená buď „shluk slov, která dávají smysl“, anebo „dohromady.“ Dále mi bylo sděleno mým bývalým spolubydlícím, který je z Kuvajtu, že se používá i jako „součet“ nebo „suma“. S projektem Joomla přišla společnost Open Source Matters, jež byla založena jako reakce na události v komunitě okolo jiného projektu, Mamby[9]. Stejně jako předchozí aplikace je i Joomla šířena pod licencí GNU GPL. Její doslovné znění si můžeme přečíst na http://www.gnu.cz/licence.html. Projekt byl implementován v programovacím jazyce PHP za použití databáze MySQL, což z něj dělá dobře nasaditelný systém na mnoha typech operačních systémů, nejčastěji používanými jsou Windows a Linux.
Filozofie Joomly je trochu jiná než u dalších redakčních systémů, které jsou distribuovány s mnoha rozšířeními. Oproti nim je tento systém nabízen ve velmi jednoduché variantě, která umí základní správu obsahu. To bude pravděpodobně také proto, aby se každý uživatel tohoto systému byl nucen
obr. 2 - Systém Joomla
20
zaregistrovat a teprve potom mu je nabídnut další speciální obsah. Nyní by se tedy mohlo zdát, že Joomla je vcelku omezená a nenabízí nám příliš dovedností. První dojem však klame. Existuje mnoho komponent, modulů, s jejichž pomocí je nabídnuta další a další funkčnost a nové „features“. Proto si při rozšiřování Joomly musíme udělat dobrou analýzu , musíme se zaměřit na to, co vlastně od vznikajícího systému vyžadujeme ,a musíme si stáhnout ty správné komponenty pro „okošatění“ webových stránek. V následujících několika větách ve zkratce popíšu,jaké komponenty je možné použít v tomto systému. Nalezneme zde takové, pomocí nichž si lze vytvořit internetový obchod, jednoduchou hru anebo fórum. Je tedy jen na nás, uživatelích, které použijeme a budeme chtít používat. Zároveň nám nic nebrání v tom,abychom za rok nebo dva systém rozšířili, například o fórum. Stačí následně stáhnout příslušnou komponentu a začít ji používat. Není tak třeba procházet skrz celý systém se všemi rozšířeními, ale postupně se naučit používat jednotlivé jeho části,komponenty. Velká většina redakčních systémů má předpřipraveno několik šablon pro zobrazování obsahu. Uživatel se tedy nemusí o nic starat, pouze vybere tu vhodnou a používá ji společně s daty, která vkládá do systému. Pro novice v používání Joomly může být celkem obtížné vytvořit si vlastní šablonu,není to totiž triviální záležitost. Je vyžadována jistá znalost funkcionality. Poté však již zkušený programátor anebo grafik může vytvořit jakoukoliv vlastní. Samozřejmostí je, že samotná Joomla nabízí mnoho takových šablon vzhledů ke stažení za poplatek, který se pohybuje kolem deseti euro. Tento software nám tedy předkládá slušné možnosti a je třeba se rozhodnout ,zda je pro nás ten pravý, který vyžadujeme. Má sice jistou funkcionalitu, ale na druhou stranu je omezený jen na jednu databázi, což může být problém, pokud bychom chtěli použít jinou.
RS2 Tento software začal tvořit a stále je jeho jediným autorem Juneau. Již několik let zdokonaluje svůj redakční systém, jehož název je RS2 RC5[10]. Postupně ,jak se systém stále vyvíjí kupředu, získává na své funkcionalitě a roste také po grafické stránce.
21
obr. 3 - Systém RS2
Výhodou tohoto redakčního systému je intuitivní rozhraní, které každý pochopí. Stejně tak i práce s ním je jednoduchá, na stránkách je vše potřebné vysvětleno v dostatečné míře. Co však není zatím na patřičné úrovni, to je fórum a fotogalerie. Pravděpodobně se jedná o počáteční vývoj, na kterém se bude v budoucnu stavět a vylepšovat, jak uvádí sám autor. Je třeba prozatím mít jisté zkušenosti, pokud chceme přidat fotografie do zmíněné fotogalerie, ale snad bude do budoucna i tento problém vyřešen. V administrační části je možno nastavit celý blog. Z pohledu zabezpečení je aplikace členěna na dvě uživatelské role, a to na uživatelskou a administrační, možná by se dala ještě přidat editorská. Ke každé z nich je přidružena klasická funkcionalita, pro správu účtů, příspěvků, zpráv, článků, statistik, aktualit, fotogalerie a fóra. Tedy vše, co lze očekávat. Zaujalo mě, že systém RS2 rozlišuje dva typy příspěvků: texty a články. Texty jsou klasicky kusy textu, jež se vloží do stránky, zatímco články zde vytvoří samotnou stranu, na které jsou zobrazeny. Takovéto rozdělení není vůbec běžné, jedná se tudíž o zajímavý nápad. Pro formátování textu je k dispozici nástroj Texy!, dále pak vkládání anket, tabulek, obrázků atd. Tento systém RS2 nabízí i RSS kanály. A ne jeden: RSS komentáře, RSS texty a RSS novinky. V administraci však chybí možnost nastavit tyto kanály,
22
samotný autor se zmiňuje takto:,,Máš-li zájem o něco vychytanějšího, zkus editovat soubory rss.php a rss-komentare.php. Pokud tedy víš, co děláš... ". RS2 nám také nabízí vcelku propracovaný systém statistik. Jedná se o neplatná přihlášení do administrační části, sledování RSS kanálů a SQL, slova která jsou hledaná, pak je tu možnost zobrazit si statistiky textů, ať už podle počtu slov za den, anebo podle počtu příspěvků. Podle mě však nejdůležitější z pohledu uživatele bude ta statistika, která sleduje, který text anebo článek byl nečtenější, co za prohlížeče bylo používáno pro zobrazení a kdo byl nejaktivnější v psaní příspěvků. Protože mi nejde o to kritizovat systém, ale znát jeho výhody, tak zde několik kladů uvedu. Jednoduché rozhraní, tudíž snadná orientace. Dobře napsaný kód, který se dá lehce pochopit a v kterém se dají snadno dělat úpravy. Dále existuje poměrně podrobný manuál a zároveň autor nabízí podporu na fóru. RS2 je ke stažení jako celek, je v češtině, a pokud se do budoucna zlepší fórum a fotogalerie, bude obsahovat všechny základní komponenty redakčního systému v dostatečné kvalitě. Tento systém vyvíjený jedním člověk si zaslouží obdiv. Pro uživatele, který by chtěl jednoduchý spravovaný portál, je to ideální volba. CMS systémy, které jsem doposud popsal, jsou podle mě jedny z nejlepších a nejblíže webové aplikaci, kterou budu vyvíjet v rámci mé diplomové práce. Na trhu existuje mnohem více takových systémů pro správu obsahu, ale myslím si, že pro představu je tento výčet postačující. Proto dále již uvádím jen názvy systémů, na kteréjsem narazil, a odkaz v referencích na ně. Zdály se mi vcelku dobře navržené v rámci své kategorie a dobré i z hlediska funkčnosti. -
BLOG:CMS [15] phpRS [16] Textpattern [17] Wordpress [18]
Představil jsem zde několik systémů pro správu obsahu. Jejich vlastnosti, možnosti a možná rozšíření. Každý z nich má své přednosti a je vhodný pro jiné nasazení. V porovnání se systémem, který má vzniknout v rámci mé diplomové práce, bych řekl, že se zde nalezne jistá podobnost v několika ohledech. Můj systém bude též obsahovat moduly a komponenty, avšak oproti Drupalu anebo Joomle bude jednodušší a méně komplexní. V tomto ohledu se bude více blížit systému RS2. Celý systém bude možné spravovat skrz administrační rozhraní. A to jak vzhled, tak i jeho funkčnost. Zároveň mě půjde o to, aby ho bylo možno nasadit prakticky kdekoliv a v kombinaci s dnes běžnými databázemi Sám o sobě by měl poskytnout dostatečně silný nástroj pro správu například zásilek klientům, databáze návštěv pacientů u lékařů
23
anebo záznamy o sociálně problémových jedincích a jejich sezeních. Tento výčet by mohl být mnohem širší, ale myslím si ,že pro základní představu je to dostatečné.
24
4. Analýza V první části jsou shrnuty požadavky pro aplikaci správy dat. Ty vycházejí z druhé kapitoly a jsou doplněny o další specifikace a funkcionalitu, jež systém nabídne. Dále pak je předložen kontextový diagram a model jednání, kde je znázorněno, jak budou jednotlivý uživatelé interagovat se systémem. Neméně důležitý je i stavový diagram, který prezentuje stav relací. Na závěr, pak představím databázový E-R model a celkovou architekturu aplikace.
4.1. Požadavky a vlastnosti systému Cílem tohoto snažení bude vyvinout systém, který by napomohl spravovat obsah firmám středně velkým, které nepotřebují žádný složitý systém a z pohledu uživatelského rozhraní nabídne dostatečně velké portfolio služeb, funkcí a jiných "features". Zároveň systém bude platformově nezávislý, schopen komunikace s dnes běžnými databázemi a měl jednoduchou instalaci, aby se dosáhlo možnosti širšího nasazení. Systém se zpřístupní po přihlášení, na základě kterého se rozhodne, jakou uživatelskou roli přihlášený uživatel dostane. Těmito rolemi budou aplikační správce, správce, editor a čtenář. S každou takovou rolí souvisejí práva uživatele. Aplikační správce bude mít přístup do celého systému, ať už administrační části bežícího systému, tak i přímo jádru systému. Bude moci nastavit uživatele, vzhled stránek a jak se budou kontrolovat vložená data. Každá další role je již pouze pod rolí této. Správce systému bude mít přístup pouze již do správy obsahu, čili dat a nikoliv metadat nutných pro běh aplikace, kde mu budou nabídnuty k tomu určené funkce systému. Rozdíl mezi správcem a editorem pak bude v tom, že editor nebude moci mazat nic v systému, bude smět pouze údaje prohlížet a měnit. A poslední typ uživatele pak bude mít právo prohlížet si co v systému je. Tímto rozvrstvením uživatelských rolí docílím jisté hierarchie, která se používá v klasických systémech tohoto typu. Pokaždé zde je jistý technický dozor, který se stará o samotný chod systému a dělá jeho případné úpravy na základě požadavků jednotlivých uživatelů. Dalším kdo v takovýchto aplikacích figuruje je určitý šéf, vedoucí oddělení, který kontroluje a reviduje jednotlivé příspěvky zadávané editory, případně vkládá svoje články, příspěvky a záznamy. Editoři jsou pak vlastně zaměstnanci, jež dodávají obsah, případně upravují ten stávající. A čtenáři potom budou všichni ostatní přistupující k systému.
25
Tato aplikace pro správu dat bude postavena tak, že bude možné mít fyzicky oddělenou aplikační správu od datové a tím se zajistí vyšší zabezpečení systému. Toho docílím dvěma databázemi, které buď budou společně na jednom stroji anebo na dvou různých. Tudíž tu bude možnost použít tento systém několikanásobně bez nutnosti instalovat pokaždé jádro, uživatel si pak vybere z jakého oddělení se přihlašuje a dostane k němu ten správný obsah. V rámci společnosti se to pak bude jevit jako několik vzájemně nezávislých systémů. Tato koncepce je založena na dnešní potřebě zabezpečení a oddělení samotných dat od meta dat, zároveň dovoluje lepší centrální správu celého jádra systému. V následující části uvedu jaké moduly bude systém obsahovat pro svoji činnost a co dalšího by se do systému mohlo v budoucnu přidat, aby byla nabídnuta větší funkcionalita a zabezpečení této aplikace. Prvním popisovaným modulem je vlastně vrstva pro komunikaci s databází. Bude se jednat o třídu, která nadefinuje základní funkce pro připojení k databázi a operace s ní. Na ní budou postaveny zděděné třídy, pro komunikaci s již konkrétní databází, takže pokud se rozhodneme používat systém s jinou databází, než nám systém v základu nabízí, bude stačit jen malé rozšíření. Jakmile jednou vytvořím takové rozšíření, bude již platnou částí celé aplikace a nebude ho již třeba nikdy znova vytvářet. Webová aplikace tak bude moci běžet nad jakoukoliv databází, pro kterou si nadefinuji rozšíření. Tímto získám značnou dynamičnost a v zásadě možnost nasadit ji kdekoliv bez obav, že nebude obsahovat potřebné rozhraní pro určitou databázi. Nedílnou součástí systému je jeho jádro. Tento modul bude mít na práci při každém načítání stránky ji sestavit. Protože bude obsahovat nastavení ostatních modulů a jejich vstupní parametry. Samotné jádro této webové aplikace tedy nebude nikterak složité a zároveň velmi flexibilní pro případné další rozšíření, moduly. Zbytek aplikace budou již menší komponenty, které dostanou za úkol provádět kontroly dat při vkládání do databáze, zobrazení menu, dat a jejich procházení. Bude se jednat o sadu funkcí, tříd a procedur, které budou schopny pracovat se systémem. Již v počátku vývoje webové aplikace je jasné, že implementace úplně celé je běh na dlouhou vzdálenost a teprve v průběhu implementace a testování se dozvím, kde jsou její slabé články. Přesto doufám, že se bude jednat o velmi kvalitní produkt, který nabídne plno funkčnosti a uspokojí jeho uživatele. Již teď mě napadá plno rozšířeních, které by mohly být implementovány. Ale ty nechám až na budoucí verze a popíši je v kapitole 8.2 možné zlepšení webové aplikace.
26
Celkově bude tento systém předpřipraven jako dobrý základ pro velmi mohutný nástroj a při dostatečné péči, vynaloženém úsilí ho lze dovést ve velmi profesionální nástroj na úrovni Drupalu anebo ještě lepší.
4.2. Kontextový diagram
obr. 4 - Kontextový diagram
Uvedl jsem zde kontextový model pro moji webovou aplikaci. Aktéři jsou zobrazeni v obdélnících a budou komunikovat se systémem, jež je zobrazen v oválu. Šipky mezi objekty naznačují datové toky při vzájemné komunikaci. Editor ze systému získává záznamy z datové části, má možnost přidávat nové,upravovat je anebo jen prohlížet a systém mu je poskytne. Čtenář má povoleno pouze prohlížení záznamů z stejné části jako editor, ty jsou mu aplikací zpětně zpřístupněny. Jedná se o uživatele s nejmenšími právy Pak zde je Správce mající za úkol korigovat obsah dat, proto může přidávat, měnit a i mazat záznamy. Samozřejmostí je, že je může prohlížet. Zároveň má také možnost editovat a upravovat uživatele přistupující do systému, který mu tyto informace na základě jeho platné autorizace poskytne. Aplikační administrátor má práv nejvíce a s tím souvisí i to co je mu aplikaci poskytováno. Je mu dovoleno upravovat, mazat, přidávat a prohlížet jakýkoliv záznam z datové a navíc oproti předchozím rolím i metadatové části. Samozřejmě že tak může nastavovat uživatele, vzhled, nastavení tabulek pro
27
zobrazení, menu a fragmenty kódu z kterých je aplikace pak skládána. Zde musím poznamenat, že jsem zvolil 4 uživatelské role, ale je možné jich přidat do systému více, protože se může stát, že i datovou část budeme chtít rozdělit na několik kategorii a více diferencovat přístup uživatelů do ní.
4.3. Model jednání Na obrázku je vyobrazen model jednání, jak mohou jednotliví aktéři komunikovat se systémem. Každý z aktérů je znázorněn jako postavička. Systém je vyobrazen jako velký obdélník a v něm je naznačeno, že je reprezentován dvěma entitama, datovou částí a metadaty. V rámci každé z těchto částí jsou pak elipsy obsahují případy použití. V metadatech je obsažena administrace menu, fragmentů HTML kódu, nastavení zobrazení tabulek, definice uživatelských rolí a pomocných struktur pro zobrazení nějakého detailu anebo upřesnění typu pole Data obsahují administraci uživatelů, změnu nápisu položky v menu, sloupečku tabulky. Dále pak jsou zde zahrnuté kódové tabulky pro tvorbu vazby master-detail a nakonec samotné datové tabulky, obsahující zmíněnou vazbu.
obr. 5 - Model jednání
28
4.4. Stavový diagram Na obrázku je zobrazen stavový diagram ukazující stavy aplikační administrace při procházení. Při otevření je uživateli předloženo přihlášení do webové aplikace a na základě odeslaných údajů dojde k ověření totožnosti. V případě, že by nebyl takový uživatel nalezen, systém oznámí neúspěch a nabídne znovu přihlašovací formulář. V opačném případě je nabídnuta úvodní obrazovka aplikace s menu. Já zde uvádím případ, kdy se jedná o aplikačního administrátora. To z důvodu, že v datové části jsou akce stejné, pouze nad jinými tabulkami. Je vidět, že i v rámci této části jsou všechny akce, co do způsobu provádění shodné. A jsou jimi zobrazení tabulky, na které navazuje editace nějakého záznamu, smazání anebo přidání nového.
29
obr. 6 - Stavový diagram
30
4.5. E-R schéma databáze Na obrázku je vyobrazena datová struktura databáze. Dá se lehko všimnout, že tabulky nejsou příliš propojeny. Jediné propojení, které lze nalézt je mezi tabulkami cms_admingroup a cms_menulab. Je to tím, že tabulky jsou silně nezávislé a vše se děje dynamicky uvnitř php kódu. Tam se postupně načítají data z tabulek podle url odkazu, kde je řečeno co se odkud vezme a jak se to má použít, respektive zobrazit. Tabulky jsem uvozoval prefixem cms_ . A to z toho důvodu, aby v databázi, kde nebudou oddělena metadata a samotná data, bylo dobře rozeznat jednotlivé tabulky. V případě mnoha tabulek by se hůře hledali. Podobný plán je připraven i pro ty datové. Ty se navíc ještě rozdělí na dvě skupiny. První budou takzvané kódové tabulky uvozované prefixem C_. Ty využiji následně v tabulce cms_forms, kde se definuje vše kolem každé tabulky v databázi, která má být použita. A jedním z vstupů je i možnost vytvořit vztah master-detail. A právě tabulky uvozené C_ se budou používat jako detaily. Ostatní datové tabulky označím prefixem D_. Tímto rozdělením napomůžu každému administrátorovi v snadnější orientaci mezi nimi.
obr. 7 - E-R schéma databáze
31
V následujících několika odstavcích popíši jednotlivé tabulky, co v nich lze nalézt a za jakým účelem byly stvořeny.
4.5.1.
cms_admingroups
Tato tabulka je vlastně definicí menu. Definuji zde názvy jednotlivých položek, jejich pořadí, přístup podle uživatelské role a několik dalších parametrů. V bodech teď popíši co jaká položka znamená. groupid – primární klíč této tabulky groupdesc – název položky menu definované administrátorem, které se zobrazí grouplink – zde je link na danou položku, jedná se o speciální link, který říká jak a z kterých částí se má stránka sestavit, podrobnosti o něm se nacházejí v části 6.5 grouptext – nadpis skupiny v menu, aby se použilo, musí být nezaškrtnuto menuactive grouporderid – obsahuje číslo , podle něhož jsou položky v menu seřazeny a zobrazeny menuimage1 – místo slovního popisku můžeme použít v menu i obrázek, zde vložím url adresu k němu menuimage2 – zde se též definuje pro menu obrázek, občas totiž z nějakých specifických důvodů chceme zobrazit ještě druhý menuvisible – nastavení zda má být položka v menu viditelná, například pokud chceme udělat v menu mezeru, tak zaškrtneme tuto volbu a nezaškrtáváme možnost menuactive. další pro co slouží je, že chceme nějakou položku v menu dočasně odstranit, ale v budoucnu ji plánujeme mít opět přístupnou hovertitle – popisek k čemu odkaz v menu je, zobrazí se nám při přejetí myší přes položku openinpage – jedná se o zaškrtávání zda chci otevřít odkaz v novém okně loginreq – předpřipravena možnost pro znovuvyžádání přihlášení usergroup – zde definuji ze seznamu uživatelských rolí, kdo má přístup k této položce v menu, přičemž všechny co jsou nadmnožinou mají přístup též menuactive – nastavení zda položka má být aktivním linkem v menu anebo pouze textem siteid – pro definici, ke které stránce patří toto menu
4.5.2.
cms_forms
Zde je nadefinováno jedno z nejdůležitějších nastavení celé webové aplikace.
32
Pro každou tabulku v databázi, ke které chceme přistupovat musíme mít zde záznam. Který říká o její struktuře, jak k ní přistupovat a kterak ji zobrazovat. form_id – primární klíč tabulky form_name – název formuláře, který je vlastně názvem tabulky bez předpony cms_ form_fields – zde definuji čárkou oddělené sloupečky z dané tabulky, jež se zobrazí v náhledu na ní, jím je myšlena obrazovka, která se zobrazí při kliknutí na položku v menu. form_fieldwidth – spojené s předchozí položkou a to tak, že obsahuje stejný počet čárkou oddělených položek, v tomto případě čísel, určujících šířku každého z nich form_query – zde je předpřipravený začátek sql dotazu, pomocí něhož pak vyberu z tabulky data form_where – pokračování dotazu v části where form_keyfield – názve primárního klíče vyplňované tabulky form_table – název tabulky bez předpony form_conn – typ připojení který se má použít pro tuto tabulku, v zásadě rozeznávám dva, buď stejné, pokud jsou metadata a samotná data na stejném serveru anebo rozdílné, jsou použity dva stringy „dat“ pro data a „mtd“ jako metadata. form_select_table – pokud potřebuji na zobrazení náhledu propojit více tabulek, napíši je zde oddělené čárkou form_screenfields – zde v případě, že nechci zobrazit všechny sloupečky z tabulky rpvedu výčet oddělený čárkou anebo nechám prázdné pro zobrazení všech form_foreignkey – pro nadefinování master-detail vztahů u této tabulky, pro vytvoření jednoho je třeba vyplnit následující čtveřici v takovémto formátu nahrazovany_sloupecek;sloupec_s_popisem_v_tabulce_detailu;primarni_klic_ detailu;nazev_tabulky_detailu. V případě, že potřebujeme více takových vztahů, oddělujeme je čárkou form_selectscript – potřebujeme-li při zobrazení záznamu z tabulky javascript a nějakou jeho funkci, zde bude jeho zdrojový kód form_fieldlab – normálně se názvy sloupců zobrazují pod jejich jmény v databázi, pokud chceme použít jejich přejmenování pro tuto tabulku, vepíšeme slovo fieldlab a názvy obsažené v tabulce cms_fieldlab budou pak přepsány. form_editor – zaškrtávání možnosti použít pro textové ( type text ) sloupce wysiwyg editor form_nocols – zaškrtnutím určuji zda se má zobrazit obsah záznamu do jednoho anebo dvou sloupců form_need – některé sloupce v databázi jsou nenulového typu a potřebujeme, aby je uživatel
33
vyplnil, ty vyjmenujeme oddělené čárkou právě zde insertm, deletem,updatem – z názvu vyplývá již o jaké operace nad touto tabulkou se bude jednat, my zde určíme uživatelské role, jež to mohou dělat, zároveň bude tato akce povolena každé nadroli.
4.5.3.
cms_menulab
Tato tabulka je připravena pro přejmenování popisku položek menu, je vzájemně spojena s tabulkou cms_admingroups přes primární klíče admin_id – primární klíč musí být shodný s klíčem v tabulce cms_admingroups tablename – název tabulky v databázi bez prefixu, pro kterou je toto přejmenování tablepkey – primární klíč této tabulky tablelabel – definuje popisek, na který se zamění ten původní
4.5.4.
cms_fieldlab
Tak jako předchozí přejmenovávala jednotlivé položky menu, zde máme možnost si přepsat jména jednotlivých sloupečků do přívětivější podoby a také je zde předpřipravena struktura na jejich budoucí kontrolování na rozsah, nadefinování defaultních hodnot anebo jazykovou verze popisku. Labid – primární klíč languagecode – definice jazykové verze v písmené zkratce, např cs,nl tablename – název tabulky, kde je sloupec k nalezení label – název sloupce labeltext – nový popisek helptext – připraveno pro nápovědový text, říkající co vlastně toto políčko znamená errortext – zde bude chybový text, objevující se v případě, že jsme vložili špatnou vstupní hodnotu do pole mandatory – ne/povinnost sloupce , tj. zda musí být vyplněný fieldperm – kdo k němu bude mít přístup minvalue,maxvalue a defaultvalue – definují rozsah, resp. defaultní hodnotu
34
4.5.5.
cms_structform
Tato tabulka slouží ke speciálnímu případů. Mám-li například databázi pacientů, vyberu jednoho z nich, a pak procházím jeho záznamy. A někdy se tane, že už si nevzpomenu o koho jde a tak se zde definuje struktura, v které bude informace uložena a v horním framu zobrazena. Formid – primární klíč formname – název struktury, slouží jako popisek header – html kód, kde nadefinuji jak bude vypadat toto zobrazení, včetně proměnných formvars – proměnné oddělené čárkou, které se budou nahrazovat za hodnoty need – potřebné vstupní proměnné, tvořené stejně jako předchozí. Jejich počet musí být shodný s počtem v formvars a vzájemně se tak párují.
4.5.6.
cms_authors
Zde uchovávám informace o uživatelích systému. A na základě nich jim přiřazuji role a s tím související práva. authorid – primární klíč username – uživatelské jméno password - heslo authorname – uživatelovo reálné jméno authoremail – jeho email regdate – datum kdy byl zaregistrován usergroup – do které uživatelské skupiny patří countrycode – definuje odkud je uživatel, např. cs,nl language – v jakém jazykovém režimu se mu mají zobrazovat popisky, např. cs,nl departmentid – v kterém oddělení pracuje siteid – k jaké stránce se tato registrace vztahuje a s tím související menu
4.5.7.
cms_seting
Slouží pro definici speciálních tlačítek, které jsou v databázi typu char(1) a chci jim nastavit dvě hodnoty, jsou to vlastně pak vlastně boolean hodnoty. Setid – primární líč settingname – pojmenování nastavení
35
settingvalue – políčka oddělená čarkou, jež se mají zobrazit jako checkboxy
4.5.8.
cms_usergroup
Zde mám uloženy jednotlivé uživatelské role vyskytující se v databázi. usergroup – primární klíč, který zároveň používám pro určení o jakou roli jde usergroupdesc – popisek skupiny siteid – ke kterým stránkám tato role přísluší
4.5.9.
cms_htmlpart
Stránky jsou složeny z jednotlivých fragmentů html kódu, které máme uložené zde, přičemž se většinou jedná o hlavičku a spodek. Tělo je tvořeno pak daty, která se načtou z databáze, případně nějakými menšími strukturami zde uloženými partid – primární klíč partname – název této části pro snazší orientaci html – samotný html kód
4.5.10.
cms_structtable
Slouží pro předpřipravené struktury, které se zobrazují v úplně nové stránce. tableid – primární klíč tablename – jméno tabulky, ke které patří struktura tablevars – proměnné, které se budou nahrazovat src_page – html kód stránky s proměnnými src_show – určuje zda se má nebo nemá použít pro danou tabulku přepis proměnných, které určují, kde jsou obrázky, css styly a ikony
4.6. Architektura
36
obr. 8 - Architektura systému
Architektura tohoto systému je velmi jednoduchá. Máme databázi, případně dvě, pokud jsou oddělena metadata a data. S ní komunikuje sql vrstva aplikace. Posílá dotazy a přebírá jejich výsledky, které předává výše. Na základě takto obdržených dat vytvoří prezentační vrstva aplikace příslušnou webovou stránku s daty a zpětně má možnost požádat přes sql vrstvu o další.
37
5. Návrh V této kapitole postupně vysvětlím výběr programového vybavení pro moji aplikaci. Po něm bude následovat kapitola o komunikaci s databází a nakonec zde představím, jak bude aplikace vypadat z pohledu uživatele .
5.1. Výběr platformy Při výběru platformy jsem vzal v potaz, že systém by měl být přístupný z naprosté většiny počítačů. Tuto vlastnost splňuje webové rozhraní, každý uživatel má na svém pc nainstalovaný webový prohlížeč a z toho tedy vyplývá ,že výstupem budou webové stránky. Internetové stránky lze v dnešní době tvořit v několika programovacích anebo skriptovacích jazycích. Například v ASP.NET, ASP, Java Servlet Pages, PHP, CGI a ještě v několika méně používaných. Podívám-li se na nabízené hostingy na internetu, zjistím, že nejčastější je podpora pro PHP a potom pro ASP.NET. Přičemž zprovoznit php je jednodušší a navíc, co se týče platformové nezávislosti, tak nad ASP.NET vítězí. Sice existuje na linuxu projekt “mono“, který by měl zastupovat .NET framework běžící na Windows, ale jeho rozšíření je velmi malé. Proto jsem zvolil pro implementaci programovací jazyk PHP. Co se týče verze, mám v zásadě v dnešní době na výběr dvě možnosti -PHP 4 a PHP 5. Přičemž vše, co běží na 4, poběží i ve verzi 5. A protože na trhu existuje nástroj pro spuštění webu lokálně, bez nutnosti znát nějaké podrobnosti o nastavení, a ten používá verzi PHP verze 4, bylo rozhodnuto. Tímto nástrojem je EasyPHP [11]. V posledních dnech byla uvolněna verze, která obsahuje PHP 5, ale pro zpětnou kompatibilitu a širší nasazení jsem zůstal u verze 4. Další, co je třeba vybrat, je databáze, na které systém prvotně spustím. Těch mám na výběr také celou řadu – MySQL, Postgres, MSSQL, Oracel, Sybase atd. Tento systém má umožnit komunikovat s jakoukoliv z těchto databází, a proto se musím zaměřit na dostupnost a vhodnost prvotní databáze, na níž web rozběhnu. Zprvu pro samotný běh jsem vyřadil MSSQL a Oracle, protože ty jsou prozatím pro moji webovou aplikaci příliš mohutné a zdaleka nevyužiji jejich výhody v plné míře. Dalším proti je i jejich pořizovací cena. Přesto i tyto databáze bude možné použít. Podobně dopadne i Sybase. Zbývající dvě jsou volně dostupné a vzájemně dost podobné. Z nich jsem vybral MySQL, a to hned z několika důvodů. První byl, že při prohlížení dostupných hostingů víceméně každý nabízí podporu této databáze, dále je možné k ní přistupovat přes webové rozhraní phpMyAdmin[12]. A posledním důvodem, proč jsem vybral tuto databázi, je to, že je obsažena v instalačním balíčku EasyPHP. Ten
38
mi tak nabídne vše, co potřebuji. Tedy programovací jazyk PHP, databázi MySQL a webové rozhraní pro přístup k ní – phpMyAdmin, zároveň mi nabízí možnost jednoduše upravit základní nastavení podle mých potřeb. Co však je jeho největší předností, je to, že je ho možné nainstalovat na všech běžných platformách a zároveň po instalaci nemusím již nic nastavovat a mám běžící verzi, kterou mohu použít pro moji webovou aplikaci a budu vědět, že její rozběhnutí na jiném stroji bude pak dosti jednoduché. Jak jsem již nastínil dříve, není toto jediná možnost, jak „rozjet“ můj systém, protože budu mít předpřipraveny třídy pro připojení k více typům databází, a tedy i možnost je použít v případě, že je již nějaká nainstalována. PHP je možno nainstalovat úplně zvlášť, buď právě tak, jak to dělá EasyPHP pomocí serveru Apache[13], anebo využít produktu od microsoftu - IIS serveru[14]. Při zvolení databáze typu MSSQL, Oracle anebo Sybase lze zajít ještě o něco dále se zabezpečením při autentizaci. Vytvořením úložné procedury, na základě které se rozhodne o vstupu do webové aplikace. Tím by byl systém ještě více zabezpečen, protože až do doby, než proběhne autentifikace ,nebude uživatel připojen k žádné databázi. O této variantě se zmíním v kapitole 8.2 o možných rozšířeních. Já jsem se rozhodl pro EasyPHP a předpokládám, že pak bude možno tuto webovou aplikaci nasadit víceméně kdekoliv a bez problémů.
5.2. SQL vrstva Při popisu, jak bych si představoval připojení k databázi, jsem říkal, že budu vyžadovat, aby bylo možné použít jakoukoliv existující databázi anebo aspoň ty nejběžnější v dnešní době. Tím, že pro tvorbu aplikace jsem zvolil skriptovací jazyk PHP, je třeba upřesnit, že se bude jednat o databáze, které tento programovací jazyk umí používat, respektive pro něž má moduly s funkcemi. A protože v dnešní době umí pracovat se všemi známými databázovými produkty na trhu, neměl by vzniknout žádný problém. Samotnou vrstvu je třeba rozdělit do dvou částí. Jednu pro potřeby webové aplikace pro správu obsahu a druhou ke komunikaci se samotnou databází. První na straně webové aplikace bude používat stále tytéž funkce při komunikaci s databází a na základě dědičnosti a zvolené databáze dojde k transformaci na funkce schopné s ní komunikovat. A tak vznikne několik „překladových“, zděděných tříd, kdy každá z nich bude mít na starost již konkrétní databázi. Budu tedy implementovat základní třídu a k ní několik zděděných, těch
39
očekávám kolem 3-5 podle množství předpřipravených databází. Samozřejmě pro funkčnost každé z těch databází v nich budu muset mít vytvořenu tabulkovou strukturu a tu mít naplněnu příslušnými metadaty.
5.3. Aplikační a prezentační vrstva V následujících několika odstavcích se pokusím popsat, jak by měla fungovat logika aplikační a prezentační vrstvy, které generují obsah webové stránky na základě dat a metadat z databáze při provedení akce uživatele. Akcí se zde myslí výběr položky v menu anebo již konkrétního záznamu. Jak jsem se již dříve popsal u E-R modelu databáze, jednotlivé tabulky neobsahují v zásadě žádné vzájemné propojení mezi sebou. Nalézt se tam dá jediná vazba mezi tabulkou určenou pro menu cms_admingroups a cms_menulab, pomocí níž můžu přejmenovat položky v něm. Přesto jsou pro zobrazení obsahu použity povětšinou všechny tabulky nacházející se v databázi. To, jakou použít , má na starost jádro systému, které se na základě vstupu, url odkazu, postará o celou tuto problematiku. Výstupní webová stránka bude mít vždy podobu tří framů, jejich hranice jsem na tomto obrázku zvýraznil červenou barvou. Jeden na levé straně, kde se zobrazí menu, další ve vrchní části. Tam je místo pro logo, případně další informace, podle nichž se uživatel bude schopen zorientovat, kde se v systému nachází anebo co momentálně provádí. Například, pokud edituje záznam o pacientovi a prohlíží si jeho lékařské záznamy, tak zde může mít základní informace o něm. Poslední a nejdůležitější frame ve zbytku stránky bude sloužit k zobrazení obsahu záznamů. V něm se budou provádět všechny změny a úpravy obsahu, zobrazovaných struktur, zdrojových kódů a práv uživatelů.
40
obr. 9 - Layout systému
Po počáteční inicializaci, kdy se nahrají všechny dostupné komponenty a dojde k přihlášení uživatele, bude vstupovat do celé aplikace již jen jediný vstup. A to webový odkaz URL s předefinovanou strukturou, říkající vše potřebné jádru k tomu, aby sestavilo výstup pro uživatele.
41
6. Realizace Na základě informací a údajů, které jsem získal analýzou a jsou popsané v předchozích kapitolách, jsem začal s realizací systému pro správu obsahu – CMS. Nejprve jsem stáhl z internetu balíček EasyPHP[28] a provedl jeho instalaci na operačním systému Windows XP. Tím jsem získal plně funkční webový server používající Apache[13], phpmyadmin[12], skriptovací jazyk PHP[29] a databázi MySQL. Konkrétní konfigurace verzí je v rámci tohoto balíčku easyphp 1.8 : apache 1.3.33 - php 4.3.10 - mysql 4.1.9 - phpmyadmin 2.6.1 . Poté mně zbývalo vybrat jen vhodný editor na programování. A protože již dlouhou dobu používám program pspad[30] a jsem s ním spokojený, použil jsem ho i v tomto případě. Mám tedy připraveno vše k tomu, abych mohl začít s tvorbou databáze a pak se samotným programováním této aplikace.
6.1. Tvorba struktury databáze Jak jsem již v předchozí části říkal, provedl jsem instalaci databáze MySQL. Zároveň jsem již zmínil E-R model databáze, z kterého jsem vycházel a podle něhož jsem vytvořil oněch zmíněných 10 základních tabulek v databázi, nutných pro funkčnost tohoto softwaru. K jejich vytvoření jsem použil nástroj phpmyadmin. Ten má velmi pěkné a intuitivní rozhraní a v zásadě každý je pomocí něho schopen vytvořit databázi a tabulky v ní. Databázi samotnou jsem nazval CMS a tabulky s jednotlivými sloupečky přesně podle E-R modelu. Tím mi vznikla základní struktura v MySQL a zbývalo do ní vložit potřebná data k funkčnosti webové aplikace. Naplnil jsem tedy následující tabulky příslušnými daty: cms_htmlpart, cms_usergroup, cms_seting, cms_authors, cms_forms, cms_admingroups . V cms_htmlpart jsem předvyplnil několik záhlaví, zápatí a těl webových stránek. Nadefinoval jsem čtyři uživatelské skupiny v cms_usergroups, konkrétně se jedná o aplikačního administrátora, administrátora, editora a čtenáře. Tabulku cms_setting jsem naplnil sloupci z databáze, pro které jsem potřeboval, aby se staly tak zvanými „boolean“ sloupečky a dovolovaly mi je nastavovat na dvě hodnoty. Pro tuto moji databázi jsem nadefinoval jednoho uživatele s aplikačními právy nad celou aplikací, ten je uložen v tabulce cms_authors. A pak již zbývaly poslední dvě velké tabulky k vyplnění, první z nich je menu, definované v cms_admingroups. Zde jsem vytvořil odkazy pro menu a nastavil práva pro editaci každé z tabulek v databázi, plus několik málo
42
oddělovačů pro přehlednost menu, link pro odhlášení ze systému a pro aplikačního administrátora ještě jeden odkaz, říkající mu vše o jeho momentální konfiguraci webového serveru. Na závěr bylo třeba pro každou existující tabulku v databázi vytvořit její popis uložený v tabulce cms_forms, z těch základních a nutných jsem definoval název tabulky, její primární klíč, povinné sloupce, sql dotaz pro tuto tabulku, jaké připojení se má pro ni použít , a pokud obsahovala, tak i master-detail vazbu. Po vykonání této dlouhé práce nad databází jsem provedl export do souboru. A to jak struktury, tak i dat v ní uložených. Aby bylo možno v dalších případech použít tento soubor jako vstupní dávku a nebylo nutné provádět opakovaně tyto kroky. Později bude třeba vytvořit stejné kroky v každé databázi, již budu chtít používat pro moji aplikaci, a vytvořit pro každou z nich takovouto úvodní dávku na počáteční naplnění.
6.2. SQL vrstva Tato vrstva je odpovědná za vše, co se děje při komunikaci mezi webovou aplikací a databází. Jejím úkolem je transformovat dotazy od aplikace na správnou zděděnou třídu a pomocí ní předložit dotaz databázovému serveru. Je tedy jednou z nejdůležitějších komponent systému. Proto teď ukážu, jak vypadá, co s ní mohu dělat a jak je používána. Základem je třída nazvaná sql, která je stavebním kamenem komunikace aplikace směrem k databázi. Proto ji popíši podrobněji, k tomu přikládám i její výpis. class sql { // Connection data var $engine; var $host; var $usr; var $pwd; var $db; // Database resource var $D; // Query result var $res; //Verbosity var $debug;
43
//constructor function sql($arr,$debug=0) { $this->host = $arr['host']; $this->usr = $arr['usr']; $this->pwd = $arr['pwd']; $this->db = $arr['db']; $this->prefix = $arr['prefix']; // its inheritants has to call connect to specified db $this->D = 0; $this->res = 0; $this->debug = $debug; } function query($q) { return 0; } function fetch_array($r = '') { return array(); } function fetch_row($r = '') { return array(); } function free_result($r) { return 0; } function fetch_all($r) { return array(); } function num_rows($r) { return 0; } function commit($r) { return 0; } function rollback($r) {
44
return 0; } function close() { return 0; } } Vstupem do ní jsou proměnné $engine, $host, $usr, $pwd a $db. První definuje, jaký databázový stroj se použije. V mé aplikaci je na výběr MSSQL,MySQL, Interbase a Sybase. Poté je třeba definovat adresu v síti, kde je tento stroj k nalezení, to je obsahem druhé proměnné. S tím souvisejí proměnné pro autentizaci $usr a $pwd. Čili uživatelské jméno a heslo. Poslední $db obsahuje název databáze, ke které se chci připojit. Dále pak mám připravenu proměnou $D pro odkaz na databázi, který získám po připojení k ní. Ten je ze začátku nastaven na 0, abych pak mohl bezproblémově posoudit, zda jsem se úspěšně připojil k databázi. V případě, že potřebuji mít vypsány podrobnosti o spojení s databází anebo kde mi uvízlo, je k dispozici proměnná $Debug, ta je implicitně nastavena, aby se tyto hlášky nevypisovaly, ale občas nastanou případy, kdy je třeba nalézt chybu. Například , pokud bych zadal špatně, přepsal se v údajích pro připojení k databázi, tuto chybu bych za pomoci nastavení této proměnné lehko odhalil a věděl pak, v čem je problém a ten mohl následně vyřešit. Poslední proměnná $res mi slouží k ukládání výsledků dotazů z databáze. Mám definováno několik základních funkcí pro operace s databází. Byly vybrány ty nejběžnější a jen za pomoci nich jsem schopen dělat téměř veškeré operace s ní, důkazem toho je, že celá aplikace funguje bez problémů. Tímto způsobem došlo k oddělení typu databáze od aplikace, protože pro každou databázi je třeba vytvořit třídu zděděnou. Teď jsem tedy představil, co mi vstupuje a vystupuje z této třídy a kde jaké informace uchovávám. A tak tedy představím, jak funguje zbytek. Jak jsem říkal, musím určit , jakou databázi chci použít. Podle toho se vybere třída zděděná od třídy sql. Ta již má definované všechny funkce specifické pro svůj databázový stroj a mohu skrz ni posílat dotazy do databáze a očekávat informace, údaje zpět. Toto činí připojení webové aplikace databázově nezávislým. Pokud se tak naše databáze nevyskytuje v zděděných třídách a programovací jazyk PHP má pro
45
tuto databázi funkce pro připojení a práci s ní, je už pak jen otázkou několika minut ji přidat a tím ji plně zpřístupnit pro webovou aplikaci.
6.3. Session Webové stránky jako takové jsou bezstavové, to znamená, že si nepamatují žádná data, jež do nich uživatel vyplní. A tak se programátoři a vývojáři snaží tuto situaci vylepšovat. Prvním, kdo si byl schopen něco zapamatovat, byly webové prohlížeče, avšak jejich schopnost pamatovat si je značně omezená. Povětšinou jsou to předvyplněná uživatelská jména a hesla k různým účtům. Pravdou je, že si pamatují o něco málo více, pokud k tomu započítáme i cookies a různé session. Avšak to již závisí na programátorovi. A tím se dostávám k daleko zajímavější oblasti. Dnes asi nejlepším na tomto poli je ASP.NET, alespoň co mohu říci z vlastní zkušenosti . Každý si může sám zkusit, jak mocná je tato technologie. Například, mám-li rezervační formulář o několika krocích, nemusím se strachovat o ukládání historie, stránky si ji pamatují samy , a to včetně dat. O tom se lehko přesvědčím, pokud se rozhodnu vrátit zpět k nějakým již vyplněným údajům. Naleznu je tam všechny, v té samé podobě, jak jsem je vyplnil. Tento systém pro správu obsahu však není postaven na technologii ASP.NET, ale PHP. Ta nemá takovýto mechanismus implementovaný, pouze nabízí prostřednictvím session možnost zapamatovat si nějaké hodnoty. A právě v „proměnné“ tohoto typu si ukládá moje webová aplikace vše potřebné. Hned po samotné autentizaci uživatele se uloží jeho jméno, heslo, autorizační level a několik málo dalších potřebných údajů o něm do jedné velké session. Dále je v ní uložena konfigurace, jež se načte při prvotní inicializaci. Do ní spadá nastavení aplikace čtené ze souboru config.inc, potom dostupné moduly a všechny ostatní potřebné údaje pro správný refresh stránky, těmi mám na mysli parametry zmíněných modulů. Takže by se dalo říci, že se jedná o jakousi paměť této aplikace, protože při každém zobrazení stránky je právě do této session nahlédnuto, zda je uživatel autentizovaný správně, pak se zrekonstruují všechny moduly s jejich nastaveními a na základě url dotazu jsou ty správné moduly použity. Tento mechanismus byl zvolen, protože jak už jsem říkal, samotné PHP je bezstavové a při každém načítání stránky zobrazí jen ty informace, které
46
dostane, žádné si nepamatuje samo. Takže jsem mu přidal pomocnou berličku v podobně paměti ukládané do session.
6.4. Autentizace Při otevření adresy s touto webovou aplikací je po uživateli vyžadováno přihlášení do systému. Celou tuto proceduru obsluhuje jedna třída, nazvaná login. Po vložení uživatelského jména a hesla jsou tyto údaje poslány do nové instance třídy login, zároveň je k ní přidána proměnná obsahující autentizační parametry pro databázi. V třídě je pak zavolán sql dotaz na tabulku cms_authors, zda se takový uživatel vyskytuje v systému. Pokud je nalezen, vrací se celý kompletní záznam o něm. Ten obsahuje i autorizační level. Podle role v systému se pak zobrazí ta část menu, ke které má přístup. V případě neúspěchu je uživateli tento fakt oznámen a je mu umožněno se přihlásit znovu. Systém si nikde neukládá pokusy o přihlášení . a je tedy možno to zkoušet do nekonečna. Možná by v nějakém rozšíření bylo dobré zavést nějaký zákaz pro účty, které se pokusí přihlásit vícekrát v krátké době a neúspěšně. Stejně tak jsem přišel ještě na jednu bezpečnostní díru, která je podle mě palčivější. Tím je možnost podvrhnout dotaz. O možném řešení tohoto problému a jeho detailnějším popisu se dá dočíst v sekci 8.2 možné zlepšení webové aplikace.
6.5. Konfigurační soubor V sekci 6.3 byl zmíněn konfigurační soubor používaný aplikací. Představím tedy, jak vypadá, co v něm k čemu slouží. Nejdříve zde uvedu jeho výpis, aby bylo dobře poznat, o čem je řeč, už jen tento výpis sám o sobě je dost intuitivní. //Connection to DATA database (MYSQL) $dat2 = array( 'engine' => 'mysql', 'host' => 'localhost', 'usr' => 'username', 'pwd' => 'password',
47
'db_conn' => 'mtd', 'db' => 'CMS', 'prefix' => 'cms_'); //Connection to METADTA database (MYSQL) $dat = array( 'engine' => 'mysql', 'host' => 'localhost', 'usr' => 'username', 'pwd' => 'password', 'db_conn' => 'mtd', 'db' => 'CMS', 'prefix' => 'cms_'); //Paths $lng = 'CZ'; $imgdir = "images/$lng"; $paths = array( 'class_path' => 'modules', 'language' => $lng, 'imagedir' => $imgdir, 'styledir' => 'styles', 'icon_dir' => $imgdir, 'prefix' => 'cms_', 'PageSize' => 20); Jak je z výpisu vidět, máme zde 2 proměnné pro připojení k databázi. To souvisí s faktem, že aplikace nabízí možnost mít odděleně metadata a samotná data. Pro každou se definuje typ databáze, kterou používá, uživatelské jméno a heslo, název databáze , k níž se aplikace má připojit, typ spojení a prefix tabulek. Dále mám možnost mít několik jazykových verzí a ke každé zvlášť obrázky. To má význam například u menu, kde místo textu se zobrazují obrázky a potřebuji, aby byly v tom správném jazyku. Poslední důležitou proměnnou je $paths, kde mám definované všechny cesty, první je cesta, kde se mají načíst všechny moduly dostupné mé aplikaci, dále jaký jazyk se bude používat, kde naleznu obrázky pro webovou stránku, kam se mám podívat na css styly používané pro vylepšení vzhledu stránky, adresář s ikonami, prefix tabulek a kolik záznamů se má zobrazit na stránce.
48
6.6. Odkaz webové aplikace content.php?view=htmlpart&table=fieldlab;;[$0]show(4)&[$0]show( 2)&[2]selectform()[$0]show(3) content.php?view=htmlpart&table=structtable;;[$0]show(5)&[$0]sh ow(2)&[2]screenform(1)&f_index=1&s_index=Persoon&[$0]show(3)
Tuto kapitolu uvádím dvěma ukázkami odkazu, které jsou nejčastěji používané v tomto systému. Proto v další části popíšu ve zkratce jednotlivé části. content.php?module1_name=param&module2_name=param&...=param;;meth od=prm1;prm2;prm3&method=prm A takto je poskládáno za sebou vše, co se v odkazu nachází. Nejdříve nahrávám moduly, ty jsou odděleny ampersandama (&) a každý z nich dostává vstupní parametr. Dále pak za dvojicí středníků máme jednotlivé metody a jejich parametry. To vše se lehko dá vyčíst z ukázkové struktury odkazu výše. Pokaždé tedy používám soubor content.php, kde dochází k rozparsování odkazu na jednotlivé části. Zároveň je třeba říct, že modul view je třeba použít pro zobrazení jednotlivých html částí z databáze. Přesněji říkám, v které tabulce je má hledat. Následuje zavolání modulu table, tomu dávám za vstup tabulku pro zobrazení. Když již vím, odkud mám nahrávat html fragmety a z jaké tabulky budu zobrazovat záznamy, respektive detail, tak je třeba definovat ještě metody. Modul show nahraje konkrétní kód podle id záznamu a ten je za sebe řazen v tom pořadí, jak je volán v odkazu. Ne jinak je to u funkcí, modulů selectform a screenform, první je pro zobrazení všech záznamů a druhý jednoho konkrétního. V případě druhé ukázky odkazu je tu ještě menší rozšíření. Protože občas tabulka má více než jeden primární klíč k identifikaci záznamu, je třeba je mít uvedené v odkazu. Při parsování pak nejsou nalezeny metody tohoto názvu, ale přesto jsou tyto proměnné uloženy v session a já jsem pak podle nich schopen nalézt správný záznam.
6.7. prezentační vrstva webové aplikace Vše , co se zobrazí uživateli, je závislé na odkazu popsaném v minulém oddílu. Vysvětlil jsem, že je velmi komplexní a není zpočátku jednoduché ho plně pochopit. Ale až častým používáním se vžije jeho struktura.
49
Celá funkčnost pro zobrazování obsahu uživateli, tedy co se týče prezentační vrstvy webové aplikace, je v souboru components.php. Zde je definováno několik funkci v rámci jedné velké třídy, která nese jméno table. Proto v následujících několika odstavcích popíši, co se v nich děje a jak fungují.
6.7.1.
Konstruktor table třídy table
Zde v konstruktoru se provádí dotaz do systémové tabulky databázového stroje, kde chci vědět informace o konkrétní tabulce. Těmi jsou jména sloupců, jakého jsou typu, jaký je jejich primární klíč a jejich velikost. Na základě získaných informací pak začínám pracovat s danou tabulkou. Další , co je důležité zde zmínit, je fakt, když chci používat jinou databázi než tu , pro kterou tento specifický dotaz již mám připravený. Protože ten je pro každou jiný , musím tedy i zde doplnit malinký kousek kódu, stejně jako je tomu v případě sql třídy. Opět se jedná o jednorázovou záležitost, kterou pak budu v budoucnu moci již používat bez omezení a nutnosti jakékoliv změny.
6.7.2.
Funkce get_fieldlabels
Tato funkce, jak už z jejího názvu vyplývá, má za úkol pouze jednu věc. Pokud mám v tabulce cms_forms vyplněnu u sloupce form_fieldlab hodnotu „fieldlab“, tak je funkce zavolána a podívá se do tabulky cms_fieldlab, zda zde pro aktuální tabulku mám nějaký záznam. Pokud ano, tak všechny sloupce v ní uvedené se přejmenují předvyplněným jménem.
6.7.3.
Funkce data
Tato funkce je určena pro nahrání dat konkrétního záznamu z databáze, který je pak pomocí funkce screenform prezentován uživateli. Jedná se o velmi jednoduchou funkcionalitu, kdy jako vstup předkládám id záznamu. A protože v globálních proměnných mám uloženo, v které tabulce ho budu hledat, je již velmi jednoduché sestavit dotaz na samotnou databázi a vrátit data.
6.7.4.
Funkce selectform
Při každém výběru v menu se uživateli zobrazí seznam záznamů patřící k dané
50
kategorii, respektive k tabulce. Na pozadí je to prováděno jednou funkcí, která volá ještě několik menších definovaných v ní. Jedná se o velmi rozsáhlou proceduru, která v několika málo řádcích provede velmi mnoho operací. Uživatel tedy při zobrazení záznamů vidí následující. Je zde pruh pro filtrování záznamů nad každým zobrazeným sloupcem, posouvání po záznamech dopředu, dozadu a ještě možnost přidání nové položky. Toto rozhraní je zajištěno funkcí frmNavigator. Dále pak jsou zobrazeny jednotlivé záznamy v tabulce, které je možno editovat a mazat. K tomu slouží frmBody. Aby mi toto celé fungovalo , bylo třeba zabalit zobrazenou strukturu do formuláře, který se odesílá při provádění akcí a navrací se mi požadované údaje, proto zde mám ještě jednu vcelku jednoduchou funkci frmFilter. Co se týče obsahů těchto funkcí, tak nemyslím , že by mělo smysl popisovat nějak detailněji jejich funkčnost. V některých případech by stejně bez pořádné znalosti zdrojového kódu nešlo správně a korektně nastínit, co se v nich kde děje. Je zde několik globálních proměnných, majících v sobě uložené data , na jejichž základě dochází k parsování a tvorbě formuláře.
6.7.5.
Funkce screenform
Screenform je určena pro zobrazení konkrétního záznamu anebo jeho přidání. Zároveň má za úkol přidat do webové stránky kusy javascriptových kódů pro kontrolu dat před samotným odesláním. To je zde z toho důvodu, aby byly vyplněny všechny údaje, které vyžadujeme a zároveň byly korektně. Vstupem do celé této struktury je buď id záznamu , anebo nic. Za pomoci globálních proměnných vím, z jaké tabulky to bude, které připojení použít a zda se bude jednat o editaci anebo vložení nového. V úvodu si podle toho předpřipravím dotaz do databáze a provedu ho. Hned za touto částí začínám z navrácených údajů vytvářet formulář, do kterého se vyplní data do příslušných okének anebo je zobrazím prázdná v případě nového záznamu. Přičemž vím, jakého typu je pole v databázi ,a podle toho určím, které se zvolí pro webovou stránku. A zároveň pro všechna povinná pole je vytvořena kontrola za pomoci javascriptu.
6.7.6.
Funkce screen
Již v předchozí části této diplomové práce jsem se zmiňoval o jisté sofistikované funkci, která napomůže uživateli se orientovat v tom , co vlastně dělá. Kupříkladu, když chce znát záznamy o nějaké osobě a už si je prochází
51
tak dlouho, že si nevzpomíná, kdo to je, má možnost mít nadefinovanou strukturu, do které se mu takovéto informace zobrazí. Právě pro tuto příležitost je zde funkce screen, jejím vstupem je id struktury, kterou chci zobrazit a na ní se podívá do tabulky cms_structtable. Dostanu html kód, v kterém mám připravené proměnné, jež je třeba nahradit a to vše funkce udělá. Poté jsou tato data zobrazena v horní části systému vedle loga aplikace. To je z toho důvodu, že tato část zůstává stále po celou dobu stejná a nedochází zde k obměně, pouze při zavolání změny takovéto struktury anebo pokud nemám zvolenou editaci záznamu a jeho podzáznamů, takovou formu nápovědy mohu potřebovat.
6.7.7.
Funkce show
Aplikace pro správu obsahu je připravena tak, že plno jejích částí, které se zobrazují uživateli , je předdefinováno a uloženo v databázi a pak právě funkce show dostává jako vstupní parametr id záznamu. Ten je nalezne v tabulce cms_htmlpart a použije se. Je to tedy velmi jednoduchá, přesto však důležitá část programu, protože pomocí jejího volání dokážu sestavit stránku z jednotlivých uložených částí.
6.8. Dokumentace Pokaždé , když vzniká nějaký projekt, je potřeba potom pro jeho ovládání vytvořit i dokumentaci, v níž je napsáno a vysvětleno ovládání programu. Povětšinou mívá dvě části, jednu pro administrátora a druhou pro každodenní uživatele. Proto v příloze je vytvořena dokumentace pro každou uživatelskou roli, zároveň je zde popsána instalace a konfigurace.
52
7. Testování Při vývoji bylo použito několik technik testování, a proto v jednotlivých bodech popíší, o co se jedná a jakých výsledků jsem dosáhl.
7.1. Explorativní technika testování Jedná se o velmi účinnou a hodně chyb objevující techniku. Aktérem je osoba, která nezná systém anebo je s ním pouze v rychlosti seznámena. Poté je vyzvána k tomu, aby se pokusila se systémem pracovat a používat ho. Tento aktér by měl být co nejvíce podobný finálnímu uživateli, aby se zjistilo, zda je aplikace intuitivní a neklade přílišné nároky na uživatele. Uživateli je dáno za úkol po prvotním seznámení provést jisté typické úkony, které se budou v systému dělat. Přitom je bedlivě sledován a zaznamenávají se chyby a nepřesnosti, na než se přijde v průběhu tohoto testování. Tento systém byl testován dvěma osobami, přičemž se jednalo o lidi, kteří se neznali, a tedy nemohli být vzájemně ovlivněni svými poznatky o systému. Webová aplikace jimi byla testována po větších částech z důvodu ušetření jejich času. Testeři prováděli akce vkládání,editace a mazání záznamů, přidávání položek do menu, tvorbu vzhledu zobrazení, které se objeví po kliknutí na položku v menu, práci s uživateli a jejich rolemi, tvorbu a používání HTML fragmentů. V průběhu testování byl zaznamenán určitý počet nedostatků, některé byly v kódu, jiné v typu prohlížeče, ale všechny se podařilo úspěšně vyřešit.
7.2. Jednotkové testování V tomto druhu testu se jedná o otestování každé komponenty ( prvku ) zvlášť, a to na co nejvíce možností, které mohou nastat. Předem musím říci, že tímto způsobem nebyl testován celý systém, ale jen některé jeho části. Stále je možné v kódu nalézt proměnnou jménem debug pro budoucí vývoj. Ta byla zavedena proto, že jazyk PHP nemá sám o sobě možnost, jak krokovat, respektive debugovat. To jsem nahradil možnostmi výpisu u jistých částí kódu, ty jsou za normálních okolností, ostrém běhu aplikace potlačeny.
53
Tento způsob testování odhalil velké množství chyb, které v průběhu tvorby nových částí vznikaly, tudíž posloužil svému účelu a napomohl mi je napravit včas. Jednou velkou částí bylo testování formulářů. Ty jsou pro činnost celého systému zcela zásadní. Komunikace s databází probíhá skoro výhradně jen přes ně a je důležité, aby korektně zkontrolovaly naplnění všech polí a na jejich základě buď připravily SQL dotaz , anebo zavolaly jiný formulář s jistými parametry. Zkušenosti z praxe prokázaly , že testování pouze metodou Black Box je nedostatečné, proto je třeba vycházet ze znalosti vnitřní implementace a postupně formuláře plnit různými daty a sledovat jejich činnost. Obzvláště důležité je zkontrolovat, co se stane, pokud některé pole není vyplněno, pokud je vyplněno nesprávně ( navíc vždy existuje celá řada možností, jak je vyplnit nesprávně) a také pokud jsou všechna pole zadána správně. Počet možností roste exponenciálně se složitostí formuláře a je nemožné ověřit je všechny, ale u každého pole je nutné ověřit alespoň tři výše uvedené varianty, a to několikrát v různých kombinacích s jinými poli. Opět i zde bylo odhaleno několik chyb, které bylo třeba napravit, aby webová aplikace pracovala korektně a bez chyb.
7.3. Zátěžové testy Zátěžové testy mají za úkol ověřit, že v mé aplikaci nedojde při vysoké zátěži k chybám, které se jinak nevyskytují. Byl proveden pokus, kdy bylo dáno dohromady 10 lidí, kteří se připojili k té samé webové aplikaci a každý z nich prováděl sledy úkonů, které by se měly se systémem normálně provádět. Těmi bylo editování největších tabulek, přidávání záznamů a procházení stromem aplikace. Ani jeden z nich nezaznamenal jakékoliv zhoršení odezvy aplikace. Nutno ještě poznamenat, že jim byly předloženy takové úkoly, které vyžadovaly větší komunikaci s databází. Takovýto průběh jsem spíše i předpokládal, protože webové aplikace jako takové jsou vcelku rychlé a výkonné. Nevyžadují moc systémových prostředků a teprve při připojení tisíců uživatelů v jednu chvíli dochází k jejich zpomalení. A to často ještě záleží na typu webové serveru, zda je dohromady, fyzicky na jednom počítači s databází anebo odděleně, na rychlosti připojení a kvalitě spojení v síti. Tyto parametry jsem neměl možnost otestovat, protože nějaké smysluplné výsledky bych očekával až teprve při konkrétním nasazení na internetu. Domnívám se tudíž, že tento systém by si poradil i s velkým počtem uživatelů najednou.
54
7.4. Závěr z testování Webovou aplikaci jsem otestoval několika způsoby, proto předpokládám, že byly odstraněny nejzávažnější chyby a nic nebrání v jejím plnohodnotném provozu.
55
8. Závěr Projekt webové aplikace pro správu obsahu se podařilo naprogramovat tak, jak jsem předpokládal a plánoval. V průběhu ujasňování myšlenek o tom, jak by co mělo fungovat a jak by mělo být naprogramováno, jsem si často mohl vybrat z několika variant. Některé jsou zažité a odzkoušené, další jsou buď úplně nové, anebo se blíží k jiným řešením. Při samotném vývoji a implementaci jsem zjistil, že má uvažování vedla správným směrem. A již v této etapě mě napadaly myšlenky, jak aplikaci vylepšit. Proto jsem navrhl vylepšení a rozšíření mé aplikace. Jejich přínosem by mělo být, že aplikace bude uživatelsky přívětivější a bezpečnější. A přestože mě takových zlepšení napadlo relativně hodně, tak si myslím, že aplikace je z tohoto důvodu schopna svého života i do budoucna.
8.1. Přínos Pokaždé, když se vyvíjí nějaký nový software, tak je to z určitého důvodu a očekává se od něj, že přinese něco nového nebo se pokusí najít nové řešení, jež se nakonec může ukázat mnohem lepší než to původní. Tento produkt si nekladl za cíl uspokojit potřeby náročných uživatelů takovýchto systémů. Přesto i pro ně by se mohl stát cenným. Nic totiž nebrání tomu, aby byl doplněn o další „features“. Ale šlo mi o to, aby ho bylo možno nasadit na jakémkoliv počítači v kombinaci s jakoukoliv dnes používanou databází a zároveň jeho celková cena byla přijatelná i pro menší firmy, které nepotřebují žádný velký nástroj pro správu svých dat. Dalším přínosem je snadnost instalace, která má 3 kroky. Prvním je instalace EasyPHP anebo webového serveru a použití sql dávky pro databázi. Poté nastavení konfigurace v config.inc a posledním je vyplnění metadat pro datové tabulky. Vynechám-li mnou zmíněny produkt Drupal, který je schopen komunikovat se čtyřmi databázemi, tak jsem nenašel nikde na internetu žádnou další aplikaci, která by byla schopna komunikovat s více než jednou anebo výjimečně dvěma databázemi. A zároveň většina těchto systémů je platformově závislými. Tento produkt si kladl za další cíl, aby mohl být použit s jakoukoliv dostupnou databází. A to při použití jazyka PHP je splněno. Nepřišel jsme na žádnou databázi, pro kterou by nebyly napsány funkce k jejímu užívání. A proč jsem vyžadoval tuto vlastnost? Vezmeme-li v úvahu firemní prostředí, tak v dnešní době se v něm nachází
56
nějaká databáze, ať už novější, starší, výkonná anebo jen jednoduchá, a plní účel,pro který byla pořízena. A najednou je potřeba spravovat nějaký obsah. Ano, můžeme použít nějaký stávající produkt s databází typu MySQL, která je zadarmo, avšak co podniknout, jestliže má firma již svoji databázi a nechce si instalovat novou, se kterou by byly spojené tvorby uživatelských rolí a přenos stávajících dat. Pravděpodobně by jim vyhovovala moje webová aplikace, která nabídne použití jejich současné databáze. Nemusí jít ani o tento případ, ale jen o to, že firma anebo podnik by chtěly využít více svoji zakoupenou databázi, a ne přidávat další do svého systému. S rozběhnutím nové databáze je spojeno slušné množství práce, které by mohlo leckteré potenciální uživatele od nasazení tohoto typu aplikace odradit. Je totiž třeba nadefinovat uživatelské účty, naplnit ji nějakými daty a povolit porty, na kterých běží. Co bych tedy vyzdvihl na tomto produktu, respektive webové aplikaci? Její platformovou, databázovou nezávislost za použití ověřených technologií, rychlost instalace a modularitu, tudíž s možností dalšího vývoje do budoucna.
8.2. Možné zlepšení webové aplikace 8.2.1. Automatická tvorba odkazu pro menu v tabulce cms_admingroups Protože tento link je zpočátku poněkud složitější na pochopení a vyžaduje jistou potřebu znalosti jeho tvorby, bylo by dobré mít nějaký nástroj nebo možnost ho vytvořit jednodušeji. Pro tvorbu tohoto linku by bylo možné použít speciální webovou stránku. Ta by mohla fungovat následujícím způsobem. Vedle políčka pro vstup tohoto odkazu by byl odkaz anebo tlačítko s popisem „tvorba odkazu“. Otevřela by se webová stránka mající 3 roletkové nabídky a tlačítko vytvořit. V první roletce by byly ty části, jež bychom dali do skupiny hlavička,v druhé části zbytek a tělo. V poslední už je zápatí. Uživatel by poté měl za úkol pouze vybrat kombinaci těchto 3 a kliknout na tlačítko tvorba odkazu. Tím by se vytvořil jednoduše odkaz, který by na těch správných místech vyplnil údaje vybrané uživatelem. Nejednalo by se o naprosto plnohodnotný nástroj pro tvorbu odkazů, ale
57
dokázal by usnadnit práci v alespoň 80-90 procentech případů, což podle mého názoru je docela slušná úspora času.
8.2.2. Dynamická kontrola vstupních dat a maska pole Momentálně je v systému zavedena kontrola vstupních dat, ale pouze pro pole, jež jsou povinná. To není moc silná kontrola a je možné donutit systém k chybě, pokud se bude člověk snažit. Proto jedním z dalších rozšíření by bylo udělat tuto kontrolu silnější. Toho by se dalo docílit tím, že bych vytvořil buď úplně speciální tabulku, kde by se uvedl každý sloupeček z každé tabulky, který chci kontrolovat ,anebo bych musel mít záznam v tabulce cms_fieldlab pro každý sloupec. Z mého pohledu se zdá lepší první varianta, protože tabulka cms_fieldlab je určena primárně pro přejmenovávání polí, i když je předpřipravena i pro tuto možnost kontroly. V průběhu vývoje jsem však došel k názoru, že by bylo dobré mít tuto funkčnost oddělenou a vzájemně nezávislou. Zároveň by se dala vylepšit o masku. Ta by fungovala tím způsobem, že by webové aplikaci řekla, co se má pro dané pole kontrolovat a zároveň jak. Takovouto masku bych potom mohl využít pro každé pole a nezáleželo by, jakého by bylo typu v databázi. Nemusel bych se zajímat o to, zda se jedná o sloupec typu integer, varchar, datetime anebo jiný. Jediné, co bych udělal , by bylo vložení masky říkající - kontroluj toto pole jako datum, text , číslo anebo jinak. Zároveň zadáním maximální, případně minimální délky by bylo ošetřeno, že se vstupní data od uživatele vejdou do sloupce v databázi a nedojde k chybě anebo ztrátě dat. Pravděpodobně by se dalo namítnou, že ne každý vyžaduje tuto kontrolu tak silnou a někdo se spokojí jen s již definovanou a funkční základní. Proto zde zmíněné rozšíření je třeba při realizaci udělat tak, aby nebylo nutné, ale pouze možnou náhradou, respektive rozšířením již stávající kontroly. V následujících několika řádcích popíšu, jak bych si představoval konkrétní realizaci. Jak by se změnila databáze, upravila struktura, co by bylo třeba udělat z pohledu kódu a jaké údaje vložit do metadat. Jak jsem již říkal, v databázi by došlo k vytvoření nové tabulky, kde by každý sloupeček tabulky byl určen svým jménem v ní a názvem tabulky, do které přísluší. Dalšími údaji by byla maska, pro kterou by bylo dobré udělat vztah master-detail a v detailu mít definované potřebné masky. Ať už pro datum,
58
číslo, text anebo nějakou jinou strukturu. Občas například uživatel vyžaduje, aby hodnota byla v nějakém rozsahu od- do anebo že je vstupní údaj standardizován. Tudíž by zde vlastně měl být buď přímo regulární výraz , anebo ještě jeden sloupeček, který bude určovat, zda maska je čistě maska anebo již zmíněný regulární výraz. Dále pak možnost vyplnit minimální a maximální hodnotu v případě čísla anebo datový rozsah pro databázový typ datetime. Pravděpodobně posledním dostatečným parametrem pro kontrolu by pak byla délka vstupního řetězce ve znacích. S pomocí těchto údajů bych pak měl být schopen zajistit, aby nedošlo ke konfliktu s databází při vkládání anebo editaci dat. V kódu by se dalo rozcestí na místo, kde je teď momentálně vkládána jednoduchá kontrola, které by říkalo, co se má použít. Přičemž v případě použití masky by musela být jasně stanovena pravidla, co se v ní a jak může objevit, aby pak kód na to mohl správně zareagovat, a tedy vybudovat korektní a masce odpovídají javascriptový kód pro kontrolu vstupních dat. Pro případ nějaké nepovedené anebo neinterpretovatelné masky do javascriptu, by se vložila stávající kontrola pro daný typ vstupního pole. Teď tedy ještě popíši správnou tvorbu masky. V zásadě nejjednodušší je zapsat ji jako regulární výraz. Ale měla by se dát možnost i ostatním, aby byli schopni ji vytvořit. Tudíž musím zavést klasicky známé věci jako zápis data ve formátu „dd-mm-rr“, čísla třeba „c“, textu „t“, emailu „email“ a tak dál. To, jaké by se zvolily možnosti, by muselo být uvedeno v manuálu a zároveň by zde mělo být řečeno, že není možné tímto způsobem postihnout jakýkoliv řetězec, pro tento případ je tu právě regulární výraz.
8.2.3.
Tvorba reportu
Aplikace pro správu obsahu by pravděpodobně měla obsahovat nějaký výstup typu report. Co se týče této aplikace, tak zatím nedošlo k implementaci, ale nutno poznamenat, že nic nebrání tomu přidat do systému nějaký typ. Říkám nějaký, protože je to dost složitá otázka. Ne každý si představuje ten report ve stejném smyslu, co by mělo být jeho výstupem, zda by měla být možnost obměňovat tento výstup, případně možnost tvořit různé typy reportů. A to je právě kamenem úrazu této komponenty. Na internetu je možné najít několik již implementovaných tříd pro tvorbu reportů. Příkladem může být PHP Report Generator [31] anebo PHP Report Maker 1.0 [32] . První z nich je šířen pod licencí GNU a pracuje nad databází MySQL a druhý je naopak zpoplatněný a též běžící nad MySQL. Avšak oba mi nevyhovují. Můj systém je postaven tak, že může použít jakoukoliv databázi, na kterou lze přistupovat za pomoci PHP.
59
Mám tedy dvě možnosti, buď použít nějaký reportovací nástroj na internetu a přepsat ho tak, aby byl použitelný v mé webové aplikaci , anebo si napsat vlastní. Těžko proto říci, jaká varianta by byla schůdnější a dala kýžený výsledek. Pokud bych se měl k nějaké variantě přiklonit, tak bych použil již nějaké stávající řešení. Odzkoušením chování nabízených řešení na internetu bych našel ty nejvhodnější produkty a v dalším kole po prozkoumání kódu kandidátů z prvního výběru by byl nalezen ten, jež nabízí co nejvíce možností a zároveň jeho implementace, respektive přepsání do mé aplikace zabere rozumné množství času.
8.2.4.
Přidání dalších dávek pro databáze
Momentální stav aplikace je takový, že zatím nemá předpřipravenu více než jednu dávku. Tudíž pro zvýšení rychlosti nasazení by bylo dobré připravit další, alespoň pro ty databáze, jež mají vytvořenu zděděnou třídu sql. Jejich stvoření by neměl být problém, protože se jedná o jednoduché sql příkazy, myšleno, že zde nejsou žádné úložné procedury, pohledy a triggery. Větším problémem je vlastnění databáze samotné, komerční databáze také něco stojí a dále pak je od těchto databází vyžadován i nějaký výkon stroje, na kterém běží. Toto je hlavní důvod, proč není více dávek, ale existuje zatím pouze pro databázi MySQL.
8.2.5. Autentizace za pomoci úložné procedury Co je myšleno tímto rozšířením anebo k čemu by bylo dobré? Především je to o zvýšení bezpečnosti celé webové aplikace. I když máme autentizaci a při každém načítání se kontroluje, zda jsme ten uživatel, co může provádět nějaké akce s aplikací, není zaručeno, že někdo nepřijde na to, jak podstrčit nějaký škodlivý kód již při samostatném přihlašování. Stačí místo dotazu typu select vložit dotaz typu delete a najednou je prázdná tabulka. To by bylo pravděpodobně dost nemilé zjištění. Stávající aplikace se při kontrole přihlašovacích údajů musí připojit k databázi, pošle dotaz a ten se vykoná. A jak jsem nastínil v minulém odstavci, to je přesně ten problém. Provádí se dotaz nebo akce s databází a tam již nikdo
60
nekontroluje, zda je vše v pořádku, pouze se doufá, že to bude přesně to, co bylo ve zdrojových kódech. Možnost, jak se vyvarovat takové situace, aby nám nikdo nepodstrčil špatný dotaz do databáze, je nepřipojit se před autentizací přímo, ale zavolat uloženou proceduru. Ta má jasně řečeno, jaké vstupy očekává. Pokud jí zadáme uživatelské jméno, heslo a případně vybereme, k jakému webu se chceme připojit, tak nám vrátí platnost nebo neplatnost o této akci. Buďto najde takového uživatele v databázi a přístup je povolen, anebo není. S tím je však spojen další problém. Použitá databáze MySQL toho není schopna, ale použije-li se nějaká vyspělejší typu Sybase, Oracle anebo MSSQL, kde úložné procedury můžu tvořit, tak si tím zvýším bezpečnost aplikace a nemusím se trápit s útoky na moji databázi.
8.2.6.
Trigger pro změnu záznamu
Toto vylepšení by mělo být jakousi historií změn záznamu. Čas od času se stane, že dojde ke změně záznamu, ať už chtěně, nebo nechtěně , a je potřeba dohledat, kdo to byl. A k tomu by mi dopomohlo vystavění triggerů. Opět, jako v minulém případě , je toto řešení možné použít teprve u vyspělejší databáze, ale rozhodně je to velmi dobré vylepšení. V zásadě jsou asi dvě možnosti, jak to udělat, první z nich je u každé tabulky vytvořit čtyři další sloupce, kdy první by sloužil pro uložení data ,vložení záznamu do databáze. Druhý by obsahoval jednoznačnou identifikaci uživatele, který je jeho tvůrcem. Poslední dva by sloužily k naprosto stejnému účelu, pouze při vložení by obsahovaly stejné údaje jako první dvojice, ale při změně záznamu by v nich již byly údaje toho, kdo změnu provedl. Tak bych věděl, kdo vložil záznam a zároveň, kdo ho změnil naposledy. Druhou možností je vytvořit speciální tabulku logů změn v databázi. Ta by fungovala úplně na stejném principu, jen bych musel přidat další sloupce pro jednoznačné určení záznamu v rámci celé mé databáze, což by neměl být problém. K tomu mi stačí nejméně dva a nejvíce tři sloupce. První by obsahoval název tabulky, druhý id záznamu a třetí volitelný pro případ, že je více datových častí k jednomu jádru, tak by určoval ,o jakou tabulku se jedná. Samozřejmě se předpokládá, že takováto tabulka by byla přístupná pouze aplikačnímu administrátorovi a spadala do takzvaných metadat. Každé z těchto řešení má své přednosti a nedostatky, při druhé variantě jsou
61
tyto informace schované v metadatech a tedy nejsou tak úplně na očích, ale potřebuji zase ukládat více informací k zpětnému nalezení záznamu.
8.2.7.
Ajax pro vyhledávání a nápovědu
Při velkém množství záznamů v nějaké kategorii je poněkud složitější najít ten, který hledám. Systém sice umí vyhledávat nad sloupcem, ale toto hledání nemusí být vždy úspěšné. Proto by stálo za to udělat samotnou sekci, kde by se zadávala klíčová slova písmeno po písmenu a postupně by se mi nabízela hesla k vyhledání. Tak jako je to uděláno například na seznamu[33].
8.3. Závěr Uvedl jsem zde několik podle mě dobrých vylepšení, která by si tato aplikace do budoucna ještě zasloužila pro svůj lepší chod a bezpečnost. Pravděpodobně by se našla ještě další, jež zde chybí a bylo by vhodné je implementovat. Ale jak to tak už u softwaru bývá, nejdříve se vydá první verze a od ní vznikají další a další, podle potřeb uživatelů, vývojem aplikace samotné, při vzniku záplat a řešení dalších problémů, které při běhu aplikace vyvstanou. A tedy tato webová aplikace pro správu obsahu, by měla být brána jako takový dobrý základ, který je možno dále rozvíjet.
62
Použitá literatura [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]
Myslíme v jazyku UML – Joseph Schmuller, vydavatelství Grada Google Inc.- Webový vyhledávač http://www.google.com Wikipedie, otevřená encyklopedie http://cs.wikipedia.org/wiki/ Meta Group ::: scouting, seed finance & incubation: "knowledge to market" http://www.meta-group.com/ Velké srovnání cms a redakčních systémů http://asymptomatic.net/blogbreakdown.htm Drupal http://drupal.org/ Moduly systému Drupal http://www.drupal.org/project/Modules . Domovská stránka produktu Joomla http://www.joomla.org/ A Joomla! Open Source CMS Fansite http://www.mamboportal.com/ Domovská stránka redakčního systému RS2 http://rs.reality-show.net/ [EasyPHP] - PHP - Apache - MySQL - PhpMyAdmin for Windows http://www.easyphp.org/ Domovská stránka projektu phpMyAdmin http://www.phpmyadmin.net/home_page/index.php The Apache Software Foundation. Http server project [online]. Webové stránky aplikačního serveru Apache HTTP Server http://www.apache.org/ Microsoft Corporation http://www.microsoft.com/cs/cz/ PHP/MySQL Personal Content Management System http://blogcms.com/ Redakční systém a publikační systém phpRS http://www.supersvet.cz/phprs/ Team Textpattern http://www.textpattern.com/ Domovská stránka redakčního systému WordPress http://wordpress.org/ Sbírka zákonů ministerstva vnitra http://www.mvcr.cz/sbirka/ Zákoník práce 65/1965 Sb. ze dne 16. června 1965 se změnami a doplňky. Poslední novela zákonem č. 415/2005 Sb. S účinností od 1. ledna 2006 Zákon č. 525/2004 Sb. O ochraně osobních údajů Zákon č. 480/2004 Sb. O některých službách informační společnosti a o změně některých zákonů ( zákon o některých službách informační společnosti ) Zákon č 127/2005 Sb. O elektronických komunikacích a o změně některých souvisejících zákonů ( zákon o elektronických komunikacích ) Směrnice Evropského parlamentu a Rady 2002/58/ES ze dne 12 . července 2002 o zpracování osobních údajů a ochraně soukromí v odvětví elektronických komunikací. Informační systém pro aproximaci práva ( ISAP ) [database online]. Praha : Úřad vlády ČR, ČR, 2003 http://isap.vlada.cz
63
[26] Stanovisko Úřadu pro ochranu osobních údajů ve věci Monitorování elektronické pošty a ochrana soukromí a osobních údajů zaměstnanců [online].2003 http://www.uoou.cy/index.php?l=cz&m=top&mid=02:02:15 [27] Visual Paradigm International http://www.visual-paradigm.com/ [28] NetCentrum, s.r.o. a MITON CZ, s.r.o. , vyhledávač softwaru na internetu http://www.stahuj.centrum.cz/vyvojove_nastroje/ostatni/easyphp/?g[hled ano]=easyphp&g[oz]=1.8 [29] Copyright (c) 2001-2008 The PHP Group http://www.php.net/ [30] PSPad editor http://www.pspad.com/cz/ [31] PHP Report Generator http://www.phpclasses.org/browse/package/1785.html [32] Webový vyhledávač softwaru - PHP Report Maker download http://www.download3000.com/download_18490.html [33] internetový vyhledávač Seznam.cz, a.s. http://www.seznam.cz
64
Příloha A SQL kód k vytvoření struktury databáze CREATE TABLE cms_admingroups ( groupid int(11) NOT NULL auto_increment, groupdesc varchar(100) collate utf8_czech_ci default NULL, grouplink text collate utf8_czech_ci, grouptext text collate utf8_czech_ci, grouporderid varchar(10) collate utf8_czech_ci default NULL, menuimage1 varchar(255) collate utf8_czech_ci default NULL, menuimage2 varchar(255) collate utf8_czech_ci default NULL, menuvisible char(1) collate utf8_czech_ci default 'Y', hovertitle varchar(255) collate utf8_czech_ci default NULL, openinpage char(1) collate utf8_czech_ci default NULL, loginreq char(1) collate utf8_czech_ci default NULL, usergroup int(11) default NULL, menuactive char(1) collate utf8_czech_ci default 'Y', siteid bigint(10) default NULL, PRIMARY KEY (groupid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_authors ( authorid int(11) NOT NULL auto_increment, login varchar(20) collate utf8_czech_ci NOT NULL default '', `password` varchar(64) collate utf8_czech_ci default NULL, authorname varchar(50) collate utf8_czech_ci default NULL, authoremail varchar(255) collate utf8_czech_ci default NULL, regdate datetime default NULL, usergroup int(11) default '4', countrycode varchar(2) collate utf8_czech_ci default NULL, language varchar(2) collate utf8_czech_ci default NULL, departmentid int(11) default '0', siteid bigint(10) default '0', PRIMARY KEY (authorid), UNIQUE KEY login (login) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_fieldlab ( labid bigint(20) NOT NULL auto_increment, tablename varchar(45) collate utf8_czech_ci NOT NULL default '', languagecode varchar(2) collate utf8_czech_ci NOT NULL default '', label varchar(45) collate utf8_czech_ci NOT NULL default '', labeltext varchar(150) collate utf8_czech_ci default NULL, helptext text collate utf8_czech_ci, errortext text collate utf8_czech_ci,
65
mandatory int(1) NOT NULL default '0', fieldperm int(1) NOT NULL default '0', minvalue varchar(60) collate utf8_czech_ci default NULL, maxvalue varchar(60) collate utf8_czech_ci default NULL, defaultvalue varchar(60) collate utf8_czech_ci default NULL, PRIMARY KEY (labid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_forms ( form_id bigint(11) NOT NULL auto_increment, form_name varchar(250) collate utf8_czech_ci default NULL, form_fields varchar(250) collate utf8_czech_ci default NULL, form_fieldwidth varchar(250) collate utf8_czech_ci default NULL, form_query text collate utf8_czech_ci, form_where text collate utf8_czech_ci, form_keyfield varchar(250) collate utf8_czech_ci default NULL, form_table varchar(250) collate utf8_czech_ci default NULL, form_conn varchar(3) collate utf8_czech_ci NOT NULL default 'mtd', form_select_tables varchar(250) collate utf8_czech_ci default NULL, form_screenfields text collate utf8_czech_ci, form_foreignkey text collate utf8_czech_ci, form_selectscript text collate utf8_czech_ci, form_editor char(1) collate utf8_czech_ci default NULL, form_need text collate utf8_czech_ci, form_nocols char(1) collate utf8_czech_ci default '0', insertm int(11) NOT NULL default '5', updatem int(11) NOT NULL default '5', deletem int(11) NOT NULL default '5', PRIMARY KEY (form_id) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_htmlpart ( partid int(11) NOT NULL auto_increment, partname varchar(32) collate utf8_czech_ci default NULL, html text collate utf8_czech_ci, PRIMARY KEY (partid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci PACK_KEYS=0; CREATE TABLE cms_menulab ( admin_id int(11) NOT NULL auto_increment, tablelabel varchar(100) collate utf8_czech_ci default NULL, tablename varchar(255) collate utf8_czech_ci default NULL, PRIMARY KEY (admin_id)
66
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_settings ( setid bigint(10) NOT NULL auto_increment, settingname varchar(64) collate utf8_czech_ci NOT NULL default '', settingvalue text collate utf8_czech_ci, PRIMARY KEY (setid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_structform ( formid bigint(20) NOT NULL auto_increment, formname varchar(40) collate utf8_czech_ci NOT NULL default '', header text collate utf8_czech_ci, formvars text collate utf8_czech_ci, need text collate utf8_czech_ci, answer text collate utf8_czech_ci, PRIMARY KEY (formid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_structtable ( tableid bigint(20) NOT NULL auto_increment, tablename varchar(40) collate utf8_czech_ci NOT NULL default '', tablevars varchar(255) collate utf8_czech_ci default NULL, scr_page text collate utf8_czech_ci, scr_show char(1) collate utf8_czech_ci default NULL, PRIMARY KEY (tableid) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; CREATE TABLE cms_usergroups ( usergroup int(11) NOT NULL auto_increment, usergroupdesc varchar(100) collate utf8_czech_ci default NULL, siteid bigint(10) default NULL, PRIMARY KEY (usergroup) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
67
Příloha B Instalační příručka Pro instalaci programového vybavení je doporučen balíček EasyPHP, který obsahuje webový server Apache, podporu jazyka PHP a databázi MySQL. Při instalaci není třeba nic měnit a řídit se pouze pokyny při instalaci. Poté rozběhnout webový server a databázi spuštěním souboru EasyPHP.exe. Otevřít nástroj phpMyAdmin a vytvořit novou databázi, jejíž název a přístup k ní je třeba zaznamenat do konfiguračního souboru config.inc. V tomto nástroji nahrát SQL dávku pro databázi pojmenovanou cms_mysql.sql. Dojde k vytvoření struktury a přednaplnění metadaty. Nakonec je třeba rozbalit do webového adresáře soubor cms.rar, který obsahuje zdrojové kódy. Dalším krokem je již přihlášení do databáze pomocí uživatelského jména a hesla admin/admin
68
Příloha C Obsah přiloženého CD – –
dokumentace – diplomka.doc - diplomka.pdf instalace – pspad452cz – cms.rar – cms_mysql.sql – easyphp1-8_setup.exe – php_manual_cs.chm – wrar351cz.exe
69
Příloha D Dokumentace Protože role v tomto systému jsou postavené tak, že se dědí všechny pravomoci směrem nahoru od čtenáře k Aplikačnímu administrátoru, budu postupně uvádět u každé role, co má navíc. U prvních tří to bude poněkud kratší seznam možností a teprve až aplikační administrátor oplývá mnohem širšími pravomocemi oproti ostatním. Prvním krokem je přihlášení do systému, kdy je požadováno jméno a heslo. Na základě jich se ověří uživatel a buď se mu přiřadí nějaká role anebo je mu oznámeno, že přihlašovací údaje jsou neplatné. Následující tři role dostanou svoji část menu a skrz něj mohou dělat akce, povím tedy pouze jaké. Čtenář V případě této role je vše jednoduché, uživatel se přihlásí do systému a má možnost prohlížet pouze takové tabulky, pro které jsou mu předělena práva. To povětšinou budou ty datové. Tato role je určena pro všechny návštěvníky a občasné hosty v systému a nejsou s ní spojeny žádné pravomoci měnit anebo upravit záznamy. Editor Při této roli je dovoleno oproti předcházející měnit údaje v tabulkách. Záleží pak do jakých tabulek dá aplikační administrátor přístup. Administrátor Pokud má uživatel tuto roli, je mu dovoleno mazat údaje v datový a kódových tabulkách, případně podle nastavení může spravovat uživatele. Aplikační administrátor V každé aplikaci je třeba mít někoho kdo má buď možnost dělat cokoliv anebo mít možnost spravovat a starat se o aplikaci, zde k tomu je právě tato role. Samozřejmě může přistupovat a měnit údaje v datových a kódových tabulkách, avšak navíc i v metadatech, jež jsou určeny k běhu aplikace. Protože popsaní funkčnosti jednotlivých políček v tabulkách metadat, by bylo jen kopírováním textu, odkazuji se na kapitolu 4.5, kde jsou všechny popsány. A zde popíši, co se v které položce menu nastavuje. V definici menu, muže nastavit vzhled, funkčnost a co se má dít, při kliknutí na položku. Poté v definicích pro jednotlivé tabulky, jaké sloupce se budou zobrazovat, které master-detaily pro roletkový výběr se nabídnou, políčka jež
70
uživatel musí vyplnit, kusy javascriptových kódu pro speciální funkce, zda se údaje z tabulek zobrazí do jednoho anebo dvou sloupců a nakonec práva přístupů k tabulkám. V definicích HTML jsou kusy webových stránek, které jejsem možno přidat nebo je upravit či smazat. Protože občas je třeba, aby se položka v stránce jevila jako zaškrtávací tlačítko má aplikační administrátor možnost ho přidat. Udělá tak skrz položku menu nazvanou setting. Další důležitou neméně důležitou položkou menu jsou uživatelé, kde se dají spravovat a přidělují se jim zde role. Nakonec jsou tu dvě poslední položky v menu, které jsou určeny pro definování speciálních struktur. Opět se zde vkládají kusy HTML kódu avšak s proměnnými, které jsou pak nahrazeny daty při zpracování. Pro správné ovládání aplikace je třeba znalosti z kapitole 4.5, jinak by mohlo dojít k problémům s během aplikace. Není totiž možné jednoduše popsat nastavování v této části dokumentace.
71
Příloha E Ukázky vybraných obrazovek systému
obr. 10 - Úvodní obrazovka systému s menu
obr. 11 - Zobrazení záznamů po výběru položky menu
72
obr. 12 - Detail záznamu v dvou sloupcovém layoutu
73
