Après avoir présenté rapidement comment générer des objets pratiques pour gérer vos tables et décrit la méthode pour en générer des formulaires, ils nous faut désormais regarder d’un peu plus près comment affiner notre code.

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