- Milyen okostelefont vegyek?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Mobil flották
- Android alkalmazások - szoftver kibeszélő topik
- Google Pixel 8a - kis telefon kis késéssel
- Huawei P30 Pro - teletalálat
- Samsung Galaxy Watch7 - kötelező kör
- Google Pixel topik
- Karaktere biztos lesz az első Nothing fejhallgatónak
- iPhone topik
-
Mobilarena
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
Mr Dini #6163 üzenetére
Ha ahhoz is lusta vagy, hogy a böngészőben kipróbáld némi kiegészítésekkel, akkor miért nem vagy lusta megkérdezni itt a fórumon? SOKKAL tovább tart az egész hozzászólást megírni, mint kipróbálni azt a nyomorék kódot.
Csak saját okulásod céljára kérlek nyomj egy Ctrl+Shift+I-t, kattints a Console tabra, majd dobd be ezt a pici kódot:var storagesArray = ['https://drive.google.com', 'https://dropbox.com'];
var storagesAsString = '';
var i = 0;
for(i = 0; i < storagesArray.length; i++){
storagesAsString += (i + 1) + '.: ' + storagesArray[i] + '\n';
}
alert(storagesAsString);Jé, nahát, működik, gondolom csodát láttál.
Ilyen nagy erőfeszítésekre gondoltam, amikkel akár egyből ki is próbálhatod, mi a búbánattól vérzik el a kódod. Amíg nem tanulsz meg rájönni a saját kódod hibáira, addig programozni sem fogsz megtanulni soha. Mindig mástól várni a segítséget megint csak nem jó út.Ha meg a 0. indexen lévő elemet nem szeretnéd kiíratni, akkor igazítsd hozzá a kódot:
var storagesArray = ['EZ NEM KELL', 'https://drive.google.com', 'https://dropbox.com'];
var storagesAsString = '';
var i = 1;
for(i = 1; i < storagesArray.length; i++){
storagesAsString += i + '.: ' + storagesArray[i] + '\n';
}
alert(storagesAsString); -
Sk8erPeter
nagyúr
válasz
Mr Dini #6155 üzenetére
Az ilyen halál egyszerű kódrészleteket egyébként nyugodtan kipróbálhatnád a fejlesztői panelben is, úgy, hogy bedobod a konzolba, csak alakítsd át egy picit úgy, hogy tesztelhető is legyen. Nyomsz egy Ctrl+Shift+I-t (vagy F12-t), rányomsz a Console fülre, majd bedobod a kódodat. Vagy erre van a jsFiddle, csak akkor is nyisd le a konzolt, hogy lásd az esetleges hibákat, amiket oda dobál ki. Meg hát nyilván ennél kicsit szofisztikáltabb módszerek is léteznek, például valami komolyan vehető fejlesztőkörnyezet használata, JSHint, JSLint, meg egyéb módszerek, amik hozzájárulhatnak a kódod minőségének javításához.
Amúgy igen, inicializálni kell a változódat, mielőtt a nemlétező korábbi értékéhez akarsz hozzáfűzögetni bármit, és ha nem akarsz "Uncaught ReferenceError: <VALAMIVALTOZO> is not defined" jellegű hibákat kapni. Például ezeket a hibákat azonnal láttad volna, ha a konzolba dobálnád be a kódot, vagy abban a környezetben, aminél használod a kódot, kihasználnád a rendelkezésre álló, hasonló jellegű hibakeresési módszereket.
Ezenkívül JavaScriptben nem szokás a változókat nagy kezdőbetűkkel írni.
Plusz ha alert-üzenetbe akarod mindezt kiírni, akkor valami nem stimmel, valószínűleg lenne ennél szebb megoldás (az alert-dialógus elég bénácska és korlátozott, persze tesztelésnek néha elmegy (ha nagyon muszáj), ha nem tudsz épp debuggolni, plusz nem felel meg a console.log, stb.). -
Sk8erPeter
nagyúr
fordfairlane-nel értek egyet, ezek a kulcsszavak egy kezdőt szerintem is inkább elrettentenek, mint kedvcsinálónak számítanak, elkezd ezekre guglizni, és akkora zsongás lesz a fejében (mondjuk már eleve a kulcsszavaktól is), hogy lehet, hogy azt fogja érezni, hogy ezt inkább hagyjuk (jó, mondjuk egy komoly elhivatottság eleve kell a minőségi programozáshoz). Az általad felsoroltak közül van olyan, amikről nekem is csak felületes tudásom van, már ha annak nevezhető, igaz, most épp nem a webfejlesztés van terítéken esetemben, hanem csak hobbi, de azért le tudok ülni megoldani egy JavaScriptes feladatot, gondolom azért ez csak lejött.
Először tényleg angolul kell megtanulnia (ezt Te is írtad), aztán programozói alapszemléletet elsajátítani (nem biztos, hogy JavaScripten keresztül kellene, de fogalmam sincs, mi a leginkább működő módszer, pl. a C nyelv kezdésnek kissé erős lehet, mégis pl. BME-n ezt nyomatják elsőre), majd tök alapvető dolgokkal megismerkedni a JavaScripten belül - pl. épp azt, hogy mi is az a DOM, milyen módon tudja alapszinten manipulálni a HTML-elemeket, stb. Eleinte nem szükséges minden olyan ismeret, ami a pár-/sokéves tapasztalatból neked kapásból előugrik. Legyen némi sikerélménye, amiből tovább építkezhet (ami azt hiszem, nagyon fontos ahhoz, hogy legyen kedve folytatni). Amikor kezdő voltam programozásból, én is azt éreztem, hogy a haladók vagy profik ritkán tudnak csak visszaemlékezni (vagy nem is akarnak) arra, hogy ők honnan is kezdték. Érted, ha elkezdesz tanulni angolul, akkor sem a past perfect continous-zal kezded.
-
Sk8erPeter
nagyúr
válasz
Mr Dini #6087 üzenetére
A smiley kivágására szolgáló reguláris kifejezés így nem jó, túl megengedő, és érthető, hogy kivágja a többi részt is. Le kell szűkítened olyan módon, hogy ténylegesen csak a smiley-kra illeszkedjen, és konkrétan azt a részt szedd ki, ami neked kell, tehát ami az
alt
attribútumnál meg van adva.Itt van egy példa a smiley-kra szolgáló képre:
<img src="/dl/s/d1.gif" alt=":D">
Ebből neked értelemszerűen az
alt
attribútum értékének megadott:D
kell, idáig Te is eljutottál.Itt egy példa egy jól működő replace-re:
var emoticonImg = '<img src="/dl/s/d1.gif" alt=":D">';
var emoticonText = emoticonImg.replace(/<img src="\/dl\/s\/[^"]+\.gif" alt="([^"]+)">/, "$1");
console.log(emoticonText); // output: :DEzt a reguláris kifejezést persze el kell látnod a megfelelő flagekkel, hogy jól működjön, itt leszűkítettem a lényegre.
Szerk.: a reguláris kifejezésben szereplő
[^"]+
azt jelenti, hogy itt egy vagy több olyan karakternek kell szerepelnie, amely nem egyezik az idézőjellel ("). -
Sk8erPeter
nagyúr
válasz
fordfairlane #6066 üzenetére
Ez sztem elég egyértelmű.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #6041 üzenetére
Azért szerintem jelenleg még igen nagy túlzás, hogy a jQuery felett "eljárt a kor".
Egyszerűen még nem tartunk ott, bármennyire is menő lenne, a jQuery-nek az egyik lényege továbbra is megmaradt, vagyis röviden leírni mindazt, amit amúgy hosszabban, de amúgy tényleg megoldhatsz plain JavaScripttel. (A másik lényege persze a cross-browserség megteremtése, de most ettől tekintsünk el, mert nem érdekes a téma szempontjából.) Szerintem igaza van fordfairlane-nek akkor, amikor azt állítja, hogy ezen vacogni felesleges premature optimization. Ahogy haladunk előre, a középkategóriás (vagy akár még az olcsóbb) okostelók is egyre komolyabban vehető processzorokkal vannak felszerelve, úgyhogy szerintem kezd csökkenni a súlya annak is, hogy mobilon mennyire érezhető a jQuery-nélküliség (vagy sem).
Az általad linkelt oldal egy-két példája is mutatja, hogy azért kódszépség tekintetében vannak még mindig bőven különbségek egy rövidebb, beszédesebb kód és egy szószátyárabb, de menőbb (hiszen plain JS) kód között. Meg ott a ZeptoJS és társai, amik az alapvető funkcionalitást tartalmazzák, az is megfontolható lehet, ha a jQuery súlya fájdalmas.
Pont nemrég került elő, hogy korábban írtam saját célokra egy böngészőbővítményt, aminek annak idején az összes kódját plain JS-ben pötyögtem, mert nagyon menőnek éreztem akkor, hogy így minden sallangtól mentes lesz, de 1-2 hete némi agypihentetésnek egy részét átírtam inkább jQuery-re, mert egyszerűen zavart, hogy mindent olyan szószátyár módon kell leírnom.A kód karbantartását is nehézkesebbnek találtam, pedig nincs gondom a JS ismeretével ilyen szinten.
martonx foglalta össze röviden, hogy nyelvi szinten lenne elvárható némi rövidítés és funkcionalitás-bővítés, mert remek, hogy jönnek az új nyelvi feature-ök, de amíg frontenden legalábbis (!) így is library-re szorul az ember a szebb, tömörebb kód érdekében, addig nem okoz akkora felhőtlen örömöt, hogy ezeket is kézhez kapjuk. -
Sk8erPeter
nagyúr
válasz
Speeedfire #5979 üzenetére
Egyszerűbbnek biztos nem egyszerűbb, mivel így még a fejlesztőkörnyezet autocomplete-je és refaktorálási képességei sem használhatóak ki, ráadásul még hibalehetőséget is visz a kódba, szóval igazából minden szempontból rosszabb, mint ha ezeket a stringeket EGYSZER eltárolnád egy konstansba, aztán onnantól kezdve azokat használnád.
Pl. itt mennyivel értelmesebb és szebb lenne úgy használni a kódban, hogy helperTypes.gun vagy helperTypes.health, mint odahákolni minden alkalommal egy stringet a switch-ekbe. Vagy ha ragaszkodsz az indexeléshez, akkor magukat az indexeket is lehetne tárolni, és pl. helperTypes[GUN] módon felhasználni. De te tudod. -
Sk8erPeter
nagyúr
válasz
Speeedfire #5977 üzenetére
Mármint úgy érted, másnak a kódja, amibe nem nyúlhatsz bele? Vagy csak mert csak, jó az vidékre?
-
Sk8erPeter
nagyúr
válasz
Speeedfire #5969 üzenetére
Azt még azért mindenképp szépíteni kellene a kódon, hogy ne stringek legyenek ilyen esetben a switch-ben, meg a helperTypes tömbben sem, hanem konstansok (mármint most ez nem keverendő a string konstansokkal, sszóval érted
), hiszen ha mindenhol stringeket használsz fel, az törékennyé teszi a kódot. (Pl. ha később rájössz, hogy azt nem "healt"-nek, hanem "health"-nek kellene írni, és egyik helyen így használod, másik helyen úgy.
)
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5929 üzenetére
Ez így elég csúnya, picit zsongott az agyam a kód olvasása közben.
Itt ráadásul a for...in ciklusnak nincs is haszna, sőt.
A getStartTime metódusnévből ráadásul nem érthető, hogy most igazából a szabad órák kezdőidejét szeretnéd lekérni.
Érdemes egyébként néha a sok-sok indexelés több helyen történő használata helyett inkább a ciklusmag elején eltárolni változóba az aktuális értéket, vagy akkor belül is for...in-t használni.
És ezenkívül szebb lenne, ha objektumként passzolnád át tömb helyett, hogy mondjuk egy startTime és nextTime lekérdezhető legyen így attribútumnév szerint (és nem kellene agyonindexelgetni a tömböket).Számomra ez jóval olvashatóbb, persze még ezen is lehetne szépíteni, most 5 percből ennyire futotta:
https://jsfiddle.net/d1jntk9a/1/Szerk.: ja, most nézem, a freehours-nál is asszem többszörösen egymásba ágyazott tömböt szerettél volna, ennek a további indexelése lemaradt, mindegy, a lényeg végül is érthető.
-
Sk8erPeter
nagyúr
"De ezt a mondatot neked írtam és nem neki"
Nem is nekem írtad.Szerintem mindketten értjük, mi a pálya, egyszerűbb, ha itt áll mindhárom változat, amiről beszéltünk, és akkor a kezdő is remélhetőleg megérti/megérzi a különbséget:
1:
var numbersArray = [1,2,3,4,5,6,7,8,9];
var evenNumbers = [];
for(var i = 0; i < numbersArray.length; i++) {
if(numbersArray[i] % 2 == 0) {
evenNumbers.push(numbersArray[i]);
}
}
console.log("Even numbers: ", evenNumbers);2:
var numbersArray = [1,2,3,4,5,6,7,8,9];
var evenNumbers = numbersArray.filter(function(num) {
return num % 2 === 0;
})
console.log("Even numbers: ", evenNumbers);3:
var numbersArray = [1,2,3,4,5,6,7,8,9];
var evenNumbers = numbersArray.filter(num => num % 2 === 0);
console.log("Even numbers: ", evenNumbers);(#5940) zuzu000:
"Egy Javascriptes metódust szeretnék implementálni C#-ba"
Ez a mondat így ebben a formában nem biztos, hogy értelmes...(#5937) Aureal:
Mi a cél vele amúgy? -
Sk8erPeter
nagyúr
Igen, szerintem ne egy filter és egy fat arrow megértésével kezdje valaki, amíg gondot okoz neki, hogy kigyűjtse egy tömbből a páros számokat, tehát még nem tiszta számára, hogy mit jelent egy for/while ciklus. Kezdőként Te sem syntactic sugart raktál a kávédba hagyományos cukor helyett.
Gondolj bele, mit fog fel egy kezdő abból, ha azt írod neki, hogy "Ezt fat arrow-nak hívják ami egy rövidebb syntactic sugar a function expressiönök helyett és lexikálisan bindolja a this-t, kvázi block scoping."
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Végigmész a tömb elemein, egyenként megvizsgálod őket, és ha az adott szám páros, akkor belerakod az elemet egy új tömbbe. Jobbat nem tudsz, ilyenkor muszáj végigiterálni a tömb összes elemén, különben honnan tudnád, melyik a páros?
A Jim-Y által említett módszer is pont ezt csinálja, csak ez egy rövidebben leírható módszer ugyanarra, amit írtam. (Azt nem tudom, van-e érdemi sebességbeli előny vagy hátrány a hagyományos for ciklushoz és tömbbe pakolós módszerhez képest.) -
Sk8erPeter
nagyúr
Tudom, azért is írtam, hogy nem neked szólt.
Mondjuk ha már portable, ilyen tök egyszerű célokra jó az USBWebserver is.
Amúgy igazad van, hogy lightweightebb mindenképp bármilyen portable cuccos, de állandó, gyakran használt webszervernek Windows-on szerintem picit túl van erőltetve az Apache, miközben az IIS az én tapasztalataim szerint legalábbis jobban képes teljesíteni. Persze a szempont az szokott lenni, hogy legyen akkor már ugyanaz a környezet ilyen szempontból az, ami a céloldalon is van, de ha az alapvető rendszergazdai jellegű beállítások már stimmelnek itt is, ott is (nincs gond magával a kiszolgálással), akkor kevesebbszer szokott előjönni ez a probléma, mint a gondok inkább magával a webalkalmazással. -
Sk8erPeter
nagyúr
válasz
Mr Dini #5875 üzenetére
"Azt szeretném, hogy addig fusson a for loopba, amíg az i értéke I-vel megegyezik."
És ki fogja átállítani azt a mágikus globális I változót?
Igazából egyébként ez a kódrészlet és a feladatspecifikáció teljesen érthetetlen:
"A feladata az, h kiírja a listFiles tartalmát, levágja splittel a sortöréseknél (azaz a következő fájl nevénél) és generál egy random számot, amit utánatesz az 'i' mögé kapcsoszárójelek közt. Azaz a split miatt így tudok hivatkozni a tömbösített változóra. Na szóval értitek..."
Nem, nem értjük.Először a splittel készítesz egy tömböt, ez lesz az i változó. Itt gyorsan hozzátenném, hogy leszokhatnál az ilyen teljesen értelmetlen nevű változókról, inkább legyen egy mondatnyi hosszúságú változót, mint egy ilyen értelmetlen fos. Mit jelent az, hogy a tömb után akarsz teni valamit kapcsos zárójelek közt? Úgy érted, hogy a tömb összes stringeleme mögé akarsz fűzni valamit? A tömbbe akarsz bedobni egy újabb változót? Vagy mi a célod?
Mert itt a ciklusok, meg az egész kód ennek fényében tök értelmetlennek tűnik. -
Sk8erPeter
nagyúr
"ha van egy jól bekonfigurált szervered (az XAMPP ilyet ad)"
Az IIS is ilyet ad.A Microsoft Web Platform Installer segítségével ráadásul pár next-next klatty után ez is pont ugyanolyan felhasználóbarát módon telepíthető, mint a többi kapcsolódó termék. (Pl. rákattint az ember, hogy telepíteni akarja a Drupalt/WordPresst (amit aztán leszedhet), és ez behúzza a függőségeket.) Igazából nem is vágom, miért nem marketingeli ezt kicsit jobban a májkroszoft.
Amire figyelni kell, hogy .htaccess helyett Web.config fájl kell, megfelelő alternatív tagekkel...
(Ezeket Te nyilván tudod, nem is neked szól, inkább a kollégának, meg általánosságban.) -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5868 üzenetére
Hát tényleg nem éri meg a szenvedést, ha már más megtette helyetted, ezért érdemes használni ilyeneket, mint a Chosen, meg hasonlók.
(#5867) Cathfaern:
Jaja, ez nekem is furcsa, hogy az ilyen alapvető elemek kinézetét még olyan módon sem lehet felülbírálni, hogy mondjuk az optionnél a kijelölés színe ne kék legyen. Feltételezem, hogy egyébként a többi részét (mint a file inputot mondjuk) azért nem lehet túlzottan felülbírálni, hogy viszonylag konzisztens legyen a kinézet a böngészőben minden oldalon, és mindig rá lehessen ismerni ezekre az elemekre, de mivel szinte mindenre van workaround, ezért ez a magyarázat sem túl kielégítő. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5865 üzenetére
Úgy tudom, hogy ezt alapból nem lehet felülbírálni, ezért különálló HTML-elemekre kell "leképezni" a különböző <option>-öket (<div>, <span>, blabla), amiknek már megadhatod nyugodtan a stílusát, csak ezeket szinkronban kell tartani ugye a <select>-<option> elemekkel (hogy a háttérben valójában egy ilyen listából válogass, csak "közvetve"; tehát ha a júzer rákattint az adott divre vagy spanre vagy akármire, akkor kódból válaszd ki a kapcsolódó optiont).
Igazából ezt csinálja a Chosen is, meg a hasonló pluginek. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5863 üzenetére
Ez a Chosen egyébként egy elég fasza plugin, de nem annyira erre való, hanem inkább <select>-<option> párosokra, szóval egy adott listából történő egyszerűbb kiválasztásra. Egy taglista meg nagyon nagy lehet, azt nem akarjuk betölteni egy ilyen struktúrába.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #5860 üzenetére
Viszont most találtam egy plugint, aminél engedélyezettek a többszavas tagek.
http://bootstrap-tagsinput.github.io/bootstrap-tagsinput/examples/Amúgy az előbb linkelt threadben tényleg brutálsok plugin van, szóval lesz miből válogatni.
(#5861) Zedz : Szívesen!
-
Sk8erPeter
nagyúr
válasz
DNReNTi #5857 üzenetére
"pl egy "javascript objects" tag-et hogy hozol létre?
"
Igazából a tagek egyszavasak szoktak lenni.Lásd Stack Overflow (vagy az egész Stack Exchange-família). A szóköz helyett pedig tipikusan kötőjelet használnak (mint ott is).
Egyébként a Space-re kötni a dolgot tényleg nincs értelme, annak van, amit írtál, az Enter-hozzáadós (meg gombra kattintós), meg még a lefelé gomb segítségével lehessen kiválasztani a felajánlott taget.(#5856) Zedz:
Igazából annyi a lényeg, hogy mondjuk legalább 3 karakter begépelése után keyupra kezdj keresgélni az adatbázisban potenciális korábbi lehetőségek után AJAX-szal, ajánld fel a júzernek a potenciális tageket, legyen benne eseménykezelés a fentebb említettekre, a felajánlott tagek elfogadása vagy új létrehozása esetén legyen "egyben", elkülönítve a többitől, egyben lehessen törölni, ahogy Stack Overflow-nál, Space-nél tekintsd úgy, hogy egy tag létrejött (mert egy tag egyszavas), tulajdonképpen ennyi a kliensoldal dolga. Ha a Stack Overflow példáját "lemásolod", az szerintem tök jó, mert az nagyon kényelmes.Jó keresőszavakkal azonnal lehet találni erre is SO-n threadet:
http://stackoverflow.com/questions/519107/jquery-autocomplete-tagging-plug-in-like-stackoverflows-input-tagsSzerk.: heh, most látom a Te hozzászólásodat, hogy pont a Stack Overflow példáját akarod lemásolni, jól teszed.
-
Sk8erPeter
nagyúr
válasz
pckownz #5853 üzenetére
Nagyobb eséllyel meg lenne már oldva a probléma, ha felraktál volna egy jsFiddle-példát, szóval hogy segítséget kapj, saját érdekedben segíts nekünk ennyivel, különben senkinek nem lesz kedve magától összekalapálni egy "tesztkörnyezetet".
(#5843) htc07:
Pedig ennek működnie kell.Akkor valamilyen requestet tilthat a böngésződ (egyik bővítménye), ha a jsFiddle nálad nem üzemel rendesen.
-
Sk8erPeter
nagyúr
BK!
Egy lehetséges megoldás:
https://jsfiddle.net/ud040qh3/ -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
TheProb #5821 üzenetére
Azért, mert így nem írsz felül semmilyen másik, szintén onloadra bekövetkező eseménykezelőt, olyat, amit pl. akár egy másik fájlban határoztál meg (Te vagy akár egy library), hiszen így HOZZÁADSZ egy eseménykezelőt, mint az a nevében benne is van (addEventListener), nem pedig felülvágod az onloadot egy egyenlőségjellel, hogy az lesz az eseménykezelő, és kész, semmi más.
Vegyünk egy nagyon egyszerű példát:
A HTML-struktúrában ez a két fájl van behúzva:...
<script src="testjs-1.js"></script>
<script src="testjs-2.js"></script>
...testjs-1.js tartalma:
window.onload = function() {
alert("asdasd");
}testjs-2.js tartalma:
window.onload = function() {
alert("blabla");
}Ha mindkét fájlban meghatározott eseménykezelő fontos lenne, hogy lefusson a load esemény hatására, hát akkor szomorúan fogjuk tapasztalni, hogy bizony ez nem történik meg, csak a "blabla" felirat fog felpattanni, pedig elvártuk volna, hogy előtte az "asdasd" szöveg is vágódjon a pofánkba.
Most ha átírod így:
testjs-1.js tartalma:
window.addEventListener("load", function(event) {
alert("asdasd");
}, false);testjs-2.js tartalma:
window.addEventListener("load", function(event) {
alert("blabla");
}, false);Akkor innentől kezdve először felugrik az "asdasd", majd a "blabla" feliratú ablak. Pont ezt vártuk el, mindkét eseménykezelő lefutott.
A window.removeEventListener("load", load, false); sor pedig a jsFiddle-re felrakott példában azt jelenti, hogy eltávolítjuk az eseménykezelőt, hiszen ha már egyszer lekezeltük a betöltődés eseményét, akkor teljesen felesleges, hogy rá legyen aggatva egy eseménykezelő, mivel az esemény már bekövetkezett, nem fog többször bekövetkezni.
Még régebben az MDN oldalán láttam, aztán rászoktam a használatára, elméletileg így kevesebb erőforrást eszik a script. Általában egyébként elvileg elég jelentéktelen lehet az ebből adódó különbség, így egy weboldal esetében igazából nem biztos, hogy érdemes vele foglalkozni, hogy ez a sor szerepeljen egyáltalán a kódban, de egyébként alapvetően nem egészséges, ha feleslegesen sok listenert aggatunk fel ide-oda az alkalmazásunkban, ezért spórolok vele, hiszen minden listener azért kér némi erőforrást - így pl. egy böngésző esetén ha sok-sok bővítmény van telepítve, és mindegyik felaggatja a kis listenerjét, majd ott is marad, akkor az már elméletileg számíthat.A többi remélem érthető, kérdezz, ha nem tiszta.
-
Sk8erPeter
nagyúr
válasz
TheProb #5819 üzenetére
Gondolom a tanár elvárása volt, hogy feltétlenül a list itemekre hivatkozzatok (<li>), de egyébként igencsak kretén példa, mert itt bőven elég lenne a mainList azonosítóval rendelkező <ul> elemre beállítani a színt, és kész, ettől öröklődne a szín a gyerekelemekre is, nem kéne végigszaladgálni for ciklussal semmilyen listitem-tömbön minden alkalommal. A document.getElementById(...)-hívások eredményét is illik letárolni, amikor újból és újból hivatkozol ugyanarra az elemre, pont ugyanazok miatt, amit az előbb írtam.
Csak gyors átalakítással: https://jsfiddle.net/76218j80/2/
Szerk.: persze ez így egyébként még csúnya megoldás, mert néhány változó globális scope-ban elérhető, de most ilyen szempontokat elegánsan leszartam. -
Sk8erPeter
nagyúr
válasz
TheProb #5814 üzenetére
- Ahogy dqdb írta, itt pl. a színt előre el lehetne tárolni egy változóban, és azt a változót felhasználni minden alkalommal, mivel itt a cikluson belül nem változtatod, ergo értelmetlen mindig újból és újból összefűzögetni a stringet (mikrooptimalizáció, de az ilyen overheadek szépen egymásra tudnak rakódni, meg amúgy is igénytelenség nem figyelni a mikrooptimalizációra, ugyanígy nem hívogatunk egy metódust többször egymás után, hanem annak a visszatérési értékét is eltároljuk - már amennyiben persze nem változik a visszaadott érték menetközben).
- Stílust nem szép állítgatni JavaScript-oldalról, erről itt volt szó nemrég: [link] (1. bekezdés vonatkozik ide is). Persze kérdés, mi a cél. Ezt itt nem árultad el nekünk, hogy mit szeretnél csinálni, úgyhogy nehéz eldönteni, hogy ez a megoldás így elfogadható-e - pl. lehet olyan, hogy valami üzleti logika van mögötte, és a számított értéket kénytelen az ember JavaScriptben beállítani.
- Mi a cél azzal, hogy az oldalon az ÖSSZES list itemet beszínezed? Amúgy hallgass CSorBA kollégára, a szülőelemnek (<ul> vagy <ol>) add meg a színt egyszer, és kész - persze kivétel az, ha egy-egy elem színét felül szeretnéd bírálni, vagy explicite van bedrótozva a CSS-fájlba a list itemek színe.Na, szóval röviden írd le, mi a célod, és csak akkor tudjuk eldönteni, mi lenne rá a jó megoldás.
-
Sk8erPeter
nagyúr
Hát basszus, most nézem, tök igazad van, én meg tök hülyeségeket beszéltem, elég durván felületesen néztem meg, látszik az aznapi tevékenységemen a 3 óra alvás
.
Mondjuk ettől még tényleg ratyi az a regexp. Eleve furcsa, hogy az <input rész beleírásától miért félt következetesen.
Pl. ez illeszkedik arra az undormány regexpre (a form szigorúan nagybetűvel kezdődjön):
<Form method="POST" action=''><input name="op" value="asdasd" /><input name="id" value="asdasd" /><input name="fname" value="asdasd" /><input name="hash" value="asdasd" />(#5803) w.miki:
Kódminőségben biztos tudnánk szebbet... ha akarnánk.(#5804) TheProb:
Heh, milyen fura, még a HTML5 előtti időkből benne ragadt a fejemben, hogy az id csakis akkor valid, ha BETŰVEL kezdődik, a számmal kezdődőek nem azok - de most nézem, HTML5-től kezdve már sima szám is lehet id - sőt, igazából minden (ha nem üres), ha valóban egyedi és nem tartalmaz whitespace-t.(#5809) trisztan94:
"A programozásban nincs olyan, hogy valami egyszer működik, egyszer nem."
Mi? Hát már hogyne lenne?Olyan szép esetek vannak ilyesmikre, a kedvencem az a fajta hiba, ami debuggolás során nem tapasztalható, csak éles működés során. És erre persze csak elképesztő sok időelkúrás után jössz rá, miután már úgy érzed, hogy végigdebuggoltad az egész világegyetemet, aztán kezdheted vakarni a fejedet, hogy vajon akkor a nem debug módban futás során vajon mi történik, egyszerűen időbeli tényező az oka, vagy netán a többszálú működés alkalmazásodban tapasztalható indeterminizmusa, vagy valami eltérő hardverkörnyezetből előkerülő érdekesség, vagy...vagy...satöbbisatöbbi.
-
Sk8erPeter
nagyúr
Ebben a pluginben katasztrofális hülyeségek is vannak, ahogy elnézem, pl. ez:
var param = showtime.httpReq(path).toString().match(/<Form method="POST" action=''>[\S\s]*?name="op" value="([\S\s]*?)"[\S\s]*?name="id" value="([\S\s]*?)"[\S\s]*?name="fname" value="([\S\s]*?)"[\S\s]*?name="hash" value="([\S\s]*?)"/);
Hát ez nem tudom, milyen reguláris kifejezés akar lenni, ami direkt nem illeszkedik SEMMIRE?
(Legalábbis erre illeszkedő stringet értelmes+hozzáértő ember nem ír le.) Vagy-jel nélkül fordul elő benne többször is adott attribútum, amire vizsgálódni akar (pl. name, value), szóval ez tuti sosem fog illeszkedni semmilyen stringre.
Ezenkívül borzalmasan elavult és gány az egész kód, pl. a <font> tag ezer éve deprecated HTML-ben, JS-ben eval()-t használ, amit nem illik, meg még lehetne sorolni, de a lényeg, hogy spagettikód hatása van az egésznek, szóval nehézkes lesz ezt javítani: a gond az, hogy szerintem most hirtelen nehezen fogsz találni olyat, aki tudja debuggolni neked ezt az éles környezetében, és kideríteni, hogy mi pontosan miért nem működik. Ettől függetlenül ha elmondod, pontosan mikre is lenne még szükséged az indavideón kívül, amit használnál, de nem működik, akkor azt meg tudjuk nézni, és megmondani, mi lehet a gond vele.
-
Sk8erPeter
nagyúr
Jaja, kicsit megváltozott a jsFiddle, amúgy szerintem előnyére, legalábbis nekem jobban bejön, jobb helyen vannak a JS library-k annál a lenyílónál.
Picit tényleg fura ez a Language megnevezés, de végül is ha úgy vesszük, ezek tényleg mintha más nyelvek lennének, más szintaktikát használsz, a JavaScript sajátjánál sokkal értelmesebbet. -
Sk8erPeter
nagyúr
Be van húzva:
De amúgy bocsi, asszem hülyeséget mondtam, és igazad van, JavaScriptre visszaváltva elég a "use strict"; az elejére, és Blink-motorral menni fog ("Uncaught SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode"). Firefoxban még nem ("SyntaxError: let is a reserved identifier"). Mindenesetre ezeket a problémákat áthidalja a Babel.
-
Sk8erPeter
nagyúr
válasz
libamajas #5775 üzenetére
Több hiba is van benne. Egyrészt az a nagy hiba, hogy nem raktad fel nekünk jsFiddle-re, hogy egyből tesztelni tudjuk, másrészt nem használtad a kód kijelölése után itt a fórumon a Programkód gombot, hogy normálisan nézzen ki.
Aztán:
1.
var napok = ["H", "K", "Sz", "Cs, P"];
ez ez akart lenni:
var napok = ["H", "K", "Sz", "Cs", "P"];
(külön a "Cs", "P" stringek)2.
document.write("<div>" + napok + "</div>");
Ennek semmi értelme, mert a napok egy tömb, míg te a tömb cikluson belüli aktuális elemére vagy kíváncsi, ami a napok[i], vagyis az előzőnek a ciklusváltozóval indexelt formája.
Ezenkívül document.write()-ot nem használunk a gyakorlatban. SOHA. Még ha a tanár azt is mondja, akkor sem.Ha a tanár azt mondja, akkor le van maradva. Bár már akkor sem volt értelme, amikor divatos volt használni.
3.
fokok(i)
itt már láthatóan indexelni akartál, csak nem jött össze. Indexelésre a szögletes zárójelet használjuk, tehát így: fokok[i].4.
document.write(<img src='https://cdn0.iconfinder.com/data/icons/good-weather-1/96/weather_icons-68-128.png'>);
Itt az <img ...> részt úgy kezded el, hogy elfelejtetted stringként átadni. Tehát ez így nem lesz jó.
Így jó lenne:
document.write("<img src='https://cdn0.iconfinder.com/data/icons/good-weather-1/96/weather_icons-68-128.png'>");
A feltétel másik részénél ugyanez.Itt láthatsz egy működő változatot:
http://jsfiddle.net/5hvwzquf/=====================================
(#5776) Agostino:
Akkor jó. -
Sk8erPeter
nagyúr
válasz
Des1gnR #5773 üzenetére
Amit Jim-Y írt, az BabelJSben íródott. Mondjuk azt nem igazán értem, minek szopatni ilyesmivel valakit, aki nagy eséllyel nem ért a Babelhez.
Itt van plain JavaScriptben (jQuery sincs behúzva; itt mondjuk direkt leszedtem az onLoadot is, hogy lásd, hogy kell kezelni az ablak betöltődésének eseményét):
http://jsfiddle.net/sm3e5wjz/1/ -
Sk8erPeter
nagyúr
válasz
Agostino #5770 üzenetére
Én túl sokat nem tettem hozzá, inkább Jim-Y-nek köszönd, ő volt az érdemi segítő.
Egyébként nem teljesen értettem, hogy konkrétan mit jelent, hogy "a mootools-more.js egyik sora szerint hibás a dátum (all my wat) a csv-ben", erről nem ártott volna egy PONTOS hibaüzenet vagy screenshot vagy bármi (mondjuk eddig sem voltál túl bőbeszédű, amikor a pontos hibákról érdeklődtünk), mert alapvetően nem illlik egy CMS valamelyik, egyébként nagy eséllyel nem véletlenül behúzott fájlját csak úgy átnevezgetni, hogy hiába keresgélje, ne találja meg - ez nem megoldás, csak átmeneti tüneti kezelés egy hirtelen zavaró problémára, amivel összefügg a fájl behúzása, de ez hosszú távon aztán más problémákat is okozhat.
A $-jelet fő változóként használó library-knél és/vagy frameworköknél felmerülhet egy névütközés, ez pont így van a jQuery-nél és a MooTools-nál is, ezt pl. a jQuery.noConflict(); segítségével lehet feloldani (példák bőven vannak a neten). -
Sk8erPeter
nagyúr
válasz
Agostino #5765 üzenetére
Nézd meg szépen alaposan, amit Jim-Y írt neked. Nyilván csak nem figyeltél oda, hogy mit küldött neked.
Ezek közül minden stimmel?<script src="https://code.highcharts.com/highcharts.js"></script>
<script src="https://code.highcharts.com/highcharts-more.js"></script>
<script src="https://code.highcharts.com/modules/data.js"></script>
<div id="container" style="width: 100%; height: 400px;"> </div>Mindegyik fájlt behúztad? Szerkesztette is a kolléga a hsz.-t, látható, hogy a felsoroltak közül a harmadiktól jött helyre az, ami először nem működött.
ÉS nyilvánvalóan kell a jQuery is.De itt van a komplett kód, amit akár kopipésztelhetsz is magadhoz:
http://jsbin.com/kamobinuju/edit?html,output
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Trying out Highcharts</title>
</head>
<body>
<div id="container" style="width: 100%; height: 400px;"> </div>
<script src="https://code.jquery.com/jquery-2.1.4.js"></script>
<script src="https://code.highcharts.com/highcharts.js"></script>
<script src="https://code.highcharts.com/highcharts-more.js"></script>
<script src="https://code.highcharts.com/modules/data.js"></script>
<script>
$(document).ready(function() {
$.get('https://gist.githubusercontent.com/jim-y/d056bb03e6d3348d6aca/raw/d27bef445c3b38b4254f64f5052133851620ad89/data.csv', function(csv) {
//console.log(csv);
$('#container').highcharts({
chart: {
type: 'column'
},
data: {
csv: csv
},
title: {
text: 'Fruit Consumption'
},
yAxis: {
title: {
text: 'Units'
}
}
});
});
});
</script>
</body>
</html>A Jim-Y által felrakott CSV-fájlban pedig csak ennyi van teszt gyanánt:
Categories,Apples,Pears,Oranges,Bananas
John,8,4,6,5
Jane,3,4,2,3
Joe,86,76,79,77
Janet,3,16,13,15
Ez így egy teljesen szabályos CSV-fájl.
Ha ez sem műxik, akkor tényleg valami gáz van nálad.(#5759) martonx:
"hogy lássuk egyáltalán a hivatalos dokumentációt tudtad-e értelmezni"
Már hogy én? Brühühühhűűűűű.Amúgy csak trollkodom, tudom, hogy nem nekem szólt.
-
Sk8erPeter
nagyúr
válasz
Agostino #5756 üzenetére
"elvi akadálya annak sem volna, hogy a csv menjen, de ott maga a file nem tetszik neki. nem húz be belőle adatot, pedig utf8 wo bom, vessző tagolás stb mint a dokumentáció szerint..."
De megnézted, hogy az AJAX-kommunikáció során milyen hiba keletkezik? Mit jelent, hogy "nem tetszik neki", ezt honnan látod, miből tudod? Kapsz hibaüzenetet? Vagy mi történik? -
Sk8erPeter
nagyúr
Alapvetően annyi a baj azzal, hogy JavaScripttel állítgatod a stílusát egy DOM-elemnek, hogy így keversz két különböző területet: alapvetően a CSS feladata meghatározni az oldal megjelenését (benne van a nevében, hogy stíluslapokat készítesz), JavaScripttel pedig inkább a viselkedését illik manipulálni az oldalnak. Nyilván vannak kivételek, de ez pont olyan példa, amire érvényes. Persze nem érdemes túlizgulni, ez már csak szépítgetés, szemantikai okoskodás.
Most amúgy kíváncsiságból rákerestem a dologra, és találtam egy cikket, ami vitatja az osztályok ráhelyezésének vagy levételének elvét, és inkább a data-attribútumok használatát javasolja:
http://toddmotto.com/stop-toggling-classes-with-js-use-behaviour-driven-dom-manipulation-with-data-states/
Elfogadható, amit ír, de túlzásba esik az osztályok használatának elvetésével. De egyébként nem rossz a data-attribútumok használata sem."Lenne esetleg értelme minden sort egy ID-val ellátni, a szűrést pedig client-side/local storage-ban elvégezni majd az eredmény alapján állítgatni a displayt?"
Semmi értelme nem lenne ennek a megoldásnak. A szűrést így is az összes adaton kellene elvégezni, itt pedig semmiféle előnyt nem jelentene az, hogy csavarintasz és bonyolítasz egyet a dolgon.
Gondolj bele, a mostani megoldásod egy document.getElementsByClassName hívás, ami visszatér egy HTMLCollectionnel, amin végigmész egy for ciklussal, és megnézed, benne van-e az adott sorban valahol a keresett elem, aztán kész vagy. Ez is nagyon gyorsan fog végezni, még ha többezer elemed lenne, akkor se lenne vészes, a DOM-manipulálás már más kérdés. Ha viszont átállnál arra, hogy id-k szerint kérdezgess le, akkor értelemszerűen az id-kat is nyilván kellene tartani egy másik tömbben (mert különben honnan tudod, hogy miket kellene lekérdezni? Ha meg nem tudod a konkrét id-kat, akkor vissza kell térned az eredeti, amúgy ezerszer értelmesebb megoldásra), és azon a tömbön kellene végigmenned, lekérdezned id szerint az elemet, majd pont ugyanezt a keresést végrehajtani. Nem nyertél semmit, sőt, még overheadet is tettél a dologba (plusz egy-egy lekérdezés minden elemre az id szerint is, miután megkaptuk a tömbből az elemet).
Azt meg nem tudom, hogy érted, hogy "client-side"-ban elvégezni a keresést, most is kliensoldalon keresel.localStorage-be átpakolni a keresést meg megint semmi értelme, mit keresne ott, miért kellene perzisztens módon tárolnia a kliensnek az összes adatot. Nem beszélve arról, hogy valószínűleg az oldaladon változni fognak ezek a megjelenített és szűrhető adatok, így a localStorage-et mindig szinkronban kellene tartani az újabb adatokkal.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #5744 üzenetére
Elég szomorú, ha valami idióta tanár document.write-ot ajánl, de egyébként a srác leírásából sehol nem is derült ki egyértelműen, hogy az ő tanára valóban azt várná el, csak elkezdte használni, és ennek megfelelően alakult a további beszélgetés. Ha pedig működik anélkül, akkor elég érthetetlen lenne, ha nem fogadná el a tanár úgy, hogy a srác éppen nem document.write-tal oldja meg, hanem máshogy, mivel működik - ráadásul nem olyan módszert használt, ami tulajdonképpen tilos.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #5740 üzenetére
Régvótmáaz, biztos azóta már sokkal minőségibb kérdéseket teszel fel.
(just kiddin') Kérdezzzzz, most!!!444NÉGY
-
Sk8erPeter
nagyúr
válasz
Speeedfire #5732 üzenetére
Hádenemiskötöttem beléd!
(Kivételesen.
) Gondolom amúgy is ismered, csak rácsodálkoztam, hogy jé, pont nem műxik a jsbin.
(#5733) Cathfaern:
Jaja, beleírattam az összefoglaló legelső sorába, mert kis naivan azt gondoltam, hogy az már eléggé feltűnő.(#5737) Zedz:
Azért amikor az ember elkezd tanulni programozni, a szakmai infós angol kezdőként nagyon fárasztó tud lenni. A megoldás az, hogy eléggé kitartónak kell lenni. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5663 üzenetére
Chrome-ban (46.0.2490.86 m) az if (navigator.getUserMedia) feltétel nem is teljesül ebben a formában, mert az undefined. A navigator.webkitGetUserMedia függvény viszont létezik.
Jobb fallback így néz ki:
Capturing Audio & Video in HTML5
http://www.html5rocks.com/en/tutorials/getusermedia/intro/navigator.getUserMedia = navigator.getUserMedia ||
navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia ||
navigator.msGetUserMedia;Olvasd el a cikk többi részét is, elég jól összefoglalja a témát.
Szerk.:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getUserMedia
Most látom, a Navigator.getUserMedia() deprecated. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5632 üzenetére
"Adsz egy id-t 0-48-ig az űrlapmezőknek, majd ezt for-al kiolvasod"
He? Ezt most tényleg leírtad?
Az id-k aztán pont nem segítik az elemek bizonyos jellemzők szerinti általános, közös kezelését, hiszen azok egyedi azonosítók, azt az EGY bizonyos elemet találod meg a felhasználásukkal, pont az a lényegük.
Ilyesmire az osztályok valók, vagy egyéb közös tulajdonságok felhasználásával (pl. a tag neve, attribútumok, ilyesmik) is lehet azonosítani a közös viselkedéssel felruházni kívánt elemeket.(#5636) PumpkinSeed:
"Amúgy ez így szerintem undorító, már megbocsáss (nem szoktam így fogalmazni). Sokkal szebb lenne, ha az inputokat is JS-el generálnád. appendChild vagy valami hasonló függvény az ami neked kell ehhez."
A lényeg szempontjából teljesen mindegy, hogy hogyan készülnek el az elemek, egyáltalán nem lesz attól "undorító", hogy a HTML-kimenetben egyből ott van a táblázat összes eleme, egyrészt úgy nem JavaScript-kóddal kell minden elemet elkészíttetni (ez erőforrás-spórolást jelent), másrészt elkészítheti az elemeket a szerveroldal is, és bele is pakolhatja egyből adott esetben az input-elemek értékeit is (amiket pl. adatbázisból szed). Nem láttam az eredeti kódot, de az önmagában biztosan nem jelent problémát, és nem is csúnya, ha a HTML-kódba "égette bele" az elemeket, amiket viszont kliensoldalon kellene manipulálni/ellenőrizni.(#5640) martonx:
"Azért nem moccant meg a js-ed, mert ha onload-ot használsz a js kódod wrapperének, akkor az inline js eventnél nincs scope-on belül."
Tetszett ez a mondat, szerintem ebből a kolléga egy büdös árva szót nem értett.Nekem is kétszer kellett elolvasnom, hogy felfogjam.
Amúgy a kódban az a displayDate callback csak valami elírás (a check helyett).
-
Sk8erPeter
nagyúr
válasz
inf3rno #5603 üzenetére
"Arra, hogy a TDD/BDD többlet idővel járna mutathatnál valami bizonyítékot, mert pont az ellenkezője igaz."
Ha nem baj, megfordítanám a dolgot: arra mutathatnál nekem olyan általánosítható bizonyítékot, hogy minden esetben gyorsabb összeállítani egy gigarendszerben - annak összes függőségével, aktuális használati esetnek megfelelő konfigurációjával, stb. - egy valóban komplett tesztkészletet egy kisebb/nagyobb feature időre történő fejlesztéséhez, mint TDD/BDD aktuális alkalmazása nélkül azt elkészíteni. Mint minden általánosítás, a tiéd is itt sántít. Ha előre megvan hozzá minden infrastruktúra, valóban csakis mindenki úgy készített kódot, és valóban mindenki töltötte az idejét a minden esetre kiterjedő tesztesetek lefedésével, akkor előfordulhat, hogy nem akkora para, de van, amikor tényleg para.
De hidd el, ezt nem bántásból vagy kötekedésből írtam le, hanem azért, mert a gyakorlat sokszor sajnos messze kell, hogy kerüljön az elméleti bullshittől, még ha az elméleti bullshitnek nyilvánvalóan lehet bőven létjogosultsága."Persze ha nem veszed komolyan az egészet, vagy nem fotnos a minőség, akkor nyugodtan fejleszthetsz tesztek nélkül is."
Hümm, tehát arra, aki valaha életében merészelt leírni TDD/BDD-elvek alkalmazása nélkül kódot céges környezetben (alap, hogy az első kör nem az éles), Te most itt ünnepélyesen kijelentetted, hogy nem veszi komolyan az egészet, meg annak nem is fontos a minőség, értem.
Sajnos nem lettem meggyőzve - de még egyszer megemlíteném, cseppet sem becsülöm le a TDD/BDD előnyeit és szépségeit. (Egyébként meggyőzésként említettél EGY multit, ahol állítólag csak olyan kódot adnak ki a kezükből, ami ezen elvek mentén készül - egyrészt nem tudhatjuk ennek valódiságát, másrészt nem egy nagy merítési minta. De a gondolkodásmódod alapján biztos csakis ott lehet a szakma krémje, ahol ez percről-percre szem előtt van, máshol csak noobok és igénytelen k×csögök vannak.)
-
Sk8erPeter
nagyúr
válasz
inf3rno #5598 üzenetére
"Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz"
Bocs, de most már muszáj beszólnom, annyira folyamatosan erőlködsz ezzel a TDD-BDD-HDD-SSD-DDD-XXX-ASDASD-QWEQWE-BLABLA-HABLATY-vonallal (:]), hogy kezd már picit irritáló lenni. Azért komolyan kíváncsi lennék, hogy létezik olyan munkahely, ahol a fejlesztők tényleg MINDEN kódot TDD/BDD/akármi-vezérelt elven írnak? Van erre idő? (Persze elméletben ez is létezhet, ahol irreálisan nyugis a tempó.) Csak mert általában a megrendelők várnak a termékükre, a főnökök az eredményre (joggal), majd jön a következő feladat, és így tovább. Vagy ezek csak jól hangzó elvek, amiket a hobbiprojektjeidnél alkalmazol? Mert az egyébként úgy tök jó, és szép dolog, de amúgy akkor még csomó vezérelvhez tartozó mozaikszót vagy buzzwordöt be lehetne dobálni, ami a gyakorlatban azért inkább fenntartásokkal kezelendő, mert vagy működik, vagy nem, jó, ha sikerül annak mentén csinálni, de sokszor inkább az erre való törekvés jön csak össze (és már az is valami). -
Sk8erPeter
nagyúr
Szép találat, türelmes voltál.
Végül is ez esetben meg lehetne tenni, hogy a fájtl letölti, átírja ennek megfelelően, és az adott kérésre ezt az új tartalmat szolgálja ki saját extensionnel, DE ennek igen komoly hátránya, hogy "bedrótozza" a korábbi kódot, és a fájl frissülése nála nem lesz érvényes.
Azt nézem, hogy van egy ilyen rész a kódban:setTimeout(function() {
$('iframe').each(function() {
var src = $(this).attr('src');
if(src.match(/youtube\.com/i) || src.match(/video\.mno\.hu/i)) {
reloadBlocker = true;
}
});
if(!reloadBlocker) {
document.location.assign(document.location.href);
}
}, reloadTime);(fúj)
Ezek szerint ha saját extensionből csak beágyaz egy elrejtett YouTube-os iframe-et (lényeg, hogy az src attribútum a youtube-ra mutasson, nyilván az egész oldalt nem érdemes beágyazni), akkor a reloadBlocker változó értéke true lesz, és a document.location.assign(document.location.href); sor nem fog lefutni.
Borzasztó ronda megoldás mindenképp, de legalább nem fog 20 perc múlva (most ez van a reloadTime-ban) újrafrissülni az oldal...
-
Sk8erPeter
nagyúr
Uhh, ezt én is de tudom utálni, régen ilyet a prog.hu is csinált, hogy automatikusan frissült a lap, de nem csak frissült, át is irányított, így hiába volt későbbi olvasásra félretéve pár cikk, ránéztem egy idő múlva, és már csak a címlapot láttam. Gratula annak, aki kitalálta...
Írtam is nekik levelet ezzel kapcsolatban, hogy emiatt szoktam le a cikkjeik olvasásáról, hogy azóta is van-e ez a jelenség, fogalmam sincs, mert tényleg nem olvasom őket.
A kérdésre amúgy most érdemben nincs időm reagálni, de látom, kaptál már ötletet, csak hát JS-hez értés nélkül nehéz lesz ezekkel bármit is kezdeni... Amivel hozzákezdhetnél, az az, hogy megnyitod a webfejlesztő panelt, és az ottani keresővel minden, oldalról letöltött forrásban elkezded keresgélni (Blink-alapú böngészőkben (pl. Chrome, Opera) a Ctrl+Shift+F segítségével!) az említett "setInterval" és "setTimeout" szavakat. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5396 üzenetére
De a Te kódod szempontjából ez nem is meglepő, mivel ellenőrzöd, hogy van-e a stringedben meg nem engedett karakter, és ha igen, épp akkor valid. Neked pont az ellenkezője kell. Ezért írta dqdb, hogy negálnod kell (nézd meg az ő kódját).
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5256 üzenetére
Érthető jetarko kolléga álláspontja. (Erősen) típusos nyelvekből érkezve elsőre borzasztó idegesítő tud lenni a gyenge típusosság, időbe kerül, míg az ember megszokja. Épp ezért a PHP-val összevetni, hogy ahhoz képest szerinted milyen csudajó, pont nem jó példa, mivel az is gyengén típusos nyelv.
Mondjuk ha valaki színtiszta Javázás/C#-ozás/C++/stb. után kerül a JavaScript világába, akkor egy JS-kód rohadt zavaró lehet a szemnek. Ettől még JavaScriptben is lehet szép kódot írni, de szerintem sosem lesz olyan kellemes "külsőre", mint mondjuk egy jól kinéző C#-kód. Nyilván ez szubjektív, szerintem így van.
Alapvetően a gyengén típusos nyelveknek nagyon is megvan a maguk szerepe, a probléma általában szerintem az lehet velük, hogy sokakat sarkall spagettikód írására. Ettől még erősen típusos nyelvben is lehet borzalmasan gusztustalan kódokat írni, de mondjuk aki ilyen problémáktól szenved, valószínűleg nem egy kódmágus, és azt legalább a fejlesztőkörnyezet figyelmezteti, hogy valamit szarul csinál. -
Sk8erPeter
nagyúr
Elég vicces, hogy a cím teljesen ellentmond a tartalomnak:
"Assembly-szerű nyelv válthatja le a JavaScriptet a böngészőkben"
"Erre a problémára akar egy új megoldást kínálni a W3C egy új munkacsoportja, ami egy assembly-szerű nyelv értelemzőjének beépítését javasolja a modern böngészőkbe a JavaScript mellé."Már ez is kifejezi, hogy nem LEVÁLTÁSról van szó, hanem legfeljebb kiegészítésről. Meg is őrülnék, ha assembly-szerű nyelven kellene programozni kliensoldalon. Nem tudom, programoztatok-e már assembly-ben, hát szenvedjen vele az, akinek muszáj, vagy akinek van ilyen jellegű perverziója.
JavaScript MELLÉ komoly teljesítménynövekedés esetén nem hülyeség, de lehet, hogy ez is megmarad egy ilyen "volt róla szó"-projektnek, hacsak valaki nem tesz bele nagy lóvét, hogy nyomassa orrba-szájba. -
Sk8erPeter
nagyúr
válasz
fordfairlane #5243 üzenetére
... és akik még ráadásul kegyetlenül lusták is ahhoz, hogy önálló erőfeszítéseket is tegyenek annak érdekében, hogy maguktól is megpróbáljanak megtanulni valamit, és ne mindent a fórumról várjanak, szájbarágósan. Na, honda ilyen (volt).
-
Sk8erPeter
nagyúr
válasz
fordfairlane #5231 üzenetére
HTML-fájl, scriptfájl, az alapvető HTML-struktúra létrehozása helyett nem lett volna egyszerűbb és gyorsabb picit csak simán bedobni a konzolba a kódot, ha már meg van nyitva?
-
-
Sk8erPeter
nagyúr
válasz
DR|FTK|NG #5212 üzenetére
Rettentő komplikált egy ilyen feltételvizsgálat... Ne szórakozz már. Programozásnál NEM LÉTEZIK olyan, hogy megbízható felhasználó. SOHA. A létező legrosszabb eset felől kell megközelíteni az ilyen jellegű validálásokat. És amúgy is MINDIG először a szerveroldali ellenőrzést írjuk meg, és CSAK azután a kliensoldalit, mivel a kényelem, gyorsaság és hasonló szempontok abszolút másodlagosak a biztonsággal szemben.
Egyébként elég csak annyi, hogy valaki régebbi böngészőt használ, ami a HTML5-ös feature-öket még nem támogatja, és máris buktad a kliensoldali ellenőrzésedet, simán átmegy a beírt szám a szűrőn, mivel szerveroldalon egyáltalán nincs szűrőd, és még kliensoldalon sem működik a dolog, és még csak nem is gonosz júzerről volt szó. Hanem olyanról, aki valamilyen oknál fogva egy elavult szart használ. Remélem, ezek fényében nem kérdés, hogy azonnal megírod a szerveroldali ellenőrzést, főleg, hogy normális esetben nem kéne, hogy több időt elvegyen pár percnél (bár ebbe azt is beleszámítottam, hogy az ember elindítja a használt fejlesztőkörnyezetet (vagy akár szövegszerkesztőt), és megnyitja a fájlt).
-
Sk8erPeter
nagyúr
Hehe, és tényleg, reprodukáltam a jsFiddle-példában a problémát, <div class="modal">-ba rakva a visszakapott tartalmat, és így tényleg üresen jelenik meg. Hát ez a library működéséből következik, a megoldás simán az, hogy
1.) a visszaadott tartalomból kihagyod a "modal" osztállyal ellátott divet (végül is felesleges)
2.) átírod a displayModal függvényt úgy, hogy csak egy $(content).modal(); sor legyen benne.
Utóbbinál viszont garantálnod kell, hogy egy jQuery-nek átadható tartalom van benne, tehát pl. mindenhol szerepel egy konténerelem, pl. épp a <div class="modal">...</div> vagy hasonló, de ez annyiból törékeny, hogy pl. már egy asdasd<div class="modal">...</div>qweqwe nem működne, mert a jQuery-nek átadva így szintaktikai hibát kapnál (a jQuery ezzel a tartalommal így már nem tud mit kezdeni, elég kipróbálni azt, hogy $('asdasd<div class="modal">...</div>qweqwe'), "Syntax error, unrecognized expression" lesz az eredmény).
Persze annyiból így is-úgy is törékeny lesz a dolog, hogy ha van egy olyan div a kapott tartalomban, ami tartalmazza a "modal" osztályt, akkor az abban lévő tartalmat eleve kidobja. Szerintem ilyen szempontból szarul működik a library, de hát ez van. -
Sk8erPeter
nagyúr
Érdekes, mert úgy tűnik, a tartalom lekérése sikeresen meg is történik, ahogy látszott a korábban a konzolra kiírt tartalomból, tehát valamiért csak épp a modális ablak betöltése az adott tartalommal nem sikeres. Az általam definiált displayModal függvényt is átmásoltad?
Igazából itt a legértelmesebb a böngészőn belüli debuggolás lenne, úgy, hogy egy breakpointot raksz a sikeres AJAX-kérést jelző eseménykezelőbe, meg mondjuk a displayModal függvénybe, megnézve, hogy a tartalom az elvárt-e, mi a változók aktuális értéke, stb... Egyszerű megközelítésként, ha még nem debuggoltál (egyébként elég egyszerű), egészítsd ki mondjuk ezt is egy konzolra kiíratással:function displayModal(content) {
console.log('content: ', content);
$('<div>', {
html: content
}).modal();
}Most jobb ötletem nincs, ha a debuggolás még nem megy, mint hogy vizsgáljuk meg ilyen módon, hogy a tartalmak az elvártak-e, eljut-e idáig, stb. Ha a tartalom ezenbelül megfelelő, akkor nem nagyon értem, miért nem működik nálad, amikor a jsFiddle-példában jó, de derítsük ki egyelőre ezt, hogy idáig eljutunk-e.
(#5201):
Hát köszi, de azért bőven szoktam tévedni. -
Sk8erPeter
nagyúr
Szívesen. Ja, a konzolra ezt az üzenetet azért írja, mert beleraktam egy console.log(...) sort.
Azt akár ki is törölheted, debuggolási célra jó a console.log - de ebből kiindulni nem lehet, mivel ez nem hiba.
Ha a Network fülre kattintasz a webfejlesztő panelon, ott látszik valami pirossal jelölt erőforrás, meg valami hibakód, amikor megpróbálja betölteni a tartalmat? Ha a megfelelő linkre kattintasz, akkor mi történik? -
Sk8erPeter
nagyúr
Működésre bírtam neked:
http://jsfiddle.net/bha6er48/20/
Kommenteztem a kódot, remélem, az alapján egyértelmű lesz, ha valami nem tiszta, kérdezz nyugodtan.
A jsFiddle API-t használtam az AJAX-tesztelésre, ezért szerepel bedrótozva az URL-nél a /echo/html/ a loadContentFrom függvény első sorában (a böngészők biztonsági beállításai miatt nem is lehetne másik domainre kérést indítani), azt az egy sort majd kitörölheted az éles kódban! Az $.ajax résznél majd a POST-metódust változtasd GET-re, ez is a jsFiddle miatt volt szükséges. -
Sk8erPeter
nagyúr
Ha lehet, rakj fel egy egyszerűsített példát inkább a jsFiddle-re, pont ilyen szemléltetésre és demózásra való. Az egyes külön lévő panelekbe fel tudod rakni a HTML-, CSS-, ill. JS-kódodat. A HTML-résznél ebben az esetben nem kell az alapvető struktúra, elég a <body>-ban lévő részt bemásolni. Így több esélyed van arra, hogy segítséget nyújt valaki közülünk, amikor picit ráér.
Szerintem a legtöbbünknek nem lesz kedve kibontani a zip-fájlodat, aztán helyileg tesztelni, majd felrakni helyetted a javított/javasolt jsFiddle-példát. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5191 üzenetére
Tesztelésre meg az egyszerűen elérhetőek közül ott a console.log() vagy console.debug() (és társai), ami nem egy ilyen korlátozott, gyakorlatban sehol sem használható fos, mint a document.write(), sőt, akkor már megtanulhatnál JavaScript-kódot is debuggolni, nem egy akkora művészet, a böngészők debuggerében sem nehéz kiigazodni. Persze az is érthető, ha adott esetben ki akarod íratni az értékeket, mert mondjuk gyorsabb áttekinteni, vagy ilyesmi, de akkor is már inkább a console-t használd erre (és nyisd meg a webfejlesztő panelt tesztelgetéshez, ott a konzol is, meg ott érhető el a debugger is, stb.).
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5189 üzenetére
Akkor hagyd ott a kurzust.
Kifejezetten nem ajánlatos. Gondold végig, a gyakorlatban mikor használnád egy éles weboldalon? Ugye?
Amúgy rákerestem, meglepődtem volna, ha nincs Stack Overflow thread a témával kapcsolatban, itt aztán mazsolázhatsz:
http://stackoverflow.com/questions/802854/why-is-document-write-considered-a-bad-practice -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5187 üzenetére
Mármint így nem sokáig marad ott a sok hiba?
Amúgy már feltűnt, a document.write()-ot mennyiszer használod, ha tanácsolhatom, szokj le róla, nincs szükséged rá, sőt. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5167 üzenetére
Ja értem, hát ilyen nemsokára leadandó házikat azért az ember kicsit másképp közelít meg, mint egy éles projektet.
Előbbinél inkább az a lényeg, hogy a legtöbb pontot összekapard (max. nem kapod meg a teljes pontot amiatt, hogy nem ott jön be a figura, ahol kéne, ha nem marad időd kijavítani, de legalább a többi feladatból is megoldottál valamennyit), utóbbinál meg az, hogy tényleg a speckónak megfelelően működjön, különben az ügyfél mérges lesz. Ha valós, nem mindig előkerülő, de adott esetben elég problémás bugról van szó egy éles projektnél, akkor azt nem jó ellökdösni, hogy majd megcsinálom, mert akkor elfelejtődhet...
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5163 üzenetére
"Igazából, a bugok nem nagyon befolyásolják a működést"
Ha az, amiről beszélsz, nem befolyásolja a működést, akkor azt nem bugnak hívják... -
Sk8erPeter
nagyúr
válasz
martonx #5142 üzenetére
Az egészben tényleg az a durva, hogy bármilyen segítséget felhasználhatott (mármint azonkívül, hogy valakivel elküldeti a megoldást, hogy felvegyétek, mert az úgyis kiderül), szóval ha valaki valamirevaló fejlesztő, akkor nem igaz, hogy egy formot nem tud kiguglizni. Az sem mentség, hogy ő inkább irányítgatta az embereket, meg én sem értem, akkor hogyan vizsgálhatta felül mások kódját, ha ilyen hülye a kódoláshoz. Most például ezt az MDN és form szavakat egymás után írva három másodperc alatt találtam:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms
Ha valaki ez alapján nem tud összerakni fejlesztőként egy űrlapot, akkor az ássa el magát. -
Sk8erPeter
nagyúr
válasz
martonx #5135 üzenetére
De ez hogy lehet, ha elvileg többéves webfejlesztői tapasztalata van? Úgy értem, biztos van valami oka: ennyire nem volt köze a frontendhez, végig csak backend-kódokat készítgetett, és az évek alatt elfelejtette? Vagy sosem tudta? Engem tényleg érdekel, ez hogyan fordulhat elő.
-
Sk8erPeter
nagyúr
Ezt még nem olvastam, de sejtettem, hogy valójában ilyen nevetséges a háttérsztori.
Egyébként én támogatnám, hogy akár a régi fos kódok eltörésével erőltessük keresztül ennek az automatikus pontosvessző-beszúrásnak (szerepeljen már legalább egyszer magyarul is
) az eltörlését.
-
Sk8erPeter
nagyúr
válasz
martonx #5122 üzenetére
Nem hiszem, hogy még neked kéne szégyellni magad a nyelv egyik hibája miatt.
Na, már látom előre az anyázásokat és hőbörgéseket, feldühödött "te vagy a hülye!"-jellegű reakciókat, de nem hiszem, hogy az egy jó dolog, ha a nyelv próbálja valahogy korrigálni az amúgy potenciálisan elkúrt kódot, ezzel pont, hogy hibát belerakva az amúgy adott esetben pont nem hibás kódba (mert elméletileg az általad mutatott kód nem kellene, hogy az legyen).
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5105 üzenetére
Szívesen.
Ezt nem értem, honnan hova akarod "áttenni az inputot"? Ez utóbbi mit jelent? Szóval mit szeretnél elérni? -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5102 üzenetére
Gondold végig: Te a document.getElementById()-vel lekérsz egy elemet, majd annak próbálod elérni a document tulajdonságát - ennek semmi értelme, nem lesz document tulajdonsága/attribútuma.
Ha végig akarsz menni az elemeken, akkor több lehetőséged is van, például:
- document.querySelectorAll segítségével, egy selector felhasználásával megkeresed a vonatkozó elemeket; pl. ha mindegyik checkbox el van látva a fruit-checkbox osztállyal, akkor ez aztán egészen szigorúan csak azokat fogja megtalálni:
var fruitCheckboxes = document.querySelectorAll('input[type="checkbox"].fruit-checkbox');
Ez egy NodeListet ad vissza, ezeken végig tudsz menni egy for ciklussal simán.
Pl.:
for (var i = 0; i < fruitCheckboxes.length; i++) {
var currentFruitCheckbox = fruitCheckboxes[i];
console.log(currentFruitCheckbox.name + ' - is it checked? ', currentFruitCheckbox.checked === true);
}
Ilyesmi.
- ha egy tömbben van összegyűjtve, hogy milyen nevű elemeket keresel (pl. a name attribútuma tartalmazza az elemnek a gyümölcs nevét), és egy adott konténerelemen belül szeretnél csak keresni, és kifejezetten egy elemre, akkor megteheted az Element.querySelector() segítségével, pl.:var fruitCheckboxContainer = document.getElementById('fruit-checkbox-container');
var fruitNamesArray = ['apple', 'orange', 'pear'];
for (var j = 0; j < fruitNamesArray.length; j++) {
var currentFruitCheckbox = fruitCheckboxContainer.querySelector('input[name="' + fruitNamesArray[j] + '"]');
if (currentFruitCheckbox === null) {
console.log('A checkbox with the name "' + fruitNamesArray[j] + '" does not exist in the fruit checkbox container');
continue; // go on to the next one
}
console.log('is "' + fruitNamesArray[j] + '" checked? ', (currentFruitCheckbox.checked === true));
}- stb., a lehetőségekből még elég sok van, de ezek elég egyszerű példák.
Felraktam neked ide egy demót:
http://jsfiddle.net/Sk8erPeter/Ls015fk7/ -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5100 üzenetére
Értelmezted a hibaüzenetet?
formId.document.getElementById(fruitsArray[i])
--> Cannot read property 'getElementById' of undefined
Elég egyértelmű... ha kifejted a formId változót, mi értelme van annak, hogy
document.getElementById("valami").document.getElementById(fruitsArray[i])
? -
Sk8erPeter
nagyúr
A SoundCloud lejátszója elvileg csak valóban SoundCloudról származó zenéket tud lejátszani (legalábbis a talált infók alapján).
De beírtam Google-be, hogy "jquery waveform player", és ezeket találtam:
http://www.wavesurfer.fm/
http://justwave.beotiger.com/player.html
http://codepen.io/FadedShadows/pen/crjza
Aztán biztos van még, ami említésre méltó.Van egy ilyen BBC-s oldal, ami egy kicsit komolyabb ezeknél, szerintem talán még az ilyen jellegű előfeldolgozás (itt egy C++-alkalmazás segítségével végzi el) az, ami igazán komolyan vehető (értsd: valóban "helyes" hullámokat generáló megoldás):
http://waveform.prototyping.bbc.co.uk/
(kapcsolódó cikk: http://www.bbc.co.uk/rd/blog/2013/10/audio-waveforms) -
Sk8erPeter
nagyúr
válasz
Speeedfire #5067 üzenetére
"Miért ne lehetne gyorsabb? Nem tudhatod.
"
Most ezt komolyan mondod? Szerinted ha először parse-olod a localStorage-ed tartalmát, majd a megfelelő elemet lekéred, az nem tart tovább, mint azonnal hozzáférni a változó tartalmához?"Miért? Mert leírtam, hogy mire használtam?
"
Valószínűleg simán előítélet a múltbeliek alapján.Sorry.
Egyébként mutathatnál egy konkrét use case-t, hátha nincs szükség külön adatbázisra, és megoldható localStorage vagy más adatstruktúra segítségével is. Vagy hát ahogy gondolod, ha nem akarsz, akkor ne, gondoltam hátha megkímélünk pár kör futásától. -
Sk8erPeter
nagyúr
válasz
Speeedfire #5064 üzenetére
"Nem láttam se gyorsabbnak, se egyszerűbbnek, mint a js változókat."
Mitől lenne már gyorsabb localStorage-en vagy bármin keresztül elérni, mint a változókhoz hozzányúlva?Egyébként szerintem ennyi alapján simán elegendő lenne neked a localStorage is, csak sanszos, hogy rosszul használtad.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #5059 üzenetére
Miért nem használod a dokumentációkat? Sokkal kevesebb szopásban lenne részed (persze az értő olvasás is követelmény hozzá):
https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementsByClassName"Returns an array-like object of all child elements which have all of the given class names."
Ebből elég jól látható, hogy ez a metódus az összes olyan gyerekelemet visszaadja, ami az adott (nálad épp a shipsIndex2 nevű) osztállyal van ellátva, és mindezt egy tömbszerű szerkezetben fogod megkapni. Tehát nem is használhatsz olyan szintaktikát, ami egyetlen elemre vonatkozik. Akkor sem, ha csak egyetlen találat van.
Magának a metódusnak a nevéből (getElementsByClassName) is igen jól látszik, hogy ilyen viselkedésre lehet számítani - ott a többesszám.
Ezenkívül abból is, hogy az általad mutatott screenshoton látható konzolon is szögletes zárójelek között van az az egy elem, amire illeszkedett a keresésed.
Tehát minden ilyen esetben, ha a fene fenét eszik is, és csak egy elemre illeszkedett a keresésed, akkor is valamilyen tömbszerű szerkezetben fogod megkapni azt az egy találatot is, ennek megfelelően is kell tehát elérni.==============
(#5062) Speeedfire :
"A localStorage-et kipróbáltam, de annyira nem jött be."
Hogy érted, hogy nem jött be? Milyen célra?
Amúgy valóban nem egy szofisztikált valami, de alapvető dolgokra bőven elegendő lehet. -
Sk8erPeter
nagyúr
Tényleg nagyon komolyak ezek a DevTools-újdonságok! Rengeteget fog számítani fejlesztésnél, debuggolásnál.
Amúgy az a rész vicces, ahol elemzik a jQuery jelenlegi hülyeségeit, amik jelentősen rontják a teljesítményt, és szinte következetesen azt hozzák ki a dologból, hogy használj plain JavaScriptet.
Egyet leszámítva, hogy ne használd a .hide()/.show() metódusokat, mert rohadt lassú, inkább váltogasd az osztályokat az elemen az elrejtéshez/megjelenítéshez - na én ezt speciel régóta követem, pedig nem vágtam, hogy ilyen komoly teljesítménybeli problémák vannak vele, mert szebb is, hogy nem égetődik bele a kódba a display:none; vagy display:block;.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #5024 üzenetére
Ha jól láttam abból a pár másodpercnyi ránézésből, valami slideshow-szerűséget szeretne készíteni, az meg pont az a tipikus eset, amikor bármit is rögzíteni id-vel a lehető legrosszabb ötlet. Ha ugyanarra az oldalra két darab slideshow-t is szeretne tenni (mert mondjuk az egyik divben a partnerek listája csúszkál jobbra-balra, a másikban meg pl. képeket mutatnak a legutóbbi konferenciáról, vagy a tököm tudja), akkor máris meg van lőve, és nyúlkálhat bele megint a kódba, és jöhet rá, hogy a francba, jobb lett volna kapásból egy fokkal általánosabb megoldani.
Ha meg már amúgy is jQuery-ről van szó, akkor már kiindulástól kezdve rossz a megközelítés, eleve jQuery-plugint kellene fejleszteni, és akkor bármilyen selectorra működhetne a dolog. Attól, hogy pluginként építi fel az ember a kódot, semmivel sem lesz bonyolultabb, sőt, még legalább valami értelmes keretet is ad, és a doksi is igencsak beszédes:
http://learn.jquery.com/plugins/basic-plugin-creation/
A konkrét slideshow-struktúrával kapcsolatosan nyilván kell némi megkötésekkel élni, az nem lehet akárhogyan, de a selectort ne rögzítsük már le előre.Aztán még ott van az az érv is, hogy a slideshow-kódokból Dunát lehet rekeszteni, a lightweighttől kezdve a nehézbombázóig, mindenféle effektekkel teletűzdelve, ingyenes és fizetős egyaránt van ilyenekből, nem biztos, hogy érdemes feltalálni a spanyolviaszt.
Ha esetleg nem tök általános slideshow-ról volt szó, hanem ennél picit specifikusabbról, és muszáj hozzáfejleszteni vagy saját kódot írni, attól még a fentiek az általánosabb, kevésbé bebetonozott kódkészítéssel kapcsolatban ugyanúgy igazak.Szerk.:
Amúgy Jim-Y jól mondja, ez általános szoftvertervezési elv is.Természetesen a fenti elveket csak az kövesse, aki igényes a saját kódjával szemben is, és nem sajnálja azt a plusz pár percet, amit egy picit általánosabb, több helyen (akár a megjelenített oldalon belül többször, akár más projektben) is felhasználható megoldás nyújthat. Szerintem ez olyan dolog, hogy ha az ember folyamatosan így próbál gondolkodni, akkor eleve sokkal nagyobb körben teheti működőképessé a kódját (és például nem fogja akkora macerának érezni egy rögzített azonosító helyett egy általánosabb osztály felhasználását).
-
Sk8erPeter
nagyúr
"Egyszerű és nagyszerű, meg sem fordult a fejemben, hogy 'id'-ra tegyem a formázást..."
Még jó is, hogy nem fordult meg a fejedben, mert illik sokkal általánosabban megoldani az ilyesmit, nem pedig id-vel szórakozni, és ezzel kb. örökre rögzíteni, hogy melyik elemet is fogod buzerálni. Vannak esetek, amikor ez nem számít, de többnyire mégis.Amúgy örülök, hogy nálad működik a "javított" demó, mert nálam konkrétan semmit nem csinál, igaz, összesen 5 másodpercnyi időt töltöttem a kipróbálásával, nem próbáltam elgondolkozni, mit csinál és mit kellene csinálnia.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #4993 üzenetére
Igen, ezt értem, de miért nem kifejezetten a négyjegyűekre keresel rá egy regexppel, és egyből cseréled is őket egy valamiString.replace()-szel, ha pont az az érdekes? Miért a negáltat akarod keresgélni?
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #4989 üzenetére
Bevallom, a konklúziódat nem értettem, miért negálni akarod, hogy bármi, ami NEM négyjegyű szám, miért nem volt jó a \d{4}, vagy az az érdekes, tehát azt szeretnéd kiszűrni és esetleg jelezni a felhasználónak, ami NEM felelt meg a szabályoknak, és emiatt azt kotrod ki?
-
Sk8erPeter
nagyúr
válasz
martonx #4985 üzenetére
Király! Kíváncsi vagyok, mit hoznak ki belőle. Amúgy meglepően aktívak a Microsoftnál fejlesztői téren, elég durván sok változás van mostanság, kezdve az ASP.NET-es nyitástól a Linux és Mac felé, némi open source-osodáson, az ingyenes, mégis profi Visual Studio Community Edition megjelenésén, meg sok egyéb újításon át egészen eddig az együttműködésig (ja, meg bár ez inkább felhasználói szempontból érdekes, ugye tervezik a Windows 10-hez az új Spartan-böngészőt (amiből még nem tudom, mi lesz), stb.).. Eléggé tesznek érte, hogy magukhoz csábítsák a fejlesztőket.
(#4981) Jim-Y:
Jaja, belénkverték.Hát az "easier to reason about" tudtommal csak annyit jelent, hogy könnyebb valami mellett érvelni. Nem?
(#4984) Cathfaern:
Jó ez a kép. -
Sk8erPeter
nagyúr
Bocsánat a totális OFF-ért, de úgy látom, még mindig nem kopott ki a fejlesztői közbeszédből ez a "meredek tanulási görbe", pedig ez a kifejezés meglehetősen értelmetlen, ezt már itt is leírtam: [link].
Ha az x tengelyen az idő van, az y tengelyen pedig a tudás mértéke, akkor a meredek pont azt jelenti, hogy rohadt gyorsan tanulható. Pedig általában ellenkező jelentéssel szokták használni. Ha fordítva lenne ábrázolva, úgy még talán lenne is értelme, de ez csak azt bizonyítja, hogy a kifejezés jelentése csupán értelmezés kérdése, tehát körülményes, feleslegesen finomkodó (vagy nem is tudom, hogy mondjam, lehet, hogy az "okoskodó" szó már erős
), simán írhatnánk azt, hogy "hosszú idő alatt tanulható", "nehéz", "elsajátítása egy hosszabb folyamat", stb.
-
Sk8erPeter
nagyúr
válasz
Tibcsi55555 #4950 üzenetére
Szívesen. Persze, hogy lehet, bár ez már nagyon nem JavaScript-téma.
Viszont önmagában arra, hogy egymás mellé legyen rendezve két elem, nem kell táblázatot használnod, lehet inline-ná vagy inline-block stílusúvá tenni az elemet, és akkor is egymás mellé kerül, de odaraktam neked táblázatba is, de utóbbit tényleg csak indokolt esetben használd (és nézd meg, most mi változott a CSS-kódban az előzőhöz képest):
http://jsbin.com/jodipaxoxa/2/edit -
Sk8erPeter
nagyúr
válasz
Tibcsi55555 #4944 üzenetére
Ja, hát igen, jsFiddle-nél ez szándékos, hogy az egyes kódok jól elkülönüljenek.
Ebből lehet kiindulni, ez alapján készítettem neked egy egy az egyben kimásolható példát, itt akár online játszhatsz is vele, átírhatod a kódot, és meglátod, mi történik vele:
http://jsbin.com/fujoluyugu/1/editVidd az egeredet a linkek fölé. A linkeket hasonló módon készítsd el a saját oldaladon, ahogy itt mutattam, a lényeg, hogy a data-tooltip-img attribútum értéke az legyen, ami a kép közvetlen linkje. Remélem, így már el fogsz tudni indulni.
-
Sk8erPeter
nagyúr
válasz
Tibcsi55555 #4942 üzenetére
Most ezt nem értem, a konkrét példa, amit fordfairlane belinkelt, az miért nem jó? Az egy nagyon egyszerű kód, csak annyit kell tenned hozzá, hogy működjön az oldaladon, hogy a jQuery-t és a jQuery UI-t behúzod, aztán a selectorokat kicseréled a sajátjaidra, és kész vagy.
-
Sk8erPeter
nagyúr
Ez nagyon egyszerű, a :hover részhez még hozzáadsz egy osztályt is, amire ugyanezek a tulajdonságok érvényesek (vesszővel elválasztva, pl. .skill_line:hover, .skill_line_hovered { /*...*/ }, itt a skill_line_hovered osztály az új), majd ezt az osztályt hozzáadod JavaScripttel, ettől elindul az animáció, majd leveszed az osztályt, amikor azt szeretnéd, hogy visszacsússzon eredeti állapotába.
Tessék:
https://jsfiddle.net/8ndwnb2b/1/Amúgy volt egy csöpp hiba a CSS-kódodban:
-webkit-transition: width 2s;
For Safari 3.1 to 6.0 -ms-transition: width 2s;
Ez a For Safari 3.1 to 6.0 nyilván komment akart lenni, de nem működő kód lett belőle.Az eredeti JS-kódban a scrollozással kapcsolatos résznek meg nem sok értelme volt.
(#4924) D4nY:
Itt van egy nagyon egyszerű dialógusablakot felpattintó kód a jQuery UI felhasználásával:
http://jqueryui.com/dialog/#modal-confirmation
Ha elakadsz, segítünk.
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone i3 10105F 8/16/32GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! GIGABYTE AORUS ELITE Z790 i7 14700K 64GB DDR5 1TB SSD 7900XTX 24GB be quiet! SB802 1000W
- LG 42C4 - 42" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- GYÁRI TÖLTŐK DELL LENOVO HP FUJITSU TOSHIBA Macbook---------- Budapest,/MPL/Foxpost
- AKCIÓ! ASUS PRIME Z390-P i5 8600K 16GB DDR4 512GB SSD RX 6600 8GB GDDR6 DEEPCOOL Matrexx55 630W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged