Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky. Vyšší odborná škola informačních služeb v Praze. Libor Musil

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Libor Musil Webová aplikace pro podporu vypsaných konzultačních hodin na VOŠIS Bakalářská práce 2010

2

3

4 Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Webová aplikace pro podporu vypsaných konzultačních hodin na VOŠIS zpracoval samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 16. prosince 2010 Libor Musil

5 Obsah Abstrakt... 7 Abstract Úvod Rešerše Rešerše řešení konzultací na vysokých školách Rešerše dostupných aplikací pro podporu konzultací Metodika návrhu databáze Proč bychom se vůbec měli metodikou zabývat? Výhody správně navrhnuté struktury Analýza a návrh Analýza poţadavků Datové modelování - konceptuální model Datové modelování - logický model Datové modelování - fyzický model Normalizace Systém řízení báze dat Pouţité webové technologie HTML Historie HTML HTML a XHTML Rozdíly mezi XHTML a HTML Struktura XHTML dokumentu Kaskádové styly (CSS) Historie CSS Vkládání CSS stylů do XHTML PHP Historie PHP Zápis PHP do XHTML Propojení s databází Praktická část Návrh databáze Analýza poţadavků Use-case diagram Vývojový diagram aplikace Fyzický datový model Tvorba aplikace Zabezpečení Registrace Přihlášení... 50

6 6.1.3 Zabezpečení přístupu k sekcím Zabezpečení přístupu k přihláškám studentům Omezení stahování příloh Práce s konzultacemi Tvorba konzultace Mazání konzultace Editace konzultace Práce s přihláškami Přihlášení ke konzultaci Mazání přihlášky Editace přihlášky Systém vyhledávání konzultací Závěr Zdroje... 68

7 Abstrakt Cílem mé bakalářské práce bylo jednak vytvořit aplikaci, která umoţní přihlášení a evidenci studentů na vypsané konzultační hodiny, a jednak do systému zahrnout i moţnost v rámci přihlášky předem odevzdat příslušné materiály ve formě přílohy a zároveň vytvořit cyklus konzultací prostřednictvím jednoho zadání. V teoretické části přibliţuji technologie a postupy, které jsem vyuţil pro vytvoření aplikace. Proběhne seznámení s tvorbou databáze, se skriptovacím jazykem PHP, se značkovacím jazykem XHTML a s kaskádovými styly. V praktické části se pak jiţ snaţím zaměřit na prezentaci základní tvorby a částí aplikace, cílem je zejména vysvětlit neobvyklé pasáţe kódu.

8 Abstract The aim of my bachelor thesis was at first to create an application that lets you log and record the students at listed consulting hours, and also to include the possibility to send the relevant materials in the form of attachments together with the form of application to the system and to create a series of consultations through a single set as well. In the theoretic part I explain technology and procedures that I used for creating application. There will be familiarization with the creation of a database, with PHP scripting language, the markup language XHTML and Cascading Style Sheets. In the practical part I am already trying to focus on the presentation of the basic creation and the parts of the application, the aim is especially to explain the unusual passage code.

9 Úvod 9 1 Úvod Téma Webová aplikace pro podporu vypsaných konzultačních hodin na VOŠIS jsem si vybral proto, ţe uţ ve chvíli, kdy jsem se na této škole s databázovými technologiemi setkal poprvé, velice mě to oslovilo a začal jsem se tedy zajímat, jak takovéto systémy z obecného hlediska vůbec fungují, a zjistil jsem, ţe ve světě internetu se jedná o mimořádně silný nástroj, který se skrývá za téměř kaţdou internetovou stránkou, coţ si moţná mnoho lidí ani neuvědomuje. Já to dnes jiţ vnímám a fascinuje mě ta obrovská vyuţitelnost, moţnost kreativity a vytvoření poloautomatického systému. Ve světle vlastních zkušeností s problematikou jsem zároveň usoudil, ţe konzultace jsou na většině škol řešeny velice nejednotně a v zásadě nesystémově, buď pomocí ové, či jiné domluvy anebo jen nedomluveným příchodem na předem vypsané časy. V podstatě tedy neexistuje zaznamenání jejich historie a je jen na jejich účastnících, co si zaznamenají sami, proto jsem se rozhodl vytvořit takovou webovou aplikaci, která by měla napomáhat interakci mezi konzultujícím a konzultantem, a to zejména v podobě vypisování konzultací na konkrétní datum a přesný čas pedagogem, přihlašování studentů na vypsané konzultace s předem popsaným problémem a s moţností zaslat přílohu, která by konzultantovi dala předem materiály k prostudování, anebo by jej pouze nasměrovala, aby věděl, na co se má při konzultaci zaměřit a co tedy bude jejím předmětem. Myslím si, ţe tím by pak mohlo docházet i k individualizované přípravě konkrétního pedagoga na konkrétní konzultační téma a konkrétní problémy, které se v jeho rámci budou řešit. Tím se dle mého názoru můţe ještě zvýšit kvalita konzultací, ale zároveň se v konzultacích vytvoří nějaký řád, ušetří se čas a zaznamená historie, kterou bude moţné zpětně dohledat. Cílem mé bakalářské práce je tedy jednak vytvořit aplikaci, která umoţní přihlášení a evidenci studentů na vypsané konzultační hodiny, a jednak do systému zahrnout i moţnost v rámci přihlášky předem odevzdat příslušné materiály ve formě přílohy a zároveň vytvořit

10 Úvod cyklus konzultací prostřednictvím jednoho zadání. Pokusím se navrhnout jak back-end sytému, tak i uţivatelský front-end. 10

11 Rešerše 11 2 Rešerše 2.1 Rešerše řešení konzultací na vysokých školách Abych zjistil, jak jsou na vysokých školách řešeny metody, či systémy pro konzultace, rozhodl jsem se vytvořit rešerši na stránkách mnou vybraných vysokých škol. Záměrně jsem se zaměřil na online řešení, protoţe jedině tak lze takovýto systém provozovat, aby byl plně vyuţitelný pro kaţdého pedagoga, čí studenta. Vybrané záznamy volně dostupné na www škol Klíčová slova: konzultace, rezervační systém, systém konzultací Vysoká škole ekonomická [online] [cit ]. Konzultace a poradenství. Dostupné z WWW: < - Konzultace studia objednatelná přes Fakulta stavební, ČVUT v Praze [online] [cit ]. Konzultace. Dostupné z WWW: < - Časový rozpis konzultací. České vysoké učení technické v Praze, Fakulta strojní Ústav mechaniky, biomechaniky a mechatroniky [online] [cit ]. Rozvrh a konzultace. Dostupné z WWW: < - Rozvrh konzultací katedry mechaniky. BUŘILOVÁ, Marcela. Marcela Buřilová - osobní stránka [online] [cit ]. Rozvrh hodin. Dostupné z WWW: < - Stránka učitele a jeho rozvrh včetně konzultací. Atelier fotografie, VŠUP, Praha [online] [cit ]. Aktuality. Dostupné z WWW: < - Výpis konzultačních hodiny v ateliéru na určité dny.

12 Rešerše 12 VŠUP [online] [cit ]. Konzultační hodiny katedry dějin umění a estetiky v letním semestru. Dostupné z WWW: < - Rozpis konzultačních hodin.

13 Rešerše Na druhou stranu lze předpokládat, ţe systém pro správu konzultací a přihlášek můţe být součástí interního systému školy, který není pro lidi nespjaté se školou dostupný. Nicméně i přesto jsem se pokusil ověřit přímým dotazováním studentů, zdali se na jejich školách podobná aplikace nachází. Škola Interní systém správy konzultací ČVUT v Praze fakulta elektrotechniky Není BIVŠ - program Bankovnictví Není VŠE v Praze Není PEF ČZU v Praze Není VŠMIE Existuje aplikace na vypisování konzultací PF Univerzity Karlovy Není ÚISK FF UK není Z rešerše vysokých škol je patrné, ţe na nich ve většině případů neexistují ţádné dohledatelné systémy, které by podporovaly rezervační systém konzultací, obvykle se jedná jen o vypsané hodiny a dny, kdy se lze zastavit, ovšem domluva a přihlášení se buď vůbec nekoná, anebo je na bázi ové komunikace Rešerše dostupných aplikací pro podporu konzultací Mimo případných interních konzultačních systémů vysokých škol by šlo pouţít i rezervační a redakční systémy, které jsou k dispozici na internetu. Vybrané záznamy volně dostupné na internetu Klíčová slova: rezervační systém EUNECO - webdesign, redakční systémy, profesionální řešení na míru [online]. 2002, 2009 [cit ]. Rezervační systém Netbooking. Dostupné z WWW: < Detaily Zpoplatněné: ano Vhodné: pro hotely, objednávky Správa: přes internetový prohlíţeč Nower systems Rezervační systém pro sportovní centra [online] [cit ]. Online rezervační systém Booker. Dostupné z WWW: < Detaily

14 Rešerše Zpoplatněné: ano Vhodné: pro sportoviště, objednávky Správa: přes internetový prohlíţeč CMS - E-shop - tvorba www stránek - redakční systém - Czechproduct.cz [online] [cit ]. Rezervační systém - rezervace termínu. Dostupné z WWW: < Detaily Zpoplatněné: ano Vhodné: pro rezervace termínů, objednávky Správa: přes internetový prohlíţeč 14 Z této rešerše vyplývá, ţe existuje celá dlouhá řada rezervačních systémů, ovšem jejich vyuţitelnost klesá zaprvé s jejich zpoplatněním a zadruhé s jejich zaměřením na obchodní funkcionalitu. Jelikoţ tedy neexistuje plnohodnotný a vyuţitelný rezervační systém, rozhodl jsem se vytvořit databázovou aplikaci, která by splňovala potřebná kritéria funkcionality a navíc by byla k dispozici zdarma.

15 Metodika návrhu databáze 15 3 Metodika návrhu databáze V této části se zabývám metodikou, jak správně postupovat při návrhu datové struktury databáze, protoţe z mého pohledu se jedná o jeden z nejzásadnějších kroků celého projektu. Obr. 1.:Metodika návrhu databáze [1]

16 Metodika návrhu databáze Proč bychom se vůbec měli metodikou zabývat? Pro někoho, kdo se s databázemi nikdy nesetkal, je samozřejmost si o různých praktikách a postupech tvorby zjistit co moţná nejvíce, ovšem někteří se dostali jen ke kusým informacím, pomocí kterých lze vytvořit relační model a pracovat s ním, avšak vyvstává otázka, jestli je takový model vůbec pouţitelný jinak, neţ jen pro úzké osobní pouţití. Existuje tu samozřejmě několik moţností, jak takový návrh můţe dopadnout; do nich lze ostatně zařadit i situaci, kdy tento bude naprosto v pořádku, nicméně ve většině případů se spíše stane, ţe bez jasné metodiky a vymezených postupů bude vyvinut systém, který pravděpodobně bude na první pohled fungovat, ale na pohled druhý a třetí se zjistí, ţe jeho nedokonalé navrţení zabraňuje aplikaci se rozvíjet, vytvářet nové funkce a plnohodnotně pracovat s daty. Proto je dobré, neţ se začne pracovat na samotné aplikaci, projít podrobně všechny kroky správné metodiky návrhu databáze, aby se předešlo pozdější nutnosti měnit celou dosud vytvořenou aplikaci v jejích základech. Výhody metodiky se dají shrnout do několika bodů: Povede tvůrce aplikace přesně po jednotlivých bodech, které je třeba v rámci tvorby absolvovat, aby se podařilo vytvořit funkční a plně vyuţitelnou strukturu databáze. Pomáhá sníţit na minimum riziko výskytu případných chyb. Sniţuje objem času, který je potřeba vynaloţit na návrh struktury databáze. Důsledkem jejího uţití je následně i lepší proniknutí do samotné problematiky databází a jejich tvorby [2] 3.2 Výhody správně navrhnuté struktury. Výše jsem zmínil, ţe je potřeba dbát na správné kroky a postupy při návrhu databáze. Uvedl jsem jejich obecné výhody a co vám to jako navrhovateli přinese, nyní se zaměřím také na to, co dobrého to přinese pro databázi a jaký vliv na ní tedy bude mít správně navrhnutý model. Databáze by měla splňovat moţnost přidávání jak záznamů v době vytvoření databáze, tak i pozdějších záznamů, které přidá uţivatel. Data jsou minimálně redundantní, a proto s nimi lze kvalitně pracovat a vytvářet z nich statistiky, různé závěry a správně je interpretovat i upravovat.

17 Metodika návrhu databáze 17 [2] Je zaručena integrita dat, která definuje jejich přesnost ve vztahu k okolnímu světu, který se snaţíme interpretovat. Data poskytují platné a přesné informace pro problematiku, kterou se snaţíme modelovat. Databázi je v budoucnu moţno ještě modifikovat nebo rozšířit bez nutnosti upravovat celou strukturu. Data lze snadno upravovat Získání informací z databáze je jednoduché Všechny nastíněné body následně ulehčí i samotné programování uţivatelské aplikace, kdy nebude potřeba vymýšlet nové postupy získávání dat z databáze a sloţitě je interpretovat. Tím se samozřejmě ušetří i čas strávený při tvorbě aplikace. 3.3 Analýza a návrh Pokud chceme navrhnout model, který bude přesně odpovídat modelované realitě a zároveň budeme chtít odstranit co nejvíce chyb uţ v začátku, tak potom je potřeba projít nejdříve analýzou poţadavků, třemi úrovněmi návrhu datového modelu a normalizací: Analýza poţadavků. Datové modelování - konceptuální model. Datové modelování - logický model. Datové modelování - fyzický model Normalizace Analýza požadavků V této fázi se ještě plně nezaobíráme samotným návrhem databáze, ale jde nám především o důkladné prozkoumání například konkrétního firemního prostředí za účelem získání co nejvíce podkladů a informací, na jejichţ základě poté budeme postupovat dále. Tato analýza probíhá většinou na několika frontách, tou první je samozřejmě vnější zkoumaní modelovaného výseku reálného světa představujícího prostředí konkrétní firmy, následně se prozkoumá dokumentace, pozoruje se provoz organizace a nakonec se začne pracovat s informacemi od firemních zaměstnanců, coţ v sobě vlastně zahrnuje rozhovory a

18 Metodika návrhu databáze dotazníky se samotnými uţivateli, kteří budou aplikaci vyuţívat, o tom, jak si daný projekt představují a co jim popřípadě na stávajícím modelu vadí. V neposlední řadě je potřeba vše prodiskutovat s managementem a předloţit příslušným osobám moţné návrhy a nápady z analýzy vzešlé a zaměřit se na budoucí potřeby a cíle ve světle potřeby zajistit funkcionalitu systému, který měl z analýzy vzejít jako její výsledek. [3] Datové modelování - konceptuální model Na této úrovni se snaţíme interpretovat, jaká data budou uloţena v databázi. Zatím se vůbec nezajímáme o HW, SW či logiku, jediné co nás zde zajímá je to, co bude obsahem samotného systému, a to se snaţíme znázornit pomocí konceptuálního modelu, ve kterém se nacházejí zatím jen základní informace jako názvy entit a atributů, cizí klíče a vztahy.[4] Kromě názvů entit a atributů tedy bude ještě vytvořen vztah mezi entitami, který bude znázorňovat i jeho mohutnost. Mohutnost vztahu Mohutnost nebo také kardinalita vztahu určuje, kolik záznamů z jedné tabulky odpovídá kolika záznamům z tabulky druhé. Takto mohou vzniknout 4 druhy vztahů 1:1, 1:N, N:1 a N:M. 1:1 vztah, kdy jednomu záznamu odpovídá jeden záznam z tabulky druhé.[1] 1:N jedná se o vztah, kdy jednomu záznamu z první tabulky odpovídá nekonečně mnoho záznamů z druhé tabulky, takový vztah můţe v reálném světě vzniknout například u vztahu fotbalový klub a hráči, kdy jeden klub můţe mít více hráčů, ale hráč nesmí mít najednou více klubů neţ jen jeden.[4][1] N:1 jedná se o totoţný vztah jako 1:N, ale je na něj nahlíţeno z druhé strany, tedy ze strany tabulky, ve které více záznamů odpovídá jednomu záznamu z tabulky druhé. N:M tento vztah se vyznačuje tím, ţe v podstatě spojuje oba dva předchozí vztahy a vytváří z nich spojení N:M, které se dá v reálu hezky popsat velice oblíbeným vztahem autoři a knihy, kdy jeden autor zcela jistě můţe mít více knih a stejně tak jedna kniha můţe mít více autorů. Nicméně ve světě databází takovýto vztah nemůţe vzniknout ze dvou tabulek, jako tomu bylo u předchozích příkladů, ale je potřeba vztahy 1:N a N:1 propojit takzvanou

19 Metodika návrhu databáze vazební tabulkou, která tvoří spojovací prvek, kde se setkávají většinou primární klíče propojovaných tabulek a vzniká tím spojení M:N. [4][1] 19 Obr. 2. Ukázka celého konceptuálního schématu Převzato z: Datové modelování - logický model Zde uţ se snaţíme navrhovaný model popsat daleko podrobněji, model je jiţ přesně definován (relační, relačně-objektový ), jsou vytvořeny konkrétní tabulky a sloupce a určujeme primární klíče.[4] Nicméně stejně jako konceptuální model, tak ani logický nesmí být navrhován tak, aby splňoval přesné poţadavky pro implementaci do nějakého konkrétního SŘBD. Stále je to model, který je vytvářený bez zaměření na konkrétní systém, a jeho datová struktura je popisována v obecné rovině, coţ nám v budoucnu můţe pomoci i při konstrukci nového konečného schématu pro jiný SŘBD, neţ pro jaký jsme navrhovali původně.

20 Metodika návrhu databáze Primární klíč Primárním klíčem (PK) v podstatě rozumíme jeden atribut jedné datové věty, který jí jednoznačně charakterizuje a zároveň neexistuje moţnost, aby se ve stejné tabulce vyskytl u jiné datové věty stejný. Při hledání vhodného atributu se nejdříve vyberou tzv. kandidáti na primární klíč (KPK), z nichţ se vybere následně ta nejideálnější moţnost nebo moţnosti, které nejlépe splňují poţadavky na unikátnost a minimálnost, neboli neopakovatelný a co moţná nejmenší. Z kandidátních klíčů, které nebyly vybrány, se stávají alternativní klíče.[2][3] Nicméně primární klíč je mezi daty velice těţko hledatelný, a proto se většinou pouţívají uměle vytvořené, které s obsahem databáze nemají nic společného, zato ale představují posloupnost čísel, které vţdy jednoznačně identifikují jeden záznam. Cizí klíč Sloupec nebo skupina sloupců v jedné tabulce, která odpovídá kandidátnímu klíči některé (případně téže) tabulky. [3] Cizí klíč tvoří v podstatě spojení mezi dvěma tabulkami a vytváří referenční integritu pro na sobě závislá data. 20

21 Metodika návrhu databáze 21 Obr. 3. Ukázka celého logického schématu Převzato z:

22 Metodika návrhu databáze Datové modelování - fyzický model Ve fyzické úrovni se uţ model přizpůsobuje přesně daným kritériím a pravidlům pro konkrétní SŘBD, coţ ve výsledku znamená, ţe navrhovatel se musí zaměřit na to, do jakého systému se bude relační model implementovat. Týká se to zejména s datových typů, indexů a integritních omezení. [5]

23 Metodika návrhu databáze 23 Obr. 4. Ukázka celého fyzického schématu Převzato z:

24 Metodika návrhu databáze Normalizace Normalizace je, když: upravíme konceptuální či logický model databáze s cílem 1) omezit redundanci - každý údaj má být v databázi jen jednou 2) omezit složitost, tj. dekomponovat složité relace na dvojrozměrné tabulky s atomickými hodnotami polí a složité vztahy více - více na jednoduché vztahy 1 : N nebo 1 : 1 3) zabránit tzv. aktualizačním anomáliím (např. abychom při zrušení záznamu o programu nepřišli o údaje o filmu). [6] V této proceduře tedy probíhají zejména korekce struktury a je zde snaha o zkvalitnění a zlepšení vyuţitelnosti databáze, jejího budoucího lehkého udrţování a zrychlení dotazování na ni. Samotná korekce struktury pak probíhá zejména na bázi rozdělování tabulek na hlavní tabulky a podkategorie, aby se dalo v budoucnu s daty lépe a přesněji pracovat a aby se co nejvíce sníţila redundantnost dat. Celý tento očistný proces se provádí v 6-ti krocích, a zjišťuje se během něho, jestli kaţdá tabulka i její atribut splňují 6 norem / pravidel [7], které jdou v přesném pořadí za sebou a navazují na sebe, coţ ve výsledku znamená, ţe kaţdá vyšší norma musí splňovat všechny niţší normy, které byly před ní, přičemţ nejdůleţitější jsou první tři, které by měla splňovat kaţdá databázová struktura: 1NF říká, ţe všechna data musí být atomická, coţ znamená, ţe data by neměla jít z pohledu databáze dále rozkládat, takţe pokud například popisujeme adresu nějakého domu, tak nemůţeme jako jeden atribut uvést město, ulici a č.p., ale tento údaj musíme rozdělit na tři atributy město, ulici a č.p.[7][8] Adresa Praha, Jindřišská 2 Praha, Na Pískách 130 Město Ulice Č.p. Praha Jindřišská 2 Praha Na Pískách 130 2NF udává, ţe všechna data v tabulce musí záviset na celém klíči, takto napsané se to moţná na první dojem zdá trochu nepochopitelné, protoţe na jednom primárním

25 Metodika návrhu databáze klíči závisí data vţdy, ale musíme si uvědomit, ţe mohou existovat i vícenásobné primární klíče a tam uţ vyvstává onen problém, který se snaţí řešit druhá normální forma, která se snaţí předejít tomu, aby se nestalo, ţe některá data budou záviset jen na jedné podmnoţině celého primárního klíče a ne na všech jeho podmnoţinách, coţ by mohlo vést k aktualizační anomálii, coţ je stav, kdy pro změnu jednoho údaje (popis výrobce) musíme změnit více řádků (u modelů GTBi i GTSi).[7][8] Model - pk Výrobce pk Popis výrobce Popis auta GTBi Ferarri Popis Ferrari Popis GTBi 25 SLK Mercedes Popis Mercedes Popis SLK GTSi Ferrari Popis Ferrari Popis GTSi Výrobce - pk Ferarri Mercedes Ferrari Popis výrobce Popis Ferrari Popis Mercedes Popis Ferrari Model - pk Výrobce - pk Popis auta GTBi Ferarri Popis GTBi SLK Mercedes Popis SLK GTSi Ferrari Popis GTSi 3NF neklíčová data jsou závislá jen na klíči, nikoli mezi sebou, tak zní třetí normální forma a dá se vysvětlit tak, ţe hodnota jednoho neklíčového sloupce nesmí záviset na jiném, pokud se nejedná o klíč. [7][8]

26 Metodika návrhu databáze 26 Knihy ID pk Název Autor autora 1 Myslíme v Mysql n Gilfilia Gilfilian@hotmail.com Knihy Autoři ID pk Název Autor Autor - autora 1 Myslíme v Mysql Gilfilian pk Gilfilia Gilfilian@hotmail.co Ostatní normy BCNF všechna data závisí jen na klíči, nikoli mezi sebou. n m 4NF sloţený primární klíč nesmí být tvořen z nezávislých dat 5NF pokud je klíč sloţený z více neţ tří atributů, nesmí obsahovat párové cyklické závislosti [7] 3.4 Systém řízení báze dat Systém řízení báze dat je software, který dokáţe pracovat s velkým mnoţstvím dat, řídit ho, spravovat ho a provádět s těmito daty úkony jako mazání či aktualizaci. Přes tuto programovou komponentu se teprve tahají data a vytváří se takový most mezi aplikačním rozhraním a samotnými daty, který obyčejný uţivatel nevidí a moţná ani neví, ţe existuje, ale přesto je stejně důleţitý, ne-li důleţitější neţ samotné aplikační rozhraní.[1] Jelikoţ se tedy jedná o software, který pracuje s našimi daty a vyuţívá k tomu námi vytvořený model, je potřeba vědět, o co se jedná a jak nám zasahuje do celého návrhu, proto ještě předtím, neţ dokončíme tvorbu datového modelu, je potřeba vědět, jaký SŘBD budeme pouţívat, jelikoţ většina těchto komponent má mezi sebou rozdíly ve funkcích, v dotazech, v zápisu datového typu a v ovládání, navíc kaţdý SŘBD není vhodný pro opravdu velké

27 Metodika návrhu databáze datové objemy, tedy objemy v řádu miliónů záznamů, proto je potřeba nejen si podle výběru uzpůsobit nebo vyrobit fyzický model, ale je více neţ vhodné si předtím ještě zanalyzovat situaci ohledně budoucího objemu databáze a podle toho i vybrat vhodnou variantu SŘBD. Mezi nejznámější patří MySQL, Oracle nebo PostgreSQL. Administrace se následně provádí přes rozhraní správce. 27 Obr. 5. Ukázka administračního rozhraní phpmyadmin pro SŘBD MySql Převzato z:

28 Použité webové technologie 28 4 Použité webové technologie 4.1 HTML HTML je zkratka pro HyperText Markup Language a jedná se o základní značkovací jazyk pro tvorbu webových stránek Historie HTML Vůbec první výskyt jazyka HTML se datuje na rok 1990, ale prozatím se nejednalo o standardizovanou verzi, byl to úplný začátek, něco nového a bylo zapotřebí vývoje. Totéţ se dá říct i o verzi HTML+, která spatřila světlo světa v polovině roku 1993 a byla oproti původní verzi vybavena formuláři, tabulkami a moţností obrázků s popisky, nicméně stále chybělo formátování písma a textových částí a řada elementů byla nadbytečná a v pozdějším vývoji se uţ ani neobjevovala. [9] Roku 1994 se ale verzi HTML 2.0 otevřela cesta pro standardizaci, navíc jako první verze měla svojí formální specifikaci a také proto se stala oficiálním standardem. Tato verze měla oproti 78 elementům HTML+ elementů jen 49, ale jejich propracovanost byla daleko vyšší. Po úspěchu verze 2.0 nenechal na sebe další vývoj dlouho čekat a hned další rok se objevila verze 3.0, která úroveň formátování opět pozvedla a přinesla s sebou jiţ moţnost tvořit obtékání obrázků nebo tabulek textem, poprvé se objevil také element FORM pro formuláře, který se pouţívá dodnes, nicméně některé další elementy pozbyly svojí vyuţitelnost a jejich podpora jiţ není k dispozici. Nicméně i přes to, ţe verze 3.0 přinesla několik zajímavých inovací, nezaznamenala ţádný výraznější úspěch a proto se jako pravý nástupce HTML 2.0 bere aţ vylepšená verze 3.2, která ale navazuje spíše na 2.0 neţ na novější verzi 3.0. HTML 3.2 přineslo dalších 19 elementů a zaznamenalo velké rozšíření zejména u prohlíţečů Netscape.[9][10][11] V roce 1997 vyšla verze HTML 4.0, ke všemu, co jiţ bylo v předchozích verzí vyhodnoceno jako uţitečné a vyuţitelné, byla přidána moţnost prvku OBJECT pro převáţně

29 Použité webové technologie multimediální záleţitosti jako obrázky či videa, popřípadě FLASH a objevily se i úpravy formulářů a tabulek, ovšem největším vylepšením byla moţnost vyuţití kaskádových stylů, se kterými se daly dělat vizuální divy na tvořené stránce, coţ je dodnes pouţíváno a u webových stránek to napomáhá jejich reprezentativnosti. [10] [11] O dva roky později vyšla ještě opravná verze 4.01, ale tím se v podstatě na dlouhá léta zastavil vývoj, pokud pomineme XHTML, které nepřináší do webových stránek nic objevného, pouze pravidla pro jejich psaní, nicméně v minulých letech se začalo pracovat na verzi HTML5, která by měla být budoucností a dnes jiţ tento standard je v podstatě na světě, ovšem některé jeho části jsou stále rozpracované. [12] Ve specifikaci této nové verze [13] se lze dočíst, ţe nabídne mnoho nových vylepšujících moţností, které bylo doposud moţné na internetové stránky dostat jen pomocí jazyků jako jsou PHP, Java nebo JavaScript, coţ se týká například i elementu TIME, který by měl reprezentovat datum a čas. Dále bude k dispozici práce s videem a audiem. Dalším vylepšením prošly i formuláře, které od verze 5 budou mít moţnost v elementu INPUT typově pracovat s URL, čísly, em, časem a dokonce i s barvou. Drobnějšími úpravami pak prošly i jiţ známe elementy jako IMG pro obrázky, kde se poupravovala práce s ohraničením a bude moţnost zaměnit název NAME za ID. Nová verze HTML 5 ale nemá u změn jen řadu nových elementů a vylepšení, ale zároveň i odstraňuje několik nepotřebných značek, které se zdály být s vývojem CSS jiţ nepotřebné, jelikoţ v kaskádových stylech se s nimi zachází daleko lépe, coţ platí pro CENTER, BIG nebo FONT HTML a XHTML Ve spojení s HTML se často objevuje i název XHTML, kde přidané X znamená extensible, neboli v překladu rozšířený, coţ ale ve skutečnosti XHTML nesplňuje tak, jak by se na základě názvu dalo očekávat, jelikoţ se v podstatě nejedná vyloţeně o rozšíření funkcí původního HTML, ale převáţně o jeho omezení co do způsobu, jak se co má zapisovat, aby dokument splňoval validitu XHTML, a byl tak naprosto správně interpretován prohlíţečem, nicméně z dlouhodobých zkušeností je známo, ţe validita většinou není nezbytně důleţitá k tomu, aby se stránka vykreslila správně. [12] Samotné XHTML vzniklo spojením HTML a XML a v podstatě kombinuje elementy HTML s pravidly zápisu XML, která přinášejí se svým formátem větší srozumitelnost, proto se také svět odvrací od obyčejného HTML a vše se v budoucnu směřuje k pravidly

30 Použité webové technologie svázanějšímu XHTML, aby se zápis kódu ustálil a byl pro aplikace lépe rozpoznatelný a jednotící, navíc všechny ostatní aplikace XML budou moci těţit ze stejných pravidel zápisu. [12][14][15] Verze XHTML XHTML 1.0 transitional (přechodové) bere v potaz i zápisy, které se s XHTML neslučují, jedná se například o formátování textu v dokumentu. XHTML 1.0 stric (striktní) jen přesný zápis podle pravidel, která určují formátování struktury a vzhledu webu, přičemţ formátování textu je vyňato. XHTML 1.0 Frameset pouţívá se u stránek, kde se vykytují rámy, nicméně tento [15] způsob tvorby stránek jiţ není příliš rozšířený, takţe s tím upadá i tato verze Rozdíly mezi XHTML a HTML Jak jiţ bylo řečeno, rozdíly mezi HTML a XHTML jsou v určitých zpřísněných pravidlech, jak zapisovat kód dokumentů, nicméně ještě předtím, neţ se vůbec dostaneme ke správnému zápisu značek, je potřeba zmínit, ţe dokument ve formátu XHTML vyţaduje hned na začátku uvést typ dokumentu, coţ se dělá pomocí DOCTYPE, kdy se uvede, o jaký jazyk a jakou verzi se jedná; podrobnější rozbor provedu v kapitole struktura dokumentu.[12] Příklad takovéto deklarace typu XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " Další výraznou změnou je, ţe všechny značky se musí psát malými písmeny, coţ platí jak pro ty základní jako <html>, <body> nebo <head>, tak i pro ty ostatní.[12] Základní zápis rozvrţení HTML dokumentu oproti XHTML: HTML <HTML> <HEAD>.. </HEAD> <BODY>.. <P>text.</P> </BODY> </HTML> XHTML <html> <head>.. </head> <body>.. <p>text.</p> </body> </html>

31 Použité webové technologie 31 Dalším rozdílným pravidlem je, ţe nepárové značky končí lomítkem, s čímţ souvisí i další pravidlo, které spočívá v tom, ţe párové značky musí být v páru povinně. Obě dvě pravidla jsou celkem jasná, první lze předvést například na značce <HR>, která označuje vodorovnou čáru; její délku určujeme parametrem anebo končí na konci bloku, ve kterém je, a proto není potřeba pro ni mít ještě zakončovací značku. V zápisu HTML byl zápis takto jednoduchý: <HR>, naproti tomu v XHTML je potřeba jej nejprve napsat malými písmeny, abychom dostáli úvodnímu pravidlu a následně je potřeba ještě tag uzavřít, coţ se provádí vloţením lomítka před koncovou ostrou závorku - <hr />. Druhé pravidlo nám zase říká, ţe pokud je značka párová, tak ukončovací tag nesmíme, stejně jako tag úvodní, vynechat, kaţdopádně toto pravidlo se nepsaně dodrţovalo i v HTML, takţe to z faktického pohledu není zásadní rozdíl, ale v XHTMl je to povinnost. [12][14][15] Původní HTML zápis mohl vypadat takto: <P>..text.. Zápis v XHTML musí vypadat takto: <p>..text.</p>. Dále musí mít všechny jednotlivé atributy přiřazeny hodnoty, přičemţ tyto hodnoty musí byt zároveň uzavřeny v uvozovkách. Jinými slovy, dle dřívější praxe v rámci HTML bylo moţno napsat k linii <hr /> délku pomocí atributu size, ale nevyplnit jí, anebo napsat délku bez uvozovek: <hr size= /> nebo <hr size=10 />, ale pokud chceme mít dokument jako XHTML a chceme ho mít validní, je potřeba všechny atributy vyplnit nějakou hodnotou a ještě tu hodnotu vloţit do uvozovek: <hr size= 10 />. Pokud z nějakého důvodu nevyhovují zmíněné uvozovky, lze je nahradit apostrofy: <hr size= 10 />. [12][14][15] Dalším odlišením XHTML od HTML je zákaz kříţení značek, coţ znamená, ţe pokud máme dvě párové značky do sebe vnořené, je potřeba, aby jejich zakončovací části šly za sebou přesně v opačném pořadí, neţ jsme psali počáteční. [12][14][15] Chybně napsáno: : <p><b><i> Odstavcový text v tučné kurzívě</b></p></i> Správně napsáno: <p><b><i> Odstavcový text v tučné kurzívě</i></b></p> Jak je nyní tedy zřejmé, co do popsaných rozdílů se jedná v podstatě o záleţitosti marginálního charakteru, ale uvedené změny výrazně napomáhají ve sjednocování stylu psaní webových projektů a v jejich snazším zpracovávání.

32 Použité webové technologie Struktura XHTML dokumentu Stejně jako se většina typizovaných dokumentů (například ţivotopis) řídí určitými pravidly, která určují, jak se tyto dokumenty mají psát, aby jim čtenář správně rozuměl, je takto potřeba strukturovat i XHTML dokument, aby mu správně rozuměly internetové prohlíţeče. Na začátku dokumentu musíme povinně zadat deklaraci XML, ovšem jen pokud je dokument v jiném kódování neţ UTF-8 nebo UTF-16. <?xml version="1.0" encoding="utf-8"?> Následně musíme označit dokument jako HTML, to se dělá deklarací DOCTYPE, která je jedinečná a je potřeba ji uvést v kaţdém dokumentu.[16] <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " Deklarace je uzavřena do <! a >, coţ je v HTML označení pro komentář, ale zde to označuje začátek a konec deklarace, následuje slovo DOCTYPE, která dává najevo, ţe se bude jednat o deklaraci typu dokumentu. Samotné označení typu přichází aţ teď, jako první se píše html, pokud však zamýšlíme psát XHTML dokument, je nutné to napsat malými písmeny, jelikoţ XHTML mezi malými a velkými písmeny rozlišuje; pokud bychom to tedy napsali písmeny velkými, dokument by pak nebyl validní. V deklaraci pak následuje slovo PUBLIC, coţ je další důleţitou součástí, jelikoţ indikuje, ţe se jedná o původní veřejný dokument a ne o jeho konkrétním subjektem upravenou verzi, která se občas objevuje u různých firem. Následující řetězec -//W3C//DTD XHTML 1.0 Strict//EN, který je záměrně uzavřen do uvozovek, aby bylo zřejmé, ţe se jedná o celek, nám definuje druh a verzi jazyka a činí to pomocí zkratek W3C(World Wide Web Consorcium), DTD(Document Type Definition), coţ je seznam povolených elementů a atributů, které se dají pouţít pro jazyk, XHTML 1.0, která určuje verzi jazyka, a Strict, coţ je typ verze XHTML 1.0, která vyţaduje striktní dodrţování pravidel. Poslední částí je pak URL adresa, která vede na seznam elementů a atributů - Takovýto začátek je tedy potřeba pro správnou validaci, a to ne kvůli tomu, ţe by se bez toho dokument neobešel, ale při zkoumání správnosti webu konsorciem W3C je právě díky

33 Použité webové technologie tomuto označení zjištěno, co a jak se má kontrolovat, takţe následné zkoumání validace probíhá tak, ţe se podle DOCTYPE zjistí, o jaký dokument se jedná a následně se správnost zápisu porovnává se seznamem povolených elementů a atributů v DTD. Po této deklaraci typu dokumentu je na řadě uţ samotná struktura, která ze stránky vytváří jeden celek. Nejprve je nutné ohraničit celý dokument párovou značkou <html> a </html>, která nám rámuje vše, co bude patřit pod elementy, se kterými bude stránka pracovat a zobrazovat je. Oproti HTML by měl počáteční tag obsahovat deklaraci jmenného prostoru XHTML a jazyk.[16] <html xmlns=" xml:lang="cs" lang="cs"> Následovat bude opět párová značka <head> a </head>, která má v sobě hned několik důleţitých částí a vkládají se do ní informace, které se ještě přímo nevykreslují. První, co by nemělo v hlavičce chybět, je značka TITLE, ve které se schovává název nebo nadpis celé stránky, který se následně při prohlíţení stránek zobrazuje v horní části prohlíţeče nebo jako název záloţky. Lze tam napsat cokoliv, co charakterizuje obsah stránek.[16] <title>seznam Najdu tam, co neznám</title> 33 Obr. 6. Ukázka titulku internetové stránky Další části hlavičky jsou jiţ jen volitelné, patří mezi ně například meta data. Ty v sobě nosí plno informací o stránce, o autorovi, o klíčových slovech, ale mimo tyto méně důleţité části obsahuje i informace o znakové sadě pouţitého jazyka, díky které se nám následně bude správně zobrazovat například čeština. Pro znakovou sadu a jazyk se pouţívají tyto meta data, ve kterých zjistíte o který typ se jedná, zde windows-1250, a také o jaký jazyk. <meta http-equiv="content-type" content="text/html; charset=windows-1250" /> <meta http-equiv="content-language" content="cs" /> Pro název autora nebo klíčová slova se pouţívá podobný zápis, do atributu name se napíše název a do content hodnota.

34 Použité webové technologie 34 <meta name="autor" content="libor Musil" /> <meta name="keywords" content="konzultace, sks, vysoká škola informačních služeb" /> Další součást hlavičky dokumentu je opět značně variabilní, jedná se o přidávání externích skriptů nebo souborů s kaskádovými styly, popřípadě přímo napsání skriptů a výpis kaskádových stylů. Přidání souboru s CSS styly: <link rel="stylesheet" type="text/css" href="./default.css" media="screen" /> A souboru s JavaScriptem: <script type="text/javascript" src="./js/wpsf-js.php"></script> Přímé vepsání CSS do hlavičky: <style type="text/css">... </style> Přímé vepsání JavaScriptu: <script type="text/javascript">... </script> Po hlavičce uţ následuje tělo dokumentu, píše se pod hlavičku a je to párová značka <body> a </body>, v tomto segmentu se uţ vytváří samotná stránka, která se bude uţivateli vypisovat, tvoří se text, formuláře, tabulky, layout stránky a vše se navíc graficky dolaďuje obrázky a pomocí kaskádových stylů. 4.2 Kaskádové styly (CSS) Dříve, ještě neţ HTML začalo podporovat formátování pomocí kaskádových stylů, se vše upravovalo pomocí značek a atributů a nejenţe to nebylo příliš přehledné při sloţitějším

35 Použité webové technologie formátování a velikost dokumentu tím rapidně rostla do neúnosných mezí, ale navíc nebyly tak velké moţnosti pro tvůrcovu kreativitu a například pro rozvrţení stránek se pouţívaly tabulky, nicméně s nástupem CSS se u grafické úpravy HTML dokumentu otevřely úplně nové obzory. Jeho největší přínos tkví zejména v jiţ zmíněném oddělení formátování od prezentace obsahu, coţ nabízí hned několik výhod: Je moţné nastavit pro různá média či prohlíţeče různé styly, aniţ bychom museli vytvářet nesčetně souborů se stejným obsahem. Daleko přehlednější členění, neţ kdyţ formátujeme přímo v dokumentu pomocí atributů. Menší dokument s obsahem a tím jeho rychlejší načítání. Jeden takto vytvořený styl lze pouţít v libovolném mnoţství dalších dokumentů a následná úprava se neděje zdlouhavě v samotných dokumentech, ale upraví se jen jeden soubor se styly, účinek se pak promítne všude, kam byl importován. CSS styl se načte do paměti prohlíţeče, coţ pro nás znamená, ţe se při prohlíţení stránky jiţ znovu nenačítá, čímţ se urychlí přechod mezi stránkami. [19] Historie CSS Oficiální vznik CSS se sice datuje aţ na konec roku 1996, ale samotné úvahy o tom, jak jakýmkoliv způsobem oddělit formátování od obsahu dokumentu, existují v podstatě od samotného vzniku HTML, coţ bylo někdy kolem roku Tehdy začal na něčem podobném pracovat Tim Berners-Lee ve svém prohlíţeči NeXT, ale nikdy svojí vizi nepublikoval, takţe se ani nestala oficiální a pro formátování dokumentů se nepouţívala.[20] Nicméně roku 1994 uţ se začala pomalu rodit myšlenka odděleného formátování a to díky Hakon Wium Lieovi, který svůj koncept Cascading HTML Style Sheets publikoval a udal tak směr, jakým se posléze ubíralo CSS, avšak ještě před oficiálním vydáním bylo pro potřeby HTML vytvořeno formátování přímo v něm, coţ ale nebylo šťastné řešení; to se ukázalo aţ později, kdyţ roku 1996 byla vydána první oficiální specifikace kaskádových stylů a začalo být patrnější tření mezi formátováním pomocí CSS a formátováním v HTML.[21][22] Nicméně problémy, které přetrvávají dodnes, rozhodně nezabrzdily vývoj samotného CSS, hned v úvodu jej začali pouţívat u Microsoftu a jeho podporou obdařili svůj Internet Explorer

36 Použité webové technologie 3, na coţ zareagoval i Netscape a pro svůj prohlíţeč zařídil totéţ, coţ pro tvůrce stránek otevřelo nové moţnosti úpravy textu a vzhledu svých stránek. Mimo jiné najednou mohli snadno a rychle upravovat font textu, jeho velikost, mezery mezi slovy, písmeny nebo textem, upravovat barvy pozadí, přidávat obrázky, zarovnávat, zvětšovat odsazení a spoustu dalšího. V polovině roku 1998 byla vydána druhá verze kaskádových stylů, která byla nazvána CSS2 a byla zaloţena na původním CSS. Nová verze přidávala další moţnosti převáţně v pozicování a nabízela tzv. z-index, který přiřazuje prvku jeho důleţitost a nadřazenost při překrývání. Nicméně následně na delší dobu nastal menší útlum a zpomalení vývoje, ovšem CSS se jiţ plně uchytilo a začaly se objevovat i další prohlíţeče, které měly jeho podporu, coţ se konkrétně projevilo například u Opery. [22] Roku 2004 byla ale po dlouhé době vydána opravná verze pod názvem CSS 2.1, které opravovala určité chyby v původní verzi, například výšku a šířku u absolutně pozicovaných elementů a odstraňovala špatně podporované vlastnosti, ale zároveň přinesla i několik vylepšení.[23] V nynější době se jiţ skoro pět let pracuje na nové verzi CSS3, ale rozvoje této technologie stále není dokončen Vkládání CSS stylů do XHTML O vkládání CSS do dokumentu jsem se jiţ nepřímo zmínil v kapitole struktura, ale zde bych se tomu rád věnoval trochu obšírnějším a důkladnějším způsobem, jelikoţ je hned několik způsobů, jak to provést a některé je výhodnější pouţívat neţ ty ostatní. Z předchozí části tedy víme, ţe existují nejméně dva způsoby jak vkládat zápis CSS do dokumentu, ale ve skutečnosti je jich více. Tím prvním, málo pouţívaným, je psaní vlastností přímo k elementům. Tato metoda není moc efektivní, protoţe tím ztratíme mnoho výhod, ať uţ se jedná o přehlednost kódu a jeho pozdějších sloţitých úprav nebo velikost celého dokumentu. Takovéto stylování elementu se provádí přímo uvnitř jeho začáteční části a mezi uvozovky v style jiţ vypisujeme všechny vlastnosti a hodnoty. Příklad se změnou barvy písma a jeho podtrţením: <span style="color: #666; text-decoration: underline;"> Další, uţ trochu lepší moţností, je vepsání vlastností a hodnot přímo do hlavičky (<head></head>), nicméně i tady by se ztratilo hned několik výhod, které CSS svými moţnostmi přináší, například mít jen jeden soubor se styly pro všechny dokumenty a také ušetření místa, takţe uţ jen z toho vyplývá, ţe tato varianta také není nejideálnější.

37 Použité webové technologie 37 Příklad takovéhoto zápisu v hlavičce: <head> <style type="text/css"> <![CDATA [ p, div, span { Font-size: 14px; Text-decoration: underline; ] ]> } </style> </head> Pomocí <![CDATA [ ] ]> schováváme CSS zápis před prohlíţeči, které neumí s tímto formátováním pracovat. Následující varianta je nejpouţívanější, jedná se o sepsání všech vlastnosti do jednoho textového souboru s příponou css, a následně tento soubor vloţit do všech dokumentů, které hodláme tímto stylem naformátovat do určité vizuální podoby. Příklad vloţení, který následně rozeberu: <link rel="stylesheet" type="text/css" href="./default.css" media="screen" /> <link /> je tedy jakýsi vkládající element, který má v sobě hned několik atributů, které lze nastavovat. Tím prvním je atribut rel, který nám specifikuje vztah odkazovaného zdroje k našemu dokumentu, zde tedy styl, atributem type pak udáváme typ zdroje, který se bude načítat, dále pomocí href udáváme alternativní nebo absolutní cestu k cílovému zdroji, a nakonec v části media popisujeme médium, které náleţí dokumentu, neboli u nás screen bude znamenat, ţe je to optimalizováno pro barvy a rozlišení obrazovky, pokud bychom zadali print, tak je to pro tiskový náhled. [24] Výše uvedené metody jsou asi nejznámější, ale existuje ještě jedna varianta, která dává prostor pro větší optimalizaci i pro starší prohlíţeče. Jedná se o importování, coţ ve výsledku vypadá sice stejně, jako kdyţ pouţíváme element pro vkládání <link />, ale není to úplně pravda. Importování se totiţ mimo hlavičky dá pouţít i v samotném textovém souboru CSS, coţ nám přináší hned dvě výhody. Zaprvé, pokud máme více stylových

38 Použité webové technologie souborů, lze je naimportovat do jednoho CSS a ten pak teprve vloţit do obsahového dokumentu, zadruhé starší prohlíţeče nepodporují některé modernější pozicování, takţe do importovaných souborů můţeme vloţit modernější zápis, tím ho distancovat od starých prohlíţečů, které by se na něm mohly zaseknout a následně lze jednoduchý zápis například velikosti nebo barvy písma dopsat do souboru, kde importujeme a který pak vkládáme do dokumentu. [25] Názorná ukázka souboru CSS default.css vkládaného pomocí url("nabidka.css"); body{ font-family:arial; font-size:12px; } V importovaných CSS souborech layout.css a nabídka.css můţeme pak mít sloţitější pozicování nebo z nějakého důvodu oddělené styly, třeba kvůli přehlednosti. A pro kompletnost ještě ukázka importu v hlavičce: <head> <style type="text/css"> <![CDATA default.css ; ] ]> } </style> </head> PHP PHP je skriptovací jazyk, který nám dává moţnost vytvářet vlastní skripty a vkládat je přímo do hypertextového dokumentu. Jeho výhodou oproti například JavaScriptu, který nám také nabízí moţnosti tvorby skriptů, je ta, ţe se zdrojový kód nezpracovává u klienta, jako tomu je u JS, ale zpracovává se přímo na serveru, coţ nám přinese výhody jako: Nenáročnost na HW a SW klienta

39 Použité webové technologie 39 Přenesená data jsou menší, jelikoţ PHP skript se zpracuje na serveru, ale dál uţ se u klienta nezobrazuje, na rozdíl například od JS. Vyšší ochrana aplikace a chráněné skripty před útoky hackerů, jelikoţ se jádro skriptu nezobrazuje a nelze se k němu dostat. Tím můţeme pracovat s údaji uvnitř skriptu, které by neměl uţivatel vidět, například tzv. solení hesla. [26] 4.4 Historie PHP Začátky PHP šahají aţ do roku 1994, kdy si Rasmus Lerdorf vytvořil pro svoje soukromé účely program, který měl hlavně sledovat návštěvnost stránky, nejdříve ho napsal v PERLu, ale později přeprogramoval do C a dokonce ho nabídl pár svým známým k pouţívání. Sám Lerdorf by asi jiţ s vývojem nepokračoval, ale naštěstí pro budoucnost PHP jeho přátele program zaujal a chtěli po Lerdorfovi neustále nové funkce, přicházeli dokonce s různými svými vlastními nápady a vývoj PHP tak pokračoval. Oficiální vypuštění do světa tak na sebe nenechalo dlouho čekat a první PHP bylo na světě, ovšem tato zkratka v sobě tehdy nesla označení Personal Home Page. [26][27] Vývoj ale pokračoval dál a hned o rok později spojil Lerdorf PHP se svým dalším programem a vytvořil tak PHP/FI 2.0, zkratka FI znamenala Form Interpreter a přinášela do PHP zejména snadnou manipulaci s daty z formulářů. Tato verze zaznamenala velký úspěch a tedy i velké celosvětové rozšíření. [26][27] Koncem roku 1998 vznikla třetí verze PHP 3.0, která byla o mnoho rychlejší neţ předchozí, obsahovaly ji nově i Windows a přinesla také podporu mnoha databázových systémů, cookies nebo objektů. Někdy v té době se uţ nedalo mluvit o PHP jako o nástrojích pro osobní domácí stránky, coţ PHP v začátku znamenalo a začalo se pouţívat Hypertext PreProcesor, neboli jakési předzpracování hypertextu. [26][27] Za další dva roky vyšla dokonce uţ PHP 4.0, vývoj byl tedy velice rychlý, ale s novou verzí přišla snaha spíše o velké zrychlení u sloţitých skriptů a proto jako největší vylepšení je povaţována změna jádra samotného PHP na Zend engine, který změnil způsob zpracovávání skriptů.[28]

40 Použité webové technologie Naproti tomu u PHP 5.0 v roce 2004 uţ přišla vylepšení i ve funkcionalitě a podpoře. Největšího vylepšení se dočkalo objektově orientované programování, XML nástroje a spolupráce s MySQL. [29] Zápis PHP do XHTML Jelikoţ XHTML je značkovací jazyk a PHP skriptovací a kaţdý se zpracovává jinde, je nutno je v dokumentu od sebe oddělit, anebo propojit, nelze je bezmyšlenkovitě slučovat. První variantou, která v tomto případě lze pouţít, je uzavřít php kód do bloku, který bude značit, ţe se jedná právě o php skript a tím oddělit značkovací jazyk od skriptovacího. Dělá se to pomocí párových značek <?php a?>, do těchto značek se vypíše skript a ten se pak zpracuje mimo XHTML tak, jak má.[30] Ukázka: <body> <p>text vypsaný v HTML</p> <?php echo Text vypsaný v php ;?> </body>. Druhou variantou je zapsat uţ XHTML kód v PHP značkách, neboli pokud zadáme v PHP jako prostý text XHTML značky, tak nám je server pošle zpátky jako text a prohlíţeč zobrazí jako XHTML stránku.[30] <?php echo <body> <p>text</p> </body> ;?>

41 Použité webové technologie Propojení s databází PHP také slouţí jako velice výkonný nástroj pro práci s SŘBD, obzvláště pak s MySQL, umí se k nim připojit a interpretovat data z databáze uţivateli. Ukázka připojení k MySQL $db_server $db_login = 'mysql.webzdarma.cz'; = 'konzultacesks'; $db_password = '*******'; $db_name = 'konzultacesks'; $spojeni die('<p style="color: #CC0000">Nastala chyba v pripojeni k databazi'); Ukázka připojení k Oracle oci_connect($prihlas_jmeno, $heslo, '//adresa:port/mojedatabáze');

42 Praktická část 42 Praktická část

43 Návrh databáze 43 5 Návrh databáze 5.1 Analýza požadavků Zanalyzovat poţadavky na systém jsou základem pro následný vývoj celého projektu, proto jsem se rozhodl vytvořit body, podle kterých se budu řídit při tvorbě. V této části jsem ale vycházel ze svých subjektivních poţadavků, jakoţto studenta, který by to vyuţíval, samozřejmě jako alternativní moţnost by tu byl sběr poţadavků od dalších potenciálních uţivatelů, nicméně aby tato metoda byla efektivní a ukázala relevantní výsledky, tak by bylo potřeba jí věnovat hodně času při průzkumu, proto jsem od ní upustil. Aplikace musí podporovat nejméně 2 typy uţivatelů učitelé a studenty Musí jít vytvořit konzultace nebo přihlášky uţivatelem. Uţivatel můţe mít více konzultací nebo více přihlášek- Konzultace musí mít časové údaje. Konzultace bude mít určené místo konání Místa konání budou pevně dané a konzultace se k nim budou jen přidávat. Systém bude správně zabezpečen, aby se do sekcí ostali jen osoby, které tam mají mít přístup Tentýţ systém bude platit i pro zaslané materiály studenty. Systém řízení báze dat nemusí být výkonnostně pro rozsáhle databáze.

44 Návrh databáze Use-case diagram Obr. 7. Use-Case diagram.

45 Návrh databáze Vývojový diagram aplikace Obr. 8. Vývojový diagram

46 Návrh databáze Fyzický datový model Fyzické datový model jsem vyrobil pro implementaci do SŘBD MySQL, který se mi vzhledem k potřebám aplikace a snadnému přístupu, jevil jako ideální. Obr. 9. Fyzický datový model pro MySql Model obsahuje 6 tabulek, základním kamenem je tabulka DBKonzultace_Uzivatele, kam se ukládají údaje o uţivateli, které jsou ještě rozšířeny pomocí vztahu M:N tabulkou DBKonzultace_Role, kde se uţivatel přiřazuje k roli (student, učitel). Následně jiţ vytváříme přihlášky, či konzultace pomocí tabulek DBKonzultace_Prihlaska a DBKonzultace_Kozultace, kde ještě konzultace jsou rozšířeny o místnosti vztahem 1:1 s tabulkou DBKonzultace_Mistnost a přiřazujeme je pomocí cizích klíčů k uţivatelům.

47 Tvorba aplikace 47 6 Tvorba aplikace V této kapitole bych se chtěl převáţně zaměřit na to nejdůleţitější z řešení svého kódu a ukázat, jak aplikace funguje zevnitř, myslím, ţe vysvětlování tvorby vzhledu, či jakým skriptem jsem se připojil k databázi, tu není důleţité. Obr. 10. Ukázka uživatelského rozhraní aplikace 6.1 Zabezpečení Aby mohla aplikace vůbec začít fungovat na principu jedinečného uţivatelského přístupu a být zabezpečená, bylo potřeba vytvořit zaprvé registraci uţivatelů a jejich přihlášení, to do

48 Tvorba aplikace aplikace přináší fakt, ţe kaţdý uţivatel má jedinečný přístup a zadruhé bylo nezbytné celý systém opatřit spoustou omezení Registrace Tato sekce je tvořena jako volná registrace pro studenty a pro učitele, je to z toho důvodu, ţe zatím nebylo nutné tyto pozice při registraci oddělovat, nicméně pokud by aplikaci začala vyuţívat konkrétní škola a chtěla v ní mít jen svoje pedagogy, pak by byla maličkost vytvořit pod heslem zabezpečenou sekci jen pro registrace kantorů. Nicméně, neţ samotná registrace proběhne, je potřeba provést kontrolu, zdali nově registrovaný uţivatel nechce pouţívat login, který jiţ v databázi je. Na to jsem pouţil funkci JeUzivatel(), která to dotazem do databáze kontroluje a posílá zpátky výsledek, který buď zabrání registraci, anebo nechá pokračovat dál. function JeUzivatel($username){ } $q = "select Login from DBKonzultace_Uzivatele where LOWER(Login) ='".strtolower(mysql_real_escape_string($username))."' limit 1"; $result = mysql_query($q) or die (mysql_error());; return (mysql_numrows($result) > 0); Tady je dobré si všimnout, ţe bylo nutné nejen ověřit existenci loginu v databázi, ale zároveň bylo nezbytné zabránit tzv. SQL Injection útoku na databázi pomocí funkce mysql_real_escape_string(), která odděluje hodnoty od dotazových kritérií. Pokud se projde všemi ověřeními, do čehoţ spadá například ověření vyplnění hodnot, či ověření délky hesla nebo jiţ uvedeného loginu, pak se nový uţivatel vloţí do databáze pomocí funkce PridatUzivatele(). function PridatUzivatele($username, $password, $ , $den, $mesic, $rok, $jmeno, $prijmeni, $mesto, $pozice){ $salt = "1ad2.6m8hcj5g"; $password= md5($password); $password = sha1($password.$salt); $username = addslashes($username);

49 Tvorba aplikace 49 $password = addslashes($password); $den = addslashes($den); $mesic = addslashes($mesic); $rok = addslashes($rok); $jmeno = addslashes($jmeno); $prijmeni = addslashes($prijmeni); $mesto = addslashes($mesto); $narozeni= $rok.'-'.$mesic.'-'.$den; $q = "INSERT INTO `DBKonzultace_Uzivatele` ( `ID_Uzivatel`, `Jmeno`, `Prijmeni`, ` `, `Login`, `Password`, `Datum_Narozeni`, `Bydliste`) VALUES ('', '$jmeno', '$prijmeni', '$ ', '$username', '$password', '$narozeni', '$mesto')"; mysql_query($q) or die(mysql_error()); $nove_id= mysql_insert_id(); } $q = "INSERT INTO `DBKonzultace_Uzivatele_Role` ( `ID_Uzivatel`, `ID_Role`) VALUES ('$nove_id', '".intval($pozice)."')"; return mysql_query($q) or die(mysql_error()); Tady je důleţitá zejména úvodní část, kde se uţivatelem zadané heslo zahashuje funkcemi md5 a sha1, přičemţ, aby bylo dosaţeno nejvyšší bezpečnosti, tak je zároveň pouţito tzv. osolení hesla, coţ je proces, ve kterém se k heslu přidá jakýkoliv řetězec znaků a tím se docílí ještě větší obtíţnosti zjištění původního hesla, pokud by se někdo dostal k zahashovaným heslům v databázi.

50 Tvorba aplikace 50 $salt = "1ad2.6m8hcj5g"; $password= md5($password); $password = sha1($password.$salt); Po přidání uţivatele se ještě zapíše jeho role v aplikaci (učitel/student), bez toho nemůţe být registrace kompletní. $q = "INSERT INTO `DBKonzultace_Uzivatele_Role` ( `ID_Uzivatel`, `ID_Role`) VALUES ('$nove_id', '".intval($pozice)."')"; Přihlášení Přihlášení se provádí přes přihlašovací formulář na hlavní stránce, kde se napíše login, heslo a nastaví role neboli pozice přihlašovaného. Obr. 11. Ukázka přihlašovacího formuláře Po odeslání se nejprve ověří uţivatel pomocí funkce OveritUzivatele, kde je dotaz na databázi se zadanými informacemi z přihlašovacího formuláře a ověření, zdali byl nalezen výsledek. function OveritUzivatele($login, $heslo, $pozice) { $salt = "1ad2.6m8hcj5g"; $dotaz = mysql_query("select u.id_uzivatel, Jmeno, Prijmeni, Login, Password, Nazev, ur.id_role, from DBKonzultace_Uzivatele u JOIN DBKonzultace_Uzivatele_Role ur ON u.id_uzivatel=ur.id_uzivatel JOIN DBKonzultace_Role r ON ur.id_role=r.id_role where Login = '".mysql_real_escape_string($login)."' and Password = '".mysql_real_escape_string(sha1((md5($heslo)).$salt))."' AND ur.id_role = ".intval($pozice)." LIMIT 1") or die(mysql_error()); $uzivatel = array(); if(mysql_num_rows($dotaz)>0) {

51 Tvorba aplikace 51 } } $row = mysql_fetch_assoc($dotaz); $uzivatel = array( ); 'Jmeno' => $row['jmeno'], 'Prijmeni' => $row['prijmeni'], 'ID' 'Pozice' 'Nazev' ' ' return $uzivatel; => $row['id_uzivatel'], => $row['id_role'], => $row['nazev'], => $row[' '], Pokud uţivatel existuje, coţ se ověří spočtením nalezených řádků, tak se do pole zapíší uţivatelovy údaje, které budeme pouţívat if(mysql_num_rows($dotaz)>0) { $row = mysql_fetch_assoc($dotaz); $uzivatel = array( ); 'Jmeno' => $row['jmeno'], 'Prijmeni' => $row['prijmeni'], 'ID' 'Pozice' 'Nazev' ' ' => $row['id_uzivatel'], => $row['id_role'], => $row['nazev'], => $row[' '], A tyto hodnoty následně pošleme zpátky a zaregistrujeme do SESSION a tím jsme přihlášení. $_SESSION["Jmeno"]=$uzivatel_log['Jmeno']; $_SESSION["Prijmeni"]=$uzivatel_log['Prijmeni']; $_SESSION["ID"]=$uzivatel_log['ID']; $_SESSION["Pozice"]=$uzivatel_log['Pozice']; $_SESSION["Nazev_Pozice"]=$uzivatel_log['Nazev']; $_SESSION[" "]=$uzivatel_log[' ']; Další moţnost zapsání přihlašovacích hodnot by byly COOKIES, nicméně ty slouţí většinou pro trvalé přihlášení a uţivatel je následně můţe upravovat, coţ u SESSION nemůţe.[31]

52 Tvorba aplikace Zabezpečení přístupu k sekcím Jestliţe má systém konzultací splňovat i nároky na bezpečnost zaslaných dat, tak jsem musel kaţdou sekci, která nemá být přístupná všem, zabezpečit tak, aby se nejen nezobrazil odkaz na ní, ale zároveň, aby se do ní nešlo dostat ani při znalosti adresy sekce. Takovéto zabezpečení probíhá ve dvou vrstvách, nejprve pomocí větvící PHP funkce if() kontroluji, jestli je dotyčný vůbec přihlášen. if($_session['pozice']) { } Pokud je přihlášen, pokračuje kontrola stejným stylem a kontroluje se role přihlášeného v systému, jelikoţ do určitých sekcí má přístup jen učitel a do jiných zase jen student. if($_session['pozice']=="1") { } Tato dvojí ověření dělám z toho důvodu, aby bylo uţivateli díky vypsanému upozornění jasné, proč se do sekce nemůţe podívat, zdvojením by se bezpečnost samozřejmě nezvýšila Zabezpečení přístupu k přihláškám studentům Dalším neobvyklým zabezpečením, které jsem se rozhodl zanést do systému, je, ţe jsem zamezil, aby si mohl kaţdý učitel prohlédnout jakoukoliv přihlášku, aniţ by se třeba týkala jeho konzultace. Tento problém jsem vyřešil dotazem do databáze, který má zjistit, zdali je učitel autorem konzultace, ke které se přihláška vztahuje, pokud není, není mu ani přihláška zobrazena. $q = "SELECT * FROM DBKonzultace_Prihlaska p JOIN DBKonzultace_Konzultace k ON p.id_konzultace=k.id_konzultace WHERE ID_Prihlaska = '".intval($_get['id'])."' AND k.id_uzivatel = '".$_SESSION["ID"]."' limit 1"; $result = mysql_query($q) or die (mysql_error()); $overeni = mysql_num_rows($result); if($overeni==1) { //výpis přihlášky }

53 Tvorba aplikace Omezení stahování příloh Další omezení, které se mi jevilo, jako velice důleţité je, ţe přílohu smí stahovat jen učitel, kterému je adresována a student, který ji nahrával. Opět jsem to vyřešil dotazem do databáze, ovšem tentokrát bylo potřeba vytvořit dynamický dotaz, který se mění podle toho, která role bude stahovat. Takto je to uděláno z toho důvodu, ţe soubor můţe stahovat jak učitel, tak student. if($_session['pozice']==1) $kp="p"; if($_session['pozice']==2) $kp="k"; $q = "SELECT * FROM DBKonzultace_Prihlaska p JOIN DBKonzultace_Konzultace k ON p.id_konzultace=k.id_konzultace WHERE ID_Prihlaska = '".intval($_get['id'])."' AND $kp.id_uzivatel = '".$_SESSION["ID"]."' limit 1"; $result = mysql_query($q) or die (mysql_error()); $overeni = mysql_num_rows($result); if($overeni==1) { // stahování souboru souboru ( Tím ale úplné zabezpečení nekončí, jelikoţ stále tu je moţnost, ţe by někdo schopný mohl získat nějakým způsobem přímou cestu k souboru a stáhnout si ho ze sloţky. Nicméně to jsem vyřešil pomocí vytvoření soubor.htaccess ve sloţce se soubory, který pracuje s právy souborů a do kterého jsem zanesl příkaz, který zabrání tomuto stahování a umoţní stahovat jedině přes PHP skript. Nicméně pro fungování je důleţité, aby.htaccess byl podporován hostingem, na kterém aplikaci provozujeme. [32][33] deny from all 6.2 Práce s konzultacemi Tvorba konzultace Další velice důleţitou sekcí je tvorba konzultací, které mohou vytvářet jen zaregistrovaní a přihlášení pedagogové a vytváří se přes formulář.

54 Tvorba aplikace 54 Obr. 12. Ukázka formuláře na tvorbu konzultací. Správnost zápisu data i času se ověřuje přes funkce datum() a cas(), které pomocí regulárních výrazů kontrolují vkládaný tvar. Pokud zadaná hodnota neprojde kontrolou, pak se vkládání do databáze neprovádí a zobrazí se chybová hláška s nápovědou zápisu. function datum($datum) { } return ereg("^(0?[1-9] [12][0-9] 3[01])-(0?[1-9] 1[0-2])-20[0-9]{2}$",$datum); function cas($cas) { return 9])$",$cas); } ereg("^(0?[1-9] 1[0-9] 2[0-4]):(0[0-9] [1-5][0-

55 Tvorba aplikace Samotné přidávání jedné konzultace do databáze pak probíhá obvyklou metodou přes insert, kam se vloţí předem zkontrolované hodnoty z formuláře. mysql_query("insert INTO DBKonzultace_Konzultace(Cas_Konzultace_Od,Cas_Konzultace_Do, Kapacita, Poznamka_Ko, ID_Mistnost, ID_Uzivatel, Datum_Pridani_Konzultace) VALUES ('$b1','$b2','$kapacita','$poznamka','$mistnost', $ID_Ucitel, NOW())") or die(mysql_error()); 55 Nicméně pokud pedagog chce vyuţit moţnost tvorby cyklu konzultací, který funguje na bázi napsání dvou dat, přičemţ jedno určuje začátek cyklu a druhé konec, je potřeba vyuţít trochu rozšířenější metodu vkládání. Na začátku je potřeba zjistit kolikrát se bude samotné vykládání konzultace opakovat, to jsem udělal pomocí výpočtu: rozdíl zadaných dat/7 dni a to celé zaokrouhlil dolů pomocí PHP funkce floor. $s = strtotime($datumstart); $m = strtotime($datummez); $pocetdalsichvlozeni = floor(($m - $s)/604800); Následně je na řadě jiţ cyklus vkládání samotných konzultací, který bude opakován o jeden více, neţ bylo předtím vypočteno, je to z toho důvodu, ţe předchozí výpočet nezahrnuje vloţení úvodní konzultace. for($i = 0; $i <= $pocetdalsichvlozeni; $i++) { $s= strtotime("$datumstart + ".(7*$i)." day"); $b=date("y-n-j", $s); $b1=$b.' '.$cas; $b2=$b.' '.$cas2; mysql_query("insert INTO DBKonzultace_Konzultace(Cas_Konzultace_Od,Cas_Konzultace_Do, Kapacita, Poznamka_Ko, ID_Mistnost, ID_Uzivatel, Datum_Pridani_Konzultace) VALUES ('$b1','$b2','$kapacita','$poznamka','$mistnost', '$ID_Ucitel', NOW())") or die(mysql_error()); } Pro cyklus je velice důleţitý tento řádek, který nastavuje vkládané data do databáze, bez něho by se vkládalo stále stejné datum. $s= strtotime("$datumstart + ".(7*$i)." day");

56 Tvorba aplikace Mazání konzultace Mimo vkládání konzultací bylo pro dobrou funkčnost celé aplikace vhodné vytvořit také jejich mazání a editaci, coţ jsem navrhl jako moţnosti v sekci náhledu vytvořených konzultací pedagogem. Obr. 13. Ukázka administrace konzultací U mazání jsem ještě před jeho provedením zvolil JavaScriptové zobrazení okna pro potvrzení, z důvodu zamezení chybnému smazání. <input type="submit" name="smazat" value="smazat" onclick="confirm( 'Opravdu chete smazat tuto konzultaci?' )">

57 Tvorba aplikace Pokud je smazání potvrzeno, provede se následující skript, který smaţe jak samotnou konzultaci, tak i přihlášky, které jsou k ní přihlášeny. if($_post['smazat']){ 57 $query="delete FROM DBKonzultace_Konzultace WHERE ID_Konzultace=".mysql_real_escape_string($_POST['smazkonzult aci'])." LIMIT 1"; mysql_query($query); $query="select ID_Prihlaska, Priloha FROM DBKonzultace_Prihlaska WHERE ID_Konzultace=".mysql_real_escape_string($_POST['smazkonzult aci']); $result=mysql_query($query); if(!empty($result)) { } while($pr=mysql_fetch_array($result)) { } if(file_exists('./include/upload/'.$pr['priloha'])) { } if(unlink('./include/upload/'.$pr['priloha'])) { } $smaz="delete FROM DBKonzultace_Prihlaska WHERE ID_Prihlaska='".$pr['ID_Prihlaska']."'"; mysql_query($smaz); else { } $smaz="delete FROM DBKonzultace_Prihlaska WHERE ID_Prihlaska='".$pr['ID_Prihlaska']."'"; mysql_query($smaz); $refresh = htmlentities($_server['request_uri']); exit(include_once("refresh.php")); } Nejsloţitější část byla mazání přihlášek, které jsou ke konzultaci přiřazené, jelikoţ u nich bylo potřeba smazat i soubory na serveru, coţ jsem vyřešil vytvořením cyklu, který najde

58 Tvorba aplikace všechny přihlášky a postupně je maţe i se soubory. Po smazání se stránka aktualizuje a pedagog smazanou konzultaci jiţ nevidí Editace konzultace Pro editaci jsem vyuţil stejného formuláře, jako pro tvorbu, ale do zápisových polí jsem jiţ předvyplnil hodnoty, které jsou uloţeny v databázi u editované konzultace. Obr. 14. Ukázka formuláře pro editování konzultace Při editování se pak ověří správnost zápisu hodnot do formuláře a provede se editace databáze pomocí kódu, který je do značné míry podobný tomu, který tvoří nové konzultace, jen je definován jako update. $edit="update DBKonzultace_Konzultace SET Cas_Konzultace_Od = '$b1',cas_konzultace_do = '$b2', Kapacita = '$kapacita', Poznamka_Ko = '$poznamka', ID_Mistnost = '$mistnost', ID_Uzivatel = $ID_Ucitel

59 Tvorba aplikace 59 WHERE ID_Konzultace=".mysql_real_escape_string($_GET['id'])." LIMIT 1"; mysql_query($edit); 6.3 Práce s přihláškami Přihlášení ke konzultaci Skoro stejně důleţitá jako vytváření konzultací je tvorba přihlášek na konzultace. Uţ ze samé podstaty aplikace je jasné, ţe přihlašovat se mohou jen studenti. Samotná moţnost přihlásit se je situována do vyhledávací sekce, kde se moţnost přihlášení zobrazí jen studentům. Obr. 15 Ukázka vyhledávání a přihlášení Přihlášení pak probíhá přes formulář.

60 Tvorba aplikace 60 Obr. 16. Ukázka formuláře ro přihlášení Vkládání přihlášky do databáze je rozděleno do dvou větví, mezi kterými se rozhoduje podle toho, zdali bude nahráván soubor nebo nikoliv. První větev bez detekce pokusu o nahrání souboru je jen vloţení údajů do databáze přes příkaz. $q = "INSERT INTO `DBKonzultace_Prihlaska` ( `ID_Konzultace`, `ID_Uzivatel`, Nazev_Prihlaska, `Poznamka_Pr`, `Datum_Prihlaseni`) VALUES ('".intval($_get['idkonzultace'])."', '".$_SESSION['ID']."', '".mysql_real_escape_string($_post['nazev'])."', '".mysql_real_escape_string($_post['text'])."', NOW())"; mysql_query($q) or die(mysql_error()); echo 'Přihlášení proběhlo v pořádku'; Ve druhé větvi je uţ ale potřeba pracovat se souborem a začal jsem nejdříve s jeho přejmenováním z důvodů konfliktu názvů a následné lepší kompatibility. $filename = opravitnazev(basename($_files['priloha']['name'])); $filename = time()."-".$filename; Změna se provádí pomocí funkce opravitnazev(), která má za úkol nahradit nevhodné znaky a mezery, a pomocí přidání času na začátek souboru, čímţ docílíme jak dobré kompatibility názvu, tak i malé pravděpodobnosti, ţe bychom soubor se stejným názvem měli jiţ na serveru a v databázi.

61 Tvorba aplikace 61 function opravitnazev($nazev) { $nazev = Strtolower($nazev); $nazev = StrTr($nazev, "áäčçďéěëíňóöřšťúůüýž", "aaccdeeeinoorstuuuyz"); $nazev= eregi_replace("[^abcdefghijklmnopqrstuvwxyz \.]+"," -",$nazev); $nazev = ereg_replace("-\.",".",$nazev); $nazev = ereg_replace("\.+",".",$nazev); return $nazev; } Po této úpravě skript pokračuje dál, kontroluje ještě, zdali náhodou server neobsahuje soubor se stejným názvem, pokud ne, tak nahrává soubor do předem zadané cesty a ukládá jeho název do databáze i s ostatními údaji. $newname = dirname( FILE )."/upload/".$filename; if (!file_exists($newname)) { if ((move_uploaded_file($_files['priloha']['tmp_name'],$newname))) { $q = "INSERT INTO `DBKonzultace_Prihlaska` ( `ID_Konzultace`,`ID_Uzivatel`, Nazev_Prihlaska, `Poznamka_Pr`, `Priloha`, `Datum_Prihlaseni`) VALUES ('".intval($_get['idkonzultace'])."', '".intval($_session['id'])."', '".mysql_real_escape_string($_post['nazev'])."', '".mysql_real_escape_string($_post['text'])."', '".mysql_real_escape_string($filename)."', NOW())"; mysql_query($q) or die(mysql_error()); } echo "Příloha <b>".$_files['priloha']['name']."</b> byla úspěšně nahrána"; echo 'Přihlášení proběhlo v pořádku'; return; }

62 Tvorba aplikace Mazání přihlášky Stejně jako u konzultací bylo potřeba mít i nad přihláškami kontrolu, proto jsem také u přihlášek udělal moţnosti pro mazání a pro editaci. Obr. 17. Ukázka administrativy přihlášek Mazání přihlášek je takřka totoţné s mazáním konzultací, nicméně bylo opět potřeba podchytit, co se souborem, který je na serveru. Tuto část jsem vyřešil tak, ţe před vymazáním údajů z databáze si nejdříve načtu název souboru a ten pomocí PHP funkce unlink() vymaţu. Pokud soubor není nalezen, provede se jen výmaz z databáze. if($_post['smazat']){ $nazev="select Priloha FROM DBKonzultace_Prihlaska WHERE ID_Prihlaska=".mysql_real_escape_string($_POST['smazprihlask u'])." LIMIT 1"; $result=mysql_query($nazev); $pr=mysql_fetch_assoc($result); if(!empty($pr['priloha'])) { if(file_exists('./include/upload/'.$pr['priloha'])) { } if(unlink('./include/upload/'.$pr['priloha'])) { } $smaz="delete FROM DBKonzultace_Prihlaska WHERE ID_Prihlaska='".mysql_real_escape_string($_POST['smazprihlas ku'])."'"; if(mysql_query($smaz)) { } echo 'Smazáno'; else echo 'Soubor byl fyzicky smazán, ale nastla chyba při vymazávání z DB, obraťte se na podporu'; else echo 'Nepodařilo se smazat soubor'; else {

63 Tvorba aplikace 63 $smaz="delete FROM DBKonzultace_Prihlaska WHERE ID_Prihlaska='".mysql_real_escape_string($_POST['smazprihlas ku'])."'"; if(mysql_query($smaz)) { } echo 'Soubor neexistuje, z databáze záznam vymazán'; else echo 'Nastala chyba při vymazávání z DB a soubor neexistuje, obraťte se na podporu'; } } $refresh = htmlentities($_server['request_uri']); exit(include_once("refresh.php")); }

64 Tvorba aplikace Editace přihlášky Editace přihlášky probíhá podobně jako editace konzultace, s tím rozdílem, ţe měnění jiţ nahrané přílohy je moţné jen pod podmínkou, ţe bude předtím smazána, na coţ slouţí kříţek vedle názvu přílohy a opět funkce unlink s následným vymazáním z databáze, kód je pak téměř totoţný s tím, co vkládá nové přihlášky, jen se opět provádí update záznamu místo vloţení. Obr. 18. Ukázka editovacího formuláře pro přihlášky. 6.4 Systém vyhledávání konzultací Vyhledávání konzultací je další důleţitá část aplikace, jelikoţ bez kvalitního vyhledávacího systému by se těţko student orientoval a těţko by hledal jemu maximálně vyhovující konzultaci. Zaměřil jsem se zejména na nejdůleţitější vyhledávací kritéria a na moţnost dynamických dotazů, které dávají velké moţnosti v nastavení ideálních parametrů.

65 Tvorba aplikace 65 Obr. 19. Ukázka vyhledávání. Vyhledávání jsem pak pojal stylem skládačky, tj. jako první si uvedu výběr tabulek z databáze, které budu potřebovat a ten jsem si uloţil do proměnné. $volanitabulek = " SELECT * FROM DBKonzultace_Konzultace k JOIN DBKonzultace_Uzivatele u ON k.id_uzivatel=u.id_uzivatel JOIN Mistnost m ON k.id_mistnost=m.id_mistnost"; Pak jsem si vytvořil pole, kam budu ukládat části pro parametry vyhledávání. $QueryParts = array(); //části dotazu pro vyhledávání A do něj si podle toho, zdali je parametr ve formuláři zadán či nikoliv, přidával části. Například hledání učitele: if ($_GET['pedagok']) { list($jmeno, $prijmeni) = explode(" ", $_GET['pedagok']); $dotaz.="jmeno='".mysql_real_escape_string($jmeno)."' AND Prijmeni='".mysql_real_escape_string($prijmeni)."'"; $QueryParts[]=$dotaz; $dotaz=""; } Takto jsem si vytvořil seznam kritérií vloţený do pole $QueryParts a následně pomocí php funkce implode sloţil k sobě s oddělovačem AND, který slouţí jako pojítko mezi parametry a udává, ţe hledaný záznam musí splňovat všechna zadaná kritéria. $dotaz.= $volanitabulek; tabulkami //do dotazu se umisti uvodni cast s if (count($queryparts)!= 0){ $dotaz.= " where ".implode($queryparts, " AND "); // pokud jsou v poli nejake polozky, vypisou se a oddeli je AND }