V našem seriálu o ASP nyní změníme trochu koncepci. Jelikož pokládám za hlavní prioritu přehlednost a systematický přístup, bude dnešní článek věnován především nastínění směru našeho dalšího putování.
Vítejte u nové série článků týkající se ASP. V minulých 12 dílech jsme se zabývali především jazykem VBS, tedy jedním z nosných pilířů ASP. V této chvíli předpokládám, že většina základních příkazů, syntaxí a možností Visual Basic Scriptu byla již probrána, a nadešel tedy čas přejít k ASP. Změníme však trochu koncepci. Protože pokládám za hlavní prioritu přehlednost a systematický přístup, bude dnešní článek věnován především nastínění směru našeho dalšího putování.
V prvních dílech jsme se o ASP zmiňovali jako o jakémsi jazyku, který nám dokáže vygenerovat stránky podle přání, vypočte hodnoty, pošle email atd. Jelikož jsme se doposud bavili na úrovni pouhého seznámení, nepokládal jsem za vhodné komplikovat čtenářům hlavu s objektovým programováním. O objektech jsme se zmínili jen velmi zběžně, řekli jsme si pár slov o objektu Response a její metodě Write, ale to bylo skoro vše. V tomto seriálu však budeme o objektech mluvit velmi často.
Koncepce následujících dílů:
- možnosti předávání parametrů (dnes)
- HTML možnosti formulářů (dnes)
- dokončení předávání parametrů a seznámení s objekty
- objekty REQUEST a SESSION z hlediska aplikace předávání parametrů
- podrobný výklad objektu RESPONSE, dokončení
- objekty SERVER a APPLICATION
- objekty ASPERROR a OBJECTCONTEXT
- úvod do databází – objekt ADO
Následující strukturu se pokusím pokládat za směrodatnou, přepokládaný rozsah na probrání těchto témat bude asi 7 článků. Ohledně dalších dílů – nechejme témata dosud otevřená. Bude záležet na vás, milí čtenáři, kam budete chtít nadále směřovat. Každopádně hodlám zařadit problematiku statistiky přístupů, zasílání e-mailů a dalších zajímavé náměty. Snad jen ještě jednu poznámku: byl bych rád, kdyby se tato nová série stala živější ve smyslu vašich reakcí (jsme přece na serveru ŽIVĚ). Názor jiné strany, třebaže kritický, někdy dokáže opravdu motivovat :-) Cílů jsme si stanovili dost, nuže do práce:
Způsoby předávání parametrů
Parametry, tedy proměnné, můžeme předávat následujícími způsoby:
- Pomocí QueryString
- Formuláře - viditelné prvky (INPUT, CHECKBOX, TEXT, RADIO, PASSWORD, FILE, IMAGE)
- Formuláře - skryté prvky (HIDDEN)
- Vlastní sestavení QueryString
- Pomocí session
- Pomocí cookies
- Pomocí binárních souborů nebo databáze
Neexistuje jasná odpověď na otázku, jaký způsob je nejlepší. U malých jednoduchých stránek jistě zvolíme formuláře. Třetí možnost, vlastní sestavení QueryString, je trochu specifický přístup, ale na druhou stranu nám dovoluje proměnné modifikovat, dříve než je pošleme. Můžeme použít například jednoduché zašifrování dat atd.
Session bychom měli použít v případě existence citlivých dat – hesla, případně osobní informace. Session a následující způsoby mají na rozdíl od QueryString velkou výhodu – nejsou uživatelem přímo viditelné (pomineme-li metodu POST, viz dále). ASP nabízí pro session, resp. cookies relativně sofistikované prostředí, takže tyto metody jsou v praxi jednoduše použitelné. Jako poslední jsem si nechal ukládání do souboru, resp. databáze. Jedná se o nejkomplikovanější způsob, který má své výhody i nevýhody. Hlavní výhoda spočívá v absolutní volnosti volby – do databáze můžeme ukládat, co chceme, jak chceme atd. Nevýhodou však je, že tuto metodu musíme často kombinovat se session – pro zabezpečení jednoznačné identifikace daného uživatele.
Klíčový tag pro definici formuláře
FORM obsahuje několik základních parametrů. O parametru
ACTION jsme si řekli minule, dále je tu parametr
ENCTYPE, který definuje způsob kódování. Implicitně se dosazuje metoda
application/x-www-form-urlencoded. Nastavení metody má význam pouze tehdy, pokud použijeme metodu post (viz dále), nebo posíláme formulářem soubory (tag
INPUT TYPE=FILE) – pak nastavujeme metodu
multipart/form-data. Třetí možnost kódování je
text/plain , kterou použijeme pouze při
ACTION obsahující
mailto:. Nejdůležitější parametr je metoda odesílání –
METHOD
Existují dva způsoby odesílání GET a POST. Pokud parametr METHOD vynecháme, použije se implicitně metoda GET. Ta odesílá data, tak jak jsme si řekli v minulém díle, tedy zakódované v relativně čitelném QueryString řetězci. Tato metoda není již na první pohled vhodná na přenos interních dat, jako jsou hesla atp. Obsahuje rovněž velikostní omezení. Ale hlavní nebezpečí hrozí v případě, kdy uživatel experimentuje s parametry, pokud jsou čitelné. Pokud šikovně změní jeden parametr, může se teoreticky dostat na stránky, které mu nejsou určeny. Na druhou stranu metoda GET je mnohdy nápomocna při ladění skriptu – vidíme, jaké parametry jsou předávány. Dovolím si malý postřeh z praxe. Posílání interních dat metodou GET nemusí být vždy tak nebezpečné. Osvědčil se mi následující postup, použitelný samozřejmě jen u jednoduchých stránek, kde tolik nelpíme na bezpečnosti. Citlivá data nepošleme přímo na cílový skript, ale zašleme je na skript, který je zakóduje podle nějakého klíče, a poté se automaticky předáme na cílový skript. Vůbec nepotřebujeme DES šifry nebo jiné podobné složité způsoby šifrování, jako klíč můžeme použít například den v měsíci. Je to velmi jednoduchý a elegantní způsob. Pokud se objeví zájem, rád tento skript uveřejním (i pro jazyk PHP)
Druhá metoda POST již některá omezení a nedokonalosti ruší. Data zasílaná metodou POST jsou uživateli skryta. Informace o přenášených datech nelze zjistit ani vyvoláním vlastností stránky. Dalo by se tedy soudit, že POST je ideální metoda, ale není tomu tak Tuto metodu nelze použít při uveřejňování linků atd. Volba metody by měla vždy záviset na tom, jaký způsob použití stránky předpokládáme. Pro informační a vyhledávací servery asi zvolíme GET, naopak pro elektronické obchody, free-mailové servery, resp. pro skripty přihlášení, autentifikace zvítězí metoda POST.
Zbývá nám probrat možnost vlastního sestavení dotazovacího řetězce. Nepoužijeme tedy klasický formulář, ale pouhý odkaz. Data předáváme tak, jak jsme si již jednou řekli – po názvu skriptu vložíme otazník a poté názvy proměnných s rovnítkem a následnou hodnotou. Problém nastane, když budeme chtít přenést jiný znak než číslici nebo znak bez diakritiky. Pokud se tak opravdu rozhodneme, musíme tyto znaky zkonvertovat. Zkonvertovaný znak „á“ by měl vypadat jako %E1, tedy převedeno na dekadickou hodnotu 225 - tuto hodnotu získáme například programem Mapa znaků. Ale neplatí to pro všechny znaky, např. znak mezera by měl být předán jako znak plus „+“. Všímavý čtenář si jistě vzpomene na předchozí článek věnovaný převodům do šestnáctkové soustavy. Musím ještě jednou zopakovat, že tato možnost je vhodná výhradně pro předávání běžných znaků.
V příští lekci si dokončíme možnosti použití SESSION, COOKIES a souboru. V návaznosti na to se samozřejmě dotkneme objektů. Budu se těšit na vaše reakce.