ugrás a tartalomhoz

adat átadás linkből jQuery-nek

unregistered · 2016. Május. 19. (Cs), 08.48
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)

<h1>Adat helye</h1>
<a href="#" data="Nagy Károly">1.</a>
<a href="#" data="Kiss Béla">2.</a>
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!
 
1

elvileg valahogy így

szabo.b.gabor · 2016. Május. 19. (Cs), 09.00
<h1>Adat helye</h1>  
<a href="#" data-nev="Nagy Károly">1.</a>  
<a href="#" data-nev="Kiss Béla">2.</a>  
$(function(){
  $('a').click(function(e){
    e.preventDefault();
    $('h1').text($(this).data('nev'));
  });
});
most így hirtelen fejből kb ennyi. lehetne rajta még optimalizálni, de nem akartam a lényegről elterelni a figyelmet.
2

Köszönöm

unregistered · 2016. Május. 19. (Cs), 16.29
Köszönöm, még próbálgatom mert valami nem világos, de előbb körbejárom a dolgot mielőtt hülyeséget kérdezek :)
3

Pepita · 2016. Május. 19. (Cs), 21.06
Ez jó megoldás, de lehet tetszőleges attribútumot is olvasni a .attr ('valami') fv el.
5

Egyszerűen?

unregistered · 2016. Május. 23. (H), 09.43
És akkor ezt csak egyszerűen <a href="#" valami="Nagy Károly"> lesz?
9

Igen, ha nem akarod a data-xxx használni

Pepita · 2016. Május. 24. (K), 07.24
$(this).atrr ('valami');
vissza adja azt, hogy "Nagy Károly"

Gábor 4. sorába teheted.

Szerk: elírtam, helyesen attr.
7

Én azért inkább javasolnám a

bamegakapa · 2016. Május. 23. (H), 23.37
Én azért inkább javasolnám a data-valami használatát, ha már a szabvány így írja elő. Persze senki sem kötelez, hogy használd a szabványt.
8

Szabvány? :)

Pepita · 2016. Május. 24. (K), 07.21
Mit ír elő?
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.
10

Embedding custom non-visible

Poetro · 2016. Május. 24. (K), 08.47
Embedding custom non-visible data with the data-* attributes, és igen, ez a W3C HTML5 specifikáció, azaz szabványos. JavaScriptben pedig a dataset tulajdonság írásával/olvasásával lehet használni.
27

+1

Pepita · 2016. Május. 25. (Sze), 19.17
Köszönöm, tanultam. :)
11

Ajánlás

Hidvégi Gábor · 2016. Május. 24. (K), 09.35
A lényege az, hogy mivel a HTML fejlesztése még nem zárult le, elvileg bármilyen nevű új attribútum belekerülhet. Ha te korábban használtál valami saját megnevezésűt, és ugyanolyan néven bekerül a szabványba egy, de más jelentéssel, akkor a kettő között ütközés lesz, ezt elkerülendő találták ki a data-*-ot.
12

Poetro már belinkelte a

bamegakapa · 2016. Május. 24. (K), 10.10
Poetro már belinkelte a lényeget a HTML szabványt illetően.

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:

The .data() method allows us to attach data of any type to DOM elements in a way that is safe from circular references and therefore from memory leaks.


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ó.
4

Pár kérdés

unregistered · 2016. Május. 23. (H), 09.42
Először is köszönöm, minden szépen szuperál, több adattal is, de pár kérdésre nem találtam a választ:

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!
6

Lefut a hívás attól még, kell

bamegakapa · 2016. Május. 23. (H), 12.14
Lefut a hívás attól még, kell a preventDefault. Az aktuális URL-be be is kerül a #, ha addig nem volt ott. Én ilyen esetekben inkább button elemet szoktam használni (megfelelően stílusolva), mert a link alapvetően nem erre való.

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.
13

ahogy a többiek is mondják az

szabo.b.gabor · 2016. Május. 24. (K), 10.16
ahogy a többiek is mondják az 'a' tag tényleg nem a legideálisabb, akkor helyes a használata, ha új ablakban megnyitva is működik, legalábbis én így szoktam eldönteni, hogy lehet-e hivatkozás vagy sem.

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..
14

A spantól óva intenék, mert

bamegakapa · 2016. Május. 24. (K), 12.06
A spantól óva intenék, mert az ember hajlamos lefelejteni róla olyan funkciókat, amiket egy erre kitalált elem natívan hoz. Ezért javaslom a button elemet. Ha tabbal ugrálsz az elemek között, nem fog kimaradni belőle, mint a span (mert a tabindexet el fogod felejteni beállítani). A screen reader tudni fogja, hogy ez egy gomb, a spanról nem (mert a rolet el fogod felejteni beállítani). És így tovább.

Ez alapján a spannál még a link is jobb megoldás, szerintem.
17

éreztem én, hogy sántít a

szabo.b.gabor · 2016. Május. 25. (Sze), 08.43
éreztem én, hogy sántít a dolog :D
15

Bonyolult

Hidvégi Gábor · 2016. Május. 24. (K), 14.58
Egy kicsit jobban kifejtem, hogyan működik a dolog.

Amikor egy <a> elemen kattintunk, az alapértelmezett viselkedése az, hogy a href 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ény false értékkel tér vissza, akkor a böngésző nem nyitja meg a href attribútumban lévő linket, ha nem false, akkor viszont igen.
<a href="valami" id="link">Link</a>
<script>
document.getElementById('link').onclick = function klikk() {
  //valamit művelünk
  return false;
}
</script>
2, A link 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 objektum preventDefault() függvényét.
<a href="valami" id="link">Link</a>
<script>
document.getElementById('link').onclick = function klikk(esemeny) {
  esemeny.preventDefault();
  //valamit művelünk
}
</script>
Ekkor nem szükséges false-szal visszatérni, mivel a böngésző már nem veszi figyelembe az onclick 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).
18

a return false nem biztos,

szabo.b.gabor · 2016. Május. 25. (Sze), 08.50
20

Nem jobb

Hidvégi Gábor · 2016. Május. 25. (Sze), 09.48
Csak annyit írtam, hogy gyorsabb. Viszont ha úgy van, ahogy írják, azaz a 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, addEventListenert használva a csatolt eseménykezelőben nem is veszi figyelembe a return false;-ot.
21

egyszer vagy kétszer lett

bamegakapa · 2016. Május. 25. (Sze), 10.04
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

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.
22

Tudsz mutatni példát?

Hidvégi Gábor · 2016. Május. 25. (Sze), 10.50
Tudsz mutatni példát?
23

Szívesen, de mire?

bamegakapa · 2016. Május. 25. (Sze), 13.40
Szívesen, de mire?
24

hogy egy elemre és/vagy

Hidvégi Gábor · 2016. Május. 25. (Sze), 14.05
hogy egy elemre és/vagy szülőjére a linkelt írásban leírt módon két eseménykezelőt tegyek
25

Elolvastam a linkelt írást,

bamegakapa · 2016. Május. 25. (Sze), 14.25
Elolvastam a linkelt írást, ott van több példa is. Ilyesmik előfordulnak és egy kezdőnek óráit viheti el, mire rájön, mi volt a gond.

Nem érzek elegendő konstruktivitást benned ahhoz, hogy energiát fektessek további példákba :).
26

Szeretném megérteni

Hidvégi Gábor · 2016. Május. 25. (Sze), 14.38
Azt én is olvastam, de kíváncsi vagyok egy működő oldalra, hogy lássak egy esetet arra, ahol ilyenre szükség van.
28

mondjuk a linkjeidet

szabo.b.gabor · 2016. Május. 26. (Cs), 08.43
mondjuk a linkjeidet "ajaxosan" akarod kezelni, ez az egyik plugined, de van egy másik ami meg épp logolná hogy mikor hova klikkeltél az oldalon.

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.)
29

Oké

Hidvégi Gábor · 2016. Május. 26. (Cs), 12.18
Köszönöm a példát és a kioktatást.
30

Nem is kell tudniuk, hogy

Hidvégi Gábor · 2016. Május. 26. (Cs), 23.52
Nem is kell tudniuk, hogy létezik onclick és társai, majd egyszer megtudják.
Továbbra sem értem, hogy miért nézed még mindig hülyének a kezdőket? Mindhárom típusú megoldással találkozhatnak a neten, és ha történetesen onclick-féle eseménykezelés van, akkor azt is tudniuk kell kezelni. Nagyon jól látszik itt, a Weblabor fórumain, hogy milyen régi forrásokból tudnak összekaparni mindenféle scripteket. Majd ha érdekli őket, utánajárnak, hogy melyik hogy működik.

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
Ha megnézed a 15-ös hozzászólásomat, ott általános működést írtam. Ráadásul a return false mindhárom esetben (onclick, addEventListener és jQuery) másképp működik.

Miért veszed el tőlük a választás jogát, hogy mit tudhatnak meg és mit nem?
31

Továbbra sem értem, hogy

bamegakapa · 2016. Május. 27. (P), 01.11
Továbbra sem értem, hogy miért nézed még mindig hülyének a kezdőket?

Kezdőnek nézem őket, mivel azok.

Mindhárom típusú megoldással találkozhatnak a neten, és ha történetesen onclick-féle eseménykezelés van, akkor azt is tudniuk kell kezelni.

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 :).

Miért veszed el tőlük a választás jogát, hogy mit tudhatnak meg és mit nem?

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.
32

ha az én segítségemet kérik,

Hidvégi Gábor · 2016. Május. 27. (P), 14.12
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
Értem, ez is egy módszer, és tiszteletben tartom.

Egy kezdőnek úgy segítesz, ha megmutatod neki, merre menjen.
Mivel nem ismerem sem a jelenlegi, sem a jövőbeli igényeit, én ennél jóval liberálisabb és rugalmasabb álláspontot képviselek. Megmutatom neki, hogy milyen utak léteznek, és ő majd eldönti, hogy melyiket választja. Honnan tudjam, hogy neki mire van szüksége? Mi van, ha neki számít az a pár ezredmásodperc? Egyre jobban fizetnek azok a melók, amikben régi rendszereket kell toldozgatni-foltozgatni, mert újat kifejleszteni nem éri meg, hisz egyébként jól működik - én is már vettem részt ilyenben jópárszor. Mi van, ha valaki ebbe az irányba megy el?

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.
Nem szoktam kiröhögni senkit, főleg nem kezdőket, úgyhogy ezt nem értem, és semmi másra nem jó ez a kijelentésed, csak lejáratásra. Ádám ész nélkül cenzúráz, de ilyenekért, pedig nem először csinálod, még sosem figyelmeztetett.

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.
Én nem tudom megítélni, hogy ki mit szeretne. És ha egy számára fontos algoritmus van azon az oldalon? Csak azért zárja be, mert onclick van rajta? Én legalábbis ilyet sosem tanácsolnék senkinek. Majd az illető eldönti, hogy használható-e számára az információ vagy sem.

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.
33

Megmutatom neki, hogy milyen

bamegakapa · 2016. Május. 28. (Szo), 00.41
Megmutatom neki, hogy milyen utak léteznek, és ő majd eldönti, hogy melyiket választja.

Ú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.
34

na persze

Pepita · 2016. Május. 28. (Szo), 06.57
A kezdőnek épp az a baja, hogy nem tudja mi kell neki.
Nekem meg az a bajom, hogy te minden ember esetében (nem csak kezdő!) "tudod", hogy mi az egyetlen, kizárólagosan általad kijelölt járható út a számára. Ez nem csak hatalmas tévedés, hanem rendkívül riasztó is a legtöbb esetben.

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... :)
35

Nem reagálnék, mert csak

bamegakapa · 2016. Május. 28. (Szo), 09.35
Nem reagálnék, mert csak felbosszantalak. Nem áll szándékomban vagdalkozni.
38

Köszi

Pepita · 2016. Május. 28. (Szo), 20.32
Ezt Köszönöm, l. lentebb.
36

Úgy általában elhiszed amit

Hidvégi Gábor · 2016. Május. 28. (Szo), 18.15
Úgy általában elhiszed amit írsz? Te egy út mellett szoktál kampányolni. Tűzzel vassal.
Látom, a te memóriád is szelektív:

2013, 2013
2014 (az utolsó bekezdés)
2015

Az állításod tehát nem igaz.

Amúgy hagyjál ezzel a lejáratós hülyeséggel már békén :)
Nem hagylak.

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!
37

+1

Pepita · 2016. Május. 28. (Szo), 18.46
Kettőtök (Illetve most hármunk) vitája viszont már-már az összes (web) fejlesztő negatív megítélését "szolgálja", aki most ide tévedő kezdő, az csak azt látja, hogy mennyire képesek egymást nyírni.
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.
39

Lehet velem van a baj, és

bamegakapa · 2016. Május. 28. (Szo), 22.21
Lehet velem van a baj, és amúgy is csak a két utolsó linket néztem meg, de én ott azt láttam, hogy procedurális tutifasza, funkcionális nem rossz (de azért elég "vad dolog"), az OOP-t meg messziről kerülni kell. Ha én nem tudok szöveget értelmezni, az a jobbik eset. Ha te vagy ennyire elfogult a saját írásaiddal, akkor asszem ideje lemondanom rólad.

Nem értem, miért akarnálak lejáratni. Miért jó az nekem?
40

Off

Hidvégi Gábor · 2016. Május. 28. (Szo), 22.54
Igen, veled van a baj, a szövegértési képességed nulla, méghozzá duplán. Nemhogy egy szóval sem írtam, hogy az OOP-t messziről kerülni kell, mégcsak nem is az eredeti felvetésre válaszoltál (amiben többszörösen megcáfoltam az állításod, hogy szerintem csak egy út létezik).

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.
41

"A legfontosabb vezérelv az

bamegakapa · 2016. Május. 28. (Szo), 23.08
"A legfontosabb vezérelv az egyszerűségre való törekvés, ami OOP esetén sajnos kizárt a fentebb említett ceremóniák miatt."
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.
42

:D szerintem bamegakapa

szabo.b.gabor · 2016. Május. 30. (H), 08.39
:D

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.
43

Amit leírsz, az

Hidvégi Gábor · 2016. Május. 30. (H), 09.23
Amit leírsz, az ellentmondásos és zavaros.
47

nézd, én nem téged akarlak

szabo.b.gabor · 2016. Május. 30. (H), 10.53
nézd, én nem téged akarlak meggyőzni, a saját szemszögödből tök igazad van. próbálok úgy hozzáadni a fórum tartalmához, hogy az ide látogató akár kezdő júzer könnyebben tudjon mérlegelni, dönteni.

ha nagyon beszűkül a téma, nyitok rajta egy kicsit.
49

Engem nem kell meggyőznöd,

Hidvégi Gábor · 2016. Május. 30. (H), 11.26
Engem nem kell meggyőznöd, csak amit leírtál, az szerintem nem tiszta. De akkor kifejtem:

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é
Hogyan fedhet le valami nagyobb spektrumot, amikor bevallottan ("Egy kezdőnek úgy segítesz, ha megmutatod neki, merre menjen. (...) Megtudhatnak bármit, de ha az én segítségemet kérik, akkor én megmutatom a rövidebb utat.") egy utat mutat meg? Minél nagyobb ez?

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?

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
Ezt a mondatot nem igazán értem.
50

azt, hogy szerintem miért

szabo.b.gabor · 2016. Május. 30. (H), 11.57
azt, hogy szerintem miért nagyobb a spektrum (nem a tudás :D) azt leírtam. azt egy szóval sem mondtam, hogy ezt be is mutatja, ő azt írja le, ami szerinte jó. tehát szerintem ő több mindenből tud választani, több mindent használ / használt aktívan, mert nem zárkózott el eleve egy-egy technológiától néhány ms miatt. több mindenből tud választani, amikor egy valamit választ és megmutatja.

é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.
51

tehát szerintem ő több

Hidvégi Gábor · 2016. Május. 30. (H), 12.43
tehát szerintem ő több mindenből tud választani, több mindent használ / használt aktívan, mert nem zárkózott el eleve egy-egy technológiától néhány ms miatt
Pár fórumszálban leírtam már, hogy használtam én is jQueryt, sőt, Angulart is, React-et is stb.. Mi alapján állapítottad meg a spektrum nagyságát?

senki nem kérdezte, hogy natívan hogyan kell megoldani. jó, szíved joga odatenni, mint érdekesség
Egy csomó, kezdők által indított fórumtémában van valami php kérdés, és hasonló módon a kollegák mindjárt szólnak, mert az illető mysql_ függvényeket használt. Ezen a jogon miért ne hívhatnám fel a figyelmet én is alternatív megoldási módokra?

egy mérlegelni nem tudó kezdőt simán rossz felé vezeti
Miért? Ebben nem hiszek, de ezt már kifejtettem korábban.
53

Egy csomó, kezdők által

szabo.b.gabor · 2016. Május. 30. (H), 13.07
Egy csomó, kezdők által indított fórumtémában van valami php kérdés, és hasonló módon a kollegák mindjárt szólnak, mert az illető mysql_ függvényeket használt. Ezen a jogon miért ne hívhatnám fel a figyelmet én is alternatív megoldási módokra?


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..
56

A jQuery használata kezd

Hidvégi Gábor · 2016. Május. 30. (H), 13.27
A jQuery használata kezd okafogyottá válni a CSS és a JS API-k, valamint a böngészők fejlődése miatt.
54

Ezen a jogon miért ne

bamegakapa · 2016. Május. 30. (H), 13.11
Ezen a jogon miért ne hívhatnám fel a figyelmet én is alternatív megoldási módokra?

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.
55

Egyébként meg szerintem az

Hidvégi Gábor · 2016. Május. 30. (H), 13.11
Egyébként meg szerintem az van, hogy mindenki magából indul ki. Ti például valószínűleg, ha egy megoldandó problémával találkoztok, száz százalékban arra szoktatok koncentrálni.

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.
44

Eleinte ez zavart, de aztán

bamegakapa · 2016. Május. 30. (H), 09.56
Eleinte ez zavart, de aztán már az, hogy Gábor magasról tesz arra, a közösség mit kér tőle. És ez szerintem sokkal nagyobb probléma.

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.
45

Ha tényleg okosabb, mint a

Hidvégi Gábor · 2016. Május. 30. (H), 10.17
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
Hol állítottam én ilyet?
46

#15 Bár igazad van, utólag

bamegakapa · 2016. Május. 30. (H), 10.22
#15

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.
48

Ez nem igaz, a 15-ben én csak

Hidvégi Gábor · 2016. Május. 30. (H), 11.09
Ez nem igaz, a 15-ben én csak annyit állítottam, hogy a fent sorolt cégek nem értenek a biztonsághoz. Blaze a 16-ban leírta, hogy a szoftvereik nem biztonságosak, mert komplexek (amit a 17-ben megerősítettem) és fejlesztésük közben tökéletlen megoldásokat készítenek. Érthet-e a biztonsághoz az, aki nem tud biztonságos szoftvert készíteni? Biztonságos-e egy szoftver, amit folyamatosan foltozni kell?
52

Nézd, egy szurkolói

bamegakapa · 2016. Május. 30. (H), 12.47
Nézd, egy szurkolói focifórumon elmegy az, hogy Kovács József fotelszurkoló kijelenti, hogy José Mourinho futballedző nem ért a futballhoz.

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.
57

Tévedsz. A fenti cégeknél

Hidvégi Gábor · 2016. Május. 30. (H), 19.17
Tévedsz. A fenti cégeknél pontosan tisztában vannak azzal, hogy túlságosan összetett szoftvereket készítenek, és hogy ez rengeteg problémát okoz - ehhez nem kell túl sok ész. Csak amíg nem lesz belőle nagyobb botrány, a szükséges minimális erőforrást fogják áldozni ennek ellensúlyozására.

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.
58

Tévedsz. Pontosan melyik

bamegakapa · 2016. Május. 30. (H), 19.34
Tévedsz.

Pontosan melyik mondatomra írod ezt? Melyiket cáfolod?

Zavaros nekem ez az írás. Mintha nem az enyémre válaszolna.
59

Az egész gondolatmeneted

Hidvégi Gábor · 2016. Május. 31. (K), 00.22
Az egész gondolatmeneted téves.

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.
60

Mi a csapatommal olyan

BlaZe · 2016. Május. 31. (K), 07.43
Mi a csapatommal olyan területen dolgozunk, ahol kritikus tud lenni minden hiba, ennek megfelelően iszonyú időt fordítunk tesztelésre. Az ügyfelünk is tisztában van ezzel, ezért költ is erre, nem keveset. Rengeteg automata tesztünk van, minden release-nél komplex end-to-end, rollback, compatibility, performance stb teszteket futtatunk le, manuálisan is sokat tesztelünk. A prod supporttól kaptunk olyan visszajelzést, hogy a legstabilabb rendszer vagyunk, pedig nem 2 rendszert felügyelnek. Halasztottunk már releaset azért, mert még tesztelni kellett, és a stabilitás fontosabb, mint az új feature. Biztos hihetetlennek tűnik, de ennek ellenére vannak prod issuek. Ezek szerint nem értünk hozzá? :)
61

Kevésbé, mint Margaret

Hidvégi Gábor · 2016. Május. 31. (K), 09.32
Kevésbé, mint Margaret Hamilton : )
16

Bizonyos szálakat töröltem.

Joó Ádám · 2016. Május. 25. (Sze), 00.29
Bizonyos szálakat töröltem. Elnézést azoktól, akik időt áldoztak a hozzászólásra.
19

A korábbi 7-es számú

Hidvégi Gábor · 2016. Május. 25. (Sze), 09.10
A korábbi 7-es számú hozzászólást miért törölted, amiben leírtam egy teljes megoldást?