Perl, jQuery és minden ami webfejlesztés MAGYARUL

Már régóta nem volt bejegyzés, mostanság feltorlódtak a tennivalók, de remélem lassan több időm jut a blogra.

Gyorsan kreáltunk egy függvényt, most nézzük meg bind használatát, a jó öreg setTimeout függvény segítségével.

Ekkor a console-ra a következő kerül kiírásra: DOMWindow, [true, "almafa"]
Mellesleg ha így hívnád a setTimeoutot azt felejtsd el, ugyanis a doSg függvény az (evil) evallal kerül lefuttatásra. 

Így már egy kicsit másabb és ugyanazt azt eredményt érjük el, a consolera szintén a következő került: DOMWindow, [true, "almafa"]

Most állítsuk be a doSg függvény meghívásakor a this értéket:

Nos most a Document, [ true, "almafa" ]  került kiírása, ez így már kezd szexi lenni:)
Már csak egy baj van, ugye minden alkalommal ha a doSg függvényhez rendelni akarunk, valamilyen paramétert akkor létre kell hozni egy anonymus függvényt, amit nem annyira szeretünk, ugyanis ha paraméter nélkül hívjuk a doSg-ot akkor ilyen egyszerűen is megtehetjük:

Ekkor a kimenet a DOMWindow, [] lesz.

Ennek a probléma megoldására vezették be bindot, anélkül tudunk hozzárendelni függvényhez paramétereket, hogy az azonnal lefutna, vagy anonymus functionba kellene írni. Nézzük, hogy nézne ki a setTimeoutunk:

Woow, ez már így igen szép, és a kimenete is a következő: Document, [ true, "almafa" ].

Szvsz engem teljesen lenyűgöz, ugyanis borzalmasan utálok folyamatosan anonymus függvényeket írogatni.

FF, és a Chrome már biztosan támogatja, IE-ről sajna még nincs infóm, de szerencsére az MDC-ben van egy egyszerű workaround a Function.bind megvalósítására illetve találhattok további példákat a használatára.

Nézzük milyen újdonságokat kaptunk:

• teljesen újraírt .ajax()
  • egy fake xhr objektumot (jXHR) kapunk az .ajax() meghívásával, a cross-browser problémák elkerülése érdekében (pl abort JSONP requesteknél)
  • XDomainRequest kezelése ( cross domain ajax kérésekhez )
  • chained callbackek$.ajax({url:"site.html"})
      .complete( function(){ alert('complete'); }) 
      .error( function(){ alert('error'); })
      .success( function() { alert('success'); });
  •  http státuszkódhoz rendelt függvények$.ajax({
    url:"site.html",
    statusCode: {
        404: function(){ alert('négy-nulla-négy'); },
        500: function(){ alert('internal server terror'); }
        401: function(){ alert('nem vagy belogolva...'); }
    }
  });
• deferred objects ( async kérések bevárására ), azt hiszem ezt nem itt fogom elmagyarázni, inkább csekkoljátok ezt az impresszív tutoriált
• 83 bugfix, 460 lezárt ticket 

 További infók

Egy pár napja túrtam a jQueryUI forráskódját, mert a dialoghoz hasonló dolgot szerettem volna varázsolni, és következő kifejezésre lettem figyelmes a 9377. sorban: ( nem, az egy darab pluszjel nem typo! )

if (+myAt[i] === myAt[i])

egy pár percig néztem WTF fejjel, körbekérdezgettem a kollégákat, hogy láttak-e már ilyet, majd miután mindenkitől nemleges választ kaptam, elkezdtem utána járni a dolognak.

jsfiddle

Tehát a + jellel a változónkat megpróbáljuk  számmá parse-olni, és ha ez sikerül akkor meg fog egyezni az eredeti értékével, ha nem sikerül akkor pedig nem fog megegyezni. Miután ezt megtudtam óriási lelkendezésbe kezdtem.

De nem hagyott a gondolat nyugodni, hogy miért így ellenőrzi a jQueryUI, hogy szám-e az adott érték, miért nem használja minderre az isNaN függvényt?! 
(Megjegyzés: az isNaN("13") kifejezésre false-zal tér vissza, magyarul számként értelmezi, míg a ' var a = "13"; console.log( +a === a );' szintén false lesz, de itt ez azt jelenti, hogy az "a" változót nem sikerült számmá alakítani)

Ezek után írtam egyszerű tesztet, hogy lássam a jQueryUI vagy az isNaN megoldás a gyorsabb: jsperf.com/a-a-or-isnan
Jelenleg még csak 4 böngészőverzión teszteltem, és eddig tisztán látszik, hogy számoknál a jQueryUI-s megoldás gyorsabb, míg stringnél Chrome 10-ben és FF3.6-ban az isNaN, FF4b10-ben és Opera11-ben a másik megoldás volt a gyorsabb. (Alig várom, hogy Windowson és Macen is kipróbálhassam :) )
 

 Ez a poszt a változók értékének összehasonlításáról fog szólni, azaz kettő vagy három egyenlőségjelet kell használni.

A jQueryben ha alaposabban megnézzük a változók értékének ellenőrzését, mindenhol a legtöbb helyen három egyenlőségjelet használnak.

De miért?

Nézzük erre példát:

var str = 'alma';
console.log( str == 'alma' );
console.log( str === 'alma' );

 Itt semmi különbség nincs a két módszer között, mindkét esetben az érték true lesz.

De akkor hol nem lesz true?

Hát az alábbi esetben: 

var bool = false;
var num = 0;
console.log( bool == num );
console.log( bool === num );

Itt két, egy bool és szám változót hasonlítunk össze, azonban az eredmény a két esetben eltérő lesz.
Első esetben az érték true, ugyanis mindkét érték ( bool és num ) hamis lesz. A második esetben pedig false.
Tehát a különbség, hogy három egyenlőségjelnél nem csak értékegyeztetés történik, hanem típusegyeztetés is.

A mai tanulság, hogy ahol lehet használjuk a három egyenlőségjeles-, negálásnál pedig '!=='  formát.

A következő napokban érkezik néhány a jQuery coreból kiragadott példa, lássuk az elsőt. :)

A mai napon a "self-executing" függvényről lesz szó, amely a következőképpen néz ki:

(function(window, undefined){
      // Use the correct document accordingly with window argument (sandbox)
     var document = window.document;
     //...
})(window)

De mit is csinál ez?

• azonnal indulás
• a globális window objektumot kapja
• az undefined mindig undefined lesz
• névtér problémák elkerülésére megoldás lehet

Mi az, hogy az undefined mindig undefined?

Nos erre nézzük egy példát.

undefined = true; // ez ugyebár js-ben teljesen megengedett
var selfwindow = (function (window, undefined){
        /*az undefined argumentum mindig undefined,
        azaz sosem lesz értéke */
  return { 
   // belerakom a selfwindow objektumba 'undef' 
  // néven ezt az igazi undefined értéket  'undef':undefined
  };
  })(window);
alert( undefined ); //ez true
alert( selfwindow.undef ); //ez pedig undefined

Azonnali indulás?

Igen, ( amennyiben a scriptünk a head-ben van ) akkor még a HTML elemek betöltődése előtt végrehajtódhat, amennyiben eseménybeállítást szeretnénk végezni, használjuk a .ready() eseményt.

Névtér problémák?

Tegyük fel, hogy írnunk kell egy jQuery plugin ( a blogon a későbbiekben lesz még erről szó ), akkor fontos, hogy minden körülmények között működjön, ezért lehetőleg ne használjuk a $ jelet, ugyanis más js libraryk is ezt használják.
Azonban ha mégis szeretnéd itt egy egyszerű megoldás:

(function($){})(jQuery)

Így a pluginunk mindig a jQuery dollárt fogja alkalmazni.

Összefoglalásként ajánlom mindenkinek, hogy dobja oda a jQuery forráskódot a böngésző könyvjelző toolbarra, és időnként nézegesse.:)

Sziasztok!

Oroszi Róbert (oroce) vagyok, webfejlesztéssel foglalkozok ( mind backendek, mind frontendek készítésével ). A blogon ( mint ahogy a leírásban is olvashatjátok ), az oldal az alábbi két fő dolog köré fog épülni:

• perl, és ezen belül is a Catalyst keretrendszer
• jQuery

Miért van szükség erre?

Egyrészt mert már jómagam is átverekedtem egy-két szopóág problémán és szeretném ezeket leírni, hogy más, akár később én se essek még egyszer ugyanabba a csapdába.
Másrészt sajnos nem nagyon létezik a Catalystnak Magyarországon közössége, és szeretném ha minél több ember megismerné ezt a nagyszerű keresztrendszert.

Továbbá óriási jQuery fan vagyok és szeretném megmutatni, hogyan használjuk megfelelően, illetve hogyan tanuljuk a jQuery-ből.

Remélem kedvetek lelitek a blogban.:)