események és adatbetőltés ajaxal
Sziasztok!
Egy elméleti kérdésem lenne.
Én szeretem az ajaxos, és ablakos admin felületeket, de van egy általános problémám, amivel rendszeresen szembe ütközöm.
1) ha ablakos a rendszer, akkor 1 űrlap akár több ablakban is lehet.
2) ezen ablakokban rendszeresen adatfrissítés lehet szükséges, pl.: Ügyfeleknél a beállíthatók kapcsolatotok, amit select2 vel lehet kiválasztani. De ha egy másik ablakban törlök, vagy felviszek egy új üygfelet, aki szintén lehetne kapcsolat, akkor attól még nem módosul semmi.
3) Ez megoldható esemény figyeléssel: mentés utánés ezt figyeljük:4) igen ám, de ebben az esetben ha az ablakot pusztítom, az esemény figyelő marad. Szembe találkoztam olyannal, hogy 1 kattintásra sokszor futott le a szükséges kód.
5) azt a problémát pedig ne felejtsük, hogy 5 ablakba 5x kérek le ajaxal megnyitásnál egy adatsort, pl select2.
Általánosságban ez fogalmazódott meg, bennem a probléma megoldásával kapcsolatban:
1) Az adat betöltést meg kellene oldanom valami adatkiszolgáló funkcióval. Ami ha megvan az adat akkor csak visszaadja, ha nincs akkor betölti, és egyes eseményeknél újból betölti.
2) igen ám, de követnem kellene, hogy kiszolgál-e még bármilyen funkciót, mert ha nem, böngésző zárásáig bent marad a memóriában. És ugye ajaxról beszélünk. Jó lenne, hogy ha már nem szolgál ki adatot senkinek, akkor elpusztítaná magát.
3) és még mindig ott tartunk, hogy az esemény figyelők bent maradnak a rendszerben.
Van valakinek hasonló elgondolású rendszere? Van ötlet, hogy lehetne rendet rakni?
■ Egy elméleti kérdésem lenne.
Én szeretem az ajaxos, és ablakos admin felületeket, de van egy általános problémám, amivel rendszeresen szembe ütközöm.
1) ha ablakos a rendszer, akkor 1 űrlap akár több ablakban is lehet.
2) ezen ablakokban rendszeresen adatfrissítés lehet szükséges, pl.: Ügyfeleknél a beállíthatók kapcsolatotok, amit select2 vel lehet kiválasztani. De ha egy másik ablakban törlök, vagy felviszek egy új üygfelet, aki szintén lehetne kapcsolat, akkor attól még nem módosul semmi.
3) Ez megoldható esemény figyeléssel: mentés után
$(document).trigger('customer');$(document).on('customer', function() {});5) azt a problémát pedig ne felejtsük, hogy 5 ablakba 5x kérek le ajaxal megnyitásnál egy adatsort, pl select2.
Általánosságban ez fogalmazódott meg, bennem a probléma megoldásával kapcsolatban:
1) Az adat betöltést meg kellene oldanom valami adatkiszolgáló funkcióval. Ami ha megvan az adat akkor csak visszaadja, ha nincs akkor betölti, és egyes eseményeknél újból betölti.
2) igen ám, de követnem kellene, hogy kiszolgál-e még bármilyen funkciót, mert ha nem, böngésző zárásáig bent marad a memóriában. És ugye ajaxról beszélünk. Jó lenne, hogy ha már nem szolgál ki adatot senkinek, akkor elpusztítaná magát.
3) és még mindig ott tartunk, hogy az esemény figyelők bent maradnak a rendszerben.
Van valakinek hasonló elgondolású rendszere? Van ötlet, hogy lehetne rendet rakni?
Központosítsd
Igen, igen
Van egy központi objektum, annak része lenne a globális adatkezelő.
Be lehetne jelentkezni az adat olvasásra,
És ki lehetne jelentkezni.
Ez nem is rossz.
Kérdés:
Mondjuk 1 ablakban 4-5 különböző adatra ráugrok. .on() megoldással. Amikor bezárom az ablakot, ezeket pusztítani kellene (akár ugye azzal együtt, hogy az adatforrásnak jelzem, hogy nekem már nem fog kelleni), hogy tudom ezeket megtalálni? Akaszkodjak rá minden ilyen mezőnél az ablak bezárására is, és futtassak arra is egy kódot?
Úgy érzem nincs más mód, mint input mezőnként az ablak bezárására is figyelni. Ugye?
a select2 egyébként egy jó kis szabható selectet csinál.
Érdemes lehet tanulmányozni
chrome plugin?
annyira nem vagyok otthon a nagyon új dolgokban, főleg ha több ablakban is fut valami. gyanítom, hogy websocket használatával megoldható lenne a problémád, itt a szerver tolna üzeneteket minden egyes példánynak.
amúgy meg ha van rá mód, írhatsz chrome plugint is. emlékeim szerint ott pont lehet háttérfolyamatot indítani, ami ki is lövi magát, hogyha már nincs kit kiszolgáljon.
Nem külön böngésző
Egyébként igen. websockettel lehetne, de nem szándékoztam ebbe az irányba elmenni. És néhány probléma ott is meg maradna.
A chrome plugin fortélyait nem ismerem, de az eleve kizárja a megoldást, hogy "chrome". Mi lenne ie-ben? vagy ff-ben? :)
bamegakapa: természetesen tanulmányozhatnám, ha a téma megérné hogy néhány hetet ezeknek a visszafejtésével foglalkozzam.
DE azért kérdeztem itt, hogy elkerüljem a hetekig tartó tanulmányozásokat.
Reméltem, hogy az általam nagyra becsült weblabor társadalom próbált már megoldani hasonlót, neagyisten dolgozik ilyesmiben valaki :D
de agy isten :D
ha mégis jquery akkor az eseményfigyelőket tedd olyan elemekre amik fixek, valami elem alá úgyis bekerülnek a dinamikus ablakok. lehet esemény névtereket is csinálni, ezekkel egy off is könnyen kezelhető, ha mégis ilyenre van szükség.
fedd el az ajaxos kéréseket egy külön objektummal, így ahol kell megvalósíthatod a cache-t elég egyszerűen (érdemes esetleg arra figyelni, hogy a cache-ből visszanyert adat is aszinkron jöjjön), valamint felépíthetsz listákat (ide fel-, le lehet irakozni), hogy bizonyos változásokra mely ablakoknak kell reagálni és adott változásoknál szépen lefuttatsz egy render-t az adott elemekre.
ilyesmik. szerintem.
Attól függ
Így elég minden űrlapelemre egy onchange eseményt tenni, és nem ütközöl abba, amit az első rész 3-as és 4-es pontjában írsz, továbbá az általános kérdéseid is érvényüket vesztik.
Én nem hiszek abban, hogy
Itt most nem alkalmazáslogikáról van szó különben sem, hanem felhasználói felületről.
De amúgy nem teljesen értem, minden űrlapelem változásnál töltse újra az oldalt, vagy hogyan?
Az általunk fejlesztett
És igen, minden űrlapelemváltozásnál töltse újra a megváltozott adatokat. Bár azt hinné az ember, hogy ez lassú, de nem az.
Lassú
Biztos
Ezt pontosan, hogy kell elképzelni?
Igen
Egyéb szempont nincs?
Miért, szerinted milyen
UX
8.-asban elhangzott, hogy UX.
Azt ajánlottam a 7-esben,
Igen
AJAX-os témában vagyunk, itt
Oké, működik, de mi az előnye?
Ha egy űrlapon a fókusz (illetve a Tab gomb) nem megfelelően viselkedik, akkor ott UX-ről inkább ne is beszéljünk.
De egyáltalán miért gondoljuk, hogy szerver oldalon könnyebb lekezelni azt, hogy melyik mező látszódik, mint ugyanezt kliens oldalon?
Akkor a 13.-ban említett teljes oldalújratöltést, mint opciót el lehet felejteni, tehát akkor jól értem, hogy azt azért mégsem ajánlod, vagy?
Miért egyszerűbb például
fókusz
Szerinted az automatikus
Látom, nagyon aggódsz a felhasználók élményéért, de azért ne feledd, hogy ez csak egy komponens a sok közül, amiből egy szoftver összeáll.
Más a nézőpont.
Persze, hogy aggódom a felhasználókért, üzleti alkalmazások esetén a felhasználókkal akár napi kapcsolatban is vagyunk. Vannak cégek ahol az a fő projekt az, hogy az adblock ellenére megjelenjenek a hirdetések, vannak cégek ahol meg az a fontos, hogy például az adatfeltöltő ne utálja annyira a munkáját és a főnökség felé ne panaszkodhasson, hogy azért halad lassan, mert a felület rossz.
Ok, nem csigázlak tovább,
A fenti példáddal élve:
kertmeret.visible = true;
}
Teljesen mindegy, hogy ez a szerveren vagy a kliensen fut le. Innentől kezdve pedig a felhasználói élmény nem a kód futásának helyétől, hanem a tisztelt készítőktől függ.
Ez azért néhány sor
Ami azt illeti, szkript nélkül is elképzelhető, a fókuszt az
autofocusattribútummal állítva, az űrlapmezőket pedig egy sor rádiógomb címkéibe helyezve, ezzel aktiváláskor kijelölve és elküldve a megfelelőt (nem próbáltam ki). Nyilván nem javaslom, csak gondolatkísérlet :)Élmény
Rossz kód
Számtalan alkalmazás létezik, amely elindulás után nem fagy le, ami elindulás után nem akad. Igen, léteznek ellenpéldák, amik rosszak. De ha valami ellen érveket hozunk fel, akkor ne az legyen állandóan az érv, hogy lehet rosszul is használni. Mert az olyan érvekkel nem lehet mit kezdeni, hogy ha egy végtelen ciklust a kliensen csinálsz, akkor csak az ügyfél böngészője akad ki, de ha szerveroldalon készítesz egy végtelen ciklust, akkor az egész szerver mindenestül behal, na melyik is a jobb? Na ugye, hogy jobb a kliens oldali megoldás! Szerintem hasznosabb, ha inkább a jól megírt kódokat hasonlítjuk össze.
Tökéletesen igazad van abban,
Vegyünk egy egyszerű példát: készítesz egy új számlát, amit azzal kezdesz, hogy kiválasztod a vevőt az adatbázisból, valamint ez alapján bemásolod a megfelelő mezőkbe az ő alapértelmezett címét és banki adatait. Ez három atomi feladatot jelent (név, cím és banki adatok választása), amit nem lehet megspórolni, azaz akár szerver-, akár pedig kliensoldalon le kell futtatni. Ha összetettek az űrlapok, akkor sok ilyen feladat lesz, sok memóriát foglal az összefüggések eltárolása. Ha ezeket a feladatokat a kliensoldalról átteszem szerveroldalra, nem lesz a kódom jobb vagy rosszabb, csak máshol fut le.
Ezek után a fenti érvelésed nem állja meg a helyét.
Vegyük a témanyitó kérdését!
Amikor irreálisan nagy DOM épül, akkor valóban vannak gondok, ám ilyen esetekben eddig mindig megoldás volt az, hogy valamin alakítottunk, úgy hogy egyszerre mégse legyen túl nagy a HTML oldal.
Vegyük a témanyitó kérdését:
Első lépésként készítesz egy üres számla formot, benne több adatbázis lekérés, mert számtalan választható opció adatbázisból jön, a felhasználó kiválasztaná az ügyfelet, de nincs még az adatbázisban, így egy új felületen létrehozza az új ügyfelet, majd visszamegy az eredeti űrlaphoz, nulla újratöltés történt, de minden pont úgy néz ki, ahogy előzőleg hagyta, és sehol nem kellett többet várni, mint a minimál.
Ugyanaz szerver oldalon? Amikor másodszorra jelenik meg a számla űrlap, probléma, hogy az eddig kitöltött adatokat visszatedd, probléma, hogy másodszor futnak le azok a lekérések, amelyek az űrlaphoz tartoztak. Nagyon sok megoldandó probléma, ami az előbbi esetben fel sem merül.
Ki mondta, hogy vékony
Pedig meg akarjuk spórolni...
Ha a rendszer érzékeny a devizaárfolyam változásra, akkor nem csak akkor kell ennek életbe lépnie, ha új ügyfelet adtunk a rendszerhez számlakészítés közben, hanem akkor is, amikor az adminisztrátor számlakészítés közben megy ki kávézni...
Ezzel nem értek egyet. A
feladom
Nagyon fontos a pénzügyekkel foglalkozó űrlapoknál a legfrissebb állapot, emiatt minden mezőmódosítás után töltsük újra a teljes űrlapot? Mert, ha tényleg ezt mondod, akkor feladtam.
Vastag kliens esetén akár célirányosan tudom figyelni a megfelelő mezők értékét, a mindent mindig töltsünk újra és majd a szerver megmondja a tutit az szerintem nemhogy pazarló, de biztosan nehezebben kezelhető.
Ám kifogytam az érvekből, így részemről lezárható a téma.
nem kód, adat
pp
Nem, eredetileg a programkód
Egyszerű
Mi ezeket az összefüggéseket nem tartjuk nyilván, mivel számuk tetszőleges lehet, ehelyett bármilyen adatváltozáskor újratöltünk minden szükséges adatot. A programunk így egyszerű és gyors marad. Az adatmennyiség nem nagy, amikor az adatbázismotor megtalál egy sort, ígyis-úgyis beolvassa az adatait a memóriába, innentől kezdve viszont nagyjából mindegy, hogy egy vagy száz mező adatait kell memóriából memóriába másolni. Hálózati szinten is elhanyagolható, hogy kétszáz vagy nyolcszáz bájtot küldök ki.
Ebben a témában én egyet
Az érvem egyszerű és önző: napi szinten okoz problémát egy öt éves – ami azért annyira nem régi – laptopon az, hogy két-három percre, de néha akár végleg elveszti a reszponzivitását a gép szkript futtatás közben. Olyan jelentéktelen oldalakról van szó, mint a Facebook, az Index, a 444 (ó, a horror!) vagy a Google gyakorlatilag bármilyen terméke.
Namost, ha ilyen erőforrásokkal rendelkező cégeknek nem sikerül kliensoldali webalkalmazást írni, akkor átlagfejlesztőknek azt javaslom, hogy inkább maradjanak a deklaratív megoldásoknál, azt viszonylag nehéz ennyire elbaszni.
Mindezt szigorúan a saját felhasználói élményem szem előtt tartva.
A web frontend része
Aki elég ideje benne van a szakmában, értheti a dolgokat, de az újonnan jövők számára egyre magasabb a belépési küszöb, ennek az eredménye, hogy az általad említett oldalak úgy működnek, ahogy.
Minden újabb eszköz az entrópiát növeli, és végeredményben visszafelé fejlődünk. Szerintem a megoldás az lenne, ha egyszerűsítenénk, és kidobnánk a ballasztot.
store events
Ahogy szerver oldalon is szokás az adatokat elválasztani a megjelenéstől, úgy ez már "divat" kliens oldalon is, majd miután ez megvan, a fenti problémákkal már lényegesen könnyebb boldogulhatsz. Tehát nem a komponens eseményeit figyeljük, hanem az adat eseményeit, és ehhez segítség a keretrendszer.
Erdekes vita
Kedves Hídvégi Gábor: Nem szeretném szerve oldalra vinni a kliens kérdéseket. :) Értem, és egy kicsit egyet is értek az érveiddel. Azonban a felhasználói élmény, a felhasználói kényelem és lehetőségek messze nagyobbak, ha valamekkora terhelést ráteszel, a kliensre.
Én meg tudom tenni az én admin felületemmel, hogy a user felvisz egy partner céget, félig kitölti az adatait, majd rájön, hogy kell egy kapcsolattartó is, és felvisz egy kapcsolattartót, majd befejezi a partner cég adatait és menti a céget.
A szerver oldali alkalmazás esetén nagy valószínűséggel kilép a cég felvitelből, veszti a munkáját, felviszi a kapcsolattartót, majd bosszankodva újraírja a cég adatait.
De számtalan példa van, amire én azt mondom, megéri a kliensre terhelni egy kis munkát. Persze NEM mindent, mert akkor meg, ahogy mondod, túl vastag lesz a kliens!
Egyébiránt a jelen kérdésemet is pont karcsúsítási okokból tettem fel.
A program visszafejtése pedig - legalábbis ha csak a szükséges dolgokat terheled a kliensre - nem lesz visszafejthetőbb. Mi történik ha belenéz valaki a kódba? Megtudja, hogy kattintásra ablak nyílik és lekéri az adatokat ajaxban?
Egyékbént a szinte teljesen kliens oldali megoldást is rossznak tartom. Pont az érveid miatt.
szabo.b.gabor: Angular JS, igen. Ezen gondolkodom. Hozzányúltam már, de nem túl mélyen ismertem meg.
Kedves t.g. bár nem tudom melyik keret rendszerre gondolsz, mondhatnál egyet, ami hasonlót csinál, de hasonlóban gondolkodom ugye én is.
A jelenlegi elképzelésem az, hogy lesz egy adatforrás kezelő objektum, ami tölti az adatot, és újratölt ha kell, pár perc után, ha senki nem kérte le az adatot, akkor elpusztítja önmagát. Lehetne maszkolva kérdezni az adatokat. így több plugin használhatná.
Jelenleg a select2 jquery combobox miatt merült ez fel. Aminek adatforrásként ez jól működne. Még végig kell néznem a többi plugin-t hogy elbírják-e ha csak ennyit tud a rendszer.
Ránézek még gyorsan most az Angular-ra, ha jól emléxem ott is volt valami adatforrásos dolog.
Azonban a felhasználói
A szerver oldali alkalmazás esetén nagy valószínűséggel kilép a cég felvitelből, veszti a munkáját, felviszi a kapcsolattartót, majd bosszankodva újraírja a cég adatait.
Nem szeretném nagyobbítani
Ez nézőpont, súlyozás kérdése. Ki - mit tart fontosabbnak, és eszerint módosítja a fejlesztési irányt. Én nem állítom, hogy a Te, vagy az én nézőpontom a jobb. Szerintem másra helyezzük a hangsúlyt - kicsit.
Így hát csak 1 példát mondok, és csak azért mondok egyáltalán példát, hátha világosabb lesz a nézőpontom.
Egy crm rendszer kezdő elemeit csináltam meg egy könyvelő cégnek.
Visznek fel Cégeket, és magánszemélyeket, más-más űrlappal.
namost menüben ki lehet választani, hogy épp melyik listát nézik. Cégek, igazgatók, vagy részvényesek listáját.
Első verzióban egy gombra kattintva lehetett felvinni a cégeket - egy dialogban -, és a magánszemélyeket, de mindig csak 1 új felvitel ablak lehetett nyitva. Gondoltam, hogy majd "sorrendben" viszik fel. Hát már az első tesztnél elhajtottak, hogy ők bizony a céget viszik fel, és KÖZBEN akarják hirtelen felvinni a céghez tartozó igazgatókat, és részvényeseket.
Ha szerveren oldod meg, szerintem problémád lenne, hogy 3 különböző űrlapot tarts meg, és minden alkalommal újra töltsd az oldalt.
Persze tán megoldható, ha sokat filóznék rajta, lehet még én is megoldanám, pedig pici ember vagyok én, de szerintem nem olyan egyszerű az. Gondolom az a minimum, hogy mindig minden űrlapos aloldalt postolni kellene, és mindent egy postba rakni. amit vagy javascripttel pakolsz össze, vagy a body mögött már egyből indítod a form taget.
Ti hogyan oldanátok meg?
Konzisztencia
Első prekoncepció: vékony kliens esetében a szerveren az adott felhasználónak nem lehet nyitva több űrlapja.
Kérdés: Miért ne lehetne a szerveren futó alkalmazás memóriájában több nyitott űrlap adatait tárolni, mi akadályoz meg benne?
Második prekoncepció: vastag kliens esetében egymásra űrlapok bezárásánál nem kell a megmaradókon újratölteni az adatokat.
Mint fentebb jeleztem, vannak adatok, amelyeknek mindig a legfrissebbeknek kell lenniük a felhasználónál. Emiatt a fenti példádban az Új igazgató ablak bezárásakor a Cég oldalt mindenképp újra kell tölteni, mert sosem tudhatod, hogy nincs-e másik űrlap, ahol ugyancsak lehet új igazgatókat felvinni. Lehet, hogy most nincs, de mondjuk a megrendelőd kitalálja, hogy máshol is lehessen. Nem a spórolás a fontos, hanem a konzisztencia, hogy mindig az aktuális adatokat lássa a kliens a képernyőn.
Innentől kezdve sem vékony, sem pedig vastag kliens esetében nem tudod megtakarítani az újratöltést. Abba az utcába pedig nem szabad belemenni, hogy megjelölni azokat az űrlapokat vagy adatokat, amit újra kell tölteni és amit nem.
Ha kicsit belegondolsz, a konzisztenciát kliensoldalon lehetetlen megvalósítani, mert az adatbázishoz nincs közvetlen hozzáférés.
Bocs, de ez túl magas labda... :)
Ha kizárjuk a helyes megoldást, akkor nehéz megoldani a problémát! :)
Elbonyolítja a szoftvert és a
Szerintem...
Ha másvalaki véleményét írom
Lehet...
Occam borotvája
1, meg kell jelölni az űrlapot, hogy ezt mindenképp újra kell tölteni,
2, meg kell jelölni a táblákat, aminek az adatai ha szerepelnek űrlapon, azt mindenképp újra kell tölteni
3, meg kell írni a kódot, ami a fenti feltételeket kezeli.
Ez három hibázási lehetőség. Ha egy nagy rohanásban (ami bármikor előfordulhat) az első két pont valamelyikéről elfelejtkezik a fejlesztő, előbb-utóbb inkonzisztens adatok jelennek meg a felhasználónál, és ő hibás döntést fog ezek alapján hozni. A felelősség a tied, tehát célszerű a hibázási lehetőségek számát a legalacsonyabbra csökkenteni (0-ra nem lehet), amit úgy lehet elérni, ha minél egyszerűbb a kód.
Általában az egyszerűbb megoldás a helyes.
Egyszerűség
2. egy forrás akár több komponenshez is tartozhat
3. ha a forrás változik, akkor automatikusa változik a komponens
A rendelkezésre álló segédeszközök segítségével minden megoldható, semmi pluszt nem kell hozzáadni. Persze, ha nem használnék keretrendszert, akkor sok munkám lenne, de azért használ az ember keretrendszert, hogy ne kelljen újra feltalálni a spanyolviaszt. A témanyitásban leírt probléma megoldása az majdhogynem Getting Started cikkekben szerepelhetne, annyira egyszerű. Feltéve, ha megfelelő segédeszközöket használunk.
Magyarán az általad írt három pontból mind az 1-es, mind 2-es pontot át kell fogalmazni, nem a komponens eseményeit, hanem az adat/adatforrás eseményeit figyeljük. 3-as pontra meg a fentebb írtak igazak, ne írjuk meg azt, amit előttünk más okos emberek már megírtak.
Nekem tényleg ez tűnik egyszerűbbnek.
Rendben van, amit írsz, és
Viszont mivel az adatok a szerveren vannak, ez felveti azt a problémát, hogy bizonyos rekordműveleteket csak ott lehet elintézni, például: adatok zárolása, írás lehetőségének ellenőrzése, jogosultságok ellenőrzése, adatformátumnak való megfelelés. Ezek miatt minden alkalommal a szerverhez kell fordulni, és jogosan merülhet fel a kérdés: az adatok kiírásán kívül miért is csináljunk bármi mást a kliensen? Persze ott is lehet ellenőrizni, de mivel megbízhatatlan, sokat nem érünk vele, a szerveren is mindenképp kell.
Innentől kezdve viszont nem értem, milyen felhasználói élményről beszéltek, hisz a hálózathoz kell fordulni. Viszont még egy mobilneten is nagyjából mindegy, hogy kétszáz vagy ezer bájtot töltesz le, ezek feldolgozása pedig végképp elhanyagolható.
Kliens oldalon nagyon sok ellenőrzés elvégezhető...
Vegyünk egy egyszerű felhasználó regisztrációt, hány olyan szabály van, ami kliens oldalon ellenőrizhető? És ne gondoljuk, hogy egy kérdőív készítő panelon több szerver oldali ellenőrzés szükséges. Sőt. Számtalan üzleti terület van, ahol nem kell minden mezőt adatbázisból ellenőrizni. Persze van, ami nem ellenőrizhető kliensen, de erre mondom én, hogy ekkor merül fel az, hogy innentől ugyanakkora a forgalom, ám előtte már sokat megspóroltam.
Az meg a mi esetünkben nem szempont, hogy a kliens oldali ellenőrzés kikerülhető, a mi ügyfeleink nem szeretnék az ellenőrzéseket kikerülni, csupán azt szeretnék, hogy nulla másodperc alatt jelezzük, ha valami mégsem jó. Kliens oldali ellenőrzéssel ez a szám hozható.
De ami számomra nem egyértelmű, hogy ha az egész űrlapot újragenerálom, akkor számtalan select választható értékét is újra kell generálnom, ilyen lekérések erős kliens esetén biztosan csak egyszer merül fel, míg az űrlap újragenerálásakor minden egyes alkalommal. Ez biztosan felesleges plusz.
Mivel a kliens eleve
Emellett a vastag kliensnél az üzleti logikával kapcsolatos dolgokat a kliensen tárolod, azaz ha változás van a modellben, újra le kell szedni a megfelelő scriptet. Lehet, hogy az ellenőrzéseknél megtakarítasz egy tizedmásodpercet, de a kliens töltögetéseinél mindezt el is veszted, tehát ugyanott vagy, ahol a part szakad.
Abban biztos vagyok, hogy ilyet magától egy ügyfél sem kért. Legfeljebb ti kérdeztétek úgy, hogy "szeretné, ha nulla másodperc alatt végeznénk el a hibák ellenőrzését?". De ez nem jó, mert nem bontja ki az igazság minden részletét. "Ön számára az adatbiztonság vagy a gyorsaság a fontos?" - ez már sokkal jobb lenne.
De, mint feljebb jeleztem, adat írásakor ígyis-úgyis a szerverhez kell fordulni. Így viszont hiába ellenőrzöd kliensen, hogy megfelel-e az adott karakterlánc egy reguláris kifejezésnek, ha az illetőnek nincs joga a mezőt írni. Így viszont csak az idejét raboltad azzal, hogy rákényszerítetted a helyes formátumra, aztán meg a beküldéskor kiderül, hogy a rekordot közben zárolták.
olyan szép ahogy mindenki
ahogy a 'vékonykliens' nem jelenti azt, hogy az egész formot újra kell tölteni
úgy egy 'vastagkliens' sem jelenti azt, hogy ne lenne szerver oldali ellenőrzés
beszélhetünk arról, hogy egy vékonykliens kevésbé összetett, ha ezt az összetettséget egy framework elfedi nekünk vastagkliens használata esetén.
ennyi erővel nyissunk vitát arról, hogy milyen pózban jobb szexelni.
úgy egy 'vastagkliens' sem
nem érdekel, hogy idióta
nem fogok egy regex ellenőrzést elküldeni a szervernek, mert nem szeretnék minden szar kis hülyeséget külön külön ellenőriztetni a szerverrel, ha a kliens oldalon átmegy az ellenőrzésen (ami ott elvégezhető), akkor terhelem a szervert. kliensnek is jobb, meg a szervernek is. (vitatkozhatsz vele, de a kliens oldali ellenőrzés akkor is gyorsabb egy regex esetén)
de itt ezek még mindig egyszerű dolgok, nem feltétlen 'vastag kliens' ez..
mondjuk azt, hogy vastagkliens egy vanpédzsapp.
kliens oldalon van a routing, controllerek, a szerverről pedig azt kéri le ami kell. újra felhasználható template-eket, adatokat, a kliens meg legenerálja a megjelenítendő oldalakat.
úgyis kell renderelnie, a html előállítása nem akkora overhead (időben _szerintem_ gyorsabb). nem változó listákat nem kérek le többször, csomót spórolsz szintúgy..
Ez fájt.
ExtJS + AngularJS
Hobby projektekben AngularJS is próbálgatom, a fenti probléma itt is könnyen megoldható, egy változó változása egyszerűen tud a HTML oldalon több helyen is változást előidézni, mindenféle eseménykezelés nélkül. ExtJS-ben is sok varázslat van, de számomra úgy tűnik, hogy az AngularJS-ben sokkal több, mindenesetre a lényeg, hogy neked semmivel sem kell foglalkoznod, egyszerűen csak működik.
Az Angulart azért nem biztos,
Kettős érzés
Viszont pont emiatt nem vagyok biztos benne, hogy egy kezdőnek ez annyira rossz. Ha valaki elfogadja, hogy van varázslat és nem kell mindent érteni, akkor lehet, hogy ez kiváló választás. Ha megnézünk egy ExtJS példakódot, meg egy AngularJS példakódot, akkor biztosan az AngularJS ajánlanám egy kezdőnek, egészen addig, míg nem nézel be a gépház mögé.
Picit belenyultam már
Egy mobil verzió megjelenítéshez használtam, pont hogy megismerhessem. Tetszik az angular nagyon, de nem találtam akkor ui elemeket hozzá, most viszont még azt is találtam.
Hát nagyon kacsintgatok most megint.
Egyébként T.G érdekességként: Az Extjs a másik amivel sokáig szemeztem, mert tetszik,
és a monogrammom pedig G.T :)
jqueryt azért használok, mert rákeresek egy ui elemre, és valaki már biztos kitalálta. Igazából általában többen. :)
Tudsz esetleg az angular-hoz valami magyar leírást, összefoglalót, stb? Az angolom nem annyira jó, szeretek magyarul is utána nézni dolgoknak.
Én idén két éles projektet
Más tapasztalat
A duplikált markup gyanítom direktívákkal kiváltható lenne, a varázslat körüljárására pedig vannak tök jól definiált event-ek általában. Szerintem a doksija is jó.
szerintem nem vészes a
Egy tapasztalt fejlesztő gyorsan belerázódik, de én vallom, hogy nem érdemes kihagyni lépcsőfokokat, és amíg nem tudnád magad is megírni a keretrendszert, amit használsz, addig folytasd a tanulást.
Itt például olyan tervezési hibákra gondolok, hogy a sablonokban a feltételvizsgálat a feltételesen megjelenített elem attribútuma, ezért ha több elemet akarsz feltételesen megjeleníteni, akkor vagy mindegyiken megismétled a feltételt, vagy körülveszed őket egy semmilyen más célt nem szolgáló divvel, illetve mivel ennek következtében else ág sincs, így azt újabb – negált – feltételekkel tudod csak megvalósítani.