Új hozzászólás Aktív témák
-
#3304
Sk8erPeter
nagyúr
trisztan94
#3303
Sk8erPeter
nagyúr
válasz
trisztan94
#3303
üzenetére
Ez esetben szerintem kénytelen vagy a jövőben létrejövő elem szülőelemére is aggatni egy MutationObservert, és figyelni a gyerekelemek változását, hogy mikor kerül hozzáadásra, és amikor a várt elem létrejöttét detektálod, akkor csapod hozzá a további MutationObservereket, ahogy martonx írta. (A szülőelemen childList vagy subtree attribútumok vmelyikével, most telóról vagyok, nem tudom kipróbálni.)
-
#3290
Sk8erPeter
nagyúr
trisztan94
#3289
Sk8erPeter
nagyúr
-
#3288
Sk8erPeter
nagyúr
Randomized
#3286
Sk8erPeter
nagyúr
válasz
Randomized
#3286
üzenetére
Ha jól értettem, valójában szerveroldalon az látszik, hogy tényleg sikeres a belépés - vagy mégsem? -, csak kliensoldalon nem gömbölyű valami, de ezt nem fejtetted ki - igazából a lényeget -, hogy mi is nem működik egész pontosan. Maga az oldal újratöltése nem történik meg? Vagy újratöltés után mégsincs bejelentkezve már a felhasználó, pedig korábban úgy tűnt, hogy be van jelentkezve - tehát mégis szerveroldali a para? Vagy kliensoldalon nem látszik valami úgy, ahogy látszania kellene? Vagy mi (nem) történik?
Ezt az alábbit még azelőtt írtam, hogy visszaolvastam volna, és láttam volna, hogy elméletileg be van jelentkezve a júzer (de lehet, hogy csak úgy tűnik, pedig igazából nem), végül is a benne írtak állnak továbbra is, de mivel itt OFF, meg valószínűleg nem is itt lesz a megoldás, ezért OFF-ba is raktam:
A PHP-kódnál sokat segít hibafelderítés esetén, ha nem nyomod el a hibakijelzést az error_reporting 0-ra állításával (persze kizárólag fejlesztői, nem production környezetben).
Egyébként a potenciális hibák lekezelése finoman szólva nem túl alapos, pl. csatlakozás után egyáltalán nem ellenőrzöd, hogy minden rendben ment-e az adatbázissal való kapcsolat létrehozása során. A mysqli_query visszatérési értékét is érdemes lenne leellenőrizni, mielőtt ráhívsz a visszaadott eredményre egy mysqli_num_rows-t - igaz, ennek elméletileg nullát kellene visszaadnia, ha már eleve előtte a query sem futott le helyesen.
A mysqli_real_escape_string-es bohóckodás nagyon rossz és rég elavult gyakorlat, helyette parametrizálni kell a query-t (lásd itt), és a nyelvi eszközök pedig elintézik, hogy az átpasszolt paraméterek le legyenek kezelve (rosszindulatúság és egyéb szempontokkal kapcsolatban).
Másik hiba: beállítod az $errors['pass']-t, és aztán később ellenőrzöd, hogy !isset($errors['userpass'])-t.
(másik kulcs, pass vs. userpass... ) Egyébként sem sok értelmét látom, hogy más kulcsot használsz fel az $errors tömbödben, mint az eredetileg klienstől (a formban az adott mező name attribútuma formájában) kapott kulcsoknál.
Egyébként mysqli-nél szerintem nagyon csúnya a procedurális formula, az objektumorientált API nem véletlenül áll rendelkezésre, de persze ízlések és pofonok. -
#3285
Sk8erPeter
nagyúr
Randomized
#3284
Sk8erPeter
nagyúr
válasz
Randomized
#3284
üzenetére
Az a baj, hogy a hibaleírásból még az sem derül ki egyértelműen, hogy melyik "szereplő" lehet a probléma okozója, mert konkrétabb kódrészletek vagy pontosabb körülírás nélkül nem lehet kitalálni. Némi kód előrébb vihet.
-
#3256
Sk8erPeter
nagyúr
dqdb
#3255
Sk8erPeter
nagyúr
Igen, elég egyszerű lett volna elintézni, hogy ne egy darab, alig észrevehető karakterben (e) térjenek el.
Amúgy persze, értem az okokat, de ez jelen formájában béna.
Főleg, hogy "belül" a sliding szócskát használják (miért nem lehetett akkor azt használni az eseménynél is?):
http://getbootstrap.com/dist/js/bootstrap.js
var Carousel = function (element, options) {
this.$element = $(element)
this.$indicators = this.$element.find('.carousel-indicators')
this.options = options
this.paused = null
this.sliding = null
this.interval = null
this.$active = null
this.$items = null
...Azért a kódban külön megjegyzik, hogy "// yes, slid"
var slidEvent = $.Event('slid.bs.carousel', { relatedTarget: relatedTarget, direction: direction }) // yes, "slid" -
#3251
Sk8erPeter
nagyúr
trisztan94
#3249
Sk8erPeter
nagyúr
válasz
trisztan94
#3249
üzenetére
Hogy mi? Ez komoly, hogy úgy akarod megoldani a problémát, hogy 5 másodpercenként ránézel az elemre, hogy mi a helyzet vele?
(#3248) disy68:
Ez mennyire brutálisan béna a Bootstrapnél, hogy egyetlen karakterben tér el a két event, "slide.bs.carousel", illetve "slid.bs.carousel", úristen, ezt még nem is láttam.
Ilyen alapon lehetett volna akár "slide.bs.carousel" és "slide.bs.carouse" is, hasonlóan lehetne érteni és észrevenni a különbséget. Micsoda egy idióta, aki ezt kitalálta. -
#3240
Sk8erPeter
nagyúr
biker
#3239
Sk8erPeter
nagyúr
Most bevallom, ezt a magyarázatot nem értettem, hogy "a billentyűzet kiosztás felülírást (nevezzük így) más rétegben alkalmazza, mint a win". No de miért tűnik kifejezetten OSX-specifikusnak tűnik a probléma, és se Windows-nál, se Linuxnál nem jelentkezik? Most kipróbáltam egy öregecske Fedora Linuxon, ott is helyesen működik (ez volt épp kéznél, igaz, virtuális gép formájában, ami elképzelhető, hogy megint változtat picit a képleten, de egyébként korábban sem tapasztaltam ilyen jellegű parát Linuxon).
Még esetleg Firefoxban csak kíváncsiságból meg tudnád nézni, ha kéznél van? Ha ott is ugyanez van, akkor legalább általános, és tényleg számolni kell ilyen gonddal OS X-nél, és jó tudni...
-
#3238
Sk8erPeter
nagyúr
biker
#3236
Sk8erPeter
nagyúr
-
#3235
Sk8erPeter
nagyúr
biker
#3234
Sk8erPeter
nagyúr
Ki tudnád próbálni a kedvemért egy normális böngészővel is, tehát ami nem Faszari? Csak úgy kíváncsiságból, mert még mindig nem értem, hogy az OSX ilyen retardált-degenerált, hogy egy normális keyboard layout beállítás is el van rontva, olyan almásan, vagy az Apple-nek csak a csodálatos büszkesége, a böngészőjük ilyen okos...
![;]](//cdn.rios.hu/dl/s/v1.gif)
Köszi!"szarul beállított karakterkódolás és beviteli ellenőrzés mellett ez miatt nem tudod beütni a születési időd, vagy telefonszámod, akkor az van, hogy magyar bill esetén 1-9 és ö betűt tudsz bevinni"
Hogy jön ide a karakterkódolás?"Ha nincs ott a user mellett egy alapfokú IT ismeretekkel rendelkező ember, aki segít angol billre váltani, az megszívta. (ha a laptopján pl nincs numpad)."
Hát ez nekem még mindig nagyon furcsa. Ha magyarra van állítva operációs rendszer szintjén a kiosztás, és a magyar billentyűzeten a felhasználó a megfelelő gombot nyomja le, akkor a 0-nak kellene előjönnie a 0 lenyomására. Szóval ez nekem elég egyedinek tűnik, valami Apple-höz kötődőnek (mindegy, hogy csak Safari vagy már kapásból az OSX szintjén), ilyet legalábbis Windows-nál és Linuxnál nem tapasztaltam.
Amúgy ha már numpad van, akkor ott meg az a potenciális hibaforrás, ha a Num Lock ki van kapcsolva... -
#3232
Sk8erPeter
nagyúr
biker
#3230
Sk8erPeter
nagyúr
"Charcodeban más a numpados 0 meg a felső számsoros"
Persze, más: a fölső számsor 0-ja 48-as kódú az ASCII-táblának megfelelően, a numpados 0 pedig 96-os (ASCII-tábla szerint ez a grave accent (`)). A fölső számsoros 0-t lenyomva magyar billentyűzetnél, de az operációs rendszerben US QWERTY layoutot alkalmazva (tehát ahol például problémát jelenthet a 0 és ö betűk közti különbség) 192 (À, Latin capital letter A with grave a Windows 1252 szerint) a keyCode/which (amúgy az eventhez tartozó charCode, keyCode és which deprecated az MDN szerint, nem tudom, miért, ha a code és key property-k jelenleg nem működnek, pontosabban a key csak Firefoxban azt hiszem, Blink-alapúakban még egyik sem).Viszont kérdés, hogy ez esetedben miért számít egyáltalán, ha úgyis barcode scannerrel viszitek fel az adatot?
"Ha be akarok lépni, angolra kell váltani a billt, hogy az ö helyén nulla legyen, ha nincs kéznél a numpados billentyűzetem"
Ezt viszont nem értettem. A tenkeyless keyboard esetén is a fölső számsorban is található egy 0 gomb, meg mivel magyar billentyűzetet használsz, egy ö betű is a számok mellett. Miért kell átváltani a kiosztást a tényleges 0 gomb megnyomása helyett?Amúgy ha érdekelnek a pontos keycode-ok csak úgy gyors ellenőrzésre, hogy épp mit nyomsz le, mi a keyCode-ja (még ha az deprecated is azóta
), valamikor nagyon régen csináltam még ilyet magamnak:
http://jsfiddle.net/Sk8erPeter/EAjYe/ -
#3203
Sk8erPeter
nagyúr
attis71
#3202
Sk8erPeter
nagyúr
válasz
attis71
#3202
üzenetére
Hát az a kód valami kegyetlen gusztustalan.
Amúgy meg miért várod, hogy működjön, ha az insertDB.php fájlodban olyan mezők értékét ellenőrzöd, és próbálod meg elérni, amelyekhez tartozó űrlapelemeket a HTML-fájlodban nem definiáltál? Jogosan nem lesznek ilyen elemek a szerveroldalra elküldött adatok között, és így jogosan nem fut le az adatbázisba való feltöltésre szolgáló kódrészlet sem (tehát nem lépbe a feltételtől függő ágba).Meg a kliensoldali insertDB() függvényed is baromság, ezt küldöd el szerveroldalra:
data: { kolcsonzoID: 'kolcsonzoID', utanfutoID: 'utanfutoID', datum : 'datum' },
Minek küldesz el ilyen stringeket? Gondolom valós adatokat akartál elküldeni. -
#3200
Sk8erPeter
nagyúr
#39560925
#3199
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). -
#3198
Sk8erPeter
nagyúr
#39560925
#3194
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.
-
#3184
Sk8erPeter
nagyúr
biker
#3183
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 -
#3182
Sk8erPeter
nagyúr
estro
#3181
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. -
#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. -
#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. -
#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. -
#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).
-
#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... Haha. -
#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"... 
-
#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? -
#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ó'.
-
#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.
-
#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. -
#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. -
#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. -
#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ó. -
#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.
-
#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/
// ...
} -
#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.
-
#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). -
#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. -
#3081
Sk8erPeter
nagyúr
fluxion
#3080
Sk8erPeter
nagyúr
válasz
fluxion
#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. -
#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.
-
#3067
Sk8erPeter
nagyúr
Zedz
#3063
Sk8erPeter
nagyúr
-
#3059
Sk8erPeter
nagyúr
Speeedfire
#3058
Sk8erPeter
nagyúr
válasz
Speeedfire
#3058
üzenetére
Nincs mit!
-
#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
). -
#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).
-
#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.) -
#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/ -
#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. -
#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.
-
#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. -
#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. -
#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. -
#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. -
#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é. -
#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.
-
#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).
-
#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... -
#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. -
#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 -
#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");
-
#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. -
#2949
Sk8erPeter
nagyúr
Jim-Y
#2948
-
#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. -
#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/ -
#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?
-
#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. -
#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. -
#2913
Sk8erPeter
nagyúr
daninet
#2912
Sk8erPeter
nagyúr
válasz
daninet
#2912
üzenetére
Nem igazán néztem a feladatodat, de az ilyenekről szokj le, hogy egymás után ennyiszer hívogatsz tök feleslegesen egy metódust, jelen esetben a jQuery(sidebar) kilencmillióhatszázezerkettőször van leírva nálad, így az minden alkalommal meghívódik, overheadet jelent, még ha nem is veszed észre. Tárold el egy változóban az értékét, és használd azt:
$sidebar = jQuery(sidebar);
$sidebar.addClass("fixed");
$sidebar.KISKUTYAFÜLE(); -
#2903
Sk8erPeter
nagyúr
Cathfaern
#2902
Sk8erPeter
nagyúr
válasz
Cathfaern
#2902
üzenetére
"Mi Kohanát használtunk, viszont elég rendesen bele lett módosítva saját igények szerint [...] Ahhoz hogy működjön minden, a .htaccess file-okon is módosítani kellett"
Már eleve nem kicsit furcsa, hogy bele lett tákolva egy framework core-fájljaiba, és akkor ebből következett az a teljesen általánosító mondatod, hogy "gyakorlatilag egy összetettebb keretrendszernél így is elég szívás tud lenni a .htaccesst rendesen belőni"? Bocs, de ezt az érvet így a körülmények ismeretében különösen nem tudom komolyan venni.(Mellesleg még a korábbi hsz. írása előtt belenéztem azért pl. a Symfony .htaccess-ébe is, és nem láttam túl komplikált dolgokat, amit ne lehetne átültetni egy web.configba, nem beszélve arról, hogy lehet találni megfeleltetést neten.)
Most tulajdonképpen semmi újító szempontot nem mondtál, hanem azokat az érveket soroltad fel, amik már előre ki lettek vesézve, de azért kicsit offenzív stílusban álltál elő a "Szép és jó", meg "Persze ez otthoni hobbi weblapnál nem akkora probléma"-jellegű érvekkel, aztán kiderült, hogy tulajdonképpen semmi konkrétummal nem tudod alátámasztani, amit írtál, mivel még csak nem is használtad az IIS-t. -
#2901
Sk8erPeter
nagyúr
Cathfaern
#2899
Sk8erPeter
nagyúr
válasz
Cathfaern
#2899
üzenetére
Az a jó, hogy azokkal az érvekkel kezdted, amikre már előre reagáltam.
Azon én is elgondolkoztam picit, hogy pontosan hogy is érted azt, hogy "gyakorlatilag egy összetettebb keretrendszernél így is elég szívás tud lenni a .htaccesst rendesen belőni", és ezt konkrétan mivel támasztanád alá, de mivel nem fejtetted ki, úgy gondoltam, inkább rádbíznám ezt a feladatot, akkor talán tudunk is róla érdemben beszélni (és nem csak nagy általánosságokban).
Pontosan erről beszéltem korábban, hogy az emberkék nagy része úgy tűnik, egyszerűen nem ismeri az IIS-t, mint nagyon jó Apache-alternatívát, ezért tart is tőle, bár a rosszabb része az, amikor erősen flegmázva is adja ezt elő, ez utóbbit sajnos te is elkövetted a végén: "Persze ez otthoni hobbi weblapnál nem akkora probléma". Ebből az következik, ha szó szerint értem (akár csak rosszul fogalmaztál, akár nem), hogy tehát akinek elegendő az IIS, akkor az valószínűleg nem tart még azon a szinten, hogy azokkal a rejtélyes-misztikus-homályos problémákkal találkozzon, mint az, aki annyira bölcs, hogy eleve Apache-on fejlesszen/teszteljen. Tehát akkor nyugodtan vehetem magamra is. Meg a cikk írója is. Meg még páran mások is. De megelőlegezem neked azt a jóindulatot, hogy nem veszem szó szerint. -
#2897
Sk8erPeter
nagyúr
Karma
#2896
Sk8erPeter
nagyúr
OK, belátom, igazad van, amúgy az a vicces, hogy idéztelek, de a "portable" szóra nem figyeltem, ami pedig nem mindegy
- mert a XAMPP nálam már néha kiveri a biztosítékot, ha Windows-ról van szó. Pedig én is azzal kezdtem, szerintem ASP.NET-ezés miatt raktam fel először az IIS-t, és csak azután láttam, hogy mekkora baromság Windows-on XAMPP-ot használni, ergo Apache-ot, amikor ott van egy kellemes grafikus felületű webszerver is, aminek a konfigurálásához nem kell konfigfájlokat buzerálni (pedig Apache esetében sajnos van tapasztalatom vele, próbálom törölni az emlékeket).
Viszont abban teljesen igazad van, hogy ha valakinek csak átmenetileg kell, aztán többet úgyse használja, akkor a portable webszerver a megoldás.
Habár ha a kérdező úgyis foglalkozik webfejlesztéssel, szerintem megéri felrakni egy normális webszervert. -
#2895
Sk8erPeter
nagyúr
r4z
#2889
Sk8erPeter
nagyúr
"Így néz ki az XML"
Ha így néz ki az XML, akkor az invalid XML, mivel nincs gyökérelem.Szerk.: ja, látom közben belinkelted a valódi XML-t, az nem hibás, gondolom csak példa gyanánt írtad a korábbit, hibásan.
-
#2894
Sk8erPeter
nagyúr
Karma
#2891
Sk8erPeter
nagyúr
"de egy portable XAMPP-t összelőni se nagy wasistdas"
Jaj ne, megint a Linuxos környezet Windows-ra erőltetése.
Pont erről ment a témázás a másik topicban. -
#2883
Sk8erPeter
nagyúr
trisztan94
#2877
Sk8erPeter
nagyúr
válasz
trisztan94
#2877
üzenetére
Itt is kértem tök normálisan, hogy rakj fel légyszi egy működő példát valahova, amibe bele tudunk mászni, és egy pillanat alatt kijavítani a hibát, akkor leszartad, és még csak válaszra sem méltattál, ennek ellenére most is azt fogom kérni, hogy rakj fel valami működő példát valahova, továbbra is ez a biztos haladás kulcsa...
-
#2860
Sk8erPeter
nagyúr
csabyka666
#2859
Sk8erPeter
nagyúr
válasz
csabyka666
#2859
üzenetére
"Egyelőre nem mélyedtem bele, de pár szóban mondjátok el nekem, hogy is működik ez a "window.location.replace("http://stackoverflow.com");" Hova kell tenni a weblapon belül? <style> </style> tagok közé?"
Őő, nem. Bocs, de ezt azért ki lehet guglizni olyan 10 másodperc alatt.
Itt már leírtam az én elképzelésemet, ott a scrollTo-s megoldást lecserélheted arra, hogy simán window.location.href-et vagy window.location.replace()-t használsz, a megfelelő anchorral (#valamidiv). -
#2856
Sk8erPeter
nagyúr
csabyka666
#2855
Sk8erPeter
nagyúr
válasz
csabyka666
#2855
üzenetére
A lényeg az, hogy az adott oldalt egyértelműen azonosító címet mentsd le (ahol pl. a query stringből vagy máshogy egyértelműen beazonosítható, hogy melyik aloldalra lépett a felhasználó), aztán szerintem azt is lementhetnéd, hogy melyik divhez kell ugrani (melyiket állította be a felhasználó - ha jól értettem, ez a koncepció; ne felejtsd, a cookie-ban összetettebb adatstruktúrát is lehet tárolni, pl. objektumot!!). Az oldal betöltődését követően pedig csekkold (JavaScripttel természetesen), hogy van-e már beállítva az adott oldalra vonatkozó, cookie-ban tárolt adat, HA igen, akkor ellenőrizd, hogy ezenbelül melyik div lett beállítva (amihez ugrani kell), és utána pl. jQuery.ScrollTo-val görgess oda a divhez. Ha nem akarsz plugint használni, itt egy másik lehetőség: [link].
Ha még nem tiszta a dolog, kérdezz.
-
#2852
Sk8erPeter
nagyúr
trisztan94
#2851
Sk8erPeter
nagyúr
válasz
trisztan94
#2851
üzenetére
fel tudnál rakni ebből pls egy módosítgatható változatot jsFiddle-re? Próbálgatnám másképpen, de így nem tudom módosítani.
-
#2850
Sk8erPeter
nagyúr
trisztan94
#2849
Sk8erPeter
nagyúr
válasz
trisztan94
#2849
üzenetére
"Létezik arra egy plugin, amivel könnyen lehet elemek sorrendjét módosítani?"
jQuery UI Sortable?(#2848) :
Ha 'keypress keydown keyup'-ot kicseréled csak 'keyup'-ra, akkor mi a pálya? Egyelőre csak tippelek, próbát megér. -
#2836
Sk8erPeter
nagyúr
trisztan94
#2835
Sk8erPeter
nagyúr
válasz
trisztan94
#2835
üzenetére
Erre írtam, hogy sztem csúf:
var waypointCounter = 2;
$('.btn-add-waypoint').click(function() {
waypointCounter++;
$('.last-waypoint')
.after('<div class="form-group waypoint last-waypoint"><label for="waypoints" class="col-md-1 control-label">'+ waypointCounter +'.</label><div class="col-md-11"><input type="text" name="waypoints[]" class="form-control" placeholder="Érkezési hely" /></div></div>')
.removeClass('last-waypoint')
.children('label')
.html(waypointCounter-1 + ".")
.parent()
.children('div')
.children('input')
.attr('placeholder', 'Megálló ' + (waypointCounter-2));
});Simán túlélhető ez a kód, de szerintem ez esetben ez a láncolás csak rontja mind a kód követhetőségét, mind a bejárhatóságot (persze megközelítés kérdése); meg általában komplett összeállított HTML-kód bedrótozása JS-kódba nem egy túl szép megoldás.
"de most így hirtelen annyi jut eszembe, hogy az after() tartalmát egy JSON fájlban tárolom, azt rakom bele. Vagy XML, de a JSON-t jobban szeretem, meg sokkal JS-barátabb is."
Nem értem, ez mire lenne jó. Attól nem lesz szebb a megoldásod, hogy még egy JSON-fájlba (vagy akármilyen másba) is kierőszakolod a tartalmat, aztán még azt az overheadet is ráteszed az egész feladatra, hogy a JSON-t parse-olni is kelljen (egyáltalán nem elhanyagolható, főleg, ha tök felesleges), ami után már használhatod a kódot...
Szóval rossz ötlet."A .waypoint elemek növelését alapvetően úgy csinálnám, hogy egy ciklusba raknám az egészet, ami a waypointCounter értékéig megy, az első és utolsó elem distinct ("különböző"?), a többi csak megálló. Biztos van jobb megoldás, de most hirtelen ez pattant ki a fejemből. (tehát így az előbbi JSON mókázás sem kellene)"
Ezt nem is értem, mit akarsz megoldani ciklussal. Amikor egyenként kell hozzáadni a DOM-hoz lényegében majdnem minden tulajdonságukban egyező elemeket, akkor hogy jön ide a ciklus?Több megoldás is létezhetne rá, template-szerű megoldás, egy adott, DOM-ban már bent lévő elem klónozása, majd egyes attribútumainak módosítgatása, vagy ha bedrótozás, akkor úgy, hogy az egyes elemek legyenek különszedve, jQuery-szintaktikával létrehozva (pl.
$( "<div/>", {
"class": "test asdasd bla"
});
), aztán egyberakva.Amúgy formelemek klónozására ez elég jó:
http://www.mdelrosso.com/sheepit/index.php?lng=en_GB&
Persze jelen esetben nálad nem valószínű, hogy szükséges (14 KB amúgy), csak eszembe jutott. -
#2834
Sk8erPeter
nagyúr
trisztan94
#2831
Sk8erPeter
nagyúr
válasz
trisztan94
#2831
üzenetére
Szegény haverod mit vétett, hogy ilyen brutális kóddal bünteted őt
-
#2828
Sk8erPeter
nagyúr
trisztan94
#2827
Sk8erPeter
nagyúr
válasz
trisztan94
#2827
üzenetére
Ezzel most egyetértek. Pedig tudod, hogy az nem sokszor fordul elő!
-
#2824
Sk8erPeter
nagyúr
martonx
#2823
Sk8erPeter
nagyúr
válasz
martonx
#2823
üzenetére
És ezzel amúgy mi a gáz? Mármint ott van az $('#extruderLeft').openMbExtruder(true);, meg az $('#extruderLeft').closeMbExtruder(); ha azt egy .hover()-be berakod, az miért nem jóféle?
Például egy
$("#extruderLeft").hover(
function() {
$( this ).openMbExtruder(true);
}, function() {
$( this ).closeMbExtruder();
}
);
a belinkelt oldalon tök jól működik, az nem jó? -
#2822
Sk8erPeter
nagyúr
ravenwood
#2821
Sk8erPeter
nagyúr
válasz
ravenwood
#2821
üzenetére
Akkor még egy "illemszabály": 5 percen belül tudod szerkeszteni a hozzászólásodat, ha totálisan ahhoz kapcsolódik, amit írsz, akkor abba az eredeti hsz.-be írd bele. (Ha ettől tök független, NEM 1-2 szavas válasz valaki másnak mondjuk, akkor szerintem nyugodtan mehet egyébként külön hsz.-be, csak ne ilyen párszavas legyen, mint amit külön írtál.
)PHP topicban egyébként reagáltam neked normálisan, de arra meg nem válaszoltál...
-
#2814
Sk8erPeter
nagyúr
martonx
#2813
Sk8erPeter
nagyúr
válasz
martonx
#2813
üzenetére
Nekem nem kell mentegetőznöd a PHP-fika miatt, tudod, hogy egyetértek, még ha programozgatok is benne, ezt már priviben sokszor átrágtuk
Viszont a magyarázatot most sem igazán értem, ahogy valaki a .htaccess-fájlba belenyúlkálhat, és ez alapvetően elronthatja a webalkalmazás működését, pont úgy belenyúlhat valaki a web.config fájlba is, és azzal is szép dolgokat (pl. átírási szabályokkal hülyeségeket) lehet művelni. -
#2812
Sk8erPeter
nagyúr
martonx
#2811
Sk8erPeter
nagyúr
válasz
martonx
#2811
üzenetére
Mondjuk hogy valaki hülye volt, arról nem a PHP tehet...
Ha valaki ASP.NET-ben programozgat, önmagában az nem óvja meg attól, hogy hülye legyen.
Még ha egyet is értek a PHP-val szembeni kritikus hozzáállással.(#2809) Siriusb :
Szerintem jobb lenne inkább az összefoglalót valóban hasznos linkekkel tömködni, ami bárkinek jól jöhet.
Amúgy a JavaScriptre sem igaz, hogy csak kliensoldali nyelv, mert szerveroldali programozásra is alkalmas.
Az alapok tisztázásához amúgy az is jó lehet, ha megosztunk egy olyan linket, ahol mindezek jól (helyesen, áttekinthetően, nem összezavarva a kezdő olvasót) össze vannak foglalva. Nem tudom, hol található ilyen.(#2810) GG888 :
Csak megkérdezte a modi, nincs-e kedve valakinek írni, nem rászólás volt. Amúgy meg ilyen teljesen általános topicban felmerül a kérdés, hogy mégis miről lehetne írni összefoglalót, mert önmagában az, hogy "weblapkészítés" (egy szó (!), ellentétben azzal, ahogyan a témát sikerült elnevezni), túl tág témakör, annyi mindent felölel.
De ha neked (vagy másnak) vannak elképzeléseid, elkezdheted, aztán max. közös erővel korrigáljuk. Pl. van ehhez Próba topic is, ahova lehet írni egy teszthozzászólást, aztán belinkelni, azt korrigálgatnánk, majd a véglegeset megkérnénk egy moditól, hogy rakja már bele az összefoglalóba.
Igazából ehhez a topichoz is el lehetne készíteni egy összefoglalót, belepakolva hasznos linkeket, amit aztán folyamatosan bővítgetünk. Ötletek jöhetnek!"Mondjuk nálam csökkenőbe vannak a hsz-ek, úgyhogy lehet már el is készült, ha így történt akkor ezúton is elnézést."
Az igazából teljesen mindegy, milyen sorrendben vannak a hsz.-eid, az összefoglaló (mint pl. ez, ami amúgy tartalmaz hibákat, pl. a jQuery nem keretrendszer, hanem könyvtár) mindig a topic tetején látszik, levágott, a teljes tartalomhoz lenyitható formában (ld. pl. ha ezt nyitod meg, mindig ott látszik fölül az összefoglaló). -
#2807
Sk8erPeter
nagyúr
trisztan94
#2806
Sk8erPeter
nagyúr
válasz
trisztan94
#2806
üzenetére
Uhh, az kemény, ez akkor elég egyértelművé teszi, érdemes-e azzal az emberrel együtt dolgozni
-
#2802
Sk8erPeter
nagyúr
whYz
#2801
Sk8erPeter
nagyúr
A böngészőkben futkorászó, megtekinthető kóddal rendelkező kliensoldali JavaScript-kódoknak SEMMI köze a biztonsághoz, ez nagy általánosságban kijelenthető, és ezt így legalább könnyű megjegyezni, hogy ez a fejekbe verődjön.
A böngésződben bármikor kikapcsolhatod a JavaScriptet, és így máris lőttek a JavaScript-alapú validációnak, erre tehát nem szabad alapozni.
MINDIG a szerveroldali validációt kell először megírni, azt agyontesztelgetni, pesszimistán hozzáállva a felhasználótól érkező adatokhoz, a kliensoldali validáció csak ezután következik, az már csak egy szépítés, egy kiegészítés (természetesen úgy, hogy ez lesz az első szűrő), aminek a célja a felesleges hálózati forgalom (kliens-szerver kommunikáció) elkerülése (értsd: minek küldjem el a szerver felé a hibás adatokat, ha már lehetett volna azokat ellenőrizni egy korábbi fázisban is, mint első szűrő), valamint a validáció felhasználóbarátabbá tétele (ennek része az is, hogy eleve gyorsabb az ellenőrzés, mivel nem igényel szerverrel való kommunikációt; aztán további része az, hogy törekszünk valami igényes hibajelzésre)."Erdemesebb inkabb json+php komboval megirni, nem?"
Nemcsak PHP létezik, mint szerveroldali nyelv. A lényeg a megfelelő szerveroldali validáció, a nyelv teljesen mindegy. Na meg nemcsak JSON-formátumban lehet fogadni az adatokat. Ettől függetlenül a JSON egy nagyon könnyen és kényelmesen kezelhető formátum, széleskörű támogatottsággal (épp ezért olyan népszerű). -
#2798
Sk8erPeter
nagyúr
stigma
#2792
Sk8erPeter
nagyúr
Megnéztem a priviben linkelt jsFiddle-példádat, és az volt a gond, hogy a rules : {...} -on belülre raktad a messages: {...} részt is, pedig annak attól függetlenül kell szerepelnie az objektumon belül. (Az eredeti mintakódodban ez nem így volt.
)
Amúgy itt vannak a magyar szövegek, a {0} és {1} jellegű placeholderek működnek:
http://ajax.aspnetcdn.com/ajax/jquery.validate/1.11.1/localization/messages_hu.jsTehát a megfelelő megoldás (az input type-ot Te eredetileg helyesen írtad, number az jó (mivel HTML5), most csak azért változtattam text-re, hogy ki lehessen próbálni a validálást más formátumra is HTML5-öt támogató böngészőben is, pl. ha szöveget írok be; a "range" validálóüzenete amúgy nem tudom, hol jön elő, de a lényeg szempontjából most mellékes):
-
#2797
Sk8erPeter
nagyúr
stigma
#2796
Sk8erPeter
nagyúr
-
#2795
Sk8erPeter
nagyúr
stigma
#2794
Sk8erPeter
nagyúr
Amúgy csak most nézem, hogy egyik helyen product_weight-et írtál, másik helyen már product_height-et, mármint utóbbinak határoztad csak meg a messages attribútumában a magyar nyelvű szöveget. Ezt a valódi kódban jól használod? Tehát product_weight-nek is megadtál magyar szöveget külön a messages-en belül, csak itt, a példakódodban maradt le?
(másik kulcs, pass vs. userpass... 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
"
És mi nem tetszik rajta neki? 
) 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"... 
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... 
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 
Ő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:
Új hozzászólás Aktív témák
- Einhell akkumulátoros fűnyíró eladó!
- Bomba ár! Panasonic CF-20-2 Tab+Laptop: i5-7G I 8GB I 256SSD I 10,1" WUXGA Touch I Cam I W11 I Gar
- Bomba ár! Lenovo ThinkPad L13 G2 - i5-11G I 16GB I 256SSD I 13,3" FHD I Cam I W11 I Garancia!
- Bomba ár! Lenovo ThinkPad E15 G2 - i7-11G I 8-16GB I 512SSD I 15,6" FHD I Cam I W11 I Garancia!
- Bomba ár! Lenovo ThinkBook 15 G2 - i5-11G I 16GB I 256SSD I 15,6" FHD I Cam I W11 I Garancia!
- Apple iPhone 15 Pro 128GB,Újszerű,Dobozaval,12 hónap garanciával
- MikroTik / hálózati eszközök több típus, készletről
- iKing.Hu - Használt, karcmentes Google Pixel 9 Pro Fold Obsidian színben, 256 GB tárhellyel, 6 hónap
- Telefon felvásárlás!! Honor Magic6 Lite, Honor Magic6 Pro, Honor Magic7 Lite, Honor Magic7 Pro
- BESZÁMÍTÁS! Asus ROG Strix B450F R5 5600 32GB DDR4 512GB SSD RTX 2070 Super 8GB Zalman S2 TG TT 650W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest