-
Fototrend
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
-
Muton
addikt
válasz Sk8erPeter #2798 üzenetére
Köszönöm! << így már jobb
Tehát akkor a $('#simplestring') egy több cuccból álló valami, aminek a string ('data-string') attributumát adja vissza.
meg lehet ezt csinálni két bemeneti mezővel (hogy ne csak egy textboxa legyen, anem kettő), vagy a simpledialog nem tudd ilyet? ha meg meg lehet, akkor ez értékadásnál honnan tudja, hogy a megkapott két stringből meyliket adja vissza?Muton#2316 - $z@r a drop >_<
-
Muton
addikt
Azt hogy lehet megoldani, hogy a body onloadban lefut egy függvény, ami kimenete egy id, és az az id-ő lap töltődik be, amelyik az init-ben meghatározódik. pl. leellenőrzi a rendszer, h be vagy-e logolva, ha igen, akkor a munkaterülettel (lappal) indul, ha meg ne, akkor meg a login lappal
olyan verziót tudok, hogy gombbal váltok lapot (vagyis div tartalmat) de fv-ből automatizálni nem tudom. eddig ilyenem van:<body>
<div data-role="page" id="welcome">
<p><a href="#login" data-role="button">Show page Login</a></p>
</div>
<div data-role="page" id="login">
<p><a href="#welcome" data-role="button">Show welcome page</a></p>
</div>
</body>[ Szerkesztve ]
Muton#2316 - $z@r a drop >_<
-
Sk8erPeter
nagyúr
Ezt a feladatot szerveroldalon kell elvégezni. Remélem nem kliensoldalon akarod leellenőrizni, az adott felhasználó be van-e jelentkezve...
(#2801) Muton : fogalmam sincs, soha nem használtam a jQM SimpleDialogot, az előbbit is csak a hivatalos doksi alapján mutattam. Mondjuk szerintem gáz a dokumentációja, mert elég gyér a demólapja. Összesen 3-féle demó? Az mi...
Nem igazán fejlesztettem még mobilra, de a jQuery UI Dialogja nem jó erre a platformra? Az sokkal jobban dokumentált, és egyszerű a használata.
De ha a SimpleDialoggal kell, én a helyedben rákeresnék, hátha vannak jóféle jsFiddle-demók róla, ami egyből elédtárja a megoldást.[ Szerkesztve ]
Sk8erPeter
-
Muton
addikt
válasz Sk8erPeter #2803 üzenetére
De, a klines végzi
Ez azért van, mert általában ha vki belogol, akkor bent is marad amíg ki nem lép, mert nem autentikáció miatt kell, hanem, hogy a szerveren az ő fakkjába menjenek az adatok. Szóval, ha valahogy kiürül a kes, és nincs meg a session id, akkor kezdjen a login-nal az app.
Meg mert felülről ez jött, hogy így csináljam (és akkor így kell), mert állítólag a usereket kikészíti a loginjajj, amúgy nagyon nem fekszik ez a jqm. most, hogy kezdem megismerni a js-t, erre egy teljesen más szintaktika...
Muton#2316 - $z@r a drop >_<
-
sztanozs
veterán
-
Sk8erPeter
nagyúr
Az érvelésed hibás, mert attól még, hogy mondjuk bejelentkezve marad a felhasználó, és nem csak addig, amíg a böngésző nyitva van (cookie), attól még szerveroldalon kell ellenőrizni azt, hogy a felhasználó be van-e jelentkezve, vagy sem, és attól függően megjeleníteni a bejelentkező felületet, vagy a bejelentkezés után látható tartalmat. Persze lehet ezt komplikálni úgy, hogy van egy "kerete" az oldalnak, ami mindig megjelenik, aztán AJAX-szal indítasz egy kérést a szerver felé, ami az érdemi tartalmat megjeleníti, és akkor így is-úgy is elmegy a szerver felé a kérés, és a szerver felől pedig aszerint dobod vissza a tartalmat (a bejelentkező ablakot vagy épp az "irányítópultot") - de ez a lényegen akkor sem változtat, hogy a szerveroldalon kell elvégezned annak az ellenőrzését, hogy be van-e jelentkezve.
Szerk.:
de hogy az eredeti kérdésre is válaszoljak, a betöltődés utánra simán betehetsz függvényt, ami csekkol egy állapotot, aztán küld egy AJAX-kérést.
jQuery-vel írom, ha már úgyis épp azt tanulgatod:$(document).ready(function(){
var idOfPageToLoad;
if(isLoggedIn()){
idOfPageToLoad = 1;
}
else{
idOfPageToLoad = 2;
}
loadPage(idOfPageToLoad);
});Ez a kliensoldali ellenőrzés a bejelentkezett állapotra totálisan megbízhatatlan, a felhasználó akkor módosítja itt az adatokat, amikor csak akarja.
Ha a felhasználó nincs bejelentkezve, de módosítja a lekért kódot kliensoldalon, és átírja a page id-t, akkor majd jól megmutatod neki azt az admin-felületet, amit elvileg csak a bejelentkezett felhasználóknak szabadna látni?==========
(#2809) Muton : látom az önbizalomban nincs hiány...
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #2811 üzenetére
"Meg mert felülről ez jött, hogy így csináljam (és akkor így kell)"
A megrendelőidnek, főnökeidnek a szerencsés kivételtől eltekintve k×rvára fingja nincs arról, hogy egy rosszindulatú támadás hogyan történhet. A fejlesztőnek attól még gondolnia kell a biztonságra, törekedni a rosszindulatú támadások elkerülésére.
Ez egyébként sem zárja ki azt, amit a megrendelőd kért, hogy a felhasználó maradjon bejelentkezve a böngésző bezárása után is (ami egyébként nem egy földtől elrugaszkodott gondolat)... tehát szerintem nem igazán értetted, mire akartunk kilyukadni. De az előbbi hozzászólásomban írtam egy példát, hogy hogyan írhatja át simán a júzer a kapott adatokat, abból talán érthető.[ Szerkesztve ]
Sk8erPeter
-
Muton
addikt
válasz Sk8erPeter #2815 üzenetére
először belogol, kap egy session id-t, majd minden get-hez és post-hoz hozzáfűzi, h a szerver tudja, hogy kihez tartozik. ha kilép, akkor elmenti, majd ha beindítja, betölti és megy tovább. azért kell ez a login dolog, mert ha elszáll a mentett session id, vagy kilép, és más userként lép be, akkor kér a szevertől újat. tehát az tud password nélkül ügyködni, ha megkaparint egy beloggolt eszközt (telefont).
szóval kicsit olyan, mintha nem is személyhez kötődne, hanem készülékhez, mert addig megy, amíg hiba nincs, vagy user váltás (ami telefon meg nagyon ritka, hogy: "hé, Munkatárs Pajti, add már ide a telódat, hogy beírjak valamit a céges rendszerbe, ok?").Muton#2316 - $z@r a drop >_<
-
Sk8erPeter
nagyúr
Kap session id-t, akkor gondolom csekkolod is a session id-t - tehát csak van szerveroldali kódolás (PHP, ASP.NET, JSF, stb.) a dologban, nem? Vagy most nem tudod, hogy milyen rendszerben dolgozol?
"először belogol, kap egy session id-t, majd minden get-hez és post-hoz hozzáfűzi"
Ez rossz és felesleges. Ne legyen hozzáfűzve.Már nem is tudlak követni, hogyan oldod meg, hogy a böngésző bezárása után se jelentkeztesse ki a júzert. Cookie-kezelés van?
[ Szerkesztve ]
Sk8erPeter
-
Muton
addikt
válasz Sk8erPeter #2817 üzenetére
én az életben nem mondtam, hogy nincs szerver oldalon hitelesítés...
de hozzá kell fűzni, mert onnan tudja a szerver, hogy nem Betörő Pistike próbál adatok kérni, hanem Munkatárs Kamilla.
Simán lementem localStorage-ba, bezárom az alkalmazást, újraindítom, és betöltöm localStorage-ból.
Muton#2316 - $z@r a drop >_<
-
sztanozs
veterán
Ja, csak ha valaki megszerzi a storage-ot (vagy lesniffeli a lekérést), akkor már meg is van valid session id... Ráadásul minek kliens oldalon ellenőrizni, ha szerver oldalon úgyis megteszed?
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Sk8erPeter
nagyúr
Hát akkor félreérthetően írtál. (ld. futtatja az index.html, és kész, kliensoldalon legyen annak ellenőrzése, hogy valaki belépett-e, stb.)
"de hozzá kell fűzni, mert onnan tudja a szerver, hogy nem Betörő Pistike próbál adatok kérni, hanem Munkatárs Kamilla."
Hiába erősködsz, akkor sem szokás az URL-hez hozzáfűzni a session id-t. (Pontosítok: csak ELAVULT webalkalmazásoknál volt (remélem, a múlt idő indokolt) szokás.) Csak még könnyebbé teszed annak ellopását. Tökéletes módszer nincs, de ezzel még messzebb kerülsz a tökéletestől.[ Szerkesztve ]
Sk8erPeter
-
Karma
félisten
válasz Sk8erPeter #2821 üzenetére
"Hiába erősködsz, akkor sem szokás az URL-hez hozzáfűzni a session id-t. (Pontosítok: csak ELAVULT webalkalmazásoknál volt (remélem, a múlt idő indokolt) szokás.)"
Biztos vagy ebben az állításban? Sok nagyobb szolgáltatás, mint például a Facebook, követeli meg az access tokent minden egyes kérésben. És ahogy láttam a GET paraméter is elég gyakori (főleg REST-nél).
“All nothings are not equal.”
-
Muton
addikt
válasz Sk8erPeter #2821 üzenetére
... és ez mind https-en megy, gondolom Kezdő Hacker Pistikének is eltartana valameddig.
Mindenkinek:
Örülök a jobbító szándékú tanácsoknak, de kérek mindenkit, hogy lépjünk már túl a dolgon, mert nem én vagyok az architekt. így kell csinálnom, és készMuton#2316 - $z@r a drop >_<
-
Sk8erPeter
nagyúr
Az URL-ben hol van a Fácsénál a session id vagy token?
Egyébként nem tudom, mennyire egyre gondolunk, én arra gondoltam, hogy sok webalkalmazásnál (pl. phpMyAdmin) az URL-ben passzolják át a tokent (pl.: index.php?token=a5f8269f1f04963c0cdc54fd174edc05), és erre alapoznak, de ez a token megszerezhető akár egy refererből is. Itt van még egy jó példa, hogy azért sem biztos, hogy jó, mert ha pl. könyvjelzőzöd az oldalt, és be vagy jelentkezve, a webalkalmazás pedig teljesen a GET-ben átadott tokenre alapoz, és ha más token van megadva, mint ami az aktuális, akkor mondjuk kidob a bejelentkező oldalra.
Amúgy most már elbizonytalanítottál, annyira nem vagyok biztos benne, de ha már így alakult, említhetnél konkrét példákat.Sk8erPeter
-
Karma
félisten
válasz Sk8erPeter #2824 üzenetére
Például a Graph API és az FQL is úgy működik, hogy paraméterként át kell adni a bejelentkezéskor kapott access tokent.
Pl. a profiloldalam adatainak lekérdezése:
https://graph.facebook.com/1669432759?method=GET&metadata=true&format=json&callback=___GraphExplorerAsyncCallback___&access_token=AAACE<kivágva>OkXfRA weboldalon ez nem ennyire látványos, amíg nem nézel rá az XHR-ekre Itt cookieból húzza fel a session ID-t a pull requestekhez.
De hogy egy másik példát is mondjak testközelből, a Liferay is folyamatosan generál sessionID-ket minden URL-be - innen fogja tudni a portletnek átadni a megfelelő objektumokat.
---
Szerintem az URL-ben küldés önmagában még nem veszélyes, ha a session ID valami hosszú, biztonságos hash, és a szerveroldal minden hívásnál ellenőrzi. Na meg persze megfelelő érvényességi idő is tartozik hozzá.
Nem úgy, mint anno a webbankos esetnél, amikor sima szám volt a user ID és szabadon be lehetett lépni bárhova (Több éve volt, nem hiszem hogy megtalálnám a cikket amiben olvastam.)
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
-
sztanozs
veterán
Egy beszállító azt állít a dolgozóiról, amit akar. Általában a helyzet ilyen elkeserítő (és nem kizárólag az új beszállítóknál)
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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
-
Sk8erPeter
nagyúr
Hmm, hát valóban nincs extra fullos módszer, és vannak esetek, ahol nem is annyira gázos, ha átpasszolod a session id-t, mert esetleg szenzitív adatokhoz nem férsz hozzá, vagy nem tudod őket módosítani. Mondjuk a Graph API-nál elvileg a user engedélyét kell kérned, hogy bizonyos adatait megkapd. Nem nagyon használtam még a Facebookos API-t, de ezzel módosítani nem is nagyon tudsz szenzitív adatokat, nem? Mondjuk végül is az igaz, hogy publikálhatsz a falára baromságokat, ha megkaptad az engedélyt, és ha valaki ezt a tokent megszerzi, akkor rosszindulatból is teheti ezt egy alkalmazáson keresztül.
Egyébként igazából a kiindulási pont az volt, hogy van egy webalkalmazás, ahova közvetlenül bejelentkezik az illető, és böngészgeti az oldalt. Nincs közvetett, API-n keresztüli kommunikáció, mint az általad említett Facebookos példánál.
Itt szerintem nem indokolt passzolgatni az URL-be a session id-t. Ahogy nem teszi a Facebook, Gmail, Google Drive, Hotmail, stb. sem, amikor csak böngészgeted az oldalukat.
Nemde?A Liferay-t nem ismerem, fogalmam sincs, hogy működik, így a motivációt sem tudom, mi az oka, hogy az URL-ben van minden alkalommal belepakolódik a session id. Nyilván megvan az oka, nem tudom, mennyire "örökség", és azt sem tudom, ennél mennyire lenne ez egyébként más módon is megoldható. Meg a körülményeket sem írtad, hogy milyen esetben jön elő ez. Szerk.: vagy minden esetben?
[ Szerkesztve ]
Sk8erPeter
-
Karma
félisten
válasz Sk8erPeter #2830 üzenetére
Direkt kitértem arra, amikor csak simán böngészgeted a Facebookot Nézd meg a Chrome Developer Toolsával, mit is kommunikál le az oldal a backendjével: minden kéréshez csatolja a session ID-t. Még egy hótegyszerű statikus oldal, mint a Prohardver is folyton küldi az azonosítót.
Hogy most az URL-ben van, vagy a headerekben, cookieban vagy más formában, az teljesen mindegy. Nehezen tudok elképzelni olyan szisztémát, amelyben ez az elem teljesen hiányzik. Hogy máshogy döntené el, hogy az adott kérés milyen felhasználóhoz tartozik? A HTTP állapotmentes, abban meg nem szabad bízni, hogy az adott IP cím végén ugyanaz az ember van (spoofolni elég egyszerű...).
Na jó, egyet el tudok, és a hideg ráz tőle azonnal: a usernév/passwordöt elküldeni minden kéréssel
Apropó Liferay, igen, mindig generálja ezeket. Ha nem használod a JSR-186/286-ot nagyon nem részletezném, a fő hogy mindig
Fontosszerk: Ja látom konkrétan az URL-ben passzolgatást kifogásoltad... Szerintem egyenértékűek, na
[ Szerkesztve ]
“All nothings are not equal.”
-
Sk8erPeter
nagyúr
Jó, hogy ilyen hosszan leírtad a dolgot, meg korábban már én is többféleképpen kifejtettem, aztán a "Fontosszerk.:" résznél végre rájöttél, miről beszéltem addig.
Lehet, hogy biztonsági szempontból egyenértékű (bár ez számomra nem feltétlenül egyértelmű, bár igen, adott esetben valóban "lehallgatható" a kommunikáció, ha valaki nagyon akarja, és akkor lehet, hogy mindegy, hogy URL-ben vagy headerben vagy cookie-ban vagy más ügyeskedéssel passzolod át az adatot; bár ha URL-lel passzolod, legalább megkönnyíted a dolgát ), de felhasználói élmény tekintetében nagyon nem. Ha az URL össze van okádva egy baromi hosszú hash-sel, amikor böngészgetek, az szerintem nagyon zavaró, plusz az URL nem lesz könnyen megjegyezhető, mert az átlaguser nem biztos, hogy szét tudja választani a
http://example.com/foo/bar/test
címet ettől:
http://example.com/foo/bar/test?asd=jalskdjq34lkj321sadnlasdequwel&bla=123lknasdl678sadlokEzenkívül akkor a felhasználó ezt a hányadékot menti el a könyvjelzőkhöz is.
Szóval szerintem ha lehet, kerülendő a session id URL-ben történő passzolgatása. Jó, hát XHR-nél kb. le van szarva, mert abból a felhasználó többnyire lószart sem vesz észre, de a böngésző címsorába ne legyen beokádva ez a fenti rondaság.
Így már oké?[ Szerkesztve ]
Sk8erPeter
-
Karma
félisten
válasz Sk8erPeter #2833 üzenetére
Oké.
Mondjuk az URL-t belülről át lehet írni, hogy a felhasználó betöltés után csak a szép formát lássa (vagy legalábbis nagyon hasonló viselkedést szoktam látni). Másrészt meg a legigénytelenebb oldalaktól (*hint hint*) eltekintve mindenki más már HTTPS fölött authentikál, ott meg nem látszik az URL a külső szemlélők felé.
Nem érzem annyira égető problémának, dehát ti tudjátok, elfogadom a rövid álláspontot.
[ Szerkesztve ]
“All nothings are not equal.”
-
sztanozs
veterán
Az auth még csak hagyján (valahogy el kell jutnia a felhasználónévnek és jelszónak a szerverhez), de ha az egész oldal https felett menne az már jó játék. Gondolom itt is mennyire örülnének neki, ha mehetne az egész oldal https-en, hogy át lehessen adni a sessionid-t gond nélkül GET paraméterként is
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Sk8erPeter
nagyúr
Na, akkor összegezve, én állításom:
- címsorban mindenféle hash-ekkel szétokádott URL csúnya
- könyvjelzőzött, mindenféle hash-ekkel szétokádott URL csúnya
Persze, ha akármilyen módon át van írva, vagy bármilyen okból a felhasználó által jól látható URL már normálisan néz ki, akkor no para.
Szerintem már jól lerágtuk ezt a témát.Érdekesebb lehet a DOM CSS-sel kapcsolatos téma. Abban van tapasztalatod/olvastál róla, hogy mitől jobb, ténylegesen gyorsabb-e, stb.?
[ Szerkesztve ]
Sk8erPeter
-
Karma
félisten
válasz sztanozs #2835 üzenetére
A Facebook pl. teljes egészében HTTPS fölött megy, meg minden Google oldal is És nem úgy néz ki, mintha összeszakadnának.
(#2836) Sk8erPeter: Ja szerintem is.
Egyébként nem tudok semmit a teljesítményéről. Az biztos, hogy a CSS betöltődések relayoutot hoznak magukkal - ezért is van az ősi mondás a <head>-be rakásról, de azt meg kéne nézni mi történik a jQuery-s és az alternatív módosításoknál.
Most sajnos van fontosabb dolgom (csak még települ a VS és az egyéb darabok), pedig szívesen játszanék egy kicsit ezzel.
[ Szerkesztve ]
“All nothings are not equal.”
-
v2izzy
tag
válasz Sk8erPeter #2829 üzenetére
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.http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
Sk8erPeter
nagyúr
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, ...).
[ Szerkesztve ]
Sk8erPeter
-
v2izzy
tag
válasz Sk8erPeter #2839 üzenetére
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.[ Szerkesztve ]
http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
Sk8erPeter
nagyúr
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
-
v2izzy
tag
válasz Sk8erPeter #2841 üzenetére
Ja csak úgy tűnik kicsit összevissza másoltam ki a kódot a hsz-edből. Javítva!
Amit linkeltem példában már azt használtam.
http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
CSorBA
őstag
Sziasztok!
Tudtok esetleg valami ultra egyszerű (esetleg Jquerys) WSYWYG editort?
Olyat, mint pl. a tinymce. De nekem kb elég annyi, hogy félkövér, aláhúzott, dőlt, ol, ul Csak üssön paragrahpot minden enternél.
-
-
Sk8erPeter
nagyúr
Eggyel visszább az ábécében : CKEditor
Ezt tudom ajánlani, elég komolyan testreszabható, és folyamatosan fejlesztik. (Az külön jó pont, hogy Drupalhoz is nagyon jó modulja van, ezenkívül ASP.NET-es kontrollert is kínálnak hozzá, meg Java-alkalmazásokba is könnyen integrálható, plusz ingyenesen (persze van liszenszelt változata is).)Meglepődve látom, hogy az ábécében eggyel később lévő CLEditor pl. nem mutatja azt sem, ha egy szót már korábban mondjuk félkövérítettél: ha a kurzor a félkövérített szó valamelyik betűjénél áll, akkor nem kerül fókusz a félkövérítés ikonra... ahogy a többi formázást sem mutatja. Pedig ez alapvető elvárás lehet egy WYSIWYG-szerkesztővel szemben. (CKEditor alap, hogy tudja.)
Ja, de most, a hsz. megírásának végére látom, hogy azt írtad, hogy legyen "lebutított".
Hát, a CKEditor mondjuk nem kicsi, de végül is úgyis csak egyszer kell a böngészőnek betöltenie a hozzá tartozó JS-fájlt, utána a böngésző már cache-ből szedi.
De ha a fentebb linkelt demóoldalon a "Custom toolbar" linkre kattintasz, akkor láthatod, milyen a CKEditor "Basic" toolbarja:Pont csak az alapvető eszközök láthatók rajta; ezt tetszőlegesen tudod bővíteni.
Sk8erPeter
-
Karma
félisten
válasz Sk8erPeter #2846 üzenetére
A mellékelt példa konkrétan azt mutatja, hogy a $.styled('.foo').set('color: #CCC;'); pár nagyságrenddel gyorsabb, mint a $('.foo').css('color', '#CCC'). A styled kimenete nem element wrapper, másra nem nagyon lehet felhasználni
[ Szerkesztve ]
“All nothings are not equal.”
-
v2izzy
tag
válasz Sk8erPeter #2846 üzenetére
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.
[ Szerkesztve ]
http://flic.kr/ps/MuuJU | @gerhard_berger | https://github.com/gerhardberger
-
Karma
félisten
Ezzel a frameworkkel ma találkoztam, ajánlom mindenkinek!
“All nothings are not equal.”
Új hozzászólás Aktív témák
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Házimozi belépő szinten
- BestBuy topik
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Napelem
- Milyen processzort vegyek?
- Formula-1 humoros
- Elektromos rásegítésű kerékpárok
- Skoda, VW, Audi, Seat topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest