Minden olyan űrlap esetében, amelyben a felhasználóktól fontos adatokat várunk, feltétlenül meg kell oldanunk ezek meglétének ellenőrzését, sőt, ha lehetséges, akkor az elküldött adatok szintaktikai és szemantikai vizsgálatát is. Ráadásul akkor lehetünk csak igazán elégedettek munkánkkal, ha az ellenőrzést kliens- és szerveroldalon egyaránt elvégezzük. A kliensoldali vizsgálattal egyrészt sokkal gyorsabban felhívhatjuk a felhasználók figyelmét az elkövetett hibára (ami ráadásul lehet vétlen hiba is, például Enterrel lezárt szövegmező), másrészt ez esetben nem kell a szerveroldalon azzal is foglalkoznunk, hogy a hibás űrlapok visszautasítását követően a már kitöltött adatokat előre betöltsük a megfelelő helyekre. Felhasználóként ugyanis nincs annál bosszantóbb, mint ha egy kis hiba miatt – ami nem is biztos, hogy a mi hibánk – kezdhetjük elölről az egész űrlap kitöltését, mert az oda-vissza út során elvesztek a korábban megadott adatok. Ugyanakkor óvatos és alapos honlapfejlesztőként arra is gondolnunk kell, hogy a felhasználó böngészőjében esetleg valamilyen ok miatt tiltott a JavaScript programok futása, márpedig ez esetben a kliensoldalon semmilyen ellenőrzés nem történik, az adatok bárminemű kontroll nélkül fognak a szerverre érkezni. (De ilyenkor már mondhatjuk azt, hogy nem csak a mi hibánk, hogy az adatok bevitelét ismét az elejétől kell kezdeni.)
Ezúttal is szükségünk lesz egy előzetes „tesztsorozatra”
Reguláris kifejezések – nagyon röviden
Honlapunk programjainak készítése során eddig is használtunk ún. reguláris kifejezéseket (például a hivatkozások kiterjesztéseinek vizsgálatához, vagy a hosszú szöveges mezők számlálóinak és ellenőrzőinek beállításához), azonban eddig ezt nem igazán hangsúlyoztuk. Mint azt hamarosan látni fogjuk, ezek a reguláris kifejezések nagyon hasznosak, és ha kicsit közelebbről megismerkedünk velük, akkor látni fogjuk, hogy jelentősen egyszerűsít(het)ik életünket, ugyanakkor tény, hogy egy-egy összetett reguláris kifejezés összeállítása nem egyszerű feladat.
A teszt ezúttal tényleg test() lesz
A JavaScriptben reguláris kifejezés objektumot kétféleképpen hozhatunk létre, a RegExp konstruktorral vagy / jeleket használva:
var re = new RegExp(kifejezés, attribútumok);
vagy
var re = /kifejezés/attribútumok;
A reguláris kifejezéseket használhatjuk szövegrészletek keresésére (search vagy match), cseréjére (replace), esetleg arra, hogy ellenőrizzük, hogy egy adott szöveg vagy annak egy része eleget tesz-e a megadott feltételeknek (test).
Jeffrey Friedl könyvében közel 500 oldalon ír a reguláris kifejezésekről
A reguláris kifejezésekről a PC World 2008. májusi számban Sümegi András értekezett hosszabban, számos példán keresztül bemutatva ezek lehetőségeit. Azoknak, akik szeretnének még részletesebben elmerülni a reguláris kifejezések világában, ajánljuk figyelmükbe Jeffrey Friedl magyar nyelven is megjelent közel ötszáz oldalas művét (Reguláris kifejezések mesterfokon), azonban – remélhetőleg érthető okokból – mi ennél most egy kicsit tömörebben próbáljuk meg összefoglalni ezek lényegét.
Az általunk használt reguláris kifejezések jellemzően konstans karakterekből, karaktercsoportokból, karakterosztályokból, ismétlés- és pozíciójelölőkből fognak állni. Például a s kifejezés a szóközt (egész pontosan szóköz, tabulátor, sortörés és „kocsi vissza” karaktereket), a w bármely alfanumerikus karaktert (kis és nagybetűket, valamint számokat) és az aláhúzás karaktert, a d bármely számot, ezek nagybetűs változata pedig pont az ellenkezőjüket (nem szóköz, nem alfanumerikus karakter, nem szám) jelenti. A pont (.) a reguláris kifejezések jolly jokere, bármelyik karaktert helyettesítheti.
JavaScript Regex Generator sokat segíthet az első reguláris kifejezések összeállításában
Ezeket, a konstans karaktereket és karakterek tartományát szögletes zárójelek ([ és ])közé zárva azt mondhatjuk meg, hogy ezek közül bármelyik szerepelhet az adott pozícióban, míg a kerek zárójelekkel csoportokba foglalhatjuk a kifejezésrészleteket. Így például a w-t tulajdonképpen írhatnánk úgy is, hogy [a-zA-Z0-9_], a d-t pedig úgy, hogy [0-9], vagy mondjuk egy sakktábla-pozíciót leírhatunk úgy, hogy [a-hA-H][1-8].
Azt, hogy az egyes karakterekből vagy karaktercsoportokból pontosan, legalább vagy legfeljebb mennyinek is kell lennie, az ún. ismétlésjelölőkkel adhatjuk meg. A karakter(csoport) mögé írt kérdőjel (?) azt jelenti, hogy a karakterek nullaszor vagy egyszer jelenhetnek meg a szövegben, a csillag (*) azt, hogy nulla vagy tetszőleges számú darab lehet az így megjelölt karakterekből, míg a pluszjel (+) azt jelenti, hogy legalább egy előfordulás szükséges az adott karakterből, karakterekből. Ezenkívül kapcsos zárójelek ({ és }) között számokkal is jelölhetjük az ismétlődések számát. Például a d{4} azt jelenti, hogy a szövegben pontosan négy számnak kell egymás után szerepelnie, de ha a d után azt írjuk, hogy {2,4} akkor már kettő-, három- vagy négyjegyű számot várunk, míg a d{2,} feltételnek eleget tesz minden szám olyan szövegrész, amiben legalább két szám van egymás után. Például a d{8}(sd{8}){1,2} kifejezés két vagy három számnyolcas csoportot, vagyis egy bankszámlaszámot ír le.
Mint említettük, a fentieken túl ún. pozíciójelölőket is használni fogunk. Ezekkel a kifejezéseket a szöveg egy (vagy több) pontjához igazíthatjuk. Így például a „háztető” karakter (^) a szöveg elejét, a dollár ($) a szöveg végét, míg a b a szóhatárt jelöli. Így a ^[+-]?d+$ kifejezés csak egy pozitív vagy negatív egész számot ábrázoló szövegre fog „illeszkedni”, hiszen a szöveg elején (^) egy plusz- vagy egy mínuszjelnek kell lennie, vagy semminek, hiszen a kérdőjel azt is megengedi, míg utána a szöveg végéig ($) tetszőleges darab számnak kell következnie. Ugyanakkor, ha lehagynánk a dollárjelet a kifejezés végéről, akkor például a „+123a” szöveg is megfelelhetne a fenti feltételnek.
Reguláris kifejezések tesztelése
Hasonlóan a legutóbbi leckénkhez, a munkát ez alkalommal is egy kis teszteléssel fogjuk kezdeni. Tesztoldalunk HTML része nem sokban tér el a múlt havi hasonló célú oldalakétól, ám ezúttal két szövegmezőre lesz szükségünk és a szokásos ‹div›-re, amibe az eredményeket íratjuk ki.
Tesztprogramunkkal ezúttal a reguláris kifejezéseket ellenőrizhetjük
Az oldal inicializáló részében ezúttal egyetlen kontrollhoz sem kell függvényeket rendelnünk, ugyanakkor az űrlap reset eseményéhez hasonlóan a submitet, vagyis az űrlap elküldését is átirányítjuk egy saját függvényre – amiből ráadásul mindig a return false; utasítással lépünk ki, így űrlapunkat sohasem fogjuk elküldeni.
Tesztfüggvényünk nagyon egyszerű lesz. Mindössze annyit fog csinálni, hogy – a szöveg és a reguláris kifejezés meglétének ellenőrzése után – a „regexp” nevű szövegmező tartalmából reguláris kifejezés-objektumot hoz létre (15. sor), majd meghívja ezen objektum test metódusát a „text” nevű szövegmező tartalmával (16. sor vége), és a két szöveget, valamint az eredményt kissé formázva kiírja az erre a célra létrehozott ‹div›-be. Így nagyon könnyen ellenőrizhetjük, hogy a használni kívánt reguláris kifejezés megfelelően működik különböző szövegeken.
A Regular Expression Libraryben szó szerint százával találunk „konyhakész” reguláris kifejezéseket
Így például kipróbálhatjuk, hogy előző példánkban használt ^[+-]?d+$ kifejezés valóban csak egész számok esetén eredményez true választ, minden más esetben az eredmény false lesz. Esetleg kicsit továbbragozva példánkat, a ^[+-]?d+([,.]d+)?$ karaktersorozat már egész és tizedesjegyű számokat is elfogad, sőt, tizedesjelként használhatunk pontot és vesszőt is. (A pontot elviekben használhatnánk önmagában is a szögletes zárójelen belül, de biztos, ami biztos alapon érdemesebb a szabványos . formát használni.)
Közvetlenül a Firefoxban is tesztelhetjük a reguláris kifejezéseket a Regular Expressions Tester kiterjesztés segítségével
Konferenciánk regisztrációs űrlapjában formailag a megadott e-mail címet kell majd ellenőriznünk, ezért nézzük meg, hogyan is néz ki egy ilyen. Az e-mail cím ugyebár áll egy felhasználói és egy domainnévből, amiket egy „@” karakter választ el egymástól. A felhasználói név alfanumerikus karaktereket, aláhúzást, kötőjelet és pontot tartalmazhat, de ez utóbbi nem lehet sem a név elején, sem a végén. Ezt megfogalmazhatnánk úgy is, hogy a név több részből állhat, és ezeket a részeket ponttal kell elválasztani. A reguláris kifejezések nyelvére lefordítva: ^[w-]+(.[w-]+)* – azaz kezdődik egy vagy több (+) alfanumerikus karakterrel, aláhúzással (ez ugyebár benne van a w-ben) vagy kötőjellel, amit követhet egy vagy több (*) hasonló, ám ponttal kezdődő csoport.
Az e-mail cím legalább formailag legyen helyes
A domainnevet nagyon hasonlóan adhatjuk meg, ám erről meg azt tudjuk, hogy egy vagy több hasonlóképpen alfanumerikus karaktert, aláhúzást és kötőjelet tartalmazó csoportot pont zár le, míg az utolsó pont utáni rész (legfelső szintű tartomány, top-level domain, TLD) már csak 2–7 betűből állhat: ([w-]+.)+[a-zA-Z]{2,7}$
Így egy teljes e-mail címet a következőképpen írhatunk le reguláris kifejezésként: ^[w-]+(.[w-]+)*@([w-]+.)+[a-zA-Z]{2,7}$
Ez a kifejezés tökéletesen működik az e-mail címek 99,9 százalékánál és mi is ezt fogjuk használni, ám előfordulhat olyan ritka, ám működő e-mail cím is, amelyet programunk hibásnak jelez. Ugyanis a szabvány szerint az e-mail cím felhasználói név része a már említetteken túl tartalmazhatja a következő karakterek bármelyikét: !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, }, ~. Persze aki ilyeneket rak a „nevébe”, az hamar tapasztalni fogja, hogy a legtöbb űrlapon el fog hasalni.
Hasznos funkciók
Még mielőtt nekikezdenénk űrlapellenőrző programunknak, érdemes létrehoznunk néhány olyan kisebb funkciót, amelyek nagy segítségünkre lesznek a későbbiekben.
A JavaScriptben sok ügyes sztringfüggvényt találunk, ám vannak olyanok, amiket esetleg más nyelvekben megszok(hat)tunk, ám a JavaScriptből hiányoznak. Ilyen például a szövegek elejéről és/vagy végéről a felesleges szóközöket eltávolító Trim függvénycsalád.
A JavaScript lehetőségeit kibővítjük néhány hasznos kis függvénnyel
Nemrégiben ezt a feladatot még úgy oldottuk volna meg, hogy például egy ciklussal elindulunk a sztring karakterein, megkeressük az első (vagy az utolsó) nem szóköz karaktert, majd a substr függvénnyel levágjuk az előtte (utána) levő részt. De most, hogy már kezdjük megismerni a reguláris kifejezéseket (és a hozzájuk kapcsolódó metódusokat), a feladatot meg tudjuk oldani egyetlen utasítással. Az str.replace(/s*((S+s*)*)/, "$1") függvény ugyanis eltávolítja az str elejéről az összes szóközt, sőt, a sztringben található dupla szóközöket is (28. sor), míg az str.replace(/((s*S+)*)s*/, "$1") függvény a sztring végén lévő szóközöket tünteti el (29. sor). (A replace függvény második paramétereként szereplő $1 a reguláris kifejezés első csoportját adja vissza.) Ha pedig szeretnénk a kapott szövegek elejéről és a végéről is eltávolítani a szóközöket, akkor szépen egymás után hívjuk meg előbb az egyiket, azután a másikat (30. sor).
A kérdőívek ellenőrzésekor az egyik tipikus feladat annak vizsgálata, hogy a kötelezően kitöltendő mezőkbe írt-e a felhasználó valamit vagy sem – és nem biztos, hogy jól tesszük, ha elfogadjuk a csak szóközökből álló választ. Éppen ezért az IsEmpty függvényünk nem azt nézi meg, hogy a paraméterként kapott sztring üres-e (már ha egyáltalán létezik), hanem azt, hogy szóközöktől megtisztítva üres lesz-e (34. sor).
Abban az esetben, ha nemcsak azt figyeljük, hogy írtak-e valamit egy adott mezőbe, hanem azt is, hogy mit, akkor sem árt, ha a szövegmező értékét megszabadítjuk a felesleges szóközöktől. Így például, amikor azt vizsgáljuk meg, hogy formailag helyes-e a megadott e-mail cím, akkor nem simán a sztringet nézzük meg az e-mail cím reguláris kifejezéssel, hanem a „megtisztított” változatot (39. sor). Hisz a kézbesítés nagy valószínűség szerint ugyanúgy hiba nélkül meg fog történni akkor is, ha egy szóközzel kezdődő vagy arra végződő címet adunk meg az elektronikus (hír)levelet küldő programunknak – arról nem is beszélve, hogy az adatok eltárolásakor szintén nem árt, ha eltávolítjuk a felesleges szóközöket.
Ugyan jelen űrlapunk esetében nem fogjuk használni, azonban érdemes egy kicsit alaposabban megnézni a lemezmellékleten is megtalálható program – kicsit korábban megbeszélt reguláris kifejezéseken alapuló – IsInteger (42-45. sorok) és IsNumber (47-50. sorok) függvényeit. (A csak számokat elfogadó mezőink ugyebár más karaktert el sem fogadnak.)
Gyűjteményünkben még jól jöhet egy-két egyszerű ellenőrzőfüggvény
Az IsDate függvény (52-55. sorok) igazából nem azért érdekes, mert hosszabb még az e-mail címet ellenőrző reguláris kifejezésnél is, hanem azért, mert a 2-es visszahivatkozásnak köszönhetően a hónapot és a napot elválasztó karakterként csak ugyanazt fogadja el, amit a felhasználó az év és a hónap elválasztására használt. Így egyaránt helyes lesz a „2009.11.04”, a „2009-11-04” és a „2009/11/04” formátumú dátum, de a 2009.11/04 vagy a 2009-11.04 már nem. Ha pedig biztosak akarunk lenni abban, hogy a dátumok részeit mindig pont választja el, akkor használjuk nyugodtan a CorrectDate függvényt, ami még a „vegyes elválasztású”, ám egyéb szempontból helyes dátumokat éééé.hh.nn formára alakítja.
E sztringfüggvényeken túl szükségünk lesz még egy „segédfüggvényre”, ami a getElementsByTagName mintájára nem (csak) az adott típusú, hanem a megadott osztályú objektumokat is összegyűjti egy tömbbe. A getElementsByClass függvénynek mindenképpen meg kell adnunk, hogy milyen osztálynevű elemek érdekelnek minket. Ezenkívül a listát szűkíthetjük azzal, hogy megmondjuk, hogy milyen típusú objektumokat keressük, valamint azzal is, ha meghatározzuk, hogy melyik objektum gyermekeivel akarunk csak foglalkozni. Ha nem adjuk meg a szülőobjektumot, akkor a teljes dokumentumban fogunk keresni (71. sor), ha pedig nem adunk meg típust, akkor a függvény minden objektumot meg fog vizsgálni (72. sor).
Új funkciónk összegyűjti az adott osztálynevű objektumokat
A kezdeti ellenőrzéseket követően töltsük be egy tömbbe a szülőobjektum valamennyi meghatározott típusú elemét (74. sor), majd ezeket egyesével vizsgáljuk meg, hogy az osztálynevükben szerepel-e a keresett név (78. sor). Ráadásul az osztálynév elé és mögé illesztett b jelölők miatt (a dupla azért kell, mert különben a sztringben a b helyett egy Backspace karakter jelenne meg) névtöredékek nem fogják becsapni függvényünket, az elements tömbbe tényleg csak azok az elemek kerülnek be, amelyek nevében megtalálható a paraméterként kapott osztálynév.
Az űrlap ellenőrzése
Természetesen ahhoz, hogy elvégezhessük az ellenőrzést, az űrlapküldést megelőzően el kell indulnia programunknak, amiről a 627. sorban található ismerős megoldás fog gondoskodni.
A böngészőnek mondjuk meg, hogy a gombok megnyomásakor mely funkciókat kell elindítania
Az ellenőrzéshez szükségünk lesz két reguláris kifejezésre, amelyek segítenek megkeresni nekünk a kötelezően kitöltendő (required) és az e-mail címe(ke)t tartalmazó mezőket (342-343. sorok). A vizsgálat során végigmegyünk az űrlap összes elemén (347. sor), de a kitöltöttségét csak azoknak fogjuk ellenőrizni, amelyek osztálynevében szerepel a required szó (350. sor).
Elküldése előtt megnézzük, hogy jól töltötték-e ki az űrlapot
Miután előfordulhat, hogy nem először fut le az ellenőrzés, ezért – feltételezve, hogy azóta a felhasználó kijavította a hibát – tüntessük el a korábban kitett hibaüzenetet. Oda kell figyelnünk arra, hogy a rádiógombok esetében nem közvetlenül a kontroll, hanem az objektumcsoportot összefogó lista mögé helyeztük el a hibaüzenetet (352–355. sorok).
A hibaüzenetek megjelenése legyen kellően feltűnő
Ezt követően először nézzük meg azt, hogy az aktuális űrlapkontroll szöveges elem-e, és ha igen, akkor üres-e (a csak szóközökből álló tartalom is üresnek minősül), vagy nem az az alapértelmezett érték van-e benne, amit két hónapja „kitöltési útmutatóként” helyeztünk el (357. sor). Ha a válasz az utóbbi két kérdés közül bármelyikre igen, akkor a showFormError függvény által hozzunk létre egy új formerror osztályú bekezdést (amit a CSS-ben természetesen időben megformázunk, hogy kellően figyelemfelkeltő legyen), abba írjuk be a megfelelő hibaüzenetet, majd helyezzük el a szövegmező után (393–399. sorok).
A hibaüzenet lehet egy „standard” szöveg is (pl. „Töltse ki ezt a mezőt!”), de megtehetjük azt is, hogy – az alapértelmezett értékekhez hasonlóan – létrehozunk egy errMsg nevű kvázi asszociatív tömböt, amiben bármely kontrollhoz létrehozhatunk egy saját hibaüzenetet, ezzel is némiképp barátságosabbá téve űrlapunkat.
Az „egyéni” hibaüzeneteket az alapértelmezett értékekhez hasonló tömbben tároljuk
Miután létrehoztuk a hibaüzenetet, megnézzük, hogy találtunk-e már korábban hibát, vagy ez az első. Ha ez az első hiba, akkor el is tároljuk a firstBadElem változóba (360. sor). Így nem csak, hogy a végén tudni fogjuk, hogy találtunk-e hibát az ellenőrzés során (384. sor), de rá is tudunk majd állni az első hibás kontrollra (385. sor).
Valamivel elegánsabb, ha az egyes mezőkhöz egyedi hibaüzenetek tartoznak
Abban az esetben, ha az éppen vizsgált űrlapkontroll nem szöveg, hanem lista (a ‹select›-ből select-one, vagy ha engedélyezett a többszörös kijelölés, akkor select-multiple lesz), és az értéke üres, akkor hasonlóképpen járunk el, mintha szöveges kontroll lenne, csak az alapértelmezett hibaüzenet kicsit más.
Ahogyan szinte mindig, a rádiógombokkal ezúttal is némi gond van. Ugyanis ezeknél nem azt kell megvizsgálnunk, hogy mi az értékük, hiszen azt mi állítottuk be a HTML-ben, és a felhasználó ezen nem is tud változtatni, hanem azt, hogy az azonos nevűek közül valamelyiket kiválasztották-e. Ezt végzi el nekünk a radioValue függvény (408-420. sorok), ami betölti egy tömbbe az összes ‹input› elemet, majd végignézi az összeset, hogy talál-e ezek között olyan rádiógombot, amelyik neve megegyezik az aktuálisan vizsgáltéval és ráadásul ki is van jelölve (413. sor). Ha talál ilyet, akkor felfüggeszti a további keresést, és visszaadja a megtalált rádiógomb értékét. Így ha a felhasználó már választott a rádiógomb-csoportból, akkor jó, ha nem, akkor tegyünk ki egy hibaüzenetet a lista mögé. A dolognak kis szépséghibája, hogy mindezt annyiszor, ahány tagja van a csoportnak, de szerencsére ebből a felhasználó semmit nem fog észrevenni, csak azt, hogy kapott egy hibaüzenetet – és hogy a böngésző nem küldte el a kérdőívet.
Ha az épp vizsgálat tárgyát képező kontroll osztálynevében szerepel az email is (376. sor), akkor azért előbb nézzük meg, hogy biztosan szöveges mező-e, kitöltötték-e, de nem az alapértelmezett szöveget tartalmazza (ha üres, és ki kell tölteni, akkor amiatt már úgyis szóltunk). Ha eddig minden kérdésünkre pozitív választ kaptunk, akkor – és csak akkor, mivel a JavaScript balról jobbra értékeli ki a feltételeket – az IsEmail függvénnyel nézessük meg, hogy tényleg úgy néz-e ki, ahogy egy rendes e-mail címnek ki kell néznie – és ha nem, akkor ezt jelezzük a felhasználónak (378. sor).
A CheckForm függvény végén – ahogyan azt fentebb már említettük – vizsgáljuk meg, hogy volt-e hiba az ellenőrzés során. Ha volt, akkor jelöljük ki az első hibásnak talált kontrollt (385. sor), és false értéket visszaadva (386. sor) akadályozzuk meg az adatok elküldését az űrlap action attribútumában szereplő címre. Ha nem volt hiba, vagyis a firstBadElem értéke még mindig null, akkor a true érték visszaadásával (388. sor) jelezzük, hogy mindent rendben találtunk, az adatok elindulhatnak a szerver felé.
Mostantól kezdve a kötelező adatokat valóban kötelező kitölteni
Adatok törlése
Egy átlagos – unalmas és barátságtalan – kérdőív esetén az Adatok törlése gomb megnyomásakor a böngésző törli a szövegmezőket és alaphelyzetbe állítja a jelölőmezőket és a rádiógombokat. Nekünk azonban arról is gondoskodnunk kell, hogy szépen kiszürkítsük, azaz deafult osztályúvá tegyük az alapértelmezett értékkel bíró szöveges mezőket – és eltüntessük az esetleges hibaüzeneteket.
Az űrlap adatainak törlésekor – és az alapértelmezett értékek visszaállításakor – a hibaüzeneteket is törölnünk kell
Ezért korábbi kérdőív-resetelő függvényünket emeljük ki az initPage-ből, és egészítsük ki azzal, hogy a kimondottan e célból létrehozott getElementsByClass függvénnyel gyűjtsük össze a form összes formerror osztálynevű bekezdését – majd távolítsuk el a dokumentumból.
A cikkben bemutatott oldalak és programkódok letölthetők innen.
