Már lassan egy éve nem volt új bejegyzés, gondoltam ideje írni valamit. :) Régebben már volt szó a PHP objektum-orientált adatbázis elérési felületéről, a PDO-ról. Mivel utóbb inkább csak a használatára tértem ki, nem lett megemlítve, hogy ezekből az osztályokból származtathatjuk saját osztályainkat is, ami alapvetően egy jó dolog tud lenni.

Vegyünk is egy egyszerű példát. Tegyük fel azt, hogy már annyira jók vagyunk, hogy az SQL szerverrel is csak l33t nyelven vagyunk hajlandóak kommunikálni. Persze a mysqld (vagy egyéb tetszőleges daemon) nem ilyen megértő, és folyamatosan panaszkodik, hogy nem ért meg minket. A probléma elsimítása érdekében származtatunk a beépített PDO osztályból egy sajátot:

class L33tPDO extends PDO {
	private static $from = array(
		's3l3ct', 'fr0m', 'wh3r3', 's3t', '1ns3rt', '1nt0', 'upd4t3', '0rd3r', '4sc', 'd3sc', 'l3ft', 'r1ght', '1nn3r', 'j01n'
	);
	private static $to = array(
		'SELECT', 'FROM', 'WHERE', 'SET', 'INSERT', 'INTO', 'UPDATE', 'ORDER', 'ASC', 'DESC', 'LEFT', 'RIGHT', 'INNER', 'JOIN'
	);
	public function query($statement, $type = false, $param1 = false, $param2 = false) {
		$statement = $this->convertStatement($statement);
		
		if ($type && $param1 && $param2) {
			return parent::query($statement, $type, $param1, $param2);
		}
		if ($type && $param1) {
			return parent::query($statement, $type, $param1);
		}
		if ($type) {
			return parent::query($statement, $type);
		}
		
		return parent::query($statement);
	}
	public function prepare($statement, $driver_options = array()) {
		$statement = $this->convertStatement($statement);
		parent::prepare($statement, $driver_options);
	}
	private function convertStatement($statement) {
		return str_ireplace(self::$from, self::$to, $statement);
	}
}

Hogy takarékoskodjunk a hellyel, a kulcsszavak listája nem teljes. Nézzünk is egy példát a használatra:

$conn = new L33tPDO('pgsql:host=localhost port=5432 dbname=test user=test password=test');

$stmt = $conn->query("s3l3ct * fr0m users wh3r3 id > 1 0rd3r by login_name 4sc" );

var_dump($stmt->fetchAll());

Bár a felhozott példa nem igényli, a PDOStatement osztályból is származtathatunk sajátot, csak meg kell mondanunk a saját PDO osztályunknak, hogy az általunk írt PDOStatement-tet adja vissza a megfelelő függvényei. Ehhez bővítsük ki a L33tPDO osztályunkat egy konstruktorral:

function __construct($dsn, $username = null, $password = null, $driver_options = array()) {
	parent::__construct($dsn, $username, $password, $driver_options);
	
	$this->setAttribute(PDO::ATTR_STATEMENT_CLASS, array('L33tPDOStatement', array($this)));
}

És egy hozzá passzoló statement osztály:

class L33tPDOStatement extends PDOStatement {
	private $dbh;
	protected function __construct($dbh) {
		$this -> dbh = $dbh;
	}
}

Ennyit mára. További kellemes kódolást.

Talán nem túlzás azt állítani, hogy a Firebug a legjobb dolgok közé tartozik, ami manapság egy JavaScript fejlesztővel történhetnek. A több mint 10 millió letöltés, valamint a tény, hogy - bár maga is kiegészítő - kiegészítőket fejlesztenek hozzá elég bizonyítékul is szolgálhat ennek alátámasztására. Egy ilyen kiegészítőbe futottam bele még valamikor a múlt héten, ami a FirePHP nevet viseli (a nevével ellentétben bármely más szerver oldali nyelvvel használható, ami képes header-öket kiküldeni). Nincs is másra szükségünk csak egy Firefox-ra (ez remélhetőleg már mindenkinek van :)), egy Firebug-ra (ez is esélyes lehet, hogy akad a közelben) és a FirePHP-ra. Meg egy kis szerveroldali scriptre, ami szintén a FirePHP oldaláról tölthető le.

FirePHP

A kiterjesztés mögött rejlő ötlet rettentően egyszerű (és talán éppen ezért olyan fantasztikus): küldjünk ki pár speciális fejlécet valamiféle JSON tartalommal, amit kliens oldalon a kiegészítő feldolgoz és a Firebug segítségével szépen meg is jelenít. Ezek lehetnek több prioritásba sorolható egyszerű szöveges üzenetek (hasonlóak a Firebug beépített üzeneteihez), táblázatok, szépen formázott backtrace-ek vagy akár print_r()-hez hasonló információk változókról.

Tovább...

A szokásos "napi" php.net böngészgetésem során bukkantam rá a lentebb olvasható kódrészletre (bár nem egy bonyolult dolog, de mégsem jutott volna magamtól eszembe), amit szerintem kötelezővé kellene tenni minden egyes PHP alapú alkalmazás fejlesztési időszaka alatt. A kód nem csinál mást, mint hogy minden hibát kivétellé alakít át, így ha nincsenek elkapva, akkor egy egyszerű E_NOTICE-tól is lehal az oldal fatal error-ral, az error_reporting beállítástól függetlenül. :)

function error_handler($errno, $errstr, $errfile, $errline)
{
    throw new ErrorException(
        $errstr, 0, $errno,
        $errfile, $errline
    );
}
set_error_handler('error_handler');

Egyéni ízlés kérdése, de én még az alábbi kóddal kiegészíteném, hogy fatal error-ok helyett inkább valami olvasható dolgot kapjak:

function exception_handler($ex)
{
	print('<pre>'.$ex.'</pre>');
}
set_exception_handler('exception_handler');

És hogy miért is lenne hasznos? Elég sokan kikapcsolják az E_NOTICE-ok jelzését még fejlesztés alatt is, mondván hogy az nem számít. Pedig elég sok kisebb hibára (pl. változó név vagy tömb kulcs elgépelésekre) hívhatná fel a figyelmet, amik így csak a tesztelési időszakban derülnek ki (ha kiderülnek). Emellett biztonsági haszna is van, mint az a php.net-en is olvasható.

Mostanság parancssori scripteket írogatok Python-ban, ha éppen nincs jobb dolgom (ritka). Gondoltam hát, hogy ezzel kapcsolatos tapasztalataimat és a nyelvvel való ismerkedésemet megosztom egy - egyelőre még nem tudni hány részes - bejegyzéssorozatban. Az első rész témája az alkalmazásnak átadott paraméterek feldolgozása a getopt és az optparse modulok segítségével.

A programunk egy egyszerű "Hello World!" alkalmazás lesz parancssori stílusban. Két fajta bemenő paramétert fogad el. Az egyik a név, akinek köszönni fog, a másikra pedig megjeleníti a súgót, hogy hogyan is kell paraméterezni ezt a rettentő bonyolult programot.

Tovább...

Néha a lustaságomon felül kerekedik az a vágy, hogy új programozási nyelveket ismerjek meg. Ennek lett a legfrissebb áldozata a Python. Bár már volt vele dolgom régebben is, de körülbelül csak egy Fibonacci-számokat számoló rekurzív függvény megvalósításáig jutottam (az is nagy valószínűséggel valami példakód volt valamelyik segédletből).

Magáról a nyelvről azt lehet elmondani, hogy feltűnően szépnek mondható ahhoz képest, hogy a Pascal-stílusú nyelvek közé tartozik. És nem csak egyszerűen szép, hanem törekszik arra, hogy a benne írt kód is szép legyen (ahogy az a Python filozófiáinak listájában is szerepel: "Beautiful is better than ugly."). Persze ehhez az is kell, hogy ne csak Python nyelven, de Python stílusban is programozunk.
A kinézetet tekintve legszembetűnőbb különbség más nyelvekhez képest a kód kötelező indentálása. Nincsenek sorvégi pontok, pontosvesszők, if-eket és egyéb blokkszerkezeteket lezáró hullámos zárójelek vagy kulcsszavak. Minden az új sor karakterek és az indentálás alapján dől el. De mivel kódolás közben a nagy többség amúgy is szokott új sorokat és tabokat használni (és mivel a kötelező indentálás az esetek közel 100%-ában megegyezik azzal, amúgy is használnánk), ezért elég gyorsan hozzá lehet szokni ahhoz, hogy tulajdonképpen kevesebbet kell gépelni. Persze ez még kevés ahhoz, hogy használható is legyen valamire. Mivel napjaim nagy részét a webprogramozás teszi ki, ezért a szintaktikai ismerkedés után első dolgom az volt, hogy utánanézzek, mire is képes a kígyó a weben...

Tovább...

Avagy az oldal összerakásával terheljük inkább a látogató böngészőjét a szerver helyett.

Néha egész érdekes dolgokat lehet látni, ha az ember - szakmai ártalomból, vagy csak egyszerű kíváncsiságból - beleles egyes oldalak forrásába. Az ilyen oldalak közé tartozik a The World of Warcraft Armory is. Az első pillantásra elég bonyolultnak tűnő oldal mögött meglepően kicsi (5 soros) XML fájl van. Legalábbis látszólag. Természetesen az XSLT áll a dolog mögött, aminek a szerver oldali alkalmazásáról már réges-régen ejtettem pár szót. Nézzük akkor most meg, hogy kliens oldalon mit művelhetünk vele:

Tovább...

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.

Tovább...

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...

Tovább...

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:

Tovább...