Digital Fashion

Pour installer le serveur PEAR, c'est simple:

pear channel-discover pear.chiaraquartet.net
pear install chiara/Chiara_PEAR_Server
pear run-scripts Chiara_PEAR_Server

Ensuite on répond aux question, et c'est automagique.

Après, pour créer des packages, ça se corse. Tout d'abord, on a besoin de PEAR_PackageFileManager:

pear install PEAR_PackageFileManager

Ensuite, le but est de générer les package.xml qui vont bien. Voilà comment j'ai procédé pour le package Zend:

mkdir -p ~/pear/zend/src && cd ~/pear/zend
wget http://framework.zend.com/download/tgz -O - | tar xzC ~
mv ~/ZendFramework-0.8.0/library/Zend* src/
php ./mkpkg.php make
cd src && pear package

Ceux qui ont bien suivi auront noté que mkpkg.php est sorti un peu de l'espace :-) Vous trouverez son contenu à la fin du billet.

Pour résumer, on créé un répertoire de travail (~/pear/zend/), dans lequel on créé un répertoire src, qui contiendra tous les fichiers du package, puis le script mkpkg.php se charge 1) d'analyser le contenu de src, et 2) de créer le package.xml qui va bien, selon les instructions qui lui sont fournies.

Nous disposons désormais d'un package Zend-0.8.0.tgz dans ~/pear/zend/src, que nous n'avons plus qu'a uploader via l'interface d'administration du serveur PEAR précédemment installé :-)

Le fichier mkpkg.php:

<?php

require_once('PEAR/PackageFileManager2.php');

PEAR::setErrorHandling(PEAR_ERROR_DIE);

$packagexml = new PEAR_PackageFileManager2;

$e = $packagexml->setOptions(array(
    'baseinstalldir' => '/',
    'packagedirectory' => dirname(__FILE__).'/src',
));

$packagexml->setPackage('Zend');
$packagexml->setSummary('Zend Framework');
$packagexml->setDescription('The Zend\'s PHP Framework');
$packagexml->setChannel('pear.phpmafia.net');
$packagexml->setAPIVersion('0.8.0');
$packagexml->setReleaseVersion('0.8.0');
$packagexml->setReleaseStability('devel');
$packagexml->setAPIStability('devel');
$packagexml->setNotes("Still a preview release");
$packagexml->setPackageType('php'); // this is a PEAR-style php script package
$packagexml->addRelease(); // set up a release section
$packagexml->setPhpDep('5.1.2');
$packagexml->setPearinstallerDep('1.4.0a12');
$packagexml->addMaintainer('lead', 'ash', 'Geoffrey Bachelet', 'geoffrey+pear@zubrowka.org');
$packagexml->setLicense('New BSD License', 'http://framework.zend.com/license/new-bsd');
$packagexml->generateContents(); // create the <contents> tag

$pkg = &$packagexml->exportCompatiblePackageFile1(); // get a PEAR_PackageFile object

if (isset($_GET['make']) || (isset($_SERVER['argv']) && @$_SERVER['argv'][1] == 'make')) {
    $pkg->writePackageFile();
    $packagexml->writePackageFile();
} else {
    $pkg->debugPackageFile();
    $packagexml->debugPackageFile();
}

?>

Les beaux jours reviennent, le Zend Framework est de sortie, dans sa version 0.8, qui apporte son lot de belles choses, comme par exemple le passage Zend_Auth, Zend_Mail_Read et Zend_Rest_Server dans le core.

Youpi.

Les concepts de classes abstraites et d'interfaces sont souvents assez flous quand on débute dans la programmation objet, et on se fourvoie assez souvent sur leur utilisation et leur but. Voila une petite explication qui j'espère sera 1) juste et 2) assez claire pour tout le monde. Si vous pensez que je me fourvoie sur ces 2 concepts de base de la POO, n'hésitez pas à me le faire savoir !

Une des questions cruciales qui se pose à tout développeur à au moins un moment de sa vie (souvent plusieurs en fait) est le choix d'un environnement de développement. J'en ai testé pas mal, plus ou moins longtemps, et bien que je ne sois jamais complètement satisfait, l'idée de perdre du temps à développer le mien m'indispose. J'ai donc opté pour l'environnement qui me va le mieux: Linux + gVim + Rox-filer.

Note: je ne couvre pas ici les fonctionnalités de débuging avancé, que je n'utilise pas encore, mais pour lesquelles j'ai déjà en tête des solutions qui me conviendront bien mieux que les outils intégrés à un quelconque IDE (je pense fortement à Xdebug).

Pré-requis: Zend_Controller_RewriteRouter.

Nous allons voir aujourd'hui comment générer automagiquement des URLs à partir des routes définies dans le RewriteRouter, ainsi que les avantages que cela présente. Le Helper que nous allons utiliser nécessite le stockage du routeur dans le registre:

Zend::register('router', $router);

Avant de voir le Helper lui même, un petit Use Case. Admettons que vous développiez une application de gestion de petites annonces, vous aurez à un moment ou un autre à créer un lien quelconque pour, par exemple, créer une annonce, et en voir les détails. Disons que vous ayez des routes route du genre (je zappe les defaults):

announceCreate.route = /announce/create
announceDetails.route = /announce/:id/details

L'objectif est de pouvoir créer les liens grâce au code suivant (à partir de la view):

<a href="<?php echo $this->href('announceCreate'); ?>">Créer une annonce</a>
<a href="<?php echo $this->href('announceDetails', array('id' => $announce->id)); ?>">Voir l'annonce</a>

Et comme le Zend Framework est bien fait, c'est très simple à réaliser sous forme de ViewHelper:

class Zend_View_Helper_Href {
	
	/**
	 * Returns the href to a given route
	 *
	 * @param string $routeName
	 * @param array $args
	 * @return string
	 */
	
	public function href($routeName, $args = array()) {
		try {
			return Zend::registry('router')->getRoute($routeName)->assemble($args);
		} catch (Zend_Controller_Router_Exception $e) {
			return '#404';
		}
	}
}

Tellement simple que pour combler un peu je vous offre le docblock qui va avec ;-)

Là où ça devient très pratique, c'est quand on souhaite localiser les URLs. Par exemple, imaginons que vous souhaitiez françiser les URLs pour, par exemple, améliorer votre référencement. Vous n'avez qu'a définir un jeu de routes fr_FR, par exemple ainsi:

L'utilisation de l'héritage géré par Zend_Config nous permet ici d'éviter la redondance des defaults.

Elle est pas belle la vie ?

Note: cette fonctionnalitée est prévue pour être builtin plus tard.

J'ai fermé le blog Zend que j'avais ouvert, tout simplement parcequ'il me semble de plus en plus clair que le genre de personne susceptible d'écrire sur ce genre de blog possède déjà un blog, et qu'il serait bien présomptueux de penser qu'ils preferreraient écrire sur mon blog plutôt que sur le leur. J'ai donc installé un moonmoon à la place, dont le but ultime est d'aggréger les blogs francophones (ou leurs tags / catégorie) traitant de près ou de loin de PHP, à la manière du Planet PHP originel, donc. La planet en question est donc disponible sur http://phpmafia.net/, et vous y trouverez d'ores et déjà les blogs qui figurent en bonne place dans mon lecteur RSS.

Pour faire partie du planet, il suffit de m'envoyer un mail avec l'adresse de votre blog (ou de sa partie traitant de PHP), ainsi que votre nom / pseudonyme, et c'est tout :-)

Pour en revenir au blog Zend Framework, vous trouverez désormais mes billets sur ce blog, sous le tag Zend Framework.

Comme je le disais plus bas, le Zend Framework Preview 0.2.0 est dans les bacs ! Cette nouvelle mouture apporte son lot de nouveautés, et nous allons nous pencher sur une des plus interressantes: le RewriteRouter. Le RewriteRouter est un routeur pour le composant MVC du Zend Framework qui va nous permettre de configurer nos URL comme dans Ruby on Rails, c'est à dire (en gros), via un fichier de configuration, et c'est là que Zend_Config entre en jeu.

Rien de plus simple, tout est déjà prévu. Après l'installation de votre forum IPB, nous allons enregistrer une nouvelle méthode de login. Pour se faire, dans le panneau d'administration, nous nous dirigeons vers Tools and Settings, puis dans Create New Log In du menu Log In Manager. On se retrouve devant un formulaire (assez explicite) que je vous laisse le soin de remplir. On dira juste que nous appellerons cette méthode de login Mon SSO (Log In Title) et qu'il vivra dans le répertoire mon_sso (Log In Files Folder Name). Pour que votre méthode de login soit active, vous devez cocher Log In Enabled, et il est toujours bon de passer en mode On-Fail, ainsi que d'autoriser la création d'utilisateurs (Log In Allow Member Creation), qui créera automagiquement les utilisateurs dans la base locale d'IPB.

Il y a tout un tas de raisons d'écrire des tests unitaires pendant ses développements, comme raccourcir radicalement le cycle code, test, debug, fix, assurer le fonctionnement de la globalité de l'application tout au long du développement, etc. Une autre que je viens de découvrir, c'est qu'écrire des tests unitaires, c'est tout simplement réfléchir à des situations susceptibles de casser votre application. On y passe beaucoup plus de temps que lorsque l'on développe vraiment, et du coup, on trouve beaucoup plus de choses, et on fait directement les modifications nécessaires. Chouette ça.