Le Laboratoire XooFoo.org, dans le cadre de ses actions de promotion du système de gestion de contenu Web "XOOPS", vient de créer deux extensions pour Google Chrome, l'une est similaire à la XooFooBar conçu pour Firefox, avec des liens vers les principaux sites de supports pour Xoops, les pages et groupes sur Facebook, sur Twitter, de partenaires, ainsi que les liens pertinents vers des sites d'Outils ou d'Astuces, .... ; la seconde vous permettra d'effectuer facilement des recherches sur les principaux sites de support Xoops, et principalement : FrXoops.org, Labs.XooFoo.org, TV.XooFoo.org, Xoops Project et Xuups.com.  plus...

Héritage de la class xoopsForm

Qu'est ce que l'héritage ?

L'héritage est un principe propre à la programmation orientée objet (POO), permettant de créer une nouvelle classe à partir d'une classe existante. La nouvelle classe "hérite" des propriétés et méthodes de la classe dont elle hérite, appelée classe "mère". La classe qui hérite est appelée classe "fille".

Cette définition est très succincte vous pouvez compléter vos connaissances en programmation orienté objet sur le web, un petit lien concernant l'héritage : http://wind.developpez.com/tutoriels/windev/windev-poo-heritage/

Xoops et l'héritage

Comme tout bon projet informatique, xoops utilise la POO. En effet ses développeurs (que je remercie au passage) ont écrit un ensemble de classes qui régissent ce projet.
Donc nous pouvons utiliser l'héritage pour ajouter, modifier le comportement de XOOPS.

Tout ça, c'est très bien, mais pourquoi faire ?

• on peut modifier n'importe quelles classes directement dans le projet.

Ces modifications sont appelées des "HACKs".

C'est a ce moment précis, que vous introduisez dans votre code le grain de sable qui risque de vous miner la vie, pour l'évolution et la maintenance de votre site.
- Que vas t'il se passer à la prochaine mise à jour ? Dans 1 an.......
Plus rien ne vas fonctionner correctement, il va falloir recommencer toutes les modifica-tions une par une; Comme vous êtes un développeur compétent vous avez pris soin de consigner dans un fichier ou sur un "petit cahier" toutes les modifications à faire.

Dans le cas contraire : je vous souhaite bon courage !

L'autre solution c'est d'utiliser l'héritage, allons y !

Prenons un exemple avec un formulaire dans XOOPS.
Les formulaires dans XOOPS, bien que souvent suffisants, ne peuvent pas répondent à l'ensemble de vos besoins spécifiques.

Nous allons ici, voir 2 applications de l'héritage avec XOOPS et plus précisément avec les éléments xoopsThemeForm et xoopsElement , ce n'est que des exemples et absolument pas restrictif.

• changer l'url de action du formulaire à la volé
• ajouter un nouvel élément, pas disponible dans le projet initial

Nous partons du principe, que nous avons un module appelé myModule et que ce module tout à fait standard contient un répertoire class dans lequel nous allons pouvoir placer nos nouvelles classes.

La première chose, c'est comprendre comment sont hiérarchisées les classes qui génèrent le formulaire.

La classe XoopsForm est la classe de base du formulaire, c'est une classe abstraite, ce qui signifie que cette classe ne doit pas être utilisée directement mais qu'elle doit être étendue, généralisée. C'est en faite une sorte de gabarit, des propriétés et des méthodes.
Je vous laisse vous plonger dans la POO pour plus de détail.

La classe XoopsThemeForm est la classe qui généralise XoopSForm et qui vas afficher le formulaire sous forme de table, c'est cette classe dont nous hériterons, pour modifier le comportement général du formulaire.

Note : si nous voulons que notre formulaire ne s?affiche plus sous forme de tableau, alors il nous suffirait de partir directement de XoopsForm et refaire le travail à notre sauce; Pour ça, s'en se prendre la tête, il suffit de partir de xoopsThemeForm et de modifié la méthode render() qui est responsable de l'affichage.

Comme vous l'aurez remarqué, dans XoopsForm (voir API) la méthode render() est vide, et oui ! C'est ça une classe abstraite; Elle nous dit juste que cette méthode doit être redé-finie dans la classe qui l'étend.

Donc dans XoopsThemeForm la méthode est redéfinie pour affiché un formulaire sous forme de table :

Mise en pratique

Dans notre premier exemple nous souhaitons envoyer notre formulaire à un traitement différent en fonction d'une action utilisateur.

Notre formulaire est le suivant :

Jusqu'ici rien de bien sorcier ! Nous allons donc modifier le comportement de XoopsThemeForm pour cela,nous créons un fichier php dans le répertoire class, que nous nommons de manière très original : my_form.php

Nous obtenons maintenant la séquence d?héritage suivante :

Pour que cette classe hérite de XoopsThemeForm, on dit aussi pour qu'elle étend, ou en-core qu'elle généralise, on écrit en php :

Bien sûr pour que cela fonctionne, il faut que la classe "fille" trouve sa classe "mère", donc il faut inclure la classe XoopsThemeForm ce qui donne :

Vous pouvez aussi utiliser xoops_load de la manière suivante :

Ensuite on peut soit ajouter de nouvelles propriétés ou de nouvelles méthodes ou bien redéfinir des méthodes existantes, on dit dans ce cas "Que l'on surcharge (override) la méthode".

Nous allons ajouter à notre formulaire une nouvelle méthode, actuellement la classe XoopsThemeForm ne permet pas de changer le paramètre action du formulaire après avoir déclaré le constructeur, ce paramètre est passé au constructeur une fois pour toute; Mais on veut le modifier en fonction des actions utilisateurs et diriger le formulaire vers des traitement différents.

Nous allons donc ajouter une méthode :

Cette nouvelle méthode (appelé aussi "setter") affecte l'url a la nouvelle propriété $newAc-tion si le paramètre de la fonction est passé.

Note importante :
La classe xoopsForm, n'a pas était optimisée pour être généralisée de manière a donner a ux développeurs la possibilité de faire ce qu'ils veulent, à mon grand regret. Pour cela il aurait fallu que les propriétés de la classe xoopsForm soit "protected" et non "private" (je vous renvois à la POO) ou alors que : chaque propriété soit associée à un "setter" et à un "getter". j'ignore les raisons de cette absence.
Ceci vas nous obliger a redéfinir la fonction render(). Ceux qui n'aurait pas été obligatoire si nous avions eu des "setter" ou que les propriétés eût étées "protected"

La classe avec la fonction render() redéfinie, on remplace $this->getAction par notre nouvelle propriété $newAction, ce qui donne :

Maintenant nous pouvons l'utiliser de la manière suivante :

Vous pouvez faire une mise à jour s'en risque......

Deuxième exemple on souhaite ajouter un élément qui n'existe pas dans les classes de XOOPS, par exemple on veut que notre formulaire affiche des images précédemment téléchargées sur le serveur, pour informer l'utilisateur.

Il n'y a pas d'élément, affiche image, dans les formulaires de XOOPS. Nous allons donc le créer en étendant la classe XoopsFormElement, qui est la classe chargée de créer un élément de formulaire, comme formcolorpicker etc....

ce qui donne comme héritage :

classe :

La méthode fonction setContent($content) vas nous permettre d?insérer du contenu.

• Utilisation :

Maintenant que nous avons créer un nouvel élément de formulaire , ajoutons le à notre formulaire

Voilà nous avons ajouté un élément à notre formulaire