Hozzászólás: Margójegyzet a web 2.0 technikáiról http://webpillango.org/web/margojegyzet-a-web-20-technikairol/ Webprogramozás és grafika, photoshop leírások és kiegészítők Tue, 07 Feb 2012 18:25:27 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Szerző: Tupacko http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-233 Tupacko Thu, 24 Jan 2008 09:33:34 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-233 Hát na, egy épkézláb ötlet, csak még hivatalosan nem láttam megjelenni sehol :) Hát na, egy épkézláb ötlet, csak még hivatalosan nem láttam megjelenni sehol :)

]]> Szerző: BlackY http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-231 BlackY Wed, 23 Jan 2008 23:03:12 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-231 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 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

]]> Szerző: Tupacko http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-229 Tupacko Wed, 23 Jan 2008 18:53:13 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-229 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 :D Fajhat is a feje az embernek ettol :) 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 :D Fajhat is a feje az embernek ettol :)

]]> Szerző: BlackY http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-228 BlackY Wed, 23 Jan 2008 16:36:44 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-228 Aszinkron Javascript And Xmlhttprequest, ha már ez az objektum neve. Másik válasz, az AJAJ/AJAJSON hülyén hangzik :) BlackY Aszinkron Javascript And Xmlhttprequest, ha már ez az objektum neve. Másik válasz, az AJAJ/AJAJSON hülyén hangzik :)

BlackY

]]> Szerző: Tupacko http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-227 Tupacko Wed, 23 Jan 2008 15:37:51 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-227 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 :) 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 :)

]]> Szerző: BlackY http://webpillango.org/web/margojegyzet-a-web-20-technikairol/comment-page-1/#comment-226 BlackY Wed, 23 Jan 2008 12:07:29 +0000 http://webpillango.org/2007/11/21/margojegyzet-a-web-20-technikairol/#comment-226 "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 “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

]]>