- Kicsomagolták a Vivo X Fold 5-öt (videó és fotók)
- Szerkesztett és makrofotók mobillal
- iPhone topik
- Honor 200 Pro - mobilportré
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Milyen okostelefont vegyek?
- Android alkalmazások - szoftver kibeszélő topik
- VoLTE/VoWiFi
- Samsung Galaxy A54 - türelemjáték
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
-
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
-
-
Jim-Y
veterán
Ezer ilyen van a neten, de ha mar szorakoztam vele egy kicsit, akkor leirom
function Animal(breed) {
this.breed = breed;
}
function Monkey(name) {
Animal.call(this, 'mammal');
this.name = name;
}
Monkey.prototype = new Animal();
Monkey.prototype.constructor = Monkey;
var charlie = new Monkey('Charlie');
console.log(charlie.name, charlie.breed); //"Charlie" "mammal"
console.log(charlie instanceof Animal); // true
console.log(charlie instanceof Monkey); // trueEloszor csinalunk egy Animal constructor function-t (hivjuk osztalynak). Az animal osztaly nem csinal mast, csak letrehozhatunk belole a new kulcsszoval olyan objektumokat amiknek beallithatjuk a breed propertijet valamire.
Utana letrehozunk egy Monkey osztalyt amivel szinten uj objektumokat tudunk gyartani majd, amiknek nevet adhatunk. Mivel elore tudjuk, hogy minden Monkey objektum egyben egy Animal is, vagyis minden majom egy allat, ezert tudjuk, hogy a Majom osztalyt az Allat osztalybol kell majd orokoltetni. Azt is tudjuk, hogy minden majom fajtaja emlos lesz, ezert ezt mixin inheritance-el allitjuk be. Animal.call(this, 'mammal')
Monkey.prototype = new Animal();
Monkey.prototype.constructor = Monkey;A fenti ket sor szolgal arra, hogy egy is-a relaciot tudjunk felallitani a Monkey es az Animal osztaly kozott.
A mixin iheritance es a sima kozott az a kulonbseg, hogy az elobbi esetben lemasoljuk a szulo osztaly mezoit es azokat mint sajatokat hasznaljuk. Elobbi esetben explicit nem masoljuk at a propertiket, hanem referenciaval valo ramutataskor visszakeressuk oket a prototype chainben.
klasszikus eset:
============function Animal(breed) { this.breed = breed; }
function Monkey(name) { this.name = name; }
Monkey.prototype = new Animal('mammal');
Monkey.prototype.constructor = Monkey;
< var george = new Monkey('George');
> undefined
< george.breed
> "mammal"
< george
> Object { name: "George" }Ekkor azt varjuk, hogy a george objektum protipusa a Monkey prototipusara fog mutatni, aminek a prototipusa az Animal prototipusara, aminek a belso prototipusa az Object prototipusara aminek a prototipusa viszont mar nem fog masra mutatni. Ez az ugynevezett prototype chain.
< george.__proto__.__proto__.__proto__ === new Object().__proto__
> trueAz oroklodes itt JavaScriptben ugy mukodik, hogy ha leirsz egy olyat, hogy george.breed akkor eloszor megnezi a runtime, hogy a george objektumban van-e breed nevu mezo, ha van akkor visszaadja az erteket, ha nincs akkor megnezi hogy a george prototipusa mire mutat es ott is elkezd keresni. Egeszen addig visszamegy a prototype chainben amig null-hoz nem er. Ha nem talalja meg, akkor undefined-al ter vissza.
< george.gender
> undefinedUgyanigy mukodik a metoduskra valo "kereses".
< Object.prototype.dummyMethod = function() { return 'dummy'; };
> function Object.prototype.dummyMethod()
< Object.dummyMethod()
> "dummy" -
Jim-Y
veterán
if (item) helyett if (item !== void 0) inkabb. Sorry
Illetve, ha ES5 a target, akkor
function take(arr) {
var indices = [].slice.call(arguments, 1);
return indices.reduce(function (accumulator, curr) {
var item = arr[curr];
if (item !== void 0) {
accumulator.push(item);
}
return accumulator;
}, []);
} -
martonx
veterán
Én az egészet poénnak fogtam fel. Pont az a típusos programnyelveket kedvelő programozó vagyok, aki a javascriptet, php-t is kimondottan kedveli, napi szinten használja.
Ettől függetlenül mindig jót mosolygok ezeken az extrém konverziós példákon, nem cseszem fel magam rajtuk. -
#4835
Sk8erPeter
nagyúr
Jim-Y
#4833
Sk8erPeter
nagyúr
Fú nem tom, számomra ezek a return console.error(...) és hasonló kerülő megoldások olyan metódusoknál, amik valójában nem adnak vissza semmit (OK, "implicite" undefined-ot adnak vissza, de érted), nagyon tákolásszagúak.
(még ha alkalmazzák is)
Semmi gond nincs egy egyszavas return; sorral sem. Igazából ha valaki lefelejti a returnt, akkor így is-úgy is lefelejti, szóval a két sor egybevonása sztem sok mindent nem old meg (bár lehet, hogy valakinek ad egyfajta megszokást, csak így meg ronda).Amúgy fura ez a figyelmeztetés, hogy a return false az event handlereknél deprecated, legalábbis ha a Reactet használod, kiíródik ezek szerint, ez nekem is új. (Szóval hogy explicite kell használni az e.stopPropagation() és/vagy e.preventDefault() metódusokat, simán a return false nem jó ezek helyettesítésére, hanem egyértelművé kell tenni a dolgot, hogy melyikre van szükséged.)
================
Más:
basszus, most látom, hogy a mostani topiclogónál a Java (és nem JavaScript) gőzölgő kávéscsészéje van, miért?
Így is eléggé keverik a JavaScriptet a Javával, adjuk alájuk a lovat?
-
-
martonx
veterán
Mi a java-s standalone verziót sokáig használtuk, de a Visual Studio a 2013-as verziója óta annyira jó beépített tool-okkal rendelkezik, hogy már csak azokat futtatjuk automatikusan (igaziból minden egyes js mentéskor újra és újra fut out-of-the-box, a végeredményt már csak automatizáltan fel kell tolni CDN-be publishkor - nem szerver oldalról beszélek). A build utáni legelső http requestkor pedig generálódik egy hash, és amíg nincs új publish, addig azzal megy a js, css.
Én tök szívesen eszmét cserélnék veled (bár szerver oldalon nem js-ezek), és még értem is amit írsz, de annyira homlokegyenest eltérő fejlesztői környezetekben dolgozunk, hogy mégis kb. nincs miről beszélni. Mindenesetre jó látni amiket írsz, legalább jobban képben maradok a másik vonalat is látva.
-
Zedz
addikt
Édes istenem, ha a felét érteném már boldog lennék.
Amúgy a Googlenak mi volt a célja a Darttal? Tényleg úgy gondolják, hogy le tudják vele váltani a Javascriptet? Prog.hu-n volt egy cikk, hogy a JS népszerűsége egyre csak növekszik, akkor mégis mit akar a Google? Ráadásul nemrég beszéltük az ES6 újdonságairól, ami nem lesznek rosszak. -
Zedz
addikt
"Egyik haverom mondta tegnap, hogy majd nézzem meg a JS topikot, mert valami hülye mindig linkelgeti a fass***it, és, hogy tök jól elbeszélget magában."
Na neee.
(#4816) martonx: Nem feltétlen kérdéseknek kell itt lenniük. Én például szívesen olvasnék eszmecserét nálam jobbaktól, biztos sokat lehetne belőlük tanulni. A nemrég írt toolokról, ki hogyan old meg 1-1 bonyolultabb dolgot, ilyenek.
-
martonx
veterán
Szvsz nem attól lesz jó egy topik, hogy mennyire pörög lásd PHP topik elképesztő szinvonaltalansága, vagy webfejlesztős, CSS-es topikban a honda nevű hülyegyerek trollkodásai.
A fórumok egyébként már csak ilyenek. Aki ért hozzá, és nagy néha felmerül benne 1-2 mélyebb kérdés, az már inkább magától utánajár, utána olvas, nem pedig ezekben a fórumokban kérdez utána. Szükségképpen inkább az egyszerűbb kérdések jönnek elő.
-
Jim-Y
veterán
Lejárt...
Amúgy még én sem ástam bele az ES.next-be magam, mert azért jelenleg az ES5 még sokkal, sokkal elterjedtebb, de az a véleményem, hogy lassan már itt lenne az ideje, megismerkedni az újdonságokkal. Én kezdésnek ezeket fogom majd megismerni, mert az iojs ezeket támogatja alapból. Eddig ha pl csináltam egy szerber-api-t, akkor ahhoz node-ot használtam, de most már nem szól mellette semmi, tehát iojs-t fogok használni, amiben ezek támogatottak:
Which ES6 features ship with io.js by default (no runtime flag required)?
Block scoping (let, const, and function-in-blocks) (strict mode only)
Collections
Generators
Binary and octal literals
Promises
New String methods
Symbols
Template literals -
Zedz
addikt
Főiskolán volt egy óra, fél évig mondjuk azt "tanították" a JS-t, de mivel annyira unalmasan adták elő, nem is igazán érdekelt a dolog. Aztán főiskola után úgy voltam vele illene megismerni, és elkezdtem kicsit jobban utánanézni. Ez volt nyár eleje, akkor magamra szedtem egy minimális tudást + jQuery használatot, az elmúlt 1-2 hétben pedig ismét nekifeküdtem a dolognak, mert szeretném komolyabb szinteken űzni a dolgot.
Olvasom azt a pár könyvet amit még a múltkor ajánlottál valamelyik topikban az egyik fórumtársunknak, illetve ismerkedem ezekkel a toolokkal, keretrendszerekkel.
(#4808) Jim-Y: Így már érthetőbb a dolog!
-
Zedz
addikt
ES6 bocsánat, elírtam.
Ezt a "Browserify"-t már többször láttam említve, most gyorsan kicsit utánanéztem. Ez egy olyan tool, ami segít elszeparálni a JS kódunkat? Majd a végén egy bundlebe rakja őket?
Köszi a tippet, ez a 6to5 szimpatikusnak tűnik.
(#4803) Jim-Y akkor ezek már ES6 fícsörök?
-
Jim-Y
veterán
Például ha Reactos projekte van az embernek, és használ JSX-et és reactify-al buildeli, akkor ezeket a harmony feature-öket használhatja:
reactify transform also can compile a limited set of es6 syntax constructs into es5. Supported features are arrow functions, rest params, templates, object short notation and classes. You can activate this via --es6 or --harmony boolean option:
Mozillában tesztelve, próbáldd ki őket, scratchpadben mindegyik megy
arrow functions
============document.body.addEventListener('click', event => console.log(event.target));
rest params
=========function sum(a, b, ...rest) {
return Math.max(...[a,b].concat(rest));
}
console.log(sum(1,2)); // 2
console.log(sum(1,2,4,1,5,6,12,2,3)); // 12templates
========console.log(
`The max out of 1 and 2 is ${sum(1,2)}`
);
// "The max out of 1 and 2 is 2"object shorthand notation
===================var myModule = function() {
var newMax = function(a, b, ...rest) {
return Math.max(...[a,b].concat(rest));
};
var oldMax = function() {
return Math.max.apply(Math.max, [].slice.call(arguments));
};
// old syntax
// return {
// oldMax: oldMax,
// newMax: newMax
// };
return {
oldMax,
newMax
};
};
console.log(
myModule().oldMax(1,2,3,4,9,3,4,5)
); // 9classes
======// In iojs/node
class Topic extends EventEmitter {
constructor() {
super();
}
publish() {
this.emit('article');
}
subscribe(subscriber) {
// subscribe
}
}És nincs felsorolva, de a destructuring is műküdik:
destructuring
==========var React = require('react'),
{ Route, DefaultRoute } = require('react-router'),
{ AppComponent, Contact, Content } = require('./components/Screens'),
baseUrl = require('../appConfig.json').app.baseUrl;
module.exports = (
<Route name="home" path={baseUrl} handler={AppComponent}>
<Route name="contact" path="contact" handler={Contact} />
<DefaultRoute handler={Content} />
</Route>
); -
#4798
Sk8erPeter
nagyúr
Jim-Y
#4797
Sk8erPeter
nagyúr
Pedig csak a következő menüpontra kellett volna kattintanod.
http://imakewebthings.com/waypoints/guides/jquery-zepto/"Prior to version 3.0, Waypoints was strictly a jQuery plugin. You'll notice most of the examples on this site use code that is compatible with the new no-framework build of Waypoints using class instantiation and generally available DOM querying methods, like this:
var waypoint = new Waypoint({
element: document.getElementById('new-operator'),
handler: function(direction) {
notify(this.id + ' hit')
}
})
If you're using the jQuery or Zepto builds, you can still use the no-framework approaches featured in the documentation, but those builds also provide extensions specific to the framework."Aztán egy példa:
var waypoints = $('#options-only').waypoint({
handler: function(direction) {
notify(this.element.id + ' hit')
}
})wis itt korábban már linkelt egy működőt.
Tehát az van, amit mondott, hogy csak simán rossz fájlt használ, vagy rossz az elérési út. -
#4724
Sk8erPeter
nagyúr
Jim-Y
#4722
Sk8erPeter
nagyúr
"De amugy szerintem a FF-ban nincs olyan ami a DevTools-ban ne lenne, inkább fordítva van"
Pedig de, a FF inspectora alapértelmezetten egy-két apróságban okosabb (azt leszámítva, hogy ezt asszem nem lehet bővíteni extension segítségével), például a beépített EyeDropper, meg a 3D View ([link]) kifejezetten hasznosak tudnak lenni.
Persze a legtöbb dologra elég a Chrome sajátja is (én is azt használom gyakrabban, mert a Firefoxot nem sikerült megszeretnem a GUI relatív vánszorgóssága miatt). -
#4706
Sk8erPeter
nagyúr
Jim-Y
#4705
Sk8erPeter
nagyúr
Jelen példám ilyen tekintetben tényleg rossz volt, ebben teljesen igazad van: jelen esetben tényleg jobb lett volna -1-gyel visszatérni, ha nem találtuk meg a megfelelő indexet (ellenkező esetben meg épp az indexszel térünk vissza, ami szintén egész szám). Cseppet sem tekintendő mintának a példa, gyors, pár perc alatt összekalapált kód (írtam is, hogy a tiéd sokkal ésszerűbb), annyiból viszont jó, hogy látszik belőle, mennyire könnyen megcáfolható az a hülyeség, hogy ne legyen több kilépési pont: itt épp egy ciklusból térek vissza azonnal, amint megvan a találat, hiszen a feladattal végeztünk, semmi értelme tovább tartózkodni a függvényben. Lehetne átadni egy változónak a talált értéket, majd break-elni a ciklust, vagy épp a feltételt a for ciklus fejlécében ennek megfelelően meghatározni, majd ezután visszatérni, de tökéletesen felesleges és ronda code bloat lenne.
-
Jim-Y
veterán
Annyit hozzatennek, hogy en ugy latom, hogy konzisztens tipussal kell/kene visszaterni. Tehat megsem latjuk ugyanugy, csak hasonloan.
Szoval figyelni kene arra (egy idealis vilagban), hogy ha a fuggveny alap esetben egy integer ertekkel ter vissza, akkor mondjuk hiba eseten is azzal terjen vissza csak mondjuk egy beszedes ertekkel. Pl -1. Vagy exception-t dobjon. De mondjuk ne legyen az, hogy a caller szamot var es a csillagok rossz egyuttallasa eseten meg stringgel ter vissza. Persze... sokszor ezt nem lehet betartani, de ha lehet, akkor azert jo erre is figyelni
Undefined-al explicit visszaterni tovabbra sincs ertelme
Bar a fene se tudja, jobban at kene gondolnom, mint amennyire most idom engedi. -
#4703
Sk8erPeter
nagyúr
Jim-Y
#4702
Sk8erPeter
nagyúr
1. Dehogynem, ez így jobb. Tegnap ez jött ki akkori agyi állapotomban, evvan.
Viszont jó, hogy mutattad ezt a módszert, jobb látni több, főleg jobb alternatívát.
2. Ja.
3. Valóban úgy van, hogy alapból undefined-dal tér vissza a függvény JavaScriptben, ha nincs explicite meghatározva a visszatérési érték, de szerintem meg gusztustalan egy olyan függvény, ami valamilyen feltétel nem teljesülése esetén egyből visszatér valamivel, egyébként viszont semmilyen visszatérési érték nincs (ha a feltétel teljesül); csak rábízod magad a nyelv ilyen szempontból ronda adottságára. Így csinálni, ahogy Te javasolnád, sokkal inkább antipattern, úgyhogy ezt a részt buktad. ![;]](//cdn.rios.hu/dl/s/v1.gif)
(Amúgy bocsi, hogy önhivatkozás, de ajánlanám még egyszer ebben a hsz.-emben az utolsó bekezdést. )
Főleg ha az ember más nyelvben is programozott, amiben az általad írt módszer még csak nem is működne, akkor hozzászokik, hogy már csak a kód olvashatósága tekintetében sem mindegy, hogy hogyan is van megvalósítva ez a rész (hogy egyik helyen explicite kiírod a visszatérési értékét a függvénynek, egyszer nem, majd lesz valahogy). Na meg nem biztos, hogy undefined-dal akar az ember visszatérni, lehet, hogy null-lal, vagy false-szal, vagy -1-gyel, vagy akármivel, tervezői kérdés; az undefined csak egy lehetséges példa volt.
Múltkor elvileg épp az ilyen apróságokról beszéltél, ami jobb fejlesztővé tehet valakit, és amitől olvashatóbb kódot produkál, hát most mi ez az ellentmondásosság? (#4700) ^Boss:
Elég beszédes a függvényedben az a rész, ahol appendeled a <table>-t, meg annak a lezárását, hát tedd ezt a részt bizonyos feltételektől függővé, hogy csak akkor appendeljen, ha valamilyen feltétel teljesül, egyébként ne. -
Zedz
addikt
Húú igen, elfelejtettem megjegyezni, hogy kifejezetten weboldal készítésre gondoltam. Nemrég használtam egy JS-es galéria nézegetőt, megnéztem a kódját és ott is contructor objectet használ az illető.
jQuerynél miért kell azt példányosítani? Pl. nem lenne elég egy object literál függvényeit használni?
(#4691) Sk8erPeter Írni akarok egy olyan eszköztárat, amit a jövőben több oldalnál is fel tudok használni. Mondjuk ha csak validálni akarok egy formot, akkor mondjuk meghívom az app.validator-t, átadom a megfelelő értékeket és végzi a dolgát. És itt merült fel bennem a kérdés, hogy az "egyszerűbb" weboldalaknál miért kellene nekem constructor objektumot írnom? Pedig ahogy elnézem a frameworkök, előre megírt pluginok is ezt preferálják.
-
-
#4676
Sk8erPeter
nagyúr
Jim-Y
#4674
Sk8erPeter
nagyúr
"Amúgy szerintem ugyanúgy gondoljuk a dolgokat, szóval ez inkább chit-chat, mint veszekedés.
"
Mindig le vagyok döbbenve, hogy emberek mit tudnak "veszekedésnek" tekinteni. (Most nem rólad beszélek, mert te is inkább chit-chatnek látod, de attól még van ez a jelenség. ) Épp ezért van talán, hogy több szakmai topicban is cseszegetésnek veszi egy csomó ember (most inkább nem említenék példákat, annyit segítek, hogy a Weblapkészítés topicban volt mostanság), és azonnal megsértődnek, ha elkezdünk velük vitatkozni, mert mi picit másképp látjuk a dolgokat, pedig ezekből a beszélgetésekből kisülhet valami hasznos is. Most is szerintem csak dumálunk, konstruktívan vitatkozunk, bennem fel sem merült egy pillanatig sem a "veszekedés" gondolata sem. Viszont ha már "szerencsétlennek" minősíted a példámat, akkor legalább figyelj oda, hogy mi van odaírva.
Egyrészt az, hogy pszeudokód, másrészt pont rossz a "ha ilyet írnék le" rész után írt példád (mondhatnám, szerencsétlen ), mert pont nem azt a példát mutattam, hanem az értékátadósat: tehát az ELSŐ példánál EGYSZER van visszatérés, így a nálad írt egyszeri return smtg-nek felel meg. Az, hogy most booleannel vagy mivel térek vissza, az azt hiszem, egy pszeudokódnál kb. qrva mindegy, főleg, hogy az nem kell, hogy JavaScript-kódnak feleljen meg (akkor helyettesítsd be más nyelvvel, és jó lesz a példa) - itt a helyzet érzékeltetése volt a lényeg, nem gondoltam, hogy ezen a szinten kerül kielemezésre a kód...
A második példának meg pontosan az a lényege, hogy TÖBB return is van: azonnal visszatérek a függvényből, amint jól látható, hogy abban a függvényben már nincs több dolgom, mert pl. valami alapvető feltétel nem teljesül - akkor minek egy óriási indentált else-blokkot fenntartani még, és a return szócskát majd csak AZUTÁN kiírni, miután az a blokk is végre befejeződött, csak azért, hogy a return szócska ne szerepeljen még egyszer, meg azért, mert valami bácsi vagy néni azt mondta, hogy lehetőleg egy darab kilépési pont legyen?
Remélem, érthető. És a korábbi példát továbbra is tartom, mert a lényeget kifejezi, és mivel pszeudokód, nem kell feltétlenül JavaScriptnek, és az itt jellemző booleannel kapcsolatos szabályoknak megfeleltetni, ne csak egy nyelvben gondolkozz.
Ja, várj, még egy: most hogy jön ide a DRY? Azért, mert még egyszer le van írva a return szócska? Ne már...
Meg még a példád kapcsán az jutott eszembe, hogy ilyen alapon az is antipattern, mivel hiba esetén visszatérsz, de ha nincs hiba, akkor nem térsz vissza semmivel, ahogy említetted is, szól is érte az IDE... -
#4672
Sk8erPeter
nagyúr
Jim-Y
#4670
Sk8erPeter
nagyúr
Szerkesztettem közben a hsz.-t egyszerű példakóddal, kukkants rá.
"jobban átlátható lesz tőle a függvény"
Na ez az említett esetben pont nem igaz. Lesz egy bazinagy beljebb tolt else-blokkod, igazából tök értelmetlen, le lehetne rövidíteni, adott feltétel esetén azonnal visszatérhetnél a függvényből, és már ránézésre, kapásból lehetne tudni, hogy annál a pontnál tényleg eldőlt, hogy a kapott adatokkal vagy a környezet adott állása szerint nincs értelme tovább tartózkodni abban a függvényben.Szerintem egy fejlesztőt az tesz igazán jóvá, ha el tudja dönteni, adott kódrészletnél mi lenne az a megoldás, ami valóban áttekinthetővé teszi a kódot: kényszeresen erőlködik, hogy alkalmazzon egy patternt, mert azt mondták, hogy az bizonyos kontextusban igenis hasznos lehet, vagy pedig felfedezi, hogy adott esetre pont nem kell mindenáron ráhúzni.
Sok minta nagyon hasznos, ez is adott kontextusban az tud lenni, de itt sem lehet fekete-fehérre leegyszerűsített általánosságokat kijelenteni. -
Köszi!
Amit szeretnék, az a következő:
Van X darab kép. Ezeket szeretném a méretük szerint elrendezni.
A rendező kód akor futna le, amikor az összes kép betöltődött, ezáltal tudjuk már a dimenzióit.Utána nézek a callback-es megoldásnak és a flag-nek is.
Viszont a flag-es megoldás miben különbözik attól, amit én csináltam, vagyis egy globális változó tárolja azt, hogy melyik kép van betöltve? -
-
#4596
Sk8erPeter
nagyúr
Jim-Y
#4594
Sk8erPeter
nagyúr
Hát abban a formában, ahogy írtad, ennek ellenkezője volt, legalábbis nem lehetett kihámozni belőle az utolsó bekezdésedben írtakat.
"Az autentikáció miatt pedig kell(ene) majd
* vagy valami szerver oldali dolog
* vagy kliens oldali javascript
* vagy mindkettő"
Ez azt jelentené, hogy lehet választani, pedig itt nagyon nincs vagy-kapcsolat, hanem csakis és-kapcsolat lehet a kettő között, tehát kizárólag az utolsó opció (mindkettő) játszik.(#4595) martonx:
Hát biztos vannak ilyenek, nem ismerem őket. Pölö tudsz ilyet? -
#4593
Sk8erPeter
nagyúr
Jim-Y
#4590
Sk8erPeter
nagyúr
Szerintem félreértetted a dolgot, ez egy HTML+JS-alapú teszt, nem pedig Wordben lévő teszt, csak a gond vele, hogy egy undorító ötezer éves tákolmányról van szó, borzalmasan elavult, és amúgy is ronda kóddal.
Amúgy ha már új megközelítésről beszélünk, akkor a kliensoldali JavaScript-kód nem tudom, hogy jön az autentikációhoz (szerk.: értsd: ha már újonnan elkészítjük, ne tudják már megnézni a jelszót a forráskód böngészésével... írta, hogy ha már valaki ilyet is tud, akkor megérdemli azon a tanfolyamon az 5-öst, de azértmárna). -
Agony
aktív tag
Szia!
Valóban felesleges volt a nekiesés, mert én is csak egy ismerősömnek szerettem volna segíteni és PH fórum más topicjaiban jelen lévő segítőkészséget feltételezve tettem fel a kérdést.
Nem vagyok javascript programozó, aki ki szeretné töltetni ezeket az 1000 éves teszteket pár diákjával szintén nem javascript programozó és nagy valószínűséggel pár gagyi teszt kitöltéséért senki sem fog megtanulni programozni, de bizonyára vannak olyan emberek akik csak mert egyszer repülni szeretnének pilóta vizsgát tesznek.
Nyilván nem szeretném hozzáértő emberek idejét lopni, ezért tettem fel a kérdést, hogy valami vállalható összeg és idő ráfordítás árán meg tudná-e nézni valaki...
Minden esetre köszönöm az építő jellegű hozzászólást, a kérdésemet egy kedves fórumtársatok megválaszolta, úgyhogy a továbbiakban igyekszem nem szakmaiatlankodni a topicodban. -
#4588
Sk8erPeter
nagyúr
Jim-Y
#4586
Sk8erPeter
nagyúr
Szerintem meg most elég felesleges volt a nekiesés, nyilván nem vágja a témát, így gondolom nem is próbálja magától megcsinálni. Lehet, hogy nem tartana sokáig elmagyarázni neki, mi a pálya a kóddal, hogy lehet működésre bírni a tákolmányt, ha lenne említésre méltó szabadidőm, akkor még meg is kukkantanám ingyé' is, de most nem alkalmas. Mondjuk azt is megértem, hogy ezer éve készült kódok további tákolásában nem nagyon akarnak asszisztálni a zzemberkék.
-
#4539
Sk8erPeter
nagyúr
Jim-Y
#4538
Sk8erPeter
nagyúr
Szerinted a selectorok csak a jQuery miatt érdekesek?
Sajnos ez most nem volt túl értelmes önigazolás, hogy nem komálod a jQuery-t. 
Egyrészt ugye kezdjük a selectorokat a CSS-nél. Ha nem vágod a selectorok működését, nem vágod a CSS működését. Aztán a selectorokra építve ott van a .querySelector() (document/Element), .querySelectorAll() (document/Element) is.
Meg ott van a Sizzle JavaScript Selector Library, ami pure JS. Ezt használja a jQuery. -
#4537
Sk8erPeter
nagyúr
Jim-Y
#4536
Sk8erPeter
nagyúr
Hogy tudtál eddig működő kódot írni, ha nem tudtad, hogy működnek a selectorok?
Nehogy még véletlenül valami kezdő félreértse, inkább leírom, hogy van helyesen:
1.) '#content.inner'
- content azonosítójú ÉS inner class-szal ellátott elemre illeszkedik:<div id="content" class="inner">
...
</div>2.) '#content, .inner'
- content azonosítóval VAGY inner osztállyal ellátott elemre illeszkedik (az is jó, ha az egyik ezek közül nincs meg, vagy ha ugyanarról az elemről beszélünk, és mindkettő igaz rá, de ezt most szándékosan kihagyom a példákból, nehogy valakit megtévesszen) - hiszen felsoroljuk, mely elemeket szeretnénk kiválasztani:erre is illeszkedik (szándékosan különraktam, nem hierarchikusan):
<div id="content">...</div>
<div class="inner">...</div>erre is (egy másik elembe van ágyazva, de tök mindegy):
<div id="content">
...
</div>
<div id="anotherone">
...
<div class="inner">...</div>
...
</div>és erre is (itt egymásba ágyazva szerepelnek):
<div id="content">
...
<div class="inner">...</div>
...
</div>3.) '#content .inner'
- a content azonosítóval ellátott elemen belüli, inner osztállyal ellátott elem(ek)et keressük (egymásba ágyazott struktúra):<div id="content">
...
<div class="inner">...</div>
...
</div> -
Heló!
Köszönöm az elemzést!
A változónevekre figyelni fogok.
A K&R style-t azért használom, mert én így jobban átlátom a kódok kezdőként, egyébként nem C++-ból jövök, hanem a 17 évvel ezelötti középiskolás pascal-ból.
Igyekezni fogok ezt is megszokni.
Hinter tool-t keresek majd a Bluefish-hez, bár lehet hogy áttérek másra.
Viszont ami most megfogott.
A a változót azért raktam külön, hogy ne a ciklusban fusson le minden alkalommal.
Egy függvénybe kellene tennem? -
Heló!
A példáidat sajnos nem tudtam az én kódommal összehozni, ezért úgy döntöttem, hogy csak az elméletet használom fel belőle (enclosure), és kerestem erre a neten példákat, és ez lett a működő eredmény:
{
var c=document.getElementById("myCanvas");
var ctx=c.getContext("2d");
var files = document.getElementById("files-upload").files;
var imageObj = [];
var betolt = function(i,b,a)
{
imageObj[i].onload = function ()
{
ctx.drawImage(imageObj[i], b, 0, d, a);
};
};
a = ( 1920 - (files.length - 1) ) / ( files.length );
for (var i = 0; i < files.length; i++)
{
b = ( a + 1 ) * i;
imageObj[i] = new Image();
imageObj[i].src = "útvonal"+files[i].name;
betolt(i,b,a);
}
}A problémát a te példáidnál az okozta, hogy nem értettem a három közti különbséget és a szintaktikát - pl. a kapcsos zárójel után írt (i), vagy az, hogy egy zárójelen belül van egy függvény az onload jobb oldalán, vagy a settimeout-os Image függvény értelmét sem értem. Ezt mind a kettes példából vettem.
Persze, utána fogok nézni mindegyiknek, mert ez így nem állapot, hogy ilyen alap dolgokat nem tudok, csak most nem hagyott nyugodni a dolog és működésre akartam bírni olyan módszerrel, amit értek.
Remélem, nem "csúnya" nagyon a kódom.Ezen kívül van még egy kérdésem: A betöltött képeket szeretném mouse scroll segítségével átméretezni úgy, hogy a kép nem lép ki a rendelkezésére álló keretből, hanem levágódik a széle, ami nem fér ki - persze egérrel lehetne drage-elni is a képet. További funkció lenne az egymás melletti képek közti választóvónal eltolása.
Összességében egyfajta montázs progit akarok csinálni - egyelőre csak egymás melletti képekkel, átfedés nélkül.
Egyelőre még nem jártam sikerrel, de felmerült egy kérdés ezzel kapcsolatban: elég ehhez egy canvas, vagy érdemesebb képenként klön canvas-t létrehozni? -
sztanozs
veterán
Persze - plusz cookie-t vagy form változót tudsz csinálni, de szerver oldalon attól még bele kell "szinkronizálni" a változók közé. Nem js-sel hozod létre a session változót, hanem szerver oldalon van egy olyan hátsó ajtód, ami a klienstől kapott adatokból plusz session változót csinál...
Amúgy biztonsági szempontból szerintem kifejezetten nem ildomos kliens oldalról session változókat manipulálgani...
-
#4449
Speeedfire
félisten
Jim-Y
#4444
Speeedfire
félisten
Nem szándékozom saját MVC-t írni, egyszerűen csak próbálom megtalálni a megfelelő struktúrát egy js app-hoz.
Köszi a prototype példát.
Arra gondoltam, hogy a model1-et egyszerű bővíteni a mode1.megvalami-val, de a model2-t már csak prototype-al lehet.var model1 = {
valami: function() {};
};
model1.megvalami = function() {};
var model2 = (function(store) {
var view = {};
view.store = function() {};
view.getProducts = 'product';
store.viewModels = view;
return store;
}(window.store || {}));
martonx: Félreértesz. A store.viewModels csak egy konténer lenne a többi viewModels-nek.
De közben rájöttem, hogy single page app alatt valóan elég egy viewModel (ko alapokon), ami a "controller". -
-
#4434
Speeedfire
félisten
Jim-Y
#4431
Speeedfire
félisten
Most még jobban belekavarodtam.
Az 1. példában ezek szerint valóban nincs szükség return értékre.
A 2. példában nem lesz átláthatatlan, ha sok osztály van a store alatt? Mert itt lényegében létrehozod a store golobális változót, majd mindent alá pakolsz. Vagy ilyenkor prototype-ot használsz?
A 4. nem tűnik rossznak, a require-t, amúgy is használni szeretném idővel.
-
-
#4430
Speeedfire
félisten
Jim-Y
#4429
Speeedfire
félisten
De ha nagy az alkalmazás, akkor is szükség van névterekre vagy nem?
Erre gondoltam:
store.viewModels.store = function() {
var view = this;
view.products_list = ko.observableArray([]);
view.selectedProduct = ko.observable(false);
view.selectedProductsData = ko.observable(null);
view.selected_image = ko.observable(0);
view.gallery = ko.observableArray();
view.getProducts = function() {
$.ajax({
dataType: "json",
url: 'js/products.json',
success: function (data) {
//view.products_list(data);
view.products_list($.map(data, function(item){
return new store.models.product(item);
}));
}
});
};
view.goToProduct = function (product) {
$.ajax({
dataType: "json",
url: 'js/product.json',
data: {
"product_id": product.product_id
},
success: function (data) {
view.selectedProductsData(data);
view.selectedProduct(true);
view.setGallery();
}
});
};
view.setSelectedProduct = function () {
view.selectedProduct(false);
view.selectedProductsData(null);
};
view.setGallery = function () {
var gallery = [];
var product = view.selectedProductsData;
gallery = $.map(product().gallery, function(item){
return new store.models.Gallery(item);
});
view.selected_image(gallery[0]);
view.gallery(gallery);
};
view.setSelectedImage = function (image) {
view.selected_image(image);
};
return view;
};Nekem ez jobban bejött, mint pl amikor a functiók vannak a return értékben. Vagy a return-ben hivatkozok a private metódusokra.
Az require lesz a következő, aminek neki szeretnék esni. Csak ezt a pure js-t helyre kell még raknom.
-
#4428
Speeedfire
félisten
Jim-Y
#4427
Speeedfire
félisten
Az n+1-edik tutoriálban láttam hasonlót, ahol a namespace-eket előre felvette. Sok értelme nem hiszem, hogy van.
De ha írok egy funciót, ami egy másik funckióban van és vissza kell térnem valamivel, hogy publikus legyen az a metódus. Vagy nem?
Lehet nézegetnem kellene még a pattern-eket. Az a baj, hogy komplett alkalmazás pattern-t nem láttam még seholsem.
-
martonx
veterán
-
#4409
Sk8erPeter
nagyúr
Jim-Y
#4405
Sk8erPeter
nagyúr
Bevallom, számomra ez a
function getName() {
return name;
}
return {
getName: getName
};illetve
function getName() {
return name;
}
self.getName = getName;pattern még mindig kaotikus - mi van, ha 30 metódusra van szükségem, 30-szor kell kódot ismételnem (self.getName = getName, self.tokmindegy = tokmindegy, stb.)?
Amúgy jelen esetben miért nem elég ez (kódismétlés nélkül)? --> http://jsfiddle.net/4sj41ku5/6/var App = (function() {
/**
* @private
*/
var name = 'My App';
return {
/**
* @public getter
*/
getName: function() {
return name;
}
};
}()); -
#4407
Speeedfire
félisten
Jim-Y
#4405
-
#4399
Sk8erPeter
nagyúr
Jim-Y
#4398
Sk8erPeter
nagyúr
Szerintem bad practice-eket megosztani Smarty.js néven nem túl jó ötlet...
Akkor már írd oda, hogy mit NE, és mit IGEN. Ne csak a NE-megoldás legyen ott...
Nem beszélve arról, hogy már csak azért is rossz a kód, mert nincs típusellenőrzés sem, nem biztos, hogy az átadott változónak (ami nem biztos, hogy típushelyes) létezik egyáltalán .length property-je. -
#4379
Sk8erPeter
nagyúr
Jim-Y
#4378
Sk8erPeter
nagyúr
Azért azt nem árt kihangsúlyozni, hogy lokálisan nem működik...
De nem is így szokás tesztelni fejlesztéskor, úgyhogy nem hiszem, hogy ez releváns kellene, hogy legyen (egy helyi webszervert feltenni pár kattintás, akár IIS-ről, akár Apache-ról van szó).
A második megoldás is JÓ, sőt, akár jobb is lehet! Annyiban egyszerűsít a dolgokon, hogy az aktuálisan használt protokollt fogja használni a betöltött URL-eknél is, akár pl. http-ről, akár https-ről van szó, nem kell bedrótoznod a használt protokollt! (Létezik olyan oldal, ami elérhető http-n és https-en is. Ezzel a módszerrel nem kell kutyulni a használt protokollokat.)Persze nem meglepő módon van szócikk erről is stackoverflow.com-on:
http://stackoverflow.com/questions/9646407/two-forward-slashes-in-a-url-src-href-attribute -
#4363
Sk8erPeter
nagyúr
Jim-Y
#4360
Sk8erPeter
nagyúr
"By the way ... [link]"
Fasza, és tényleg működik:
https://www.jetbrains.com/student/
Megkaptam a visszaigazoló e-mailt @hszk.bme.hu-s címmel regisztrálva, ez a "JetBrains Product Pack for Students" licenc 2015 szeptemberéig érvényes ezekre a termékekre:
IntelliJ IDEA
ReSharper
AppCode
PhpStorm
PyCharm
RubyMine
WebStorm
dotCover
dotTrace
dotMemoryEz így korrekt. Na, ha már ilyen rendesek voltak, adok még egy esélyt majd a WebStormnak/PHPStormnak.
A ReSharper meg Visual Studio-ban C#-kódoláshoz állítólag komoly mankó tud lenni. -
Zedz
addikt
-
cSuwwi
senior tag
A grunt (vagy akkor már inkább gulp) automatizált dolgainak jó része kiváltható egy jól beállított editorral.
Én pl. Sublime 3-at használok, lintelés (js, php) pár kattintással megoldható. Jobb is, mert kódírás közben már jelez ha gond van. Atommal is jól mennek az erős(?) nodejs támogatás miatt, bár W7-en tragikusan lassú.
Gulppal marad a minify, uglify, de főleg a sass konvertálás. Jó dolgok ezek, tényleg sok a helper tool mostanság. Aki még dolgozott a "hőskorban", amikor nem volt firebug meg egyéb toolok, akkoriban egy élmény volt debugolni de simán sitebuildeni is.
Köszönöm a segítséget.
De tenyleg, akkor csak -.-
(még ha alkalmazzák is)
Amúgy a Googlenak mi volt a célja a Darttal? Tényleg úgy gondolják, hogy le tudják vele váltani a Javascriptet? Prog.hu-n volt egy cikk, hogy a JS népszerűsége egyre csak növekszik, akkor mégis mit akar a Google? Ráadásul nemrég beszéltük az ES6 újdonságairól, ami nem lesznek rosszak.
Mondjuk eddig ha ebből indulunk ki, és jól fut nálam is a DevTools, akkor eddig nekem a Firebug közelebb áll, talán egy picit "letisztultabb" számomra.![;]](http://cdn.rios.hu/dl/s/v1.gif)
Egyrészt ugye kezdjük a selectorokat a CSS-nél. Ha nem vágod a selectorok működését, nem vágod a CSS működését. Aztán a selectorokra építve ott van a 
Új hozzászólás Aktív témák
Hirdetés
- AKCIÓ! Intel Core i9 13900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- Bomba ár! Lenovo X1 Yoga 1st - i7-6G I 8GB I 256SSD I 14" WQHD Sérült I W10 I CAM I Garancia!
- ÁRGARANCIA!Épített KomPhone i3 10105F 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- AKCIÓ! GIGABYTE B360 i5 9600K 16GB DDR4 512GB SSD RX 7600 8GB Rampage SHIVA Zalman 600W
- Csere-Beszámítás! Számítógép PC Játékra! I5 14400F / RTX 4060ti 16GB / 32GB DDR5 / 1TB SSD
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest