- Xiaomi Mi 11 - értékesített büntető
- Android alkalmazások - szoftver kibeszélő topik
- iPhone topik
- Két nap múlva itt a Xiaomi 17, van egy pár hivatalos fotó is róla
- Apple Watch Ultra - első nekifutás
- Prohardver app (nem hivatalos)
- Milyen okostelefont vegyek?
- Képeken a Huawei új Watch GT 6 órái
- Megérkeztek a Xiaomi 15T sorozatának telefonjai Magyarországra
- Xiaomi 15 Ultra - kamera, telefon
-
Mobilarena
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
-
föccer
nagyúr
A Tarolos értéket már a kódon belül adom meg. Igen, a Száraz ágon üzenet még kijön konzolra, illetve a számított értékek is, tehát a case még lefut. Validatorral ellenőríztem szintaktikailag elvilen nincs vele gond
Egy céges szoftveren belül kell készíteni a kódot. A node/chrome ismerős, lehet hogy erre támaszkodik ez az eszköz amit kaptunk. (egy keretrendszert fejlesztettek, amiben sok kis külön-külön értékelő szkriptet már nekünk kell megcsinálni.
egy külső, add-on függvényt kaptunk, amivel külső adatokat tudunk a kapcsolódó űrlapokról levenni és simán returnnal adjuk vissza az űrlapnak a kiértékelés eredményét. Úgy működik, mint egy function. Csak kicsit combosabb, mert ez éppen 1200 soros.
üdv, föccer
-
martonx
veterán
Expresshez nem értek, de az MVC rendszerekben szokott előre kialakított szerver oldali validáció lennie out-of-the-box, azaz én a helyedben első körben utána olvasnék, hogy Expressben milyen szerver oldali validációs megoldások vannak alapból.
Ha pedig nincs benne, akkor ideje valami más MVC megoldás felé fordulni. -
Jim-Y
veterán
Csinalni egy middleware-t ami ellenorzi. Aztan a route definicioban megadhatod, hogy milyen parameterek manadatory-k es , hogy azoknak milyen a tipusa. Ha a mandatory parameterek tipusa nem jo akkor a middleware nem engedi tovabb a requestet hanem logol, meg HTTP 403.
Pszeudokod: (majd egy masik hsz-ben mert keson kezdtem el szerkeszteni, pill)
-
#6605
fordfairlane
veterán
tick
#6603
fordfairlane
veterán
Typescripthez nem értek, de az instanceof talán ebben az esetben is használható.
-
martonx
veterán
Amit belinkeltem thread-et ott mintha lettek volna workaround-ok, utólagos megoldások ezeknek a típusellenőrzéseknek a belegenerálására. Igen, ha neked tényleg ez kell, akkor valóban nincs más hátra, mint vanillajs-ként tekinteni a ts generált kimentére (mert hiszen az is).
-
martonx
veterán
Nézd, a typescript javascriptté fordul, ami nem típusos nyelv (szerk. mielőtt valaki a fejemet veszi, pontosítok: nem erősen típusos), így elvárni, hogy futás közben is úgy viselkedjen, mint szerkesztés közben a typescript, elég naív elképzelés. Mindenesetre itt vannak workaroundok erre: [link] (gugli legelső találata volt)
-
#6458
PumpkinSeed
addikt
tick
#6453
PumpkinSeed
addikt
Valószínűleg ez lesz.
(#6454) DNReNTi
3 diagramra nem paktálok le a sátánnal.
Illetve ti hogyan oldjátok meg a view részét a dolognak? Az elképzelésem: van eddig 3 all domain www.domain.com, api.domain.com, auth.domain.com. Erre akarunk húzni egy központosított front-endet, hogyan lehet ezt szépen megoldani? Nagy részben az api és auth képes api endpointokon kommunikálni, és a www rész pedig egy symfony ami szépen lassan lecserélődik az api.domain.com-ra amiből majd a front-end táplálkozik.
-
DNReNTi
őstag
Szia,
Nem teljesen latom at a problemat, de nem e lehet megoldas, hogy a szukseges erteket a root controllerben definialnad, es azt hasznalnad fel a "gyerekekben"? Vagy ez az ertek valtozik minden controllerben? Akkor nincs mese, irni kell ra service-t, es azt hivni valami parameterrel, minden alkalommal. Lehet nem ertem.
-
Mr Dini
addikt
Adatokat szeretnék kinyerni egy HTML kódból, aki dinamikus és egy szerveren futó php rakja össze.
Pl időjárási adatokat szeretnék leszedetni és feldolgozni.
A többit meg már elmondtam. Lehet bármilyen a function, csak getPage('url');-lel lehessen meghívni és a DATA globális változóban adja vissza a html kódot. A kód nár működött xhr-rel, böngészőben, de a node -on nem akar menni a jóöreg xhr.
-
Jim-Y
veterán
Igen, sajnos a tömb és objektum duplikálásra nincsenek szép megoldások. A stringify + parse módszer amit mutattál akkor lehet problémás ha körkörös hivatkozás van a struktúrában, az angular.copy lassú és a elemenkénti másolással dolgozik (asszem). ES6-ban van Object.assign, vagy ott a spread operator, de az meg talán csak 1 mélységig működik. Tömbök másolására ott a .slice(), de az pedig ha a tömb elemei objektumok,mint a te esetedben is, akkor azokat nem másolja le hanem csak a referenciát másolja át. Nem egyszerű na, de hát minden nyelvben vannak kevésbé jó dolgok, így javascriptben is
Amúgy ennek a "problémának" amivel most találkoztál semmi köze a javascripthez a legtöbb nyelv így működik, hogy vannak primitív érték szerinti tipusok és a referencia tipusok. Nincs ez máshogy JS-ben sem, ennyi
-
-
#5757
Sk8erPeter
nagyúr
tick
#5755
Sk8erPeter
nagyúr
Alapvetően annyi a baj azzal, hogy JavaScripttel állítgatod a stílusát egy DOM-elemnek, hogy így keversz két különböző területet: alapvetően a CSS feladata meghatározni az oldal megjelenését (benne van a nevében, hogy stíluslapokat készítesz), JavaScripttel pedig inkább a viselkedését illik manipulálni az oldalnak. Nyilván vannak kivételek, de ez pont olyan példa, amire érvényes. Persze nem érdemes túlizgulni, ez már csak szépítgetés, szemantikai okoskodás.
Most amúgy kíváncsiságból rákerestem a dologra, és találtam egy cikket, ami vitatja az osztályok ráhelyezésének vagy levételének elvét, és inkább a data-attribútumok használatát javasolja:
http://toddmotto.com/stop-toggling-classes-with-js-use-behaviour-driven-dom-manipulation-with-data-states/
Elfogadható, amit ír, de túlzásba esik az osztályok használatának elvetésével. De egyébként nem rossz a data-attribútumok használata sem."Lenne esetleg értelme minden sort egy ID-val ellátni, a szűrést pedig client-side/local storage-ban elvégezni majd az eredmény alapján állítgatni a displayt?"
Semmi értelme nem lenne ennek a megoldásnak. A szűrést így is az összes adaton kellene elvégezni, itt pedig semmiféle előnyt nem jelentene az, hogy csavarintasz és bonyolítasz egyet a dolgon.
Gondolj bele, a mostani megoldásod egy document.getElementsByClassName hívás, ami visszatér egy HTMLCollectionnel, amin végigmész egy for ciklussal, és megnézed, benne van-e az adott sorban valahol a keresett elem, aztán kész vagy. Ez is nagyon gyorsan fog végezni, még ha többezer elemed lenne, akkor se lenne vészes, a DOM-manipulálás már más kérdés. Ha viszont átállnál arra, hogy id-k szerint kérdezgess le, akkor értelemszerűen az id-kat is nyilván kellene tartani egy másik tömbben (mert különben honnan tudod, hogy miket kellene lekérdezni? Ha meg nem tudod a konkrét id-kat, akkor vissza kell térned az eredeti, amúgy ezerszer értelmesebb megoldásra), és azon a tömbön kellene végigmenned, lekérdezned id szerint az elemet, majd pont ugyanezt a keresést végrehajtani. Nem nyertél semmit, sőt, még overheadet is tettél a dologba (plusz egy-egy lekérdezés minden elemre az id szerint is, miután megkaptuk a tömbből az elemet).
Azt meg nem tudom, hogy érted, hogy "client-side"-ban elvégezni a keresést, most is kliensoldalon keresel. localStorage-be átpakolni a keresést meg megint semmi értelme, mit keresne ott, miért kellene perzisztens módon tárolnia a kliensnek az összes adatot. Nem beszélve arról, hogy valószínűleg az oldaladon változni fognak ezek a megjelenített és szűrhető adatok, így a localStorage-et mindig szinkronban kellene tartani az újabb adatokkal. -
Cathfaern
nagyúr
-
Cathfaern
nagyúr
De miért akarsz kliens oldalon jelszót tárolni?
Felhasználó bejelentkezik => szerver oldalon (akár db-ben) eltárolod, hogy a X user bejelentkezett 2015.02.12 8:30-kor. Legközelebb ha X user kérést indít hozzád, akkor megnézed, hogy mikor jelentkezett be utoljára. Ha ez régebbi, mint az eltárolt idő + 30 perc, akkor újra kérsz tőle jelszót. Amit írsz az ugye arra jó, hogy ne a user id-ját tárold le, hanem generálj egy egyedi azonosítót, ami minden bejelentkezéskor megváltozik.
Vagy arra hogy már bejelentkezéskor se kelljen jelszót küldeni (sose utazzon csomagban jelszó), nem vagyok benne biztos, hogy melyik verziót írod.martonx:
Igazából nem lepne meg, ha NodeJS-en alapból nem lenne session (fél perc googlizás ebben meg is erősített). Ugye a NodeJS alapból arra lett kitalálva, hogy egyszerűen és könnyen lehessen API-kat gyártani. Ahhoz pedig nem kell session. -
#3884
Sk8erPeter
nagyúr
tick
#3883
Új hozzászólás Aktív témák
- exHWSW - Értünk mindenhez IS
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Gumi és felni topik
- Xiaomi Mi 11 - értékesített büntető
- Futás, futópályák
- Épített vízhűtés (nem kompakt) topic
- Milyen légkondit a lakásba?
- LOGOUT - ezmiez?
- Delta Force (2024)
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...
- LG 34GS95UE - 34" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Apple iPhone 12 128 GB Fekete 1 év Garancia Beszámítás Házhozszállítás
- SzinteÚJ! HP Elitebook 860 G9 i7-1255U 16GB 1000GB 16" FHD+ Gar.: 1 év
- Gamer PC-Számítógép! Csere-Beszámítás! I9 9900K / RTX 3070Ti / 64GB DDR4
- RÉSZLETRE .OPCIONÁLIS. G.SKILL Trident Z5 Neo RGB 96GB (2x48GB) DDR5 6000MHz
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest