Angular, Ember, js templétezés
Már egy jó 3 hete azon vagyok, hogy úgy írjam át a weboldal rendszerem Adminisztrációs felületét, hogy az a lehető legkönnyebben karbantartható legyen.
Belefutottam az angularjs-be aztán az emberjs-be, illetve maga a js templétezésbe, melyekből egy remek koncepciót dolgoztam ki magamnak, de valahogy nagyon nem akar összeállni a kép.
A kezdeti problémám az volt, hogy milyen nagy lehet egy "egyoldalas" app. Ami cikkeket nagy nehezen találtam az angularjs-sel kapcsolatban, java része mindig megjegyzi, hogy "azért igazából ne akarj túl nagy appokat létrehozni".
Jó, gondoltam, akkor felosztom több kicsi egységre, merthogy az én weboldal rendszerem nemhogy nagy, hanem lassan már a hatalmas kategóriát nyaldossa - és még egy csomót kéne rajta bővíteni.
Aztán az emberjs kezdett nagyon szimpi lenni, de az is úgy kezdi "határozzuk meg a routing-ot". Hát ez az ami nem fog menni! Ugyanis ez egy "központi" rendszer, amihez egy csomó weboldal csatlakozhat, természetesen egyedi modulokat is tartalmazhatnak - tehát dinamikusnak kell lennie.
Na jó, ezen is túl tettem valahogy magam. Gondoltam majd megoldom szekciónként, merthogy tényleg valahogy a js tudtára kell adni, meddig terjed a jelenlegi szekció (ugye több kicsi egységre bontom).
De mi van az adminon?! Rengeteg listanézet (gridview), meg persze űrlapok a különböző izék szerkesztéséhez.
A tervem az volt, hogy úgy szekcionálok, hogy listanézet + űrlap. Pl a bejegyzések listanézete meg a bejegyzés szerkesztése egy szekció.
Na de itt jön a feketeleves, ahol már tényleg rémálommá kezd válni az egész. És erősen kezdek bizonytalan lenni abban, hogy van értelme ezt az irányt folytatni.
Betölt kb az "üres" admin, és indul a js, ami egyből visszafordul a szerverre, hogy lekérje az adott szekció adatait, pl a listanézet adatait. De mennyi terméket küldhetek le a listába?! Oké, 1000 termékig még csak nincs baj, de mi van ha valaki a katalógusba feltölt 10e terméket?!
És mi van a szűrésekkel. Terméknévre könnyen lehet szűrni js-sel is, de az már fogósabb amikor egy kategóriára kell leszűrni a termékeket, merthogy akkor kellene hozni az alkategóriáiba rakott termékeket is. Ezt csak szerveren tudom megoldani, vagy küldjem le egyrészt egy legördülőbe a kategóriákat, meg fanézetben is, amiből egy filter leszűri melyik kategóriák termékeit kell kilistázni?!
Vagy tegyek bele "kapcsolókat"?
- ha több mint 1000 termék van, akkor mindig szerverről kérje az adatot
- ha ezt a szűrőt használja, akkor is a szerverről kérje az adatot
- ha ...
ellenben szűrje a letöltött listát?!
És akkor ne is beszéljünk olyan szűrési feltételekről, ha pl "listázz ki minden olyan terméket, aminek az x jellemzője y értékű" :)
Csak a móka kedvéért, merthogy a termékek (dinamikusan) paraméterezhetőek!
És akkor, nekem mindenféleképp frissítse az URL-t a szűrés alapján (ez nem is gond), de akkor a képlet a következő:
1, betölt az "üres" weboldal, indul a js
2, lekéri a lista dolgait
és
3, lekéri a leszűrt listát (ismét)?!
merthogy amíg nem teszi meg a 2. lépést, addig honnan tudná, mit figyeljen az URL-ben????
--ez így már nem túl gazdaságos, főleg hogy ez egy többnyelvű rendszer, és mind a 3 lépésben még a lokalizációt is el kell végeznie, ami persze szintén dinamikus (azaz db-ben van tárolva, melyik az "alapnyelv")
Tehát itt már kezd egy kicsit rémálom lenni!
És ekkor rákattintunk a termék módosítására. De visszalépve a listára megint csak frissítenem kell a listát, hiszen mi van ha termék kategóriáját módosították, és arra van szűrve a lista?! vagy a nevét?!
Arról ne is beszéljünk, hogy már az is móka, hogy a módosított termék lista adatait frissíteni kell - valahogy...
És akkor még az űrlapok kezeléséhez hozzá sem kezdtem! Na még ott is milyen fejtörők lesznek?!
Az a vicces, hogy rengeteget olvastam az angularjs és az emberjs-ről is, de minden tutorial elvan egy max pár 100-as listával, benne tök egyszerű elemekkel,
aminek a működését nativ js-sel is le lehetne tolni max 1 óra alatt :D
Szóval ezek a problémáim, nem tudom valaki közületek dolgozott már hasonló js framework-ökkel hasonló méretű rendszeren?!
Van értelme belemenni?!
Tudtok ajánlani olyan cikkeket, amik nem a fentebb említett tök primitív badarságokkal játszanak, hanem komoly, az életben is használható összetett rendszerek megvalósítását írják le?
vagy legalább elmélkednek róla?
Előre is köszi,
és bocsi hogy így rátok ömlesztettem az elmúlt 3 hetem agyalását
■ Belefutottam az angularjs-be aztán az emberjs-be, illetve maga a js templétezésbe, melyekből egy remek koncepciót dolgoztam ki magamnak, de valahogy nagyon nem akar összeállni a kép.
A kezdeti problémám az volt, hogy milyen nagy lehet egy "egyoldalas" app. Ami cikkeket nagy nehezen találtam az angularjs-sel kapcsolatban, java része mindig megjegyzi, hogy "azért igazából ne akarj túl nagy appokat létrehozni".
Jó, gondoltam, akkor felosztom több kicsi egységre, merthogy az én weboldal rendszerem nemhogy nagy, hanem lassan már a hatalmas kategóriát nyaldossa - és még egy csomót kéne rajta bővíteni.
Aztán az emberjs kezdett nagyon szimpi lenni, de az is úgy kezdi "határozzuk meg a routing-ot". Hát ez az ami nem fog menni! Ugyanis ez egy "központi" rendszer, amihez egy csomó weboldal csatlakozhat, természetesen egyedi modulokat is tartalmazhatnak - tehát dinamikusnak kell lennie.
Na jó, ezen is túl tettem valahogy magam. Gondoltam majd megoldom szekciónként, merthogy tényleg valahogy a js tudtára kell adni, meddig terjed a jelenlegi szekció (ugye több kicsi egységre bontom).
De mi van az adminon?! Rengeteg listanézet (gridview), meg persze űrlapok a különböző izék szerkesztéséhez.
A tervem az volt, hogy úgy szekcionálok, hogy listanézet + űrlap. Pl a bejegyzések listanézete meg a bejegyzés szerkesztése egy szekció.
Na de itt jön a feketeleves, ahol már tényleg rémálommá kezd válni az egész. És erősen kezdek bizonytalan lenni abban, hogy van értelme ezt az irányt folytatni.
Betölt kb az "üres" admin, és indul a js, ami egyből visszafordul a szerverre, hogy lekérje az adott szekció adatait, pl a listanézet adatait. De mennyi terméket küldhetek le a listába?! Oké, 1000 termékig még csak nincs baj, de mi van ha valaki a katalógusba feltölt 10e terméket?!
És mi van a szűrésekkel. Terméknévre könnyen lehet szűrni js-sel is, de az már fogósabb amikor egy kategóriára kell leszűrni a termékeket, merthogy akkor kellene hozni az alkategóriáiba rakott termékeket is. Ezt csak szerveren tudom megoldani, vagy küldjem le egyrészt egy legördülőbe a kategóriákat, meg fanézetben is, amiből egy filter leszűri melyik kategóriák termékeit kell kilistázni?!
Vagy tegyek bele "kapcsolókat"?
- ha több mint 1000 termék van, akkor mindig szerverről kérje az adatot
- ha ezt a szűrőt használja, akkor is a szerverről kérje az adatot
- ha ...
ellenben szűrje a letöltött listát?!
És akkor ne is beszéljünk olyan szűrési feltételekről, ha pl "listázz ki minden olyan terméket, aminek az x jellemzője y értékű" :)
Csak a móka kedvéért, merthogy a termékek (dinamikusan) paraméterezhetőek!
És akkor, nekem mindenféleképp frissítse az URL-t a szűrés alapján (ez nem is gond), de akkor a képlet a következő:
1, betölt az "üres" weboldal, indul a js
2, lekéri a lista dolgait
és
3, lekéri a leszűrt listát (ismét)?!
merthogy amíg nem teszi meg a 2. lépést, addig honnan tudná, mit figyeljen az URL-ben????
--ez így már nem túl gazdaságos, főleg hogy ez egy többnyelvű rendszer, és mind a 3 lépésben még a lokalizációt is el kell végeznie, ami persze szintén dinamikus (azaz db-ben van tárolva, melyik az "alapnyelv")
Tehát itt már kezd egy kicsit rémálom lenni!
És ekkor rákattintunk a termék módosítására. De visszalépve a listára megint csak frissítenem kell a listát, hiszen mi van ha termék kategóriáját módosították, és arra van szűrve a lista?! vagy a nevét?!
Arról ne is beszéljünk, hogy már az is móka, hogy a módosított termék lista adatait frissíteni kell - valahogy...
És akkor még az űrlapok kezeléséhez hozzá sem kezdtem! Na még ott is milyen fejtörők lesznek?!
Az a vicces, hogy rengeteget olvastam az angularjs és az emberjs-ről is, de minden tutorial elvan egy max pár 100-as listával, benne tök egyszerű elemekkel,
aminek a működését nativ js-sel is le lehetne tolni max 1 óra alatt :D
Szóval ezek a problémáim, nem tudom valaki közületek dolgozott már hasonló js framework-ökkel hasonló méretű rendszeren?!
Van értelme belemenni?!
Tudtok ajánlani olyan cikkeket, amik nem a fentebb említett tök primitív badarságokkal játszanak, hanem komoly, az életben is használható összetett rendszerek megvalósítását írják le?
vagy legalább elmélkednek róla?
Előre is köszi,
és bocsi hogy így rátok ömlesztettem az elmúlt 3 hetem agyalását
pihenj egy kicsit :)
ha szerver oldalon generálsz, akkor sem kéred le az összes rekordot és kezded el phpban szűrögetni. no hát itt se csináld. megvan az a pár paraméter ami meghatározza, hogy milyen szűrőkkel, hogyan rendezve, hányadik oldal elemeit kéred. ennyi.
pl ezt nézd át, mielőtt nagy projektbe kezdenél
https://github.com/johnpapa/angular-styleguide
annyi, hogy a szerver csak nyers adatokat küld neked, és a html bullshitet kliens oldalon teszed köré, meg a felületet működtető logikát vagy mit :)
jó lesz az
Nekem is nehéz volt, amikor először dolgoztam hasonló cuccal, én Backbone-nal kezdtem, utána jött az Angular. Rááll az ember a PHP-val szerveren HTML generálásra, ami jár egy rakás beidegződéssel... Könnyebb lenne persze egy kisebb projekttel indulni, kitapasztalni a dolgokat, de hát a helyzet adott.
A lényeg, hogy egyszerűsíts. Először is legyen egy működő API-d a szerveroldalon, amit tudsz hívogatni és tökéletesen elvégzi a feladatát. Ez kizárólag csak adatokat küldjön és fogadjon. Eköré már könnyen felhúzhatod a kezelőfelületet. A szerveroldal a HTML-hez semmilyen formában ne nyúljon, ne is kötődjön a logikájukhoz.
Ha kétségeid vannak, válaszd mindig az egyszerűbb megoldást. Például ha lehet 10000 termék egy kategóriában, akkor a szűréshez mindig kérdezze a szervert, a kliensen ne tárolja az eredményeket, hanem mindig dobja el. Egyszerre küldjél mindig annyi adatot, amit meg is jelenítesz. Ha több adatot akarsz (paging, infinite scroll, hótmindegy), indíts új lekérést. Mindig új lekérés. Az admin tipikusan nem az a hely, ahonnan a terhelés jön. Ritkán használja egyszerre kevés júzer. Majd ha úgy észleled, hogy problémákat okoz, elkezdhetsz azzal foglalkozni, hogy mit kesselj és hol.
Az űrlapoknál különösebben óriási bonyolultság nem lép fel. Lekéred az egyed adatait a szervertől, kirakod a template-be. Ha menti, hívod az API megfelelő pontját, a választ feldolgozod. A kliens oldali validációnál felmerül, hogy nem akarod kétszer specifikálni a szabályokat, ezért érdemes valami olyan közös szabályleírót használni, amit a kliens és a szerver is ért. Korábban többször is dolgoztam Laraveles backendre (én csak a frontendet írtam), ezért pl. írtam egy JS eszközt, ami érti és alkalmazza a Laravel validációs szabályait.
A UI nyelvesítését én a helyedben átvinném a kliensoldalra. Az angular-translate nevű cuccal jó eredményeket értem el. Ami az adatok nyelvesítését illeti, ezt az API-dnak le kell kezelnie.
Én is azt mondom, hagyd egy kicsit letisztulni a dolgot. És ne bonyolítsd, ne komplikáld túl.
A legegyszerűbb út
A legelső kérdés, hogy hogy jön a képbe a javascript, milyen szerepet szánsz neki? Használhatóság, usability?
Az ilyen JS keretrendszerek tapasztalataim szerint valóban nem alkalmasak nagyobb adattömeg, összetett űrlapok megjelenítésére, ilyen esetekben használhatatlanra lassulnak, ráadásul a kódjuk bonyolultsága miatt csak viszonylag kevés optimalizációs lehetőséget adnak a kezedbe. Emellett a kódod egy része arról fog szólni, hogy a keretrendszer különböző API-jait hívd.
Az ilyen adminisztrációs felületek tipikusan minimális grafikával és viszonylag egyszerű sablonokkal dolgoznak, tehát várhatóan gyorsak lesznek. Emiatt én például biztosan HTML alapúra készíteném el, hogy működjön mindenféle scriptelés nélkül, majd pedig utólag ajaxosítanám.
Mit jelent ez? Hagyományos
<form>-okat generálnék,<input>mezőkkel és társaikkal. Minden adatot szerveroldalon ellenőriznék és dolgoznék fel. A kliensen semmi mást nem végeznék, csak az űrlapok és adatok megjelenítését, így biztosítanám, hogy minden funkciót csak egyszer kell elkészíteni.Az ajaxosítás azt jelenti, hogy van egy darab eseménykezelő, amivel figyeled, mi történik a kliensen, például valaki egy
<select>elemet használva rászűr az egyik mezőre, ekkor indítanék egy ajax kérést, ami POST-olja a szűrő<form>adatait. A teljes kliensoldali script tíz kilobájtos nagyságrendű.Ha igazán jól szeretnéd megcsinálni, akkor érdemes kettéválasztani az adatokat és a megjelenítésüket, ahogy kapa ajánlja. Én erre XML alapú sablonozást használnék (XSLT), mert viszonylag egyszerű, valamint szerver- és kliensoldalon minden nyelvben van hozzá interpreter (azaz például JS-ben és PHP-ban is). Már jópár ilyen projekten vagyok túl, roppant egyszerű a működésük: a szerveroldalon egy XML-t állítok elő, majd pedig a bejövő kérés alapján eldöntöm, hogy melyik oldalon állítsam elő a HTML-t.
Jó iránynak tartom, de
Azért most megerősítenélek, hogy jó iránynak tartom. Én jó ideje az ajaxos admin felületek rajongója vagyok - hátránya mellett (kliens oldali terheltség).
Sajnos azonban még nem tértem át a teljes kliens oldali felépítésre, ami alatt azt értem, hogy nálam még a legtöbb esetben a szerver oldal állítja elő a html-t. Viszont egyre jobban érzem, hogy logikátlan a kliens oldalt szerver oldalról programozni, és nagy buktatókkal is bír.
Persze azt is tudom hogy többen vitatnák az én hozzáállásomat. :)
A te agyalásodban én csak 1 problémát látok - amit én magam is elkövettem -, hogy a modelleket is ki akarod vágni kliens oldalra. Na az nem oda való. Én azt hagynám a szerverre, és mindig azt kérném le amire szükség van.
de kell
hiszen azzal töltöd fel a html templatet
Igen, de félreérthető voltam
köszi srácok a hsz-eket
Most már nem szenvedek tovább ezzel,
az admin 90%-a így is ajax-os
és elég gyors
egyedül ez a model - js templétezés nincs benne
hát most sem fog belekerülni
majd talán egyszer...
ha lesz időm alaposabban foglalkozni ezzel
de haladni kell a melóval, erre most nincs időm :(
még egyszer köszi :)