Javascript hatókör, betöltés, eltávolítás
Tanácsot szeretnék kérni.
Adminisztrációs felületek programozásánál én előnyben részesítem az ajaxot, és az „ablakos” megjelenítést.
pl.: Egy user listánál maga a lista gridben jön elő ajaxal, míg mondjuk a user szerkesztés már egy popupban - ajaxal.
A konfliktus, amit szeretnék megoldani:
Az ablakozás előnye – ami a hátránya is -, hogy akár 4-5 ugyan olyan html kód kerülhet ki az oldalra (több user adatai, mind ugyan azon HTML kódrészt használják). Az ablak megjelenítés template-jébe azonban javascript kódok is bekerülhetnek, funkciók kerölhetnek deklarálásra. stb. És ez 2 okból gond:
Egyrészt, duplikáció keletkezhet, másrészt feleslegesen felhalmozódnak a javascript funkciók a memóriában.
Van ötletetek, hogyan lehetne ezt „megoldani”? Megoldja ezt pl az Angular?
Az eddigi megoldásom, hogy ajaxal lekérem a html template-et, ami beillesztésre kerül. és ugye „beindul” a benne lévő javascript. Ez azonban felveti a problémákat.
■ Adminisztrációs felületek programozásánál én előnyben részesítem az ajaxot, és az „ablakos” megjelenítést.
pl.: Egy user listánál maga a lista gridben jön elő ajaxal, míg mondjuk a user szerkesztés már egy popupban - ajaxal.
A konfliktus, amit szeretnék megoldani:
Az ablakozás előnye – ami a hátránya is -, hogy akár 4-5 ugyan olyan html kód kerülhet ki az oldalra (több user adatai, mind ugyan azon HTML kódrészt használják). Az ablak megjelenítés template-jébe azonban javascript kódok is bekerülhetnek, funkciók kerölhetnek deklarálásra. stb. És ez 2 okból gond:
Egyrészt, duplikáció keletkezhet, másrészt feleslegesen felhalmozódnak a javascript funkciók a memóriában.
Van ötletetek, hogyan lehetne ezt „megoldani”? Megoldja ezt pl az Angular?
Az eddigi megoldásom, hogy ajaxal lekérem a html template-et, ami beillesztésre kerül. és ugye „beindul” a benne lévő javascript. Ez azonban felveti a problémákat.
Az ablak megjelenítés
Egyrészt, duplikáció keletkezhet, másrészt feleslegesen felhalmozódnak a javascript funkciók a memóriában.
De ha ez kérdésként felmerült benned, akkor szerintem a fentebb vázolt dolgokkal inkább ne foglalkozz, ha sok bosszúságot szeretnél megtakarítani magadnak.
Miért jó az, ha a felhasználók adatai popupban jelennek meg és nem külön oldalon? Olyan sokszor kell egymás mellett többük adatait ellenőrizni? Mert ha csak ritkán, akkor egyszerűbb, ha az adminisztrátorok két külön tabon megnyitják a rendszert, és úgy böngésznek. Így a kérdésed (duplikáció, memóriafoglalás) soha nem is fog felmerülni.
De ha már mindenképp ragaszkodsz a popuphoz, akkor miért nem használod a beépített
window.openmetódust, és akkor így külön folyamatként fog elindulni minden ablak? Azaz megint nem fog előjönni a fenti probléma, ráadásul nem kell saját ablakkezelőt írnod.User friendly
Pont ezért a window.open sem jó. Az már nem ugyan az.
Mindenképpen ezt használom, de reméltem, hogy van valami "tisztító" lehetőség.
Mindenesetre köszönöm!
window.open
Egy 5let.
pl.:
jsModules.function1 = ...
jsModules.function2 = ...
és delete jsModules.function1
Akár
Lehet megint nem látom át a
Törölni, ha már nem kell.
Ha jól értelmezem a
Én onnan indulnék, hogy egy template-ben ne legyen Javascript kód, meg deklarált függvények, mert nincs ott helye.
Az Angular is jó megoldás, de arra készülj fel, hogy nagyon más a paradigma, mint amit most te csinálsz és tapasztalataim alapján ha Angulart használsz, akkor vagy megtanulod és elfogadod az Angular-way-t, vagy jajgatás és fogak csikorgatása. Attól függ, mennyire nagy a már létező kódbázis és mennyire ragaszkodsz hozzá.
A funkciók memóriában való felhalmozódásáról akkor lehetne többet mondani, ha pontosabban tudnánk, hogy töltöd be őket.
Egy új keret rendszert
Átnézem majd az angularos lehetőségeket ez ügyben, mert ugye ott controllert be kell rántani, és nyilván azt is eltávolítanám szívesen.
Nem szabad túlzásba vinni az
Lehet, hogy igaz
Az átláthatóság és a
Egyébként a mérések mit mutatnak? Rengeteg memóriát zabál a programod, vagy belassul, vagy mi a hibajelenség?
Nincs még hibajelenség
Azonban lehet, hogy túldimenzionáltam a kérdést. :)
Akkor én azt mondom, egyelőre
Angular
A jelenlegi változat az 1.4,
Ugyanakkor nem a JóskaPista Bt. áll a fejlesztés mögött, számos saját cuccuk is Angularra épül, tehát én arra számítok, hogy vagy lesz még sokáig támogatás, vagy lesz praktikus upgrade megoldás (a volt fejlesztő is erről írt).
Szerencsére nem az Angular az egyetlen remek keretrendszer manapság, van miből válogatni, ha az ember hajlandó egy kicsit szélesíteni a látókörét.
Támogatás
sem tudtak olyan szoftvert
Leginkább azért, mert nem akartak. Olyat akartak készíteni, ami radikálisan más, mint a korábbi változat. Valószínűleg a tervezési hibákat is javítani akarták, és ahhoz radikális változtatások szükségesek. A PHP-ra is ráférne, és akkor talán újra ránéznék.
Szerintem ez felelőtlen
Egyébként a "radikálisan más" az kizárja azt, hogy jó API-t tervezzenek?
A PHP minden hibája, következetlensége, lassúsága és korlátai ellenére is egy zseniális alkotás, nem sok valódi alternatívája van.
Az Angulart a Google készíti,
Én értékelem azt, ha valaki képes a tapasztalatok alapján felmérni, hol hibázott, és kijavítani ezeket a hibákat, még ha veszteség is éri ezáltal. Hiszen így a jövőben már biztosabb alapokra lehet építkezni.
A PHP sikertörténet? Akkor azt hiszem, nincs miről beszélni :). Számomra tipikus példája annak, amikor a múlt összes hibáját hordozod magaddal, folyamatosan építkezel rá, míg végül már nem tudod kijavítani komoly veszteségek nélkül, ezért inkább úgy hagyod. Ahogy láttam pár ősi cuccot az igazán nagy baromságok közül már deprekáltak, visszavonultattak, gondolom tűzközelbe került pár értelmesebb ember. Ennek ellenére nem haragszom rá, annak idején jól elvoltam a PHP-vel, amíg nem szélesült a látókör.
Meg lehet oldani hogy
Szóval továbbra sem értem, hogy miért van a fentiekre szükséged. Vagy téged órabérre fizetnek?
Nem, egyáltalán nem
Elképzelhető, hogy míg kidolgozom, addig kicsit szopós lesz, de ha már megvan a keret rendszer már nem kell miatta nyűglődnöm, és mégis elegáns megoldás.
Fülek
Másnak gondolom
Nem érzem kényelmesnek. Persze ez ízlés kérdése is, így szerintem nem nagyon van értelme ezen túlmenően feszegetni.
Nem fogod tudni meggyőzni, ha
Fejezd be a személyeskedést!
:)
Te fogod használni ezt az
Nem
Kénytelen vagyok tehát hallgatni az ösztöneimre, mert ez egy havi díjas alkalmazás lenne, és simán lehet belőle egy sima bukta is.
Ma amikor minden 3 év feletti ember a userfriendly -ről beszél, simán lefeleződhet egy ügyfélszám csak mert nem kényelmes és egyszerű a használata.
Szóval úgy gondolom elég fontos eltalálni a megfelelő megoldást.
Ha tudsz esetleg egy olyan felmérésről, ami megmondja milyen megoldásokat kedvelnek a felhasználók, azt szívesen veszem.
Azonban nem fejleszthetek le
Gondolkodj egy kicsit! Egy szolgáltatás addig, amíg ki nem adják, csak viszi a pénzt. Ha most elkezded lefejleszteni az ablakkezelést, akkor az a megrendelődnek duplán ráfizetés: 1, tegyük fel, hogy két hét, mire megírod a kódot hibátlanra, akkor ennyivel később indul be a szolgáltatás, fél havi bevétel kiesik, 2, két heti munkádat ki kell fizetni.
Ha egy problémára már van létező megoldás, akkor célszerű azt választani. Majd ha már jól megy a biznisz, lehet csiszolgatni, de ilyeneken egyébként meg nem is érdemes.
Ez az egész "user-friendly", "user-experience" egy nagy voodoo-mágia, és mindaddig, amíg egyértelműen be nem bizonyítja valaki ennek az ellenkezőjét, így célszerű kezelni minden témába vágó kijelentést.
Te leírsz számokat, lesz ezer ügyfél, abból leszel te egy, azaz a te véleményed egy ezreléket számít. Tehát a legnagyobb hiba, amit elkövethetsz, ha úgy alakítod ki, hogy alapvetően neked tetsszen.
Ez nem azt jelenti, hogy a használhatósággal nem kell foglalkozni, hanem azt, hogy csak akkor, amikor valóban szükség van rá (már megy a szekér).
Mindig megfogadom, hogy nem
Na jó, most az egyszer betartom.
Ne erőltesd
Az egyetemen tervezőmérnöknek
Az én saját tapasztalatom pedig az, hogy azért van tele a piac szeméttel, mert akik tervezik a termékeket, azok nem használják. Ha lehet választani aközött, hogy a saját igényeid szerint tervezz vagy hogy semmilyen konkrét igény alapján, akkor válaszd az elsőt.
Tehát az ergonómia áltudomány?
»Ez az egész "user-friendly",
Tehát az ergonómia áltudomány?
Tegyük fel, hogy venni szeretnék valamilyen tárgyat, amit előtte szeretnék a kezembe venni. Ha az elérhető közelségben lévő bolt webshopja lassú, ahol ki szeretném deríteni, hogy kapható-e, a válaszidők nem igazán számítanak, hisz nincs nagyon választásom, oda kell mennem, ha nem akarok kétszer annyit utazni. Tehát ilyen esetben a maximális sebesség (lassúság) nem faktor.
Rámutatnak a linkelt cikkekben valahol, hogy az emberi érzékelés határa 100 ms, azaz átlagosan ennyi idő alatt jut el az agyunkig két különböző információ, tehát ez alá nem érdemes menni, mert nem fogjuk tudni megkülönböztetni, hogy ez most 10ms vagy 100 ms alatt érkezett. A kedvenc példámban azt szoktam felhozni, hogy ekkor viszont nyugodtan ellenőrizhetünk mindent szerveroldalon, hisz átlagosan a felhasználó nem fogja tudni észrevenni a késlekedést. Lehet 100 ms alá menni kliensoldali ellenőrzéssel, de ez ugye nem megbízható, másrészt a szoftver komplexitását növeli. Tehát ilyen esetekben a minimális sebességre való törekvésnek is van ésszerű határa.
Az ergonómia igenis fontos, én például belőle diplomáztam (és természetesen a sebesség is). De ahhoz releváns mérések szükségesek, amiből kevés van, erre pedig nem lehet igazán építeni. Pont egy grafikus ismerősömmel beszéltem valamelyik nap, ő is azt mondta, hogy az UX abban a formában, ahogy a szakmában használják, csak mellébeszélés, ugyanis ha a józan eszedet használod tervezés közben, akkor nagy valószínűséggel jót fogsz alkotni.
Kedves gtoma! A webáruházunk
A webáruházunk admin felületén én is ezt a munkafolyamat szervezési sémát választottam, ami a Te tetszésedet is elnyerte. A menüből listák nyílnak, amik újabb modális listákat vagy szerkesztő formokat nyithatnak, javascriptes "ablakokban".
Mivel ezek az ablakok modálisak, így egy időben egy fajtából csak egy példány lehet nyitva belőlük, ami rögtön ki is küszöböli az Általad említett problémát. (Én ezt egyébként egyszerűen munkafolyamat szervezési szempontból is így láttam helyesnek.)
(Emellett még választottam egy nekem tetsző JS keretrendszert is, ami az ezzel kapcsolatban felmerülő, tipikus problémák/feladatok megoldására is kész eszközökkel rendelkezett, de ez ebből a szempontból részletkérdés.)
Üdv:
Dávid
Modális
Mert a megjeleníteni kívánt
Igen, de az előnyét veszti