Hirdetés
- droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
- LordAthis: RETRÓnia - RETRÓ Mánia - Úton van hozzám egy csodás történelmi darab!
- gban: Ingyen kellene, de tegnapra
- hcl: Kelj fel komám, ne aludjál
- sziku69: Fűzzük össze a szavakat :)
- Pajac: Hámozott narancs
- moongoose: Jelszóvédett IBM Thinkpad R50e működőképessé tétele
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- urandom0: Új kedvenc asztali környezetem, az LXQt
- Luck Dragon: Asszociációs játék. :)
-
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
-
#4393
martonx
veterán
Sk8erPeter
#4392
martonx
veterán
válasz
Sk8erPeter
#4392
üzenetére
"Pedig annyiból nem mondott hülyeséget, hogy valóban megakadályozhatja egy form elküldését, ha mondjuk a submit buttonre (buttonökre) van kötve az event handler, és hív egy event.preventDefault()-ot; ugyanígy a linkre is igaz. Mondjuk annyiból nem volt pontos a meghatározása, hogy a metódushívás inkább az eventet érvényteleníti/törli, DE az esemény további felszivárgását nem akadályozza meg. Szóval tulajdonképpen az alapértelmezett viselkedést lehet vele módosítani, úgyhogy nagyon nem lőtt mellé. Vagy csak most hirtelen nekem nem ugrik be, mire gondoltál."
Egyrészt igazad van, mert amit mondott önmagában annyira nem volt hülyeség, de nem is mondtam, hogy hülyeség. Viszont ha ehhez megnézed az adott példa kódját (hopsz most olvastam tovább a hsz-ed, és látom, hogy időközben törölte a kódot), akkor meg láthatod, hogy gyakorlatilag fingja sincs, hogy mit csinál, és mi a különbség az event.preventDefault és egy szimpla return között. Ergo fogalma sincs mit csinál, mire jó, még ha lexikálisan nézve nagyjából ismeri is a preventDefault meghatározását.
A CMS-es megjegyzésemet félreértetted. Arra gondoltam, hogy a CMS kismillió dolgot kérdez le a DB-ből, ahhoz, hogy egy hello world oldalt kigeneráljon. Ez esetében szükséges működés, de nyilván teljesítmény optimalizáláls szempontjából rossz működés. Mondhatni szükséges rossz. De ezt már százszor kitárgyaltuk.
-
martonx
veterán
Van pár ökölszabály:
1. scripteket mindig a body végére tesszük. Ez alól a ga script az egyetlen (általam ismert) kivétel, noha ez is simán megy az oldal alján is, de a gugli azt javasolja, hogy a mérések pontossága érdekében inkább menjen a head-be. A ga script egyébként csak egy async loader, szóval szerencsére csak minimálisat fog az oldalad betöltődésén lassítani.
2. ne foglalkozz az async - defer attribútumokkal. Ha ezekre vagy szorulva, akkor az azt jelenti, hogy valamit elég rendesen elbaltáztál. No de miért? Mert egy rendesen optimalizált oldalon egy szál minifikált bundle-özött js található (na jó az egy szál, az bizonyos esetekben, mikro optimalizációknál lehet akár 2-3 is), ergo ezekre az attribútumokra nincs is érdemben szükség.
3. ha már optimalizálás, akkor cdn-ről használod azt az egy szál minifikált, bundle-özött js-edet? Sőt menjünk tovább, minden statikus tartalmat (css - ami ugye szintén bundle-özött, minifikált, képek - amik ugye lehetőség szerint sprite-okban vannak). A cdn-ben be van állítva a gzip, illetve valami jó nagy expiary date? A cdn már csak azért is fontos, mert a böngésző azonos domain-ról sorrendben szedi le / várja be a kért cuccok letöltődését. Ellenben ha valamit másik domain-re teszel ki, pl. cdn-re, akkor annak a letöltése, feldolgozása hirtelen párhuzamossá válik.
4. ha már kismillió js file-od van, akkor használj valamilyen loader scriptet, amivel szabályozni tudod, hogy mikor épp melyik js töltődjön be, így minden oldal csak a számára szükséges minimális js-t fogja letölteni, használni.
5. egy oldal pagespeed-jén ritka az, amikor maga a js betöltés ront. Simán lehet, hogy a szerver oldalon van valami elcseszve (mondjuk a legtriviálisabb dolgokat is sql-ből kérdezgeti le, erre nagyon jó tipikus rossz példa a cms-ek működése), valami nincs cache-elve, szar a html struktúra, túlbonyolított a css, és ez miatt extra köröket fut a renderelés stb... -
martonx
veterán
1. a preventDefault-ot teljsen rosszul használod. Csak 1 kell belőle, és az legfelülre.
2. nem lehetne jsfiddle-re, hogy esetleg ki is javítsuk? Bár nekem bőven jó az az 1-es pont hintje alapján kijavítod magad![;]](//cdn.rios.hu/dl/s/v1.gif)
A kódod alapján adódik a kérdés, hogy tudod-e, mit csinál a preventDefault? Ha a válaszod igen lenne erre, akkor kérlek először olvass utána, hogy mit csinál, és értsd is meg, hogy mit csinál.
-
martonx
veterán
Ugyanarra jók. Mindig érdekeltek, de sose jutottam el oda, hogy érdemben kipróbáljam őket. Igaziból a knockoutjs-el 100%-ban elégedett vagyok, az angularjs-t kipróbáltam a hype miatt. Nem hiszem, hogy érdemben kiderülhetne bármelyik más frameworkről is, hogy sokkal jobbat tudna mint ezek.
-
#4362
martonx
veterán
Speeedfire
#4357
martonx
veterán
válasz
Speeedfire
#4357
üzenetére
A ko mapping pluginre soha nem volt szükségem. Ahogy switch case-re se, se ko, se angular alatt.
Ha anno ko alatt ennyi volt a modelled, pláne nem értem, hogy mi nem volt ezen átlátható? -
martonx
veterán
A Grunt-tal a kliens oldali framework-öd build-jét tudod automatizálni (pl. html-ek minifikálása, js-ek egybegyúrása, minifikálása, css-ek, stb...). Mint ASP.NET fejlesztő bevallom még sose használtam, mert az ASP.NET - Visual Studio alapból nagyon erős ezekben.
Nodejs-es, PHP-s világban viszont elég elterjedt. -
martonx
veterán
1. kód szervezésben. Bevallom szeretem az MVC / MVVM kód szervezést. Amikor jön egy json adat, az már megy is bele egy jó kis modellbe, és ezt bindolom a megfelelő helyekre.
2. a modellek változása realtime megjelenik a böngészőben, átvezetődik más modelleken, stb...
3. nagyon szépen lehet velük template-elni, pl. valamilyen lista elemeket kell generálnod a kapott jsonból. Ezt e frameworkök nélkül jobbára kénytelen vagy elkezdeni js kóddal foreach-ekkel megírni, és összerakosgatni string részletekből. Ha láttál már ilyen js kódot, akkor érteni fogod, hogy mire gondolok.
4. szépen el lehet velük szeparálni a különböző kód rétegeket (html - js és js-en belül a class-ok, service-ek, controller-ek)
5. a html-eidet is szépen kis darabokra tudod szedni, ezáltal sokkal átláthatóbb lesz a kódod
6. segítenek a routingban, DI-ban (ez mondjuk csak az angularjs-re igaz, aminek viszont a DI-át százszor is elátkoztam, szóval ez azért nem mindig előny). Knockouthoz meg azt húzol be pluszban, amit jól esik pl. pagejs + requirejs.
7. összességében, jóval kisebb kód mennyiséget eredményeznek, lásd Jim-Y esetét. Mondjuk angular-t telefonra a gyatra teljesítménye miatt én se mernék bevállalni, de egy 30Kb-os knockout-ot már volt, hogy használtam telefonon, és tök szépen, gyorsan tette a dolgát, pedig ez még az okostelefonok őskorában volt, amikor 1 magos 600Mhz-ez szutykokon futottak a mobilos böngészők első verziói.Mindezek ellenére abszolút nem azt mondom, hogy akkor most mindenki kezdjen el valamilyen js framework-öt használni, hiszem hogy a webes projektek jelentős részének nincs rájuk szüksége. De egy picit is jelentősebb projektet én már nem kezdenék el knockoutjs (rosszabb esetben angularjs) nélkül.
-
martonx
veterán
Single page application-ökhöz. Eddig kettő nagyobb ilyen projekten dolgoztam. Egy CRM rendszeren, amit knockout-tal csináltunk, és egy média library-s, rendelő oldalon ami angularjs-el készült (mielőtt páran felnyögnének, ez egy elég sajátságos terület, elég sajátságos megoldásokkal, így nem volt kérdés, hogy mindenből custom-ot kellett írnunk).
Kisebb ko-s projektjeim voltak még, mint pl. online repülőjegy foglaló rendszer (ezt ide is tudom linkelni, mert ez publikus link), ahol a járat keresés résznél mindent a knockout vezérel, illetve per pillanat egy pénzügyi szektoros fejlesztésen dolgozok, ami szintén publikus lesz, ha elkészül. -
#4340
martonx
veterán
Speeedfire
#4334
martonx
veterán
válasz
Speeedfire
#4334
üzenetére
Összetett adatmodelleknél valóban gázos volt a knockout vagy te szervezted rosszul a kódot? Pl. egyik legnagyobb eltérés a ko vs angular között, hogy ko alatt úgy szervezed a kódod ahogy akarod. Az angular viszont sokkal jobban belekényszerít az adott homokozóba.
A legutóbbi angularjs-es projektem több hónapig tarott. Végült most hagy ne számoljam meg, de több tucat js file-ból és fogalmam sincs hány ezer / tízezer kódsorból áll.
Ugyanilyen nagyságrendű ko-s projekteken is szoktam dolgozni.
Megnéztem az általad belinkelt tutorialt, erről beszéltem. Ilyen szinten még minden szép és jó.
"és kiegészítőket kellett leszedni hozzá" - ko-hoz kiegészítőt kellett leszedned? Miért angular-hoz nem kell? Ok, routingot és DI-t valóban tud az angular alapból, de ezeket a komponenseket bármikor ko mellé is oda tudod tenni.
-
#4332
martonx
veterán
Speeedfire
#4331
martonx
veterán
válasz
Speeedfire
#4331
üzenetére
Az angularjs egy agyonhypeolt fos szerintem (pont, mint az almás termékek). Felületesen nézve persze sok mindent tud, és nem is olyan rossz, aztán gyorsan kiderül, hogy ebből is egy kicsit tud, meg abból is, a singleton megvalósítás se feltétlenül nyerő és a többi. Teljesítményben pedig a katasztrofálishoz közelít knockoutjs-el összehasonlítva. Anno komoly knockoutjs tapasztalattal a hátam mögött nekivágtam az angularjs-nek, mert a csapból is az folyt hogy az milyen jó. Aztán pár hét elég volt, hogy kiderüljön, a pistike projektek, meg a tutorialok szintjén tényleg szép és jó, de picit is mélyebb vizekre merészkedve, már nem más mint szopás halom.
Én részemről maradok továbbra is a knockout (egy hónapja jött ki a 3.2-es ami már tudja a komponensek létrehozását, kezelését ala angularjs direktívák) + jquery (ezt mondjuk egyre inkább, egyre könyebben lehet zeptojs-re váltani, vagy plainjs-re) + pagejs (ez csinálja az SPA routingot, kemény 1Kb) kombónál.
-
#4328
martonx
veterán
honda 1993
#4325
martonx
veterán
válasz
honda 1993
#4325
üzenetére
a print és az echo mióta kiírató parancsok a javascriptben?
-
martonx
veterán
-
martonx
veterán
Jim - Y kérésére írok egy rövid összefoglalót ide a JS toikba, hogy milyen szolgáltatásokat ad a Visual Studio tisztán html (plusz nyilván css, js, de semmiképpen sem .Net) fejlesztés esetében. Először is szögezzük le, hogy legalább két verziója van a VS-nek:
1. ingyenes VS Express, aminek a funkcionalitása majdnem az, mint a Pro verziója, viszont nem lehet hozzá plugineket telepíteni, ami pont a webfejlesztés szemszögéből nézve elég nagy hiányosság.
2. fizetős VS (Pro, Ultimate), ahol a Pro kb. mindenre elég, hacsak nem teszt automatizálással, meg mindeféle brutális funkcionális teszt írásával foglalkozunk. A Pro-ból az egyetlen számomra hiányzó funkció a web oldalak beépített load test-je, ami az Ultimate-ben benne van.No, de mi az, amit az ingyenes is tud:
Kód kiegészítés js, css, html - a html kiegészítése szvsz a VS-nek a legjobb az összes eddig általam próbált rendszer közül, ami lássuk be pusztán az Eclipse, Netbeans vonalra korlátozódik, szóval lehet, hogy a PHPStrom, Webstorm ugyanilyen jó html-ben. CSS-ben segítget, js-ben egészen jó, bár kellően bonyolult jó sok js-re bontott projekt struktúránál, azért meg tudja adni magát a js kódkiegészítés. Emellett természetesen minden általános IDE funkció benne van, projektben keresés, szűrés, navigálás, verzió kezelőkkel integráltság stb...
Fizetős mivel tud többet: van egy Web Essentials nevű hivatalos MS által supportált plugin. Aminek a tudása elég emberes, nem is sorolnám fel, nézze meg mindenki maga: link
Hozzáteszem én pusztán html kódot nem szoktam fejleszteni, ASP.NET-ezek, így részemről alap volt a VS mint IDE választása.
-
#4303
martonx
veterán
honda 1993
#4302
martonx
veterán
válasz
honda 1993
#4302
üzenetére
Ez esetben a megoldás adott: első körben fel kell hoznod az angolodat legalább olyan szintre, hogy azt értsd, ami tutorialban le van írva. Ha komolyan gondolod a programozást (az eddigi hsz-eidből az tűnik ki, mégha én személy szerint inkább a kőműves szakmát javasolnám is neked), akkor muszáj lesz angolul valamennyire megtanulnod.
-
#4267
martonx
veterán
kemkriszt98
#4266
martonx
veterán
válasz
kemkriszt98
#4266
üzenetére
Akkor tegyél be unity-t a web oldaladba. Az kimondottan pont erre való.
-
#4264
martonx
veterán
Sk8erPeter
#4263
martonx
veterán
válasz
Sk8erPeter
#4263
üzenetére
Ahogy végigfutottam a css-t, js-t (kemény pár sorokról beszélünk), ennek simán mennie kellene IE-n. Inkább a demo oldalon lesz valami gikszer, ami miatt IE-n nem megy. Mondjuk időt nem szántam rá a komolyabb nyomozásra, de semmi olyat nem csinál a kjis css, js, ami IE11 alatt ne működhetne.
-
martonx
veterán
Ja, hogy mobilon. Ok, valóban egy jellemzően két magos ARM procit valóban nem lehet összehasonlítani egy szerver processzor erejével, de a szervert meg pillanatok alatt túl tudod terhelni ilyen felesleges munkákkal, amire pont az angularjs lenne a való.
Ha teljesítmény problémáid vannak az angularral, akkor javaslom a knockout-ot helyette. Az szerintem két fokkal gyorsabban teszi a dolgát.
Másrészt valami programtervezési problémát érzek ott, ahol kliens oldalon több ezer / tízezer objektumot kell mozgatni, renderelni. -
-
martonx
veterán
Nekem mindegy, de ezeket az elcseszett rövidítéseket nagyon gyorsan gyomláljátok ki! Az intellisense és a js minifikálás korában ne szopassuk már magunkat ilyen rövidítések használatával. Fontosabb az olvasható kód, mint a forráskódban megspórolni pár karaktert (amit aztán a minifikálás úgyis a, b és c-re fog cserélni éles környezetben).
-
-
#4147
martonx
veterán
kemkriszt98
#4146
martonx
veterán
válasz
kemkriszt98
#4146
üzenetére
A js elérési útja van rosszul megadva?
-
martonx
veterán
Érdekes, hogy nem működik .on-nal a scroll, a click meg igen. Szvsz semmi köze ahhoz, amit feltételezel, ki kellene próbálni plain js-sel, lehet hogy ez csak valami jquery hiba. Simán működnie kellene: példád letisztítva és a lényegre koncentrálva
-
martonx
veterán
-
-
#4077
martonx
veterán
fordfairlane
#4075
martonx
veterán
válasz
fordfairlane
#4075
üzenetére
Ez is jogos, ezért nem használok Notepad szintű IDE-ket. Jó lenne a PH-t felokosítani némi kód intellisense-el
-
#4076
martonx
veterán
trisztan94
#4072
martonx
veterán
válasz
trisztan94
#4072
üzenetére
Jogos.
-
martonx
veterán
válasz
MrSealRD
#4064
üzenetére
"Itt nálunk az a legnagyobb félelem, hogy ha az ügyfél kitalálja, hogy "jó, jó ez a táblázat, de kéne ide még egy gomb, meg oda egy címke..." stb. Akkor lehetőleg tudjunk kezdeni valamit az igényekkel."
Bármit is választotok, egy ilyen feladat megoldása triviális (na jó angularral, közel sem lesz triviális az első pár hónapban, de utána jó lesz az is).
A javascript kezdőségeteket látva, én továbbra is hagynám a francba a helyetekbe az SPA-s megközelítést, és KendoUI-al, vagy valami hasonszőrű cuccal oldanám meg a feladatot. A kérdéseidet elnézve annak is örülni fogtok, ha az első AJAX lekérést megírjátok, nemhogy kliens oldali Dependency Injection-nel, meg closure-ökkel, meg típustalansággal, meg az eddigiektől tökéletesen eltérő megközelítésekkel foglalkozzatok.
-
martonx
veterán
CRM rendszert csináltunk legutóbb knockout, jquery, bootstrap kombinációval. Szerintem nagyon könnyen használható, nagyon effektív kombináció. Angulart is használom napi szinten, szintén komoly projektben. Valahogy nem estem hasra tőle. Nagyon sokat tud, nagyon szép kliens oldali architektúrákat lehet rá felhúzni, ugyanakkor bűn gyengén dokumentált, több hónap távlatából se mérnem kijelenteni, hogy értek hozzá. Plusz nekem teljesítményben a ko sokkal erősebbnek tűnik. Én a helyedben knockoutjs (pontosabban durandaljs ha már almát almával) és angularjs között ingadoznék. Látva a kezdőséged, egyértelműen a knockout-ot javasolnám.
Ugyanakkor ezek a frameworkök SPA-khoz előnyösek, közel sem biztos, hogy tényleg ez kell Nektek. Lehet, hogy egy kendoui-al sokkal könnyebben elérhetnétek ugyanazt.Karma, ez nem neked akart válasz lenni, hanem stuszinak. Bocs.
-
martonx
veterán
válasz
MrSealRD
#4059
üzenetére
Előre bocsátom, hogy az Ext.JS-t nem használtam.
De az ugye megvan, hogy egy jquery-t AngularJs-el összehasonlítani, még csak nem is almát a körtével, hanem almafát a körtével összehasonlítás esete.
Ráadásul az AngularJs nem zárja ki a jquery használatát, szóval nem is értem, miért kell választani?
Ráadásul semmi konkrétumot nem írtál ,hogy mire akarod használni?
Ennyi infó alapján, aki állást foglal neked ebben, az biztosan nem tudja, hogy miről beszél
-
#4045
martonx
veterán
trisztan94
#4042
martonx
veterán
válasz
trisztan94
#4042
üzenetére
Kevered a windows 8-at a windows Phone 8-al.
-
#3986
martonx
veterán
Sk8erPeter
#3985
martonx
veterán
válasz
Sk8erPeter
#3985
üzenetére
Ha jól rémlik a PHP-ban van valamiféle natív SOAP is, bár az talán még rosszabb, mint a nusoap. Tavaly év elején mintha kísérleteztünk volna velük.
-
martonx
veterán
"a SOAP egy régi idők letűnt megoldása, amit a mostani eszközökkel már nem kéne erőltetni"
Messzemenőkig egyetértek. Nekem a SOAP-pal a legnagyobb bajom, hogy nagyon nem kompatibilis, ahány nyelven, ahányféle SOAP megoldást használ az ember, annyiféle kimenetele lehet a dolognak. Plusz xml-ben kommunikál, aminél a Json már sokkal fejlettebb, tömörebb.
Megérett az elfeledésre, azonban sajnos még mindig rengeteg régi, jól beágyazott cucc ezt használja
-
#3969
martonx
veterán
trisztan94
#3968
martonx
veterán
válasz
trisztan94
#3968
üzenetére
Esetleg valami normális jsfiddle példával szemléltetnéd, hogy mit is szeretnél?
-
#3959
martonx
veterán
szabo.norbi
#3958
martonx
veterán
válasz
szabo.norbi
#3958
üzenetére
várjuk a jsfiddle példádat, hogy hol a hiba a kész kódodban.
-
#3956
martonx
veterán
trisztan94
#3955
martonx
veterán
válasz
trisztan94
#3955
üzenetére
Szerinted a bedobott kódod alapján honnan tudjuk?
-
#3948
martonx
veterán
Sk8erPeter
#3947
martonx
veterán
válasz
Sk8erPeter
#3947
üzenetére
Most komolyan egy szimpla .js kipróbálásához windows alatt tényleg nem kell semmi.
Nyitsz egy command line-t, majd cscript xy.js és már fut is a js-ünk. Sőt dupla kattintásra is elindul, csak ekkor nem a cscript hanem a wscript fogja futtatni. Rémlik ezeknél az üzenet kiírást másképp kell megoldani, mint böngészős futtatáskor, azaz wscript.echo(üzenet) vagy valami ilyesmi a szintaktikája.Vagy csinál valaki egy .hta-t, és abban futtatja.
Ahogy mondtam a lehetőségek száma végtelen.
Szerintem az a legjobb, ha magával a js futtatással nem foglalkozik a leírás, aki erre adja fejét, az csak meg fogja tudni oldani, hogy futtassa a js-ét
bármilyen módon. -
martonx
veterán
Szerintem vagy vegyük ki a node.js-es részt, vagy akkor már soroljuk fel a kismillió egyéb lehetőséget, ahogy lehet futtatni egy javascriptet.
Pl, hogy mást ne mondjak windows-on simán konzolból lehet futtatni, még node.js-se kell hozzá. Aztán ott van a kismillió fejlesztő környezet, mindenféle platformon, amikkel minddel lehet js-t futtatni, mindegyikkel egyszerű.
-
#3925
martonx
veterán
fordfairlane
#3922
martonx
veterán
válasz
fordfairlane
#3922
üzenetére
"Nem azt írtam, hogy az elemek onevent attribútumainak használata jó, csak annyit, hogy van benne logika, és tisztességes implementációnál azt attribútum-eventbinddal nincs semmi gond."
Nem értek egyet. Így 2014-ben a html-be belefosott js eseménykezelő abszolút védhetetlen. Lehet 1-2 eset, amikor tudatosan generálunk pár js változót a html kimenetbe (mondjuk egy user role esetében felesleges azért egy külön ajax hívást indítani, csak hogy lekérjük a szerverről a user csoportját), de az onclick, on.... esetek használata szvsz védhetetlen. Régen ez így volt, HTML5 előtt (pontosabban jquery előtt) érthető is volt, mert egy class-al azonosított html elemre esemény kezelőt kötni fájdalmas volt, ha az a class szerepelt X darab html elementnél, és mindre rá akartad kötni ugyanazt az eseményt.
Aztán jött a jquery és már HTML4-ben is normálisan felépített szeparált kódokat lehetett felépíteni vele kliens oldalon. Nem vagyok az a típus aki design patternek megvalósításától élvez el, de minimum alap követelmény a különböző kódok szeparálása. Ráadásul a külön js-ekbe kiemelés az oldal betöltődésének is kedvez.
-
#3918
martonx
veterán
Sk8erPeter
#3917
martonx
veterán
válasz
Sk8erPeter
#3917
üzenetére
Nekem érthető volt. Ilyenkor derül ki, hogy az emberek használják a jquery-t, mert az milyen jó már, de mennyire nem értik a mögöttes folyamatokat.
-
#3915
martonx
veterán
Sk8erPeter
#3914
martonx
veterán
válasz
Sk8erPeter
#3914
üzenetére
Most jól összezavartad...
-
martonx
veterán
A dolog egyrészt egyszerű, másrészt nem.
Van ugyebár a DOM-unk, aminek egy MEGLÉVŐ elemén ha elsül valahol egy esemény, az szépen elkezd fölfelé "bugyogni" a szölő elemein végig.Feladat tud lenni, ennek a felfelé bugyogásnak a megszüntetése, mert nem várt mellékhatásokat okozhat. Pl: egy formot ajaxosan akarsz elküldeni. A submit gomb click-jére feliratkozva hiába csinálsz valamit, ha az esemény tovább bugyog, és végül a default böngészős viselkedés fog elsülni rá, azaz elnavigál az oldal a Form url-jére. Ekkor a click elkapásakor egyúttal meg kell szüntetni a tovább bugyogást is.
A másik típusú gond ott kezdődik, hogy eseményt kötni csak MEGLÉVŐ elemekre lehet, olyanokra nem amiket ajax-al utólag fogsz beszúrni valahova, és az esemény handler létrehozásakor még sehol sincs.
Ekkor sincs gond, csak éppen más módszerrel kell lekezelni ezeket az eseteket.
-
#3849
martonx
veterán
Sk8erPeter
#3848
martonx
veterán
válasz
Sk8erPeter
#3848
üzenetére
Hozzáteszem VS2012 - 2013 már alapból tartalmazza a jquery-s intellisense-eket.
A 2013 még knockout-ot, meg mittudomén még mi minden js libet támogat intellisense-el alapból. -
#3810
martonx
veterán
TomyLeeBoy
#3809
martonx
veterán
válasz
TomyLeeBoy
#3809
üzenetére
"Ezt én értem de ha egyszer muszáj?! " - ez butaság. Nem muszáj, bár nyilván kényelmesebb valamit összedobni, mint rendesen szeparálni a layereket.
Az meg, hogy db-ből jön minden, nem izgat különösebben, fogod az oldal kigenerált forrását, és egy az egyben beteszed egy szűz .html-be, és már meg is van oldva a db-ből jön minden probléma. -
#3807
martonx
veterán
TomyLeeBoy
#3806
martonx
veterán
válasz
TomyLeeBoy
#3806
üzenetére
ugyebár pont ezért nem gányoljuk össze a php-t, meg a html-t, meg a javascriptet egybe...
-
#3803
martonx
veterán
TomyLeeBoy
#3802
martonx
veterán
válasz
TomyLeeBoy
#3802
üzenetére
konkrétumok ugye még mindig nincsenek, de van egy ötletem. Nem jó helyre raktad az onmouseover-t. Vagy felcserélted, vagy valami ilyesmi.
-
#3801
martonx
veterán
TomyLeeBoy
#3800
martonx
veterán
válasz
TomyLeeBoy
#3800
üzenetére
Ugyan konkrét kód ismerete nélkül csak találgatok, de ez nem inkább szimpla css probléma? Van háttér szín, de valami fölötte van, ezért nem látszik, addig míg az egér hover el nem sül?
-
martonx
veterán
válasz
SirRasor
#3744
üzenetére
Úgy hívják Ajax. Aszinkron Javascript And Xml. Azaz aszinkron módon kellene megoldanod, még ha ezt a fajta programozást kicsit szoknod is kell. Ilyenkor fel kell iratkoznod eseményekre, amik akkor következnek be, amikor az aszinkron feladat véget ért. Ez a szép megoldás.
Konkrétabban direkt nem írom le, gugli a barátod, meg rengeteg szakkönyv van ebben a témában. Bevallom nem olvastam végig mindazt a küzdelmet, amit írtál. Ugye a Java-t nem kevered össze a Javascripttel? A legelején írtad, hogy java-ban kell programoznod, de végig javascriptről beszéltünk. Ugye nem keverednek a fogalmak? Én kérek elnézést, hogy ezt megkérdeztem.
-
martonx
veterán
Ja, én is szopni szoktam velük rendesen. Az a legjobb, amikor agyonreklámozzák, hogy ilyen meg olyan fejlesztői támogatás, meg überkompatibilis wsdl, aztán mikor csinálsz egy Service bindingot a wsdl-ből, akkor nem győzöd a hányadék wsdl-t, meg a generált kódot javítgatni. A fejlesztői támogatás meg kimerül abban, hogy 4 hónap múlva annyit válaszolnak a support ticket-re, hogy más még nem jelzett ilyen problémát, de jogos a felvetés, hogy hibás itt-meg ott (de megoldás persze nincs).
-
martonx
veterán
válasz
Teasüti
#3671
üzenetére
"Elég kevés a JSON, jellemzően eddig csak Google API-k esetén találkoztam vele.
XML-t népszerűbbnek találom azok kevés webservice közt, amikhez szerencsém volt eddig." - figyi az XML a múlt, a JSON a jövő. Viszont historikus okokból persze, hogy rengeteg XML-es webszolgáltatással lehet találkozni, de ez akkor is a múlt (illetve per pillanat még a jelen egy jó része), pont az olyan szopáshalmok miatt, mint amikbe te is belefutsz. Ráadásul a SOAP (a webszerveres xml kommunikáció élharcos protokollja) pont annyira szabványos, mint a HTML, vagyis ahány implementáció, annyiféle kompatiblitiási problémába lehet belefutni. -
#3636
martonx
veterán
Sk8erPeter
#3635
martonx
veterán
válasz
Sk8erPeter
#3635
üzenetére
Akkor egy példával én is szemléltetem, hogy mi értelme lehet:
var MyFunctions = (function (d,w) {
//ez egy publikus property
var value1 = 1;
//ez egy privát property
var value2 = 2;
//ez egy privát függvény
var function1 = function(){
return value1;
}
//ez egy publikus függvény
var function2 = function(){
return value2;
}
return: {
publicValue : value1,
publicFunction : function2
}
})(document, window); -
martonx
veterán
Nem megoldható, mindenképpen kell szerver oldali kód legalább a file mentéséhez. Ezt egy szál pár soros PHP file-lal meg tudod oldani. Kiolvasod a kapott request-et, majd ezt fogod és lemented txt-be.
Ahhoz, hogy azt a txt-t a js-ed ajax-al lehívja és kiolvassa, ahhoz tényleg nem kell szerver oldali kód. -
#3596
martonx
veterán
Sk8erPeter
#3593
martonx
veterán
válasz
Sk8erPeter
#3593
üzenetére
Akkor bocsánat, félre néztem valamit. Bár már magát a felvetést is furcsállottam, hogy ez ne menne, és meglátva a NodeList típust arra gyanakodtam, hogy az okozhatja.
-
martonx
veterán
-
martonx
veterán
keress rá erre, mondjuk gugliban: ajax tutorial
Látatlanban mondom, hogy nézd meg az első 3-at, esetleg a youtube találatok közül is szemezhetsz néhánnyal.Nem kötözködésképpen, de pont PHP-ban nincs olyan, hogy 'alap' megoldás. Maximum van egy módszer, amit nektek tanítottak. De mi ezt alapból honnan tudjuk, hogy nektek mit tanítottak?
-
#3579
martonx
veterán
Sk8erPeter
#3578
martonx
veterán
válasz
Sk8erPeter
#3578
üzenetére
A HTML+js+css kombó, már sokan sokfelé megmondták, hogy a vicc kategória. Minél komolyabban használod, annál tragikusabb.
Másrészt mindenen elfutnak, és ha nem kell bennük megváltani a világot, akkor azért tűrhető energia befektetéssel ki lehet hozni belőlük elég sokat. Ráadásul ha ilyen ütemben fejlődnek (plusz a böngészők, mobil eszközök beépített böngészői is), akkor tényleg ez lesz a jövő. A html+js+css kombó közül mostanra egyértelműen a js a leggyengébb láncszem, erre nagyon ráférne egy alapos ráncfelvarrás. -
martonx
veterán
Mert egy bizonyos szint felett tökéletesen átláthatatlanná, követhetetlenné teszi a kódot.
Debugolást, kód menedzselést is nagyban megnehezíti.Persze ezek mind olyan szempontok, amikkel egyszemélyes fejlesztők simán együtt tudnak élni, sőt ha nem tartják be ezeket a szempontokat, talán még gyorsabban is tudnak gányolni, mint ezen elvek mentén. Aztán persze két év múlva, meg 3 fejlesztővel 3 féle gányolási stílussal később, megy az átkozódás, mikor egy ilyen kódban bármin is módosítani kell.
Mondok egy példát. Van egy js függvényed, amihez hozzá kell adnod egy plusz argumentumot. Nem mindegy, hogy elég csak .js file-okban keresni, módosítani, vagy netán kismillió egyéb html-ben, php-ben, tpl, xsd-ben és még a jó ég tudja mi mindenben kell keresni. És mindez csak azért mert anno valakinek jobban kézreállt milliónyi onclick eseménybe belegányolni, ahelyett, hogy 1-2 rendes általános javascriptes eseménykezelőben kezelte volna le mindazt.
-
martonx
veterán
ja, hogy nem a példával volt a baj, hanem a javascripttel? Kivételesen ebben is tökéletesen egyetértek a tanárral.
Mára minden hülye a Jquery-t használja (köztük én is), miközben fingjuk sincs a tényleges javascriptről. Ráadásul szvsz mostanra a Jquery erősen túl van hype-olva, a modern böngészőkben sok esetben csak minimálissal több munka natív js-ben megcsinálni ugyanazt, mint jquery-vel.
Szerintem az oktatásnak pont az a lényege, hogy az alapokat tanítsa meg. Olyan ez mintha úgy tanítanának programozni, hogy soha nem tanítják meg, hogy mi az a tömb, meg objektum, hanem nesze itt a spring mvc, aztán java-zunk.
Persze akkor lenne igazán szinvonalas az oktatás, ha a tisztán javscript-elés után, ugyanezt a példát megcsinálnák mondjuk jquery-vel, is hogy a tudás legyen naprakész is. De ez már a vágyálom kategória. -
#3505
martonx
veterán
Sk8erPeter
#3504
martonx
veterán
válasz
Sk8erPeter
#3504
üzenetére
Betöltéskor is simán lehet egy ilyen trükkel jópár %-kot faragni a kódod méretéből. Nézd meg a jquery-sek mit össze nem kínlódnak pár Kb-nyi csökkentésért. Plusz a namespace-be szervezés, amúgy is hasznos dolog, összetettebb javascript-es oldalnál.
Besimerem amúgy, hogy ez erősen szőrszál hasogatás persze, de ha már js topik, meg helyes módszertanok. -
#3502
martonx
veterán
Sk8erPeter
#3501
martonx
veterán
válasz
Sk8erPeter
#3501
üzenetére
Erről beszéltem. Egyébként ha már karakter baszók akarunk lenni
(mondjuk egy 1000 soros plain js-nél már számíthat méretben), érdemes var w = window illetve var d = document konvenciókat használni, és utána már csak d.getelement.byId, meg w.addeventlistener-eket használni.
Vagy eleve belerakod egy anonim önmeghívó funkcióba, így a js namespace probléma is pipa:(function(d,w){
//Itt jön a kódod
d.getelementbyid...
w.addevenetlistener...
})(document,window)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
a Netbeans-hez képest. A VS is tudja ezeket, csak lusta voltam ténylegesen így felsorolni. Illetve a jslint, jshint részt csak a Webessential-al tudja, azaz a fizetős verzióban.
(mondjuk egy 1000 soros plain js-nél már számíthat méretben), érdemes var w = window illetve var d = document konvenciókat használni, és utána már csak d.getelement.byId, meg w.addeventlistener-eket használni.Új hozzászólás Aktív témák
- Újszerű HP 14s-dq5001nh - 14"FHD IPS - i5-1235U - 16GB - 512GB - Win11 - Magyar - Garancia
- Gamer PC-Számítógép! Csere-Beszámítás! Mini PC! I5 10600KF / RTX 3060 12GB/ 16GB DDR4 / 1TB SSD
- 22 GB-os RTX 2080 TI - HP OEM - garanciával
- BESZÁMÍTÁS! Asus H370 i5 8700 16GB DDR4 512B SSD RX 6650 XT 8GB Zalman N5 OF ADATA 600W
- HIBÁTLAN iPhone 15 Pro Max 256GB White Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3661, 100% Akkum
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő