Fájlgenerálás végeztének kezelése JS-ben

Előfordulnak olyan helyzetek, mikor egy online felületen, egy formon megadhatunk keresési paramétereket, majd az eredményt rögtön letöltve szeretnénk megkapni. Ilyenkor célszerű addig letiltani gombot, amíg dolgozik a rendszer. Ezzel elkerülhető, hogy a hosszú várakozási idő alatt többször rányomjon a felhasználó. Hiszen az ő szemében "már bezárta a böngészőt, tehát befejezte a műveletet", attól a szerver még végigcsinálja a feladatot.

JavaScriptben nincs egységes módszer, vagy esemény, vagy bármi arra, hogy mikor mondhatnánk azt, hogy most már lehet engedélyezni a gombot. Viszont van egy elfogadhatóan jó kerülő megoldás: tegyünk bele a sütibe egy tokent, amikor a kiszolgáló visszaküldi a választ és benne a letöltendő fájlt, és figyeljük JS-ből ezt a tokent, hogy elérhető-e már.

Az alábbi linken a UI blokkolásához a JQuery Block UI plugint használják, ami természetesen cserélhető/kihagyható az aktuális feladattól függően. A linken üríti a sütit egy külső JQuery pluginnel, ami tartalmazza a $.cookie-t. Erre azonban nincs szükség, hiszen minden gombnyomásnál új tokent generálunk és addig vizsgálódunk, amíg meg nem érkezik a token. Emiatt nem gond, hogy ha benne marad a token a régi értékkel olyankor, amikor amúgy sem várunk semmire sem.

http://gruffcode.com/2010/10/28/detecting-the-file-download-dialog-in-the-browser/

MVC 4 .js és .css minimalizálás, csomagolás

Balássy Gyuri videója egy jó útmutató, ha oda akarunk figyelni arra hogy gyorsan töltődjön be az oldal.

DOCTYPE, window.event és IE csoda

Különös jelenség a mostani téma.

Egy régi .NET (2.0) web alkalmazás 4.0-ra alakítása után a browser "néha" javascript hibát dobott, de nem mindenkinél.

Annyit tudtunk, hogy amikor egy lenyíló lista dobott egy event-et, akkor elszállt egy generált anonymous javascript method, mert az event.returnValue -ból az event "undefined".

Ennek az ember hogy áll neki nyomozni? Nincs megfogható, jól meghatározható exception, csak tapogatózás. Mert egyik IE-ben dobja, másikban nem stb.

Aztán egy bejegyzés megmutatta az irányt:

http://stackoverflow.com/questions/3774468/event-is-undefined-in-ie-works-in-firefox

Itt van egy utalás az egyik kommentben valamiféle "IE9 Standards Mode"-ra. Tovább kutatva kiderült, hogy ha ezt a doctype-ot kapcsoljuk be, mindenkinél működik. A probléma, hogy az ügyfélnél nem nagyon van IE9, pedig ezt úgy néz ki, ebben javították. Vagyis egy ismert problémáról van szó.

Nem akarok szöveget másolni/fordítgatni, a lényeg, hogy a generált DOCTYPE tag a html elején sokkal fontosabb annál mint sokan tippeljük, egész komoly hatással van a js működésre, feldolgozásra.

Ennél sokkal több cikket lehet találni (pl), érdemes átnézni. Megoldás végül még nem született, de úgy néz ki hogy a régi rendszer fő frame-ében egy régebbi doctype lesz beállítva, az MVC-s lapok masterén, vagy layout-ján pedig egy újabb, és azokon megpróbáljuk elkerülni, kezelni ezeket a hibákat.

Kérdés, hogy egyáltalán a jQuery UI cuccok, meg úgy a jqery majd mennyire lesz kompatibilis melyik doctype-al meg browser verzióval, majd kiderül.

Még egy hasznos js fv, ami kideríti, dob egy alertet hogy jók vagyunk-e doctype ügyileg, jól kezeli-e az aktuális csillagállásban a browser az eventeket.

JSON sorosítás, performancia

Balássy Gyuri ideillő bejegyzését érdemes elolvasni, mielőtt kitaláljuk a JSON sorosítás mikéntjét.

És itt le lehet tölteni a performancia teszthez használt forrást is, és a json.NET-et is

Javascript Design Patterns

Design Pattern-ekről már mindenki hallott. Javascript specifikusan nem biztos hogy könnyű beszélni róla, főleg mert sokan nem tudják, hogy objektum orientált "szerűen" is lehet javascriptelni.

Ez a cikk/könyv meglepően értelmesen fogalmaz, általánosságba minden patternről elmondja 1-2 mondatban hogy mire való. Érdemes elolvasni:

http://addyosmani.com/resources/essentialjsdesignpatterns/book/

jQuery template

Template rész le lett állítva anno, és itt az új rész (feature/modul)
jsRender és jsViews néven:
http://www.borismoore.com/2011/10/jquery-templates-and-jsviews-roadmap.html

jQuery nem hal ki, csak átalakul. :)

CSS és JS minimalizálás a gyors oldalért

Feritől a következő link. Sokat olvastuk már a könyvekben, hogy ez mennyit számít. Itt a segítség hozzá:
http://weblogs.asp.net/scottgu/archive/2011/11/27/new-bundling-and-minification-support-asp-net-4-5-series.aspx

DPDPDP Javascript

http://addyosmani.com/resources/essentialjsdesignpatterns/book/

Javascript DP-k dögivel.

Van élet a jQuery-n túl...

http://www.sencha.com/

Ismerős éles projekten használta többször is, erősen ajánlott.

parseInt JS alatt

Amikor egy webes felületen textbox-ból numberikus értéket vársz és alakítod át a parseInt függvénnyel, akkor erősen ajánlott a későbbi szívásokat elkerülve rögtön megadni a második paramétert is, ami a bázisa az átalakítandó string numberikus értékének.

Ha ezt nem teszed, akkor a felhasználó által beírt 01000 szám 512 lesz, míg a 0x50 = 80.

Ezek általában az ügyfél által nem kért és zavaró plusz szolgáltatások. :)

Tehát helyesen mindig xx.parseInt(xyz, 10) legyen a sor, ha csak kimondottan nem igényled a javascriptes egyéb számrendszer beli számolást.

jQuery és CSS class alapú keresés

Egyik legszebb jQuery-s DP hiba, amikor javascript kódban CSS class-szal lesz kikeresve az input-ok vagy más kontrollok, majd a fejlesztés során design vagy egyéb okból a class-t le kell róla szedni.
Ekkor szó nélkül elszaródik a kód és lehet keresni...
Alapvetően (logikailag) nem stimmel, hogy design alapján keresünk ki kontrollt kód logikában, miközben a keresési feltétel nem arról szól, hogy kellenek az "ilyen és ilyen kinézetű" kontrollok, hanem inputot keresel, stb.

Tehát helyesen mindig típus alapján (itt megfogalmazható egész bonyolult tartalmazás stb) kell keresni vagy név alapján. CSS alapján csak akkor keressünk, ha tudjuk, hogy a logika akkor változik, ha a design is.
Megoldás lehet a "marker" CSS osztályok, amik lényegi design beállítást nem tartalmaznak, és erre szelektálni.

JSON Dátum érték beállítása. Időzóna para

Ha egy JSON objektumot töltünk fel aminek date értékű mezője is van, és ezt az objektumot egy WCF request-ként felhasználjuk, akkor hamar belefutunk abba a problémába, hogy a server oldalon nem biztos, hogy meg fog egyezni a deszerializált dátum érték a cliens oldalival. Az eltérés pontosan az aktuális időzónánk és GMT közti eltérés lesz. Ennek az egyik legegyszerűbb kiküszöbölése, hogy a felküldendő dátumértéket módosítjuk ezzel az eltéréssel:

dateobj["Value"].setMinutes(dateobj["Value"].getMinutes() + dateobj["Value"].getTimezoneOffset());

Ezzel már a helyes érték megy a szerverre.

Javascript intelliSense

http://visualstudiogallery.msdn.microsoft.com/872d27ee-38c7-4a97-98dc-0d8a431cc2ed/

Javascript helyett

Javascript-et öntsük használható formába kihasználva a már létező tool-ok előnyeit:

http://html5hu.wordpress.com/2011/05/29/script-c-to-javascript-tudnivalk/#more-427
http://projects.nikhilk.net/ScriptSharp

Javascript helyett

Javascript-et öntsük használható formába kihasználva a már létező tool-ok előnyeit:

http://html5hu.wordpress.com/2011/05/29/script-c-to-javascript-tudnivalk/#more-427
http://projects.nikhilk.net/ScriptSharp

DevExpress - Google Frame - IE

Pár napja fura javascript hibákat kezdett el dobálni a weblap. A hiba nem mond sokat, de látszik belőle, hogy devexpress-es controlokkal van probléma (DXR.axd Object doesn’t support this property or method).

Hosszas tanakodás és keresgélés után megvillant, hogy telepítettem a Google Frame-et valami miatt az explorerhez (talán google wave). Na ezt nem kellett volna, viszont nem egyszerű leszedni, erre, és a hibára egy leírás itt.