Digital Fashion

Bon voilà, ce n'est un secret pour personne, j'ai mis à jour ma Dapper en Edgy, et après avoir laborieusement activé l'accélération 3D de ma carte graphique, je me suis attelé à la reconstitution de mon environnement de développement favori: LAMP5. Cet enrivonnement comprend de plus l'extension PDO Mysql, très utile dans le cadre de l'utilisation du Zend Framework :-) Seulement voilà, Edgy propose un paquet php5 plus à jour que celui de dotdeb, ce qui empêche l'installation du paquet php5-pdo-mysql de dotdeb. Ayant mieux à faire qu'installer pdo_mysql via pear, j'ai décidé d'apprendre à me servir un peu d'APT, et je me propose de vous faire part de mes conclusions. Commençons par le commencement, le message d'erreur:

Les paquets suivants contiennent des dépendances non satisfaites :
  php5-pdo-mysql: Dépend: phpapi-20041225
                  Dépend: php5-common (= 5.1.6-0.dotdeb.2) mais 5.1.6-1ubuntu1 devra être installé
E: Paquets défectueux

Il suffit donc de spécifier à APT que nous souhaitons utiliser la version 5.1.6-0.dotdeb.2 du paquet php5-common. Rien de plus simple ! Cela se passe dans /etc/apt/preferences:

Package: php5-common
Pin: version 5.1.6-0.dotdeb.2
Pin-Priority: 1001

Et comme libapache2-mod-php5 dépend également de php5-common, il va nous falloir faire de même:

Package: libapache2-mod-php5
Pin: version 5.1.6-0.dotdeb.2
Pin-Priority: 1001

Voilà, désormais APT n'installera que la version 5.1.6-0.dotdeb.2 de ces deux paquets, quoiqu'il arrive. Un simple apt-get install php5-pdo-mysql suffit désormais pour que tout rentre dans l'ordre !

A noter: le tutoriel qui m'a tout appris.

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

Bon voilà, n'écoutant que ma fébrile excitation, j'ai refais a neuf mon laptop hier avec une Dapper Drake flambant neuve (oui moi aussi je commande des CDs sur shipit), et je me suis empressé d'y installer un environnement de développement digne de ce nom (bon tout dépend des religions hein, chez moi ça veut dire LAMP5 + Zend Framework). J'ai déjà commencé à reproduire le tutoriel de Chris Shifflet pour me remettre dans le bain (pas bien compliqué vu comme c'est génial ce framework).

Je me lance donc dans un projet qui devrait comporter des technologies bien web 2.0, comme google maps, youtube et script.aculo.us. Pas la peine d'en demander plus je ne dirais rien (et au pire je ferme les commentaires).

C'est un projet qui n'ira peut être pas très loin, ou bien peut être que si, mais c'est avant tout un projet pour apprendre de nouvelles choses.

...mais c'est quand même légèrement too much. Quand on cherche juste un package pour installer une plate-forme AMP rapidement, je déconseille XAMPP. Maintenant si vous voulez un AMP plus un ftpd, plus un serveur de mail, avec des stats, etc, alors oui, pourquoi pas.

Tout a l'heure je me suis dis que j'aurai bien voulu faire un include en fonction du SAPI dans lequel un script s'execute. Comme PHP est (presque) bien fait, il existe la fonction php_sapi_name qui retourne le nom du SAPI courant. Ce qui nous permet de faire quelque chose comme:

$sapi_include = dirname(__FILE__) . '/sapi/'.php_sapi_name().'.php';
$sapi_default = dirname(__FILE__) . '/sapi/default.php';
 
if (file_exists($sapi_include)) {
	require_once $sapi_include;
} else if (file_exists($sapi_default)) {
	require_once $sapi_default;
}

C'est pas très joli, mais ça fonctionne. Le gros avantage, c'est qu'on a des includes spécifiques au SAPI, et donc on aura par exemple, dans sapi/apache2handler.php:

header('Content-Type: text/html; charset=ISO-8859-15');
require_once 'libraries/Template.php';
session_start();

et dans sapi/cli.php:

Var_Dump::displayInit(array('display_mode' => 'text'));

Le problème, résolu par l'utilisation de sapi/default.php, était que faire un fichier par SAPI possible serait fastidieux (il faut connaitre le nom de tous les SAPI disponibles (bon ok c'est disponible ici mais cette liste n'a rien d'officiel) puis faire un fichier pour chaque.

Maintenant la question que je me (et vous) pose, c'est: y'a-t'il des effets secondaires que je n'aurai pas encore remarqué ?

Problème: ini_get('memory_limit') renvoit un truc du genre 8M, or memory_get_usage() renvoit un entier (en octets), rendant toute comparaison impossible.

Solution:

function memory_get_limit() {
	$shorthands = array('K' => 1024, 'M' => 1048576);
	$memory_limit = ini_get('memory_limit');
	$parts = array();
	if (is_numeric($memory_limit)) {
		return $memory_limit;
	} elseif (preg_match('/(\d+)(K|M)/', $memory_limit, $parts)) {
		if (isset($shorthands[$parts[2]])) {
			return $parts[1] * $shorthands[$parts[2]];
		}
	}
	return false;
}

Quand on est dans une boucle, et qu'on veut remplir un array, à chaque itération on doit y rajouter une ligne et garder la trace de l'index courant du tableau, cela peut se faire de plusieurs façons, en voilà au moins deux:

$array = array();
 
while(foo()) {
 
	$array[] = array();
	$row = & $array[count($array) - 1];
 
}

$array = array();
 
while(foo()) {
 
	$row = & $array[];
 
}

qu'on peut fonctionniser comme suit (dans le but par exemple de gagner en lisibilité et en flexibilité):

function & array_newrow(&$array, $default = array()) {
 
	$array[] = $default
	return $array[count($array) - 1];
 
}
 
function & array_newrow(&$array) {
 
	$row = & $array[];
	return $row;
 
}

EDIT

Il parait que c'est pas très clair, alors on va expliquer mieux. En gros, dans une boucle, si on veut ajouter une ligne à un array et qu'on procède comme ça:

$array[]['foo'] = 'bar';
$array[]['bar'] = 'foo';

Ca ne fonctionne pas comme on le désire (ça créé deux lignes d'une entrée chacune). On peut donc faire comme ça:

$array[] = array('foo' => 'bar', 'bar' => 'foo');

Ce qui fonctionne, mais n'est pas pratique ni flexible. Reste alors la solution de récupérer une référence vers la dernière ligne du tableau, qu'on créé spécialement pour l'occasion (sortez le champomy !) en utilisant la méthode sus-expliquée:

$row = & $data[];
$row['foo'] = 'bar';
$row['bar'] = 'foo';

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