ugrás a tartalomhoz

Browser detect tool

inf · 2013. Ápr. 25. (Cs), 00.16
Segítsetek már, láttam régebben egy nagyon jó kis libet, ami ellenőrizte, hogy mi a böngésző verziója, és ha nem stimmelt, akkor kirakott ilyen kis színes ikonokat az alternatívákról. Elfelejtettem a nevét :-( :-(
‹ css - változó számú menüpontok széthúzása REST service & client uri milyen legyen? ›
 ■
1

Közben írtam egy sajátot. Nem

inf · 2013. Ápr. 25. (Cs), 06.23
Közben írtam egy sajátot. Nem annyira csilli-villi, de működik minden böngészőben.
2

Detektálás

hakos15 · 2013. Ápr. 25. (Cs), 17.25
Véleményem szerint erre lehetne írni egy olyan classt, mely alapjáraton array-ben tárolja a böngésző fajtáit. A böngészőt fajtáját ki regexp-elheted a user-agentből, vagy egy egyszerű kóddal körbejárod a tömböt és amelyikre találatot jelez, azt megvizsgálod a továbbiakban. Ennek hátránya, hogy időigényes kihalászni az összes böngésző azonosítót.
3

Ha esetleg lemondasz a

kuka · 2013. Ápr. 25. (Cs), 17.39
Ha esetleg lemondasz a tömbben tárolásról és inkább állományt használsz, akkor használhatod a létező browscap.ini-t.

Ha esetleg a létező browscap.ini-t használod, akkor használhatod a létező get_browser() függvényt.
4

Köszi a segítséget srácok, de

inf · 2013. Ápr. 26. (P), 01.36
Köszi a segítséget srácok, de már megoldottam. Ezt használtam fel: http://www.quirksmode.org/js/detect.html, meg az itt: http://browsehappy.com/ található toolbart. Egész tűrhető lett a kód végül, csak ne tegnap kezdtem volna bele... Olyan fáradt voltam, hogy képtelen voltam gondolkodni... Ma 1-2 óra alatt összekapartam a tegnapi kódot valami használható formába. Hozzácsaptam még egy cookie ellenőrzést is, meg hogy mentse, ha valaki a figyelmeztetés ellenére tovább akar menni az oldalra.

A php-s megoldás azért nem jó, mert olyan klienst csinálok, ami 100%-ig statikus. A szerveren futó rész egyedül egy rest service lesz...

Egyelőre még egyeztetek, hogy kitehetem e github-ra, valszeg kirakom forrás megjelöléssel, aztán max jelzik, ha valami nem tetszik...
6

A php-s megoldás azért nem

kuka · 2013. Ápr. 26. (P), 10.12
A php-s megoldás azért nem jó, mert olyan klienst csinálok, ami 100%-ig statikus.
Upsz. El sem tudom képzelni, hogyan olvastam tegnap a fórum nevét „PHP”-nak…
7

Nem akkora hülyeség egyébként

inf · 2013. Ápr. 26. (P), 10.50
Nem akkora hülyeség egyébként az sem, ha a szerver generálja a json-t, amit utána felhasználók a toolbar kiszórására... A mostani kódom beállít egy cookie-t, aztán pl meg lehet csinálni azt is, hogy a szerver nézi, hogy van e cookie, aztán legközelebb már be se includolja a browser detect scriptet... Na szóval lehet ezzel is variálni... :-)

A 400msec-es gap rejtélyére még mindig nem jöttem rá, valszeg túl megterhelő a requirejs-nek egyszerre 10 dependency-t sorba állítani, amik még egymástól is függenek, meg példányosítani mindegyiknek egy-egy xhr-t... Fura, mert utána rendesen lepörög, sokkal kisebb hézaggal a többi fájl betöltése... Csak az elején van egy nagy szünet valamiért... :S

Nincs valami olyan cucc, ami a firebug net-es ablakában időpontokat tud bejelölni? Beraknám a kódba, aztán hátha kiderülne, hogy melyik kódrész akasztja meg ennyire...
5

Annyi a gond vele jelenleg,

inf · 2013. Ápr. 26. (P), 03.41
Annyi a gond vele jelenleg, hogy csinál egy 400ms-ec gap-et a betöltésben. Elég fura, mert semmi olyat nem végez, ami bonyolult lenne, vagy erőforrás igényes... Felteszem githubra, hátha tudtok valami tanácsot adni.

https://github.com/inf3rno/browsehappy-toolbar

Majd tesztelem még enélkül is a kódomat, lehet, hogy alapból lassú, csak nem tűnt fel eddig ... A bootstrap file requirejs-el betölt kb 10 lib-et, amiket használok... Mondjuk mivel full statikus, cachelve lesz az egész a böngészőben, most viszont debug mode-ban tolom no-cache header-el...

szerk:

Megnéztem, az utána jövő kód a lassú... Valszeg azért, mert nem minify-olt fájlokat töltök most be, hogy könnyebb legyen a debug...