Mirmo Dynamics - Tag - librairie

Incubated

Geoffrey — Wed, 01 Nov 2006 16:10:00 +0100

Les liens interressants (ou pas) de la semaine:

J'ai pas mal entendu parler des microformats ces derniers temps, sans vraiment prendre le temps de me pencher dessus. microformats.org présente l'occasion de se plonger dedans et de comprendre que finalement, les microformats peuvent être un facteur de développement non négligeable pour un site ou une application web. GeoRSS de son côté propose une implémentation simple et puissante (c'est eux qui le disent) du Geotagging. A voir si on ne peut pas coupler tout ça avec quelques pirouettes sur Google Maps...

Pendant ce temps, chez Canonical, on établit déjà les specifications fonctionnelles de Feisty Fawn, et c'est assez prometteur :-)

Enfin, dans le petit monde du PHP et du webdev en général, il n'est jamais trop tard pour souligner l'existence de protocoles d'authentification centralisée libres comme OpenID, qui de plus à lancé un concours d'implémentation sous forme de bounties ! On notera également les débuts de l'extension d' input filtering pour PHP, qui promet de simplifier grandement la validation de données externes dans les applis PHP. Enfin, les slides de la conférences PHP Best Practices qui a eu lieu à la ZendCon, c'est vraiment rempli de bons conseils.

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 !

Intégrer une librairie tierce

Geoffrey — Wed, 06 Sep 2006 23:21:00 +0200

Il arrive forcément un moment dans un projet où le besoin de fonctionnalités avancées dans un domaine particulier (mail, réseau, etc) se fait sentir. En général, l'utilisation d'une librairie tierce s'avère nécessaire et pose quelques légers et irritants problèmes, particulièrement au niveau de la convention de nommage des classes et de l'arborescence des répertoires qui devient rapidement bordélique. Nos objectifs seront donc:

Utiliser une librairie tierce
Respecter la convention de nommage Zend
Avoir un arborescence propre

Ça tombe bien, c'est très simple à réaliser :-)

Pour ce faire, il convient de prendre nos objectifs à rebours, commençons donc par l'arborescence. Nous allons classer nos librairies par site, ce qui est une méthode assez courante. Admettons que vous ayez une arborescence de base (plus de précisions sur l'arboresence basique dans un prochain article):

app/
library/
	Zend/
	Zend.php
www/

Nous allons stocker nos librairies dans library/ext/, comme externe, et en fonction du domaine où on peut les trouver. Prenons le cas de l'excellent PHPMailer, qui est hébergé sur http://phpmailer.sourceforge.net/. Nous stockerons cette librairie dans library/ext/net/sourceforge/phpmailer/, ce qui résoud la problèmatique de l'arborescence.

Pour attaquer la 2ème problèmatique (convention de nommage), nous allons créer un nouveau répertoire dans library qui contiendra nos extensions au framework. Ce répertoire nous sera très utile par la suite. Nous l'appellerons ici Extensions, mais cela peut-être n'importe quel nom qui peut vous sembler approprié, Monappli par exemple. Une fois ce répertoire créé, nous pouvons passer aux choses sérieuses, et créer notre classe Extensions_Mailer dans library/Extensions/Mailer.php:

require_once dirname(__FILE__).'/../ext/net/sourceforge/phpmailer/class.phpmailer.php';

class Extensions_Mailer extends PHPMailer {

}

Et voilà, tous nos problèmes sont résolus. Notre classe est désormais reconnue par Zend::loadClass, ce qui finalement était bien le but de l'opération:

Zend::loadClass('Extensions_Mailer');
$mailer = new Extensions_Mailer;

L'objet $mailer est donc une instance de Extensions_Mailer, qui n'est finalement que la classe PHPMailer renommée ! Cela permet également au passage de surclasser PHPMailer pour y ajouter nos propres fonctions.