La programmation objet encore peu exploitée dans Xoops !

Bonjour,

Alors que je m'apprêtais de nouveau à tester le module ClassGenerator pour le valider et le déposer dans notre référentiel et que par la même occasion j'envisageais de programmer sérieusement sur Xoops (vous comprendrez plus loin le mot "sérieusement"), je me suis rendu compte que la programmation de module avec Xoops demandait quelques règles élémentaires à respecter.

J'ai alors entrepris une petite recherche dans la base des modules, et je vous fait parvenir plus loin les résultats.

J'ai donc lu avec attention les deux articles de l'auteur du module ClassGenerator que vous trouverez sur Xoops dans la partie documentation.

Si vous souhaitez développer des modules pour Xoops, il est conseillé de commencer par lire ces deux articles, même s'il est tout à fait possible de s'en passer et de développer des modules avec classes ou sans classes sans respecter les quelques règles de programmation énoncées dans les articles.

Pourquoi attirer l'attention de nouveau sur ces articles ? Tout simplement par le fait que développer des modules en soit ne demande pas beaucoup de connaissance quand on sait déjà programmer un peu (j'en suis la preuve avec un module que je suis en train de finaliser). De plus développer en utilisant des classes n'est pas plus compliqué quand on connais déjà les mécanismes, mais utiliser les classes mis à disposition par Xoops requière quelques recherches et un savoir faire qu'il faut acquérir.

J'ai donc entrepris ce matin en me levant (je vous passe les détails ;) une petite recherche sur les modules que j'avais sur mon disque dur. Disons sur un ensemble de 200 modules, des plus vieux (de l'époque de XM et des plus récents que j'utilise sur mes sites de tests ou en production). Le test est simple : "Rechercher le mot InitVar sans utiliser la casse dans l'ensemble des fichiers de ces 200 modules", je vous livre ici la liste des modules qui font appel à ce mot clef :

(Ordre aléatoire)

- Tous les modules de la smartfactory (smartfaq, ..)
- Xflow (le module de worflow en cours de développement)
- Xhelp
- Liaise (et formulaire, formulize..)
- Weblog
- Module TV
- Myguestbook (et Xfguesbook)
- XoopsGallery
- Forum Ipb (certaines bouts de code rajoutés pour l'intégration)
- Forum Phpbb (même commentaire ci dessus)
- AvatarMaker (utilise getobjects pour la classe AvatarMaker)
- Cbb (basé sur newbb)
- Digest (tous les modules de phppp en fait Xmline, xconv..)
- Quelques modules d'origine : XoopsPartners, xoopsPolls
- Catads (même auteur que Xfguestbook)

Comme vous pouvez le voir la liste est mince. J'ai commencé à me poser ces questions alors que j'étudiais depuis des années mois maintenant les codes qui étaient à notre disposition à savoir Mylinks et tous les modules basés dessus et croyez moi y'en a un paquet : Wfdownload, XoopsAddress, x-directory si je ne m'abuse, etc..). Et bien pour finir la dessus, je peux vous dire que ces codes malgré leur simplicité et malgré le fait qu'ils utilisent beaucoup de mécanisme de xoops (notifications, class pour les formulaires, génération d'arbre, template, etc ..) ce ne sont plus des exemples à suivre ! Il est beaucoup plus simple d'apprendre dès le départ à programme avec les bons objets ne serait que pour une meilleure compatibilité avec Xoops et les autres modules phares cités plus haut et aussi pour une meilleure pérénité alors que Xoops évolue assez vite ces derniers temps.

Il est clair également que le passage de Xoops 1 à Xoops 2 n'a pas facilité les choses, de vieux codes sont encore présent dans certains modules et personnes n'a envie d'y toucher sans parler qu'il existe aussi pas mal de module Intégré à Xoops qui ne pourront jamais satisfaire à ces nouvelles exigeances de programmation (phpWiki, XOScommerce, Adresse book, 4images, ...)

Je viens de vous livrer une piste de reflexion pour ceux qui sont en train de découvrir la programmation avec Xoops.

Je vous invite à en discuter dans ce fil de discussion

Merci