Weblabor

Ígértem egy bejegyzés sorozatot az egyik saját AJAX fejlesztés kapcsán, nos itt a folytatás. Ezúttal azzal kapcsolatosan, hogy hogyan érdemes a felhasználói interfészt előállítani, pontosabban, hogy milyen lehetőségeink vannak, hogy a felhasználói interfész a program segítségével - a design és interfész tervek alapján - létrejöjjön. A döntés nem feltétlenül egyértelmű, nincsen általánosan jó és rossz döntés (na jó, talán általánosan rossz lehetőség van), a helyzet alapján célszerű mindig meghatározni, hogy mely módszert választjuk.

Az első kérdés egyszerű: hogyan manipulálható az oldal HTML forrása JavaScriptből? Erre a válasz is egyszerű, van körülbelül három módszer: a document.write(), az .innerHTML és a DOM segítségével (X)HTML felépítés, manipuláció. Az utóbbi kettő közelít egymáshoz, de azért közel sem ugyanaz.

A document.write() segítségével nagyjából lineárisan, az oldal forrását bővítve tudjuk írni a HTML oldalt. Ennek a gyakorlati haszna egy webalkalmazás interfészének fejlesztésekor közelít a nullához, esetleg valamilyen trükkhöz használható fel, de most ilyen se nagyon jut eszembe. Ezen kívül az XHTML korában nem egy igazán javasolt módszerről van szó - ha szabvány szerint, XML-ként szolgáljuk ki az XHTML oldalt, akkor nem fog működni. De most úgyse tudjuk mire használni.

A következő lehetőség egy adott oldalelem .innerHTML tulajdonságának manipulálása, még pontosabban egy adott HTML részlet az adott oldalelemhez rendelése. Kérdés, hogy ez a HTML hogyan áll elő, erről pár bekezdéssel később. Mindenekelőtt essék szó arról, hogy .innerHTML tulajdonság nem szabványos. A Microsoft vezette be az Internet Explorer egy régebbi verziójában (ha minden igaz, már a 4.0-ban is használható volt) más, nem szabványos lehetőségekkel (mint az .outerHMTML) együtt. A megoldást, mint egy elég jól használható lehetőséget, később átvette a többi böngésző is, így ma már minden elterjedt böngészőben használható (IE, Firefox, Opera, Safari), gyakorlatilag kvázi szabvánnyá vált. Ha XML-ként szolgáljuk ki XHTML oldalunkat (amit például Explorerrel nem lehet megoldani), akkor esetlegesen problémákba ütközhetünk, például a Firefox 1.0 szériája nem támogatta ilyenkor a használatát. Az 1.5 szériával már nincsen gond. Bár jelenleg nem szabványos a megoldás, a következő DOM szabványnak a WhatWG tevékenységének köszönhetően várhatóan része lesz.

Végül az emlegetett három lehetőség közül a DOM maradt utoljára. Egy HTML szerkezet felépítése, majd az adott oldalrész lecserélése egy modern és "szép" lehetőség. "Szép", mivel ez az a megoldás, ami teljesen szabványosnak mondható, s szép, mert faszerkezetet (az oldal böngészőbeli reprezentációja kifejezetten az) nem feltétlenül sztringekkel a legkívánatosabb összeállítani.

A fenti lehetőségeket, pontosabban a megmaradt két lehetőséget súlyoztam praktikusság, sebesség és legutoljára a szépség szerint. Praktikusság alatt az átláthatóságot, a karbantarthatóságot értem, sebesség alatt azt, hogy a webalkalmazásban az igazán sebességigényes részek milyen gyorsak: ha az oldal kezdeti felépítése 500ms helyett 700ms-ig tart, nem igazán fontos, de ha az oldal folyamatos változtatása időigényes, az már igen.

Az .innerHTML esetén a praktikusság kérdése úgy merült fel, hogy hogyan állítható elő a beállítandó HTML részlet. Maga az értékadás egy eléggé egyszerű folyamat, hiszen az oldalon a lecserélendő elemet id alapján gyorsan és könnyen meg lehet találni. A HTML előállítása JavaScriptből, sztringek összefűzésével a karbantarthatóság kapcsán felállított követelményeimnek nem felelt meg. Semmi kedvem nem volt ahhoz, hogy figyeljek az idézőjelezésre és az amúgy nagyon lassú konkatenáció megkerülésére. Az eredmény nem lett volna más, mint egy nem túl átlátható kódtömeg, az összeállított HTML+CSS kódrészlet pedig transzformációt igényelt volna. A felmentősereg a korábban már felderített JavaScript Templates (JST) volt a TrimPath-től, ami nem más, mint a szerver oldali nyelveknél megszokott sablonkezelő rendszer, ezúttal teljes mértékben JavaScriptben implementálva (egyébként a Smarty-ra hajaz a formátum). A lehetőségek listája elég szimpatikusra sikeredett (értelmes formában átadható változók, "gyorsítótárazható" sablonok), s nem utolsó sorban a kivitelezését sem egy amatőr végezte - próbáltam ugyan optimalizálni rajta, de semmit sem sikerült... Egy másik, de elvetett lehetőség a Perlben használatos Template Toolkit dinamikusan fejlesztett JavaScript implementációja, a Jemplate lett volna, de mivel ez előzetes transzformációt igényelt volna, illetve más apró problémám is volt vele, ezért végül mint lehetőség kizárásra került.

A DOM-nál az adott kódrészlet előállítása - gondolom nem túl nagy a meglepetés - DOM függvényekkel történhet. Tömörnek semmiképpen sem nevezném ezt a módszert, eléggé szószátyár megoldás a document.createElement(), majd az .appendChild() függvények használata. Bár a kódot fel lehet építeni áttekinthetően, maga a végeredmény egy több képernyőnyi sorminta is lehet, amit ember legyen a talpán, aki átlát. Egy viszonylag bonyolult HTML+CSS designterv alapján nem igen vállalkoznék rá, hogy megírjak egy ilyen programrészletet, itt esetleg az automatizálás segíthet. A jobb áttekinthetőségre persze van itt is megoldás, a DomBuilder nevű pár soros osztály egy tömör lehetőséget kínál (illetve vannak más, hasonló megoldások is). A programkód előállítása viszont nem lett egyszerűbb, itt is célszerű valamilyen előfeldolgozót igénybe venni, ha erre a megoldásra esik a választás.

Mivel a webalkalmazásnál igen fontos szempont volt a sebesség is, ezért fontos volt megvizsgálni ebből a szempontból is a kérdést. Ebben egyértelműen az .innerHTML lett a győztes. A belinkelt mérés, és a saját méréseim is egyértelmű győztesnek hozták ki, viszont volt egy utalás arra, hogy a DOM gyorsabb tud lenni, ha klónozást használ az ember, és nem újra és újra előállítja a megfelelő HTML részletet. A kérdést megvizsgáltam közelebbről is. Ha adott egy sztring és adott egy már felépített HTML töredék, a nyertes körülbelül dupla sebességgel a HTML töredék DOM függvényeket használó hozzárendelése az oldal adott pontjához. A különbség persze nem sok, pár ezredmásodperc, de mint az korábbi hozzászólásomban is kiderült, adott esetben ez sokat számíthat. Ez alapján úgy hangzik, mintha a DOM lenne a nyerő, azonban a kérdésnek van egy másik fele is, mégpedig a megfelelő sztring, illetve a megfelelő HTML töredék előállítása. Nos, a sztring előállítása sokkal gyorsabban megoldható - annyival gyorsabban, hogy behozza a megjelenítésbeli különbséget, és az .innerHTML megoldás nyeri a sebességben is a versenyt.

A győztes tehát - ahogy a fenti leírásomból talán egyértelmű - az .innerHTML + JST kombináció lett, s azt kell mondjam, hogy ezt a döntést nem is bántam meg a későbbiek folyamán. Azaz egy kis kiegészítést még kell, hogy tegyek: egy nagyobb oldalrészlet cseréje villogást eredményezhet, illetve a fókusz, kijelölések is elvesznek a csere alatt - így ahol szükség volt rá, egy kiegészítő megoldást bevezettem, mégpedig a közvetlen oldalmanipulációt, egy-egy konkrét elem cseréjét DOM-mal.

Biztosan létezik még másik út is, melyen el lehet indulni, egy egyszerűbb oldalfelépítésnél például, ahol nincsenek összetett felületek, lehet, hogy valakinek a DOM megoldás fog bejönni. Vagy egyszerűen mindent kitesz, és utána csak a tartalmat változtatja, elrejt, megjelenít dolgokat. Ha az oldalon nincsen sok elem, akkor ez sebességben sem fog gondot okozni, hiszen egy 100 ms-os és egy 200 ms-os megoldás között a felhasználó nem nagyon tud különbséget tenni. A kérdés a skálázhatóság, azaz az, hogy az oldal bonyolultságának növekedésével sem fog-e sebesség probléma fellépni, de nagyon könnyen előfordulhat, hogy előre tudható: a felület végleges, s nem lesz nagy változás benne.

Végül egy zárógondolat: a webalkalmazásoknál - mint minden olyan alkalmazásnál, ahol van felhasználói interfész - nagyon fontos irányelv lehet az MVC design pattern használata: nem árt, ha az adatok megjelenítése elkülönül a program többi részétől. További, az asztali alkalmazásoknál jól bevált, de a webalkalmazásoknál nem használt technikák is hasznosak lehetnek, illetve nagyon fontos (de hát ez végülis mindenhol így van) a felhasználói élmény, például a felhasználói felület jól használhatóvá tétele. Vagyis ne csak elkészüljön az az alkalmazás, de legyen átlátható, használható, s épüljön a felhasználó által korábban megszokott felhasználói interfész elemekre.