Mirmo Dynamics - Tag - surclassage

Collections, Object Chaining, et la vérité sur le Père Noël

Geoffrey — Wed, 29 Nov 2006 23:09:00 +0100

Aujourd'hui je vais vous parler de deux concepts que j'aime beaucoup et que j'ai (re)découverts en travaillant sur mon projet personnel de conquête de l'univers: les Collections d'objets et l'Object Chaining.

Les collections, qui sont peut-être finalement un design pattern connu sous un autre nom, permettent d'executer aisément des méthodes sur plusieurs objets (une collection d'objets quoi). Concrétement, disons qu'on à une classe My_Collection, qui implémente les interfaces Iterator (et Countable tant qu'a faire) de la SPL, ainsi que la fonction magique __call suivante (je vous fait grace du docblock):

class My_Collection implements Iterator, Countable {
	public function __call($method, $args) {
		$calls = 0;
		foreach($this as $item) {
			if (method_exists($item, $method)) {
				call_user_func_array(array($item, $method), $args);
				$calls++;
			}
		}
		if ($calls > 0) {
			return $this;
		} else {
			throw new My_Collection_Exception('Method catched but could not be called: '.$method);
		}
	}
}

Ce dispositif permet d'utiliser le genre de code suivant (si les objets de la collection le permettent, bien évidemment, et disons qu'ici ce sont des objets représentant des images, supportant les méthodes move et createThumbnail):

# $array contient les objets My_Image
$collection = new My_Collection($array);
$collection->move('/new/path/')->createThumbnail();

Ce qui, comme vous l'aurez deviné, déplacera les fichiers de la collection vers /new/path, puis en créera des miniatures.

Deuxième chose, l'Object Chaining. On vient de le voir en fait, ça consiste à chainer les appels de méthodes grâce à un subtil return $this;, qui retourne donc une référence à l'objet courant. Exemple pratique, dans le Zend Framework, en étendant Zend_View:

class My_View extends Zend_View {
	public function assign($spec) {
		$args = func_get_args();
		call_user_func_array(array('parent', 'assign'), $args);
		return $this;
	}
}

Ce qui autorise le genre de code suivant (en admettant que vous ayiez une instance de My_View dans le registre):

Zend::registry('view')
	->assign('foo', $foo)
	->assign('foo', $bar)
	->render('template.php');

Et là c'est fort, parceque ça rejoint fortement quelque chose dont je parlais en janvier dernier (le truc qui parle de with), et donc j'en déduis une chose formidable: Le père noël existe, et il m'a entendu. Merci Santa Copain.

Bootstrap CLI

Geoffrey — Fri, 13 Oct 2006 18:31:00 +0200

Nous avons parcouru dernièrement la création du bootstrap HTTP qui sert de socle à une application utilisant le Zend Framework. Le même principe peut s'appliquer aux scripts CLI, mais comme les besoins sont fondamentalements différents, l'implémentation sera elle aussi complètement différente. Nous viserons les objectifs suivants:

Ne pas être obligé d'executer le bootstrap en ligne de commande
Simplifier au maximum l'écriture ultérieure des scripts CLI
Définir un jeu d'options de ligne de commande obligatoire
Mettre en place un environnement d'execution

La tentation serait de créer un système qui obligerait ce genre de commandes:

$ php batch/bootstrap.php monscript

Pour executer, par exemple, le script batch/monscript.php. Cela simplifierait grandement les choses, mais c'est moche, et puis on peut faire autrement, donc on ne va pas se priver ! Nous utiliserons a cette fin la fonction magique register_shutdown_function, qui s'occupera d'appeler une fonction qui executera les scripts ad hoc.

Avant d'aller plus loin, l'arborescence de fichiers que nous allons utiliser:

batch/
	monscript.php
	runtime.php
library/
	Zend.php
	My/
		Batch.php

runtime.php sera le fichier à inclure dans chaque script, tandis que My/Batch.php contiendra la classe d'abstraction My_Batch, qui définira les comportements par défaut de nos scripts.

Voici donc la première partie de notre bootstrap, batch/runtime.php:

ini_set('include_path', get_include_path().PATH_SEPARATOR.realpath(dirname(__FILE__).'/../library/'));

require_once 'Zend.php';
require_once 'My/Batch.php';

register_shutdown_function(array('My_Batch', 'runAll'));

Bien sur, cette méthode nous oblige à définir un format à respecter pour les fonctions à executer par la suite, nous partirons donc sur les bases suivantes:

Chaque batch doit être constitué d'une classe dont le nom commence par My_Batch_
Chaque batch doit posséder une méthode executable run

Ce qui nous donne donc:

abstract class My_Batch {
	static public function runAll() {
		$classes = get_declared_classes();
		foreach($classes as $className) {
			if (preg_match('/^My_Batch_(.+)$/', $className, $matches) && method_exists($className, 'run')) {
				try {
					$batch = new $className;
					$batch->run();
				} catch (Exception $e) {
					die(sprintf("%s: %s\n", $matches[1], $e->getMessage()));
				}
			}
		}
	}
	
	abstract public function run();
}

On en profite pour catcher toute Exception indésirable pour la transformer en un die, bien plus lisible dans un terminal qu'une backtrace :-)

Maintenant que nous avons résolu les points 1 et 2, attaquons nous à la suite. Le problème principal que j'ai rencontré lors de l'établissement d'un environnement d'execution, c'est que la gestion de la configuration repose en grande partie sur la valeur de $_SERVER['HTTP_HOST'], qui n'est bien évidemment pas disponible en CLI :-) Il me faut donc forcer le passage en argument du nom de la configuration à utiliser. C'est très simple à faire, grace a la méthode que nous avons employé: il suffit de vérifier la présence de cet argument dans le constructeur de My_Batch :-)

public function __construct() {
	foreach($GLOBALS['argv'] as $i => $arg) {
		switch ($arg) {
			case '--configname':
			case '-c':
				$this->_args['configname'] = $GLOBALS['argv'][$i+1];
			break;
		}
	}
	if (!isset($this->_args['configname'])) {
		throw new Exception('-c or --configname is mandatory');
	}
}

Voilà, le gros du travail est fait. Pour le reste, c'est la routine, mise en place d'un environnement avec Zend_Config et Zend_Db, a la suite dans le constructeur:

	$this->_config = new Zend_Config(
		Zend_Config_Ini::load(
			dirname(__FILE__).'/../../app/config.ini',
			$this->_args['configname']
		)
	);
	
	$this->_db = Zend_Db::factory(
		$this->_config->db->adapter,
		$this->_config->db->config->asArray()
	);
	
	Zend_Db_Table::setDefaultAdapter($this->_db);

Enfin, voila un exemple de script utilisant ce bootstrap:

require_once 'path/to/runtime.php';

class My_Batch_MonScript extends My_Batch {
	public function run() {
		// le code ici
	}
}

And voila !

Aller plus loin avec Zend_Db_Table

Geoffrey — Thu, 07 Sep 2006 23:25:00 +0200

Nous avons vu précédemment les bases de l'utilisation du composant Zend_Db, qui nous permet de manipuler les tables via les actions de base CRUD. Malheureusement, dans la plupart des cas, les outils fournis ne suffisent pas, et le besoin de pouvoir gérer les tables de données d'une manière plus fine et surtout plus spécifique se fait sentir. C'est là qu'entre en jeu le surclassage.

En effet, comme nous l'avons vu la dernière fois, utiliser Zend_Db_Table se résumé, pour débuter, à un simple surclassage:

class Members extends Zend_Db_Table {

}

Cette méthode laisse le champs libre à la création de méthodes spécifiques à chaque table. Nous pouvons par exemple vouloir remplir des champs automatiquement à chaque insertion ou mise à jour, par exemple des champs created_on et/ou updated_on:

class Members extends Zend_Db_Table {
	public function insert(&$data) {
		if (!isset($data['created_on'])) {
			$data['created_on'] = date('Y-m-d H:i:s');
		}
		return parent::insert($data);
	}

	public function update(&$data, $where) {
		if (!isset($data['updated_on'])) {
			$data['updated_on'] = date('Y-m-d H:i:s');
		}
		return parent::update($data, $where);
	}
}

Note: Dans cet exemple, vous pouvez constater que la variable $data de la méthode update est passée par référence. C'est tout simplement pour respecter la définition originelle des méthodes, ce qui est requis pour passer le niveau d'erreur E_STRICT.

Nous pouvons également redéfinir le comportement d'une action:

class Members extends Zend_Db_Table {
	public function delete($where) {
 		$data = array(
 			'status' => 0,
 		);
		return $this->update($data, $where);
	}
}

Il est aussi possible de définir nos propres méthodes de recherche ou d'écriture:

class Members extends Zend_Db_Table {
	public function findByMail($mail) {
		$where = $this->_quoteInto('mail = ?', $mail);
		return $this->fetchRow($where);
	}
	
	public function getByZipcode($zipcode) {
		$where = $this->_quoteInto('zipcode = ?', $zipcode);
		return $this->fetchAll($where);
	}
	
	function updateById(&$data, $id) {
		$where = $this->_quoteInto('id = ?', $id);
		return $this->update($data, $where);
	}
	
	private function _quoteInto($mask, $value) {
		return $this->getAdapter()->quoteInto($mask, $value);
	}
}

On notera ici la création également d'une méthode privée qui n'est qu'un raccourci pour protéger les clauses WHERE contre les injections SQL.