- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- LordOLOG Szféra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- GoodSpeed: Bye PET Palack, hello SodaStream
- sziku69: Szólánc.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- bambano: Bambanő háza tája
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
#39560925 #3199 üzenetére
Igen, ugyanezt egész pontosan értettem az előbb is, és erre válaszoltam. Még mindig nem tudom, miért olyan meglepő, hogy így működik (hogy meghívódik a függvény ott helyben abban a formában, ahogy át akarod adni a paramétert), ha már más programozási nyelvekben is mozogsz, és nem most kezdted.
Meglehet a véleményed a JavaScriptről, de ez nem JavaScript-szintű probléma, hanem alapvető programozási ismeret.
Félre ne értsd, semmi gond nem lenne azzal, hogy elsőre nem tiszta, hogy így nem működik, amit szeretnél, csak furcsán jön ki picit, hogy a nyelvet kezded el fikázni egy olyanért, ami speciel pont nem sorolható a nyelv hibái közé (pedig aztán bőven lehetne sorolni olyat, de ez nem az).
-
#39560925
törölt tag
válasz
Sk8erPeter #3198 üzenetére
Leírtam utána, hogy mit nem értettem ezen. Be akartam állítani eseménykezelőnek egy függvényt, aminek van 1 paramétere. Arról meg hogy a JS-t használják szerveroldalon, meg van a véleményem.
Egyébként igen, wis javaslata a legjobb erre.
-
Sk8erPeter
nagyúr
válasz
#39560925 #3194 üzenetére
"És 1 sz*r*s paraméter miért számít ennyit?
De utálom a frontendet."
Ennek semmi köze nincs a frontendhez, még a jQuery-hez sem (főleg, hogy ugyebár a JavaScript szerveroldali nyelv is), sőt, még a JavaScripthez sincs úgy konkrétan köze, mert ez nem csak itt működne így. Igazából ez elég alapvető dolog, nem igazán tudom, mit nem értesz ezen, ha a Java topicban elvileg ennél azért egy picit komplexebb kódokkal vagy elfoglalva.Attól még, mert akár anonim függvényt is át lehet adni paraméterként, ennek a működése nem tudom, miért meglepő.
Egyébként ha jól értem, mit szeretnél, ha nagyon akarod, .bind()-dal is meg tudod oldani, vagy ha áttekinthetőbben szeretnéd (hogy a kódra ránézve egyből tudd, mit csinálsz ott), akkor válaszd a wis által javasolt módszert.
-
wis
tag
válasz
#39560925 #3191 üzenetére
loadMovieDetails(link1)
Ezzel meghívod a loadMovieDetails függvényt a link1 paraméterrel, majd a visszatérési értéket (ami itt undefined) átadod a click eseménykezelőnek.
A másik példában ($(button).click(button_click_handler);) csak a függvény nevét adod át. Nem mindegy.
-
#39560925
törölt tag
válasz
#39560925 #3191 üzenetére
Így oldottam meg:
$(document).on('click', '.details_button', function(event) {
console.log(event.target.name);
console.log('button pressed');
});Dinamikusan hozzáadott html elementeknél így kell eseménykezelőz hozzáadni állítólag... pedig ebben a példában működik a .click() is.
Ennek majd érdekelne a magyarázata.
-
#39560925
törölt tag
Sziasztok!
Ebben, ennél a sornál:
$(detailsBtn).click(loadMovieDetails(link1));miért hívódik meg a loadMovieDetails(link1) függvény?
És a táblázatban lévő gombra kattintás után miért nem? -
dqdb
nagyúr
Ha nemcsak MIME type (vagy esetleg kiterjesztés) alapján szeretnél dolgozni, hanem az adattartalom alapján szeretnéd kitalálni a konkrét fájltípust, akkor ...
... a szerveren valami libmagic/file alapú megoldást javasolnék, ha van Node.js, akkor kevesebb, ha nincsen, akkor több meló.
... a kliensen a Sk8erPeter által is linkelt Blob és TypedArray alapú megoldásokat. Ezeket nem túl bonyolult használni, csak fognod kell egy formátumleírást a megcélzott fájltípusokhoz, és pillanatok alatt össze lehet dobni egy alapfokú ellenőrzést az első néhány byte figyelésével. Pár képformátumhoz ezt dobtam össze korábban, itt kihasználtam, hogy Blink motor a megcélzott, így büntetlenül használhatom az API-kat, más böngészőnél valószínűleg kell polyfill hozzá.
-
biker
nagyúr
válasz
Sk8erPeter #3187 üzenetére
"Hát a dqdb kolléga által bedobott lista eléggé kimerítő választ ad a kérdésedre.
"
Én is így érzem -
biker
nagyúr
Köszi mindkettőtöknek. a mime type kinyerése megvan, nekem azért kellene teljes lista, mert korábban sokat szívtam azzal, hogy egy .jpg gépre a sok oprendszer sok böngészője 3 féle módot tudott, és a userek meg szóltak, nem jó
vol image/jpeg, image/jpg, és image/pjpeg egyik esetben. rég volt, de volt.
És amint látom az alapján, aki elkezdte ezt írni, valamiért a doc/xls/ppt ellenrzésbe is betette az összes opendocument verziót is, így pl fel tudok tölteni pages filet is. nem csak docot.Nos, nem szeretném, ha mondjuk símán beírom |zip|rar|bz stb és aztán rájönni, multipart rar esetén az r01 r02 nem megy fel, és sorolhatnám.
A kapott lista alapján remélem a legtöbb verziót bele tudom tenni az ellenőrzésbe. kivéve futtatható alkalmazások -
dqdb
nagyúr
válasz
Sk8erPeter #3184 üzenetére
[link]
Ez a hivatalos változat, ami ebben nem szerepel, az kötelezően x- előtagos vendorfüggő típus.biker: csak olyan van, hogy image/jpeg, olyan nincsen, hogy image/jpg. A böngészők általában saját vagy az OS által nyújtott kiterjesztéslista alapján találják ki, hogy adott fájlhoz milyen MIME type tartozik.
-
Sk8erPeter
nagyúr
Te most a MIME type-ról beszélsz, ahhoz a jQuery-nek túl sok köze nincsen.
Itt van egy egész hosszú lista:
http://www.sitepoint.com/web-foundations/mime-types-complete-list/Egyébként JavaScripttel is tudod csekkolni a MIME type-ot egy adott fájltípusnál (ha felismerhető) anélkül, hogy feltöltenéd, egy egyszerű fájlválasztóval, meg némi plain JavaScript-kóddal:
http://stackoverflow.com/questions/4581308/jquery-or-javascript-get-mime-type-from-url/4581316#4581316
»» http://jsbin.com/akati3/2/edit?html,output
»» https://developer.mozilla.org/en-US/docs/Web/API/Blob/type -
biker
nagyúr
Üdv Urak!
Hl tudok elérni olyan listát, a jquery szerint visszaadott file típusok mik? értem ezalatt
var acceptFileTypes = /^image\/(jpg|jpeg|png|gif)|application\/(msword|vnd.openxmlformats-officedocument.wordprocessingml.document|vnd.ms-excel|vnd.openxmlformats-officedocument.spreadsheetml.sheet|vnd.ms-powerpoint|vnd.openxmlformats-officedocument.presentationml.presentation|vnd.openxmlformats-officedocument.presentationml.slideshow|pdf)$/i;Ezt szeretném kibővíteni zip, gz, bz, tar, 7z, stb stb formátumokkal, de hogy biztosan mindet helyesen ismerje fel, mint ahogy képnél javasol a jpg és jpeg megnevezés is, nincs-e véletlen ezeken belül is több alverzió
-
Sk8erPeter
nagyúr
Nyilván ezt a megoldást lehet általánosabbá is tenni, sőt, akár lehetne kliensoldali keretrendszert/library-t is felhasználni a célra, amivel nagy eséllyel sokkal rövidebben is "megfogalmazhatod" kódszinten az igényeidet, ez egy útmutató volt arra, hogy hogyan tudod megoldani azt a konkrét problémát, amire rákérdeztél. Mivel nem fejtetted ki a konkrét igényeket, hogy milyen módon szeretnéd általánosítani, ezt kitalálni magunktól nem tudjuk.
Amúgy hogy most mitől jobb megoldás ennél az, hogy iframe-be töltöd be, az számomra rejtély.
Mindenesetre remélem, ez azért valamennyire segített elindulni az úton. -
estro
csendes tag
válasz
Sk8erPeter #3180 üzenetére
Ez működik. Csak nekem úgy általános megoldás kellett volna. Tehát több jsp lap van, és pár servletel is kommunikál (aminek a válasza nem a divbe kerül). Ezt az ajax scriptet ahogy néztem át kellene írni minden egyes servletes jspre pl külön a loginra külön a regisztrációra. Egyenlőre iframe-val megoldottam és majd ha végeztem a többi funkcióval vissza térek erre az ajax-ra. Azért köszi a segítséget.
-
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. -
estro
csendes tag
válasz
Sk8erPeter #3178 üzenetére
succes.jsp:
<h1>Success</h1>
3.jsp:
<h1>Három</h1>
Az megy, hogy html vagy jsp oldalt bele töltök a divbe. A baj, hogy ha üzleti logikát is használok, akkor az rossz jsp-t ad vissza (a jquery script nélkül jó jspt kapok, de akkor ugye nem a divbe tölti bele). Mindig a 3.jsp tölti bele a divbe, mintha folyton üresnek értelmezné a textboxot, pedig írok neki szépeket D: .
Ajaxot nincs kedvem átbogarászni most, de mind1, marad akkor statikus és majd utána nézek jobban mifán terem egy dinamikus weboldal. Elnézve a nagyobb webáruházakat ők is valami ilyesmit csinálnak, hogy egy divbe töltik bele a weblapokat, de találtam láthatatlan iframet is, gondolom valami vezérlésre van ott, szóval kicsit bonyolultabb lehet a történet, de most már haladnom is kellene ezzel a beadandóval :S. -
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. -
estro
csendes tag
válasz
Sk8erPeter #3176 üzenetére
Igazából minden linket oda szeretnék irányítani, de majd ha kell akkor átírom h csak egy divre legyen igaz vagy valami. Az url átírásnak majd utána nézek, mert látom már tényleg baj ha nem változik.
Csináltam egy példát a problémára:
index.jsp
<body>
<ul><li><a href="1.jsp">Link</a></li></ul>
<ul><li><a href="2.jsp">Link2</a></li></ul>
<div id="content"></div>
<script src="http://code.jquery.com/jquery-1.11.2.min.js"></script>
<script type="text/javascript" src="aaa.js"></script>
</body>
Az aaa.js az amit linkeltem. A linkeket ugye nem új lapon nyitja meg hanem belerakja a divbe szépen.1.jsp
<form id="target" action="ClickME" method="get">
<input type="text" name="userName">
<input type="submit" value="Go">
<script src="http://code.jquery.com/jquery-1.11.2.min.js"></script>
<script type="text/javascript" src="bbb.js"></script>
</form>ClickME ez a servlet de igazából csak az fontos h át dob egy másik oldalra (amit kellene betölteni ugyan abba a divbe)
//...
private final String userID = "asd";
//...
String user = request.getParameter("userName");
if(userID.equals(user)){
response.sendRedirect("success.jsp");
}else response.sendRedirect("3.jsp");Próbáltam ezzel a scriptel (bbb.js), de az a baj, hogy egyből átugrik a 3.jsp-re(csak akkor kellene ha nem egyezik az textből kiolvasott érték a userID változóval) függetlenül attól mi van a textboxban (mert ugye ha "asd" szöveg van benne akkor a success.jsp-t adná vissza)
$( "#target").submit(function( event ) {
var page = $(this).attr('action');
$('#content').load(page);
event.preventDefault();
});Amit még nem értek, hogy a JSTL formon (mert eredetileg arra akarom megcsinálni) nem lehet id se class se name attribútumot adni így nem tudok hivatkozni a jqueryvel arra a formra. Azt olvastam, hogy a JSTL jobban olvasható meg rövidebb, de én csak szívok vele.
Az is lehet, hogy amin elindultam módszer egyáltalán nem jó. Valakinek van ötlete?
-
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. -
estro
csendes tag
Üdv!
Van egy dinamikus menüm ami betölti ezzel a scriptel egy content nevű divbe az oldalakat amire a menüben kattintok.
$('a').click(function() {
var page = $(this).attr('href');
if(page!="")
$('#content').load(page);
return false;
});
Hogyan lehetne megoldani, hogy pl ebbe a divbe betöltött jsp a servlet által visszaküldött oldalt is ebbe a divbe rakja bele? Tehát van mondjuk egy login jsp és a gombra kattintva a divbe töltse be a választ pl Töltsd ki a mezőket. A probléma az, hogy a gombra kattintva egy új oldalra dob és így eltűnik a menüm. Vagy hogy szokták megcsinálni a dinamikus menüket? Mert így nem változik az url ami nem tudom nagy baje.
-
Cathfaern
nagyúr
válasz
fordfairlane #3171 üzenetére
Felmerülő problémák / módszerek alapján felteszem nincsenek automatizált tesztjeik. Márpedig akkor sokkal egyszerűbb ugrani egyszer verziót, és egyszer végigtesztelni meg javítani mindent, mind végigmenni 5 verzióváltáson, és 5x végigtesztelni mindent. De persze ez csak az én meglátásom.
-
fordfairlane
veterán
válasz
fordfairlane #3171 üzenetére
-
fordfairlane
veterán
Nincs kedvem átnézni az egészet, hogy az ősrégi jQuery libhez passzoljon...
Az 1.9-es jQuerynél azért van már egy-két dolog, API hívás, ami a korábbi verziókban benne volt, majd később kikerült, szóval tesztelni kell. Én azt javaslom, hogy egyszerre csak egy alverziónyit updateljetek, és utána teszteljétek. (1.4-ről 1.5.x-re, ha minden oké, mehet az 1.6.x és így tovább). Persze lehet egyből a legfrissebb jQuery verzióra ugrani, csak az több buktatót rejthet magában.
-
adam_
senior tag
válasz
Sk8erPeter #3167 üzenetére
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#11803273Hát ez se az én ötletem volt, hogy használjunk em-et.
Újabb érdekesség felmerült: [link] Muszáj lesz jQuery-t updatelni. Megcsináltam ezt a scriptet, és miután beintegráltam Drupalba amin jQuery 1.4 fut!!, érdekességként tapasztaltam, hogy a nav toggle funkciója, csak "lenyitja a menüt", de visszacsukni nem lehet. Ezt követően kezdtem el gondolkozni, hogy ugyanaz a script, ugyanaz a html/css stuktúra mellett miért nem működik a scriptemben a toggle() a Drupalunk alatt, úgy ahogy kellene. Aztán elkezdtem tesztelni a scriptem Fiddle alatt, és azt tapasztaltam, hogy jQuery 1.9 alatt nem működik az egész. Illetve pontosan úgy viselkedik pl a toggle() hogy csak lenyitja a menüt, ahogy nálam a Drupal alatt is.. viszont jQuery 1.9 és feletti libekkel tökéletesen megy a script. Most nem tudom pontosan, hogy mely funkció támogottsága hiányzik, de egyszerűen úgy gondolom lib.-et kell updatelni, és kész. Nincs kedvem átnézni az egészet, hogy az ősrégi jQuery libhez passzoljon...
Holnap lesz egy szép beszélgetésem a kollégával. De már most kivan a t*** a szitutól.
-
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).
-
adam_
senior tag
Legújabb fiddle. Ebben már szépen megy amit szeretnék, viszont ezt még nem sikerült megoldanom:
'A másik, pedig, hogy a kis display méret melett rákattintok a trigger ikonokra, akkor nagy display méret mellett eltünik az egész nav, ez miért van?'
-
adam_
senior tag
válasz
Sk8erPeter #3164 üzenetére
Szia, köszönöm a válaszod.
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.
Nem ilyenre akartam megoldani, csak így tudtam.
Segítenél ebbe, illetve rávezetnél, hogy a menüt illetve a login miért nem akarja eltünteni, ha újból rákattintok a triggerére, hol a hiba a kódban? Hol kellene változtatnom? Szóval azt kellene elérnem, hogy ki/be csukodjon a login/menü is ha az ikonjára kattintok, normál toggle() funkcióval, de ez valamiért nem megy.
A másik, pedig, hogy a kis display méret melett rákattintok a trigger ikonokra, akkor nagy display méret mellett eltünik az egész nav, ez miért van?
miért nem használtok egy jó kiindulási alapot, valami olyasmit, mint a Bootstrap (Drupal-smink is van hozzá)
Na látod, ez is jó kérdés. kollégám szerint nem lehet Bootstrapet használni, mert alapból Foundationnal dolgozunk Drupal alatt.
Abból viszont nem tetszik neki a beépített nav funkció. Szóval totál káosz.
-
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...Haha.
-
adam_
senior tag
//fix: menu always show on desktop (40em +)
if ( $('#nav-main').hide() && ($('#headerTop').width() > 640) ) {
$('#nav-main').show();
}Írtam egy ilyen fixet, mivel ha normál desktop nézetben megnyomják a logint, automatikusan eltünik a navigációs sáv is, ezzel a scripttel ez kiküszöbölhető. Viszont még továbbra is szeretném megoldani, hogy ha a loginra kattintásnál aktíválodó toggle()-t, mivel a login content szépen lenyílik toggle() segítségével továbbra is, viszont ha újból rákattintok a login-ra nem akarja "visszacsukni" azt. További részletek itt [link].
-
adam_
senior tag
Valamint még azt szeretném elérni, hogy normál desktop nézetbe ha a loginra kattintanak, az szépen lenyílik toggle() segítségével, viszont ha újból rákattintok a login-ra nem akarja "visszacsukni" azt, ez miért van?
Előre is köszönöm az észrevételeket, és bocsi ha ma "sok voltam" itt, de már csak ezt az apróságot kellene megoldanom valahogy.
-
adam_
senior tag
[link] Újabb módosítás történt, bevezettem data-targeteket a cél ID-s konténrekehez, valamint a data-hide-ot a triggere vonatkozóan, valamint toggle-link a triggerhez + toggle-box osztályokat a boxokhoz. Így szépen megy a kód, viszont a hide() funkcionalítást kellene belőnöm hozzá. Valaki tudna segíteni benne?
-
attis71
tag
Sziasztok!
jQuery-ben szeretnék e-mail karakter ellenőrzés megvalósítani input mező elhagyásakor.
Tudnátok valami ötletet, persze nem kell a kész kód!
Csak szeretném megoldani és mindig zsákutcába jutok.attis71
-
-
adam_
senior tag
-
adam_
senior tag
válasz
Sk8erPeter #3154 üzenetére
Szia,
készítettem egy demót az elképzelésemről. Mielőtt linkelném a fiddle-t, leírnám, hogy jelenleg mi a felállás:
Kollégám szerint egyenlő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.. tehát marad az esetünkben a delegate() parancs és az ősrégi JQuery
Nem vitatkozom vele.
A show() / hide() témával kapcsolatban kollégám azt írta, hogy elméletben így lehetne megoldani:
- toggle link hozzáfűzése a DOM-elemekhez ( hide()/show() )
- optional a show() előtt a többi kapcsolodó DOM-elemet rejtsük elEgy lehetséges forgatókönyv hozzá:
- toggle link kap egy data-target="ziel-id" -t és opcionálisan data-hide="other"
vagy egy másik felállás szerint:
- Cél elemnek van egy id-ja és egy közös osztályuk pl.: toggle-box
Tehát a toggle-link és toggle-box osztállyal így variálhatunk. Toggle link osztály megadása az összes trigger elemnek (tehát menü-trigger + form-trigger), majd a lenyiló tartalmak pl menü-box + form-box nak is adunk egy közös osztályt toggle-box néven. Majd egy lehetséges kód hozzá:
$(document).delegate('.toggle-link', 'click', function() {
var target = $(this).attr('data-target'),
hide = $(this).attr('data-hide');
if(hide == 'other') {
$('.toggle-box').hide();
}
$('#'+target).toggle()
return false;
});Szóval az a lényeg, hogy valahogy párhuzamosan elérjük, hogy a user ne tudjon egyszerre a login (jelen esetben zöld) és a menü trigger ikonjára (fiddleben ez piros kocka) is kattintani ezzel lenyitva mind a két boxot. Csak szépen az egyiket tudja lenyitni egyszerre.
Jelenleg a fiddleben egyszerre lenyílik a menü és a login box is, ha rákattintunk, és ez valóban nem szép.
Hogyan tudnám a mostani fiddle példámban ezt megoldani, az új kód segítségével? Pluszban ugye jó lenne elérni, ha a user a menüre kattint, onnan jelentkezzen be, közben meg párhuzamosan ne tudjon a login-trigger(zöld kocka)-ra kattintva is bejelentkezni. Tehát az hide()-olni kellene.
Valamint még megjegyezném, hogy most már szépen lenyílik a menü ha kis display mérett alatt a kék kockára kattintok, viszont ha ezt követően összehúzom a kijelzőméretét, akkor azt tapasztalom, hogy a navigáció eltünt. Ez miért van? És a login miért marad ugy szépen, ahogy kell?
Remélem ezúton érthető demót szolgáltattam.
Előre is köszönöm az észrevételeket,
Ádám
-
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"...
-
adam_
senior tag
válasz
Sk8erPeter #3152 üzenetére
Őszintén szólva, így kérte a felettesem, gondolom neki meg az ügyfél mondta, hogy így akarja, így hát én így próbálom megcsinálni.
Egyenlőre becommitoztam neki az én variációm, de tényleg elég gázos, hogy egyszer eltünik a pl a login ha a nav-ra kattintanak, majd a navból elérhető ugyanez a login menüpont.
-
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? -
adam_
senior tag
Elméletben így tudnám prezentálni a problémám, amit funciónalítás (kód) szempontjából szeretnék megéretni, és átültetni az én konkrét példámra (Konkrétabb részletek a korábbi hozzászólásaimban.
)
További komment fiddleben.
Köszönöm szépen előre is, ha valaki időt szán rá/rám.
Ádám
-
adam_
senior tag
válasz
Sk8erPeter #3149 üzenetére
Köszönöm szépen, beajánlom a backendes kollégánál a modul telepítését.
És előre is köszönöm a véleményed következő kérdésemre. Ha valami nem lenne világos, részletezem még jobban.
-
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ó'.
-
adam_
senior tag
Fiddle Ezúton kimásoltam az érintett html kódokat az oldal forrásából, plusz alá írtam a jelenlegi JS-t. Remélem így valamelyest átláthatóbb.
Mellékelek még pár képet, hogy jobban szemléltessem a problémákat egy kis magyarázattal karöltve:
Valamely logikai hiba miatt nem jó az egész, szerintem az if..else ágban csúszik el nekem valami, ami megakadályozza, hogy visszatérjen az eredeti állapotra mindig az adott ciklus. Tettem rá kisérletet az else ágban, hogy jelenítse meg máskülönben mindig az eredeti konténereket, de nem történik semmi sem.
-
adam_
senior tag
Az a baj, hogy linkelek én hozzá html-t, meg css-t, de Drupalból ezt kinyerve így néz ki fiddleben: link
Segítenél abban, hogy hogyan lehetne a kódom effektívebb?
Ez a hide / show funkcionalítás nálam nem akar összejönni, úgy értem, ha egyszer elrejti ... végleg elrejti, és vissza se lehet hozni, nem beszélve arról, hogy nem is azon a display méreten rejti el, ahogy szeretném, és amelyre tettem kisérletet az if .. else ágban. És fogalmam sincs, hogy hol lehet a hiba..
Elméleti síkon, a logikát szeretném megérteni, hogy mi lehet a hiba, hogy tudjam javítani a kódom.
-
Jim-Y
veterán
-
adam_
senior tag
Készítettem egy újabb fiddle-t, ezentúl delegate()-el, mivel egyenlőre az on() nélkül kell beérnem, hála az ősrégi JQuery libnek.
Valamiért nem akarja az igazát a linkelt scriptem. Leírom mégegyszer, hogy mit szeretnék elérni.
Loginboxnál:
Ha rákattintanak, akkor szépen toggle-val jöjjön le a bejelentkező box. Ez eddig megy. Viszont, párhuzamosan szeretném elérni, hogy a menü ikonja tűnjön el mellette, ha épp a loginboxra kattintottak. DE ezt is csak kis display, jelen esetben 640px (etc 40em) alatt.
Jelen állás szerint, ha rákattintok a login ikonra, eltünik a menü, de mindenhonnan, nem csak kis display mérett melett, és igazából vissza se lehet hozni, ha újból bezárom a loginboxot.
Ugyanezt szeretném elérni a menünél is, csak ez annyival bővült ki, hogy ha rákattintanak a login bejelentkező ikonja eltünik, és a bejelentkezés az egyik menüpontból lehetséges a .login-menuitem a linken keresztül.
Mi nem stimmel a kóddal?
Előre is köszönöm az észrevételeket!
Ádám
-
adam_
senior tag
válasz
Sk8erPeter #3140 üzenetére
Linkeltem egy fiddle-t, amelyben az on()-t szeretném használni Drupal 7 alatt. Fiddlben is írtam, ide is kiírom, hogy az alábbi hibaüzenetet kapom vissza konzolba + az alábbi sorokra hivatkozik "hibaként".
Uncaught TypeError: undefined is not a function $('#z4lms-login-trigger').on('click', function (e) { ........ $('#nav-trigger').on('click', function (e) { .....
Próbáltam alkalmazni az előző sima delegate-es funkcionalítást is on()-nal helyettesítve, szintén ugyanezt a hibaüzit kapom vissza. Ez miért van, Drupalban problémás csak az on() alkalmazása, vagy az én scriptem hibádzik valahol?
Amúgy a scriptekkel szeretném elérni, ha pl. rákattintanak a navigációra akkor a login gomb tünjön el és fordítva, és pluszban a login funkcionalítása egy másik menüpontba a navigáción belül elérhetővé váljon. Valamint ha már be van jelentkezve a felhasználó, (ergo, létezik a logged-in osztály), akkor a login-triggere láthatatlan legyen.
-
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.
-
adam_
senior tag
Köszönöm szépen a fenti tanácsokat, tippeket, bár még ezeket a szakmai koncepciókat, "hogy lenne jobb, szebb, effektívebb kódolni.." "szoknom" kell
, mert még nincs sok szakmai év a hátam mögött, de bízom benne, hogy idővel már minden zsigerből a legegyszerűbb / legjobb módon fogok programozni. Hála nektek, és az eddigi "mentoraimnak" akikkel volt szerencsém találkozni a szakmában.
Linkeltem egy újabb "rejtvényt", amivel a mai napomon szembesültem. Lényegében most a koncepciót szeretném megérteni, és abból kiindulva rájönni, hogy mi a gubanc. A login már szerencsére tökéletesen működik a Drupallal (responsive) is, szépen mobilon / kisebb display méreteken úgy jelenik meg, ahogy a szerződésben leírtak. 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.
//login box
$(document).delegate('#z4lms-login-trigger', 'click', function() {
$('#z4lms-login-content').toggle();
return false;
});Viszont, úgyanezt kellene lezongoráznom a menüvel is, hogy ha kisebb a display méret, akkor popup / jelen esetben nálam dropdownban jelenjenek meg a menüpontok. Mivel nem akarok erre a célre még egy nav -taget írni html-ben, úgyanazt az eredeti nav-ot szeretném átadni a mobilos nézetben beaktiválodó nav-mobile konténernek.
Erre a megoldásra, mint a kódban is láthatjátok,
$("#nav-mobile").html($("#nav-main").html()); metódust alkamazok, az ötletet innen vettem: [link] Ezzel nálam csak az a baj, hogy amikor az egész oldal betöltődik, már egyből beállítja az eredeti nav értékeit, CSS-el, mindennel együtt a nav-mobile konténernek. Ebből következően az összes nav-mobile konténerre vonatkozó CSS-t is figyelmen kívül hagyja, és már nagy display méret mellett is megjeleníti az egészet, holott eredetileg display: none-re van állítva, nem beszélve a formázások figyelmenkívül hagyásáról.Mit gondoltok, hogyan lehetne beállítani, hogy csakis akkor adja át az értékeket a nav-mobile konténernek az eredeti nav, ha rákattintanak a "nav-trigger"-ben található svg-re, ami csak kis display méreten jelenik meg?
Próbáltam már úgy, hogy a kérdéses JS-t beillesztem IF ágba, de úgy sem jó, meg elvégre, ha az eredeti oldalon megy, akkor nálam miért nem megy így? A Dropdown funkcionalítás működik, hiba nincs a konzolban (a kód elvégre helyes Drupalban is így), szóval gyanítom, hogy ez a sor a ludas nálam: $("#nav-mobile").html($("#nav-main").html());
Előre is köszönöm a mostani hasznos tippeket is,
Ádám
-
martonx
veterán
válasz
DNReNTi #3133 üzenetére
Én a "hivatalos" jquery validation-t használom. Ehhez kigenerálok data tag-ekben validációs szabályokat, amiket utána egy jquery validation bővítmény szabványos validation rule-okkát konvertál.
És mindez a szerver oldali modellekből fakad. Szóval ha egy modell egy mezőjén jelzem, hogy azon xy regexp validáció legyen, akkor nem csak szerver oldalon, de hirtelen kliens oldalon is kész is van a megfelelő validációm -
DNReNTi
őstag
válasz
Speeedfire #3134 üzenetére
Érteni értem, csak nem tudom, ez hogy fogja levenni/rátenni a disabled attribútumot a submit-ra.
-
DNReNTi
őstag
válasz
martonx #3132 üzenetére
Összesen két mező tartalmának a hosszát csekkolja le, így akkor marad. Persze ettől függetlenül szerver oldalon is validálva van a felvitt info. A delegate-et cseréltem on-ra, jogos észrevétel. Néztem korábban kimondottan form validációs plugineket jQ-hez, de ilyen egyszerű feladathoz nem akartam behúzni egyet. Köszi a tippeket!
-
martonx
veterán
válasz
DNReNTi #3131 üzenetére
Ha minden egyes keyup-nál nem több száz input egyenként 10-féle validációját kell végigellenőriznie a kódnak, akkor biztos nem.
Viszont a .delegate valami őskori jquery maradvány.
Plusz javasolnám valami normális validációs framework kialakítását, valami pluginre alapozva. -
DNReNTi
őstag
Hola,
Egy villámkérdés:
Egy halál egyszerű bejelentkező formot szeretnék validálni (kemény két field). Csináltam már 100x, de most megkérdezem jól csinálom e egyáltalán.
A kotta erre vonatkozó része:$loginForm.delegate(".required", "focusout keyup", function(){
checkLoginInputsLength() ? $loginButton.removeAttr("disabled") : $loginButton.attr("disabled", "disabled");
});Nem túl erőforrás igényes a keyup event ide?
Köszke.(#3130) Sk8erPeter
Egyetértek. Nem ide vág, de sose fogom felfogni aki pl SASS-t használ (SCSS helyett) annak hogy nem törik le a keze, és folyik ki a szeme.Akinek esetleg nem ismerős: SASS-ban se pontosvessző, se kapcsos zárjójel.
-
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.
-
Jim-Y
veterán
válasz
Sk8erPeter #3128 üzenetére
Ezt meg annyival egeszitenem ki, ami kimaradt Sk8erPeter amugy remek osszefoglalojabol, hogy a ; (semicolon) rakasokat sem hasznalod tul kovetkezetesen. Neha kiteszed, neha nem. A best practice az, ha mindig kiteszed. A masik a dangling else.. Tegyuk mar ki a { (curly braces) jeleket!
if ($(this).hasClass('active')) $(this).find('#loginLogo').html('▲')
else $(this).find('#loginLogo').html('▼')helyett
if ($target.hasClass('active')) {
$loginLogo.html('▲')
} else {
$loginLogo.html('▼')
}Sot, mivel ez meg mindig nem tul DRY, ezert ami ennel is jobb practice
var chevron = $target.hasClass('active') ? '▲' : '▼';
$loginLogo.html(chevron);Illetve en biztos, hogy nem hasznalnam a click(), change() stb.. shorthand functionoket event handlingre, mert ha helyette:
$topLevelElem.on(CLICK, 'eventDelegation', handler);
Igy hasznalod az esemenykezeloket, akkor vele jar elonyokre teszel szert:
- egyreszt a CLICK valtozot egyszer fogod letrehozni amit addot esetben le tudsz majd konnyen cserelni TOUCH_END-re peldaul.
- event delegation -
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.
-
adam_
senior tag
válasz
Sk8erPeter #3123 üzenetére
Köszönöm, javítottam a JQuery-t egy ilyenre:
(function ($) {
Drupal.behaviors.z4_lms = {
attach: function (context, settings) {
$('#login-trigger').click(function(){
$(this).next('#login-content').slideToggle();
$(this).toggleClass('active');
if ($(this).hasClass('active')) $(this).find('#loginLogo').html('▲')
else $(this).find('#loginLogo').html('▼')
})
}
};})(jQuery);Ezzel már tökéletes megy. Az átlátszósági probléma pedig nem z-index és hasonlóból eredt, hanem egyszerűen valamiért a foundation osztályok, amit ráhúztam a konténerre, egyszerűen "bezavart", levettem, és manuálisan írtam media query-t, így már szépen lehet kattintani az input mezőkre adatokat bevinni, submittal elküldeni a különböző display méretek mellett. És javíottam a html kódot is. köszi.
Igazából különösebb bajom nincs a Drupallal, viszont számomra így az elején mindent úgy megbonyolít.
Főleg, ha még bevan kapcsolva egy framework is hozzá.
Statikus html / css / JS -el egy oldal megírása nem probléma, ha már bevan kapcsolva hozzá egy CMS is, az még okoz izzasztós perceket / órákat számomra.
-
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.
-
adam_
senior tag
Drupal 7 Templatinggel foglalatoskodom, és már most utálom.
Ugyanis, az alábbi JQuery toggle funkcióját szeretném benne alkalmazni, konkrétan ezt és ilyen formában: [link]
Természetesen ez így itt úgy működik, ahogy szeretném, viszont Drupalban részben megy. Az alábbi hibák jelentkeznek.
Valamiért a leugró ablakban csak a username mezőre lehet kattintani, és oda beírni a tartalmat, a jelszó input mezőre lépés csak tabulátorral lehetséges, ezt követően a gomb megnyomása is úgy lehetséges, ha előtte tabbal rámegyek. Fogalmam sincs, hogy csak miért az első input mezőre lehet kattintani. Esetleg JS kódból nem lehetne "kényszeríteni" valahogy a kattintás lehetőségét a mezőkre Drupalban?
A második, pedig hogy a fő content "áttüt" az egész lenyiló konténeren Drupalban, konkrétan így:
Erre próbáltam már egy másik JQuery scriptet írni, egyenlőre ki van kommentelve, de sajnos nem működik így sem, sőt úgy sem, ha manuálisan állítgatom css-ben az opacity-t a konténeren.
Mit gondoltok, mi lehet a probléma forrása? Bocsánat ha nem jó helyre írtam volna, de úgy gondolom itt több JQuery szakértőt találok, talán olyan is akad, aki jártas a Drupal okosságaiban, és tudna nekem segíteni a témában.
Egy másik kicsit inkább CSS témában vágó dolog, hogy azt hogyan oldhatnám meg (külön még egy erre a célra létrehozott konténer nélkül), hogy ez a lenyiló menü mobil nézetben csak a headerTop részben jelenjen meg a menü mellett.. és az mostani helyéről(HeaderBottom) tünjön el (ergo display: none) vagy hasonlóval? Azt tudom, hogy Foundationben léteznek okosságok, amivel el lehet tünteni egy adott osztály egy adott méreten belül/kívül, viszont újból előhívni egy másik pozicióban kisebb display méret alatt, na ez nekem kihívás.
Előre is köszönöm,
Ádám
-
Speeedfire
félisten
válasz
Sk8erPeter #3120 üzenetére
Akkor marad így az egész.
-
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ó. -
Zedz
addikt
válasz
Speeedfire #3118 üzenetére
Jajj, nem voltam elég figyelmes.
-
Zedz
addikt
válasz
Speeedfire #3116 üzenetére
Ha már okés, akkor oszd meg velünk a megoldásod.
-
DNReNTi
őstag
válasz
Speeedfire #3114 üzenetére
De amúgy most pontosan mit szeretnél figyelni?
Az még nekem nem tiszta.
-
DNReNTi
őstag
válasz
Speeedfire #3112 üzenetére
keyup() ?
-
Speeedfire
félisten
Sziasztok,
egy html elemre raktam egy change figyelőt, viszont most nézem, hogy a doksiban a js féle val() input adást nem figyeli. Lehet erre kötni egy másik eseményt?Change api: Note: Changing the value of an input element using JavaScript, using .val() for example, won't fire the event.
-
PumpkinSeed
addikt
válasz
Sk8erPeter #3110 üzenetére
Ez érthető, köszönöm. A codeacademy-s tutorial sorozat elég sok mindent kihagyott, viszont adott egy jó alapot a továbbfejlődéshez.
-
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.
-
PumpkinSeed
addikt
válasz
Sk8erPeter #3107 üzenetére
Köszönöm, még annyi kérdésem lenne, hogy a click event handlerének mire szolgál az e paramétere?
(#3106) Speeedfire
Köszönöm, igazából sok változást nem generált az .on-s megoldás.
-
DNReNTi
őstag
válasz
Sk8erPeter #3107 üzenetére
Épp írni akartam, hogy felesleges js-sel mozgatni a menüt ha lehet CSS-el is, de megint elkéstem.
Viszont nagy UP, hogy implementáltad is nem csak leírtad.
-
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/
// ...
} -
Speeedfire
félisten
válasz
PumpkinSeed #3105 üzenetére
Használj frissebb jquery-t.
Illetve a 2. részt javítsd ki on()-ra. Azért nem fut le, mert a figyelő olyan elemen van, ami még nem létezik a dom-ban. -
PumpkinSeed
addikt
Olyan kérdésem lenne, hogy a miért nem akar működni a kódom. Itt található, a piros gombra kijön ha megint kattintok vissza kellene mennie. De nem megy.
-
Speeedfire
félisten
dqdb & Sk8erPeter & martonx: Köszi a helyreigazítást srácok, akkor marad az a megoldás, hogy az adott oldalon figyelem, hogy mire kattint.
-
martonx
veterán
válasz
Speeedfire #3098 üzenetére
Félreértetted. Ez annyit csinál, mint amit sk8erpeter mondott, azaz oldalon belüli navigációt figyeli, plusz a böngésző előre, hátra gombjait, historyban ugrálást.
Azt hogy a user fogja és beír xy.hu-t a böngészőbe, és elugrik oda, azt sehogy nem fogod tudni kideríteni. Csúnya is lenne. -
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.
-
dqdb
nagyúr
válasz
Speeedfire #3100 üzenetére
Ha saját oldalon kell megoldani, és csak a linkekre kattintva kell működnie, akkor az egyik legegyszerűbb megoldás, ha a kifelé mutató direkt linkeket olyan sajátokra cseréled, amelyek átirányítják a felhasználót a megfelelő helyre, miközben te tudod regisztrálni a választott célt. Így működik többek között az Index főoldala is, például a legelső hír linkje a főoldalon most ez, amiből átirányítás után ez lesz.
Új hozzászólás Aktív témák
Hirdetés
- Panasonic CF-XZ6 AIO all-in-one laptop tablet 2k touch i5-7300u speciális ütésálló rugged
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2253,95% Akkumulátor
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- Xiaomi Redmi Note 9Pro 64GB Kártyafüggetlen 1 év Garanciával
- Gamer PC-Számítógép! Csere-Beszámítás! R5 5600X / RTX 3070Ti / 32GB DDR4 / 1TB SSD
Állásajánlatok
Cég: FOTC
Város: Budapest