AJAX alkalmazás milyen vastag legyen VIEW tekintetében kliens oldalon
Adott egy AJAX alapú webalkalmazás. Adott számos funkció melyeknél egy-egy formon keresztül lehet adatokat bevinni, módosítani.
Kérdés: a form előállítása szerver oldalon történjen, vagy kliens oldalon?
1. eset - kliens oldali form előállítás JS segítségével
Hátránya: Elég terjengős kód kell a VIEW előállításához
2. PHP oldalon generáljuk a teljes VIEW-t
- Szerver oldali VIEW kezelés használata
- Egyszerűbb kliens kód
Hátránya:
- Nem csak az adatok, hanem a markup is közlekedik AJAX segítségével a hálózaton
- (van még egy hátránya, de ez az én rendszerem miatt van, nem ide tartozó probléma)
■ Kérdés: a form előállítása szerver oldalon történjen, vagy kliens oldalon?
1. eset - kliens oldali form előállítás JS segítségével
- Célszerű template jellegű helper függvényeket írni
- View módosítása JS ismeretet igényel
- Terjengős kód állítja elő a VIEW-t (lévén, hogy egy táblázaton belül vannak az input elemek -- bár ezen valamelyest segítenek a helper függvények)
- Külön művelet a form feltöltése adatokkal (AJAX segítségével lekért adatok beillesztése a form-ba)
Hátránya: Elég terjengős kód kell a VIEW előállításához
2. PHP oldalon generáljuk a teljes VIEW-t
- Szerver oldalon meglévő VIEW és a hozzá kapcsolódó template rendszer, helperek alkalmazása a VIEW generálására (végkonyabb kliens)
- A form előállításához szükséges DB műveletek egy lépésben zajlanak a VIEW előállításával, azaz a kliens kész VIEW-t kap
- Kliens oldalon már csak az eseménykezelőket kell beállítani
- Szerver oldali VIEW kezelés használata
- Egyszerűbb kliens kód
Hátránya:
- Nem csak az adatok, hanem a markup is közlekedik AJAX segítségével a hálózaton
- (van még egy hátránya, de ez az én rendszerem miatt van, nem ide tartozó probléma)
Volt egy köztes megoldás, de elvetettem ...
A kliens lekéri a FORM-ba illesztendő adatokat, majd a JS végzi el az INPUT-ba illesztést, valamint a SELECT, CHECKBOX, RADIO beállítást. De rájöttem, hogy ez felesleges JS kód, mert ha már úgyis PHP oldalon generálódik a VIEW, akkor egyúttal be lehet állítani a selected értékeket, meg egyszerűbb a template-ben beilleszteni az INPUT-ok value értékeit, mint erre külön JS kódot írni. A POST-oláskor pedig az AJAX miatt nem kell már újra létrehozni a FORM-ot és visszaírni az adatokat (ezért is lett full AJAX based a rendszer).
Jelenleg a második megoldás felé hajlok, mert ez adja a legegyszerűbb megvalósítást. PHP-s rendszer VIEW kezelése, VIEW-n belül template engine helper-ekkel, adatok feltöltése a FORM-ba a template-ben. JS kész VIEW-t kap, már csak az eseménykezelőket belőni és kész is.
Azért érdekel még, hogy ki hogyan oldja meg az ilyen eseteket. Volt-e olyan vállakozó szellemű ember, aki a megjelenítést teljesen JS alapon csinálta meg? Egyáltalán megéri-e, ha az ember nem kész UI-t használ (mint pl. az ExtJS UI-ja)?
Amennyire szükséges
Én alapvetően a JS-t diszkrét módon szeretem használni (persze ehhez megfelelően sok idő kell, vannak trükkös fogások). Átlag oldalnál valszeg köztes megoldás lesz a nyerő, webalkalmazásnál meg tök mindegy, csinálj főbb modulokat, azon belül meg AJAXozz kedvedre. Egyedül arra figyelj, hogy JS-sel nagyobb adathalmazokat rendezni képes megfektetni egy kissebb atomerőművet is, nemhogy valami B kategóriás irodai gépet. (Pentium D 3 GHz-ben gondolkodj.)
Arra is érdemes figyelni, hogy ha azt szeretnéd elérni, hogy az eventek a PHP fele transzparensen látsszanak (tehát pl egy onClick eventet megkapsz PHPban, ha úgy definiálod) akkor tudok mutatni olyan júzereket, akik ilyesmivel próbálkoztak.
A HTTP egy stateless és request-based protokoll, az olyan próbálkozások, amik ezt a két tulajdonságát próbálják teljes mértékben elfedni általában anyaszomorításra vannak ítélve. Persze lehet engem meggyőzni az ellenkezőjéről.
Zárt webalkalmazás
Honlap esetében én is a diszkrét JS megközelítés híve vagyok, és természetes dolog, hogy az üzleti érdekeket nézem, mert hát ugye a honlap nem azért készül, hogy nekem legyen pénzem, hanem, hogy sikeres(ebb) legyen az adott megrendelő online fronton (is).
Amiért teljes AJAX megvalósítás mellett döntöttem az főkét a felhasználói élmény, több helyen könnyebb programozási megoldások, valamint a terhelés csökkentés (na nem mintha bármelyik most fejlesztés alatt álló rendszer is nagyterhelésű lenne, de feleslegesen minek terheljem a vasat -- osztott hostingon működő alkalmazásokról van szó, én meg előzékeny és előrelátó vagyok; én sem szeretném, ha más sz@r kódja miatt lenne lassú az én oldalam).
ExtJS
Az ExtJS is kepes szerveroldalon osszallitott dinamikus formok letrehozasara (JSON), de neked valojaban csak az adatkezelessel kell majd foglalkoznod a PHP-ban. Mindossze a kommunikacios (AJAX) interfeszeket kell osszehangolni, egysegesiteni. Ennek kovetkezteben, kicsit alkalmazkodni kell a keretrendszer (amennyiben nem sajat) altal tamaszott kommunikacios interfesz kovetelmenyekhez, de ez altalaban nem jelent 1-2 plusz osztalynal tobbet.
Javascriptes keretrendszerrel nagyon konnyen el tudod kuloniteni a megjelenest az adatkezelesi retegtol igy konnyen feloszthato a munka tobb ember kozott.
-cs-
Sanyi
GWT + GXT
Ha rám lenne bízva, biztosan a graceful megoldást választanám, azaz amit lehet megcsinálnék szerver oldalon, és olyan esetben alkalmaznék Ajaxot, mikor kisebb adatokat kell a szerverről hozni, (pl egyes inputok frissítése, gyors számítások, stb, de nem képekkel és millió szöveggel injektált html fragmenteket)
A GWT + GXT párost még csak most tanulom, ám a lényege, hogy gyakolratilag egy id-zett elembe beleinjektálja a teljes UI -t. Így a projekt, melybe belekapcsolódtam, egy gyöngébb gépen igen lassacskán áll fel, ám ezt nyilván jó programozói tervezéssel lehet javítani, és még így is eléggé felhasználóbarát (kérem várjon .gif, stb), tehát végül is látjuk hogy van valami.
Előnyei továbbá hogy gyorsan lehet fejleszteni benne, könnyebb debugolni, előre kész a kinézet, és nem kell böngészőkülönbségekkel törődni. Hátránya, hogy nem indexelődik, javascript nélkül nem működik, és bizony mire egy picit is átlátom a kódot, az legalábbis minimum két hét java tanulás volt (nekem). Mivel itt a szerver is java, a "jó pap holtig tanul" közmondás értelmét fogja nyerni esetemben :-)
Nos viszont ha már a téma felvetődött, érdeklődnék róla, hogy vannak -e tapasztalatok a statikus (x)html oldalban kapott ui, és a dinamikusan js -el felépített ui böngészőre, memóriára, cpu - használatra, hálózathasználatra gyakorolt hatásának különbségeiről, hasonlóságairól, pro, kontra, akár idegen nyelven is.
Üdv:
Gábor
jQuery appendDOM
jQuery
carstepPCE említette az ExtJS-t. A végső tervem az, hogy az ExtJS UI-t használom fel admin felületek készítésére, de az még odébb van.
Ami pedig a HTML küldést illeti AJAX-szal, logikailag nekem is sántít, ezért is postoltam a témát (mert ugye, ha már vastagkliens, akkor csak az adatok közlekedjenek a hálón). Jelenleg viszont az idő nagy úr, így most Prototype JS + a 2. megoldás lesz.
Aztán ha lecsendesülnek a dolgok (és lesz egy kis szabadidőm tanulgatni), akkor ránézek jQuery-re, majdan pedig ExtJS (legalábbis UI fronton).
Ext3
Egyrészt pár soros kóddal létrehozod a teljes UI-t, másrészt meg egyszerűen képes kezelni immár a CRUD-dolgokat is. Azaz előre előkészített kereteket ad neki, és még a komponensek is támogatáják (combo, grid, etc).
Nem nagy ördöngősség az ExtJS, egyszerű leírónyelvként működik az esetek 90%-ban, a maradékban kell csak eventeket írnod.
Szóval felesleges újra inventálni a kereket, azt már megcsinálta Jack Slocum és csapata. :D