S’il vous plait ! Et je m’explique.

J’utilise, comme outil d’intégration continue, Integrity.
Avec un « post-receive » sur le repository github, à chacun de mes commits, Integrity est mis au courant et il exécute les tests.

Ca fonctionne à merveille avec mes projets Rails (l’API RefStats et mon portfolio); mes projets Django (la documentation de RefStats).
Mais pour les projets Zend Framework (l’appli web RefStats) et un autre sur lequel je vais bosser en aout et qui sera fait avec Symfony, c’est pas cool.
Les tests, bien qu’ils ne passent pas tous, sont considérés par Integrity, comme valides.

La raison de cela est très simple : lorsqu’un processus console est exécuté, il peut retourner un code de status. Un peu comme le code HTTP sur les pages web.
Ce code doit être à 0 pour que les tests soient valides et à une autre valeur, quelconque, si les tests ne passent pas.
Voir notamment la documentation Integrity.
En PHP, un simple exit(0) ou exit(1) à la fin des tests suffirait à exécuter la chose correctement.

Et vraissemblablement, Symfony tout comme le Zend Framework ne renvoient pas le bon code de status.
Alors s’il vous plait, PHP a déjà pas mal de retard au niveau des tests automatisés d’applications, qu’il serait cool de rattraper. Faire ceci serait déjà un premier pas :)

Si vous avez déjà touché à Zend Framework, vous vous êtes peut-être déjà pris la tête sur ses formulaires.
Et dans ce cas la, vous comprenez déjà probablement ce que je veux dire avec ce titre. Sinon, la suite détaille.

Voici un exemple de formulaire un petit peu complexe.
Vous pouvez en voir le résultat sur la page de gestion des mots clés de RefStats.

Comme vous pouvez le constater, il est assez difficile de comprendre l’intérêt d’un tel formulaire, ce qu’il affichera et même les champs qu’il contient.

Le problème des formulaires ZF est le même que dans beaucoup d’autres composants du framework : ils veulent trop en faire.
Le but d’un formulaire côté serveur est pourtant simple : faciliter la validation des données.
Que cela soit dans Rails ou ceux-ci sont directement inclus dans les modèles ou dans Django et Symfony ou ceux-ci ne servent que à faire la validation, à chaque fois, les formulaires ne génèrent pas d’HTML automatiquement.

C’est, malheureusement, ce qu’essaye de faire Zend Framework.
Mais cela rends la chose illisible car pas ergonomique; impossible à modifier pour la première raison.
Et surtout, absolument pas DRY. Si vous avez besoin de placer deux fois le même formulaire pour les mêmes données. Mais les afficher différemment ou simplement ne pas permettre la modification de certaines données, il vous faut créer deux formulaires différents !
Alors qu’il serait tellement plus simple de ne faire qu’un seul formulaire mais deux pages HTML affichant celui-ci.

Du coup comme vous l’avez deviné, je ne vous conseille absolument pas d’utiliser ces formulaires.
Après, au niveau alternatives, je vous épargnerai Rails et Django. Tout autant que Symfony, qui requiert l’inclusion complète du framework.
En revanche Loic me souffle sur Twitter que JForms serait pas mal.
Mais il est l’un des développeurs du framework et je n’ai pas eu l’occasion de tester la chose. Donc vous êtes sans filet !

Le cas « général »

Lorsque l’on utilise un framework tel que Zend, Symfony ou encore n’importe quelle librairie, il y a deux écoles :

  • Installer une fois le framework dans un répertoire spécifique. Et toutes les applications situées sur la machine utilisent cette version.
  • Installer une version du framework pour chaque application.

A première vue, la première solution pourrait paraitre intéressante. On y gagne en place disque et on a pas des copies de fichiers similaires partout sur sa machine.

Cependant il s’agit d’une très mauvaise idée.
Vous allez en effet vous retrouver bloqué sur une version de la librairie à utiliser pour toutes vos applications. Et lorsque une nouvelle version majeure sortira et que la rétrocompatibilité avec la version précédente ne sera pas forcément très poussée, soit vous ne mettrez pas à jour.
Soit vous devrez mettre à jour toutes vos applications en même temps pour faire cette mise à jour. C’est un petit peu lourd. Autant donc dire que vous ne mettrez pas à jour.
Et si vous le faites, vous ne prendrez probablement pas le temps de tester chaque application correctement et vous retrouverez avec des bugs.

En revanche si vous avez une version spécifique de la librairie spécialement pour l’application, vous pouvez mettre la librairie à jour pour une application, tester celle-ci proprement et puis passer à l’application suivante.

Et en versionnant la librairie globale

Avec Rails

Rails propose quelque chose d’assez sympatique. Dans le fichier config/environment.rb, vous avez
RAILS_GEM_VERSION = '2.3.2' unless defined? RAILS_GEM_VERSION

Vous définissez la version de la librairie utilisée dans l’application.
A côté de cela, vous avez donc plusieurs versions de rails installées dans le répertoire des librairies globales. Et vous pouvez choisir celle que vous désirez en fonction de l’application.

Plus de librairie inclue directement dans l’application (ce qui est tout de même assez crade).
Plus de problèmes de changement de version multi applications. Vous pouvez installer Rails 2.3.2 et l’utiliser dans l’une de vos applications tout en ayant toutes les autres qui tournent encore avec Rails 2.2.

Symfony

Symfony possède un fichier config/ProjectConfiguration.class.php
Dans lequel vous trouverez
require_once dirname(__FILE__).'/../lib/symfony/autoload/sfCoreAutoload.class.php';
Remplacez le chemin par celui vers la version de Symfony de votre choix. Et le tour est joué !

Zend Framework

Avec Zend Framework, c’est en définissant le include_path que vous pouvez définir la version de la librairie que vous utilisez.
Si vous avez, dans votre document public/index.php
set_include_path(
APPLICATION_PATH . '/../library' . PATH_SEPARATOR
. APPLICATION_PATH . PATH_SEPARATOR
. get_include_path()
);

require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();

Il vous suffit de remplacer ‘/../library’ par le chemin vers le dossier library versionné pour votre application.

Alors après entre utiliser des librairies versionnées et implémenter directement la version de votre choix dans l’application, c’est à vous de faire la part des choses. Je pense que cela dépends surtout des gouts.
La seule chose à éviter est bien évidemment la librairie installée une seule fois, utilisée par toutes les applications et impossible à mettre à jour.
Et ceci est bien évidemment faisable avec d’autres frameworks et librairies que les 3 mentionnés ici. Documentez vous ! ;)

Je publie ce billet un peu rapidement comme une note car j’ai eu du mal à trouver l’information lorsque j’en ai eu besoin.

La documentation de Zend Framework n’indique que les informations de connexion pour SQLite dans app.ini.
Mais tout le monde n’utilise pas SQLite (et pour donner un avis totalement personnel, je dirais heureusement).

Voici donc les informations requises pour la configuration de MySQL dans votre application utilisant Zend Framework.

[general]
database.adapter = "MYSQLI"
database.params.host = "localhost"
database.params.username = "root"
database.params.password = ""
database.params.dbname = "myDatabase"

Et puis rien que pour le fun, Oracle :
[general]
database.adapter = "Oracle"
database.params.host = "localhost"
database.params.username = "root"
database.params.password = ""
database.params.dbname = "myDatabase"

SQL Server
[general]
database.adapter = "Pdo_Mssql"
database.params.host = "localhost"
database.params.username = "root"
database.params.password = ""
database.params.dbname = "myDatabase"

Et PostgreSQL
[general]
database.adapter = "Pdo_Pgsql"
database.params.host = "localhost"
database.params.username = "root"
database.params.password = ""
database.params.dbname = "myDatabase"

 
Fork me on GitHub