Mirmo Dynamics - Tag - howto

Multiple domains for one symfony project, the basics, config file version

Geoffrey — Thu, 22 Jan 2009 22:02:00 +0100

When I published my post about using a single symfony application to serve multiple domains using a database to store the site-specific data, there was some people to complain about the extra query you get on each request. Right. Using a (cached) config file instead is not that hard as long as you use it only to match a domain name against a numeric id. Storing more site-specific data is a bit more problematic, but we will solve this in a later post.

And because I'm lazy, I won't re-write the entire article, just highlight the differences between the two methods, so you might as well read the database version if you did not already.

Now, first thing, the config file. We will create a simple project-wide config file: /config/app.yml:

all:
  paris.carshop: 1
  auckland.carshop: 2

Then we detect the site and add a generic sfConfig entry for it. This is done, as before, in /config/ProjectConfiguration.class.php. We will only change the detectSite() method to take advantage of the cached config information:

[php]
  public function detectSite(sfEvent $event)
  {
    sfConfig::add(array('site_id' => sfConfig::get('app_'.$_SERVER['HTTP_HOST'])));
  }

Easy heh ?

Now we just have to adapt the model classes to use this config entry. The CarTable::createQuery() method will look like:

[php]
/**
 * Creates a query, adding the site criteria automatically
 *
 * @return Doctrine_Query
 * @see Doctrine_Table::createQuery()
 */

public function createQuery($alias = '')
{
  $query = parent::createQuery($alias);
  $query->where('site_id = ?', sfConfig::get('site_id'));
  
  return $query;
}

The Car::save() method:

[php]
/**
 * Automatically populates the site_id field if necessary
 * 
 * @see sfDoctrineRecord::save()
 */

public function save(Doctrine_Connection $conn = null)
{
  if (empty($this->site_id))
  {
    $this->setSiteId(sfConfig::get('site_id'));
  }

  return parent::save();
}

And you're all set ! For the record, here are the other modified files from the last post:

config/doctrine/schema.yml:

Car:
  columns:
    site_id:      { type: integer }
    name:         { type: string(255) }
    description:  { type: clob }
    image:        { type: string(255) }

data/fixtures/ now contains only the Car fixtures:

Car:
  car_1:
    site_id: 1
    name: Peugeot 307
    description: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  car_2:
    site_id: 1
    name: Renault Laguna
    description: Maecenas tortor nunc, aliquam et, ultrices id, ornare consectetur, mauris.
  car_3:
    site_id: 2
    name: Subaru Impreza
    description: Ut accumsan diam et orci. Sed sit amet neque ac diam rutrum iaculis.

Multiple domains for one symfony project, the basics

Geoffrey — Mon, 29 Dec 2008 11:10:00 +0100

So let's say you run a car franchise, and you have several shops that you want to be able to manage through a web application. The application would be same for each shop, except you'd have to manage different sets of data and have specific assets for each shop. Fear not, this is very easy to achieve using symfony (well, it's quite easy with any framework I guess, but we will be using symfony :p)

Sample project

At the beginning, there were generate:project:

$ mkdir carshop
$ cd carshop
$ symfony generate:project carshop
$ symfony generate:app frontend
$ symfony generate:module frontend default

We will also need a simple database schema for the sake of examples. We will be using Doctrine, so let's fill in our config/doctrine/schema.yml with a very simple schema:

[yml]
detect_relations: true

Car:
  columns:
    site_id:      { type: integer }
    name:         { type: string(255) }
    description:  { type: clob }
    image:        { type: string(255) }

Site:
  columns:
    name:         { type: string(255) }
    domain:       { type: string(255), unique: true }
    main:           { type: boolean, default: false }

Also, let's not forget to enable Doctrine in our project in config/ProjectConfiguration.class.php, replace the line:

[php]
$this->enableAllPluginsExcept('sfDoctrinePlugin');

with:

[php]
$this->enableAllPluginsExcept('sfPropelPlugin');

and to configure the database:

$ symfony configure:database --name=doctrine --class=sfDoctrineDatabase "mysql:host=localhost;dbname=carshop" root

Oh, we shall need some fixtures too, let's put them in data/fixtures/01_sites.yml:

[yml]
Site:
  paris:
    name: Paris
    domain: paris.carshop
  auckland:
    name: Auckland
    domain: auckland.carshop

and data/fixtures/02_cars.yml:

[yml]
Car:
  car_1:
    Site: paris
    name: Peugeot 307
    description: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  car_2:
    Site: paris
    name: Renault Laguna
    description: Maecenas tortor nunc, aliquam et, ultrices id, ornare consectetur, mauris.
  car_3:
    Site: auckland
    name: Subaru Impreza
    description: Ut accumsan diam et orci. Sed sit amet neque ac diam rutrum iaculis.

And now that everything is ready, let's create the tables and load the fixtures:

$ symfony doctrine:build-all-load

Vhosts

The second thing we will need is a set of vhost with differents domains all pointing to our newly generated project. It's quite easy to do, and I will assume you run some kind of linux or unix here (although it's similar under windows if I remember well). Let's start with creating fake domain names, you just have to add the following line to your /etc/hosts:

127.0.0.1 auckland.carshop paris.carshop

And the following to your apache vhost:

[apache]
ServerName paris.carshop
ServerAlias *.carshop

Save and quit, reload apache, and you're all set.

Detecting the current site

First thing we need to know if we want to handle site-specific data, is which site we're currently in. This can easily be done in the project configuration. Since we will need database access, we will hook up on the context.load_factories event. So, on with coding, open your config/ProjectConfiguration.class.php and add the following line to the setup() method:

[php]
$this->dispatcher->connect('context.load_factories', array($this, 'detectSite'));

This will hook the detectSite() method to the event context.load_factories. We now need to add the detectSite() method to the ProjectConfiguration class:

[php]
/**
 * Detects the current site based on the url
 * Fallback to the main site (main = 1 in database) if we can't find a suitable entry
 *
 * @param sfEvent $event
 */

public function detectSite(sfEvent $event)
{
  $request = sfContext::getInstance()->getRequest();
  $domain = $request->getHost();

  $siteTable = Doctrine::getTable('Site');

  if (false !== $site = $siteTable->retrieveByDomain($domain))
  {
    $siteTable->setCurrent($site);
  }
  else
  {
    $siteTable->setCurrent($siteTable->retrieveMain());
  }
}

Nothing very hard here. We get the HTTP host from the request, then try to fetch a corresponding Site from the database, fallbacking to the main site if necessary. You may have noticed that we added three methods to the Site model class: retrieveByDomain(), retrieveMain() and setCurrent(). Your lib/model/doctrine/SiteTable.class.php should look like this now:

[php]
<?php
/**
 * This class has been auto-generated by the Doctrine ORM Framework
 */
class SiteTable extends Doctrine_Table
{

  /**
   * Holds the current site
   * @var Site
   */

  protected $current;

  /**
   * Retrieve a Site by its domain
   *
   * @param string $domain
   * @return Site or false if no site is found
   */

  public function retrieveByDomain($domain)
  {
    return $this->createQuery()->where('domain = ?', $domain)->fetchOne();
  }

  /**
   * Retrieve the main site
   *
   * @return Site or false if no site is found
   */

  public function retrieveMain()
  {
    return $this->createQuery()->where('main = 1')->fetchOne();
  }
  

  /**
   * Sets the current site
   *
   * @param Site $site
   */

  public function setCurrent(Site $site)
  {
    $this->current = $site;
  }

}

While we're there, let's add a getCurrent() method as well:

[php]
/**
 * Gets the current site
 *
 * @return Site
 */

public function getCurrent()
{
  return $this->current;
}

Handling domain-specific logic and data

Ok, so now that we know where we are, let's make the Car model aware of the current site. Open lib/model/doctrine/CarTable.class.php and add the createQuery() method:

[php]
/**
 * Creates a query, adding the site criteria automatically
 *
 * @return Doctrine_Query
 * @see Doctrine_Table::createQuery()
 */

public function createQuery($alias = '')
{
  $query = parent::createQuery($alias);
  $query->where('site_id = ?', Doctrine::getTable('Site')->getCurrent()->getId());
  
  return $query;
}

This is the method used internally by Doctrine_Table to create queries related to the Car model, so now, all find methods fired from the Car model will only fetch cars from the current site. We need to take care of this at save() time too, in lib/model/doctrine/Car.class.php:

[php]
/**
 * Automatically populates the site_id field if necessary
 * 
 * @see sfDoctrineRecord::save()
 */

public function save(Doctrine_Connection $conn = null)
{
  if (empty($this->site_id))
  {
    $this->setSite(Doctrine::getTable('Site')->getCurrent());
  }

  return parent::save();
}

Handling domain specific assets

On with the assets. We are going to use our good friend mod_rewrite to handle this. First, let's create a specific directory for each domain we're going to manage:

$ mkdir -p web/perhost/{paris,auckland}.carshop/{css,images,js,uploads}

Also, for testing purpose, let's create some fake js file:

$ echo 'paris.carshop' > web/perhost/paris.carshop/js/foo.js
$ echo 'auckland.carshop' > web/perhost/auckland.carshop/js/foo.js
$ echo 'fallback' > web/js/fallback.js

Then add some voodoo magic in your web/.htaccess, before the we skip all files with .something rules generated by symfony:

[apache]
RewriteCond /home/ash/projects/carshop/trunk/web/perhost/%{HTTP_HOST}%{REQUEST_FILENAME} -f
RewriteRule (.*) /perhost/%{HTTP_HOST}/$1 [L]

Please note that %{REQUEST_FILENAME} includes the starting /, so that we don't need to add one after %{HTTP_HOST}.

Now check that you have mod_rewrite enabled (for example check that /etc/apache2/mods-enable/rewrite.load exists). If it's not enabled it, do it now:

$ sudo a2enmod rewrite
$ sudo /etc/init.d/apache2 reload

You can test the following urls to see if everything is going well, the results should be pretty obvious:

See you next time !

Now you have a working multi-domain architecture for your symfony project, but there are still a couple of things we could (and will) discuss:

uploading assets (from forms for example)
having a different layout for each site
having specific css files for each site (eg: paris.css and auckland.css)
cache problematic for shared assets

All these points will be addressed in the next part of this tutorial, but not before 2009 has came !

Débuter avec le Zend Framework

Geoffrey — Thu, 12 Apr 2007 00:31:00 +0200

Pour info.

Je suis un peu triste parce que je voulais m'atteler à cette tâche, mais bon il faut croire que j'ai trop lambiné :)

Mini Howto: Serveur et Packages PEAR

Geoffrey — Fri, 02 Mar 2007 12:11:00 +0100

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();
}

?>

Remplacer un caractère par un "Carriage Return" dans vim

Geoffrey — Wed, 03 Jan 2007 11:04:00 +0100

Par exemple, imaginons qu'on récupère une query string, et qu'on veuille l'exploser sur plusieurs lignes, on peut faire:

:s/&/\="\<CR>"/g

le \="" annonce à VIM que la chaine de substitution sera une chaine a interpréter avant utilisation, et le \<CR> représente tout simplement le Carriage Return.

Annuler un changeset SVN

Geoffrey — Sun, 17 Dec 2006 16:43:00 +0100

Méthode bourrin, je ne sais pas si il en existe une meilleure. Disons qu'on veut annuler la révision 329 (et que c'est la dernière en date):

$ svn update
$ svn merge -r 329:328 .
$ svn commit -m "cancel 329"

En tout cas chez moi ça a marché.

ViewHelper de génération d'urls

Geoffrey — Fri, 24 Nov 2006 20:27:00 +0100

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:

[routes_fr_FR]
announceCreate.route = /annonce/creer
announceDetails.route = /annonce/:id/details

[routes_en_UK]
announceCreate.route = /announce/create
announceDetails.route = /announce/:id/details

[routes:route_fr_FR]
announceCreate.defaults.controller = announce
announceCreate.defaults.action = create

announceDetails.defaults.controller = announce
announceDetails.defaults.action = details

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.

Zend Framework: Un plugin simple pour le Front Controller

Geoffrey — Sun, 19 Nov 2006 21:30:00 +0100

L'implémentation du Front Controller du Zend Framework inclue un système bien pratique de plugins, qui va nous permettre de réaliser plus simplement et proprement l'automatisation des vues, initialement embarquée dans une extension de Zend_Controller_Action (ce qui pose quelques problèmes, nottament au lors de l'utilisation de __forward() et _redirect()).

Techniquement, un plugin est une classe qui implémente l'interface des plugins (Zend_Controller_Plugin_Interface). Dans la pratique, une classe abstraite est fournie pour simplifier la tache (Zend_Controller_Plugin_Abstract). Notre premier plugin s'appellera AutoView (My_Controller_Plugin_AutoView, stocké dans My/Controller/Plugin/AutoView.php).

Un plugin est donc une classe dont les méthodes seront appelées a différents moments de la dispatch loop du controlleur frontal, comme on peut le voir dans Zend_Controller_Front::dispatch():

routeStartup(), à la mise en route du routeur
routeShutdown($action), à l'arrêt du routeur
dispatchLoopStartup($action), avant la dispatch loop
preDispatch($action), avant d'executer une action
postDispatch($action), après avoir executé une action
dispatchLoopShutdown(), pour finir.

A chaud, on pourrait se dire que postDispatch est exactement ce dont on n'a besoin, et on se tromperait. Ce qu'il faut savoir, c'est que l'argument $action passé à postDispatch contient l'action qui suit celle qui vient d'être executé. Dans la majorité des cas, n'ayant qu'une seule action à executer, $action sera vide, et on se retrouve l'air un peu con.

Bon donc, on va user d'un stratagème: notre plugin va stocker les actions qui passent dans preDispatch, pour s'occuper de la dernière à être passée dans dispatchLoopShutdown. Dernier détail, notre plugin s'occupera lui même de gérer son instance de Zend_View. Et sans plus attendre, le code, qui n'a finalement rien de compliqué:

<?php

require_once 'Zend/Controller/Plugin/Abstract.php';

class My_Controller_Plugin_AutoView extends Zend_Controller_Plugin_Abstract {

	private $_lastAction;

	public function __construct() {
		$view = new Zend_View;
		$view->setScriptPath(APP_ROOT.'/views/');
		Zend::register('view', $view);
	}

	public function preDispatch($action) {
		$this->_lastAction = clone($action);
		return $action;
	}

	public function dispatchLoopShutdown() {
		if (!is_null($this->_lastAction)) {
			$viewPath = sprintf('%s/%s.php', $this->_lastAction->getControllerName(), $this->_lastAction->getActionName());
			echo Zend::registry('view')->render($viewPath);
		}
	}
}

?>

Bien, notre plugin vaillament codé, il nous faut désormais expliquer au controlleur frontal qu'on aimerai bien qu'il en tienne compte. Cela se passe fort logiquement dans le bootstrap, via la méthode registerPlugin du sus-cité controlleur frontal, qui prend en argument une instance d'un objet implémentant Zend_Controller_Plugin_Interface:

$controller = Zend_Controller_Front::getInstance();
$controller->registerPlugin(new My_Controller_Plugin_AutoView);

And viola !

Migrer un dépot subversion

Geoffrey — Thu, 09 Nov 2006 17:25:00 +0100

Imaginons que vous souhaitiez déplacer votre dépôt subversion myproject d'une machine old-server à une machine new-server. Vite fait, bien fait:

old-server# svnadmin dump /var/lib/subversion/myproject > ~/myproject.svndump
old-server# scp ~/myproject.svndump new-server:
new-server# svnadmin create /var/lib/subversion/myproject
new-server# svnadmin load /var/lib/subversion/myproject < ~/myproject.svndump

Attention, il vous faut par contre migrer vos éventuelles hooks à la main, ils ne sont effectivement pas gérés par svndump. Une autre méthode, incluant les hooks celle-ci, serait d'utiliser svnadmin hotcopy, mais je n'ai pas testé.

Plus d'infos:

Howto: Utiliser Zend_Controller_RewriteRouter avec Zend_Config

Geoffrey — Tue, 31 Oct 2006 20:26:00 +0100

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.

Mettre en place le routeur

C'est bien beau tout ça, mais pour l'utiliser, il faut déjà en informer le controlleur. Pour cela, rien de plus simple, on utilise la méthode addRouter:

$router = new Zend_Controller_RewriteRouter;
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

Le RewriteRouter est pré-configuré avec deux routes qui permettent d'assurer la compatibilité descendante avec l'ancien routeur, donc jusque là, tout va bien.

Déclarer les routes

Nous utiliserons un fichier de configuration dédié aux routes, que nous appellerons sobrement routes.ini, et que nous placerons dans app/, à coté de son compagnon config.ini. Ce fichier de configuration contiendra une unique section [routes], qui contiendra à son tour les multiples définitions de routes que nous souhaitons y caser. Une route se compose de 5 éléments principaux:

L'identifiant de la route. C'est un identifiant interne utilisé par le RewriteRouter,
l'URL de la route, c'est ce qui permet au routeur de reconnaitre la route à utiliser,
les valeurs par défauts des variables,
les requirements de la route, qui permettent de déterminer si une route est bien formée ou non.

Sans plus attendre, un petit exemple: la route qui pourrait permettre d'accéder à un billet dans dotclear 2:

post.route = post/:year/:month/:day/:title
post.reqs.year = "\d+"
post.reqs.month = "\d+"
post.reqs.day = "\d+"
post.reqs.title = "[a-zA-Z0-9_:-]"+
post.defaults.controller = post
post.defaults.action = view
post.defaults.title =

Elle pourrait seulement, car en fait, la regexp du title est trop restrictive (une URL peut contenir d'autres caractères que ceux là), et de plus, les URL stockées par dotclear 2 en base de données comprennent tout ce qui se trouve après post/ (par exemple le champs post_url de ce billet contient: 2006/10/31/Howto:-Utiliser-Zend_Controller_RewriteRouter-avec-Zend_Config).

Cela étant dit, la route que nous venons de décrire s'appliquera aux URLs suivantes:

/post/2006/30/10/ZendFramework
/post/42/2006/56/Foobar
/post/2006/30/10/
etc.

Mais pas à:

/post/2006/Foobar
/post/Foobar/2006/30/01
etc.

On note donc d'ores et déjà:

que la validation des composants d'une route se fait par expression régulière
qu'on peut ommettre le dernier composant d'une route si il possède une valeur par défaut (récursivement)
qu'on ne peut pas modifier l'ordre des composants d'une route
qu'on doit spécifier manuellement le nom du controlleur et de l'action à utiliser
et c'est déjà pas mal.

Décortiquons maintenant une URL: /post/2006/30/10/ZendFramework. Le routeur va diviser cette URL ainsi:

Controller: post (d'après les defaults)
Action: view (d'après les defaults)
Paramètres: year: 2006, month: 30, day: 10, title: ZendFramework (d'après l'URL)

Les paramètres ainsi détectés seront disponibles via la méthode $this->_getParam($name); a l'intérieur du controlleur.

Dernier point de ce chapitre, une déclaration de route peut comporter deux variables spéciales: :controller et :action, qui servent respectivement à détecter le controller et l'action à utiliser dans l'url. Par exemple, la route builtin compat chargé d'assurer la compatibilité descendante se déclare ainsi:

compat.route = :controller/:action
compat.defaults.controller = index
compat.defaults.action = index

Assembler le tout

Dernière étape, transférer directement toutes ces déclarations dans le Routeur: n'y allons pas par quatre chemin:

$router->addConfig(new Zend_Config_Ini('/path/to/routes.ini', null), 'routes');

C'est aussi simple que ça. Ce qui nous donne, en prenant en compte le morceau de code du début de l'article:

$router = new Zend_Controller_RewriteRouter;
$router->addConfig(new Zend_Config_Ini($routes_path, null), 'routes');
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

And voilà. Je ne saurais que vous conseiller la lecture du manuel pour plus d'informations (sachant qu'en fait, addRoute attend en deuxième argument une instance de Zend_Controller_Router_Route, mais qui s'instancie avec les paramètres qu'ils passent à addRoute, petite coquille du manuel :p).

Mettre en place un SSO avec Invision Power Board

Geoffrey — Wed, 25 Oct 2006 23:02:00 +0200

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.

Ensuite on met les mains dans le camboui. Dans le répertoire sources/loginauth/ de votre installation, il doit exister un repertoire external/, qui nous servira de base. On commence donc par le dupliquer:

cp -r external mon_sso

Puis on regarde un peu ce qu'il y a dedans:

mon_sso/
	auth.php
	conf.php
	index.html

Le fichier index.html n'est qu'un empécheur de tourner en rond pour les gens qui explorent un peu trop les arbos web. Le premier fichier qui nous interresse est conf.php, il contient les informations relatives à la base de données distantes. Là encore, c'est assez explicite et bien commenté. Le seul petit truc à savoir est que l'utilisateur qui se connectera à la base a besoin des droits SELECT sur toute la table, pas seulement sur les champs login / pass.

Dans le meilleur des cas, votre SSO est prêt :p Le fichier auth.php contient les méthodes appelées par le gestionnaire d'identification. Vous pouvez avoir besoin de modifier __compare_password, pour la vérification du mot de passe (j'ai par exemple changé la méthode de cryptage qui est md5 par défaut).

A ce stade, vos utilisateurs peuvent s'identifier, mais le forum leur demande quand même leur mail et quelques infos que j'ai oublié. Il est bien évidemment possible d'éviter ça :-) Dans la méthode authenticate, vers la fin, quand un utilisateur local est créé, la main est passée à la méthode create_local_member, qui redirige ensuite vers l'écran de complétion du compte. C'est là que nous intervenons. La méthode create_local_member n'est pas implémenté dans login_method, mais dans login_core, qui se trouve dans le fichier sources/loginauth/login_core.php, nous commençons par la copier/coller dans notre login_method, puis nous modifions sa déclaration pour lui permettre de recevoir $remote_member en paramètre:

function create_local_member( $remote_member )
{

Cette méthode permet de piocher dans les informations récupérées dans la base distante. Dans la partie Populate member table(s), par défaut, un faux mail est créé:

$email_tmp = $username.'@'.$timenow;

Qu'on peut remplacer par le mail qu'on a déjà potentiellement dans la base distante (disons que le champs s'appelle mail):

$email_tmp = $remote_member['mail'];

On peut ensuite récupérer les champs que l'on veut pour les ajouter au membre local, par exemple dans mon cas, le display_name (nickname chez moi):

$display_name = $remote_member['nickname'];

en les rajoutant dans le tableau $member.

Les deux derniers appels de méthode dans create_local_member, $this->ipsclass->DB->do_insert et $this->ipsclass->print->redirect_screen sont à commenter, et on rajouter avant le bout de code suivant:

$this->return_code = 'SUCCESS';
return;

Retour dans authenticate, dans la partie Got no member - but auth passed - create?, on modifie la première partie du if ainsi:

if ( $this->allow_create )
{
	$this->create_local_member( $remote_member );
	$this->_load_member($username);

	if ( $this->member['id'] )
	{
		$this->return_code = 'SUCCESS';
	}
	else
	{
		$this->return_code = 'NO_USER';
	}
	return;
}

And voilà, nos utilisateurs peuvent désormais s'identifier sans avoir a re-entrer des informations que l'on possède déjà :-)

Relayer un stream audio avec icecast2

Geoffrey — Fri, 20 Oct 2006 22:05:00 +0200

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 :-)

Vous prendrez bien un peu de ssh avec votre tunnel ?

Geoffrey — Fri, 20 Oct 2006 20:06:00 +0200

Il arrive des fois où on aimerait pouvoir relier directment deux machines appartenant a deux réseaux distincts. C'est par exemple mon cas quand j'ai besoin (envie on va dire) d'accéder à ma machine du boulot depuis une machine non connectée au VPN. Dans ce genre de cas, il existe en général une machine qui possède des interfaces susceptibles d'accéder à chacune des machines (le concentrateur VPN par exemple). Nous appellerons cette machine relay, car elle servira de relai au tunnel. Pour éviter les sempiternelles appellations A et B qui embrouillent plus qu'autre chose, les machines s'appelleront startpoint pour la machine sur laquelle on a la main et endpoint pour la machine à laquelle on souhaite accéder.

Postulats de base:

relay possède un serveur SSH qui tourne
startpoint possède un client SSH capable de créer un tunnel (ssh, par exemple)
relay est accessible depuis startpoint et peut se connecter à endpoint

Bien, allons y franchement, la commande, à executer depuis startpoint, permettant de créer un tunnel SSH entre startpoint et endpoint est la suivante:

ssh -L 2222:endpoint:22 relay

Qu'avons nous fait là ? L'option -L de SSH sert à binder un port de la machine locale (startpoint donc), à un autre port (ou le même) de la machine distante (endpoint). Ici, on associe le port local 2222 (22 étant déjà pris par mon serveur SSH, mais on pourrait utiliser le port 22 si aucun serveur ne tournait, à la différence près qu'il faudrait lancer la commande en root pour pouvoir binder un port inférieur à 1024 (c'est comme ça)) au port 22 de endpoint, c'est à dire le serveur SSH. Il nous est dès lors possible d'ouvrir une connection SSH sur endpoint en se connectant au port 2222 de notre machine locale:

ssh -p 2222 localhost

Magique non ? Bien sur, il est possible de forwarder n'importe quel port au travers du tunnel:

ssh -L 8080:endpoint:80 relay

Faire pointer votre navigateur sur http://localhost:8080/ vous ammenera sur le serveur web de endpoint.

Mais un tunnel ne se limite pas à joindre deux machines d'un réseau différents. On peut également imaginer un tunnel entre deux machines dans l'unique but de sécuriser une transmission, par exemple, des échanges de mails. Imaginons que votre serveur mail preferré, pop.example.com, ne propose pas de connection POP sécurisée. Vous pouvez remédier à ce manque flagrant de confidentialité en créant un tunnel SSH:

ssh -L 1100:localhost:110 pop.example.com

Bien sur, ce cas de figure nécessite d'avoir un compte permettant une connexion SSH sur pop.example.com, ce qui n'est pas forcément le cas. Pour remédier a ceci, deux solutions: utiliser un relay qui possède un serveur SSH, ou installer un serveur SSH sur startpoint pour s'en servir comme relai (sudo apt-get install openssh-server sur toute distribution debian-like qui se respecte):

ssh -L 1100:pop.example.com:110 localhost

And voila, il n'y a plus qu'a indiquer à notre client mail que le pop se situe sur localhost au port 1100, et le tour est joué :-)

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 !

L'environnement d'execution

Geoffrey — Thu, 12 Oct 2006 21:51:00 +0200

Voilà un article que j'avais déjà proposé sur un site a caractère privé, un peu remis au gout du jour et étoffé de quelques informations et ressources non négligeables. Nous verrons ici comment mettre en place un environement d'execution standard du Zend Framework, également appelé bootstrap de l'autre coté de l'atlantique.

Un petit dessin valant mieux qu'un long discours, entrons dans le vif du sujet. On assume ici un environnement préinstallé: Apache / PHP5 / MySQL, avec une copie du Zend Framework dans /usr/share/zend/, ainsi que le .htaccess suivant à la racine de votre site (il semblerait que cette dépendance à mod_rewrite soit sur la liste des choses à éliminer avant la release):

RewriteEnfine On
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

On peut également utiliser les règles suivantes, qui comportent l'avantage d'une plus grande simplicité pour intégrer des éléments d'application externe:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php

L'environnement

Les plus perspicaces d'entre vous l'auront surement déjà deviné, le fichier www/index.php servira de bootstrap, c'est à dire de point d'entrée unique pour toute l'application. Le Zend Framework se chargera lui même de décortiquer l'URL pour tenter de deviner ce à quoi l'utilisateur pouvait bien penser quand il a cliqué !

Pour ce qui est de l'arborescence de fichiers conseillée, un peu d'organisation est recommandée.

Pour utiliser le Zend Framework en toute quiétude, il nous faut nous assurer qu'il pourra accéder à ses propres composants. La première chose à faire est donc de modifier l'include_path:

set_include_path(get_include_path().PATH_SEPARATOR.realpath(dirname(__FILE__).'/../library/'));

Il n'est pas inutile également de prendre quelques précautions d'usage:

ini_set('error_reporting', E_ALL); # | E_STRICT);

if (get_magic_quotes_gpc()) {
	die('<strong>E_NOOB_ERROR</strong>: magic_quotes_gpc must be turned off.');
}

set_magic_quotes_runtime(false);

Last but not least, on charge la librairie Zend:

require_once 'Zend.php';

Ainsi préparés, nous pouvons nous plonger en toute quiétude dans la mise en place de quelques objets qui nous serons bien utiles tout au long du développement de notre application.

Les objets

La mise en place des objets est on ne peut plus claire. On configure le front controller (Zend_Controller_Front) pour lui dire où trouver les controllers, puis on configure les vues (Zend_View) pour leur dire où trouver... les vues :-) On enregistre ensuite l'objet $view dans le registre, qui n'est rien de plus qu'un endroit pratique où stocker des objets/données pour y avoir accès plus tard (Zend::register($name, $value) et $var = Zend::registry($name);).

Une petite liste (non exhaustive) d'objets interressants à stocker dans le registre:

Zend_Db

Zend::loadClass('Zend_Db');
Zend::loadClass('Zend_Db_Table');

$params = array(
	'host' => 'localhost',
	'username' => 'someobscureusername',
	'password' => 'someobscurepassword',
	'dbname' => 'yourdbname'
);

$db = Zend_Db::factory('PDO_MYSQL',$params);
Zend_Db_Table::setDefaultAdapter($db);

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

Zend_Config

Je vous renvois à mon article sur la gestion de la configuration :-)

Zend_View

Zend::loadClass('Zend_View');

$view = new Zend_View;
$view->setScriptPath(realpath(dirname(__FILE__).'/../app/views/'));

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

Le Dispatch

Dernière étape, le dispatch, qui utilise les objets Zend_Controller_Router et Zend_Controller_Dispatcher. Ces deux objets sont au coeur du processus de sélection du controller à executer. Le Router va déterminer, à partir de l'environnement (en général l'URL, via $_SERVER['REQUEST_URI'] par exemple) quelle action executer et dans quel controller, tandis que le Dispatcher va s'occuper lui de les trouver (par exemple dire FooController::bar(), dans controllers/FooController.php).

Le Zend Framework gère en natif les friendly urls, et ça c'est chouette. Par exemple: les urls suivantes:

http://example.com/foo/bar
http://example.com/foo
http://example.com/

Seront analysées comme suit par le Routeur par défaut:

controller: foo, action: bar
controller: foo, action: index
controller: index, action: index

Dernières choses à savoir sur la théorie:

quand le controlleur est défini par l'url mais non trouvé par le Dispatcher, celui ci execute index/noRoute.
les controllers sont des classes qui étendent Zend_Controller_Action (ou une classe qui elle même l'étend)
le Dispatcher par défaut va executer(en supposant une url type http://example.org/foo/bar) FooController::barAction dans FooController.php (modulo le path déterminé avec Zend_Controller_Front::setControllerPath)

Les vues

Dernier point de cette brève excursion dans le Zend Framework, les vues. Pas grand chose à en dire pour le moment, si ce n'est que par défaut l'objet Zend_View se contente d'include() les fichiers templates. Il parait que l'intégration avec des moteurs de template (Smarty par exemple) est très aisée, mais comme je ne suis pas fan de ce genre de choses, ce ne sera pas couvert ici :-)

Ma première impression sur XGL

Geoffrey — Tue, 03 Oct 2006 17:08:00 +0200

Bon voilà, je viens de suivre ce howto, et ça marche très bien. Passé le stade mais où sont mes efferalgans ?, on arrive rapidement au stade mais où mon smecta ?, tellement c'est gerbant de fluidité. Bref, le desktop mappé sur un cube, c'est sympa, mais on lui preferrera de loin les effets moins psychédéliques tels que la vraie transparence et les animations des fenetres (et encore).

Empecher la sauvegarde d'un mot de passe

Geoffrey — Sun, 24 Sep 2006 22:22:00 +0200

Le titre n'est pas très explicite, malheureusement, j'ai du mal a réfléchir ce soir. Nous parlons ici de la sauvegarde d'un mot de passe par Firefox quand on valide un formulaire contenant un champs password. Je ne connais pas exactement les règles qui régissent ce comportement, mais quand on à un formulaire d'enregistrement, en général, cette fonctionnalitée est plus une gène qu'autre chose. Pour la désactiver, il suffit donc d'affecter un attribut autocomplete de valeur off à votre champs:

<input type="password" name="password" id="password" autocomplete="off" />

Je sais, ça fait beaucoup de password.

Automatisation des vues

Geoffrey — Wed, 30 Aug 2006 13:17:00 +0200

Le rebutement principal que j'ai eu au début avec le Zend Framework était l'impossibilité (a priori) d'automatiser le rendu des vues en fonction du controlleur et de l'action appelés. Mes pérénigrations webesques m'ont finalement fait entrevoir la solution.

EDIT: mes nouvelles pérégrinations dans les sources du Zend Framework m'ont fait entrevoir une meilleure solution :-)

Tout se passe dans le destructeur du controlleur, et nous allons voir ici une version édulcorée de celle disponible dans le lien sus-cité. L'astuce qui sauve, c'est de savoir que l'objet Controller possède un membre _action, qui lui même propose (entre autres) deux méthodes bien utiles: getControllerName et getActionName. Il suffit donc de récupérer ces informations pour construire dynamiquement le chemin de la vue à utiliser pour un controlleur donné:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __destruct() {
		$view = Zend::registry('view');
		$controller = $this->_action->getControllerName();
		$action = $this->_action->getActionName();
		$viewPath = sprintf('%s/%s.php', $controller, $action);
		try {
			echo $view->render($viewPath);
		} catch (Exception $e) {
			trigger_error('Unable to render view: ' . $e->getMessage(), E_USER_ERROR);
		}
	}
}

Fichier source

Ce controlleur requiert que vous ayez instancié, configuré et enregistré Zend_View au préalable. Il ira, lors de sa destruction, chercher la vue dont le nom correspond à controller/action.php, c'est à dire:

pour une URL du type http://example.com/foo/bar/, foo/bar.php,
pour http://example.com/, index/index.php,
pour http://example.com/foo/, foo/index.php.

Pour une raison obscure, on ne peut pas laisser trainer l'éventuelle exception générée par Zend_View dans le cas d'une vue inexistante. Cela entre en conflit avec une autre Exception qui traine, j'essayerai de tirer ça au clair :-)

Zend Framework et les sessions

Geoffrey — Sat, 12 Aug 2006 20:31:00 +0200

Bon voilà, j'ai commencé le développement d'un projet, et j'ai décidé d'utiliser le Zend Framework (pour des raisons que je détaillerais dans un autre billet si ça vous interresse). Après mise en application du tutoriel de Chris, Un premier problème s'est posé à moi: l'intégration des sessions. Après quelques recherches, on peut trouver un blog développé avec ZF. Me ruant sur la partie d'admin, je découvre a ma grande stupeur des session_start() incrustés a chaque méthode du controlleur, un peu comme ça:

class AdminController extends Zend_Controller_Action {
	function indexAction() {
		session_start();
	}
	function postAction() {
		session_start();
	}
}

Ce n'est évidemment pas une solution acceptable. J'ai opté pour ma part pour une surcharge de la classe Zend_Controller_Action, avec un appel à session_start() dans le constructeur:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __construct() {
		session_start();
	}
}

class AdminController extends My_Controller_Action {
	function indexAction() {
		// code
	}
}

Bon là, la problèmatique de base est déjà résolue, mais on peut aller plus loin, et ajouter un destructeur:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __construct() {
		session_start();
	}

	public function __destruct() {
		$session_id = session_id();
		if (!empty($session_id)) {
			session_write_close();
		}
	}
}

Voilà c'est tout pour aujourd'hui, la prochaine fois, on parlera de l'utilisation des Views, et nottament, comment éviter un appel rébarbatif à Zend::registry() dans chaque controlleur.

Faire du CLI en PHP

Geoffrey — Sat, 05 Mar 2005 13:02:47 +0000

Souvent les gens ne voient PHP que comme un langage de script orienté web. Même si il est vrai que c'est son but premier, ce n'est pas la seule chose que PHP peut faire. Penchons nous un peu sur l'utilisation de PHP en CLI, qui permet d'utiliser PHP comme un langage de script classique. Nous utiliserons pour se faire un système linux (ubuntu pour être précis) avec un binaire php-cli déjà installé.

Au commencement...

Au commencement est le shebang. Qu'est-ce que c'est donc que ça ? C'est simplement la première ligne d'un script shell, celle qui indique au shell quel interpréteur utiliser pour executer le script. Elle début obligatoirement par les caractères #! (qu'on appelle shebang), suivis du chemin absolu de l'interpréteur. Dans la plupart des cas, l'intérpréteur PHP se situe dans /usr/bin et s'appelle php, tout simplement. Ce qui nous donne donc:

#!/usr/bin/php

Bien sur, il est possible que votre interpréteur se situe ailleurs, /usr/local/bin/php par exemple. Pour le trouve, vous pouvez utiliser la commande which:

ash@sushi:~$ which php
/usr/bin/php

Si cette commande ne retourne rien, c'est que php-cli n'est pas installé, et là ça dépasse le cadre de cet article :)

Un petit détour par la doc

A ce stade, il est bon d'aller voir ce que la doc a a nous dire sur l'utilisation de PHP en ligne de commande. On y apprend toutes sortes de choses, a commencer par la compilation de PHP en CLI. On y apprend également que certaines valeurs du php.ini sont différentes de celles de PHP utilisé avec un server web, et nottement:

html_errors, pour ne pas afficher de HTML dans les erreurs
max_execution_time, pour autoriser un temps d'execution infini
register_argc_argv, pour peupler les variables $argc et $argv, sur lesquelles nous reviendrons plus tard

On y apprend aussi que php-cli enregistre automatiquement de nouvelles constantes telles que:

STDIN
STDOUT
STDERR

Qui représentent respectivement l'entrée standard, la sortie standard, et la sortie d'erreur standard. Nous reviendronts sur ces constantes et leur utilisation plus tard.

La dernière chose que nous retiendrons de cette page est que php-cli ne modifie pas le repertoire courant a l'execution d'un script. C'est à dire que si vous vous trouvez dans le répertoire /tmp, et que vous executez php /home/ash/foo.php, la fonction getcwd (GET Current Working Directory) retournera /tmp, et pas /home/ash.

Notre premier script en CLI

Il est grand temps d'entrer dans le vif du sujet et de faire notre premier script. Soyons originaux, créons un hello_world.php, avec le code suivant:

#!/usr/bin/php
<?php print "hello world !"; ?>

Une fois le fichier créé, nous avons deux possibilités pour l'executer. Soit lancer directement l'interpréteur PHP en lui précisant le script a executer:

$ /usr/bin/php ./hello_world.php

Soit rendre le script executable et l'executer directement:

$ chmod +x ./hello_world.php
$ ./hello_world.php

Dans tous les cas, le résultat est le même:

hello world !

Facile non ? Notez bien que si vous décidez de rendre le script executable, vous n'aurez a executer la commande chmod qu'une seule fois.

Vous remarquerez surement que votre prompt s'affiche directement après le !, c'est normal, nous n'avons pas inclus de caractère de nouvelle ligne () dans notre print. Vous pouvez donc modifier le script ainsi:

#!/usr/bin/php
<?php print "hello world !
"; ?>

Et le tour est joué.

Utilisation de $argc et $argv

Tout ça c'est bien beau, mais un script c'est quand même mieux quand on peut lui passer des arguments. Et non, executer ./hello_world.php?arg=value ne fonctionne pas :-) Comment faire alors ? Les variables $argc et $argv sont là pour ça.

Pour passer des paramètres à un shell script, on utilise usuellement la syntaxe suivante:

$ ./script [arg [arg...]]

C'est comme cela que nous procéderons en PHP-CLI. La variable $argc (ARGuments Count) contient le nombre de paramètres passés au script, tandis que la variable $argv (ARGuments Values) est un array contient les valeurs de ces arguments. Modifions donc notre script de tout à l'heure:

#!/usr/bin/php
<?php
var_dump($argc);
print_r($argv);
?>

Et executons le en lui passant quelques paramètres:

$ ./hello_world.php foo bar

Voyons le résultat:

ash@sushi:~$ ./hello_world.php foo bar
int(3)
Array
(
    [0] => ./hello_world.php
    [1] => foo
    [2] => bar
)

On remarque que le nom du script compte comme un argument.

Utilisation de STDIN

Ces constantes dont nous avons parlé plus tôt sont très importantes. Elles définissent les flux standards à votre disposition, mais nous ne nous interresserons qu'a STDIN dans cet article.

STDIN (STanDard INput) est l'entrée standard. C'est elle que vous devez utiliser que vous voulez interragir avec l'utilisateur. Par exemple pour lui faire entrer des données. Modifions encore une fois notre hello_world.php:

#!/usr/bin/php
<?php
$name = trim(fgets(STDIN));
print "hello $name !
";
?>

Et executons le:

ash@sushi:~$ ./hello_world.php 
geoffrey
hello geoffrey !

Le script a donc attendu que je tape quelque chose en terminant par un CRLF (Cariage Return Line Feed, la touche Entrée quoi ;). J'ai donc tapé geoffrey, et voilà. Notons l'utilisation de trim pour supprimer le CRLF en question.

Le mot de la fin

Voilà, avec ça, vous devriez avoir les bases nécessaire pour commencer a faire du PHP-CLI. Cela dit, cet article n'explore pas toutes les subtilités du CLI, et une bonne lecture de documentation est fortement conseillée :)