Mirmo Dynamics

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.

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.

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Il existe au bas mot autant de manières de gérer la configuration d'une application qu'il y a de développeurs: fichier INI, variables, constantes, fichier XML, etc. Le composant Zend_Config développé par Rob Allen propose une approche simple et élégante basée sur un fichier INI qui permet de mettre en place aisément plusieurs environnements de configuration. Commençons par rappeler qu'un fichier INI s'écrit le plus simplement du monde en associant un nom de variable (composante gauche) à une valeur (composante droite) en leur interposant un signe d'égalité:

name = value

On peut également y ajouter des sections, qui permettent de structurer le fichier:

Venons en au vif du sujet, l'utilisation proprement dite du sus-cité composant. N'y allons pas par quatre chemins, balançons directement un petit bout de code:

Zend::loadClass('Zend_Config');
Zend::loadClass('Zend_Config_Ini');

$config = new Zend_Config(Zend_Config_Ini::load('mon/fichier/ini', 'section'));

Rien de bien compliqué, on indique a Zend_Config_Ini un fichier INI à charger, et plus précisément quelle section de ce fichier nous interresse, puis il transmet les informations qui vont bien à Zend_Config, qui s'occupe de nous créer un bel objet de configuration. L'objet $config contient dès lors les valeurs du fichier INI comme autant de variables membres. Par exemple, si on utilise le fichier INI détaillé plus haut, on pourrait faire:

echo $config->username;

Ce qui afficherai unprivilegieduser. Simple non ? Simple, mais ne nous leurrons pas, ce n'est pas là l'usage que l'on fera de ce composant. En effet, quoi de plus rébarbatif que de devoir charger chaque section d'un fichier INI ? La vraie puissance de ce système réside dans le fait qu'il permet d'avoir des environnement de configuration séparés. Remanions légèrement notre fichier de configuration:

; Developement environement configuration
[dev]
db.hostname = localhost
db.username = unprivilegieduser
db.password = someobscurepassword
db.database = mydatabase

; Production configuration
[prod]
db.hostname = db.monsite.fr
db.username = someobscureuser
db.password = somereallyobscurepassword
db.database = mydatabase

Comme Zend_Config_Ini fait bien les choses, il analysera chaque nom de variable pour créer une arborescence d'objets en utilisant le . (point) comme séparateur. On aura ainsi:

$config = new Zend_Config(Zend_Config_Ini::load('./example.ini', 'dev'));
echo $config->db->username;

Il ne reste plus qu'a déterminer une manière de savoir quand on se trouve dans l'environnement de production ou dans celui de développement, il existe quelques méthodes pour cela:

• un fichier .htaccess avec une directive SetEnv DEV 1, qui donnera la variable $_ENV['DEV'] dans le script
• un test sur l'IP du serveur (IP locale, serveur de développement, IP publique pour le serveur de production)
• un test sur la variable $_SERVER['HTTP_HOST'] (dev.monsite.fr, etc)

A titre personnel, j'utilise la solution du .htaccess, qui peut s'implémenter comme ça:

$section = isset($_ENV['DEV']) ? 'dev' : 'prod';
$config = new Zend_Config(Zend_Config_Ini::load('./example.ini', $section));

On peut bien entendu enregistrer notre instance de $config dans le Zend_Registry:

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

Ce qui nous permettra d'y avoir accès en toute simplicité par la suite:

$config = Zend::registry('config');

(Commentaires et Trackbacks sur PHP Mafia)