Weblabor

A Javascript ma minden bizonnyal reneszánszát éli, kezd felnőni a feladataihoz. Köszönhető ez a hozzáférhetőségre egyre nagyobb figyelmet helyező fejlesztőknek, talán a CSS-nek, s minden bizonnyal annak, hogy az elterjedtebb böngészőkben már jól használható a DOM szabvány. A cikkben, mely a PHP Konferencia előadásomra épül, a diszkrét Javascript témakörét fogjuk körüljárni, azaz megnézzük: hogyan használhatjuk úgy ezt a technológiát, hogy senkinek se okozzunk hátrányt vele.

Talán senkinek sem kell bemutatni: a Javascript egy programozási nyelv, melyet eredetileg LiveScript néven fejlesztettek ki a Netscape mérnökei, de azóta EcmaScript (a címen további részei is vannak) néven szabványos nyelv lett belőle, s az elterjedt grafikus böngészőkben megtalálható. Létezik szerver oldali és önálló, "asztali" megvalósítása is, PDF dokumentumokat is programozhatunk vele vagy akár Firefox kiterjesztések is létrehozhatóak segítségével, de ezekre nem fogunk kitérni, csakis a böngészőkben levő használatára fogunk szorítkozni. Illetve arra, hogy ezt hogyan tegyük úgy, hogy az mindenkinek jó legyen.

A Javascript egy objektum-orientált nyelv, számos előre definiált objektum áll rendelkezésünkre a böngészőkben, így egy weboldal egészéhez hozzáférhetünk, így kiegészíthetünk és megváltoztathatunk benne, illetve eltávolíthatunk belőle részeket. A weblapon belül szabadon garázdálkodhatunk, ennek minden előnyével, s hátrányával együtt.

Beszéljünk egy kicsit a hátrányokról! Ha a Javascriptet rosszul használjuk egy oldalon, s azt feltételezzük hogy a böngésző ismeri: hibát követünk el, hacsak nem vagyunk 100% biztosak benne, hogy igazunk van, például egy ismert böngészőket használó intranet hálózati megoldás esetén. Ha az internetre fejlesztünk, nem feledhetjük el annak változatosságát: van, aki nem grafikus böngészőket használ, van, aki biztonsági okokból letiltja a Javascriptet, s van, aki valamely testi fogyatékosságának okán nem is tud olyan böngészőt használni, mely támogatja azt. Ha a navigációt, az oldal valamely fontos szolgáltatását kizárólag Javascriptre építjük, hibát követünk el. A Javascript ezen használati módját hívhatjuk "tolakodó" Javascriptnek. Olyan megoldásnak, amivel látogatóink egy részét kizárjuk oldalunk használatából.

Itt kell megemlítenem a webalkalmazásokat (böngészőben használható, az asztali alkalmazásokhoz hasonlító webes programok), melyeket ha közelebbről megnézünk, bizony ilyen megoldások: csak bizonyos böngészőkkel működnek, nagy részben támaszkodnak a Javascript adta lehetőségekre, stb. A webalkalmazások célközönsége azonban általában nem mindenki, hanem egy meghatározott célcsoport, akik rendelkeznek ezekkel a kívánalmakkal felszerelt böngészővel (például egy oldal adminisztrátorairól van szó). Ha ez mégsincs így, s egy olyan alkalmazást készítünk, melynek célcsoportja a lehető legtöbb internetező, akkor két választásunk van: vagy megbarátkozunk a gondolattal, hogy mégsem tud a célcsoportunk a teljes internet lenni, vagy pedig valamilyen alternatív megoldást kínálunk, mely nem bír az összes szolgáltatással, amit a Javascriptre épülő társa tud, de a kínált funkcionalitás elérhető. Ezt a megoldást választotta a Google is a GMail esetén: kínálnak egy hagyományos felületű alkalmazást is, mely akár Javascript nélkül is használható. Ha ezt választjuk, próbáljuk meg ezt úgy tenni, hogy ne kelljen dupla munkát végeznünk. Erről is szó lesz a következőkben.

Felugró ablakok

Nézzünk meg egy egyszerű példát, egy popup ablak megnyitását. Az itt bemutatott megvalósítás több szempont miatt is rossz, ne használjuk!Miért rossz? Mert a megvalósításhoz egy olyan megoldást használ, amely csak akkor működőképes, ha a kliensnek van Javascript támogatása. Mert egy kereső robot nem fogja tudni felismerni a linket, a popup ablakunkat nem fogja tudni leindexelni. Ez miért probléma? Előfordulhat, hogy valaki egy karakteres böngészővel, például Lynxet vagy Links-et használva próbálja meg megtekinteni az oldalt. Nos, ekkor csak bűvészkedve, az oldal forrását megtekintve fog tudni hozzáférni a popup ablak tartalmához. A tapasztalatok szerint a weblapok látogatóinak körülbelül 1%-a ebbe a kategóriába tartozik. Erre lehet mondani, hogy ez egy olyan kis szám, mellyel felesleges foglalkozni. Egészen addig, amíg elő nem fordul, hogy az egyik potenciális nagy megrendelő pont emiatt át nem megy a konkurenciához. Hogy ennek kicsi az esélye? Ki tudja. Mindenesetre én nem emiatt dobnám el a későbbiekben bemutatandó kifejezetten egyszerűen használható megoldást. És akkor nem beszéltem a keresőrobotokról sem, melyeket ha kizárunk így a tartalom eléréséből, akkor szintén csökkenni fog látogatottságunk. Egy weblap több százaléknyi látogatóját (akár több tíz százaléknyit) is hozhatnak keresők, ez sem egy lebecsülendő érv tehát.

De térjünk vissza arra, hogy hogyan lehetne a fenti kódon javítani? Sok helyen a következő, szintén hibás megoldást szokták javasolni:Itt a link nem mutat sehova (pontosabban az aktuális dokumentum elejére mutat). Javascriptet támogató böngésző esetében az ablak megnyílik, majd a return(false); visszatérésnek köszönhetően az eredeti esemény nem fut le, azaz nem ugrik a dokumentum elejére a böngészőnk. Az előbb felvázolt két problémát viszont nem oldottuk meg: Javascript nélkül továbbra is működésképtelen a megoldás.

Egy teljes, jól használható megoldás a következőképpen nézhet ki:Bekapcsolt Javascript esetén az előző megoldással teljesen megegyező eredményt kapunk, míg ha a Javascript nem támogatott, vagy ki van kapcsolva, a link akkor is működni fog. Mind a felhasználó, mind a kereső robot el tud jutni a popup ablakhoz, s meg tudja tekinteni a tartalmát. Ez jó. Ennyi volt? Nem: a probléma diszkrét Javascript megoldása esetén ez még csak a feladat egy része volt.

Diszkrét Javascript

A diszkrét Javascript azt mondja, hogy a HTML kódunkban ne használjunk Javascriptet, válasszuk le, s tegyük külön fájlba teljesen scriptjeinket, s építsük fel úgy az oldalt, hogy azok nélkül is teljes funkcionalitással bírjon - maximum nem olyan kényelmesen. Ismerősnek tűnhet az ötlet: a mai modern CSS technikák pontosan ezt mondják a stíluslapok esetén is: válasszuk szét a megjelenést és a tartalmat. A Javascript esetén a tartalom, s a használhatósági javítások szétválasztásáról van szó. A HTML azt mondja meg, mi ez a szöveg, a CSS azt, hogy hogyan nézzen ki, a Javascript pedig azt, hogy hogyan viselkedjen (az oldal). A Javascript egy nagyon jó eszköz a weblapok használhatóságának növelésére.

A diszkrét Javascript bár első ránézésre nem biztos, hogy így tűnik, a fejlesztő dolgát nem nehezebbé teszi, hanem megkönnyíti. Térjünk vissza a példánkhoz, s nézzük meg, hogyan alakul a popup ablakok sorsa.

A HTML kódunk nagyot fog egyszerűsödni:

Diszkrét felugró ablakok

A titok nyitja a class megadása. Ahova ilyet teszünk a HTML forrásunkba, popupként fog megnyílni. Ugye milyen egyszerű? Nem kell extra Javascriptet írnunk sehova, csak egy egyszerű jelzés, s máris működik minden, ahogy szerettük volna. S CSS-ből akár még más stílust is adhatunk az ilyen linkeknek (például egy kis felugró ablakot stilizáló ikonkát kitéve ezen linkek mellé). Természetesen ehhez egy kicsit fejlesztenünk kell. De csak egyszer.

A háttérben futó Javascript nem fog mást tenni, mint az oldal betöltődése után végigmegy az összes popup osztályba (class-ba) sorolt elemen, s azoknál melyek href tulajdonsággal is rendelkeznek (biztos, ami biztos), beállítja hogy a kattintást (onclick) kapják el, s nyissanak meg egy ablakot. Ez nem olyan nehéz mint amilyennek tűnhet. A DOM függvényeket fogjuk használni a feladathoz, konkrétan a getElementsByTagName függvényt, s egy kis ciklust. Hogy egy kicsit általánosabb legyen a megoldásunk, bevezetünk egy getElementsByClass függvényt a getElementById DOM függvény mintájára. Egy tömböt fog visszaadni az összes olyan elemmel, mely egy adott osztályba lett sorolva (a class) tulajdonsággal. Íme a függvény:A függvényünk régebbi böngészőkben nem működik - ez ellen lehet tenni kisebb kiegészítésekkel -, de ezt az olvasóra bízzuk, itt és most az érthetőségre törekszünk (és az egésznek ugye pont az a lényege, hogy nincs semmi baj, ha valaki olyan böngészőt használ, mely nem támogat valamilyen lehetőséget: a legrosszabb, ami megtörténhet, hogy nem felugró ablakban nyílik meg a link...). A függvény létrehoz egy tömböt, lekéri az oldalon levő összes elemet (ezt esetünkben, ahol csak linkeket kerestünk, szűkíthettük volna csak a elemekre), majd végigmegy rajtuk, s azokat, melyek a paraméteréül kapott osztályúak, beleteszi a tömbbe. Ezzel a tömbbel visszatér.

A fenti függvényen kívül egy másikat is használni fogunk, melynek az addEvent nevet fogjuk adni:Ez a függvény egy adott böngésző objektum egy adott eseményéhez csatol hozzá egy adott függvényt, melyeket paraméteréül kap. Mint látható a kódból, sajnos a böngészők kapcsán nincs egység a megvalósítás terén, de nem árt, ha tudjuk, hogy a szabványos megoldás a W3C DOM szabványa szerint az addEventListener. Objektum alatt általában egy HTML elem böngészőbeli leképezését szoktuk érteni, így egy linkről, vagy az oldal window eleméről is szó lehet (ez utóbbi a <body> elemmel ekvivalens, amennyiben a load eseményét szeretnénk kihasználni). Második paraméternek az esemény nevét kell megadni, mely szintén sokminden lehet, így egy click, azaz kattintás esemény. A konkrét alkalmazást mindjárt látni fogjuk, de a függvényről még tudni kell, hogy nagy előnye: egy bizonyos elem egy bizonyos eseményéhez akár több függvényt is hozzárendelhetünk, szemben azzal a Javascript megoldással, ahol egy objektum onclick tulajdonságának állíthatunk be egy darab függvényt (objektum.onclick=fuggveny).

Ezután nincsen más dolgunk, mint végigmenni az első függvényünk által kapott elemeken, megnézni, van-e href tulajdonságuk, melyek nem üresek (nehogy egy popup osztályú div elemre állítsuk be a felugró ablakként működést), s ha igen, akkor beállítani a kívánt viselkedést. Íme:A kívánt viselkedés itt a doPopup függvény meghívása lesz. Ez a függvény a következőképpen néz ki:Ha a doPopup függvényt közelebbről megnézzük, a lényegét tekintve nagyon hasonlít ahhoz a Javascript kódhoz, melyet az onclick tulajdonságba írtunk be nem is olyan rég: nem tesz mást, mint megnyit egy ablakot. Négy különválasztható részből áll, melyek egy részét ha jobban beleássuk magunkat a témába, célszerű külön függvényként megvalósítani. Az első részben az ev objektumot keressük meg. Elvileg a függvény paramétereként érkezik, de Internet Explorer alatt egy "globális" változót kiolvasva juthatunk hozzá. Ezután meghatározzuk, mely objektum váltotta ki az eseményt - ez is böngészőfüggő módon történik (ha ez sikertelen, akkor be is fejezzük a futást). A window.open megnyitja az ablakot, végül pedig arról gondoskodunk, hogy a bekövetkezett eseményt más már ne kezelje le, konkrétan ne nyíljon meg az eredeti ablakban a linkelt oldal.

Nos, ezután egy dolgunk maradt, valahogy elérni, hogy az oldal betöltődése után elinduljon a classPopupHandler függvényünk. Ehhez a következő sort kell hozzáadnunk Javascriptünkhöz:És ezzel be is fejeztük a fejlesztést, ha betöltjük az oldalunkhoz ezt a külső Javascript fájlt, teljesen automatikusan elvégzi a dolgát.

Továbbfejlesztési lehetőségek

Ha egy kicsit gondolkodunk a működésen, több dolog is felmerülhet bennünk. Hogyan mondhatjuk meg, hogy mekkora legyen a felnyíló ablak? Szabályozhatjuk-e, hogy megjelenjenek a görgetősávok az ablakban, vagy ne? Ha nem popup ablakot szeretnénk megnyitni, más jellegű paraméterezési lehetőség is előjöhet, hogyan oldhatjuk ezt meg? Nos, több válasz is van a kérdésre.

A beállításokkal törődjön a felugró ablak maga

A felugró ablak döntse el saját maga, hogy mekkora szeretne lenni, szeretne egy görgetősávokat, stb. Ezt Javascripttel, illetve CSS segítségével meg lehet oldani. Előnye, hogy bármennyi méretünk lehet, van azonban hátránya is. Az ember nem szereti a felugró ablakokat (ez más téma, most nem térnék ki rá), de ha még át is méreteződik egy ilyen ablak, főként, ha például a böngészőben azt állította be az ember, hogy ez egy új fül legyen, nos, az még zavaróbb lehet. Még ha ez nem is lenne baj, akkor sem néz ki szépen az a folyamat, amikor megnyílik egy nagy ablak, s egy kisebbé ugrik össze. De van más lehetőség is.

Nem kell paraméterátadás

Ha a diszkrét Javascriptet szeretnénk megérteni, forduljunk bátran a modern CSS nézőponthoz! Hogyan jön ide a CSS? A következőképpen: egy általános szabály ott, hogy ne a megjelenéshez, hanem a funkcióhoz definiáljunk CSS stílusokat. Ne legyen pirosbekezdes, kekbekezdes osztályunk, hanem legyen figyelmeztetes és informacio nevű. Ha közelebbről megnézzük, a piros és kek része az előbbi osztályneveknek paraméterként értelmezhető. Ez azonban a későbbiek folyamán megváltozhat, s lehet, hogy nem is piros színű lesz az a bekezdés, vagy a piros színen kívül mást is be kell állítanunk. Nos, a helyzet ugyanez a Javascript esetén is. Ha különböző viselkedést szeretnénk, definiáljunk különböző osztályt hozzá. Ha ezután megváltozik a feladat, s egy kicsit nagyobb ablakot kell megynyitni, akkor nem a HTML forráshoz, hanem a Javascripthez kell hozzányúlnunk. És ez a lényeg: egy olyan réteg bevezetése, mely egy központi helyen teszi menedzselhetővé a feladatokat.

Ha mégis kell

Ha ennek ellenére mégis szükség lesz paraméterátadásra, többféleképpen járhatunk el (de tényleg gondolkodjunk el, szükség van-e erre!). Íme a lehetőségek:

• az osztályba vegyük bele a paramétereket (href="/popup.html" class="popup 320 200")
  
• definiáljunk saját tulajdonságokat (href="/popup.html" class="popup" width="320" height="200")
  
• adjuk meg a link paramétereiként a tulajdonságokat (href="popup.html?width=320&height=200" class="popup")
  

Lássuk, melyik miért jó, miért nem jó!

Az osztályba történő paraméter bevétel látványos, de a HTML szabvány szellemiségéhez nem kifejezetten passzol. Az osztály tulajdonság akármennyire is szép megoldásnak tűnik a fenti, de nem arra van, hogy paramétereket adjuk át általa. Ez bármely más tulajdonság esetében is hasonlóképpen lesz, a HTML-ben nincs erre alkalmas tulajdonság. Egy további probléma, hogy opcionális paraméterek átadása ebben az esetben csak megkötésekkel, körülményesen lehetséges (kötött a paraméter sorrenddel).

A saját tulajdonságok használata szintén egy tetszetős megoldás, a szabvány szellemiségével sincsen baj, "csak" a szabvánnyal magával ütközik, ugyanis ilyen paraméterek nincsenek benne. Egy megoldás lehet az, hogy saját DTD-t definiálunk, s ebben az esetben a kódunk is helyes lesz, a paramétereket is át tudjuk adni. Ez egy megoldás lehet, bár elég körülményes.

A harmadik lehetőség, ahol a linkhez valódi paramétereket rendelünk, egy ötletes és szép megoldás a problémára. A felugró ablakot nyitó kód kiolvashatja ezeket a paramétereket, akár le is szedheti a linkről, tehát megoldhatja, hogy a megnyitott ablaknak (Javascript támogatás esetén) már át se adódjanak. Ezzel a technikával akkor lehet gond, amikor a diszkrét Javascript technikát nem egy link esetében szeretnénk alkalmazni, ekkor ugyanis nem áll rendelkezésünkre href tulajdonság, aminél beállíthatjuk ezeket.

Hogyan legyünk diszkrétek?

A diszkrét Javascript ismérvei a korábbiakban már elhangzottak. A példa kapcsán megismerhettük, hogy hogyan kell ennek jegyében megnyitni egy felugró ablakot, de természetesen ennél jóval többet nyújt ez a filozófia, technika. Erről még írok. De nézzük át, hogy miket kell elsajátítanunk, illetve hogyan kell gondolkodnunk ahhoz, hogy ennek ezen technológia jegyében készítsük el oldalunkat!

Javascript nélkül, vele, s az átmenet a kettő között

Gondoljuk végig, hogy milyen funkciót szeretnénk megvalósítani, s ez ha van Javascript hogyan nézne ki. Ha ez megvan, akkor pedig azon gondolkodjunk el, hogy lehet egy ehhez legjobban közelítő funkciót megvalósítani, de immár Javascript nélkül. Mindezt úgy, hogy az oldal manipulációjával a Javascript nélküli esetet át tudjuk alakítani (Javascript segítségével) az eredetileg elképzelt megoldásra. Ha ez megvan, talán ez a legnehezebb akkor a legfontosabbal meg is vagyunk.

Vegyünk egy példát: a feladat az, hogy ha egy beviteli mező fölé megyünk, jelenítsünk meg egy rövid súgószöveget hozzá egy div elem segítségével. A Javascript feladata itt a mező fókuszba kerülésekor és annak elvesztésekor ennek a div elemnek a megjelenítése, illetve eltüntetése lesz. A funkciót tehát elképzeltük. Hogyan jelenítenénk meg egy súgót akkor, ha nem Javascripttel szeretnénk megoldani a feladatot? Például úgy, hogy a beviteli mező alatt minden különösebb bonyolítás nélkül kiírjuk a szöveget.

Hogyan közelíthető egymáshoz a két megoldás? A Javascript kód megkeresi az oldal összes beviteli mezőjét, s megnézi, van-e hozzá súgószöveg. Például a súgószöveget tehetjük egy div elembe, aminek az azonosítójának az eleje megegyezik a beviteli mező azonosítójával, a vége pedig _help, vagyis ha a beviteli mező azonosítója name, akkor a hozzá tartozó súgóé name_help. A megtalált div elemeket elrejti a Javascript, majd a beviteli mező focus és blur eseményéhez egy megfelelő kódot rendel. Ezek fogják a súgó szöveget megjeleníteni, illetve elrejteni, amikor azt kell.

A feladat megoldva. Vegyük észre, hogy a felugró ablakos példával ellentétben itt nem használtunk osztályokat, itt másképp jelöltünk meg elemeket, hiszen azokat hozzá is kellett rendelni egy beviteli mezőhöz. A viselkedési réteget jelentő diszkrét Javascript megoldás nem konkrét problémákra kíván megoldást, hanem általános szemléletmódot kínál.

Használandó technológiák

A legfontosabb felhasznált technológia a W3C DOM. Ez egy hozzáférési módszert, eljárásokat, tulajdonságokat definiál. Az újabb böngészőkben használatos Javascript ezt a szabványt megvalósítja, s így a HTML (vagy éppen megtekintett más dokumentum, például XML) esetén ahhoz a DOM keretében hozzáférési, s manipulációs lehetőséget kínál. Magát a szabványt, s annak különböző verziót jó, ha megismerjük, de nem árt tudnunk, hogy az egyes böngészőknek (a legmodernebbeknek is) vannak elmaradásaik.

A diszkrét Javascripthez ezen kívül javasolt ismerni a CSS lehetőségeit (megjelenítés, elrejtés), s azt, hogy hogyan férhetünk az oldal s egyes elemeinek CSS-éhez hozzá Javascriptből.

Ha szép megoldásokat szeretnénk készíteni, jó ha ismerjük a Javascript lehetőségeit, s a HTML célját, lehetőségeit, s a szabványt és annak szellemiségét is.

A fenti technológiák egyáltalán nem bonyolultak, de ha nem is ismerjük mindet, akkor is van merre elindulnunk, ahogy a felugró ablakoknál láthattuk, kis lépésekből egy kényelmes és célszerű megoldást állíthatunk össze.

Mire jó még?

A diszkrét Javascript lehetőségeinek száma végtelen, legalábbis annyira, amennyire a CSS biztosít ezer és egy megjelenési lehetőséget egy oldalhoz. Nincs szó új technológiáról, nincs szó új célokról, a fentiekben "csak" egy viszonylag új szemléletmód bemutatására került sor.

További két lehetőséget felsoroltam előadásomban is, az egyik a textareaknak wyswiwyg osztály beállításával HTMLArea szerkesztővé történő átalakításáról szólt, a másik módszer pedig a Weblabor oldalain használt fülek kialakításának kapcsán mutatatta be a diszkrét Javascriptet.

Bármilyen meglepő, a Weblabor oldalain is mutattunk már be a diszkrét Javascript filozófiájára építő technikát, mely a Dinamikus betűméret választásba nyújtott betekintést. Ebben az esetben a "kezelőszerveket" akkor tettük csak ki, ha volt Javascript támogatás a böngészőben, vagyis csak akkor, amikor használni lehetett ezt a funkciót - egy extra viselkedést tettünk ezzel a módszerrel elérhetővé, ha pedig nem volt rá lehetőség, mint ha ott se lett volna, nem zavartak senkit a nem működő gombok.

Bízom benne, minden olvasó kedvet kap ehhez a szemlélethez, hiszen számos szempontból hasznos, s egy jobban működő webet is eredményez. Ha valakinek van ötlete, példája, hogy mire használta már ezt a megoldást, szívesen venném, ha megosztaná hozzászólás formájában, illetve ha tud róla egy hosszabb lélegzetvételű írást összeállítani, szívesen vennénk cikk keretében is.