Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
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
-
Sk8erPeter
nagyúr
válasz tilla23 #3899 üzenetére
[link] - itt megkérdeztem, a naptár napjaira fog-e kattintani a felhasználó, tehát a napok legyenek-e belinkelve, de azt írta, "Nem a látogató választja a linket és nézi meg azt vagy azt az oldalt, hanem készen kapja az előre megírt szöveget, adatokat." Fogalmam sincs, ez mit jelent. Sajnos a leírásnak ebben a formában nem sok értelme van, ember legyen a talpán, aki ilyen specifikációból kihámozza, pontosan mit is kell csinálni.
Amennyit összeraktam az egész kívánságából, az alapján továbbra sem értem, az egész feladatnak mi köze van a JavaScripthez. Szerintem nem a kliensoldali részét kellene megvalósítania, hanem a szerveroldali sem néz ki még sehogy.Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #3901 üzenetére
Így van, ez továbbra is értelmezési probléma, nem szoftverfejlesztési. Amíg nem tudja leírni érthetően, mit szeretne, addig nincs értelme implementációs részletekkel foglalkozni. Ő is vaskosan keveri a két dolgot, volt itt "script", meg gif, meg jpg izé, épp csak a lényeget nem tudjuk. Azaz, hogy mit lásson a felhasználó az adott oldalon, és milyen interakciókat végezhessen el.
[ Szerkesztve ]
x gon' give it to ya
-
Bogjas
újonc
Köszönöm Uraim a véleményeket!... a feladat megoldva ... viszlát
-
CSorBA
őstag
Sziasztok!
Egy kis segítséget kérnék, és ha szabad így megszólítanom Sk8erPeter fórumtársat, akkor az Ő hozzászólására kiemelten számítok
Szóval a Javascript bubbling and capturing-ról tudnátok mesélni? Kicsit zavarosan az angol leírások. Akár jquery példát hozva, valaki el tudná magyarázni, hogy ez miért jó? Miért és hogy jobb szülőre bindelni eseményt? - Ha jól tudom ezt ajaxos betöltődésnél lehet kihasználni, hogy nem kell újrabindelni a bekért DOM elemekre, hanem elég egy szülőre. De ez gyakorlatban hogy valósul meg, leginkább ez érdekelne.
[ Szerkesztve ]
-
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.
Én kérek elnézést!
-
CSorBA
őstag
válasz martonx #3905 üzenetére
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.
Köszi a választ, viszont pont ez az utóbbi dolog érdekelne. Erre példát, példákat tudna hozni valaki?
-
Sk8erPeter
nagyúr
Hi! Az események buborékszerű felszivárgásáról itt írtam, belinkelve egy példát:
http://prohardver.hu/tema/weblap_keszites/hsz_10515-10516.html
http://prohardver.hu/tema/weblap_keszites/hsz_10543-10543.htmlAz AJAX-os betöltött elemekre kötött event handlerekre jó példa a jQuery.on(), ahol a "delegated events" rész az érdekes, itt tök jól elmagyarázza a helyzetet (kiemeltem a nagyon fontos részeket):
"Delegated events have the advantage that they can process events from descendant elements that are added to the document at a later time. By picking an element that is guaranteed to be present at the time the delegated event handler is attached, you can use delegated events to avoid the need to frequently attach and remove event handlers. This element could be the container element of a view in a Model-View-Controller design, for example, or document if the event handler wants to monitor all bubbling events in the document. The document element is available in the head of the document before loading any other HTML, so it is safe to attach events there without waiting for the document to be ready.
In addition to their ability to handle events on descendant elements not yet created, another advantage of delegated events is their potential for much lower overhead when many elements must be monitored. On a data table with 1,000 rows in its tbody, this example attaches a handler to 1,000 elements:
$( "#dataTable tbody tr" ).on( "click", function() {
alert( $( this ).text() );
});A delegated-events approach attaches an event handler to only one element, the tbody, and the event only needs to bubble up one level (from the clicked tr to tbody):
$( "#dataTable tbody" ).on( "click", "tr", function() {
alert( $( this ).text() );
});[...]
Attaching many delegated event handlers near the top of the document tree can degrade performance. Each time the event occurs, jQuery must compare all selectors of all attached events of that type to every element in the path from the event target up to the top of the document. For best performance, attach delegated events at a document location as close as possible to the target elements. Avoid excessive use of document or document.body for delegated events on large documents.
jQuery can process simple selectors of the form tag#id.class very quickly when they are used to filter delegated events. So, "#myForm", "a.external", and "button" are all fast selectors. Delegated events that use more complex selectors, particularly hierarchical ones, can be several times slower--although they are still fast enough for most applications. Hierarchical selectors can often be avoided simply by attaching the handler to a more appropriate point in the document. For example, instead of $( "body" ).on( "click", "#commentForm .addNew", addComment ) use $( "#commentForm" ).on( "click", ".addNew", addComment )."
Itt tehát a példában az eseménykezelőt a tbody-ra kötötte, ahelyett, hogy az összes tr-re tette volna ugyanezt, így az eseménynek csak pontosan egy szintet kell buborékszerűen felúsznia, a klikkelt tr elemből a tbody felé.
Ide felraktam egy egyszerű példát:
http://jsfiddle.net/Sk8erPeter/Tpc3k/
itt például gombokat adok hozzá egy container elemhez. Az első példában csak az első gomb "reagál" (dob alert() ablakot), mert konkrétan a kód lefutásának pillanatában jelenlévő button elemre kötöttem az event handlert; a második esetben viszont amikor hozzáadok újabb gombokat, azok is dobnak alert()-ablakokat, hiszen ott azt határoztam meg, hogy a szülőelemre legyen kötve az event handler (egyébként itt a lényeg a hierarchia, nem az, hogy közvetlen szülőeleme legyen!), és megadtam egy selectort is (ami a "button"), hogy a leszármazott elemek közül ezekre szűrjön az eseménykezelés során, ezek triggereljék a click eseményt.
Lásd a doksiban a leírást a selectorra:
selector
Type: String
A selector string to filter the descendants of the selected elements that trigger the event. If the selector is null or omitted, the event is always triggered when it reaches the selected element.Tehát a különbség:
első:
$container1.find('button').on('click', function (event) { ... } );
második:
$container2.on('click', 'button', function (event) { ... } );Remélem, nagyjából érthető, ha valami nem tiszta, mert bonyolultan írtam, kérdezz nyugodtan
Sk8erPeter
-
trisztan94
őstag
válasz Sk8erPeter #3908 üzenetére
Hihetetlen, hogy milyen kidolgozott profi válaszokat tudsz adni, kb. mindenkinek aki legalább felig ertelmes kerdest tesz fel, le a kalappal. Tenyleg.
https://heureka-kreativ.hu
-
Sk8erPeter
nagyúr
válasz trisztan94 #3909 üzenetére
Hát köszi. Igyekszik a zzember. Legalább később lehet linkelgetni az ilyen válaszokat, ha valaki rákérdez, és akkor egy csomó időt megspóroltam vele, hogy a megírása kicsit pöcsölős volt.
[ Szerkesztve ]
Sk8erPeter
-
CSorBA
őstag
válasz Sk8erPeter #3908 üzenetére
Éreztem én, hogy téged kell megszólítani Szerintem lassan összedobhatnánk a fórumtársakkal egy sörözést és neked pár sört
Nagyon hasznos leírás, letisztult a kép azt hiszem. Még talán annyi, hogy ugye jQueryben az onclick is valójában .on?
-
Sk8erPeter
nagyúr
"Azt hittem valamiért, h. van egy onclick is ami egyenlő az .on("click"-el"
Igen, lényegét tekintve ugyanaz, lásd a jQuery source code-ot a jQuery.fn.click-nél:
http://james.padolsey.com/jquery/#v=1.10.2&fn=jQuery.fn.clickfunction (data, fn) {
return arguments.length > 0 ? this.on(name, null, data, fn) : this.trigger(name);
}magyarul a jQuery.on() hívódik meg a .click() esetén is, csak nyilván a 'click' paraméterrel. Ugyanígy néz ki például a .dblclick() is ([link]).
A jQuery.on()-nál már láthatsz viszont különbséget, csak kukkants rá:
http://james.padolsey.com/jquery/#v=1.10.2&fn=jQuery.fn.onAz .on() általános eseménykezelő-hozzákapcsoló.
Lehetne akár .on('dblclick', ...) is. Annyi a különbség, hogy a $('#valami, .blabla').dblclick(...) egyértelműen a selectorral kijelölt elemekhez kapcsol egyértelműen megnevezett eseménykezelőt, és itt még nem tudsz átadni selectort, ami szűr azokra az elemekre, amiknek ki kéne váltani az adott eseményt, és ezt a különbséget emeltem ki itt a tbody-tr példánál. Tehát például a .click() nem fog működni AJAX-szal hozzáadott elemekre.[ Szerkesztve ]
Sk8erPeter
-
martonx
veterán
-
cSuwwi
aktív tag
pedig még lehetne fokozni.
pl. asszem 1.7 előtt nem volt "on", live-al kellett/illett kezelni, vagy jQ előtt az addeventlistener-es megoldások. A click esemény az IE kivételével mindenhol click volt, IE alatt mindenhova kellett az "on" előtag (onclick, onsubmit, ...).
keverhető még a nem diszkrét js-t használó oldalakon a különböző tagekre ráaggatott eventekkel, onclick buttonoknál, vagy onsubmit formokon.
sok "on" van és mind ugyanaz -
Sk8erPeter
nagyúr
válasz martonx #3915 üzenetére
Most miért? Amúgy meg ő kérdezte, hát akkor kapott rá választ. Bár most így hirtelen nem jön le, mi a magyarázatomból az érthetetlen, de majd megírja.
(#3916) cSuwwi :
.bind() volt már 1.0-tól, .live() 1.3-tól, meg .delegate() volt 1.4.2-től... 1.7 után szerencsére már egységesen az .on() az ajánlott.lásd a .live() dokumentációjában:
$( selector ).live( events, data, handler ); // jQuery 1.3+
$( document ).delegate( selector, events, data, handler ); // jQuery 1.4.3+
$( document ).on( events, selector, data, handler ); // jQuery 1.7+"jQ előtt az addeventlistener-es megoldások. A click esemény az IE kivételével mindenhol click volt, IE alatt mindenhova kellett az "on" előtag (onclick, onsubmit, ...)."
Nemcsak .addEventListener, hanem .attachEvent az IE miatt, if-else formában..."különböző tagekre ráaggatott eventekkel, onclick buttonoknál, vagy onsubmit formokon"
Aki inline onclick, onsubmit, stb. attribútumokat használ, az meg is érdemli."sok "on" van és mind ugyanaz "
Azt hogy érted, hogy "ugyanaz"? Azért eléggé más tud lenni a szerepük az eventeknek...Sk8erPeter
-
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.
Én kérek elnézést!
-
cSuwwi
aktív tag
válasz Sk8erPeter #3917 üzenetére
attachEvent-re gondoltam csak régen volt már nem ugrott be
bind, on, live megvolt, többi sose kellettohh, nagyon sok oldalon van még most is inline js event, nem csak kezdőknél/kis siteokon
vajon miért nem kopik ki a köztudatból?a sok on-al nincs gondom, csak nem fogalmaztam jól sry
-
fordfairlane
veterán
vajon miért nem kopik ki a köztudatból
Mert egyszerű, és mert szemantikailag nem olyan rossz az (félig jó ). Látod magánál az elemnél, ha van hozzá kötve eseménykezelő.
Az már kevésbé jó, hogy az on(event) attribútumba nem egyszerűen metódusnevet írsz, amit a javascript hozzáköthet az adott elemhez, hanem gyakorlatilag komplett scriptet rakhatsz bele inline.
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz martonx #3918 üzenetére
Hát ja. Kezdőnek egyértelmű, hogy bűn jQuery-vel kezdenie, mert később már nem fogja akarni megtanulni, milyen munkafolyamatot is egyszerűsít le.
Mondjuk szerencsére a 11-es verzió óta már az IE sem számít annyira szitokszónak, mint régen (még ha a felhasználói felület ostoba is még mindig), így ritkul az, hogy böngészőspecifikus baromságokat kelljen tákolni (lásd az IE-specifikus attachEventet régről az addEventListenerrel szemben), ezért a plain JavaScript is talán használhatóbbá kezd válni, mint régen, ami egyébként vicces helyzet, de azért még mindig sokat segít a cross-browseresítésben a jQuery... aztán az megint egy következő szint, hogy valaki értse, hogy a $('#test') és document.getElementById('test') hiába hivatkozik ugyanarra az elemre, attól még az első egy jQuery objectet ad vissza, a másik pedig egy Element objectet...
Persze mindezek értéséhez/sejtéséhez először is tudni kellene használni a dokumentációkat, ami ahogy a topicokban észreveszem, sajnos cseppet sem magától értetődő. Meg hát érted, majd a fórumon a srácok megmondják...(#3919) cSuwwi :
Sztem azért nem kopik ki, mert az onclick és többi hasonló attribútumot eleinte gyorsabb bepötyögni egyből az elemhez, és meglátni, hogy mi történik - ez a tanulási fázisban még az elfogadható érvek közé tartozik, én is így kezdtem, csak van, aki aztán megragad ezen a szinten, és azt mondja, hogy de hát így könnyebb olvasni, és egyből tudom, hogy ahhoz az elemhez milyen eseménykezelő tartozik. Na ez egy baromság. Sokkal nehezebb karbantartani egy ilyen széttákolt kódot. Eleve ott kezdődik, hogy mindegyik nyelvnek legyen meg a maga jól körülhatárolható felelőssége, ne legyen szétgányolva a JS-kód CSS-sel vagy HTML-lel se. A PHP-kódban se legyen lehetőleg stringként inline behányt JavaScript-kód. Meg hasonlók. Persze vannak fejlesztők, akik ezekre is megtalálják az önigazoló magyarázatokat, de nem ők csinálják jól.Szerintem erről ez egy nagyon jó összefoglaló diasor:
Refactoring to Unobtrusive JavaScript
http://www.slideshare.net/fgalassi/refactoring-to-unobtrusive-javascript
(lehet, hogy meg is kérem, hogy ezt tegyék be az 1. hsz.-be, csak hogy mindenkinek szem előtt legyen, nagyon tömören elmagyarázva, mit, hogyan kéne)Na meg amúgy a net tele van szemétrevaló tutorialokkal is, amik a rossz szokásokat verik az emberek fejébe.
=====
(#3920) fordfairlane :
Kicsit később küldtem el, mint Te, mert kotorásztam a belinkelt diasor után, így csak most látom, amit írtál, de közben Te is azt a szempontot írod, hogy látod magánál az elemnél, hogy hozzá van kötve az eseménykezelő, és az jó... de ne már.
Ezzel nyugodtan alá lehetne támasztani azt is, hogy formvalidálásnál minden egyes inputra külön-külön dobjuk be mondjuk onblurre a validáló függvényt. Vagy akkor ez ne legyen, csak egyszer, magán a form csomóponton legyen egy onsubmit-attribútumba bedobott függvénynév, mert az épp a határon mozgolódik a tákolmány és a karbantartható kód között? Érted, ezzel a hozzáállással (mondjuk ha valaki ilyen tutorialt ír) a kezdők is kedvet kaphatnak hozzá, hogy na, akkor ilyen alapon mehet minden az attribútumokba, mert azt írták, hogy jó az, és akkor ránézek a HTML-kódra, és tök jó, hogy egyben látom a JavaScript-kódot is. De akkor ugyanígy nem lenne helytelen az sem, hogy valaki style-attribútumban határozza meg az adott elem kinézetét. Az sem magyarázható, bár elméletileg ezen az elven az is jó lehetne, mivel akkor tök jó, hogy helyben látja az illető, hogy fog kinézni az elem.[ Szerkesztve ]
Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #3921 üzenetére
Ezzel nyugodtan alá lehetne támasztani azt is, hogy formvalidálásnál minden egyes inputra külön-külön dobjuk be mondjuk onblurre a validáló függvényt. Vagy akkor ez ne legyen, csak egyszer, magán a form csomóponton legyen egy onsubmit-attribútumba bedobott függvénynév, mert az épp a határon mozgolódik a tákolmány és a karbantartható kód között? Érted, ezzel a hozzáállással (mondjuk ha valaki ilyen tutorialt ír) a kezdők is kedvet kaphatnak hozzá, hogy na, akkor ilyen alapon mehet minden az attribútumokba, mert azt írták, hogy jó az, és akkor ránézek a HTML-kódra, és tök jó, hogy egyben látom a JavaScript-kódot is. De akkor ugyanígy nem lenne helytelen az sem, hogy valaki style-attribútumban határozza meg az adott elem kinézetét. Az sem magyarázható, bár elméletileg ezen az elven az is jó lehetne, mivel akkor tök jó, hogy helyben látja az illető, hogy fog kinézni az elem.
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. Az, hogy te mit tartasz jónak, meg logikusnak, meg karbantarthatónak, az ezen a véleményemen nem fog változtatni.
[ Szerkesztve ]
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz fordfairlane #3922 üzenetére
Mit tekintünk ez esetben "tisztességes implementációnak"?
"Az, hogy te mit tartasz jónak, meg logikusnak, meg karbantarthatónak, az ezen a véleményemen nem fog változtatni."
Te ezek szerint nem tartod karbantarthatóbbnak a szeparált JS-kódot?
Igazából te sem fogsz változtatni a véleményemen, mert szerintem ettől még továbbra is rontja a karbantarthatóságot, és még ha régen én is csináltam ilyesmit, ma már inkább nem követnék el ilyen merényletet, csak nagyon kihangsúlyoztad, hogy ezt csak én gondolom így. Pedig a korábban belinkelt cikk is pontosan ennek a kutyulódásnak a negatív hatásait fejtegeti röviden.===========
Más: össze kéne már gyűjtenünk közös erővel olyan linkeket, amiket bedobhatnánk a téma-összefoglalóba. Szóval ha van olyan cikk, amit jónak tartotok, és kapcsolódik a JavaScripthez, akkor dobjátok be plíz!
Sk8erPeter
-
CSorBA
őstag
Én köszönöm a segítségeket, hasznosak voltak. Ha valami nem lenne tiszta esetleg gyakorlatban még, akkor úgyis kérdezek
-
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.
Én kérek elnézést!
-
fordfairlane
veterán
válasz martonx #3925 üzenetére
Mégegyszer: Nem az onevent attribútumot védem jelen implementációs formájában, hanem azt, hogy van logikája az attribútum-event kötésnek. Az event binding összekötő elem, nem tisztán struktúra vagy viselkedés téma. Mint ahogy a data-binding sem az, amikor két nyelv közti adatcserét deklarálsz, lásd angular vagy knockout.js.
x gon' give it to ya
-
fordfairlane
veterán
válasz Sk8erPeter #3923 üzenetére
Mit tekintünk ez esetben "tisztességes implementációnak"?
Például egy angularjs-t, ahol egyedi attribútumokkal kötöd össze a megfelelő html kódot a script modell vagy a controller objektumaival.
x gon' give it to ya
-
Jim-Y
veterán
válasz Sk8erPeter #3923 üzenetére
Szia, gondoltam csinálok egy alapot a téma-összefoglalónak, mert ha valaki nem kezdi el, akkor nem lesz belőle semmi
a bejegyzés végén van egy raw link, ami arra szolgál, hogyha valaki bővítené szeretné, vagy csinosítani/egyéb, akkor meglegyen a forrás. üdv
-
Jim-Y
veterán
-
Sk8erPeter
nagyúr
válasz fordfairlane #3927 üzenetére
Ja értem, ezek szerint akkor mindketten félreértettük, amire gondoltál, sorry. Eleinte azt hittem, azt véded, ha valaki behányja a konkrét függvényhívást vagy akár implementációt az onclick-be és társaiba, de így utólag visszaolvasva egyértelműen kihangsúlyoztad, hogy nem erről van szó, csak akkor nem jött át, bocs.
Sk8erPeter
-
Sk8erPeter
nagyúr
Tegnap én is csináltam egy nagyon rövidet, csak ilyen tök egyszerűekkel, hogy linkek jsFiddle-re és társaira, és hogy aztán bővítjük, csak aztán nem küldtem el a modker topicba, de most megtettem, de majd holnap átrágom azt is, amit írtál.
Most csak nagyon gyorsan átfutottam, és jó linkek vannak benne, de szerintem kissé túl sok, nem tudom, ki fog elolvasni/megnézni ennyi mindent; például a végefelé a Twitteres linkek úgy, ahogy van, felejtősek, tök felesleges ezeket belerakni, szerintem nem illenek a PH-s összefoglalóba (érdekességként lehet őket követni, de ide inkább a tanulást elősegítő vagy hülye kérdéseket megelőző linkeket kellene bepakolni).[ Szerkesztve ]
Sk8erPeter
-
Zedz
addikt
Sziasztok!
Ez a kód miért nem működik? Miért nem reagál az if-en belüli this szóra?
Szerk.: a dolog lényege, hogyha üres az input mező akkor az alá szúrjon be valamit.
[ Szerkesztve ]
-
Jim-Y
veterán
Több gond is van vele, egyrészt $(this) és nem $('this'), mert utóbbi esetben a DOM this tageket szűrnéd ki vele.
Másrészt amit meg akarsz csinálni azt nem így kell, mert a a $(this) ebben a kontextusban az oldalon található input mezőket adja vissza.
A $(this).length == 0 akkor igaz, ha az oldalon nincs <input>.Helyesen: [link]
Magyarázat:
- a this mindig a hívó objektumra utal. Ebben az esetben amire a focusout-ot meghívtuk. Mire hívtuk? $('input')-ra ami egy olyan objektum ami az oldal összes input mezejét tartalmazza.
- a $(this) a this objektumból csinál egy jquery objektumot, így a $(this)-re meghívhatjuk a jquery-s függvényeket. Mint a példában: $(this).after("<p>Empty this</p>");
Az after egy jquery metódus, jquery objektumokon van értelmezve. this.after() hibás!
- a this.value helyett írhattunk volna $(this).val() -t is, ugyanazt az eredményt kapjuk. Ellenben, míg a value az input element beépített property-je, addig a val() egy jquery-s függvény, valószínűleg a val()-is a value-t kérdezi le. Annyi különbség mégis van, hogy a val() egy jquery objektummal tér vissza, tehát működik rajta a method chaining.[ Szerkesztve ]
-
Karma
félisten
"- a this mindig a hívó objektumra utal. Ebben az esetben amire a focusout-ot meghívtuk. Mire hívtuk? $('input')-ra ami egy olyan objektum ami az oldal összes input mezejét tartalmazza."
Ez nettó marhaság, az eseménykezelő függvényekben mindig az az egy elem a this, aki az eseményt generálta. Tehát semmi szükség ID-t adni a bemeneti mezőnek! Sőt!
Itt van máshogy megjavítva a kód. Mint látható, csak két gond volt a kóddal: az aposztrófok a this körül, és hogy nem az input mező értékét próbálta lengthtel ellenőrizni. Bátorkodtam sokszorosítani az input mezőket, hogy demonstráljam az álláspontomat.
[ Szerkesztve ]
“All nothings are not equal.”
-
Jim-Y
veterán
"- a $(this) a this objektumból csinál egy jquery objektumot, így a $(this)-re meghívhatjuk a jquery-s függvényeket. Mint a példában: $(this).after("<p>Empty this</p>");
Az after egy jquery metódus, jquery objektumokon van értelmezve. this.after() hibás!"Meg ez is...
Hát pedig ha akarod, ha nem, ez így van
Ez nettó marhaság, az eseménykezelő függvényekben mindig az az egy elem a this, aki az eseményt generálta. Tehát semmi szükség ID-t adni a bemeneti mezőnek!
Az eseménykezelőknél ez lehet, hogy így van (ezt nem tudtam), de általánosságban, javascriptben, pedig úgy, ahogy írtam. Tehát marhaságnak nem marhaság, sőt, csak ez esetben pontatlan.
[ Szerkesztve ]
-
Karma
félisten
Igen, azt a részt épp most szerkesztettem ki a HSZ-ből. Az ott tényleg nem para, csak megtévesztett, hogy nem releváns Az ő kódjában semmi gond az afterrel.
Azontúl, hogy újra meg újra odailleszti a szöveget. De ezt meg nem kérdezte
[ Szerkesztve ]
“All nothings are not equal.”
-
Sk8erPeter
nagyúr
"Az eseménykezelőknél ez lehet, hogy így van (ezt nem tudtam), de általánosságban, javascriptben, pedig úgy, ahogy írtam."
Ezt hogy érted, hogy általánosságban? Mármint mire vonatkozóan?(#3928) :
ezt a linkes dolgot végül elfelejtettem, szerintem nyugodtan mehetnek a linkjeid végül is az összefoglalóba, hasznos anyagokat szedtél össze, főleg a Douglas Crockford-előadássorozat jó lesz oda.
Szóval nyugodtan berakathatnád a modker topicban!
Csak a Twitteres követősdi nem kell szerintem.[ Szerkesztve ]
Sk8erPeter
-
caindwan
tag
Heló!
Hogyan lehet float-ból a tizedes pont utáni összeget int-be kinyerni? pl 2.3441 = 3441 -
BomiBoogie
MODERÁTOR
Frissült a téma összefoglaló!
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #3938 üzenetére
Most nézem a Jim-Y jegyzetekkel kiegészített összefoglalót... na basszus, nem ártott volna még lektorálni előtte. Én inkább az elején lévő linkekre koncentráltam, amiket be lehetett volna rakni, de vannak benne rendkívül összeszedetlen részek, például van egy ilyen rész: "Ha a saját gépünkön szeretnénk tesztelni a megírt js kódunkat" - utána meg az következik, hogy hogyan tudjuk felrakni a Node.js-t... Mégis hogy jön ide? Vagy akkor miért nincs kiegészítve azzal, hogy mi a különbség a kliensoldali és szerveroldali JavaScript-kódok között? Egy olyan emberke, aki épp szeretné elsajátítani a JavaScriptet, az valószínűleg teljesen össze lesz zavarva ezek után.
Sk8erPeter
-
BomiBoogie
MODERÁTOR
válasz Sk8erPeter #3943 üzenetére
Itt a raw, javítsátok, ahogy gondoljátok és frissítem.
-
Jim-Y
veterán
válasz Sk8erPeter #3943 üzenetére
A node js-el jon egy js interpreter amivel a js fleodat tudod clin keresztul tesztelni. De a nodejs meg nincs alapbol felteve ezert le kellett irni hogy hogyan tegye fel az ember. A nodejs ebben az ertelemben csak a bongeszobe epitett interpreter alternativaja. Egyebkent tudtommal lehet kerni modositast a modkerben. Ha szerinted valami rossz akkor nyugodtan szedesd ki nem fogok megsertodni, bar szerintem pont ez a nodejs-es resz tok hasznos.
Nekem sokszor nagyon jól jött volna, ha ezt már korábban ismerem, például ha csak ki akarom próbálni élesben, hogy mit csinál a map(), akkor nem csinálok
- egy .js fájlt benne implementálva egy tömböt, meghívva rá a map-et.
- illetve egy html fájlt, amiben hivatkozok a js fájlra,
- majd a html fájlt megnyitom a böngészőbenVagy,
- nem nyitok egy firefoxot, benne egy konzolt
- meg egy scratchpad-etVagy megyek a jsfiddle-re
Hanem nyitok pl egy aptana studio-t, vagy a geditet (mindkettőben van embedded terminal) és sokkal gyorsabban tudom tesztelni a megírt kódomat, mint a fenti esetekben. Én csakis ezért írtam bele az összefoglalóba azt a részt. De mondom, ha tényleg kusza, akkor szedjük ki, vagy fogalmazzuk át.
[ Szerkesztve ]
-
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ű.
Én kérek elnézést!
-
Sk8erPeter
nagyúr
Nem szántam offenzívnek, mert amúgy hasznos anyagokat gyűjtöttél össze, raktál bele energiát, bocs, ha úgy tűnt.
Inkább jelezni szerettem volna, hogy az említett rész a Node.js-sel ebben a formában még egy kezdőt nagyon nagy eséllyel teljesen összezavar, mert abban a fázisban az sem tiszta, mi az a kliensoldali és szerveroldali JavaScript-kód, mi az a Node.js, és még kismilliónyi lehetőség van a Node.js telepítése előtt, amivel ki lehet próbálni a JS-kódot. Na meg akkor már a Windows-ra telepítés módszerét is meg kéne említeni. Mondjuk az csak egy installer-fájl a nodejs.org-ról: http://nodejs.org/. Amúgy érdekességként: Windows-on lehetséges Web Platform Installeren keresztül is bekattintani a Node.js telepítését."Nekem sokszor nagyon jól jött volna, ha ezt már korábban ismerem, például ha csak ki akarom próbálni élesben, hogy mit csinál a map(), akkor nem csinálok
- egy .js fájlt benne implementálva egy tömböt, meghívva rá a map-et.
- illetve egy html fájlt, amiben hivatkozok a js fájlra,
- majd a html fájlt megnyitom a böngészőben
Vagy,
- nem nyitok egy firefoxot, benne egy konzolt
- meg egy scratchpad-et
Vagy megyek a jsfiddle-re"Ezek például mind jó alternatívák, amiket meg lehet említeni.
A böngészőt az ember úgyis folyton megnyitva tartja. Ott nyom egy Ctrl+Shift+I (vagy F12) billentyűkombót, és az ennek segítségével előhívható fejlesztői panelon keresztül, a Console fülön tud tenni egy gyorspróbát a JS-kódokkal; a fejlesztői panellel úgyis minden webfejlesztőnek meg kell ismerkednie."Hanem nyitok pl egy aptana studio-t, vagy a geditet (mindkettőben van embedded terminal) és sokkal gyorsabban tudom tesztelni a megírt kódomat, mint a fenti esetekben."
Ez is egy módszer.
Egy haladó részben esetleg azt is meg lehetne említeni, hogy mind böngészőn, mind integrált fejlesztőkörnyezeten (IDE) keresztül van lehetőség JavaScript-kód debuggolására, utóbbira példa a NetBeans Connector, ami szerintem nagyon hasznos, itt tettem róla említést:
http://prohardver.hu/tema/weblap_keszites/hsz_10596-10596.html
http://stackoverflow.com/questions/15801506/how-to-debug-javascript-and-php-togheter-in-the-same-netbeans-7-3-project/20809988#20809988Szívesen foglalkoznék ezzel, de se időm, se energiám most erre.
(#3944) BomiBoogie :
OK, köszi, reméljük, lesz előbb-utóbb valakinek ideje rá, vagy nekem, vagy másnak.[ Szerkesztve ]
Sk8erPeter
-
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.
Én kérek elnézést!
-
Sk8erPeter
nagyúr
válasz martonx #3948 üzenetére
De az JScript-interpreter, nem JavaScript.
Komolyra fordítva amúgy igazad van (mondjuk nálam nem túl sokszor merült fel az igény a cscript.exe-vel történő JS-futtatásra, az ilyen módon történő tesztelésre ), szerintem is jobb lenne egy külön részbe tenni a Node.js-t úgy általában, azt inkább a haladóknak ajánlva, és a kezdőknek szóló részből egyszerűen kiszedni, hogy ne zavarjuk össze a kezdő ember fejét - szerintem jobb, ha nem kavarunk be neki a szerveroldali programozást lehetővé tevő nodejs-sel, mert nem fogja tudni hova tenni, amikor ő csak eseménykezelőt akart kötni egy gomb klikk eseményére, vagy JS-sel meg akarta változtatni egy elem betűinek színét. Vagy max. nagyon OFF-ként benthagyni, de én sem látom szükségét.[ Szerkesztve ]
Sk8erPeter
-
BomiBoogie
MODERÁTOR
válasz Sk8erPeter #3947 üzenetére
Rendben, jelezzetek privátban.
Új hozzászólás Aktív témák
- DVB-T, DVB-S (2), DVB-C eszközök
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- MG4 menetpróba
- Vezetékes FEJhallgatók
- Mit tehetsz jogilag, ha átvertek, megkárosítottak a Hardveraprón?
- Skoda, VW, Audi, Seat topik
- Vicces képek
- Escape from Tarkov
- koxx: Bloons TD5 - Tower Defense játék
- Milyen belső merevlemezt vegyek?
- További aktív témák...
- Új, Bontatlan MacBook Air 13 M1 chip modell eladó! Újat használt áráért számlával garanciával!!
- Razer Blade 16 2023 (i9 13950HX,RTX 4090 16Gb, 32GB DDR5 5600Mhz, 2x 1TB, 16" Dual UHD+FHD+ MiniLED)
- Lenovo Thinkbook 15 G2 i5-11TH/16Gb/256 Gb SSD/Full Hd
- I7 - GAMER /8700K + VÍZ - Z370 - 16GB DDR4 - 512GB NVME - 4TB HDD -RX 6600/8GB DDR6- 700W - RGB HÁZ
- EVGA 850W BQ 80+ BRONZE