A Google Reader egy rettentő addiktív dolog, ha az ember a feedolvasást választja a hírek beszerzésének kényelmes formájaként. De mi van akkor, ha az itt olvasott dolgokat szeretnénk másokkal is megosztani a saját honlapunkon? És ha a feliratkozásainkból szeretnénk egy blogrollt csinálni az oldalunkon? Természetesen a Google is gondolt erre, ezért mindkettőre van lehetőségünk.

Az alábbiakban szeretném bemutatni, hogy hogyan is valósíthatjuk meg ezeket a dolgokat, valamint mit tehetünk, ha nem elégszünk meg az alap lehetőségekkel.

Régebben írtam a PHP sablonnyelvként való használatáról. Lehet szépíteni a dolgokat, de hosszú távon ennek a használata (főleg megfelelő szerkesztőprogrambeli makrók nélkül) kényelmetlen, hosszadalmas és még a makrók használatával együtt is csúnya, olvashatatlan. A Smarty egyetlen pozitívuma az, hogy egyszerűen és gyorsan lehet írni, kényelmesen lehet használni. Persze ez nem vigasz azoknak, akik nem akarnak egy több ezer kódsorból álló sablon kezelőt használni csak emiatt a kényelem miatt.

Nagyrészt így vagyok vele én is. Gyakorlatilag a szintaktikájának az alapjait leszámítva nem lenne szükségem semmire a Smarty-ból. Nem érdekel, hogy korlátozni lehet a sablon íróját, hogy a PHP eszköztár csak egy részét használhassa (minek is korlátoznám magam...). Nem érdekel, hogy könnyen és gyorsan lehet hozzá plugineket írni (ha az egész PHP használható lenne, erre nincs is túl nagy szükség). Nincs szükségem semmi ilyesmire.
Sokkal inkább vonz az, ha a nyelvet gyorsan lehet gépelni (pl. mert rövid, minimális speciális karaktert használ és logikus a szerkezete). Az se egy hátrány, ha az elkészült sablon valamilyen szinten olvasható lesz. Nem lenne rossz még, ha egy elfogadható minőségű PHP kódot generálna az én sablonomból, ami aztán elfogadható (a lehető leggyorsabb) sebességgel futna. Az első kettőt még csak-csak teljesíti, de az utolsóval eléggé hadilábon áll a Smarty. Így itt az idő valami más után nézni...

Mivel az "esemény" és annak kezelése a JavaScript-ben az egyik legfontosabb dolog, ezért nem teljesen mindegy, hogy mégis hogyan csináljuk. Vagy méginkább az, hogy hogyan kell csinálnunk. Értem itt ezalatt azt, hogy minden egyes alkalommal egy kisebb fajta regényt kell írnunk, amikor egy objektum egy eseményét akarjuk figyelni, vagy elég egy Event.observe() hívás, ami elvégez számunkra minden piszkos munkát.

Az "Objektum-orientált JavaScript" című bejegyzésem utolsó példájával kapcsolatban felmerült, hogy kicsit jobban is kifejthettem volna az ott történteket. Mivel ott nem az eseményeken volt a hangsúly, ezért gondoltam egy külön bejegyzésben teszem ezt meg.
A prototype.js az események téren is képes a dolgunkat a végtelenségig leegyszerűsíteni. Egészen addig, amíg mi magunk nem akarjuk a dolgokat "bonyolítani", és bele nem fogunk az objektum-orientáltságban. Ilyenkor kezdődnek a problémák. Tegyük fel, hogy szeretnénk egy olyasmi dolgot megoldani, hogy két gomb segítségével egy harmadik gombra tudunk eseményt tenni, majd azt az eseményt levenni a gombról. Objektumok nélkül nem lenne különösebben nehéz dolgunk:

Egy régebbi melós projekt során merült fel a dolog, aztán azóta még nem volt nagyon időm írni róla, pedig akkor eléggé rákattantam a témára. Aztán most, hogy újraírtam a deadlime bejegyzés értékelő rendszerét valami korrektebb formába (azok a kis csillagok jobbra a bejegyzés után...), gondoltam ejtek néhány szót az objektum-orientált JavaScript szépségeiről.

A "JavaScriptben programozás szépségei", mint olyan, nem nagyon merült fel bennem soha, ha ezzel a nyelvvel kellett foglalkoznom (bár ebben biztos az is szerepet játszott, hogy még a különböző keretrendszerek elterjedése előtt az embernek if ágak egész erdejét kellett írnia, hogy a műve végül a főbb böngészőkben működjön). Szerencsére ezen sikerült változtatni.

Hadd mutassak be néhány trükköt a PHP egy régi, de annál hasznosabb nyelvi elemével, aminek a neve: list(). Valószínűleg sokan vannak, akik még hallomásból sem ismerik ezt a szerkezetet, így az ő kedvükért kezdjük a legelején.

Mikor olvastam, hogy az UltimateTagWarrior nem működik együtt teljes mértékben az új WordPress verzióval, már sejtettem, hogy ez nem lesz egy olyan sima átállás, mint például a 2.0.6->2.0.7 volt. Nem is mertem rögtön élesbe felmásolni az újat, gondoltam először helyben letesztelem, hogy hogyan viselkedne a rendszer az átállás után. Még szerencse, hogy így tettem.

Kezdek beállni erre a havi egy bejegyzésre. Ez nem feltétlen egy jó dolog, de legalább valami rendszeresség már van benne. Azért nem ártana letornászni ezt legalább heti egyre, de addig is, jöjjön a "januári bejegyzés". Remélem sikerül valami érdekeset hoznom az év első deadlime-os bejegyzésével.

A téma ismét a képekkel és a GD könyvtárral lesz kapcsolatos, bár a régi adatrejtéses bitbűvészkedésnél kicsit tovább merészkedünk a képfeldolgozás és a mintafelismerés irányába. A feladat roppant egyszerű lesz, egy adott képen szeretnénk megtalálni - lehetőleg - az összes hármas számot (azért pont a hármast, mert az kellően hasonlít a nagy b betűre, valamint a nyolcas számra is, így nehezítve a dolgunkat). Ehhez adott maga a kép, amin keresünk (egy kis zajjal nehezítettem a keresést, különben elég egyszerű lenne...), valamint egy minta, hogy mit is szeretnénk megtalálni. Vessük is rögtön bele magunkat a hogyanokba.