_nec » js

Cufón – saját font, flash nélkül

_nec — Mon, 18 May 2009 08:18:25 +0000

Itt a blogon, és máshol is előszeretettel alkalmaztam egy flash alapú font megjelenítő megoldást, ami véletlenül sem a sIFR volt. Azzal kapcsolatban régóta több fenntartásom is volt, kényelmesebb volt a saját megoldásom használni, ismerve annak limitációit.

Nemrég viszont elémkerült a cufón, egy tisztán JS alapú megoldás, ami egészen zseniális.

Működése eléggé komplex, mivel a betűtípusok grafikáit kénytelen a böngésző saját eszközeivel megrajzolni. Ehhez a canvas elemet, Explorer alatt pedig annak natív VML támogatását használja ki.

A használni kívánt betűtípusból egy online generátor segítségével SVG alapú fontfile készül, amit a cufón számára VML görbékké számol át. Ezekkel már képes canvas elemre rajzolni, vagy vml elemeket készíteni.

A generátornál – a flashez hasonlóan – megadhatjuk mely karakterkészleteket akarjuk beemelni, ezzel optimalizálva a kapott font állomány méretét. A fontfile-t rögzíthetjük egy domainhez, ilyenkor az elkészült javascript “font” kódolásába bevonja az adott domaint, ezzel is védve a megvásárolt fontokat.

Ha nem bízunk a generátorban, saját dárga betűkészleteinket, vagy az ügyfél által készítetett teljesen egyedi TrueType fontot féltve, letölthetjük a generátor forrását, és azt saját fejlesztői szerveren futtatva, elkészíthetjük a font javascript megfelelőjét.

Ha kész a font, csak be kell emelni a html kódunkba, magával a cufón scripttel együtt, és amikor szükség van rá, javascriptben ráereszteni a kívánt css selector-ra.

 src="/js/cufon.js" type="text/javascript">>
 src="/js/myfont.js" type="text/javascript">>
 type="text/javascript">>

Az összes elterjedt böngészőben használható de előtte legyünk tisztában a korlátaival, nem igényel külön plugint, és érdemes egy pillantást vetni pár tesztoldalra vele.

Három hasznos jQuery plugin

_nec — Thu, 22 Jan 2009 16:48:36 +0000

Három olyan plugin-t mutatnék be röviden, melyek funkcionalitásuk alapján alapvetőnek érezhetőek, de a sima jQuery csomagból kimaradtak, valószínüleg helyspórolás, erőforrás kímélés céljából, no meg ezek valóban csak animációkhoz szükségesek. Mind a három kiterjesztés az .animate() metódus használatakor lehet hasznos.

backGround animation

A segítségével háttérképet mozgathatunk, majdnem a megszokott sílus attribútummal az .animate() metódus paraméterei között.

$('#myId').animate({backgroundPosition: '(150px 250px)'}); // ide
$('#myId').animate({backgroundPosition: '(-75px -50px)'}); // vagy oda

Érdemes odafigyelni a paraméterek körüli zárójelekre.

A plugin itt érhető el , használatára példa pl itt a menüben.

color animation

Ez a plugin lehetne talán igazán része a teljes csomagnak, pláne hogy John Resig írta – aki a jQuery-t magát is. Segítségével betűszínt, keretszínt és háttérszínt animálhatunk egy értékre.

$('.box')
	.animate({ backgroundColor: "blue" }, 'slow') // elobb legyen kek
	.animate({ backgroundColor: "#ff9900" }, 'slow') // aztan narancs

Itt a plugin oldala, példát pedig itt találhattok.

jQuery easing

Kicsit zavarbaejtő a jQuery dokumentációja az animate esetén:

animate( params, [duration], [easing], [callback] )

Az easing nincs túlságosan kifejtve, sokszor nem is használjuk emiatt. Ez a plugin rengeteg animációs effektet ad, amivel feldobhatjuk alkalmazásunkat.

$('.box').animate({
	width: '+=250',
	height: '+=200',
	left: 100,
	top: 200
},'slow','easeOutBack');

A plugin oldala, a mozgásokra az összes példa demó ugyamott, némi funkcionális játszadozás pedig itt látható.

Adobe AIR #6 SQLite JavaScriptből

_nec — Wed, 22 Oct 2008 15:17:17 +0000

Szünet után folytatva az Adobe AIR-ről szóló sorozatom, most az AIR beépített SQL adazbázis kezelését igyekszem bemutatni. Pár példával letudjuk az alapvető, az SQL lekérdező nyelvben ismert műveletet, majd kitérek pár optimalizációs megoldásra.

Az AIR futtatókörnyezet tartalmaz egy SQLite adatbázis kezelő osztálycsomagot, melyet nyugodtan használhatunk adatok tárolására, kezelésére és szinkonizálására. Annak, aki nem ismeri, erről az adatbázis rendszerről talán a legfontosabb amit érdemes nagy vonalakban elmondani, az az, hogy komplex file és memória struktúrák helyett egyetlen bináris file-ban tárolja az adatbázist. Mivel egy file és bináris, ezt a filet hordozhatjuk bármilyen rendszerre, ahol szintén használható, már ha létezik az adott rendszerre SQLite verzió.

Ennek köszönhető, hogy már rengeteg alkalmazás és operációs rendszer él ezzel a minimalista, de rendes relációs adatbázisrendszerrel, mint pl a Skype vagy a Firefox illetve a Mac OSX, jópár Symbian alapú mobiltelefon és minden iPhone vagy iPod Touch.

AIRben az adatbázishoz JavaScript segítségével férünk hozzá, mely elsőre szürreális élmény lehet azoknak, akik eddig csak rendes szerveroldali nyelvekben tettek hasonlókat.

Szinkron – aszinkron műveletek

Mint JS-ben rengeteg minden, az adatbázis műveleteink is lehetnek szinkron folyamatok, illetve eseményfüggők, így aszinkron lefutású kódok. Mindkettőnek van előnye ill. hátránya, a szinkron műveletek kódolás szempontjából egyszerűbbek, nem kell eseménykezelőkkel babrálni, de amíg lefut, a programunk malmozik/homokórázik használhatatlan csendben. Nem is ajánlott, csak nagyon kicsi adatbázisokkal, kevés adattal használni.

Az aszinkron műveletekre már készülni kell a kódunkban, eseményeket kell elkapni, adatokat mozgatni, de cserébe folyamatos marad a felhasználói élmény, meg valahogy ez közelebb is áll ahhoz a fejlesztési stílushoz, amit manapság az AJAX-al teletűzdelt weboldalak, alkalmazások megkívánnak tőlünk.

Csatlakozás az adatbázishoz

Lássuk az elejét, vegye elő alkalmazásunk az adatbázist.

1
2
3

var dbFile = new air.File("app:/db/database.db");
var db = new air.SQLConnection();
db.open(dbFile);

Meghatározunk egy File pointert ami az SQLite adatbázis filera mutat, az app:/ relatív elérési útvonal az alkalmazásunk telepített helye a fájlrendszeren. Majd létrehozzuk a kapcsolatot az adatbázishoz és megnyitjuk azt, SQLite esetén ez az a file amit megadunk neki, egy file – egy adatbázis.

Létrehozunk egy SQLConnection objektumot, majd megnyitjuk vele az adatbázist. Az SQLConnection-nek van sok eseménye, amit érdemes figyelni, leginkább talán az air.SQLErrorEvent.ERROR -t, ha hiba van. Az adatbázis megnyitása történhet az open metódussal, ha szinkron, és az openAsync metódussal, ha aszinkron műveletekkel szeretnénk dolgozni.

Aszinkron műveletek során minden lefuttatott kérést figyeltetni kell majd egy air.SQLEvent.RESULT eseményre, de most időhiányában nem térek ki az aszinkron műveletekre.

SQL műveletek

Miután alkalmazásunk csatlakozott az adatbázishoz, az SQL műveletek nagy része már nem sokban különbözik a más nyelvekben megszokott módoktól. Létrehozunk egy SQLStatement objektumot, megadjuk neki melyik adatbázist használja, és hogy mi a művelet.

4
5
6

var statement = new air.SQLStatement(); 
statement.sqlConnection = db; // az adatbázis
statement.text = "SELECT name, value FROM options"; // a művelet

statement.execute(); 
var results = statement.getResult(); // eredmények kiolvasása az SQLStatement objektumból
var numResults = results.data.length; 
for (i = 0; i < numResults; i++) 
{
    var row = result.data[i];
    row.name; // a mezőértékek asszociatív tömbben
    row.value;
}

Aszinkron műveletek során egy air.SQLEvent.RESULT eseményt kell figyeltetni az SQLStatement objektumon, de az eseménykezelőben a kód már ugyanez.

INSERT, UPDATE és DELETE műveleteknél nincs különbség, ha a statement.execute(); lefut, illetve van
air.SQLEvent.RESULT esemény, akkor volt sikeres a művelet.

Hibakezelés

Aszinkron műveleteknél az air.SQLErrorEvent.ERROR esemény figyelésekor kapott esemény-objektum hordozza a hibaüzenetet, szinkron műveletek esetén használjuk a try-catch szerkezetet, az elkapott kivétel tartalmazza majd a hiba okát.

Tippek, optimalizálás

AUTOINCREMENT - ilyen típusu oszlopoknál INSERT után az eredményobjektum lastInsertRowID paramétere hordozza az új ID-t

Paraméterezett műveletek – az AIR minden SQL műveletet alacsonyabb szintű műveleti kódra fordít, és úgy tárol, amíg nem változik a művelet szerkezete. Sok, hasonló szerkezetű művelet esetén ezt érdemes kihasználni a művelet paraméterezésével.

Ilyenkor az SQL művelet kódját felkészítjük változók fogadására, s azokat később adhatjuk hozzá vagy módosíthatjuk ahelyett, hogy újraírnánk vagy újra példányosítanánk egy SQLStatement objektumot.

statement.text = "INSERT INTO options(name, value)" + 
                 "VALUES (:optionName, :optionValue)"; 
statement.parameters[":optionName"] = "title";
statement.parameters[":optionValue"] = "Adobe AIR #6 SQLite JavaScriptből";

Később, ha ugyanerre a műveletere van szükség, csak a már példányosított SQLStatement objektumot kell újra elővenni, és módosítani a paramétereket az execute() előtt. Ennek a módszernek előnye az erőforrás kímélésen és a műveletek gyorsaságán kívül az, hogy védelmet nyújt az esetleges sql-injection sebezhetőségek ellen.

Tranzakciók – sok, logikailag valamilyen szinten összetartozó műveletet (írás/olvasás) érdemes egy tranzakcióba helyezni, összességében gyorsabb lesz a művelet.

Tranzakciókat az air.SQLConnection.begin() – .commit() – illetve .rollback() metódusaival tudunk kezelni.

Előre csomagolt adatbázisok, külső segédeszközök

Természetesen nem kell minden adatbázist helyben elkészíteni és kezdeti adatokkal, struktúrával feltölteni, lehetséges előre csomagolni az adatbázis állományt a letöltött AIR csomaggal. Csak ügyeljünk arra, hogy updatek esetén ne legyen gond esetleges felülírásból.

Az adatbázis kezeléséhez érdemes valami SQLmanager programot szerezni, vannak kifejezetten SQLitehoz kiadott programok, illetve AIRben is írtak már ilyen eszközt.

Nekem az SQLite Maestro nevű vállt be, igaz csak 30napos verziót néztem, de egész használhatónak bizonyult.

Eddig az Adobe AIR-ről:

Eval() Adobe AIR -ben?

_nec — Tue, 14 Oct 2008 08:15:01 +0000

Leggyakrabban talán JSON stringek objektumokká alakításakor jön elő ez a probléma. Az Adobe AIR környezet biztonsági okokból korlátozza az eval() javascript metódust. Ez a szigor erősen indokolt, de nem okoz megoldhatatlan problémát.

Nézzük a megoldást, de előbb az okokat, amiért így lett kialakítva a futtatókörnyezet.

Valamit valamiért, avagy amiért nincs eval().

MIt csinál az eval()? Végrehajt egy string formában megadott javascript kódsort, minden előztetes cécó nélkül.

Az AIRből pedig kivették azt a biztonsági szigorítást, hogy AJAX kérések csak azon a domainen futhatnak, ahol az oldal amit látogatunk. Bárhonnan fogadhatunk akármilyen javascript kódokat, akár fileszinten is betáplálva az alkalmazásunkba.

Ez eléggé hasznos, révén így igazi, online forrásokra támaszkodó, nyitott API-kat nyújtó webszolgáltatásokat kihasználó alkalmazást alkothatunk. De veszélyeket is rejt, révén az AIR alkalmazásunk hozzáfér a kliens filerendszeréhez. Nem lenne túl jó, ha egy pl egy chatprogram evalozott JSON stringjeiben tudatlanul kiadnánk személyesebb adatokat tartalmazó fájljainkat.

Az alkalmazásunk egy izolált környezetben fut, angol nevén ez a sandbox. Ezen belül vezették be az Adobe fejlesztői az alábbi szigorításokat:

eval() futtatások csak az onLoad előtt működnek
szinkron XMLHttpRequests kérések onLoad előtt nem adnak választ, aszinkron XMLHttpRequests kéréseket el lehet küldeni onLoad előtt, de azok válasza csak onLoad után érkezhet meg
onLoad után a document.write() és a document.writeln() függvények nem kerülnek lefutásra
htmlből hivatkozva scripteket nem lehet betölteni a sandbox-on kívülről
dinamikusan létrehozott