XHR válasz összeállítása hol jó?

Web, mail, IRC, IM, hálózatok

A rovid cimek hatranya az erthetetlenseg, szoval arrol szeretnem kerni a velemenyeteket, hogy egy XML HTTP Request (aka Ajax) valaszt szerver vagy kliens oldalon celszeru osszeallitani komplett html-re? En ugy gondolnam, hogy mindket modszernek vannak elonyei, es hatranyai; szerintem:

Szerver oldal
Elonyok

  • kliensen csak be kell illeszteni a keszre generalt htmlt, felhasznaloi elmeny jobb
  • megtarhato az MVC-struktura, azaz view-ban barmikor modosithato a kinezet, nem kell hozza kliens oldali JS-t valtoztatni
  • adott esetben szerver oldalon cache-elheto a valasz html
  • fel lehet hasznalni a projektnel alkalmazott sablontechnikakat (pl. smarty, haml stb.)
  • egy kesz html kliens oldali beillesztese nem jelent gondot semmilyen bongeszonek, abszolut cross-platform

Hatranyok

  • plusz terheles a kiszolgalonak
  • hosszabb valaszido
  • nagyobb savszelessegigeny

Kliens oldal
Elonyok

  • egyszerubb szerver oldali programkod (kis tulzassal egy SQL lekerdezesre eleg egy to_json() fv-t raengedni)
  • nincs szukseg view-ra, kevesebb include
  • rovid valaszido
  • kisebb terheles szerveren
  • kevesebb savszelesseg elegendo

Hatranyok

  • a kerdeses kod „kiesik” az MVC-bol, JS-t kell modositani a kinezethez
  • egy alapvetoen lassabb JS-parsernek kell elkesziteni a strukturat a nyers json objektumbol
  • eppen ezert a felhasznaloi elmeny kicsit rosszabb lehet
  • nem hasznalhatok a megszokott template-ezo rendszerek (hacsak nem szanja ra magat az ember, hogy megtanulja az XSL-t, es a valaszban erkezo xml-t azzal formazza be, de ennek keresztplatformossagarol nem vagyok meggyozodve)

A sebesseg es a felhasznaloi elmeny kerdesen meg gondolkodtam, lehetseges hogy nincs szamottevo kulonbseg, mert az elso esetben a kliens hamar beilleszti DOM-faba a kesz html-t, de a szerver elszoszmoszol annak elokeszitesevel; mig forditott esetben a szerver hamar kikopi az adatot, de a JS-parser dolgozik „helyette”.

Vagy netan feladata es helyzete valogatja, hogy melyik a jobb? Ahol a szervernek rettento sok parhuzamos kerest kell kiszolgalnia, de a felhasznaloi elmeny kevesse szamit, ott dolgozzon csak a latogato bongeszoje; ha viszont nagyon fontos egy tized masodperc is a felhasznaloi elmeny miatt, akkor amit csak tud csinaljon a szerver? Oke, de a valaszido csak egy dolog, mi a helyzet a kod karbantarhatosaggal, atlathatosaggal?

Laikus vagyok a temaban, tehat keretik nem kopkodni, minden epito gondolatot szivesen latok.

  • 959 megtekintés

( hrgy84 | 2009. 02. 15., v – 22:03 )

Eloszor is: a kliensoldali JS pont ugyanugy a view resze, mint barmi egyebe. Rails alatt peldaul nyugodtan lehet js-en belul ruby kifejezeseket hasznalni, azok meg a szerveren kiertekelodnek, es csak a pure JS kerul ki a kliensre, ahol vegul feldolgozodik.

Masik: mindig szem elott kell tartani a "Cel valaszt eszkozt" filozofiat. Nincs olyan, hogy mindig csak ugyanazt hasznalom, mert a furdonadrag - legyen barmilyen kenyelmes is - az Operaban eleg nevetsegesen nez ki, pedig az is nadrag...

Ugy gondolom, a lehetosegekhez kepest igyekezni kell a terheles egyenletes elosztasara. A szerver oldja meg azokat a feladatokat, melyek ora tartoznak, dolgozza fel az adatokat, es csak azokat kuldje le a kliensnek, amikbol a megjelenites mar viszonylag konnyen megteheto. Ajax eseten szerintem gyorsabb es tomorebb json-t/xml-t kuldeni, mint html-t, mert a kliens oldalon ezek beillesztese nem igenyel tul nagy eroforrast. Ugyanakkor torekedni kell arra is, hogy az oldal ott is mukodokepes legyen, ahol nincs JS.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha maradunk annal, hogy a szerver csak egy json objektumot kuld, akkor kliens oldalon milyen technikak vannak arra, hogy normalis, jol karbantarthato koddal epitsen fel az ember beillesztendo html-t?

Az utolso mondatoddal egyetertek, de itt XHR-rol van szo, akkor pedig adott a JS.

Amugy ez is egy eredekes aspektus: ha nincs JS, nincs Ajax, hanem teljes oldalujratoltes van, akkor mindenkepp szerver oldalon kell generalni a html-t. Ott ahol szamit az, hogy JS nelkul is menjen az oldal, nem jelent dupla munkat egyszer igy egyszer ugy megcsinalni?

Pont ezert mondtam, hogy meg kell talalni az osszhangot, meg hogy attol fugg, mi a cel. Nyilvan egy chatoldalnal ugysincs ertelme minden egyes uzenetre ujratoltetni az oldalt, ott tehat lehet dobni a non-js supportot. Ugyanakkor mondjuk egy webboltnal mar erdemes lehet elgondolkodni azon, hogy mi az, ami kivalthato js-sel, megis kompatibilisek maradunk.

Nyilvan munkatobblet a js supporttal nem rendelkezo ugyfelek megfelelo kiszolgalasa, de ez sajnos velejaroja a webes programozasnak. De hogy mennyire kell a JS-t eroltetni, annak mar a portal tervebol ki kell derulnie, es magat a portalt ugy kell felepiteni, hogy ne jelentsen jelentos tobbletmunkat a dolog.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Vilagos, de epp ezert gondolnam en, hogy ne dolgozzunk ketszer, hiszen dupla a hibalehetoseg is. Csinalja a szerver a html-t, ami akkor is ua. ha teljes oldalujratoltes van, es akkor is ha csak XHR valasz. A partial-ok nagy elonye, hogy mindket esetre tokeletesen alkalmazhatok. Felreertes ne essek, nem megyozni akarlak, csak a velemenyem irom le. A chat-nel meg az Ajax mar obsolate, Comet a meno. :)