- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- 185 Hz-es kijelzővel és 9000 mAh-s akkuval jöhet az új OnePlus
- Poco F8 Ultra – forrónaci
- Bemutatkozott az Oppo kamerás csúcsmodellje
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy A56 - megbízható középszerűség
- Telekom mobilszolgáltatások
- Fotók, videók mobillal
- Milyen okostelefont vegyek?
- Samsung Galaxy A55 - új év, régi stratégia
-
Mobilarena
Mobilarena
Új hozzászólás Aktív témák
-
Hmm, igaz.
Gondoltam rá, hogyha sokáig nem fut le a függvény akkor addigra megváltozik, de logikusnak tűnt a leírásom (mert szerintem úgy jó lehetne).
Hát egy megoldás rá, hogy .bind-al adod neki az értéket this-ben viszont így a függvény this-je ugye eltűnik, de ha ez nem gond, akkor megoldás lehet. példa
-
Nem kell átadnod, egyszerűen csak használd fel a path változót a callback függvényben.
$("#list").append('<li>' + path + ': ' + musicProperties.artist + ', ' + musicProperties.title + '</li>');
Itt egy példa.
Már gondolkodtam ezen, hogy honnan tudja az értékeket, bár nem kerestem, és most hirtelen nem is találtam erre konkrét leírást. Aki tudja pontosan, leírhatja, mert engem is érdekelne.
Amúgy én úgy gondoltam, hogy amikor meghívsz egy függvényt függvény paraméterrel, akkor a paraméterfüggvényeket interpretálja és az adott scopeban levő változók ha megjelennek a függvényben (persze úgy ha ott írod le a függvényt, nem előre definiálod), azokat kicseréli az adott értékekre (konkrét szám, mutató akrámi) és így fut le a függvény.Nem egészen, ha ezt tenné, szerintem az összes callback hívásnál a path az utolsó név lenne.
Itt egy példa, ahogy próbáltam rekonstruálni a dolgot a WinJS alapján
-
Nem kell átadnod, egyszerűen csak használd fel a path változót a callback függvényben.
$("#list").append('<li>' + path + ': ' + musicProperties.artist + ', ' + musicProperties.title + '</li>');
Itt egy példa.
Már gondolkodtam ezen, hogy honnan tudja az értékeket, bár nem kerestem, és most hirtelen nem is találtam erre konkrét leírást. Aki tudja pontosan, leírhatja, mert engem is érdekelne.
Amúgy én úgy gondoltam, hogy amikor meghívsz egy függvényt függvény paraméterrel, akkor a paraméterfüggvényeket interpretálja és az adott scopeban levő változók ha megjelennek a függvényben (persze úgy ha ott írod le a függvényt, nem előre definiálod), azokat kicseréli az adott értékekre (konkrét szám, mutató akrámi) és így fut le a függvény. -
Sk8erPeter
nagyúr
Na akkor, sorra veszem.
1. Csak jQuery:
var foo = $('.foo')
foo.css('color', '#CCC')
foo.css({
'font-size': '14px'
, width: '250px'
})
Ennek a sebessége átl. 160-170ms.2. Styled I. változat:
var foo = $('.foo').styled()
foo.set('color', '#CCC')
foo.set({
'font-size': '14px'
, width: '250px'
})
Ennek a sebessége átl. 5-6ms.3. Styled II. változat:
var foo = $.styled('.foo')
foo.set('color', '#CCC')
foo.set({
'font-size': '14px'
, width: '250px'
})
Ennek a sebessége átl. 0-1ms.A II. azért gyorsabb mint az I., mert az I.-ben van egy függvényhívás először: $('.foo') és ennek a időt vesz a lefutása (a 2 közti különbség). A II.-nál pedig csak egy stringként átadom a selectort.
Ja hogy így!
Ez volt a lényeg, hogy stringként adod át, erre kérdeztem rá.
($.styled('.foo'))Mondjuk nem mintha az 1 ms versus 5 ms különbséget túl sűrűn lehetne releváns különbségnek nevezni.
De mindenesetre azt bizonyítja az összes teszt, hogy abban az esetben igencsak megfontolandó a plugined használata, amennyiben RENGETEG elemről van szó, amit egyszerre kell módosítani.
Mondjuk a felrakott tesztedben egyértelműen érezhető, hogy a jQuery-s .css() módosítás mennyivel lassabb. Mármint számok ismerete nélkül érezhető.==================
(#2849) Karma :
ez kurva jó.
Amúgy ez tényleg csak viccnek jó, mert az AJAX-os rész azért már igencsak sántít, mert a kód nem cross-browser megoldást mutat.
Na de nem kötekszem. -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Látod ez túl egyszerű és ésszerű volt, hogy eszembe jusson.
Itt ki lehet próbálni a tesztet, konzolba írja az időt. Nekem jQuery-re átlagba 160-170ms-t adott, styled-ra 0-1ms-t. Bár most annyi változtatás történt, hogy észrevettem például az hogy $('.foo') időt vesz el (átl. 3-5ms) míg megcsinálja az objektumot (de bennmaradt, mivel szerintem ez szebb, meg ha valaki olyat csinál, hogy $('body').find('.foo'), akkor abból ő összerak egy selectort). Ezért hozzáadtam egy ilyen végrehajtási módot is.Ez elég durva különbség....
Mondjuk azt nem értettem, miért úgy mérted az időt, hogy a kezdeti időnél new Date()-et használsz, a végénél meg Date.now()-t, akkor már legyen következetes. Mármint az alábbi résznél:
var start = new Date();
...
var end = Date.now();
Nem sok teteje van.
"Ezért hozzáadtam egy ilyen végrehajtási módot is."
Példa a használatra? -
Sk8erPeter
nagyúr
Igazából nem nagyon ismerek benchmark-os oldalakat/programokat, ha tudsz akkor ajánlhatnál.
A Chrome Inspector-ban a Profile-al próbáltam méregetni. A CSS Selector Profiles-ban mértem le a 2 fajtát, styledal, és csak sima jQuery-vel, előbbi 2 mérésből 0 és 1ms, utóbbi 94 és 107ms lett. A CPU Profiles ezt adta jQuery-vel, styled-al.
Amúgy persze érthető, hogy miért lassabb a .css(), hiszen ennél mindegyik matched elementet sorra veszi, csinál belőle egy jQuery-nek megfelelő osztályú objektumot, metódusokkal stb. és ez mind időt vesz el. A styled meg szintén valamilyen módon sorra veszi az elementeket, de az már csak annyira, mint amikor a .css() megváltoztatja a style attribútumot és azt sajnos nem tudom, forráskód hiányában, hogy talán optimálisabb módon is akár. Memória szempontjából egyik se kérdéses, a styled alapból nem használhat sokat, a jQuery-s objektumokat meg a GC majd összeszedi gondolom.Semmi különös benchmarkra nem gondoltam.
Csak valami ilyesmire, ami milliszekundumokban mérve kijelzi a scriptek lefutása közötti különbséget:
var startTime, endTime, differenceInMilliseconds;
startTime = new Date();
for(var i = 0; i < 10000000; i++){
;
}
endTime = new Date();
differenceInMilliseconds = endTime - startTime;
console.log('difference in milliseconds:');
console.log(differenceInMilliseconds + ' ms');Itt a for ciklus helyére kerülne a Te kódod, így lehetne tesztelni a hagyományos jQuery-s és a styled pluginos lefutás közötti különbséget.
Egyébként most látom, MDN-en is van példa (csak már megírtam a fentit addigra):
MDN - Date// using static methods
var start = Date.now();
// the event you'd like to time goes here:
doSomethingForALongTime();
var end = Date.now();
var elapsed = end - start; // time in millisecondsMásik:
// if you have Date objects
var start = new Date();
// the event you'd like to time goes here:
doSomethingForALongTime();
var end = new Date();
var elapsed = end.getTime() - start.getTime(); // time in millisecondsLényegében ugyanaz, mint az enyém.
===========================================================
Egyébként érdekes, sokan nem hiszik el, hogy az Opera JavaScript-motorja márpedig igenis gyorsabb, mint a többi jelenlegi böngészőé. Ahogy azt sem hiszik el, hogy a Firefoxé lassú (ahogy lassú a Firefox általában).
Most lefuttattam egy tesztet a fenti, legelső kóddal a konzolból - tehát 10 millió lépéses for ciklus:Chrome 21.0.1180.83 m
Átlag: 9733 ms.
Firefox 14.01
Átlag: 20759 ms (!!!).
Opera 12.01 (x86)
Átlag: 2163 ms (!!!).
A Firefox tehát 3 mérés után átlagban 18596 ms-mal (!!!) lassabban végzett a feladattal, mint az Opera, Chrome pedig átlagban 7570 ms-mal hajtotta végre lassabban az Operánál; a Firefox 11026 ms-mal volt átlagban lassabb, mint a Chrome.
Az Opera tehát elég feltűnően nyert. Ezt a mérést még többször végrehajtottam, mindig hasonló eredményekkel zárult, legfeljebb 1-1,5 másodperc differencia volt az egyenként kijött eredmények között. A teszt idejére egyébként a legtöbb extensiont a böngészőkben letiltottam.
Számomra azért meglepő, hogy 10 millió lépésszámnál már ilyen szintű különbségek jönnek elő.
A Firefox GUI-ja egyébként a teszt idejére lényegében végig teljesen használhatatlan volt ("Not responding").A tesztgép pedig az adatlapomon is látható Lenovo Y570 (Intel Core i5 Mobile i5-2410M @ 2.30 GHz / 1066MHz / 3MB L2 - 2.9GHz Turbo Boost, Western Digital Scorpio Blue WD7500BPVT-24HXZT1, Intel HD 3000 / NVIDIA GeForce GT555M - 1GB GDDR5 VRAM, ...).
-
Sk8erPeter
nagyúr
+ (#2794) Karma :
bocs, most látom, hogy erre elfelejtettem reagálni, pedig ez egy jó téma.
A DOM CSS gondolom azért lehet gyorsabb, mert a böngésző "natívhoz közeli" dolgait piszkálod, nem pakolsz köré egy library-t (mármint itt a jQuery-t). De mennyivel gyorsabb ez egyáltalán?
Végül is attól még, hogy ilyen módon használja az ember, a böngészőnek ugyanúgy frissítenie kell minden elemet, ha az adott selectorra 100'000 elem illeszkedik, akkor annyit.
v2izzy, tudnál esetleg valami benchmark-szerű mérést csinálni erről?
Ha már így belementél a dologba... Kíváncsi lennék, milyen különbségeket lehet mérni, érdekes lehet egy ilyen eredmény. -
Sk8erPeter
nagyúr
Jaaa értem, tegnap nem esett le. Mondjuk abból, ahogy leírtad, nem is csoda.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Kösz, Karma.
Hogyan valósítottad meg, hogy a jövőben létrejövő elemekre is igaz legyen? Az .on()-nal, ahogy Karma említette? (most nincs időm átbogarászni a kódot, de kíváncsi vagyok)
Viszont így megint csak kérdés, hogy a .set()-nek ilyenkor mit kellene megvalósítania... az lenne a logikus ezek alapján, hogy akkor minden egyező selectorú elemre igaz lesz, hogy melyik fájlban van definiálva maga a stílus, az itt szerintem totál irreleváns. -
Sk8erPeter
nagyúr
Nem kell hozzáférni a css fájlhoz, én sem abból olvasom ki. A stíluslapok betöltődnek a DOM-ba és innen könnyen lehet kezelni őket, szóval egy értékadás nem a fájlt írja át hanem csak a DOM-ba. A .set()-et azért tartanám jónak, mert pl. olyan előnye (persze ez valahol lehet hátrány is) van a jQuery-s .css()-el szembe, hogy ez azután is igaz az egyező selector-ú elemekre miután miután a művelet végrehajtódott. Sebességbeli különbséget nem tudok, de kíváncsi lennék, meg kellene nézni. Plusz így nem tesz a html kódba egy ronda style attribútumot.
"olyan előnye (persze ez valahol lehet hátrány is) van a jQuery-s .css()-el szembe, hogy ez azután is igaz az egyező selector-ú elemekre miután miután a művelet végrehajtódott."
Ezt nem értem. Miért, a .css() miért ne lenne igaz a "művelet" végrehajtása után? Milyen "műveletre" gondolsz?
Vegyünk egy példát, van egy ilyened:
<div class="alma">ASD</div>
Nyomatsz egy ilyet:
$('.alma').css('color', 'red');Ez ennek végrehajtása után is igaz lesz.... persze fogalmam nincs, mire gondolhattál...
-
Sk8erPeter
nagyúr
Igen arra való. Kiválaszthatod, hogy melyik fájlban/fájlokban keressen, mert így gyorsabb lehet és csak ami selector-t a jQuery átad ($(selector).styled()), azt megkeresi és visszaadja. Még lehetne akár bővíteni olyannal hogy legyen egy .set() is, tehát lehessen változtatni a CSS-t.
Viszont amiben nem voltam biztos, hogy ha van több fájl és azokban valamelyik selectorhoz tartozó stílus többször is szerepel, akkor melyiket tartsam meg? Most úgy csinálja, hogy mindig ha a következő fájlban lévő felülírja a már szereplő stílusokat. Ez logikus, de nem tudom, hogy ez a legjobb megoldás. -
Sk8erPeter
nagyúr
Hello!
Nemrég felmerült egy olyan gondom, hogy el akartam érni CSS stílus értékeket JS-el de úgy hogy nem egy meglévő elem stílusát vizsgálom. Meg is találtam hogy el lehet érni, de elég hosszadalmas mire hozzá lehet jutni a kívánt értékhez. Keresgettem jQuery-ben valami szép megoldást rá (vagy nem jQuery-ben), de nem nagyon talátam. Úgyhogy csináltam egy kis plugin-t, ami a beadott selector szerint megkeresi az ahhoz tartozó stílusokat. Akinek van kedve nézze meg és lehet közreműködni is akár, mert lehet még javítani/plusz funkciókat bele tenni.+ részben ennek segítségével elkészült egy sportversenyeknél használt csoport és bracket készítő bundle-öm. Akinek netán ilyenre lenne szüksége.
</self-reklám>
-
Így már igen működik, bár az kicsit fura, hogy az obj-nak az area property-je a polygon, majd az egész obj-ot beleteszed a polygonba.
De hát így fog működni ezzel a módszerrel az igaz. Viszont itt egy példa ami szemlélteti, hogy különböző ciklusfajták hogy kezelik a handler függvényt. Ez alapján így is írhatnád:data = items;
data.forEach(function(x) {
...
var obj = {
'name': x[i-4],
...
'area': polygon
};
google.maps.event.addListener(polygon, 'click', function(event){
showArrays(event, obj, this.getPath());
});
google.maps.event.addListener(polygon, 'rightclick', function(event){
showContextMenu(event.latLng, obj);
});
...
})Köszönöm a példát.
Tudom, hogy a pop() függvény az utolsó elemtől megy végig az obj-on és ráadásul ki is veszi belőle az elemeket, míg a for és a foreach gondolom nem.
Szerintem át is írom ilyen alakra, amit írtál. -
Például egy új embernek, vagy neked később nehezebb lesz egyből megértened, mi is történik és szerintem egy .forEach() gyorsabb is mint így (bár ez csak nagy adatmennyiségnél lenne feltűnő).
Másrészt nem az volt kezdetben a gondod, hogy csak az utoljára kiszedett tömb elemei kerülnek bele? A pop-os módszerrel ez így is van, de ha forEach-el csinálod, akkor az eventListener-ek handler függvényében, mindig az aktuális elemet tudod felhasználni és akkor így nem szükséges id. Remélem jól értelmeztem a problémát.Az volt a gondom, hogy nem tudtam beletenni az összes adatot a korábbi módszeremmel az obj változóba, igazából nem értettem, hogy hogy kellene megvalósítanom a dolgot.
Nekem az adatok sorrendje teljesen mindegy, csak kirajzolom a polygonokat.
Jelenleg az alábbi módon valósítottam meg a dolgot, remélem nem csináltam benne programozói hibát (végülis működik
).function process_data(items){
var x;
var data = new Array();
data = items;
while ( x = data.pop())
{
var i = 5;
var y = x[i];
var obj = {};
var polygon = new google.maps.Polygon({
paths: google.maps.geometry.encoding.decodePath(String(y)),
strokeColor: "#0000ff",
strokeOpacity: 1,
strokeWeight: 1,
fillColor: "#00ffba",
fillOpacity: 0.4,
editable: false
});
polygon.setMap(map);
var obj = {
'name':x[i-4],
'description':x[i-3],
'address':x[i-2],
'wikipedia':x[i-1],
'points':x[i],
'category':x[i+1],
'parent_area':x[i+2],
'area':polygon
};
polygon.objInfo = obj;
google.maps.event.addListener(polygon, 'click', function(event){
showArrays(event,this.objInfo,this.getPath());
}); //kattintásra megnyílik az infowindow
google.maps.event.addListener(polygon, 'rightclick', function(event){
//this.setMap();
showContextMenu(event.latLng,this.objInfo);
});
infowindow = new google.maps.InfoWindow();
}
}
function showArrays(event,obj,vertices) {
var contentString = "<b>" + obj.name + "</b><br />";
contentString += "Leírás: " + obj.description + "<br />";
contentString += "Cím: " + obj.address + "<br />";
contentString += "Wikipedia: <a href='http://hu.wikipedia.org/wiki/" + obj.wikipedia + "'>hehe</a><br />";
contentString += "Kategória: " + obj.category + "<br />";
contentString += "Szülõ terület: " + obj.parent_area + "<br />";
contentString += "Clicked Location: <br />" + event.latLng.lat() + "," + event.latLng.lng() + "<br />";
infowindow.setContent(contentString);
infowindow.setPosition(event.latLng);
infowindow.open(map);
}A ShowContextmenu függvényt azért nem másoltam be, mert az még nincs kész.
-
Sk8erPeter
nagyúr
Ismerem a jQuery-nek ezt a funkcióját természetesen, de pont ez volt a célom vele, hogy egyszerűbben és szebben lehessen leírni a html-t js-be. És persze hogy elmehetnék jq-s irányba és string-ként átadhatnám, de pont nem ez a célom. A jQuery természetesen ezt csinálja, mert nekik nem ez a lényeg, hogy minden tag-hez külön fgv. stb. Pont ezért csinálom így, hogy valami pluszt adjon ez mondjuk a jQuery-shez képest. (Bár azért világmegváltó terveim nincsenek vele, de tanulásnak jó meg azért érdekesnek találom
)És ha összehasonlítod:
var img = $('<img />').attr({
'id': 'myImage'+img_index,
'src': 'http://doc.jsfiddle.net/_downloads/jsfiddle-logo.png',
'alt': 'JSFiddle logo',
'title': 'JSFiddle logo',
'width': 250
}).appendTo('#container');Ezzel:
huk('#container')
.img({
'id': 'myImage'+img_index,
'src': 'http://doc.jsfiddle.net/_downloads/jsfiddle-logo.png',
'alt': 'JSFiddle logo',
'title': 'JSFiddle logo',
'width': 250
})
.append();Szerintem utóbbi szebb (de lehet mert én írtam
)Meg azért nagy erőforrást nem emészt fel szerintem, minden tag-hez egy function pointert rendel, tehát nem klónozza a függvényeket a tag-ekhez. És akinek meg a custom tag kell (az esetek nagyon kis százaléka), annak meg arra is van lehetősége. Meg például a .list() fgv-t különösen hasznosnak találtam sokszor.
"A jQuery természetesen ezt csinálja, mert nekik nem ez a lényeg, hogy minden tag-hez külön fgv. stb."
Ja, hanem az a célja, hogy lehetőleg a legtöbb tagre működjön, és ne kelljen a böngészőtől megkapni arra vonatkozó komplett listát, hogy milyen tageket támogat.
Persze ha összegyűjtöd szorgalmas munkával a tagek többségét, aztán belerakod egy array-be, hát oké.
Nekem olyan nagyon nem csúf a jQuery-s szintaktika, amit mutattam.
A tiédnél annyi a különbség, hogy valóban jobban "szétválik", bár pár karakternyi különbség van, tehát szerintem lényegében irreleváns.Amúgy nyilván van haszna a pluginednek, félre ne értsd, most én nem akartam egy csöppet sem szembeállítani!
Jelen esetben csak azt vizsgálgattuk, hogy vajon van-e értelme minden tagről komplett lista alapján létrehozni egy hozzá tartozó "függvényt". -
Sk8erPeter
nagyúr
Jaaaaaa, értem, jó, így már felfogtam.
Szerintem erre nincs jobb, mintha stringként átadod úgy, ahogy a jQuery-nél lehet, pl. img tag dinamikus létrehozására a jQuery topicban épp mutattam példát: [link]
valahogy hasonlóan kellene megoldanod, persze akkor alternatív utat kell választani, nem ilyen "függvényszerűen" lehet meghívni (pl. div() ).
jQuery-kódban pl.:
// If a single string is passed in and it's a single tag
// just do a createElement and skip the rest
.....Aztán a végére eljutsz oda, hogy felfedezed a spanyolviaszt, és készítesz egy új jQuery-t.
-
Sk8erPeter
nagyúr
A komplett lista azért kell mert akkor tudom a prototypejába betenni az alap objektumnak a függvényeket (.div(), .span() stb).
Mikor elkezdtem csinálni, akkor még nem nagyon ismertem a DOM-ot, aztán így maradt eddig.
Nekem nem az a gondom, hogy nem valid tagokat akarnak megadni, azzal semmi gond (most is van benn egy addTag fn. hogyha valakinek van valami mása. Csak azt írtam, hogyha pl. kiiratod, hogy:
console.dir(document.createElement('asd'))
akkor a visszakapott objektum típusa HTMLUnknownElement
console.dir(document.createElement('div'))
akkor HTMLDivElement.
Ezzel csak azt akartam mutatni, hogy a valid tagok külön vannak kezelve, tehát valahol el vannak tárolva, hogy mik validok. De ez nem olyan lényeges, mivel ettől függetlenül is biztos el van tárolva.Lehet kellene csinálni egy jsFiddle-t, majd megnézem holnap, meg a jsLint-et is. Köszi!
"A komplett lista azért kell mert akkor tudom a prototypejába betenni az alap objektumnak a függvényeket (.div(), .span() stb)."
Nem néztem meg a kódodat, és biztos most nehézkes a felfogásom, de most még mindig nem jön át, mi az oka, hogy a createElementes megoldás miért nem elegendő ehhez (tehát ha valaki divet szeretne kreálni, akkor document.createElement('div');). Mit hagyok ki? Mihez kell a komplett lista konkrétan?Példakódra rátérve: én amúgy nem értem, a megfelelő sorok végére miért nem teszel pontosvesszőt.
Sokkal áttekinthetetlenebb így a kód, jó is, hogy a JSLint szól érte.
A korábbi kódot, amit az oldaladról szedtem, elég gyorsan JSLint-validdá lehetett tenni:
http://jsfiddle.net/Sk8erPeter/Pm6pg/1/
Így már szerinte is okés (a class-ból 'class' lett, különben nem jó, mert foglalt névre hivatkozik a JSLint).
Példa még mindig nincs a GitHub-oldaladon.
Amúgy ha bejelentkezel a JSFiddle-oldalon, és ennél a kódnál rámész, hogy "Fork", akkor máris a Te neved alatt fog megjelenni.=========
(#2578) Forza_JUVE :
OK, nincs mit, ha kell segítség, akkor másold be ide a kódot, hogy mivel próbálkoztál, és segítünk. -
A komplett lista azért kell mert akkor tudom a prototypejába betenni az alap objektumnak a függvényeket (.div(), .span() stb).
Mikor elkezdtem csinálni, akkor még nem nagyon ismertem a DOM-ot, aztán így maradt eddig.
Nekem nem az a gondom, hogy nem valid tagokat akarnak megadni, azzal semmi gond (most is van benn egy addTag fn. hogyha valakinek van valami mása. Csak azt írtam, hogyha pl. kiiratod, hogy:
console.dir(document.createElement('asd'))
akkor a visszakapott objektum típusa HTMLUnknownElement
console.dir(document.createElement('div'))
akkor HTMLDivElement.
Ezzel csak azt akartam mutatni, hogy a valid tagok külön vannak kezelve, tehát valahol el vannak tárolva, hogy mik validok. De ez nem olyan lényeges, mivel ettől függetlenül is biztos el van tárolva.Lehet kellene csinálni egy jsFiddle-t, majd megnézem holnap, meg a jsLint-et is. Köszi!
-
Sk8erPeter
nagyúr
Hát már régebben szerintem linkeltem, egy ilyen kis HTML kód generáló modulomhoz. Mert most ugye van egy tömb amibe összegyűjtögettem úgyahogy a tageket, de így azért mégsem az igazi.
Amúgy lehet teljesen, de majd meg látjuk újra írom az egész modult, mert most csináltam egykét tesztet és úgy tűnt ha DOM-os függvényeket (createElement, appendChild stb) használok, akkor gyorsabb (ti is mondhatnátok véleményt ha van tapasztalat (most csak egy objektumból generálok le egy stringet és azt illesztem be)). Szóval ilyen függvényekkel hoznám létre a HTML-t.
Nézegettem, és ugye a a createElement az bármilyen taget legenerál, de ha nem ismert az element akkor a visszaadott objektum HTMLUnknownElement típusú, viszont ha valami ismert, akkor HTML HTMLDivElement például. Tehát ezért is gondolom, hogy valamilyen módon benne vannak a létező tagek (meg hát amúgy is benne kellene lennie azért ), de jó lenne valahogy elérni őket.Speeedfire: ismerem, de mint fent írtam még nincs megoldásom.
-
Sk8erPeter
nagyúr
Hát már régebben szerintem linkeltem, egy ilyen kis HTML kód generáló modulomhoz. Mert most ugye van egy tömb amibe összegyűjtögettem úgyahogy a tageket, de így azért mégsem az igazi.
Amúgy lehet teljesen, de majd meg látjuk újra írom az egész modult, mert most csináltam egykét tesztet és úgy tűnt ha DOM-os függvényeket (createElement, appendChild stb) használok, akkor gyorsabb (ti is mondhatnátok véleményt ha van tapasztalat (most csak egy objektumból generálok le egy stringet és azt illesztem be)). Szóval ilyen függvényekkel hoznám létre a HTML-t.
Nézegettem, és ugye a a createElement az bármilyen taget legenerál, de ha nem ismert az element akkor a visszaadott objektum HTMLUnknownElement típusú, viszont ha valami ismert, akkor HTML HTMLDivElement például. Tehát ezért is gondolom, hogy valamilyen módon benne vannak a létező tagek (meg hát amúgy is benne kellene lennie azért ), de jó lenne valahogy elérni őket.Speeedfire: ismerem, de mint fent írtam még nincs megoldásom.
-
Sk8erPeter
nagyúr
-
Speeedfire
félisten
-
Speeedfire
félisten
-
-
Sk8erPeter
nagyúr
Pl. a konkrét problémám, hogy egy oldalon egy gombnyomásra előjön egy div középre pozicionálva és ha azon kívül kattintanak akkor zárja be, vagy mint pl. a facebook-nál ha az Account-ra kattintasz, akkor ha a megjelenő ul-en kívül kattintasz akkor eltűnik.
Remélem már érthető. -
Sk8erPeter
nagyúr
(
Na de nem kötekszem. 
Ha már így belementél a dologba... ![;]](http://cdn.rios.hu/dl/s/v1.gif)
).
Új hozzászólás Aktív témák
- Akció!!! Sosemhasznált! HP OmniBook 5 i7-1355U 16GB 1TB 16" FHD+ Gar.: 1 év
- Thrustmaster t-lcm pedál
- AMD FX-6300 CPU + ASUS M5A97 EVO R2.0 + GeForce GTX 1060 3GB
- Új - MacBook Pro M5 Pro Chip 14" 15C / 16C / 24 GB RAM / 1TB SSD / Silver / Black - 27% Áfás
- Dell Precision 5560 i5 11500H 16GB 256GB SSD 1920x1200 Matt IPS
- BESZÁMÍTÁS! 8TB WD RED WD80EFAX HDD meghajtó garanciával hibátlan működéssel
- 0% THM 4 havi részlet, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
- 15,6" Dell Latitude laptopok: E5550, E5570, 5590, 5500, 5501, 5510, 5520 / SZÁMLA + GARANCIA
- Apple iPhone 11 128GB, Kártyafüggetlen, 1 Év Garanciával
- Xbox Elite Series 2 kontroller 3 hó garancia, számlával!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest