Margójegyzet a web 2.0 technikáiról

Írta: | 2007. november 21. | kategóriák: Blogolok, Web

Web 2.0 tag felhőEddig is weboldalak voltak, most is: mi a különbség? Talán sokan vannak ezzel így, de ez nem igaz! Régen is volt online enciklopédia? Régen is volt ennyi ingyenes és mégis okos, jól elkészített internetware? Nem volt, mert nem lehetett elkészíteni, vagy csak nehéz, nagy anyagi hátteret igénylő körlülmények közt.
A nagy változást az is befolyásolta, hogy drasztikusan estek a tárhelyek árai, és ez mellet, hihetetlen mértékben nöttek az internetelérhetőségek és sávszélességek is. Olcsó lett a számítógép: manapság rengeteg számítógép van a világban és a különböző programoknak hála a harmadik világ országaiba is rengeteg csomag érkezik. Nem kell softwaret sem venni (ha nincs rá pénz): minden van ingyen, létezik open source és freeware!
A fizikai változás a szellemi változást is elősegítette, sok jófejű idő és fiatal lelt szórakozást a számítógépes tanulás nyújtotta lehetőségekben. Volt aki grafikázni kezdett, volt aki a PHP és MySQL szépségét találta meg, stb. Így rohamosan fejlődött és fejlődik a technológia, amely megvalósítja a mai webkettes világhálót és, ami már építi a hidat a harmadik generációs web felé (ami valójában már a negyedik, ha az internet kezdeti formáit is vesszük).
Régen gondot jelentett a frissítés, minden egy HTML állományban volt: tartalom, formázás, esetleges kódok. Nehéz volt formázni és nehéz volt megfelelően új részeket hozzátoldani. A megoldást a tartalom, a programozási rész és a formázás szétválasztása jelentette (ezt az asztali alkalmazásokról mintázta az internet). Így a tartalmat könnyen kezelhető és biztonságos adatbázisokban tárolják, a(z) (X)HTML generálást megoldja a szerveroldali PHP program, a végfelhasználónál pedig a CSS végzi a formázást. Természetesen más nyelvek is vannak, én a legelterjettebekről szóltam.
Az adatokat álltalában SQL alapú adatbázisokban tárolják, majd azt egy erős szerveroldai programnyelvel bányásszák ki, mint példáúl a PHP, ASP, .NET ASPX, JSP, stb. Az így kapott információt beillesztik egy keretbe, egy sablonfájlba, ami általában (X)HTML vagy XML, amit többnyire CSSel társítva a felhasználó böngészőjére küldenek. Ott a CSS elvégzi a formázást, egységesnek kinéző, jó weboldalt szolgáltatva. Ezáltal külön és eredményesen kezelhetjük a tartalmat, nem gond a frissítés és szerkesztés sem. A programozást is külön végezhetjük, így aránylag egyszerű új funkciók beépítése, illetve a formázást is külön lapon tárgyalhatjuk.
Nagy újdonság az asszinkron frissítés is. Először példákban beszélnék, hogy legyen érthetőbb. Bizonyára használtad már a Google Maps-et, ahol megtekintheted a Földet. Észrevehetted, hogy az oldal látszólagos újratöltése nélkűl, az egér mozgatásával frissül, betöltődnek az újabb képkockák. Több, mint valószínű, hogy néztél már webcamen kereszűl egy parkot vagy várost, ahol volt rá lehetőség, hogy egy kattintással beközelíts, vagy elforgasd a kamerát. Az adott példák esetében valóban nincs látszólagos oldalbetöltés, mivel az egy hátsó szálon át küld kérést a szervernek, amely ugyanazon a szálon válaszol. Másként mondva, az oldal a háttérben kommunikál a szerverrel, anélkül, hogy a felhasználót zavarná az oldalfrissítésekkel.
A megoldást az aránylag egyszerű AJAX, asszinkron JavaScript és XML, lehetőségei biztosítják. Dióhéjban úgy müködik az egész, hogy az oldal a JavaScript segítségével kikűld egy háttér kérést, az XMLHttpRequest objektumot használva, a kiszolgáló szerver fele, amely egy XML objektum formájában válaszol. Az így kapott információ halmazt a JavaScript kiértékeli és tálalja a felhasználó számára. Az asszinkron megnevezés a szolgáltatás jellegéből fakad, hogy nem szinkronban, bizonyos peridódusonként végez el egy tevékenységet a rendszer, hanem spontán módon a felhasználó kérésére.
Nem szabad megfeleldkezni az új standard protokolokról sem, mint például a különböző hícsatornák nyelvei: RSS, RSS 2.0, ATOM, stb. Ezeken az igen egyszerű, jól strukturált XML fájlokon keresztűl az oldal meglátogatása nélkül juthatunk a legfrissebb hírekhez. Használata is igen egyszerű: betesszük az oldal feedjét a hírolvasonkba és folyamatosan értesülünk a kívánt hírekről. Ha szeretnénk, akkor a szülőoldalon teljes pompájában is elolvashatunk az adott hírt, csupán a hiperhivatkozásra kell kattintanunk.
Nagyvonalakban ez a webkettes szolgáltatások és az új világháló technikai felépítése. Természetesen sok száz másfajta koncepció is létezik, sok születik és tünik el, de a fő elképzelés ez: a felhasználók és egyben termelők kommunikációjának egyszerű és kielégítő megvalósítása.
A következő webkettes témájú bejegyzés a webkettő grafikai és design divatirányzatával fog foglalkozni.



Értékeld a bejegyzést!

Loading ... Loading ...

A bejegyzésre érkező kommenteket elérheted RSS 2.0 formájában vagy emailben is:

A bejegyzéshez tartozó trackback cím, illetve a permalink.

A megjegyzéseket kérlek, tedd fel érthető és illendő módon, ne fikázz le másokat, mert nem tudnak valamit, amit te már igen. A kommentár lehetőleg függjön a bejegyzéshez :)

kötelező
kötelező, titok marad
ha nincs, maradjon üres



“XML objektum formájában válaszol.”
Ezzel azért így önmagában vitatkoznék, mivel már nem mindig van így. Ha csak a sávszél-kímélésből is, de a JSON-t (JavaScript Object Notation) választod, akkor a válasznak az XML-hez semmi köze nem lesz. Ha ráadásul mindezt Prototype JS-el csinálod, ami a JSON adatokat HTTP fejlécben várja el, akkor többnyire valós kimeneted nem is lesz.

“asszinkron megnevezés a szolgáltatás jellegéből”
Ez is kissé pontatlan, itt az aszinkron jelző több dologra is vonatkozhat: ugye az xhr objektum magától is képes szinkron és aszinkron kérést futtatni: előbbi esetben a letöltés végéig a böngésző “megfagy”, mivel vár a letöltés befejezésére, utóbbi esetben a háttérben indítja el a kérést (és nem vágja haza a gépet egy 10 megás html betöltésekor 🙂 ). A másik, hogy az aszinkronitás a felhasználói interakciótól való függetlenséget is kifejezheti, gondolj csak a Prototype JS Ajax.PeriodicalUpdater objektumára.

A JavaScript – HTML+CSS – Szerveroldal hármas elemzéséből pedig hiányoltam, hogy felfogható ez a három egy végletekig leegyszerűsített MVC rendszernek: a JavaScript a Controller (ugye ez kommunikál az M-el és a V-vel, kezeli az eseményeket, …), a HTML+CSS kettős önmagában a megjelenítésért felelős (bár itt van az első hiba az elméletben: a megjelenítés frissítéséért is egy kis JS felelős, így a megjelenítés inkább HTML+CSS+JS), a szerver oldal pedig a Model (ahol a PHP csak egy egyszerű kapu a JS és az adatbázis között, nem végez controller feladatokat, vagy csak minimálisan). (Végülis: M (PHP + SQL) V (HTML + CSS + JS) C (PHP + JS))

BlackY

BlackY 2008. január 23. - 15:07

Igazad van, de nem is akartam minden teljes elkomplikáltságában leírni, mert ugy-e erről a témáról egy egész könyvet is lehetne. Végülis ahol JSONt kapsz vissza nem is igazi AJAX, mert hanem már egy olyan tech. ami már rég túlnőtte az AJAXot, csak nem kapott új nevet. A JSONra alapul pl. az ASP .NET és AJAX környezete is … bár sok XML ott nincs. Akkor miért AJAX?
Az utolsó bekezdésed igen jól kiegészíti a cikket, köszi 🙂

Avatar Tupacko
2008. január 23.
18:37

Aszinkron Javascript And Xmlhttprequest, ha már ez az objektum neve. Másik válasz, az AJAJ/AJAJSON hülyén hangzik 🙂

BlackY

BlackY 2008. január 23. - 19:36

Az AJAX bizony nem XMLHttpRequest, hanem “Asynchronous JavaScript and XML”. Ez 100%. Az egy dolog, hogy XMLHttpRequest az, amin keresztul a kommunikacio zajlik.
Az AjjAjj tetszik 😀 Fajhat is a feje az embernek ettol 🙂

Avatar Tupacko
2008. január 23.
21:53

Az XmlHttprequest-et azért hoztam fel, mert a JSON kódot is azon keresztül töltöd be, tehát a JSON-alapú megoldásoknak is közük van hozzá, és így csak az XML-t kell XMLHttpRequest-re cserélni, és mindkét technikát lefedi 🙂

BlackY

BlackY 2008. január 24. - 02:03

Hát na, egy épkézláb ötlet, csak még hivatalosan nem láttam megjelenni sehol 🙂

Avatar Tupacko
2008. január 24.
12:33