adat átadás linkből jQuery-nek
Sziasztok!
Egyszerűen nem találom a módját hogy egy linkből vagy egy "trigger" területről adatot adjak át jQuery funkciónak.
A kódot csak szemléltetésnek írtam (főleg a data tulajdonságot):
(elvileg úgy működne hogy ha rákattintok az 1-re akkor a h1-nek az tartalmát lecseréli a Nagy Károly-ra, de ezt nem tudom hogy mivel kellene mert sehogy nem tudom kiolvasni az adatot)Ha input mező lenne akkor szépen működne, de így nem találom a módját az átadásnak, egyáltalán milyen kulcssóval keressek rá a neten (link data passing és hasonlóakon már kerestem, de nem találtam működő segítséget)?
Előre is köszönöm!
■ Egyszerűen nem találom a módját hogy egy linkből vagy egy "trigger" területről adatot adjak át jQuery funkciónak.
A kódot csak szemléltetésnek írtam (főleg a data tulajdonságot):
(elvileg úgy működne hogy ha rákattintok az 1-re akkor a h1-nek az tartalmát lecseréli a Nagy Károly-ra, de ezt nem tudom hogy mivel kellene mert sehogy nem tudom kiolvasni az adatot)
<h1>Adat helye</h1>
<a href="#" data="Nagy Károly">1.</a>
<a href="#" data="Kiss Béla">2.</a>
Előre is köszönöm!
elvileg valahogy így
Köszönöm
Jó
Egyszerűen?
Igen, ha nem akarod a data-xxx használni
Gábor 4. sorába teheted.
Szerk: elírtam, helyesen
attr
.Én azért inkább javasolnám a
Szabvány? :)
Akkor nem lenne a .attr fv, ez nem szabvány, mindössze ajánlás, kényelmi funkció. A (html) szabvány annyit mond ki, hogy tetszőleges nevű és számú attribútumokat használhatsz (nyilván nem célszerű ide építeni adatbázist, de akár azt is lehet). A data-xxx nevűek arra jók, hogy lehessen mégegy jquery fv, ami kódba égetve csak az ilyen kezdetű attribútumokat keresi... Semmi köze semmilyen szabványhoz.
Embedding custom non-visible
dataset
tulajdonság írásával/olvasásával lehet használni.+1
Ajánlás
Poetro már belinkelte a
Annyit tennék hozzá, hogy ennek az attr függvénynek semmi köze, az csupán egy jQuery wrapper az Element.getAttribute/setAttribute vagy az Element.attributes körül (konkrétan nemtom melyiket használja, de mindegy is), amik a DOM szabvány részei. Tehát ez egy általános dolog, annyi köze van a HTML-hez, hogy abból is építünk DOM-ot.
További tévhitek eloszlatása végett a jQuery data() függvényének annyi köze van a data-* attribútumokhoz, hogy ha az elemen van data-* attribútum a megfelelő névvel, akkor azt felhasználja az adattár inicializálásához. Merthogy ez egy adattár funkciót valósít meg:
Ha például a data()-val tárolsz egy adatot az elemen, akkor az már nem is íródik vissza se a dataset-be, se az elem attribútumaiba, mert a tárolás nem ott történik. Demó.
Pár kérdés
Miért kell a preventDefault, hiszen a href="#" miatt úgysem fut le a hívás, ez form-nál lenne fontos nem?
Ha több adat van átadásra én most úgy oldottam meg hogy data-lastname="Nagy" data-firstname="Károly"... stb, ezt így a végtelenségig fokozhatom vagy inkább használjak egy adatmezőt és arra írjak egy feldogozót pl: data-adatok="Nagy|Károly|Budapest|1980.01.01" és akkor ezt a feldolgozás során a "|" elválasztók mentén szétszedem?
Előre is köszönöm!
Lefut a hívás attól még, kell
Több adatnál attól függ a válasz, hogy mire akarod használni még. Az attribútumok sok mindenre használhatóak, írhatsz rá CSS selectorokat (például stílusolhatod az N betűvel kezdődő vezetéknevű embereket), használhatod a tartalmukat before/after elemek tartalmaként és így tovább. Én inkább ezt az utat javasolnám.
Ha csak egy adattárolóra van szükséged, elképzelhető, hogy nem egy HTML attribútum a legalkalmasabb erre (ha mégis ezt akarod, valami kitalált elválasztó helyett használj inkább JSON-t). Én inkább egy objektumban tárolnám az adatokat, a HTML elemre csak a kulcsot raknám ki attribútumként, ha már ez az irány.
ahogy a többiek is mondják az
használhatsz simán span-t is és css-ben tolsz rá egy cursor:pointer; szabályt (bár ezt a többiek lehet, hogy megcáfolják).
szerintem nyugodtan használj több data-* attribútumot. aztán ha nagyon elfajul a dolog, akkor meg csináld azt, hogy data-id és akkor egy js tömbben id alapján megtalálod..
A spantól óva intenék, mert
Ez alapján a spannál még a link is jobb megoldás, szerintem.
éreztem én, hogy sántít a
Bonyolult
Amikor egy
<a>
elemen kattintunk, az alapértelmezett viselkedése az, hogy ahref
attribútumában lévő hivatkozást megnyitja a böngésző.Ha a
href
-be egy meztelen # jelet teszel, akkor a következő a helyzet: az url két részből áll, az első része (a kettőskereszt előtt) üres, azaz megegyezik az épp megnyitott oldal url-jével. Azaz ekvivalens mondjuk ezzel:<a href="http://localhost/unregistered/adatok.html#">
A kettőskereszt utáni részben lehet hivatkozni az adott oldal egy bizonyos id-jű elemére, azaz, ha azt írod be, hogy
<a href="#mutato">
, akkor az adott oldalon belül a mutato id-jű elemre helyezi a fókuszt a browser, és odagörget, hogy láthatóvá váljon.Mivel jelen esetben a kettőskereszt után nincs beírva semmi, az oldal tetejére ugrik a
<a href="#">
linkre kattintva.Ezt megakadályozandó két lehetőség van:
1, A link
onclick
eseménykezelőjéhez hozzárendelhetünk egy függvényt. Ha ez a függvényfalse
értékkel tér vissza, akkor a böngésző nem nyitja meg ahref
attribútumban lévő linket, ha nemfalse
, akkor viszont igen.onclick
eseménykezelőjében megkapjuk az eseményt. Az esemény alapértelmezett működését (jelen esetben a link megnyitását) megakadályozhatjuk, ha meghívjuk az esemény objektumpreventDefault()
függvényét.false
-szal visszatérni, mivel a böngésző már nem veszi figyelembe azonclick
visszatérési értékét.Mellesleg a
return false;
-os megoldás gyorsabb (mivel nem kell egy plusz műveletet elvégezni az esemény objektumán).a return false nem biztos,
Nem jobb
return false
esetében három dolog is történik, akkor nem értem, miért gyorsabb úgy a futás.Másrészt érdekes, hogy bár munkásságom alatt rengeteg weboldallal dolgoztam, de összesen egyszer vagy kétszer lett volna olyanra szükség, hogy egy elemre és/vagy szülőjére a linkelt írásban leírt módon két eseménykezelőt tegyek.
-
Úgy látom, a linkelt írás teljesen jQuery specifikus,
addEventListener
t használva a csatolt eseménykezelőben nem is veszi figyelembe areturn false;
-ot.egyszer vagy kétszer lett
Nekem sokszor. Honnan tudod, hogy akinek ajánlasz egy módszert, ugyanolyan "szerencsés" lesz, mint te? Ezért javaslok a kezdőknek mindig olyan módszereket, amikkel kevésbé futnak bele felesleges szopásokba.
Például eseménykezelésre pont emiatt csakis addEventListener (vanilla JS esetén). Nem is kell tudniuk, hogy létezik onclick és társai, majd egyszer megtudják. Évek óta nem használtam őket. Ugyanígy preventDefault, mert az azt csinálja, ami a nevébe van írva, nincsenek mellékhatások. Most tök mindegy, hogy a return false-nak konkrétan vannak-e mellékhatásai ebben az esetben, a linkelt írás valóban jQuery-ről szól, de egy kezdő fejében ez csak zavart okoz, tehát felejtsük is el egyelőre. Lesz ott elég zavar még, amit viszont nem kerülhetünk ki, hanem fel kell oldani.
A kód épp annyira van szánva emberi használatra, mint gépire. Különben gépi kódot használnánk. És az cseszett gyors lenne. De ismét hangsúlyoznám az itt felbukkanó kezdők érdekében, felejtsük el a mikroszekundumokat. Ne is hozzuk fel kezdő topikokban, azt javaslom. Köszönöm.
Tudsz mutatni példát?
Szívesen, de mire?
hogy egy elemre és/vagy
Elolvastam a linkelt írást,
Nem érzek elegendő konstruktivitást benned ahhoz, hogy energiát fektessek további példákba :).
Szeretném megérteni
mondjuk a linkjeidet
de amúgy tökmindegy. van egy lehetséges probléma és van rá egyszerű megoldás, akkor azt próbáljuk elkerülni, és ha tudunk erről akkor ne reklámozzuk tovább az adott problémát (még ha amúgy a saját munkánk során simán bevállaljuk, akkor se.)
Oké
Nem is kell tudniuk, hogy
Miért veszed el tőlük a választás jogát, hogy mit tudhatnak meg és mit nem?
Továbbra sem értem, hogy
Kezdőnek nézem őket, mivel azok.
Ha a neten pl. onclickkel találkoznak, zárják be azt a tabot (többnyire én is ezt teszem). Csak nagyon speciális esetben érdemes tovább olvasni, az meg nekik úgyse fontos még. Aki neten publikál, legyen minimálisan igényes a kódjára. Ha nem az, időpazarlás olvasni.
Ezt a szabályt betartva egy rakás olyan hibától megóvják magukat, amivel még ráérnek találkozni. És ráadásul nem szoknak hozzá a fostalicska példakódok használatához :).
Egy kezdőnek úgy segítesz, ha megmutatod neki, merre menjen. Nem úgy, ha kiröhögöd utána, mennyire béna, hogy eltévedt. Megtudhatnak bármit, de ha az én segítségemet kérik, akkor én megmutatom a rövidebb utat. Ami persze attól még rohadt kemény út, de legalább értelmetlen kitérők nélküli.
Amúgy nem te szoktál folyton hisztizni, hogy a JS túl bonyolult és túl sokféleképpen lehet dolgokat megcsinálni? Segítsünk magunkon, használjuk csak a legjobb részeket. Ld. Crockford bácsi.
ha az én segítségemet kérik,
CSS-sel például nagyon szép animációkat lehet csinálni, ezért egyre kevesebb oldalon találkozunk olyan javascriptekkel, amik segítségével saját animációt tudunk készíteni. Ettől függetlenül ezek nem lesznek elavultak, mert lehet, hogy olyat kérnek tőlünk, amit stílusokkal nem lehet megvalósítani, ekkor jól jön a régi tudás.
Megmutatom neki, hogy milyen
Úgy általában elhiszed amit írsz? Te egy út mellett szoktál kampányolni. Tűzzel vassal.
Amúgy hagyjál ezzel a lejáratós hülyeséggel már békén :). Te járatod le magad, semmi közöm hozzá. Ádám majd törli ezt a szálat is, aztán vagy lesz okulás vagy nem. Eddig többnyire ésszel cenzúrázott.
A kezdőnek épp az a baja, hogy nem tudja mi kell neki. Ezért eleinte kímélni kell a döntéstől. Ha eljut egy jó szintre, simán tudja majd az ósdi rendszert is tracskolni. Könnyen szerez már új tudást, mert az alap rendszere jó, lehet rá építkezni.
na persze
Ha valaki emberről van szó (nem csak kezdő), akkor Gábor valóban több megoldást szokott vázolni, és nem kardoskodik egy mellett (mint te). Ezt én becsülöm benne, mert ebben a szakmában ez az egyik legfontosabb: mindig legyél nyitott új megoldásokra, vizsgáld meg, teszteld, és ha van rá lehetőséged, másokat is vonj be a döntésbe.
Azok az "eszmék" egészen másról szólnak, ha ezt összekevered a kezdőkhöz való viszonyával, az minimum nagy tévedés (ha nem konkrét rossz szándék).
Valószínűnek tartom, hogy te teljesen egyedül dolgozol, vagy ha nem, hát nem irigylem a kollégáidat. Csak mert számodra az egyetlen elfogadható vélemény - a sajátod. Merjen bárki mást mondani... :)
Nem reagálnék, mert csak
Köszi
Úgy általában elhiszed amit
2013, 2013
2014 (az utolsó bekezdés)
2015
Az állításod tehát nem igaz.
Ha bárkiről negatívat mondanak vagy írnak, az lejáratás, és azonnal védekezésre kényszerül, és az már rég rossz, mert a külső szemlélődő ezen állítások alapján fogja megítélni. A legszebb az egészben, hogy nem is kell megindokolni, anélkül is működik.
De nagyon jól tudod te ezt. Úgyhogy megkérlek, fejezd be!
+1
Emiatt én azt kérem, hogy
- mindhárman most fejezzük ezt be
- egyikünk se kezdjen ilyesmibe a jövőben, tartsuk tiszteletben egymás véleményét, akkor is, ha nem értünk egyet.
Köszönöm.
Lehet velem van a baj, és
Nem értem, miért akarnálak lejáratni. Miért jó az nekem?
Off
Hogy miért akarnál lejáratni? Nem tudom, nem ismerlek; szerintem egyszerűen csak irigyelsz, mert olyanra vagyok képes, amire te nem.
A részemről itt most lezártam a szálat.
"A legfontosabb vezérelv az
Ami ellehetetleníti a legfontosabb vezérelvet azt kerülni kell, nem? Legalább azt ne tagadd ami megtörtént.
Majd meglátjuk lezártad-e, én addig is lépek. Irigykedek magamban :D.
:D szerintem bamegakapa
szerintem bamegakapa tudása nagyobb spektrumot fed le, kiindulva abból, hogy ő nem elkötelezett a "natív", "teljesítményorientált" megoldások felé (legalábbis a teljesítményorientáltságot nem processzoridőben méri).
ha találtok olyan fórumtémát, ami arról szól hogy "kód futásidő optimalizálás" vagy mittudomén, ott biztos nem fogtok tőle újabb absztrakciós réteg bevezetésének szükségességéről hallani.
ellenben bamegakapát az zavarja, ha jól emlékszem, és ezzel így vagyok én is, hogy bármi legyen a kérdés, Gábor nem tud elvonatkoztatni attól, hogy a natív gyorsabb, csak ezen a szemüvegen keresztül képes válaszolni, amivel nem is lenne baj, de a végletekig indokolatlanul tolja az álláspontját, és ez torzítja a válaszok minőségét, mert az nem igaz, hogy a legfontosabb dolog az, hogy hányat röccen a processzor míg létrejön valami.
"előre optimalizálás.." mielőtt nagyon belemennénk. optimalizálsz processzorra és máshol vesztesz.
fontos ismerni persze a natív részeket, de továbblépni sem boszorkányság, sőt..
szerintem.
Amit leírsz, az
nézd, én nem téged akarlak
ha nagyon beszűkül a téma, nyitok rajta egy kicsit.
Engem nem kell meggyőznöd,
Ezzel szemben a 15-ben én két utat mutattam meg. Nem mondtam, hogy melyik a jobb, csak az egyiknél megjegyeztem, hogy gyorsabb. Ehhez te hozzátetted, hogy nem túl szerencsés a használata, amit egy teljesen jogos felvetés.
Másrészt azért nem jó a cenzúra, mert az eredeti 7-es hozzászólásomban megmutattam, natív kóddal pont ugyanannyi volt elkészíteni a feladatot. Itt sem mondtam ítéletet, nem mondtam, hogy válassza ezt, hanem az olvasóra bíztam.
Tehát hol van itt a nagyobb spektrum?
azt, hogy szerintem miért
én is volt, hogy ragaszkodtam saját keretrendszerhez, ami nem volt felesleges, mert kialakult egy stílus, amit szeretek és most ha választok egy keretrendszert, akkor már tudom, hogy mi az a felépítés ami nekem tetszik. de ettől függetlenül nem vágnék bele nélküle semmibe, hacsak nem nagyon triviális a feladat.
15-ös.. odaírtad, hogy gyorsabb, odaírtam, hogy szerintem aggályos a használata, majd odaírtad, hogy amúgy az aggályos használat amúgy nem fordul elő tapasztalataid szerint. na ennek nem volt pl semmi értelme - ez az ami ellen küzdenénk. majd példát kérsz, adunk példát. ezen felül leírom, hogy miért tartom fontosnak a rossz példák reklámozásának a mellőzését. erre odaírod, hogy köszi a kioktatást. hidd el nem akar senki sem kioktatni, ez a fórum nem rólad szól, hanem a látogatókról.
utolsó rész.
a kérdés címe: adat átadás linkből jQuery-nek
senki nem kérdezte, hogy natívan hogyan kell megoldani. jó, szíved joga odatenni, mint érdekesség, de ne a natív megoldásról, egyéb hisztiről, szóljon a bejegyzés alatti hozzászólások 75%-a, mert nem ez volt a kérdés.
tudjuk, hogy gyorsabb a natív kód, de nem számít, mert vannak más nézőpontok is.
rekesz sörben simán fogadok, hogy azon fórumtémák, ahol 40-nél több hozzászólás van, ilyen offtopikokkal van tele.
feleslegesen.
ami nem is baj, csak egy mérlegelni nem tudó kezdőt simán rossz felé vezeti. ezt elkerülendő próbálunk mindig egyensúlyba hozni a történetet, amit te személyes támadásnak veszel.
tehát szerintem ő több
Egy csomó, kezdők által
remélem tudod mi a különbség a mysql_* függvények és a jQuery használata között, miért más az egyik esetben szólni, és miért a másikban..
A jQuery használata kezd
Ezen a jogon miért ne
Mert fórumtársaid megkértek rá, hogy ne tedd. Az admin pedig még szabályt is hozott direkt a te kedvedért erre. Tökmindegy, mások mit csinálnak, majd ha belőlük is sok lesz, nekik is szólva lesz.
Ne magyarázd meg. Alternatív megoldásokat természetesen szabad ajánlani. Azt ne csináld, amit eddig csináltál. Pont.
Egyébként meg szerintem az
Ezzel szemben én ilyen esetekben el szoktam kalandozni, és kifejezetten szeretem az offtopic szálakat. Ha egy témában el kell mélyednem, jellemzően egy csomó tabot nyitok meg, mert ha egy érdekes mellékvágányt találok, azon is végigmegyek. A tudásom jó részét ilyen módon szedtem össze, és ennek köszönhetem, hogy ha felmerül valami, tudom, hova kell nyúlni.
Eleinte ez zavart, de aztán
Nem hiszem, hogy nagyobb tudásom lenne Gábornál. A "kód futásidő optimalizálás" témában hallgatnék, mint a sír, és igyekeznék tanulni.
De neki sincs akkora tudása, mint amekkora arca.
Ha tényleg okosabb, mint a Google, a Microsoft, az Apple és az Oracle mérnökei együttvéve, mint a Javás témában állítja, vajon mit keres itt, ezen a kis magyar fórumon? Miért pazarolja ránk zsenijét, mikor épp a világ szoftverpiacának megreformálásán kéne munkálkodnia? Láthatja, hogy itt termékeny talaj nem akad.
Ha tényleg okosabb, mint a
#15 Bár igazad van, utólag
Bár igazad van, utólag visszanézve nem pont ezek a cégek voltak a listában :).
Utána a 17-esben hozzá is teszed, hogy bár ezek mind nem értenek a biztonsághoz, te tudod a megoldást. Csak sajnos nem írhatsz róla, mert a sok ostoba gonosz nem engedi.
Ez nem igaz, a 15-ben én csak
Nézd, egy szurkolói
Szakmai fórumon azért ilyesmit csak akkor jelentünk ki, ha van rá bármi alapunk. Például tudjuk, mit csinálhatnának jobban. Ebből következik, hogy te jobbnak tartod magad náluk, hiszen te nem vagy fotelszurkoló, ez pedig nem egy kocsmajellegű fórum.
Tévedsz. A fenti cégeknél
Ha az általuk fejlesztett szoftvert triviális lenne biztonságosra készíteniük, akkor úgy tennének, mert pénzt lehet vele spórolni - de nem az. Magyarul az új featúrák hozzáadása egyelőre több pénzt hoz, mint biztonságos szoftvert készíteni.
Tévedsz. Pontosan melyik
Pontosan melyik mondatomra írod ezt? Melyiket cáfolod?
Zavaros nekem ez az írás. Mintha nem az enyémre válaszolna.
Az egész gondolatmeneted
Kijelented, hogy okosabbnak tartom magam a Microsoft, Oracle és társaik összes fejlesztőjénél, mivel ha azt állítom, hogy ők nem értenek a biztonsághoz, akkor arra van alapom, és tudom, mit kell jobban csinálni náluk.
Erre pedig azt válaszoltam az 57-ben, hogy nem, nem kell okosabbnak lennem náluk, ők is tisztában vannak azzal, hogy ementálit gyártanak, de jobban megéri elkészíteni valamit, és utána, a felhasználók visszajelzései alapján foltozni, mint eleve biztonságosra gyártani.
Minden hiba kijavítása pénzbe és presztízsveszteségbe kerül, ezért elemi érdekük, hogy a szoftvert hibamentesen készítsék el. Programjaikat mégis mindig foltozni kell. Ezért mondom azt, hogy biztonság terén nincsenek toppon, hisz nem tudják hibamentesen elkészíteni azokat.
Mi a csapatommal olyan
Kevésbé, mint Margaret
Bizonyos szálakat töröltem.
A korábbi 7-es számú