Masarykova univerzita Fakulta informatiky
Webový archív vědeckých konferencí bakalářská práce
Martin Mayer
Brno, 2007
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Martin Mayer
Poděkování Rád bych poděkoval vedoucímu mé práce RNDr. Jaroslavu Ráčkovi, Ph.D., za odborné vedení a rady při tvorbě této práce.
Shrnutí Obsahem této práce je analýza existujícího nevyhovujícího webového archivu sborníků konference a návrh nového systému. Na základě návrhu je vytvořen systém s využitím jazyka PHP a databáze MySQL. Dále je provedena konverze původních dat do nového archivu.
Klíčová slova Analýza systému, archivace dokumetů, datové modelování, webové aplikace, vědecká konference
Obsah 1 Úvod....................................................................................................................................2 2 Analýza a návrh systému.....................................................................................................3 2.1 Analýza původního webu............................................................................................3 2.2 Požadavky na systém...................................................................................................3 2.3 Kapacitní a zátěžové odhady.......................................................................................4 2.4 Popis systému..............................................................................................................4 2.4.1 Administrační část................................................................................................4 2.4.2 Veřejná část..........................................................................................................5 2.5 Datový model..............................................................................................................5 2.6 Struktura částí webu....................................................................................................7 3 Implementace......................................................................................................................9 3.1 Použité technologie......................................................................................................9 3.1.1 WWW..................................................................................................................9 3.1.2 HTML a XHTML................................................................................................9 3.1.3 CSS......................................................................................................................9 3.1.4 JavaScript.............................................................................................................9 3.1.5 PHP....................................................................................................................10 3.1.6 MySQL..............................................................................................................10 3.2 Nefunkční požadavky................................................................................................10 3.3 Způsob kódování.......................................................................................................10 3.4 Struktura systému......................................................................................................11 3.5 Sdílený kód a jeho použití.........................................................................................12 3.5.1 Databáze.............................................................................................................12 3.5.2 Manipulace s daty..............................................................................................13 3.5.3 Ostatní................................................................................................................14 3.6 Administrace..............................................................................................................14 3.6.1 Autentizace.........................................................................................................14 3.6.2 Provádění změn..................................................................................................15 3.7 Veřejná část................................................................................................................15 3.7.1 Cache..................................................................................................................15 3.7.2 Vyhledávání........................................................................................................16 3.8 Použité vývojové nástroje..........................................................................................17 4 Import původních dat........................................................................................................18 4.1 Extrakce údajů z původních HTML stránek..............................................................18 4.2 Konverze skupin obrázků do PDF.............................................................................18 5 Závěr..................................................................................................................................20 Literatura..............................................................................................................................21
1
1 Úvod Mnoho lidí, zvláště mladých, se domnívá, že počítače se k nám dostaly až po roce 1989. Archiv konference Tvorba software (TSW) je ale pěkným dokladem toho, jak vypadala ještě dřívější historie používání počítačů. Konference se pořádá kontinuálně každý rok už více než 30 let a je společně s konferencí SOFSEM (Softwarový seminář) nejdéle organizovanou konferencí v českém regionu. Snaží se prezentovat aktuální trendy a moderní metody v programování. První ročník se konal v roce 1975 v Havířově jako seminář „Metody programování počítačů 3. generace“ s počtem učastníků blížícímu se stovce. Po třech letech došlo ke změně na „Celostátní seminář programování“ a za dalších pár let se místo konání přestěhovalo do Ostravy. V 90. létech pak došlo k transformaci akce na konferenci s názvem „Tvorba software“. Přes půl tisíce autorů z více než dvouset organizací předneslo během tří desetiletí na 800 referátů a zaplnilo ve sbornících kolem 7500 stránek. Archiv sborníků proběhlých konferencí TSW je přístupný veřejnosti na webu. Tento archiv je tvořen statickými HTML stránkami, které však nejsou jenoduše a rychle aktualizovatelné. Cílem této bakalářské práce je vytvořit nový sytém fungující jako archiv sborníků a jejich příspěvků. Tento systém uživateli poskytne přehled všech příspěvků konference podle ročníků a jednodůché hledání příspěvků podle jejich názvu nebo jména autora. Administrátorovi umožní přidat nový sborník, vytvářet, editovat a mazát jeho příspěvky a stejně tak i autory příspěvku. K systému se bude přistupovat přes webové rozhraní. Data ze starého archivu bude potřeba extrahovat a přenést do nového. Jednotlivé kapitoly této práce se zabývají tvorbou tohoto systému. Začíná se od analýzy původního webu ke specifikaci a návrhu nového systému. Pokračuje se popisem použitých technologií a dokumentací implementace. V poslední částí práce je popsána transformace dat ze starého webu.
2
2 Analýza a návrh systému Tvorbu nového systému je dobré vždy začít důkladnou analýzou. V tomto případě bude prvním subjektem analýzy původní web, určení jeho obsahu a případných chyb. To usnadní specifikaci požadavků na nový systém. Následně pak mohu rozhodnout, jaké entity se v systému budou vyskytovat, a stanovit strukturu databáze a celého systému.
2.1
Analýza původního webu
Úvodní stránka původního archívu se nalézá na adrese http://honor.fi.muni.cz/tsw/. Celý web sestává z těchto oblastí, které jsou mezi sebou vzájemně provázány: ● obsahy a texty sborníků podle ročníků ● jmenný rejstřík autorů ●
jmenný rejstřík firem
●
tématické rejstříky tříděné systematicky nebo podle abecedy
Celkově jsou zpracovány sborníky z let 1975 až 2004. V záhlaví každé stránky ročníku je uveden název konference, místo konání a datum. Následuje seznam příspěvků. U příspěvku je vždy uvedeno číslo odpovídající číslu stránky v tištěném sborníků. Zároveň odkazuje na obsah příspěvku. U ročníků 1975 až 1998 tvoří obsah jedna a více naskenovaných stran. U následujících ročníků je obsah stáhnutelný jako jediný soubor formátu PDF. Dále je uveden identifikátor autora odkazující do rejstříku autorů, identifikátor organizace odkazující do rejstříku firem, název příspěvku a klíčová slova odkazující do tématického rejstříku. Jmenný rejstřík autorů je řazen abecedně a rozdělen na dvanáct stránek po čtyřiceti autorech. Autory doplňují odkazy na ročníky, kdy publikovali své příspěvky. U několika autorů je uveden i web nebo email. Rejstřík firem je řešen obdobně jako rejstřík autorů. Systematický rejstřík sdružuje témata do několika skupin. Zde uvedené téma odkazuje do rejstříku abecedního, kde se téma spojuje s některým příspěvkem a je k němu doplněno ještě krátka poznámka. Celkově se jeví web a především rejstřík jako poněkud nepřehledný. Nedostatkem je také absence alespoň základního vyhledávání příspěvků.
2.2
Požadavky na systém
Systém má zpřístupnit archiv sborníků konference přes webové rozhraní. Se systémem bude pracovat jediný administrátor provádějící veškeré editace. Dalšími uživateli budou návštěvníci webu, kteří mohou zobrazovat obsah archivu a vyhledávat v něm. Pro každý rok lze přidat a editovat jeden sborník. Sborník se skládá z příspěvků. Každý příspěvek má alespoň jednoho autora. K autorovi se vždy uvádí organizace, kterou zastupuje, případně další kontaktní údaje. Obsah příspěvku může být přiložen jako soubor ve formátu PDF. Při změně stavu archivu se uchovává stručná poznámka o provedené akci (vytvoření, editace nebo smazání entity) do logu událostí, aby bylo možné zjistit případné narušení systému. Celý sborník se vždy nachází ve zvěřejněném nebo nezveřejněném stavu. Nezveřejněný sborník je přístupný pouze administrátorovi pro účely editace. 3
Zveřejněný sborník a jeho příspěvky jsou přístupné komukoli. Uživatelé mohou hledat příspěvky podle jejich názvu, jména autora, jména organizace autora a ročníku publikace. Data z původního statického webu bude potřeba převést do nového systému. Zdrojová data, ze kterých byl web vygenerovaná, ale bohužel nejsou k dispozici, proto bude nutné data extrahovat přímo z webu. Pro sjednocení zdroje se naskenované stránky každého příspěvku u starších ročníků sloučí do jednoho PDF souboru. Podle těchto požadavků lze sestavit základní logický datový model:
Obrázek 1: Logický datový model - diagram entit Přínosem nového systému bude především lehká a rychlá aktualizace prostřednictvím webového rozhraní. V budoucnu bude systém dále snadno rozšiřitelný.
2.3
Kapacitní a zátěžové odhady
Podle udajů z původního webu lze vysledovat a obecně předpokládat tyto trendy: ●
Větší editace se budou prováděny jen jednou za rok v průběhu krátkého období.
●
Každoročně přibyde přibližně tři až pět desítek příspěvků.
Většina příspěvků má uvedeného jediného autora. Jeden příspěvek má v průměru přibližně 1,3 autorů.
●
Velikost jednoho PDF souboru bývá do 300KiB. Každý rok přibyde cca 10MiB dat.
●
2.4
●
Již existující data sborníků od roku 1975 zabírají přibližně 200MiB.
●
Denní návštěvnost webu se bude pohybovat spíše v řádu desítek lidí.
Popis systému
Systém bude rozdělen do dvou částí. Administrátorská část je neveřejná, vyžaduje autentizaci pro přístup a umožňuje modifikovat údaje v archivu. Veřejná část je přístupná jakémukoli uživateli a prezentuje obsah archivu podle ročníků nebo pomocí hledání.
2.4.1
Administrační část
Administrace je jednouživatelský podsystém, tzn. že se vyžaduje jediný uživatelský účet pro celou část. Přístup k adminstraci systému je podmíněn zadáním loginu admin a hesla. Pro zvýšení bezpečnosti budou existovat dvě hesla – běžné a bezpečnostní. Přihlašování bude vždy probíhat běžným heslem a v takovém případě nebude možné změnit bezpečnostní heslo. V případě, kdy by snad někdo nežádoucí odhalil běžné heslo a změnil jej, bude pořád možné přihlásit se s pomocí bezpečnostního hesla, změnit běžné heslo a znemožnit tak další přístup útočníka. Admnistrátor může také prohlížet jednoduchý log 4
událostí, ve kterém je pro každou událost měnící stav archivu zaznaménána ip adresa, ze které přišel ke změně podnět, čas, typ změny (vytvoření, modifikace, smazání) a krátky popis. Účel tohoto logu je odhalit diskreditaci hesla nebo nežádoucí chování administrátora, pokud by účet mezi sebou sdílelo více lidí. Administrace systému celkově umožňuje provedení následujících akcí: ●
založení nového sborníku
●
editace sborníku
●
vytvoření příspěvku patřícího ke sborníku
●
editace příspěvku
●
smazání příspěvku
●
přídání nového autora k příspěvku
●
editace autora příspěvku
●
smazání autora u příspěvku
●
smazání PDF souboru přiloženého k příspěvku
●
změna hesla
2.4.2
Veřejná část
Veřejná část zpřístupní zveřejněné sborníky přes webové rozhraní libovolnému návštěvníkovi. Sborníky jsou řazené podle jejich ročníků, příspěvky podle pořadí v tištěném sborníku. Od roku 1998 toto pořadí odpovídá abecednímu řazení podle jmen autora. Důležitá funkce je základní vyhledávání příspěvků. Portálová část zajišťuje provádění těchto akcí: ●
zobrazení sborníku a jeho detailů včetně seznamu příspěvků
●
zobrazení detailu příspěvku a jeho autorů
●
stažení přiloženého PDF souboru
vyhledání příspěvku podle jména příspěvku, jména autora, jména organizace a ročníku
●
2.5
Datový model
Datový model definuje strukturu dat uložených v databázi.
5
Obrázek 2: Datový model Popis databázových tabulek a jejich atributů: ●
Tabulka Sbornik
Záznamy této tabulky představují jednotlivé ročníky konference. Den a měsíc u dat začátku i konce konání jsou rozděleny na samostatné atributů pro větší variabilitu zadávání. Pokud by byly v atributu typu DATE, nešlo by zadata například jen měsíc, ve kterém se konference konala. ●
rok – identifikace záznamu, rok pořádání konference
●
zverejneny – příznaka, zda je sborník zveřejněný
●
nazev – název konference v daném roce
isbn – mezinárodní standardní číslování knih, jednoznačná identifikace knižního vydání
●
●
●
naklad – počet výtisků sborníku
●
misto_konani – kde se konference konala
●
datum_od_den – den měsíce od kdy se konference konala
●
datum_od_mesic – měsíc od kdy se konference konala
●
datum_do_den – den měíce do kdy se konference konala
●
datum_do_mesic – měsíc do kdy se konference konala
Tabulka Prispevek Každý záznam této tabulky se váže přímo na jeden záznam v tabulce sborníků. ●
id – identifikace záznamu
6
●
●
rok – identifikace sborníku
●
nazev – název příspěvku
●
nazev_ascii – název příspěvku zbavený diakritiky, použitelné pro hledání
●
strana – číslo stránky, na které příspěvek začíná v tištěném sborníku
Tabulka Autor Tabulka uchovává informace o jednotlivých autorech každého příspěvku. ●
id – identifikace záznamu
●
prispevek_id – identifikace příspěvku v tabulce Prispevek
●
jmeno
●
prostredni_jmeno
●
prijmeni
jmeno_slozene – spojení jmen a příjmení autora, použitelné pro hledání autora
●
jmeno_slozene_ascii – stejně jako předchozí atribut, ale zbavený diakritiky
●
●
email – emailový kontakt na autora
●
web – webová prezentace autora
●
organizace_nazev – název organizace, kterou autor zastupuje
organizace_nazev_ascii – stejně jako předchozí atribut, ale zbavený diakritiky
●
● ●
organizace_web – adresa webu organizace
Tabulka Log udalosti
V této tabulce se uchovávají záznamy o provedených změnách dat prostřednictvím administračního rozhraní. ●
id – identifikace záznamu
●
ip – ip adresa, ze které byla provedena změna
●
cas – čas provedení změny
udalost – typ události, která nastala – vytvoření, změna, nebo odstranění záznamu (insert, update, delete)
●
●
popis – stručný textový popis události
Tabulky Sbornik, Prispevek a Log udalosti splňují náležitosti třetí normální formy (3NF). Tabulka Autor porušuje 3NF, protože údaje organizace jsou na primárním klíči závislé tranzitivně. Organizace by mohla být samostatnou entitou. Vzhledem ale k tomu, že v existujících datech se často jedna organizace vyskytuje opakovaně pod různými názvy, nebo by bylo značně problematické jednotně určovat organizaci, pokud je nějak složitěji členěna, nebylo by možné zamezit rendundanci v datech entity. Po diskusi se zadavatelem bylo proto rozhodnuto dat přednost méně problematickému řešení porušením formy.
7
2.6
Struktura částí webu
Následující diagramy popisují hierarchii webu. Každý obdélník bude ve výsledném řešení odpovídat samostatné obrazovce.
Obrázek 3: Struktura administrační části
Obrázek 4: Struktura veřejné části
8
3 Implementace Tato část mé práce popisuje implementaci systému. Zabývá se stručným vysvětlením elementárních technologií a standardů, které byly použity k tvorbě celého systému. Dále popisuji vyprodukovaný zdrojový kód a specifika částí systému. Text doplňují odkazy na internetové zdroje a fragmenty kódu systému. Výsledný zdrojový kód doplněný o patřičné komentáře se nachází na médiu přiloženém k této práci. V době tvorby práce byl systém také otestován a zprovozněn na adrese http://projects.cba.muni.cz/tsw/.
3.1
Použité technologie
Před tvorbou nového webového archivu jsem se musel seznámit s několika standardy a technologiemi, které umožňují vzájemným provázáním vytvořit požadované řešení. Tato podkapitola popisuje pouze jejich určení. K samotné tvorbě je potřeba jejich více či méně detailní znalosti. Všechny pužívané technologie jsou veřejné standardy nebo software s oteveřeným zdrojovým kódem.
3.1.1
WWW
WWW (World Wide Web, krátce web) označuje celosvětovou soustavu dokumentů. Definovat lze jako propojení těchto technologií: URI (Universal Resource Identifier) – způsob jak jednoznačně identifikovat zdroj
●
HTTP (Hypertext transfer protocol) – protokol aplikační úrovně pro přenos informací. K tomuto protokolu existuje také bezpečnější verze HTTPS, která umožňuje přenášet data šifrovaně
●
3.1.2
●
Architektura klient-server
●
Značkovací jazyk
HTML a XHTML
HTML (Hypertext Markup Language) je značkovací jazyk založený na standardu SGML , což je univerzální značkovací metajazyk. XHTML je obdobný jazyk založený na XML, které také vychází ze SGML. Jazyky spojují obsah (data) s významem (metadata). Obsah bývá uzavřen mezi značky, které určují jejich význam, respektive způsob zobrazení.
3.1.3
CSS
CSS (Cascading Style Sheets) je jazyk pro popis způsobu zobrazení dokumentu napsaného pomocí značkovacího jazyka, nejčastěji HTML, XHTML nebo XML. Hlavní účel je oddělení vzhledu dokumentu od jeho struktury a obsahu.
3.1.4
JavaScript
JavaScript je skriptovací jazyk používaný na straně uživatele, tzn je interpretovaný 9
webovým prohlížečem. S jazykem Java jej kromě názvu spojuje jen podobná syntaxe. Umožňuje vložit do webových stránek proveditelný obsah a tak komunikovat s uživatelem, řídit prohlížeč nebo dynamicky vytvářet obsah.
3.1.5
PHP
PHP je skriptovací jazyk určený především ke generování webových stránek. Na rozdíl od JavaScriptu je interpretovaný na straně serveru. Jeho syntaxe je podobná jazyku C. Vzniklo v roce 1995. Současná produkční verze má číslo 5 a jejím hlavním přínosem je zlepšená podpora objektového programování. Jazyk má otevřený zdrojový kód a volné použití. Obsáhlá knihovna funkcí, široka podpora různých databázových serverů a jednoduché použití vytvořilo z PHP velmi populární a rozšířerný jazyk. Informace lze nalézt na domovské stránce http://www.php.net/.
3.1.6
MySQL
MySQL je multiplatformní relační databázový systém standardu SQL. Velmi často se pužívá ve spojení s PHP. K dispozici je pod GPL licencí. Vyniká rychlostí a snadným použitím. Další informace lze nalézt na http://www.mysql.com/.
3.2
Nefunkční požadavky
Je potřeba zajistit, aby systém běžel v produkčním prostředí na operačním systému Linux, webovém serveru Apache 2.0, PHP 4.3.4 a MySQL 4.0.18. V průběhu následujícího cca jednoho roku se očekává, že přibyde nový server s nainstalovanými novějšími verzemi těchto programů, především PHP ve verzi 5. Proto je vhodné do budoucna maximálně usnadnit přechod systému na novější prostředí.
3.3
Způsob kódování
Před samotnou tvorbou ještě vysvětlím několik věcí, které se týkají kódu a programování, a kterých se budu snažit co nejvíce držet. Jednou z nich je jazyk používaný k pojmenovávání proměnných a funkcí. Vzhledem k tomu, ze TSW je především česká konference, jeví se jako vhodné, aby jména tabulek a atributů v databázi byly vždy česky. Stejně tak i v kódu jména proměnných, které jim budou odpovídat. Naopak názvy funkcí a zbylých proměnných by měly být vždy v angličtině podobně, jako jsou názvy funkcí v PHP. Doufám, že takové rozdělení přispěje k lepší čitelnosti a přehlednosti kódu. Podstatným omezením je potřeba, aby vytvořené řešení bylo plně funkční na PHP 4, a současně aby bylo možné v budoucnu s minimem námahy přenést na novější verzi PHP (pravděpodobně verze 5). Z toho důvodu jsem se rozhodl nepoužívat žádné frameworky, kterých existuje několik a i vcelku kvalitních, ale jsou buď psané pro PHP 5 (například v současnosti vznikající Zend framework), nebo by mohly způsobovat kompatibilní problémy při budoucím přechodu. Ze stejného důvodu jsem se také rozhodl neprogramovat systém objektově. PHP 4 obsahuje alespoň slabou podporu pro objektové programování. V PHP 5 byl objektový model docela výrazně změněn. To s sebou však nese často potřebu upravovat již existující kód, aby se v nové verzi dosáhlo správné a požadované funkčnosti. I když se často nejedná a žádné složité úpravy, přesto je to častý problém zabraňující přechodu na novější a bezpečnější verzi PHP. Místo tříd a jejich metod tedy budu používat 10
jen vhodně organizované funkce a místo objektů převážně asociativní pole. Projekt není natolik rozsáhlý, aby nutně vyžadoval objektové naprogramování. Obětuji proto výhody objektového přístupu, především dědičnost a zapouzdření, snazšímu přechodu v budoucnu. Nahradím je svojí snahou co nejlépe strukturovat kód a zachovávat tak jeho dobrou čitelnost. Zároveň se budu snažit, aby bylo řešení do budoucna v určitých mezích snadno rozšiřitelné. Zvláště v dřívějších letech bývalo nedobrým zvykem webových vývojářu míchat vzájemně mezi sebou aplikační a prezentační logiku. Pro lepší strukturování budou ve vyvíjeném systému oddělené. Aplikační kód bude obsahovat pouze řídící logiku. Prezentační logika bude uložena v samostatných souborech – šablonách (angl. templates). Aplikační kód provádí manipulaci s daty a zajišťuje obsah, který má být zobrazen. Obsahem může být například název a autoři příspěvku. Tento obsah je pak předáván šabloně k zobrazení. Takovéto oddělení má výhody v tom, že při úpravě šablony nemůže dojít k narušení řídícího kódu. Ještě důležitější je u větších projektů, kde umožňuje nezávislou práci vývojářů a designerů. Samotná šablona bude tvořena XHTML kódem, do kterého bude vkládán kód PHP zobrazující dynamický obsah.
3.4
Struktura systému
Celý sýstém je rozdělen na dvě na sobě nezávislé části – administrace a portál. Portálová část zajišťuje především prezentaci obsahu z databáze. Administrační část je složitější. Kromě podobné prezentační funkce jako v portálové části musí umožňovat editaci obsahu. Klade se u ní také větší důraz na zabezpečení. Obě části mezi sebou sdílejí stejnou databázi a podobný kód. Nyní navrhnu rozložení celého systému do adresářů a pak dopním jejich význam: /inc – sdílené knihovní kódy config.php – konfigurační údaje /admin – administrační část index.php code/ - aplikační logika a kód specifický pro administrační část templates/ - prezentační logika /portal – veřejná část index.php getfile.php – download zveřejněného PDF souboru code/ - aplikační logika templates/ - prezentační logika /pdf – obsahy sborníků v PDF souborech Většina interakce s uživatelem probíhá v obou částech systému přes jediný soubor index.php. Na jednom místě se tak nachází kód společný pro všechny stránky. Aplikační kód se nachází v adresáři code, šablony v templates. V souboru index.php se provádí následující úkony: ●
Inkluze potřebných sdílených souborů 11
●
Výběr aplikačního kódu, který má být proveden a jeho vykonání
●
Zobrazení obsahu za pomoci šablony
Nabízí se lehké přirovnání k architektuře MVC (model – view-controller). V tomto případě by soubor index.php odpovídal controlleru, inkludovaný kód z code modelu a šablona view. Předpokládejme, že by byla aplikace provozována na doméně tsw.cz. Uvedu příklad, jak by fungovalo výše uvedené strukturování v praxi. Doména www.tsw.cz by směřovala do adresáře portal, doména admin.tsw.cz do adresáře admin. Tam se nachází indexové soubory, které převezmou požadavek uživatele a vytvoří odpověd v podobě webové stránky. Adresář pdf není přístupný přímo přes web, aby bylo možné kontrolovat přístup k souborům s obsahy příspěvků. Ty jsou totiž dostupné jen tehdy, když je sborník označen jako zveřejněný. Přístup k nim tedy bude prováděn přes skript getfile.php, který bude kontrolovat stav sborníku a přepošle uživateli přímo PDF soubor z adresářového stromu nebo mu zamezí v přístupu k němu. Zároveň je potřeba, aby byl z prostředí PHP možný zápis do tohoto adresáře, jinak by nešlo uploadovat soubor prostřednictvím administračního rozhraní. Obsah adresářů code a templates je v takovémto stromu přístupný veřejně. Uživatel by tak mohl zobrazit prázdnou šablonu nebo spustit PHP skript, což není chtěné. Přístupu k těmto adresářům by tedy mělo být zamezeno. Lze tak provést pomocí oprávnění, zakázem v .htaccess souboru, který zpracovává webserver Apache, nebo úplným přesunem těchto adresářů mimo dokumentový adresář webserveru. Takto navržená stromová struktura je samozřejmě jen jedna z možných. Vytvořený systém bude dostatečně variabilní, aby bylo možné ji bez složitých úprav ve zdrojových kódech nastavit podle potřeby.
3.5
Sdílený kód a jeho použití
Sdíleným kódem je myšleno základní API umístěné do adresáře inc a používané v obou částech systému. Jeho prostřednictvím se především přistupuje k databázi a provádí výběr a manipulaci s daty.
3.5.1
Databáze
Ve výchozím stavu je na výběr ze dvou souboru – db.mysql.php a db.mysqli.php. Oba obsahují identické API, ale liší se v implementaci. V PHP totiž existují dvě nativní knihovny pro přístup k MySQL databázi, ale často se v prostředí běhu systému vyskytuje jen jedna z nich. Nejčastěji nastává případ, kdy v PHP4 je přístupná extension mysql a v PHP5 naopak extionsion mysqli. Podle toho, která je dostupná, je potřeba vybraný soubor přejmenovat na db.php. Obsažené API tvoří funkce dostačující pro absolutní většinu práce s databázi a zjednodušuje přístup k ní. Navíc vytváří nezávislost na použité extension. Dokumentace funkcí se nachází přímo v souboru, zde uvádím nejdůležitější: ●
db_select($sql)
provede dotaz do databáze obsažený v řetězci $sql a vrátí 12
výsledek v dvourozměrném asociativním poli. provede dotaz, který vrací ve výsledku právě jeden nebo žádný řádek, a vrátí výsledek. Často jsou to výběry konkrétního záznamu podle primárního klíče nebo selecty s použitím agregačních funkcí.
●
db_select_one($sql)
●
db_escape_value($val)
vrátí zadanou hodnotu ošetřenou pro použití v SQL
dotazu. provede zadaný insert, update nebo delete.
●
db_execute($sql)
●
db_get_insert_id()
vrátí nové id posledního vloženého záznamu
Databázové spojení se navazuje automaticky při prvním použití některé databázové funkce. Využívá se při tom konfiguračních hodnot ze souboru /inc/config.php. Příklad použití:
3.5.2
Manipulace s daty
Vytvářený systém není příliš složitý – obsahuje tři hlavní entity: sborník, příspěvek, autor. Ke každé této entitě jsem vytvořil potřebné rozhraní umožňující provádět základní akce: ●
vytvoření nového záznamu
●
výběr podle primárního klíče
výběr přidružených záznamů (například příspěvky pro daný sborník, autory pro daný příspěvek)
●
●
modifikace existujícího záznamu
●
smazání záznamu
Při použití objektově orientovaného programování (OOP) by pravděpodobně byla vytvořena například třída Prispevek, která by mohla mít metodu insert zapouzdřující vložení instance příspěvku do databáze. O několik kapitol dříve jsem vysvětloval, proč jsem v projektu od OOP upustil. Místo volání metody insert na instanci třídy Prispevek tak používám funkci prispevek_insert, která dostává jako parametr asociativní pole představující instanci příspěvku. Tyto funkce jsou pro každou entitu velmi podobné, jsou dokumentované ve zdrojovém kódu a příklady jejich použití lze snadno nalézt v aplikačním kódu, proto je zde nebudu podrobně rozebírat. Uvedu pouze stručný vysvětlující příklad pro základní pochopení jejich aplikace:
13
$prispevek['nazev'] = „Ukázkový příklad“; prispevek_insert($prispevek); $new_id = $prispevek['id'];
/* Modifikace */ $prispevek = prispevek_get_by_id(1); $prispevek['nazev'] = „Změněný název“; prispevek_update($prispevek);
$autori = prispevek_get_autori($prispevek['id']); foreach ($autori as $autor) { echo $autor['prijmeni']; } /* Delece */ prispevek_delete($prispevek); ?>
Funkce jsou logicky rozděleny do souborů sbornik.php, prispevek.php a autor.php.
3.5.3
Ostatní
Pro potřeby systému jsem vytvořil několik dalších obecně použitelných funkcí. Nachází se v souboru inc/general.php. Jejich význam, parametry a návratové hodnoty jsou více dokumentovány přímo v kódu.
3.6
Administrace
Přístup do administrace je podmíněn autentizací uživatele. Navíc se pro zvýšení bezpečnosti vyžaduje přístup přes zabezpečené připojení (HTTPS). Toto testuji na začátku indexového souboru a v případě, že uživatel používá nezabezpečené připojení, dojde k jeho přesměrování na URI se změněným schématem: if ($_SERVER['HTTPS']!='on') { redirect('https://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']); }
3.6.1
Autentizace
Pro ověření uživatele se používá autentizace pomocí HTTP protokolu. Snadno se tak zamezí v přístupu k citlivým částem systému. Požadavek odeslaný prohlížečem musí obsahovat hlavičku se jménem uživatele a heslem. Pokud ji neobsahuje, nebo když nesouhlasí jméno či heslo, vrací se v HTTP odpovědi stavový kód 401 Unathorized a prohlížeč v takovém případě vetšinou zobrazí dialogové okno pro zadání jména a hesla. Více informací lze nalézt ve specifikaci HTTP protokolu. V tomto případě je jméno uživatele vždy admin. Může se ale prokázat jedním ze dvou hesel, jak je vysvětleno v požadavcích na systém v kapitole 2. Hesla musí být uložena 14
někde v systému. Pro toto místo jsem zvolil soubor /admin/code/passwords.php. Ten obsahuje dvě jednoduché funkce get_admin_password a get_master_password, které každá vrací odpovídající heslo hashovane funkcí md5. Implementace autentizačního mechanismu pak znamená ověření, zda bylo zadáno jméno, toto jméno je admin a zda zadané heslo odpovídá jednomu ze dvou možných: if (!isset($_SERVER['PHP_AUTH_USER']) || $_SERVER['PHP_AUTH_USER']!='admin' || (md5($_SERVER['PHP_AUTH_PW'])!=get_admin_password() && md5($_SERVER['PHP_AUTH_PW'])!=get_master_password())) { response_status_401(); exit(); }
Další informace o HTTP autentizaci v PHP lze nalézt přímo v manuálu na adrese http://www.php.net/manual/en/features.http-auth.php.
3.6.2
Provádění změn
Údaje sborníků, příspěků a autorů jsou uživateli zobrazována prostřednictvím formulářových prvků, ve kterých může uživatel zároveň provádět editaci. Při ukládání ověřuji, zda zadal uživatel nezbytné údaje a u některých položek také zda jsou zadané ve správném formátu (např. čísla). V případě špatného zadání k žádné změně nedojde a uživateli se zobrazí zadaná data s vysvětlující hláškou. Při uploadu PDF souboru se také kontroluje jeho hlavička na přítomnost sekvence znaků %PDF-1.. K provedení změny je také potřeba, aby byly data v odeslaném požadvku předána metodou POST. Ta je podle specifikace protokolu HTTP k takovému účelu určena.
3.7
Veřejná část
Veřejná část webu je oproti administraci značně jednoduší, protože nevyžaduje až tolik složité kontroly přijatých dat. Poskytuje navíc jednoduché i pokročilé vyhledavání příspěvků. Pro optimalizaci zátěže na server je implementována cache.
3.7.1
Cache
Změny dat v databázi archivu nejsou časté. Větší změny se dělají jednou ročně v souvislosti s každoročním pořádáním konference. U starších ročníků jsou změny hodně výjimečné. Na rozdíl od nepoměrně běžnějšího zobrazovanání těchto dat. Zátěž na server způsobovaná opakovanou prezentací identických dat není sice velká, ale při dané častosti modifikace dat je zcela zbytečná. Z toho důvodu se jeví velmi smysluplné, aby byl u stránek zobrazujících detail sborníku a detail příspěvku použit nějaký kešovací mechanismus. Tzn. že vygenerovaný obsah stránky se při prvním zobrazení uloží někde bokem a je opakovaně používán při dalších přístupech na identickou stránku, dokud nedojde ke změně stavu v systému. Odpadá tak nutná režie způsobená selekcí dat z databáze a generováním výstupu při každém přístupu. Takovouto jednoduchou, ale velmi účinnou cache jsem implementoval do systému. Cache se chová zcela transparentně a řádově zkracuje čas odezvy na požadavek1. Rozdíl je celkem významný, i když uživatel podstatné zrychlení ve většině případů zřejmě nepozná, 1 Při měření jsem zjistil, ze použití cache znamenalo minimálně dvojnásobné zrychlení. Ale i více než desetinásobné zrychlení nebylo výjimkou.
15
protože doba generování stránky bývá i bez použití cache v řádu setin až desetin sekundy. Princip je takový, že při přístupu na stránku se ověřuje, zda pro požadované údaje existuje již dříve vygenerovaná cache. Pokud ano, ověří se, zda došlo k nějaké změně v databázi. Nejjednoduší způsob, jak toto zjisit, je mít jeden synchronizační soubor, jehož čas poslední změny odpovídá času provedení poslední libovolné změny v databázi, která by mohla ovlivnit zobrazovaná data. To lze samozřejmě zabezpečit jen tak, že všechny změny se provádí prostřednictvím administračního rozhraní, které provede zneplatnění celé cache změnou data poslední změny synchronizačního souboru. Čas takovéto poslední změny musí být starší, než čas vygenerování cache, jinak by mohlo dojít k zobrazení neaktuálních dat. Další krok je postupné ověření, že nedošlo ke změně některého souboru, který se podílel na generování obsahu. Například při změně šablony je potřeba každou stránku generovat znovu, jinak by se zobrazoval obsah generovaný podle zastaralé šablony. Pokud tedy nedošlo k žádným změnám, může být cache povážována za stále platnou a odeslána uživateli. V opačném případě se běžným způsobem vygeneruje požadované stránka, odešle uživateli a zárověn uloží do cache pro budoucí požadavky. Současně se ukládá také informace o tom, které všechny zdrojové soubory byly při běhu skriptu použity. K tomu se skvěle hodí funkce get_included_files(). Celá logika procesu je znázorněna na následujícím diagramu aktivit.
16
Obrázek 5: Použití cache pro zobrazení stránky
3.7.2
Vyhledávání
Systém nabízí základní a pokročilé vyhledávání příspěvků. V základním vyhledávání zadává uživatel text, který se má nacházet podle volby alespoň v jednom z názvu příspěvku, jméně autora nebo názvu organizace. Nebere se přitom v potaz diakritika ani velikost písmen. V pokročilé vyhledávání lze údaje lépe specifikovat, vzít v úvahu dikritiku, nebo omezit hledání podle ročníků. Nalezené příspěvky jsou zobrazeny stránkovaně a v pořadí podle ročníku jejich publikace ve sborníku. Při implementaci vyhledávání jsem zvažoval použití jedné ze dvou alternativ: ●
vyhledávání pomocí výrazu LIKE, který je běžnou součástí jazyka SQL
●
fulltextová podpora v MySQL od verze 3.23.23
Nakonec jsem se rozhodl pro použití prostého výrazu LIKE a hledání přesné shody. Fulltext v MySQL je ovlvňován minimální délku slova, která lze hledat. Tato délka je defaultně nastavena na 4. Tzn. že slova kratší než 4 znaky nebudou brána v potaz. Zejména dvou a třípísmené zkratky, kterých je v IT oboru hodně (např. XML, C++), by byly obtížně 17
hledatelné. Tato minimální délka se dá nastavit pro celý server. Vyžaduje to ale administrátorský zásah a mohlo by to nepříznivě ovlivnit výkon jiných databázi.
3.8
Použité vývojové nástroje
Systém byl vyvíjen v následujícím prostředí: ●
Apache 2.0.59
●
PHP 5.2.1
●
MySQL 5.0.37
Vytvořené řešení bylo zároveň testováno v prostředí shodném s produkčním. Při vývoji systému jsem dále používal tyto softwarové produkty: ●
Opera – internetový prohlížeč
PDT - PHP Development Tools framework for the Eclipse platform, vývojové prostředí pro PHP postavené na editoru Eclipse
●
●
phpMyAdmin – nástroj pro správu MySQL
18
4 Import původních dat Před nasazením systému bylo potřeba převést data z původního webu. Převod se skládal ze dvou částí. V první byly extrahovány data z HTML stránek a vloženy do nové databáze. Druhá část představovala konverzi skupin naskenovaných obrázků do PDF souborů.
4.1
Extrakce údajů z původních HTML stránek
Z původních stránek bylo potřeba extrahovat tyto údaje a vložit do existující struktury databáze: ●
Jména autorů z rejstříku autorů
●
Názvy organizací z rejstříku firem
●
Rok, název, místo a data konání konference, náklad a ISBN sborníku
●
Název příspěvku
●
Autor příspěvku podle rejstříku autorů a obdobně organizace
Moje první snaha, jak data ze souborů získat, bylo pomocí XML parseru. Bohužel jsem zjisitl, že soubory nebyly well-formed a bylo by je nutno je upravit, aby mohly být zpracovány parserem. Přesto byly ale vcelku vhodně strukturované, abych mohl provádět jejich parsování pomocí regulárních výrazů. Pro převod jsem napsal v jazyce PHP skript import.php, který je také uložen na přiloženém CD. Na začátku importu jsem získal z rejstříků jména autorů a názvy organizací. Dál jsem postupně parsoval sborníky spolu s jejich příspěvky. Například takto jsem byl schopen vyparsovat název každého sborníku: preg_match('|<span class="x1">([^<]+)|', $content, $matches); $nazev = $matches[1];
U všech příspěvku bylo potreba spárovat jeho autora se získaným jménem z rejstříku. Obdobně pro organizaci. K ukládání záznamů do databáze jsem používal již existující funkce.
4.2
Konverze skupin obrázků do PDF
V druhé části bylo potřeba sjednotit formáty obsahů starších a mladších ročníků. Pro ročníky 1975 až 1998 byly obsahy tvořeny naskenovanými obrázky. Mladší ročníky měly své obsahy již v požadovaném formátu PDF. Obrázky jsou rozděleny do adresářů podle roků a pojmenování odpovídá číslu stránky v tištěném sborníku. Pro práci s PDF soubory existuje například knihovna PDFlib (http://www.pdflib.org/), která se mi však v mém vývojovém prostředí nedařila zprovoznit. Šáhl jsem proto k řešení s použitím PHP a Zend Frameworku (http://framework.zend.com/). To je v současnosti nově vznikající framework pro tuto platformu a zdá se, že by mohl získat v budoucnu velkou oblibu pro vývoj aplikací v PHP. Jeho součástí je také modul napsaný čistě v PHP pro snadnou manipulaci s PDF dokumenty. Dokáže mimo jiné vytvořit dokument a vložit do něj obrázek ze souboru, coz je přesně požadovaná funkce, kterou jsem hledal. Zdrojové obrázky byly formátu GIF. Pro použití s uvedeným frameworkem je bylo nejdříve potřeba 19
zkonvertovat do PNG. To jsem provedl pomocí freewarového programu XnView (http://www.xnview.com/). Při konverzi nedošlo k žádné viditelné ztrátě kvality. Pro samotnou tvorbu PDF souborů jsem vytvořil skript png2pdf.php, opět umístěný na přiloženém CD. Skript se spouští z konzole a bere jako parametr ročník, pro který se má provést převod obrázků. Pro tento rok se vyberou příspěvky tohoto ročníku naimportované v předchozí části. U příspěvku je také uvedeno, na jaké straně začíná v tištěném sborníku. Ze všech příspěvků v daném roce tak mohu určit číslo první i poslední strany každého příspěvku a podle toho i přidělit obrázky ke svým příspěvkům. Nový PDF soubor se s pomocí frameworku vytvoří takto: $pdf = new Zend_Pdf();
Vložení obrázku se provádí opakovaně pro každý obrázek příspěvku. Obrázek pozicuji na střed a dolu na stránku doplňuji její číslo: $image = Zend_Pdf_Image::imageWithPath($image_file); $pdfPage->drawImage($image, ...); $pdfPage->drawText($page_number, ...);
Nakonec se soubor uloží na disk, jméno odpovídá identifikátoru příspěvku: $pdf->save('pdfs/'.$rok.'/'.$prispevek['id'].'.pdf');
Všechny vygenerované soubory je možné nalézt na přiloženém CD.
20
5 Závěr Tato práce měla za úkol vytvořit webový systém pro správu archivu sborníků konference. Vycházela z nevyhovujícího existujícího archivu, který lze nyní nahradit výsledkem práce. Vytvořený systém nabízí jednoduché neveřejné administrační rozhraní i veřejnou prezentační část. Vytvořená verze systému může být označena za přechodnou pro období několika dalších let. Tvorba byla zaměřena na snadnou přenositelnost v budoucnu. Systém lze dále snadno rozšířit. Výsledné řešení nabízí také dostatek námětů pro další rozvoj a mohlo by se stát dobrým základem pro další studentskou práci, která by využila novější technologie a data ze vzniklé databáze. Vylepšit lze například vyhledávání o možnost fulltextového prohledávání obsahů příspěvků. Věřím, že systém usnadní správu archivu a přinese větší komfort všem uživatelům.
21
Literatura [1] Shifflet, Ch.: HTTP Developers Handbook, Developer's Library, 2003 [2] Flanagan, D.: JavaScript: Kompletní průvodce, Computer Press, Praha, 2002 [3] PHP Manual, http://www.php.net/manual/en/ [4] MySQL 3.23, 4.0, 4.1 Reference Manual, http://dev.mysql.com/doc/refman/4.1/en/index.html [5] Staníček, P.: Kompletní průvodce: CSS – kaskádové styly, Computer Press, Brno, 2003 [6] Adobe Systems: Adobe PDF 101: Quick overview of PDF file format http://www.adobe.com/devnet/livecycle/articles/lc_pdf_overview_format.pdf [7] Čevela, V.: 30 let informací, inspirace a interakce - Tvorba softwaru a Programování Ostrava, 2004, http://honor.fi.muni.cz/tsw/2004/025.pdf [8] Tvrdík, J.: Třicet instancí třídy Programování-Tvorba softwaru, 2004, http://honor.fi.muni.cz/tsw/2004/301.pdf [9] Šimůnek, M: SQL – Kompletní kapesní průvodce, Grada Publishing, Praha, 1999 [10] XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), 2002, http://www.w3.org/TR/xhtml1/ [11] Schloosnagle, G.: Pokročilé programování v PHP 5, Zoner Press, 2004 [12]The Apache Software Foundation: Apache HTTP Server Version 2.0 Documentation, http://httpd.apache.org/docs/2.0/
22
