Digital Fashion - organisation

Le firebug nouveau est arrivé

Geoffrey — Tue, 05 Dec 2006 11:05:00 +0100

Firebug 1.0b1 est sorti. Et il est bien (tm).

Linux + gVim + Rox-filer = Mon IDE.

Geoffrey — Tue, 28 Nov 2006 22:39:00 +0100

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

Comment définir un IDE ?

Commençons par le début: qu'est-ce qu'un IDE ? Acronyme de Integrated Development Environment, le terme peut prendre pas mal de signification selon la personne à laquelle on s'adresse. Pour certains, le plus c'est le mieux, alors que pour d'autre, le moins c'est le pas plus mal finalement. On pourra citer quelques exemples connus d'IDE full-featured, tels que les incournables Zend Studio, Eclipse et autres phpEdit, mais ce n'est pas le but de cet article. Ici, je vais vous expliquer pourquoi et comment j'utilise quotidiennement gVim et Rox-filer, et le tout sous Ubuntu.

Revenons en à nos moutons, un environnement de développement, c'est constitué de quelques briques primordiales:

Un éditeur de code
Un navigateur de fichier
Un truc qui fait tourner tout ça

Peu importe qu'ils soient intégrés ou non, finalement. Personnellement, je suis un fervent adepte du précepte une tâche, un outil, donc je preferre qu'ils soient dissociés.

L'éditeur de code: gVim

Certains perdent leurs moyens à la simple évocation de son nom, vim n'est pourtant rien de plus que le plus puissant des éditeurs de fichier aujourd'hui disponible dans le monde (un troll s'est malicieusement glissé dans cette affirmation, saurez-vous le retrouver ?). Ce qui déroute au premier abord dans vim, c'est finalement ce qui fait toute sa puissance: le mode commande. J'ai longtemps utilisé bluefish, et finalement las de ses quelques bugs bien énervants (wtf syntax color ?), j'ai décidé de faire le grand pas, et d'utiliser vim. J'avais bien sur déjà une expérience de cet éditeur, mais retenez bien que le meilleur moyen de maitriser un outil aussi puissant que vim, ce n'est pas de se jeter à corps perdu dans la doc, mais c'est d'investir du temps incrémentiellement: commencer à utiliser vim, et quand on souhaite faire quelque chose qu'on ne sait pas faire, lire la doc correspondante^[1]. Pour finir, j'ai traduit il y a quelque temps un excellent tutoriel sur vim: L'édition efficace avec vim, donc n'hésitez pas.

Un .vimrc qu'il est joli

Comme la plupart des applications *nix, vim autorise l'utilisation d'un fichier ~/.vimrc. S'il peut paraitre compliqué au premier abord d'élaborer un .vimrc efficace, il ne faut pas se décourager, car comme d'habitude, il y a tout ce qu'il faut sur le net. J'en veux pour preuve les excellents articles de Tobias Schlitt à ce sujet.

Pour info, quelques directives de configuration utiles qu'on peut trouver dans mon .vimrc:

" Supprime un buffer de la mémoire via le raccourci clavier Ctrl+W
noremap <C-W> :bdel!<CR>

" Active l'indentation automatique
set autoindent

" Active les plugins de type de fichier
filetype plugin on

" Active la coloration syntaxique
syntax on

" Thème de couleur pour gVim
colorscheme desert

" Utiliser des tabs de 4 caractères pour l'indentation
set noexpandtab tabstop=4 shiftwidth=4

" Activer la souris (molette, sélection, etc)
set mouse=a

" Afficher des infos dans la barre de status
set ruler
set laststatus=2

" Activer la numérotation des lignes
set number

" Utiliser la recherche incrémentielle
set incsearch

" Ne pas surligner les résultats de recherche
set nohlsearch

Quelques unes (beaucoup en fait) de ces directives sont tirées du .vimrc de Tobias.

Dernier détail pour les réfractaires de la ligne de commande, gVim s'execute en mode graphique, avec une interface GTK conviviale qui permet d'apprendre les raccourcis aisément, et qui gère la souris (défilement à la molette, etc, et d'ailleurs, même en console ça gère la souris, il suffit d'un :set mouse="a" pour l'activer).

Un ftplugin pour le PHP

Ce qu'on appelle ftplugin dans vim permet de configurer vim en fonction du type de fichier que l'on édite. Tobias fournit un ftplugin spécialisé dans l'édition du PHP plutôt bien foutu, qui gère la plupart des features convi-enabled des soit disants IDE évolués:

Complétion des fonctions
Complétion des mots-clés
Auto-fermeture des crochets, parenthèses, etc.
Auto-génération des docblocks PHPDoc
Vérification de syntaxe du fichier édité
Et d'autres trucs merveilleux !

La classe non ?

Un navigateur de fichier kirox (tm)

C'est pas moi qui le dit, en fait c'est comme le port-salut, rox-filer rox, c'est tout. Pour ceux que ma puissance de persuasion ne suffit pas, et bien rox-filer offre tout ce que vous pourriez attendre d'un gestionnaire de fichier moderne:

Navigation spatiale avec technologie oupas (tm)
Prévisualisation des images
Personnalisation (aisée !) des applications utilisées pour lancer les fichiers (en fonction du mimetype)
Navigation one-click (oupas (tm))
Navigation aisée au clavier
Monitorage des fichiers en cours d'utilisation (ils apparaissent en gras, ce qui est pratique).
Et j'en passe et des meilleurs.

Bref, il fait tout ce que ferait un filebrowser intégré, mais en mieux, puisqu'il est dédié dès le début à cette tache. Afin de le faire interragir au mieux avec gVim, j'utilise la Run action suivante sur le mimetype text/*:

gvim --servername ash0 --remote-silent-tab "$@"

Qui permet d'ouvrir le fichier dans un nouveau tab de vim, en créant une instance d'un server vim à la volée si il n'existe pas déjà (ici le server s'appelle ash0, mais vous pouvez bien évidemment en changer le nom).

Une distribution du bien: Ubuntu

Et parcequ'il faut bien faire tourner tout ça, j'utilise un système d'exploitation du bien (tm): GNU/Linux. Mais comme j'ai la flemme, j'utilise une configuration convi-enabled: Ubuntu. Pas besoin de s'étaler je pense, Ubuntu c'est bien, tout le monde en conviendra.

Un window-manager léger et puissant: fluxbox

Le choix du gestionnaire de fenêtre peut par contre préter a controverse. En effet, c'est ici avant tout une question de gout et de puissance de machine. J'ai personellement un penchant pour les logiciels puissants et légers. Là je vous vois venir avec vos gros sabots: tout le monde veut ce genre de logiciel. Et bien j'ai envie de répondre que non. La majorité des neo-geeks de la génération Ubuntu s'en donnent à coeur joie sous Gnome et/ou KDE, qui est loin de ce qu'il convient d'appeler un logiciel puissant et léger, sous prétexte que les autres WM (à part KDE), saitrocomplicai. Bon là ok, j'amalgame surement un peu (beaucoup même, tous les gens sous Gnome ne sont pas des neo-geek, et l'inverse également), mais il manquait un peu de trollitude dans cet article. Bref, quand on veut, on peut, et comme les gens ne switchent pas de Gnome à un WM plus puissant et plus léger, j'en conclus (peut-être à tord hein) qu'ils ne veulent pas.

Tout ça pour dire que j'utilise fluxbox, et ce depuis ma plus tendre enfance. Fluxbox est léger (osez prétendre le contraire...) et puissant: il permet:

de reconfigurer l'intégralité du comportement de vos fenêtres
une gestion fine et puissante des raccourcis claviers (j'ai pu reconfigurer les touches convi de mon clavier convi en quelques minutes dans mon .fluxbox/keys grâce à xev).
de controler facilement quelles applications se lancent au démarrage
de controler encore plus facilement sur quels bureaux se lancent les sus-citées applications

Par exemple, mon .fluxbox/startup démarre sur le premier bureau quelques terminaux, un gaim et un exaile; sur le deuxième bureau un firefox sur le troisième bureau: sylphee, et sur le quatrième bureau, un rox-filer. A coté de ça, je dispose de raccourcis claviers conviviaux pour lancer mes logiciels favoris: le terminal (Mod4^[2]+e), rox-filer (Mod4+r), etc. J'ai également à ma disposition des raccourcis claviers pour gérer mes fenêtres: maximiser (horizontalement (Ctrl+Alt+H), verticalement -Ctrl+Alt+V), ou les deux (Ctrl+Alt+M)), enrouler (Mod4+S), sticker (Ctrl+Alt+S), enlever les décorations (Ctrl+Alt+T), et j'en passe.

Enfin, et le plus important pour moi, fluxbox est non-intrusif. Par défaut, un bureau standard de mon fluxbox ne contient rien. Pas de barre des taches, pas d'icones, pas de menu, rien. Question de gout je vous l'accorde, mais là encore, notez que "c'est faisable": fluxbox ne vous impose rien, et surtout pas les choix discutables car subjectifs des développeurs.

Subversion en ligne de commande

Enfin, j'utilise le client subversion en ligne de commande. D'une part parceque je ne connais pas de client digne de ce nom en GTK (ma religion m'interdit d'utiliser Qt), d'autre part pour profiter pleinement de la puissance qu'offre un shell quand on sait un minimum s'en servir. Pouvoir passer mes commandes svn dans des awk, sed, et autres grep (surtout grep en fait), ça n'a pas de prix, et je pense vraiment qu'aucune interface graphique n'arrivera jamais à la cheville de la puissance d'un shell.

Deuxième avantage à utiliser svn en ligne de commande: le jour où je serais obligé de le faire, je saurais le faire.

Conclusion

Voilà, vous savez (presque) tout de mes habitudes de travail (il reste pas mal de domaines à couvrir quand même, je n'ai pas parlé par exemple de mes extensions firefox favorites, ni de mon utilisation intensive de trac, et encore moins des tests unitaires, peut-être une prochaine fois), et j'espère vous avoir donné l'envie de regarder d'un peu plus près ces outils à la réputation peut-être un peu geek, mais d'une puissance incomparable une fois maitrisés :-)

Notes

[1] :help commande est en général d'une grande utilité

[2] Le petit nom de la touche Windows

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:

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.

Discussion sur l'optimisation en PHP chez NiKo

Geoffrey — Thu, 23 Nov 2006 13:40:00 +0100

Une petite discussion sur l'optimisation en PHP à lieu en ce moment chez NiKo ! Ce n'est pas souvent que je link directement comme ça, donc dites vous que quand je le fais, c'est que ça en vaut la peine ;-)

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 !

A propos du blog Zend et du planet

Geoffrey — Mon, 06 Nov 2006 14:28:00 +0100

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.

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.

Bonnes pratiques PHP

Geoffrey — Sun, 29 Oct 2006 16:22:00 +0100

Vite fait, un petit jeu pour vous, amis PHPiens.

Dans le snippet de code qui suit se cachent 6 bonnes pratiques (7 selon le degré de subjectivité que l'on inclue dans une bonne pratique), saurez vous les retrouver ?

<?php

$code_is_ugly = true;
if (9069 === $code_author) {
	$code_is_ugly = false;
}

?>

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

Débuter un projet: un brin d'organisation

Geoffrey — Sat, 16 Sep 2006 13:05:00 +0200

Architecture des dossiers

Commençons par le commencement: le stockage des fichiers. Pour ne pas trébucher sur la longue route que représente l'accomplissement d'un projet, il convient de bien s'organiser dès le début, et savoir précisément où stocker et trouver les choses est une bonne chose. Nous allons donc nous baser sur les recommandations de Zend à ce sujet:

monprojet/
     app/
          controllers/
          models/
          views/
     library/
     www/

A partir de là, on peut faire évoluer un peu. J'ai personellement rajouté un répertoire dist/, qui contient les scripts nécessaire à la distribution de mon application (dump des bases SQL par exemple), et cet article de Rob parle de répertoires comme scripts/ (pour contenir les scripts cron par exemple) et tmp/ (à toutes fins utiles).

Enfin, notons l'utilité d'un répertoire library/ext/ ou assimilé, comme expliqué ici.

Définir ses controlleurs et ses vues

Première question a se poser: qu'est-ce qu'un controlleur ? Un controlleur, c'est tout simplement une entité qui va s'occuper de traiter une requête que reçoit l'application. Dans le Zend Framework, les controlleurs possèdent des Actions (sous formes de méthodes), qui permettent d'avoir des URL telles que:

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

Dans un tel cas de figure, Zend Framework ira chercher la méthode barAction du controlleur fooController. On voit dès l'ors l'interet de bien définir nos besoins en termes de controlleurs dès maintenant, puisque c'est cela qui définira toute l'architecture de l'application. La marche à suivre est la suivante:

Lister toutes les fonctionnalitées de l'application
Les regrouper logiquement
Traduire tout ça en termes de controlleurs et d'action

Prenons l'exemple typique d'un portail d'actualité. Voici quelques unes des actions que nous serons susceptibles de proposer:

Ajouter une news
Lister des news (action par défaut)
Voir les détails d'une news
Ajouter un commentaire

Ce qui se traduit par:

controlleur News
- action Ajouter (url: news/ajouter/)
- action Lister (url: news/lister/)
- action Voir (url: news/voir/id/$id)
controlleur Commentaires
- action Ajouter (url: commentaires/ajouter/news/$id)

Cela nous permet donc de prévoir l'arborescence suivante:

app/
        controllers/
                CommentairesController.php
                IndexController.php
                NewsController.php
        views/
                Commentaires/
                        ajouter.php
                Index/
                        index.php
                News/
                        ajouter.php
                        lister.php
                        voir.php

Voilà pour la théorie, pour la pratique, il faut mettre en place un environnement d'execution dans lequel on pourra déployer toutes la puissance du Zend Framework, c'est ce que nous verrons la prochaine fois :-)

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.