V pátek jsme sestavili administrátorovi rozhraní pro zadávání koncertů. Pokud jste si to doma zkusili, pravděpodobně jste zjistili, že tomu k dokonalosti ještě něco chybí. Pojďme to tedy dnes trochu vylepšit.

Vylepšujeme administrační část

Především, je tu jeden nedodělek ze zadání. Mezi podmínkami totiž bylo to, že aplikační logika by neměla povolit zadat více než jeden koncert denně, což nám současná verze povolí. Problém lze řešit různě. Jedna možnost je, že před uložením otestujeme, zda dané datum v databázi již není. Něco podobného jsme již dělali v případě přezdívek a mailů při registraci. Tehdy jsme použili dotaz, který zjistil, zda se v databázi zadaný údaj již nevyskytuje a zachová se podle toho.

Jiné dobré řešení je nechat pracovat databázi. Pokud to databázový stroj umožňuje, lze na určitém sloupci definovat tzv. unikátní index. V praxi to znamená, že hodnoty v daném sloupci musejí být navzájem odlišné, jinak databáze nepovolí uložení nebo úpravu záznamu. MySQL tohle umí a příslušný unikátní index přidáte k poli následujícím způsobem:

V praxi se přitom musí dát pozor na dvě věci. Za prvé, databáze nepovolí vytvoření unikátního indexu v případě, kdy již ve sloupci duplicitní hodnoty existují. Na to pozor, potom by to vůbec nefungovalo. Za druhé, pokud sloupec může obsahovat hodnotu NULL, zvažte, zda index dělá to, co zamýšlíte. Výchozí (a správné) chování MySQL (a většiny jiných databází) je to, že řádků s hodnotou NULL ve sloupci s unikátním idexem může být více než jeden. To je logické, pokud si uvědomíte, že jedna hodnota NULL se nikdy nerovná jiné hodnotě NULL. Nás uvedené problémy trápit nemusejí, protože naše tabulka koncertů je zatím prázdná a pole datum je definováno tak, že nesmí obsahovat hodnoty NULL.

Zpracování pak obecně vypadá následovně:

1. Aplikace (v našem případě PHP) sestaví dotaz a pokusí se jej provést "duplicita neduplicita"
2. Databáze si to přebere a buď záznam(y) uloží nebo neuloží
3. Volající aplikace by měla být schopna zachytit a zpracovat případnou chybu z MySQL

Na první pohled může vypadat tohle "spoléhání na databázi" složité, ale má to jednu podstatnou výhodu: Pokud byste do tabulky přidávali řádky z více skriptů (nebo prostě z více programů), nemusíte již pokaždé na omezující pravidla myslet. I když bezpochyby bude v každém programu třeba ošetřit případné chyby, do databáze se vám nikdy nedostanou nežádoucí údaje.

Pozn.: Přenášení částí aplikační logiky na databázi je oblíbené zejména u rozsáhlejších systémů. Vždy to závisí na schopnostech databáze. PostgreSQL je v tomto ohledu mnohem lépe vybavena než naše MySQL.

Skript zadejkoncert.php teď upravíme do podoby, v níž bude schopen zachytit případnou chybu z MySQL. Samozřejmě, že nám nic nebrání v případě výskytu chyby znovu zobrazit formulář. Celé to může vypadat nějak takto:

Pozn.: Ještě jedna záludnost: Popsané řešení dobře funguje u pokusu vložit nebo upravit jeden řádek. Pokud byste ale chtěli podobným způsobem provést v databázi změnu více řádků, bude se MySQL chovat různě podle toho, zda používá nebo nepoužívá úložiště podporující transsakce.

• Pokud jsou transsakce podporovány a narazí se při vkládání nebo při aktualizaci na problém s unikátním indexem, je celé vkládání nebo aktualizace vráceno
• Pokud transsakce nesou podporovány, provedou se všechny aktualizace až do řádku s chybou (ten a všechny následující se již neprovedou)

Toto chování je sice dobře zdokumentováno, ale není příliš intuitivní, takže na to pozor.

Zpětná vazba

Další možnost, jak vylepšit administrační rozhraní spočívá v tom, že se po úspěšném vložení řádku přesuneme na jinou stránku. Tuto techniku jsme již v seriálu probírali, takže jen připomenu, proč je to nutné: pokud bychom zůstali na současné stránce a uživatel by si znovu natáhl stránku do prohlížeče, hrozí opětovné vložení záznamu a v databázi bychom pak měli stejný záznam dvakrát.

Pozn.: Vnímavý čtenář namítne, že to není pravda. Podruhé se záznam nevloží, protože v našem případě selže vkládání kvůli tomu, že v poli datum nastane duplicita a databáze to nepovolí. To je pravda, nicméně měli bychom si osvojit správné návyky při vkládání záznamů bez ohledu na to, zda opakované vložení hrozí či nikoli.

Další důvod pro přesunutí na jinou stránku je psychologický. Namísto lakonické hlášky "koncert byl vložen" je přece mnohem lepší zobrazit stránku s koncerty, aby administrátor na vlastní oči viděl, zda se mu vložení povedlo či nikoli. Tím jsme vlastně odpověděli i na otázku kam by měl být uživatel přesměrován po dokončení akce vkládání řádku. Mělo by to být na stránku se seznamem koncertů.  Odpovídající kód tedy bude:

Jára Cimrman by prhlásil: "Nápad jistě dobrý, výsledky nebyly dobré". Problémem tohoto kódu je, že nebude fungovat. Důvod je prostý - někde v polovině skriptu jsme se pokusili odeslat hlavičku pomocí funkce Header, což zákonitě musí skončit chybou "Cannot add header information - headers already sent". To jsme již v seriálu rozebírali. Co s tím?

Možností je několik: Můžeme izolovat skript pro zadávání koncertů tak, aby se neprováděl jako vložený v souboru index.php, tím si však zcela rozházíme koncepci stránek. Můžeme vložit skript koncerty.php ihned poté, co úspěšně zapíšeme data do databáze, ale tím zase nezbavíme uživatele možnosti pokusit se znovu vložit data refreshováním stránky v prohlížeči!

Řešením jsou tzv. funkce pro řízení výstupu, jejichž význam a použití si probereme příště. Příště rovněž dokončíme skript koncerty.php.

Změny na portálu

Nové soubory:

• koncerty.php (nový soubor, zatím "slepý")

Změněné soubory:

• zadejkoncert.php (upravené ukládání)

Na současný stav projektu se můžete na našem webu podívat nebo si jej můžete stáhnout.

Pozn.: Aby Vám stažená verze fungovala na lokálním stroji, upravte si hodnotu konstant SQL_HOST, SQL_USERNAME, SQL_PASSWORD a SQL_DBNAME. Případně si je můžete včlenit do konfiguračního souboru podobně, jako jsem to udělal v souboru func.php.