A croire que l’interface a été une réussite car j’ai reçu plusieurs demandes de redesign de services web en m’invoquant la lisibilité de dump-it.

Alors en cas de besoin d’uploader une image, sans perte de qualité :

Depuis que j’utilise PEAR, et plus spécialement le package DataObject j’ai gagné un net gain de productivité, de qualité de code.

Les gains flagrant en lisibilité :

• une page classique de code (CRUD) contenant l’interface (un système de template devient quasi inutile) fait environ 60 lignes
• aucune requête SQL contraignante à lire (et donc, à comprendre) de plusieurs lignes
• gain de sémantique pour un partage de code (j’expliquerais ce point un peu plus loin)
• gestion quasi triviale des héritages entre tables

Prise en main de la librairie PEAR par un programmeur non spécialiste PHP

J’ai eu à travailler avec un ami développeur qui n’est pas fan du PHP car il trouvait ce langage méli-mélo.
Je lui ai donc montré comment je travaillais avec PEAR et particulièrement le package DataObject ainsi que FormBuilder.
Il m’a confessé quelques heures plus tard que cette librairie donnait à PHP un sens une homogénéité, un plaisir à développer. Que cela renouait avec l’esprit ‘fun’ du développement web.

J’ai été moi même surpris à quelle vitesse il a su s’adapter ainsi que créer des CRUD avancés d’une manière très aisée.

Conclusion

Il m’a été très bon d’avoir un avis externe au cercle des développeurs web quant à l’utilisation de PEAR ainsi que sa prise en main. Il en ressort que PEAR est très pratique, mais qu’une courte formation sur les points clés de son fonctionnement est nécessaire sous peine d’éplucher les forums des heures durant.

PEAR est donc un moyen ‘logique’ de manipuler des données qui séduira des programmeurs de tout bords lorsqu’ils auront à travailler dans le web.

Voyons quelques unes des fonctionnalités avancées des librairies PEAR::DB_DataObject ainsi que PEAR::DB_DataObject_FormBuilder.

Jetons tout d’abord un coup d’oeil à notre fichier Utilisateurs.php :

Tout d’abord, premier point : comme décrit dans les commentaires, ne tentez pas de modifier ces lignes-ci, ce sont celles qui sont générées automatiquement par notre fichier createTables.php.

1.Les règles

Les règles permettent de gérer le type de contenu pouvant être soumis par l’utilisateur dans un formulaire.
Voyons maintenant comment appliquer une règle sur notre champs email.

Ajoutons apres le END_AUTOCODE
une fonction :

Simple non? Décrivons cette ligne de code:
la fonction postGenerateForm est la fonction qui sera exécuté comme son nom l’indique apres la génération du formulaire. Elle prend en paramètre un pointeur sur l’objet formulaire (qui est je rappelle un HTML_QuickForm ).
Le premier paramètre correspond au champs du DataObject ici, MAIL, ensuite, le seconde paramètre correspond au message qui sera affiché en cas de probleme, et le troisième correspond à la règle proprement dite.
Vous pouvez y insérer une expression réguliere, ici, lorsque l’on précise ‘email’ le test sera automatique.

Pour plus d’informations sur les règles et les filtres visitez le site de PEAR.

2.Executions d’actions lors de delete insert update

Notre objet Utilisateurs qui est comme vous aurez remarqué une classe héritant de la classe DataObjects, vous pouvez surcharger les fonctions update(), insert() et delete().

Cette surcharge est très utile par exemple si l’on a besoin d’effacer un fichier lors d’une destruction d’une entrée dans la table.

Exemple de traitement de fichier :

3.La fonction preProcessForm

Si vous avez besoin d’effectuer un traitement sur le formulaire avant qu’il soit affiché, c’est ici qu’on bosse !

Par exemple si nous avons un booléen au nom de BACTIF dans notre base, qui correspondrait à l’état d’activation d’un compte user.
Afin de représenter ce booléen, j’ai choisi d’utiliser une checkbox.
Voici le code de ma fonction :

Il est à noter que pour cette fonction le paramètre est un Array.

4. Afficher / cacher certains champs du forum

Il peut être utile voire indispensable de pouvoir cacher ou interdire à l’édition certains champs de votre table. Pour ceci nous disposons de deux variables de type Array : $fb_fieldsToRender et $fb_userEditableFields

Comme leurs noms l’indiquent, la première contient les champs à donner au Renderer ( donc les champs à afficher ) et la seconde contient les champs que l’utilisateur aura le droit de modifier.

A noter que dans son extrême lucidité, notre formulaire n’affichera jamais (encore moins n’autorise à éditer) le champs servant de clé primaire.

Exemple d’utilisation :

5. Modifications des labels du formulaire

Avoir un formulaire affichant froidement une alternance de labels et champs tout droits décendus de la table n’est pas génial.
Pour rendre notre affaire réellement géniale nous allons modifier une variable au doux nom de $fb_fieldLabels

Voici un exemple d’utilisation :

6.Conclusion

Ce quatrième article vient clore cet aperçu rapide du gain de temps et de productivité permis par la librairie PEAR.

Je vous invite à aller visiter les sites traitant du sujet :

• PEAR
• Documentation de FormBuilder
• un slide en anglais présentant le prototypage rapide grâce à DataObject et FormBuilder
• Package DataObject
• Package HTML_QuickForm

Voyons désormais le package PEAR::DB_DataObject_FormBuilder qui permet de créer automatiquement des formulaires depuis nos objets précédemment générés.

Reprenons là ou nous nous étions arrétés dans le dernier article.

Nous possédons un objet utilisateurs que nous avions créé avec peu d’efforts. Je vais maintenant vous exposer comment créer automatiquement un formulaire de traitement pour cet objet.

Tout d’abord vous devrez installer le package PEAR::DB_DataObject_FormBuilder disponible sur le site de PEAR, ou, via l’installeur ligne de commande :

pear install DB_DataObject_FormBuilder

Une fois le package installé nous pouvons passer à l’utilisation du générateur de formulaire.

Et hop, un formulaire tout beau, prêt à insérer des données dans notre base d’utilisateurs !

Si vous voulez éditer un enregistrement, rien n’est plus simple, il vous suffit de modifier :

Dans le prochain article, j’approfondirais l’exemple d’utilisation des formulaires et des objets DataObject, en détaillant comment ne pas afficher un champs, appliquer des règles, et encore comment appliquer des traitements spéciaux aux données ( par exemple un MD5 sur un password)

Votre dossier dataobjects/ est plein d’objets frémissants, prêts à être torturés ?

Dans cette partie nous allons voir comment utiliser simplement ces objets afin de manipuler nos tables en BDD.

Charger le contexte

Afin d’utiliser ces objets php, nous nous devons de leur fournir le contexte, autrement dit, de les configurer.
Par exemple prenons une table Utilisateurs, ayant comme champs id,nom,prenom.
Lors de la génération de l’objet, un fichier a été créé: dataobjects/Utilisateurs.php, nous allons donc créer à notre tour le fichier de configuration pour cet objet. Pour le moment plaçons le à la racine du site.

utilisateurs.config.php

Vous aurez compris que ce fichier de configuration permettra à l’objet créé d’obtenir tous les paramètres spécifiés dans le db_dataobjects.ini.

Créez et utilisez vos objets

Le chemin n’a pas été trop long? Nous y sommes ! A deux pas de l’arrivée.
Nous allons créer un objet prêt à être utilisé pour gérer notre base de donnée.

Créons à la racine du site ce fichier : index.php

Comme vous avez pu le constater, c’est relativement trivial.

Le prochain article portera sur l’utilisation approfondie des objets DataObjects.

Et bien figurez vous que moi aussi !

Les techniques les plus à la mode pour le développement rapide sont les framework comme Ruby On Rails, CakePHP, Symphony, et j’en passe…
Cependant ces frameworks sont relativement longs à l’apprentissage (surtout si vous choisissez ROR), et il peut vous sembler utile de n’utiliser qu’une librairie.
Qui dit librairie en PHP, dit ZendFramework ou PEAR, mon choix s’est porté sur PEAR.

Voici donc en plusieurs parties comment utiliser les bases de données, créer des applications rapidement en PHP avec PEAR::DataObject.

1. DataObject kézako?

Le module DataObject de la librairie PEAR permet de générer des objets grâce à la récupération de la structure d’une table.
Il vous faut dans un premier temps, installer la librairie PEAR (qui est généralement installée d’office avec PHP), puis d’installer le module DataObject en entrant dans un shell :
pear install DB_DataObject
Une fois les fichiers récupérés, nous pouvons nous attaquer à la création de nos objets!

2. Configurer

Jetons un oeil sur ce qu’a installé notre commande, dans notre dossier PEAR.

Nous avons plusieurs scripts, Generator.php, createTables.php, error.php etc..
Ici, le script qui nous intéresse est createTables.php.

Ma méthode (peu orthodoxe) conciste à copier ce fichier et à le déplacer dans le dossier public_html qui contiendra les sources de mon futur site (ou dossier www d’un serveur wamp sous windows).
Ce fichier est destiné à être appellé en ligne de commande (php createTables.php bla bla bla), cependant j’ai trouvé que cette utilisation n’était pas la plus pratique à la longue, lorsque vous devez générer régulièrement des DataObjects.

Nous devons ensuite créer un fichier de configuration, que j’appelle db_dataobjects.ini, voici celui que je vous montre en exemple :

Hop une fois ce fichier sauvegardé il ne vous manque plus que d’entrer en ligne de commande:
php createTables.php db_dataobjects.ini
ou bien d’insérer cette ligne au début de votre createTables.php que vous avez déplacé:

Exécutez votre script : http://localhost/projet_pear/createTables.php

Tadaaaaaaaaaa, c’est tout.

Si tout s’est bien passé vous aurez obtenu un dossier dataobject contenant les structures de vos objets pour gérer vos tables etc…

Je vous écris la suite rapidement, promis.