- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- Gurulunk, WAZE?!
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- sh4d0w: Csak a profit - emberélet nem számít
- vrob: Az IBM PC és a játékok a 80-as években
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
-
LOGOUT
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.
-
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
Hirdetés
- PlayStation 5
- sziku69: Fűzzük össze a szavakat :)
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Kerékpárosok, bringások ide!
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kazy Computers - Fehérvár - Megbízható?
- BestBuy topik
- Milyen légkondit a lakásba?
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Autós topik
- További aktív témák...
- Eredeti Windows 10 / 11 Pro aktiválókulcs AZONNALI SZÁLLÍTÁSSAL!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- A Panasonic Toughbook CF-54 i5-5300u i5-6300u TN, IPS touch Budapest, MPL Foxpost
- Szerezd be most az érzékelhető különbséget! Akár 0% THM-re
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest