Új hozzászólás Aktív témák
-
#2919
Sk8erPeter
nagyúr
Muton
#2918
Sk8erPeter
nagyúr
Ez fura, úgy látszik, MERŐBEN MÁS Google-találataink vannak, kipróbáltam azt a keresőstringet, hogy "set tab order in a form", és már az első találat megmondta a választ.
Na jó, nem köcsögösködöm, de őszintén szólva eszembe nem jutott volna, hogy a tabindex újdonság a jQuery topicban. 
Sk8erPeter
-
#2939
Sk8erPeter
nagyúr
spammer
#2938
Sk8erPeter
nagyúr
válasz
spammer
#2938
üzenetére
Pl. Chrome extensionnél meghatározhatod, mikor kerüljön injektálásra a JS-fájl, lásd a run_at részt:
https://developer.chrome.com/extensions/content_scripts"In the case of "document_start", the files are injected after any files from css, but before any other DOM is constructed or any other script is run.
In the case of "document_end", the files are injected immediately after the DOM is complete, but before subresources like images and frames have loaded.
In the case of "document_idle", the browser chooses a time to inject scripts between "document_end" and immediately after the window.onload event fires. The exact moment of injection depends on how complex the document is and how long it is taking to load, and is optimized for page load speed.
Note: With "document_idle", content scripts may not necessarily receive the window.onload event, because they may run after it has already fired. In most cases, listening for the onload event is unnecessary for content scripts running at "document_idle" because they are guaranteed to run after the DOM is complete. If your script definitely needs to run after window.onload, you can check if onload has already fired by using the document.readyState property."
De neked a css lesz az érdekes, beszúrhatsz saját CSS-t, így pl. adott elemre vonatkozó display:none-t:
css:
Optional. The list of CSS files to be injected into matching pages. These are injected in the order they appear in this array, before any DOM is constructed or displayed for the page.Sk8erPeter
-
#2942
Sk8erPeter
nagyúr
spammer
#2940
Sk8erPeter
nagyúr
válasz
spammer
#2940
üzenetére
Mivel újból és újból felülírod a textarea tartalmát, ezért a kiválasztáshoz szükséges is, hogy újból lefusson a selectTextareaLine() függvény. De miért zavar az téged?
Most akkor melyiket szeretnéd, hogy ténylegesen az összes tartalomból a 4. sor legyen kiválasztva, vagy mindig az újabb beszúrt szöveg 4. sora?
Sk8erPeter
-
#2945
Sk8erPeter
nagyúr
spammer
#2943
Sk8erPeter
nagyúr
válasz
spammer
#2943
üzenetére
"(A lefutás megakadályozásához meg gondolom számolni kellene a klikkeket, mármint, hogy első volt-e vagy nem, de ilyennel meg aztán tényleg felesleges lenne pöcsölni.)"
Nem erről beszéltem. Azt megoldani, hogy ne fusson le még egyszer a kiválasztásért felelős függvény, a létező legegyszerűbb probléma. De onnantól kezdve, hogy a következő menetben felülírod a tartalmát a textarea-nak, NEM lesz kiválasztva az általad kívánt sor, mivel elvesztetted a felülírással az előző kijelölést! Vágod? Itt van egy szemléltető példa, egyszerűen bevezettem egy isFirstInsertion változót, és na bumm, nem fut le többször, de aztán nem is működik: http://jsfiddle.net/56HNA/1/
Szóval ennek a beillesztések utáni újból és újból történő lefutását nem fogod tudni megúszni, de nem is kell!"A jobb megoldás a mindig beszúrt rész 4. sora lenne persze, ha nem kell tökölni vele sokat, mert egyáltalán nem életbevágó dolog, inkább csak úgy kíváncsiság, hogy ebből megoldható-e relatíve egyszerűen.
"
Megoldható Ennyiből:
http://jsfiddle.net/56HNA/2/Sk8erPeter
-
#2947
Sk8erPeter
nagyúr
spammer
#2946
Sk8erPeter
nagyúr
válasz
spammer
#2946
üzenetére
Nincs mit!
Na várjál, itt mindegyik megoldásban egyelőre a "line4->selected" sor teljesen be van drótozva, bármit változik a szöveg, természetesen az indexek "elromlanak", ezt csak szövegkereséssel lehet megkerülni! Igazából nem tudom, mi a végcélod.
Az viszont semmiképp sem jó megközelítés, hogy csak elsőre fusson le a szövegkiválasztós módszer, mert akkor a többi beillesztésnél nem lesz kijelölve semmi."Viszont ez után már nem működik a gomb, tehát a blablabla után nem szúrja be újra a sorokat."
Na most őszintén szólva nem fogtam fel ezt a példát, ezt körül tudnád írni picit jobban, mi nem működik?
(#2944) Jim-Y:
Én itt erre a feladatra kicsit overkillnek érzem a sessionStorage használatát.[ Szerkesztve ]
Sk8erPeter
-
#2949
Sk8erPeter
nagyúr
Jim-Y
#2948
-
#2951
Sk8erPeter
nagyúr
spammer
#2950
Sk8erPeter
nagyúr
válasz
spammer
#2950
üzenetére
Mindez azért van, mert korábban szar kódot mutattam.
Őszintén szólva csak összecsaptam a korábbit. Ezenkívül az .append() metódust használtam, mert hirtelen nem ugrott be, hogy ez textarea esetén nem jó, mert szerkesztés után nem fogja hozzáfűzni az értéket:
http://stackoverflow.com/questions/4722914/jquery-append-not-appending-to-textarea-after-text-edited/4723017#4723017Na, egy szó, mint száz, javítottam
Csekkold plíz, hogy ez így jó-e (nem teszteltem agyon, ezt is gyorsan pötyögtem össze, de kicsit jobban odafigyelve, első próbálgatások alapján működik, meg beleraktam minimális hibaellenőrzést):
http://jsfiddle.net/56HNA/4/Még azt javítani kellene, hogy ne legyen keveredés plain JS és jQuery közt, mert az nem olyan szép, de ehhez most nem nagyon volt kedvem.
Ja, még annyi, hogy a numberOfLineToSelectFromTextToInsert jelöli azt a számú sort, amelyiket ki kellene jelölni a beillesztendő szövegből (a hosszú változónévből kiderül), tehát még ez is be van drótozva ilyen módon, hogy épp hanyadik sort kell kijelölni, de ezt ennek alapján már könnyű átdolgozni úgy, hogy akár szöveges alapú keresést végezz, hogy milyen stringet keresel - és azt a sort jelölje ki, amelyikben az a string megtalálható. Ha esetleg ilyenre lenne szükséged még pluszban.
Kérdezz, ha valami nem tiszta a kódból.[ Szerkesztve ]
Sk8erPeter
-
#2963
Sk8erPeter
nagyúr
Zedz
#2956
Sk8erPeter
nagyúr
"Esetemben van 4 kép, és én csak az elsőre szeretném rárakni."
Lehetőségek tárháza:
1. http://api.jquery.com/first-selector/
$(".banner img:first").addClass("kiskutya");
2. http://api.jquery.com/first/
$(".banner img").first().addClass("kiskutya");
$(".banner img").eq(0).addClass("kiskutya");
4. http://api.jquery.com/eq-selector/
$(".banner img:eq(0)").addClass("kiskutya");
5. http://api.jquery.com/slice/
$(".banner img").slice(0, 1).addClass("kiskutya");
[ Szerkesztve ]
Sk8erPeter
-
#2964
Sk8erPeter
nagyúr
Sk8erPeter
#2963
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#2963
üzenetére
6. http://api.jquery.com/first-child-selector/
$(".banner img:first-child").addClass("kiskutya");
7. http://api.jquery.com/first-of-type-selector/
$(".banner img:first-of-type").addClass("kiskutya");
8. http://api.jquery.com/nth-child-selector/
$(".banner img:nth-child(1)").addClass("kiskutya");
9. http://api.jquery.com/nth-of-type-selector/
$(".banner img:nth-of-type(1)").addClass("kiskutya");
10. $($(".banner img")[0]).addClass("kiskutya");
Készítettem rá egy összehasonlító tesztet:
http://jsperf.com/jquery-first-element-test[ Szerkesztve ]
Sk8erPeter
-
#2968
Sk8erPeter
nagyúr
martonx
#2966
Sk8erPeter
nagyúr
válasz
martonx
#2966
üzenetére
Használt böngészőtől, meg az aktuális tesztelés körülményeitől is nagyban függ.
Pl. Firefox 30.0-ban a :first-of-type selector győzött. Bár bevallom, éles kódban még sosem láttam ezt a selectort, én sem használtam előtte soha, nem tudom, Te hogy vagy vele. Máskor az :nth-of-type selector nyert, na ezt sem használtam még, az :nth-childot igen, ami meg volt, hogy szintén győzött (pl. Opera 24.0.1543.0 alatt).
Ezek tipikusan azok az optimalizációk, amikkel egyszerűen tényleg nevetséges foglalkozni, mert annyira jelentéktelen a gyakorlatban a különbség, hacsak nem valami soklépéses ciklusban merül fel ilyesmi - bár akkor meg már ahogy mondtad, vanilla JavaScripttel kellene inkább szarakodni, nem jQuery-vel, és akkor nem tűnik ennyire viccesnek az optimalizálgatás.
==============================
(#2965) Zedz :
Teljesen egyetértek martonx-szel, ezek annyira nevetséges különbségek, hogy a kód olvashatósága ezerszer többet számít, mint az, hogy nyerj pár milliszekundumot (gondolom elég egyértelmű, hogy utóbbiból a felhasználó úgysem fog érzékelni semmit). Főleg, hogy ez csak bekorlátoz (pl. mit csinálsz akkor, ha legalább 3 selectorra is alkalmazni kell valamit? Akkor nem lesz jó a selector széjjeldarabolása), és kellemesebb olvasni egy egyben is működő CSS selectort, mint egy szétdaraboltat (még ha adott esetben az utóbbi teljesítményben jobb is, de mint megbeszéltük, ez a különbség elhanyagolható felhasználói szempontból).
Amíg az alapokkal nem vagy tisztában, addig meg aztán tényleg rohadtul ne a mikrooptimalizációkkal töltsd az idődet, hanem azzal, hogy megtanuld a nyelvet.Sk8erPeter
-
#2971
Sk8erPeter
nagyúr
Zedz
#2969
Sk8erPeter
nagyúr
"Amúgy mit gondoltok a javascript OOP felhasználásáról? Érdemes lenne azzal is foglalkozni, vagy annyira nincs jelentősége mint mondjuk PHP-ban?"
Szerintem a kérdés második felének nincs abszolúte semmi értelme (az elsőnek még lenne). Mégis mitől játszana már fontosabb szerepet az objektumorientáltság PHP-ben, mint JavaScriptben?
Eleve PHP esetén az 5-ös major verzióig nem beszélhettünk objektumorientáltságról. A JavaScript meg valamelyest eleve objektumorientáltan lett tervezve, még ha a klasszikus értelemben véve nem is feltétlenül OOP, de mégis valamennyire az, csak az objektumorientáltsága kicsit körülményes. Prototype kulcsszónak nézz utána.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript
Egyébként nyilván érdemes foglalkozni vele. Van jelentősége, ha szervezett kódot szeretnél. Agyonerőltetni nem kell, de hogyne lenne érdemes belemenni.(#2970) Jim-Y :
Azért gondolom csak értetted, mire utalt. Lehet írni simán functionöket mindenhova, egységes struktúra kialakítása nélkül is működőképes kódot lehet összehozni. Feladattól függ, nyilván sokszor érdemes objektumszerűségekben gondolkodni. Nem arra kérdezett rá, hogyan írja át a core-t...Sk8erPeter
-
#2976
Sk8erPeter
nagyúr
Jim-Y
#2974
Sk8erPeter
nagyúr
"A véleményem az, hogy azért látsz erről kevesebb infót, mert a PHP-t főleg szerver oldalon használják, vagy legalábbis ebben a kontextusban amiről beszélünk, a javascriptet pedig főleg kliens oldalon. Na most az olyan témakörök, mint Osztály, öröklődés leginkább az adatok/állapotok tárolásával hozhatóak összefüggésbe. Adott objektumokat írunk le egy osztállyal, és ezen onjektumokat akarjuk perzisztálni valamilyen módon. Adatokat pedig rendszerint adatbázisba mentünk, az pedig a szerver oldalra tartozik."
He?! Az objektumorientált programozási elveknek már miért a perzisztenciához lenne közvetlen köze?
Ez egy nagy baromság. Az OOP egyszerűen egy programozási módszertan, kódszervezési elv, ami közelíti a kódot valamelyest az ember objektumokban történő gondolkodásához... Önmagában abszolút semmi köze bárminek adatbázisban, fájlban vagy akármiben tárolásához... 
Magyarul az érvelés/levezetés már eleve hibás. Hogy PHP-nál több objektumorientált kódot látott, annak az lehet az oka, hogy többet foglalkozott PHP-val, vagy nagyobb problémakörök kapcsán látott kódokat, nem pedig rövid példakódokat nézegetett, vagy fingom sincs. Nyilván csomó netes egyszerű sample code nem tartalmaz komplett objektumorientált kódot. Ha megnéz bármilyen tisztességesebb library-t, plugint, akármit, akkor láthatja, hogy az alapvetően objektumorientált kódszervezés alapján készült."Kliens oldalon nem szokás adatokat tárolni. Van rá lehetőség (indexedDB, localstorage stb..) de nem jellemző."
Hát pedig sűrűn előfordul, lásd bármilyen böngésző-extension JavaScript-kódját is."Szerintem már csak ezért sem találkozni olyan sűrűn a klasszikus értelemben vett osztály fogalmával kliens oldali javascriptben."
Na hát ennek meg aztán megint csak köze nincs az előző állításhoz (még ha az előző állítás helyes is lenne, bár nem az).Amúgy a hsz.-ed végén látható felsorolásodból azt kihagytad, hogy az is kell, hogy az ember tudja használni a keresőt, tudja értelmezni a dokumentációkat (mert akkor nem akad el hülyeségeken, és valóban nem kell ismernie rogyásig egy nyelv összes dolgát - bár nyilván a tapasztalat és az adott nyelv ismerete jót tehet a gyors+minőségi kódírásban).
[ Szerkesztve ]
Sk8erPeter
-
#2980
Sk8erPeter
nagyúr
Realradical
#2979
Sk8erPeter
nagyúr
válasz
Realradical
#2979
üzenetére
Akkor végül is megoldódott? Mert ha nem, tényleg jó lenne egy jsFiddle-példa, és akkor nem nekünk kell szenvednünk vele, hogy demózás céljából összeállítsuk neked a helyes működést. Úgy magyarázatot is tudnánk fűzni hozzá, és gyorsabb lenne a közös feladatmegoldás.
Sk8erPeter
-
#2992
Sk8erPeter
nagyúr
biker
#2987
Sk8erPeter
nagyúr
Na ne.
Ez kőkemény. Ez a kód okádék, bár ettől függetlenül nem tudom, mi okozott gondot az "automatizálásán". Amúgy az ingyenes, akár alapos doksival ellátott sliderekből Dunát lehet rekeszteni (2 perc Google, és máris nem tudsz választani, hogy melyiket kéne, annyi van), biztos vagyok benne, hogy minimalisták is bőven vannak, ami picit indokolatlanná teszi az ilyesmivel való tökölést, az ilyen minőségű kódért viszont 5 korbácsütés járna, nem lóvé. 
Sk8erPeter
-
#2999
Sk8erPeter
nagyúr
biker
#2994
Sk8erPeter
nagyúr
"és sajnos annyira nem vagyok jquery imádó, hogy azt lássam, mitől hányadék a kód"
Nem értem igazán, hogy mi rajta a tudomány, ha bármilyen nyelvben szereztél már tapasztalatot, gyors átgörgetés után kapásból látható, hogy ez spagettikód. Már azokból a dolgokból is, amiket martonx előttem leírt.
Amúgy hogyhogy nálad a jQuery teljesen kimaradt? Úgy tudom, webfejlesztés a munkád.Késő van, úgyhogy nincs energiám összeszedni minden potenciális szempontot, de próbálok felsorolni pár dolgot, ami gáz a kódban így átpörgetés után:
- undorítóak a változónevek, seggbe kéne rúgni acélbetétes bakanccsal az összes olyan programozót, aki magát és másokat szopat egy-két karakteres változónevekkel. Ez három dologra utalhat, illetve azok egyvelegére: I.) szintet átlépő lustaság II.) kapkodás, III.) valami ostoba szövegszerkesztő használata
normális fejlesztőkörnyezet helyett, ami a keze alá dolgozik (és azért lusta leírni, mert nem egészíti ki neki a kódot a szerkesztő)
Könyörgöm, mi az, hogy if(n==i)?? Miért kell spórolni a karakterekkel?
- levegőben lóg az egész. Semmi egységes struktúra, itt csak eléggé egymástól függő, de "globális függvények" vannak, nincs objektum/prototípus-orientáltság vagy bármi ahhoz hasonló a kódban, egyszerűen nem tartoznak egybe a dolgok. Tartozzon egybe, legyen valami struktúra, az legyen érezhető, hogy ez egy dologhoz tartozik, nem pedig csak úgy be vannak dobálva függvények. Ha már ilyesmit készít, és jQuery, akkor ráadásul illik jQuery plugint készíteni ilyesmire. Még leírás is van róla a hivatalos oldalon:
http://learn.jquery.com/plugins/basic-plugin-creation/
- ha már az előző leírás szóba került, illik a library-nek/pluginnek a saját scope-jában tevékenykednie, nem szennyeznie a globális névteret. Bár ez még persze túlélhető.
- mivel nem az előzőek fényében lett megvalósítva, nem láncolhatók a hívások.
- egyszerűen nem lehet normálisan felparaméterezni az egészet. Nincsenek default opciók, inicializálásnál nem lehet átadni egy objektumot a felülbírálni kívánt paraméterekkel. Minden be van drótozva. Pl. idézek: w=694; //force to max size - hát miért pont 694 a max. size? Mi van, ha a megrendelő úgy dönt, hogy legyen picit átszabva itt-ott (és mondjuk még fizet is érte jó esetben)? Akkor majd lehet áttanulmányozni ennek a katyvasznak a belsejét, és kihámozni belőle valahogy a lényeget?
- ha már bedrótozás: MINDEN be van drótozva, a selectorok is. Ami nagyon gáz. Ismét előjön a szempont: mi van, ha valamiért meg akarjuk változtatni a classneveket? Tényleg át kell bogarászni az egész kódot, és mindenhol egyesével átírni? (Sajnos vannak idióta programozók, akik ezt elfogadhatónak tartják.) Ja, és mi van, ha te valamiért több slidert is el akarsz helyezni az oldalon, és az egyikre más opciókat akarsz érvényessé tenni? Erre nem válasz, hogy de úgyse akarok ilyet. (Az gondolom tiszta, hogy a beton rugalmasságával rendelkező kód mindig rossz.) Többek közt erre is való a pluginkészítés. Ha már jQuery, lehessen kihasználni annak képességeit.
- és a többi, asszem ideje aludni.
Sk8erPeter
-
#3002
Sk8erPeter
nagyúr
biker
#3000
Sk8erPeter
nagyúr
"A benne lévő dolgok, amiket írsz, teljesen érthetők, szerintem a kollégának azért sikerült így, és nekem azért nem tűnt zavarónak pl a w=694 és társai, mert egyértelműen kötött designba készítette, ahol 694px a slider box mérete."
De az ilyen szintű bedrótozást semmi nem indokolja.
Itt olyan dolgokról beszélünk, amit 5 perc többletmunkával bele lehet rakni: default opciók, és a felülbírálható opciók lehetőségének kialakítása. Ilyenekre tengernyi példakód található neten, például a korábban linkelt tutorialban egy egész konkrét és egyszerű példa van:"Accepting Options
As your plugins get more and more complex, it's a good idea to make your plugin customizable by accepting options. The easiest way to do this, especially if there are lots of options, is with an object literal. Let's change our greenify plugin to accept some options.(function ( $ ) {
$.fn.greenify = function( options ) {
// This is the easiest way to have default options.
var settings = $.extend({
// These are the defaults.
color: "#556b2f",
backgroundColor: "white"
}, options );
// Greenify the collection based on the settings variable.
return this.css({
color: settings.color,
backgroundColor: settings.backgroundColor
});
};
}( jQuery ));Example usage:
$( "div" ).greenify({
color: "orange"
});The default value for color of #556b2f gets overridden by $.extend() to be orange."
vagy akár bele lehet nézni a jQuery source code-jába, stb.
"Nem ez a főállásom, és nem is "weblapos" vagyok, aki egész nap weblapokat gyárt "húszezeré' megcsinálom" verzióban. Az csak a nagyon uborkaszezonban, de akkor is inkább készen megveszem 50USD-ért themeforesten.
Én egyedi alkalmazásokat fejlesztek inkább weben használható kivitelben, hogy a T. usernek ne legyen gépfüggősége. beléptető/tagnyilvántartó rendszer, crm rendszer, most épp egy szexhirdetős oldalt annak minden szépségével és gondjával,vés hasonlók. De ezeknél a legkevesebb a kinézet, a csicsa, az adattartalom a lényeg..."
Ez a "húszezeré megcsinálom" példa nem értem, hogy jött ide, az egyedi webalkalmazások fejlesztése meg aztán végképp nem értem, miért is zárná ki a JavaScript+jQuery-tudást. Éppen ellenkezőleg. Amit itt írtál, ott is "mezei" weblapokról beszélsz, mintha a kliensoldali kódolás valami vérpistis dolog lenne - pedig egyedi webalkalmazásokhoz, akár üzleti szektorban is NAGYON erősen kellhet a kliensoldali programozás, így a jQuery is. Manapság pont minden arrafelé halad, hogy a kliensoldali rész is faszán el legyen készítve, AJAX-os kérések történjenek a háttérben, és így tovább, és az, aki ezeknek a fejlesztését végzi, pont nem jó, ha egy vérpisti, ehhez is szakmai tudás kell. Hogy jön ide a csicsa? Nem kell összekeverni a JavaScript-programozást a dizájnerkedéssel, meg a sitebuilddel, van ilyen része is, meg van más része is.
Amúgy azt magyarázd már el nekem plíz, hogy mit jelent az, hogy "az adattartalom a lényeg"? Ezt próbáltam értelmezni, de valahogy nem sikerült. Sk8erPeter
-
#3014
Sk8erPeter
nagyúr
biker
#3010
Sk8erPeter
nagyúr
Karma igen jól és tömören összefoglalta a lényeget, ami miatt finoman szólva nehezen elfogadható ez a megoldás.
De a kód több sebből is vérzik, ezt mindjárt.Egyébként a PHP-kód vonatkozó részénél, amikor macskakaparásos idézőjelet kell használnod egy stringben, szerintem nyugodtan kihasználhatnád, hogy a stringeket aposztróffal is írhatod, és úgy nincs változó-behelyettesítés sem, így nem kell escape-elni az idézőjelet sem, tehát:
$termek_jq.="\"".$query_tomb['termek_ean']."\" : \"".$query_tomb['termek_nev'].": ".$query_tomb['termek_ar']."Ft / db \" , ";
HELYETT lehetne ez is:
$termek_jq.= '"'. $query_tomb['termek_ean'] .'" : "'. $query_tomb['termek_nev']. ': '. $query_tomb['termek_ar']. 'Ft/db " , ';
Sztem jobban néz ki. (Például ha HTML-kódot kell neadjisten generálni, annál is az attribútumokat ugye idézőjellel szokás írni, ott is elkerülhető az állandó escape-elgetés így.)
Na de a kód tartalma már annál kevésbé néz ki jól. Erről megint mindjárt.Amúgy én PHP-kódnál és lehetőleg más nyelvekben is inkább kerülni szoktam a stringben "elrejtett" változóneveket (amik behelyettesítődnek), ezzel persze biztos vannak, akik nem értenek egyet, de engem kifejezetten zavar, ha nem látszik kapásból a kódból, hogy oda bizony egy "kívülről hozzácsapott" változó értéke kerül - még akkor is, ha az IDE highlightolja az adott stringben a megfelelő részt. Nem beszélve arról, hogy tömbindexeknél vagy objektumok attribútum/metódushívás-eléréseinél a stringben így még bűvészkedni is kell, hogy az valóban behelyettesítődjön. Bár bevallom, pl. shell scripteknél sokszor kivételt teszek.
Na, szóval a kód érdemi részére rátérve:
- Eleve rossz, hogy PHP-vel generálsz komplett JS-kódot, mert ott biztos, hogy valami koncepcionális hiba van, és lehetne sokkal általánosabban.
- Ha már ilyen megoldást választottál, és generálsz mindent, miért drótozod be az elemek számát a ciklusban? Lásd $i<16 --> miért pont 16? Miért nem egy változó van ott? Ha egyébként JS-kódbeli ciklusban szerepelne, az is rossz lenne, mert itt egy ismeretlen nagyságú valaminek a kalkulált hossza kellene, hogy szerepeljen, nem egy konkrét, bedrótozott szám. Ha valami be van drótozva, akkor ott gondolkodni kell, hogy miért is van az ott bedrótozva. Szóval most igazából elkövetted pont azt a hibát, amiről a korábbiakban beszélgettünk.
- Minden egyes termékazonosítóhoz legenerálsz egy-egy külön anonim event handlert. Minek? Meg lehetne oldani az egészet class-szal (class-okkal), és mindegyikhez egy darab általános event handler tartozhatna. A kódod semmi olyat nem tartalmaz, amit ne lehetne egy ilyen eseménykezelővel megoldani.
Meg amúgy a kimeneti, legenerált JS-kódod tele lesz var value1, var value2, ... var value15 jellegű változókkal, ami gondolom nem kell mondani, hogy igen csúf.
(Amúgy még így pluszban nem tudom, mennyire jó ötlet, hogy mindig hozzáfűzögeted a #bufe_uzenet elem tartalmához az aktuálisan becsippantott kódot. Érdekel valakit az előző akárhány becsippantott elem? Mert ha igen, akkor is talán mehetne egy kinyitható, logolós részbe, mert így ránézésre zavaró lehet, hogy nem egyértelmű, az adott pillanatban mit csippantott be valaki.)Szóval a kérdésre válaszolva ja, elég gány, bocsi.
(#3003) Karma :
"Egyvalamivel egészíteném ki. A pluginba szervezésnek lenne még egy kézzel fogható előnye is: ebben a formában csak egy slider lehet az oldalon, egy helyes megoldással meg akármennyi, függetlenül a másiktól."
Jaja, egyetértek. De igazából ez benne volt az előzőben, legalábbis erre akartam utalni azzal a résszel, hogy "mi van, ha te valamiért több slidert is el akarsz helyezni az oldalon, és az egyikre más opciókat akarsz érvényessé tenni? Erre nem válasz, hogy de úgyse akarok ilyet." Meg hogy miért is gáz, hogy a selectorok is be vannak drótozva. Persze úgy még egyértelműbb, ahogy Te írtad.[ Szerkesztve ]
Sk8erPeter
-
#3021
Sk8erPeter
nagyúr
biker
#3015
Sk8erPeter
nagyúr
"a " " jelet használni annyiból kedvezőbb nekem, hogy egy $valami behelyettesítéséhez nem kell azonnal '.$valami'. írni, mint ' ' esetén"
Ja, de sztem amúgy sem olyan jó ötlet a stringbe rakni a változót, én jobb' szeretem konkatenálni - Te is ezt tetted, szóval itt pont nem használtad ki a változó-behelyettesítést. Amúgy tömböt is lehet akár stringbe belerakni, bár sztem rettentő ocsmány:
$termek_jq.="\"{$query_tomb['termek_ean']}"\" : \"{$query_tomb['termek_nev']}: {$query_tomb['termek_ar']} Ft / db \" , ";Erre írtam a korábbit, hogy szerintem nem jó gyakorlat, de ízlések és pofonok. Meg ez talán a leglényegtelenebb rész, már eleve ott kezdődik a para, hogy PHP-vel van legenerálva a komplett JS-kód.
"Ha az ezek akármelyikébe beírt eseményt akarom figyelni, akkor kell egy onChange(#termek_ean1).... 15-ig esemény nem? Akkor 15x ki kell írni, vagy van rá jobb megoldás, hogy tudjam, a mondjuk 8-as mezőbe épp beírtak valamit, és ha igen, akkor írjunk ki valamit a lapra?"
Hogyne lenne... Igazából pontosan erről beszéltem korábban, előtte is leírtam az egyik alternatív megoldást, idézem magam:
"Meg lehetne oldani az egészet class-szal (class-okkal), és mindegyikhez egy darab általános event handler tartozhatna. A kódod semmi olyat nem tartalmaz, amit ne lehetne egy ilyen eseménykezelővel megoldani."
Tehát még egyszer: EGY darab event handlerre van szükséged, nem többre. Fúú, de jó, most látom, közben Jim-Y megmutatta, miről beszélek, így nem kell annyit hablatyolnom megint. Köszi, Jim-Y.
Amúgy vannak a HTML5-ös data-* attribútumok is, amelyek lehetővé teszik, hogy adott elemekhez egyéb információt is rögzíts, ezeket lekérni jQuery-vel nagyon egyszerű, de ez csak mellékszál volt, mint látható a példából, nincs rá szükséged."»» - Minden egyes termékazonosítóhoz legenerálsz egy-egy külön anonim event handlert. Minek?
Nem, a beviteli mezőkhöz írok ilyet, a termék azonosítók (2-300 vonalkód) a tömbben vannak, amiknek a key/value párját keresem a onChange eseményre"
DE! Akkor még egyszer elmondom: minden egyes termékazonosítóhoz legenerálsz egy-egy külön anonim event handlert. Nézd már meg a kódodat, amit belinkeltél, pontosan azt csinálod benne, amiről beszéltem.
Vágod, ott vannak azok a csúnya külön-külön kis .change( function(){ ... } ) kódocskák, azokból van jópár. Ha lenne száz terméked, akkor száz ilyet generálnál le?
Korábban erre mondtam, hogy általánosságban kell gondolkozni, úgy kell megtervezni, hogy számítasz egy rendszer bővítésére. Nem azt mondod, hogy 15 van, annyi is marad örökre, aztán ez a kód jó lesz majd vidékre.
Hozzáteszem, szerintem ez nem is tartozik a kliensoldalra, hogy az oldal HTML-kimenetébe be legyenek okádva a termékkód-termékadat párosítások."Igen, érdekli. Így kérte"
Hát jó, bár én ezt lehet, hogy egy külön dobozkába, vagy legalábbis valahogy elválasztva raknám, history-szerűen, vagy akkor már prependelném, nem appendelném, de ez aztán már abszolút más lapra tartozik."A php ciklus pont amúgy ezt generálja le"
Nem tudom, feltűnt-e, de korábban pont azt fejtegettem, milyen kód fog legenerálódni, szóval hidd el, értelmeztem a látottakat, és pontosan tudom, mi fog legenerálódni, nem túl összetett a kódrészlet, amit mutattál."Na egy ilyet hogy lehet akkor szebben, olvashatóbban megírni, azon kívül, hogy a 15 elem kérdést kirakom külön változóba, hogy átírhassam bármikor 35-re mondjuk"
Ezek szerint ez sem jött át: feltételezem, vagy adatbázisból szeded ezeket az adatokat, amiket legenerálsz, vagy beolvastad fájlból, vagy tököm tudja, mindenesetre ezeket bele tudod tömködni egy tömbbe. A tömbnek meg ugyebár van egy hossza. A tömb hosszát meg pontosan felhasználhatnád annál az ominózus ciklusnál, amennyiben a borzalmas gányolós kódnál maradunk. Akkor máris legalább egy fokkal rugalmasabb lenne a tákolmány. Mondjuk még stringbe is lehetne passzírozni ezt a generált kódot, ahogy fetch-eled adatbázisból. De inkább nem adok ötleteket további gányoláshoz.
Szóval ezeket kerüld. És akkor még egyszer: egy ciklusnál se legyen bedrótozva annak fejlécébe, hogy meddig mehet, csak kivételes esetekben, amikor garantáltan nem lesz valamiből több/kevesebb.(#3017) :
"Biztos én gondolom rosszul hogy egy adott text mezőbe bevitt adatot megkeresni id kell és nem class"
Ahogy mondod, te gondolod rosszul.
Ha rugalmas megoldást akarsz, nem id-zni kell.A jsFiddle-re felrakott kód így még durvább, mint amiről korábban beszéltünk.
A HTML-részre:
- illik az attribútumokhoz tartozó értékeket szépen idézőjelekbe rakni. Már az óvodában is így tanítják (jó lenne), nem a 90-es években vagyunk.
- Fel nem fogom, minek kreáltál annyi darab inputpárt, ahány darab terméked van.
- Lehetőleg ne használj <br />-eket a távolságtartáshoz. Szépen használj CSS-t, margint, paddinget, attól függően, mire van épp szükség. Word-dokumentumot sem úgy szerkeszt az ember normális esetben, hogy püföli az Entert, aztán valahol már kábé jó lesz. Normális dokumentum úgy van megszerkesztve, hogy rugalmasan állíthatók a térközök, egy helyen, nem ötszáz helyen. Jelen esetre értsd: ha szeretnéd kisebbre venni a távolságot, akkor normális esetben csak a CSS-kódban átírsz egy értéket, nem kell a HTML-kódhoz nyúlnod, és tippelgetned, hogy kb. hány sortörést kéne oda berakni vagy épp onnan kiszedni.
- Sajnos behánytad a HTML-kódba a JavaScript-kódokat is, inline attribútumokba, konkrétan itt számtalan onKeyPress-értékként adtad meg, mi is történjen a keypress event során. Mi van, ha szeretnéd átnevezni a függvényt? Akkor tényleg 15 helyen meg kell változtatni? Ha JS-kód írásáról van szó, akkor miért kell folyton buzerálni a HTML-kódot is? A különböző célra szolgáló nyelvek szépen legyenek elválasztva egymástól. Ez pontosan ugyanolyan ronda, mintha a CSS-kódot behánynád style-attribútumokba. Az is kerülendő, ez is. Az oka igazából ugyanaz.
A JS-kódra: - hát ezt már kielemeztük elég rendesen, hogy mitől ronda, kaptál javaslatot is a szépítésre eleget.Persze inkább kérdezz, ha még valami nem tiszta.
(#3019) :
Szerintem Jim-Y is valami olyasmi hibákra gondolt, amiket fentebb írtam."egységesen magyar"
Hát ez itt a probléma. Legyen egységesen angol. A programozás nyelve angol, akár tetszik, akár nem. Hülyén néz ki, hogy össze-vissza keverednek a nyelvek egy kódban (én már a kommentárjaimat is igyekszem angolul írni, bár ebben lehet engedményt tenni), de ha ez nem lenne elég, van olyan, aki utálja az ilyen kódot, ez csapatmunkánál nem mindegy, és ha már csapatmunka, előállhat olyan helyzet, hogy kűűűűfőőőődi embernek kellene megmutatnod a kódodat, és az meg egy büdös szót nem ért belőle. Ha utóbbi nem állhat elő, akkor se keverd a nyelveket. (Ha svédül írnád, az is hülyén nézne ki, nehogy valami turulmagyar megsértődjön, hogy a magyarral bármi baj lenne. )(#3018) Jim-Y:
Kösz, sok időt megspóroltál nekem.
Szerk.:
+#3019: 22 másodperccel megelőztél."self-closing tags"
HTML5-ben pont nem kötelező. XML-ben és XHTML-ben természetesen az.
Egyébként én is ocsmánynak tartom, ha az <img .../>, <br />, <hr /> és hasonlók nincsenek lezárva. Én személy szerint sajnálom, hogy ez pont nem kötelező az ajánlás szerint.[ Szerkesztve ]
Sk8erPeter
-
#3022
Sk8erPeter
nagyúr
Jim-Y
#3020
Sk8erPeter
nagyúr
Ezt csak most látom:
"Másrészt inline ev.handlerekkel csak egy handler-t tudsz definiálni egy eventhez"
Ez nem feltétlenül igaz, lásd ezt:
HTML:
<button id="mybutton" onclick="alert('Button has been clicked! --> UGLY inline stuff.');">Click this button</button>JS:
window.addEventListener('load', function () {
document.getElementById('mybutton').addEventListener('click', function () {
alert('Button has been clicked! --> Event handler in JS file - as you should ALWAYS do it.');
}, false);
});--> http://jsfiddle.net/4SeM5/
Mindkettő lefut, csak előbb az ocsmány inline-kód, majd a külön JS-kódban definiált fut le.
Abban az esetben viszont igaz, ha JS-kódban van mondjuk két külön window.onload = function(){...}, akkor az első felülbírálódik.
Sk8erPeter
-
#3030
Sk8erPeter
nagyúr
Speeedfire
#3009
Sk8erPeter
nagyúr
válasz
Speeedfire
#3009
üzenetére
Több információ kéne. Azt írtad, "Azt hittem az apache lehet a ludas, de minden kérésnél ott van, hogy pending." Hol van, hogy pending? Hol nézed? Webfejlesztő panelban, vagy csak a UI-on?
Mit csinál az előző hsz.-edben írt ModalDialog()? Nem azt csinálja, hogy blokkolja a UI-t, pont, mint a BlockUI?, amitől valójában elvileg mehetne több AJAX-kérés is a háttérben, csak a UI nem használható, hogy a felhasználó ne tudjon ide-oda kattintgatni?
Webfejlesztő eszközből derült ki, hogy "nem tudok egyszerre több ajax kérést intézni a szerver felé"? Hogyan vizsgálódtál?
Ezeket magunktól sajnos tényleg nem tudjuk kitalálni.
Sk8erPeter
-
#3038
Sk8erPeter
nagyúr
Zedz
#3035
Sk8erPeter
nagyúr
Ha már egy-egy változóban eltároltad azokat a jQuery-objektumokat, amikre szeretnél valamilyen event handlert kötni (ahogy esetedben), vagy egyéb műveleteket végezni, használd a jQuery .add() metódusát:
http://jsfiddle.net/8kcz885o/Sk8erPeter
-
#3049
Sk8erPeter
nagyúr
martonx
#3047
Sk8erPeter
nagyúr
válasz
martonx
#3047
üzenetére
Ez ilyen majdnem "Infinite Scroll", ha jól értem, azzal a különbséggel, hogy itt nem ugyanannak a tartalomtípusnak a végtelen betöltése történne, hanem az oldal különböző szakaszait töltenéd be scrollozástól függő módon - szerintem erre a jQuery Waypoints talán jó lehet, két use case:
http://imakewebthings.com/jquery-waypoints/shortcuts/infinite-scroll/
http://imakewebthings.com/jquery-waypoints/examples/scroll-analytics/
Bevallom, még a gyakorlatban nem használtam kipróbáláson kívül, de sok helyen láttam már linkelve, meg ez elég normálisnak tűnik API és doksi szempontjából is.
(A kód fent van GitHubon.)Sk8erPeter
-
#3055
Sk8erPeter
nagyúr
Speeedfire
#3054
Sk8erPeter
nagyúr
válasz
Speeedfire
#3054
üzenetére
Bár a központi téma szempontjából nem releváns, jelen esetben a .text() metódushívás jobb lehet, mint a .html(), mert utóbbinál egy esetedben tök felesleges (textarea-ba raksz be sima szöveges tartalmat) reguláris kifejezéssel történő cserét is lefuttat(na, ha lenne illeszkedés, de az illeszkedést ugye vizsgálni kell): http://james.padolsey.com/jquery/#v=2.0.3&fn=jQuery.fn.html
ezzel szemben:
http://james.padolsey.com/jquery/#v=2.0.3&fn=jQuery.fn.text
http://james.padolsey.com/jquery/#v=2.0.3&fn=jQuery.textNéha érdemes lehet ilyen különbségeket is figyelembe venni (még ha eleve jQuery használatánál nem is divat sajnos az erőforrásbeli különbségekre figyelni).
Sk8erPeter
-
#3057
Sk8erPeter
nagyúr
Speeedfire
#3056
Sk8erPeter
nagyúr
válasz
Speeedfire
#3056
üzenetére
"Nem úgy van, hogy a simpla tag-ekhez (pl: input), attributumokhoz van a text és a dupla elemekhez(p,div stb) pedig a html?"
Attribútumokhoz? Azokhoz biztos nem, arra az .attr() való. Amúgy meg nincs ilyen jellegű szabály, amire utalsz, a .text() egyszerűen szöveges tartalmat szúr be, a .html() pedig HTML-t - értelemszerűen. Próbáld ki például ezt: $('p').text('<strong>blablabla</strong>'); Magát a teljes szöveget fogod látni a bekezdés(ek)ben, nem kerül átalakításra a "blablabla" szöveg kiemelt szöveggé (értsd: látni fogod a <strong> taget).Visszatérve a textarea vs. .text()-re: ez vicces, mielőtt írtam volna, direkt kipróbáltam, és működik textarea-hoz a .text() metódus, ennek ellenére a doksi ezt írja:
"The .text() method cannot be used on form inputs or scripts. To set or get the text value of input or textarea elements, use the .val() method. To get the value of a script element, use the .html() method."
Szóval elvileg a .val() segítségével történő beállítás a helyes textarea-hoz is. Mondjuk lehet, hogy úgy érti, hogy a .text() nem használható pl. textarea-hoz, hogy bizonyos böngészőkben nem működik... Ezt azért odaírhatták volna.
Mindenesetre a .text() textareánál működik FF 32.0.3-ban, IE11-ben, Chrome 38.0.2125.101 m alatt, szóval az aktuális böngészők mindegyikében...Na mindegy, a lényeg, hogy végül is az eredeti állítás stimmel, hogy a .html() metódust nem érdemes használni textarea-ra, arra inkább a .val() való (bár a .text() is jó a gyakorlatban
).[ Szerkesztve ]
Sk8erPeter
-
#3059
Sk8erPeter
nagyúr
Speeedfire
#3058
Sk8erPeter
nagyúr
-
#3067
Sk8erPeter
nagyúr
Zedz
#3063
Sk8erPeter
nagyúr
-
#3072
Sk8erPeter
nagyúr
Zedz
#3068
Sk8erPeter
nagyúr
A felesleges overhead elkerülése miatt MINDEN programozási nyelvre igaz, hogy érdemes az egyes függvény-/metódushívások visszatérési értékeit eltárolni egy változóba, ha az adott kódrészlet(ek) végrehajtása során azokra többször van szükség - persze a változásokat (ha a függvény/metódus időközben más eredményt adna vissza) frissíteni kell. Arra azért figyelni kell, hogy ne menjen át gányolásba, tehát pl. ne érje el mindenki a változót, akinek nincs is rá szüksége, ne szemeteld vele a globális scope-ot, ha ez elkerülhető (van, amikor nem elkerülhető, de azért legtöbbször valami "burkolás" megoldható), stb.
Sk8erPeter
-
#3081
Sk8erPeter
nagyúr
Des1gnR
#3080
Sk8erPeter
nagyúr
válasz
Des1gnR
#3080
üzenetére
"Wordpress-be megy, így ez kiesett."
Ez hülyeség, WordPress esetén is lehet feltételtől függővé tenni egy script hozzáadását, 5 másodperc guglizással rengeteg találatot kaptam, pölö:
http://wordpress.stackexchange.com/questions/67802/most-efficient-way-to-add-javascript-file-to-specific-post-and-or-pages
(BTW fogalmam sincs, hogy ez-e a jó módszer, ami itt az elfogadott válasz, nem ismerem a WordPress számomra - Drupallal szemben a WordPress csupán nagyon felületes ismerete alapján - kicsit sivár lelkivilágát.)(#3079) martonx:
Csak kiegészítés/pontosítás akart lenni, hogy ne magára a window.location objektum egyezőségére akarjon keresni. Mert akkor a window.location.toString()-metódus által visszaadott értékre fog egyezőséget vizsgálni, az meg a window.location.href értékével ekvivalens, abban meg benne van a teljes URL (konkrét protokollal, hostname-mel, stb.), és azt melósabb egyeztetni, mint a sima window.location.pathname-et. Igazából ezt nem neked magyarázom, mert Te ezt pontosan vágod, csak hátha hasznos a kérdezőnek is. Sk8erPeter
-
#3092
Sk8erPeter
nagyúr
TomyLeeBoy
#3091
Sk8erPeter
nagyúr
válasz
TomyLeeBoy
#3091
üzenetére
Hogyan oldottad meg?
Amúgy korábban használtam a Chosent, és volt egy ilyen jellegű para (egy overlay-en használt, Chosennel átalakított listánál nem látszott rendesen a felugró lista), csak már olyan rég volt, hogy nem emlékszem, mi volt a megoldás.Sk8erPeter
-
#3099
Sk8erPeter
nagyúr
Speeedfire
#3098
Sk8erPeter
nagyúr
válasz
Speeedfire
#3098
üzenetére
Annak az oldalnak a címét, ahova a felhasználó épp navigálni készül, tudtommal nem tudod kideríteni kliensoldali kóddal ilyen módon, ha belegondolsz, komoly biztonsági kockázat lenne, túl sok személyes információ is kikerülhetne (például ha a saját oldaladról elnavigál a YouP×rnra, azt nem biztos, hogy a felhasználó akarja, hogy tudd
).
Tehát az egyetlen működő megközelítés, ha saját oldalon belüli linkekről/kiválasztható elemekről/... van szó, hogy az azokra való kattintás/kiválasztás/... eseményt figyeled. Ha mondjuk a felhasználó egy böngészőbe elmentett könyvjelzőre kattintva navigál oda, vagy konkrétan bepötyögi a címsorba a célURL-t (ami nem kizárt), akkor persze nem fogod megtudni, hogy saját oldalon belülre navigált, úgy, hogy akár előtte is saját oldal valamelyik menüpontjában volt (ilyenkor elvileg a referer sem tartalmazza, hiszen nem oldalon belüli hivatkozásra kattintva jutott el a másik oldalra).Sk8erPeter
-
#3102
Sk8erPeter
nagyúr
Speeedfire
#3100
Sk8erPeter
nagyúr
válasz
Speeedfire
#3100
üzenetére
"Azért nem teljesen így van, mert a fenti kódrészbe a var url-hez ezt beilleszted, akkor van amikor feldobja a következő oldal címét. Viszont nem jöttem rá, hogy mi alapján. [...]
e.target.activeElement.href"
Na ne már. Ez nyilvánvalóan akkor fog létezni, amikor a felhasználó egy linkre kattintott. Nem egy nagy mágia megfejteni, például a href-ből már lehet következtetni... 
Szóval de, teljesen úgy van, ahogy írtam. Ha nem linkre kattint, vagy nem valamelyik oldalon belüli elem kiválasztásával/kijelölésével/kattintásával/... kerül másik oldalra, hanem úgy hagyja el az oldalt, hogy mondjuk bepötyögi a címsorba a kívánt URL-t (vagy mondjuk rákattint valamelyik elmentett könyvjelzőre), akkor nem fogod tudni kideríteni, hogy hova is akar távozni.Ha csak a linkek céljára való kattintást kell figyelni, akkor az elég egyszerű. Vagy úgy, hogy készítesz egy event handlert, vagy például külső URL-ek esetén azt a megoldást választod, amit dqdb az előbb leírt.
Sk8erPeter
-
#3107
Sk8erPeter
nagyúr
PumpkinSeed
#3105
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#3105
üzenetére
Ez a kód erősen túl van bonyolítva!
Na meg a szerkezete sem jó: a bezáróikon logikailag és látvány szempontjából is az oldalsávhoz tartozik, együtt kell mozogniuk, éppen ezért érdemes strukturálisan is ennek megfelelően rendezni a kódot. Legyen egy közös ősük, és a bezáróikon ehhez képest legyen relatíve igazítva - ezzel azt tudod elérni, hogy a bezáróikon együtt mozog az oldalsávval, nem pedig külön-külön kell toszigálni a bezáróikont is, hogy kövesse az oldalsávot a mozgás során.
Ezt épp ezért átrendeztem a kódodban, hierarchikusan a toggle icon is a #menu alá került, a #menu kapott egy position:absolute-ot, a .menu_icon (a bezáró-kinyitó ikon) szintén kapott; a #menu ezenkívül némi CSS3 transition segítségével kerül mozgatásra, úgy, hogy a célállapotban (ahol nyitott állapotban van) a left tulajdonságot 0-ra állítom (bezárt állapotban pedig ez visszakerül az eredeti -250px-re). A JavaScript-kódban pedig simán csak az .open osztályt adom hozzá, illetve veszem le róla, ettől történik meg az átmenet.http://jsfiddle.net/gd6qqtnh/1/
Ha pedig régebbi böngészők támogatására is szükség van, és ezeknél is mindenképp szeretnél animációt (de tényleg csak akkor!), akkor azt javaslom, hogy Modernizr segítségével ellenőrizd a transition támogatottságát, majd jQuery UI segítségével animáld a left property-t: http://jqueryui.com/animate/
if(!Modernizr.csstransitions) { // Test if CSS transitions are supported
// http://jqueryui.com/animate/
// ...
}Sk8erPeter
-
#3110
Sk8erPeter
nagyúr
PumpkinSeed
#3109
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#3109
üzenetére
"a click event handlerének mire szolgál az e paramétere?"
Az maga az event. e helyett természetesen lehetne a neve kiskutya is, a lényeg, hogy ez az objektum tartalmazza a kattintás esemény összes, böngésző által beállított tulajdonságát, a rajta hívható metódusokat, stb. Így működik az összes eseménykezelő: paraméterként mindig megkapod az esemény objektumot, akármilyen eseményt figyelsz is.
Ettől még sok kódban előfordul, hogy a JavaScript adottságai miatt lehagyják ezt a paramétert (mert JavaScriptben ezt meg lehet tenni, hogy nem írod ki), nem foglalkoznak vele, mert pl. az adott kód kontextusában épp nincs szükség rá (lásd az általam linkelt kódban is a $(document).ready(function(){...})-t! - itt lehetett volna az anonim eseménykezelő function(event) is, így az event változóban lenne az esemény) - de ettől még átpasszolódik, még ha le is hagyod (pl. az arguments objektum az adott függvény/metódus kontextusában tartalmazza a kapott argumentumokat).Érdemes kiírnod konzolra console.log() segítségével az eseményt, és megnézegetni, mi van benne (vagy ami ennél sokkal jobb, tisztességes debuggerrel egy tisztességes IDE-ben (vagy akár a böngésző debuggerében) vizsgáld meg a tartalmát), mert szükséged lesz még rá. Pl. az ilyenekre, mint az event.target, event.currentTarget, event.preventDefault(), event.stopPropagation(), stb...
Ha még nem tiszta a dolog, kérdezz nyugodtan.
Sk8erPeter
-
#3120
Sk8erPeter
nagyúr
Speeedfire
#3114
Sk8erPeter
nagyúr
válasz
Speeedfire
#3114
üzenetére
"Kicsit kesze megoldás, de raktam egy trigger-t a val() után."
Szerintem semmi gond nincs ezzel, hogy ilyen esetben manuálisan váltod ki az eseményt, sokkal értelmesebb megoldás, mint időzítve figyelgetni az inputmező értékének változásait, az ilyen időzítős megoldás mindig megbízhatatlan (eleve kitalálni, hogy mennyi is legyen ez az érték, és miért pont annyi), plusz még folyamatosan erőforrást is igényel.
Tehát az általad alkalmazott megoldás a programmatikus beszúrások detektáltatására teljesen jó.Sk8erPeter
-
#3123
Sk8erPeter
nagyúr
adam_
#3122
Sk8erPeter
nagyúr
Most nem azé', de ennek a problémának túl sok köze nincs hozzá, hogy ez Drupal vagy valami totál más, szóval azért, mert nem működik, ne a Drupalt okold, hanem magadat.
Ezer éve nem Drupaloztam, de egyből lejön, hogy ennek a kódnak totál semmi köze a Drupal-konvenciókhoz. Most gyorsan rágugliztam, itt van összefoglalva szerintem elég jól, példákkal illusztrálva, hosszas kommentekkel ellátva:
https://gist.github.com/gregnostic/3cc18f91aa152c05b47c
A lényeg az anonymous closure vagy IIFE, amivel nem szennyezed a globális névteret, másrészt ami igen fontos, abszolút figyelmen kívül hagyod a module patternt. Ezzel kapcsolatban az előbbi GitHubos linken a Drupal.behaviors.myBehaviorName részt nézd meg. Ahogy az egész Drupal, ugyanúgy a kliensoldali kód is moduláris felépítésű. Fontos koncepció, hogy kivehető/berakható elemekből álljon össze az egész, mint egy lego (ez a lényege a moduloknak).
Egyébként érdemes kiindulni egy normálisan elkészített, nem összetákolt theme-ből, és ahhoz, hogy ezt úgy tudd módosítani, hogy az alapvető keretet ne kelljen bántani, érdemes leszármaztatni egy saját subtheme-et.Az alapproblémád meg teljesen egyértelműen látszik már a screenshotból is, hogy még csak nem is kötődik a JavaScript-kódhoz, mert valami pozicionálási vagy z-indexszel vagy hasonlóval van gond: pont azzal kapcsolatos, amire panaszkodsz, hogy rálóg a felirat a bejelentkező űrlapodra. A screenshotodon a "website" felirat rálóg a Password mezőre, nem csoda, hogy nem lehet belekattintani, valószínűleg valamilyen módon a "háttérbe" szorult. Ezt amúgy szerintem a Firefox 3D nézetével elég jól lehetne szemléltetni, kár, hogy a többi böngésző webfejlesztő paneljeiben ez a feature nincs meg.
Az éles kódodban is így el vannak cseszerintve a lezárások? Mert már itt sincsenek helyesen lezárva az elemek, fel vannak cserélve, pl. a "login-content" id-vel ellátott div lezására szerintem elcsúszott, a <li> elem nincs lezárva (bár a <li>-é opcionális elméletileg, asszem HTML5-ben is). Ezt első körben javítani kéne, másra most már nincs agyam.Sk8erPeter
-
#3128
Sk8erPeter
nagyúr
adam_
#3124
Sk8erPeter
nagyúr
Hát ja, akár frameworkről, akár CMS-ről van szó, bizonyos szabályokat követni kell, hogy a dolgaid az elvártaknak megfelelően működjenek. Úgyhogy nem úszod meg a dokumentáció olvasgatását, különben csak gányolás lesz belőle.
A jQuery-kódod kerete már illeszkedik a Drupal behaviors-koncepcióba, de ettől még pazarolsz vele, feleslegesen erőforrás-igényes:
- az eseménykezelődben minden egyes alkalommal kikotrod a kódból a #login-content azonosítójú elemet, ahelyett, hogy eltárolnád egy változóba, úgy, hogy egyetlen egyszer kikeresed, átadod a változónak az értéket, majd onnantól kezdve azt használnád
csak egy példa, a tiédbe nyilván picit másképp kell átültetni, máshol kell tárolni a változót, nem az eseménykezelőn belül, de a lényeget érted:
var $loginContent = null;
// eseménykezelőn belül:
if($loginContent === null){
$loginContent = $('#login-content');
}
$loginContent.slideToggle();
// ...
A dollárjel használata nálam konvenció, azért szoktam alkalmazni, hogy tudjam, hogy ott egy jQuery objectről van szó.- teljesen felesleges "kör" a $(this).next('#login-content'), hiszen adott azonosítójú elemből egyetlen egynek szabad csak lennie egy oldalon, tehát ez esetben simán rövidíthető lenne $('#login-content')-re, és kész. Az ilyen next-es megoldás csak egyéb selectorok használata esetén érdekes, id-nél sosem.
- ahogy Jim-Y írta, a this használata félreértésekhez vezethet, ezért érdemes az eseménykezelőnél odatenni az eseményt jelző változót, esetedben:
$('#login-trigger').click(function(e){
// ...
});
az e változó az érdekes, ez lehetne bővebben event, vagy kiskutyafule, vagy akármi, a lényeg, hogy ez jelzi az átpasszolt esemény-objektumot. Innentől kezdve pedig lehet játszani az e.target, e.currentTarget és társaival.
Vagy ha a $(this)-t érthetőbbnek találod, akkor legalább az eseménykezelőd elején add át egy változónak, és onnantól kezdve azt használd:
var $self = $(this);
$self.toggleClass('active');
...
így biztosan egyértelmű, hogy a $(this) épp mire is vonatkozik.- ha már erről volt szó, az is már önmagában nagyon durván erőforrás-pazarló, hogy minden alkalommal használod a $(this)-t. Gondolj bele: ilyenkor minden alkalommal a this-t átpasszolod egy függvénynek, és azzal valamit kezdenie kell belül. Így ha debuggerrel futtatnád a kódodat, és végigmennél rajta, láthatnád, hogy teljesen értelmetlenül minden egyes alkalommal, amikor ezt leírod, beleugrik az adott függvénybe, és ott csinál vele valamit (itt épp a this-ből lesz egy jQuery-objektum). Ehelyett egyszerűen még az eseménykezelő legelején eltárolhatnád a függvény visszatérési értékét egy változóban (ld. előbbi példakódom), és onnantól kezdve azt a változót használnád. Ezzel jelentős erőforrás-spórolást érsz el.
- ahogy azt DNReNTi említette is, a nyílcserélős megoldásod szintén nagyon pazarló. Elegendő lenne megoldani CSS-ből, hiszen gondolj bele, az elemedhez eleve hozzáadod például az "active" osztályt, így ebből máris lehet egy selectort készíteni a CSS-kódodban, pont úgy, ahogy DNReNTi mutatta. Nem beszélve arról, hogy itt is elköveted azt a hibát, hogy egy egyedi azonosítóval ellátott elemet használsz selectorként, mégis keresztülküldöd egy find()-on is, ami megint csak plusz erőforrást igényel.
Aztán mivel még a $(this)-t is használod (ld. előbbi pontban leírtak), a .hasClass()-t, meg meg a .html() metódust is, ezért sikerült a lehető legerőforrás-igényesebb módon megoldani ezt az amúgy nagyon egyszerű kis problémát. Az ilyenekre a tiszta kód, kisebb erőforrás-használat miatt érdemes NAGYON odafigyelni MINDIG, és akkor már eleve így fogod leírni a kódot, nem lesz az, hogy "jó, majd később megoldom valahogy" - nagy eséllyel nem fogod megoldani valahogy. Elfelejted, más épp a prioritás, lusta vagy hozzá, elfogadod, hogy van egy ilyen a kódodban, és legyintesz rá, mert sokkal fontosabb dolgok kerültek előtérbe, aztán benne marad örökre.
Vagy ha épp van egy kis időd, és van egy hirtelen kattanásod, akkor van esély rá, hogy kijavítod, de amúgy nem nagyon.Sk8erPeter
-
#3130
Sk8erPeter
nagyúr
Jim-Y
#3129
Sk8erPeter
nagyúr
Egyetértek a kiegészítésekkel, főleg a kapcsos zárójelek hiányára vonatkozó tanáccsal.
Rengeteg amúgy elég jó fejlesztő is lehagyja, mert számára úgy a jobb, pedig szerintem rondábbá is teszi a kódot (nem látszik olyan szépen, hogy az adott sor mihez tartozik, még ha be is van húzva a kód, ahogy illik, számomra hiányzik az összetartozás ennyire explicit jelzése), ezenkívül jó nagy szopások kellemes kis forrása lehet, amikor várnád, hogy valami egy feltételtől függően működjön, de nem csak attól függően teszi, vagy ha épp nem is tart erre olyan sokáig rájönni (mert homlokára csap a fejlesztő, hogy ja, odatette azt a plusz sort, de nem használt korábban kapcsos zárójelet), jó eséllyel kell futni plusz egy/két/három/stb. kört tök feleslegesen. A legjobb, ha az IDE úgy van beállítva, hogy ilyenért azonnal pampog.Sk8erPeter
-
#3140
Sk8erPeter
nagyúr
adam_
#3138
Sk8erPeter
nagyúr
Az a jó, hogy ebben a kódodban pontosan ugyanazokat a hibákat követed el, amiket részletesen kifejtettem/kifejtettünk korábban.
.delegate()?? jQuery 1.7 óta, tehát már elég régen felváltotta az .on(). Használd azt."Legvégső soron tisztázásképpen mi így oldottuk meg, mindennemű Drupálos nyalánkság nélkül, ezzel is szépen megy"
Igen, megy, de az a Drupalos "nyalánkság" (fúj de ronda szó ez) pár karakterrel lett volna több, cserébe sokkal szebb és bővíthető, illeszkedik a koncepcióba. Ami működik, az még nem biztos, hogy jó is. A többit nem olvastam el, mert láttam, hogy megoldottad azóta.
Sk8erPeter
-
#3149
Sk8erPeter
nagyúr
adam_
#3143
Sk8erPeter
nagyúr
A Drupal 7-esnél a jQuery Update modul olyan szinten alap, hogy fel sem merült bennem, hogy nincs fent nálad.
Igen, a 7-es kiadásakor még korábbi jQuery-verziók voltak aktuálisak, ezért ezzel a modullal kell frissíteni, a core-t azért nem változtatták ilyen szempontból, hogy ne legyen kötelező a frissítés, ami esetleg pont kompatibilitási okok miatt (hogy például bizonyos dolgokat kidobáltak az újabb jQuery-kből) eltörheti bizonyos modulok működését (amelyek nem lettek egy ideje update-elve, és akkor jönnének a "nem működik, mé'"-jellegű bejelentések gondolom).A másik kérdést most nincs időm megnézni, majd máskó'.
[ Szerkesztve ]
Sk8erPeter
-
#3152
Sk8erPeter
nagyúr
adam_
#3148
Sk8erPeter
nagyúr
Értem, hogy mit szeretnél, de mégis mi a búbánat értelme van eltüntetni a menü ikonját? Tényleg egyáltalán nem értem, miért zavar bárkit is, hogy ott van az a három csíkkal ellátott kis ikon. Sőt, szerintem kifejezetten béna, hogy eltűnik. Ráadásul még arra sem teremtesz lehetőséget, hogy bezárhassa a júzer magát az előugró login-felületet - pedig legalább a bezárás-ikonra kattintva pl. elő lehetne ismét hívni az amúgy tök értelmetlenül elrejtett menüikont. A képeden legalábbis a login-űrlapnál nem látszik semmiféle bezáróikon, ha a felhasználó meggondolná magát, és mégsem akarna bejelentkezni, VAGY például tök véletlenül kattintott oda. Vegyük utóbbi esetet - szerinted a júzer örülne neki, ha véletlenül kattintott volna, és erre eltűnne a menüpontokat előhívó ikon? Csak anyázna, hogy miért kellett ezt így megcsinálni, mi értelme, hogy a navigációt lehetetlenné teszed, ha rányomott a loginra. Szóval ez user experience szempontjából katasztrófa.
Ebből a példakódodból meg nehéz kiindulni, a későbbiből meg végképp, mert a valós példától eléggé eltér. Mindenesetre először közös nevezőre kell jutni, hogy érthető legyen, miért is van szükség ezekre az eltüntetgetésekre, és pontosan hogyan is képzeled, mert jelenleg ez felesleges körök futásának tűnik, amit aztán később úgyis megváltoztatsz, mert rájössz, hogy ez úgy szar, ahogy van.
A JS-kód kapcsán meg tényleg nem értem, ennyire hatástalanok voltak a múltkori tanácsok azzal kapcsolatban, hogy mondjuk egy-egy elemet tárolj már el változóban, ne keresgéld ki a DOM-ból minden alkalommal, ne legyen kódismétlés, ne keveredjen a JS-kóddal bármilyen CSS-kód, aztán amit lehet, CSS(3) segítségével intézz el, és így tovább?[ Szerkesztve ]
Sk8erPeter
-
#3154
Sk8erPeter
nagyúr
adam_
#3153
Sk8erPeter
nagyúr
Hát ha csinálsz valami értelmes demót (az előbbi dobozos nem csinál semmit, meg elavult a kód, meg nincs sok köze a valós példához, nekem meg nincs kedvem működésre bírni), akkor segítünk. Amúgy a feladatnak tényleg SEMMI értelme nincsen. Én mondjuk biztos ezt megemlíteném annak, aki kérte, hogy a júzerrel b@sznak csak ki, de hát evvan.
Amúgy szerintem Te nem tudod, mit jelent az, hogy "etc.". (csak akkor minek használod ) Következetesen rosszul használod a mondataidban: "akkor toggle()-lal, etc. ki/be lehessen nyitogatni, "viszont ha újból rákattintok a box1-re, etc becsukom a toggle()-al akkor újból jelenítse meg mellette a box2-t", "akkor a box2a maroon színű div kerüljön bele. Etc, a menüből lehessen bejelentkezni.", "jelen esetben 640px (etc 40em) alatt"... Sk8erPeter
-
#3164
Sk8erPeter
nagyúr
adam_
#3155
Sk8erPeter
nagyúr
"Kollégám szerint egye
nlőre felesleges frissíteni Drupal alatt a JQuery-t, mert az on() felhasználásán kívül jelenleg nem nyerünk vele sokat.."
Az igen... és ő egyáltalán webfejlesztő? Remélem, veled nem sikerült ezt elhitetnie.
Csupán például nem egy ősrégi elavult jQuery-t használnátok, így az újabb jQuery-k valamelyikének előnyeit ki tudnátok használni, tudnátok olyan modulokat használni, amik az újabb jQuery-ket igénylik (vannak olyan modulok/sminkek, amik ezt kifejezetten megkövetelik), tudtok több jQuery-változatból is választani a modul beállításai között, soroljam még? A kollégádnak tehát egy kissé inkompetens véleményt sikerült megfogalmaznia.A többit akkor most átugrom, mert azóta elég sok hsz.-ed volt, úgy tűnik, továbbjutottál a dologban.
(#3161):
"[link] Elvileg elkészült, ilyet szerettem volna elérni."
Ebben a példában rohadt zavaró, hogy ha előhozom a menüt, akkor ugyanoda újbóli kattintásra nem tűnik el, hanem kötelező valami elemet választanom, különben nem hajlandó eltűnni. Vagy a zöld hátterű divre kell kattintanom, ekkor viszont a bejelentkező űrlap ugrik elő, pedig én nem ezt akartam. Ha ez tényleg ilyen a végleges felületen is, számítsatok rá, hogy anyázni fognak a felhasználóitok.
Aztán ha rákattintok a Login menüpontra, az előugró űrlapot továbbra sem tudom semmivel sem bezárni. Csak akkor, ha rákattintok a menüt előhozó lenyílóra, akkor hirtelen eltűnik az űrlap, de akkor meg nem értem, mi a frászért teszi ezt, mert ugye nem kéne, senki nem kérte, hogy tűnjön el.Lehet, hogy közben ezekre rájöttél, annyit írtál, hogy már kicsit elvesztem az információtengerben, meg hogy most hol is tartasz, de majd biztos megírod.
Ilyenek miatt amúgy nem értem, miért nem használtok egy jó kiindulási alapot, valami olyasmit, mint a Bootstrap (Drupal-smink is van hozzá), aztán erre ráépítve szépíthetnétek és testreszabhatnátok a felületet. Ja, de várj, az nem fog menni, hiszen a kollégád szerint FELESLEGES a frissebb jQuery...![;]](//cdn.rios.hu/dl/s/v1.gif)
Haha.Sk8erPeter
-
#3167
Sk8erPeter
nagyúr
adam_
#3165
Sk8erPeter
nagyúr
"kollégám szerint nem lehet Bootstrapet használni, mert alapból Foundationnal dolgozunk Drupal alatt"
Hát nyilván ne legyen mindkettő, ez tök érthető, vagy egyik vagy másik.
De ezek szerint ott van a Foundation! Akkor mi a frászért nem használjátok? Tényleg nem értem:
http://foundation.zurb.com/docs/components/topbar.html
Még modális ablakokra is van lehetőség a Foundationnel:
http://foundation.zurb.com/docs/components/reveal.html
Ebben pedig szépen meg tudnátok jeleníteni a login-űrlapot.
Ha meg ez nem jön be, akkor jelenítsétek meg máshol... de ne úgy, hogy kitakarja a menü..."Abból viszont nem tetszik neki a beépített nav funkció"
És mi nem tetszik rajta neki?
Ez amúgy azért elég vicces, ehelyett elkezdtetek vadul tákolni, hogy azért mégis csak pótoljátok valahogy. De nem működik, ezért aztán megéri ezen napokat tökölni, ahelyett, hogy ízlésetek szerint ÁTSZABNÁTOK az alapértelmezett megjelenést, ahogy az erre építő theme-ek/template-ek is teszik.... De most tényleg, basszus, egy mobile-first frontend frameworköt használtok, és most komolyan azon tököltök már nem tudom, mióta, hogy hogyan csináljátok meg a top navigation bart, és hogy hogyan kéne vaklahogy azt összetákolni, hogy tényleg reszponzív legyen a dolog? Akkor miért nem kukázzátok ilyen alapon az egész frontend frameworköt, ha épp azt az előnyét nem használjátok ki, ami rengeteg időt megspórol nektek? Konkrétan többek közt ilyen feladatok megvalósítására való, épp ezt a melót spórolja meg a fejlesztőknek. Ne csináljátok már...
Valószínűleg már réges-régen kész lennétek az egésszel, ha a kollégádnak nem lennének ilyen rettentően kompetens meglátásai.A (#3166)-ban feltett kérdésedre meg azért nem tudok válaszolni, mert nekem káoszos ebben a formában, hogy itt-ott beégeted a kódba egy-egy style-attribútumban, hogy display:none;, máshol beégeted, hogy display:block;, és ha előhívom a fejlesztői panelt, akkor egyes elemeknél össze-vissza lesznek ezek (pl. a Login menüpont kapott egy display:none-t, mikor a többiek nem, ennek sincs semmi értelme) ahelyett, hogy ezekre is osztályokat használnál, pl. a .hidden vonatkozhatna azokra az elemekre, amiket elrejtettél, és így tovább... Szóval most azt éreztem, hogy túl sok időbe kerülne kibogozni. Nem véletlen az a szabály, hogy kódokat nem kutyulunk. Így "nyers" HTML-kódba nem sűrítünk bele CSS-kódot style-attribútumok formájában, JavaScript-kódot sem erőszakolunk bele onclick és egyéb ehhez hasonló attribútumok formájában, ugyanígy JavaScript-kódba nem erőszakolunk bele CSS-kódot (csak ha nagyon muszáj), legfeljebb osztályokat, amiket váltogatunk, és így tovább.
Egyébként ne em-egységeket írogassatok, tök felesleges, hanem nyugodtan használjátok a pixelt:
http://stackoverflow.com/questions/11799236/should-i-use-px-or-rem-value-units-in-my-css/11803273#11803273Ezenkívül <br />-t se használj, egy tisztességesen megszerkesztett Word-dokumentumban sem Entereket püffölünk a térköz beállításához (a <br />-ek használata pedig pontosan ugyanilyen).
[ Szerkesztve ]
Sk8erPeter
-
#3176
Sk8erPeter
nagyúr
martonx
#3175
Sk8erPeter
nagyúr
válasz
martonx
#3175
üzenetére
Elvileg a return false; miatt erre nem lenne szükség, mivel ez jQuery event handlernél olyan, mint meghívni az event.preventDefault ÉS event.stopPropagation metódusokat. ([link]) Persze bajt nem okoz, ha explicite is kiírod.
De nem innen ered a problémája.(#3174) estro:
Nem ártana a selectort kissé specifikusabbra állítani, mivel így MINDEN linkre ráaggasztod az eseménykezelőt, ami nemcsak felesleges, de káros is. A kódod ennyi alapján jónak tűnik, de ennyi infóból lehetetlen megmondani, mégis miért nem működik, a többi kódodat nem látjuk.
Egyébként igen, baj, ha nem változik az URL, erre is lehet JavaScriptet használni, nézd meg a History API-t.Sk8erPeter
-
#3178
Sk8erPeter
nagyúr
estro
#3177
Sk8erPeter
nagyúr
Mi van a success.jsp-ben, meg a 3.jsp-ben? Nehéz ennyiből mit mondani. Először hozz létre akár simán egy szöveges fájlt, amibe beleraksz valami hablaty szöveget, előbb töltse be annak a tartalmát AJAX-szal a linkre kattintás után, ha ez működik, csak azután rakd mögé az üzleti logikát. Ja, és amúgy ne rakd bele mindegyik response-ba a jQuery kódját is.
Szóval először próbáld leszűkíteni a problémát, és persze nézd a böngésző fejlesztőpaneljén (Ctrl+Shift+I), hogy mi történik.Sk8erPeter
-
#3180
Sk8erPeter
nagyúr
estro
#3179
Sk8erPeter
nagyúr
Na, most, hogy picit részletesebben írtál a problémáról, már legalább értem, mi a baj.
Tehát ezek szerint alapvetően annyiból jól működik a scripted, hogy a form elküldése után betöltődik AJAX-szal a tartalom, de a gond az, hogy mindig ugyanaz az oldal töltődik be, nem teljesül az elvárt feltételed, esetedben mindig a 3.jsp töltődik be. Teljesen jogosan sosem fog teljesülni az if(userID.equals(user)) feltétel, hiszen nem is adod át az űrlapban lévő userName nevű mező értékét a scriptnek, nincs ellátva ilyen query stringgel a lekért URL, tehát a request.getParameter("userName") mindig null-lal fog visszatérni. Szóval akkor a szerveroldal sehonnan nem tudhatja, hogy Te mit is akartál.
Ez esetben két dolgot tudsz tenni: vagy hozzáfűzöd "kézzel" a .load() metódusnak átpasszolt URL-hez a userName query stringet, DE EZT NE (inkább felejtsd el, csak azért említettem, hogy értsd, hogy úgy egyébként működne), sokkal inkább NE a .load() függvényt használd, hanem az .ajax()-ot (vagy valamelyik shorthand-társát).Tehát
$( "#target").submit(function( event ) {
var page = $(this).attr('action');
$('#content').load(page);
event.preventDefault();
});HELYETT
var $contentContainer = $('#content');
$("#target").submit(function( event ) {
var $form = $(this);
var formActionUrl = $form.attr('action');
var userNameInput = $form.find('input[name="userName"]').val();
$.ajax({
method: "GET",
url: formActionUrl,
data: { userName: userNameInput },
success: function(data, textStatus, jqXHR) {
$contentContainer.html(data);
},
error: function(jqXHR, textStatus, errorThrown) {
// TODO: értelmesebb hibakezelés
alert('There was an error when processing the request...');
}
});
event.preventDefault();
});Elgépelés lehet benne, most ezt csak ide pötyörésztem be.
Elvileg így mennie kell.Sk8erPeter
Na jó, nem köcsögösködöm, de őszintén szólva eszembe nem jutott volna, hogy a tabindex újdonság a jQuery topicban. 
A sessionStorage ugyanígy overkill, mert felesleges a session erejéig (fül/böngésző bezárásáig) tárolni ezeket az adatokat...
Ez egy nagy baromság. Az OOP egyszerűen egy programozási módszertan, kódszervezési elv, ami közelíti a kódot valamelyest az ember objektumokban történő gondolkodásához... Önmagában abszolút semmi köze bárminek adatbázisban, fájlban vagy akármiben tárolásához... 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
És mi nem tetszik rajta neki? 
Új hozzászólás Aktív témák
- Dell Latitude 7490,14",FHD,i5-8350U,16GB DDR4,256GB SSD,WIN10,TOUCH
- HP EliteBook 645 G10 (817M3EA) - ÚJ 14" üzleti notebook - Ryzen 5 PRO, W11 pro, WWAN
- 3 db ICERIVER KAS KS0 PRO
- DOBOZOS MSI Raider GE76: i7 12700H,32GB DDR5,1TB,17.3" QHD 240Hz 400nit 100%sRGB,RTX 3070Ti 8GB 150W
- Asus Tuf Dash 15 i7 11370H/16Gb/512Gb/RTX3060
- Apple Earpods fülhallgató, USB-C - Lightning kábel egyben elvihető
- We R Memory Keepers - Crop-A-Dile Corner Chomper sarokkerekítő
- iPhone 11 64Gb 83% akku, kartyafuggetlen
- Egyben eladó rendszerhűtő ventilátorok / együtt 3500! / 120-140 mm / NZXT, Akasa, Cooltek, Be quiet!
- Samsung Galaxy A20e mobiltelefon eladó
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Promenade Publishing House Kft.
Város: Budapest