Je n'ai pas encore regarder le fonctionnement du module, mais j'étais sur le point d'en développé un du coup je me disais super chouette.
Cependant je pense après avoir jeté un œil dans le code qu'il y a un certain nombre de problème dans ton module qui me laisse un peu perplexe.
Je le liste pas tout mais voici quelques axes d'amélioration:
- Pas de numéro de version dans le fichier xoops_version.php. Ce serait bien qu'il y en ai un, le changement d'icône n'est pas suffisant pour gérer les mise à jour.
- Dans le fichier xoops_version.php il y a bien le fichier "mysql.sql" qui contient l'unique table, mais il ne contient pas la liste des tables (de la table pardon), du coup la désinstallation ne se fait pas correctement, et donc impossible de réinstaller le module une deuxième fois, sans supprimer la table manuellement.
-Il est conseillé de préfixer la table avec le nom du module par exemple (moncv_cv au lieu de cv) , cela permet de s'assurer qu'un autre module ou le noyau de xoops n'a pas lui même une table de ce nom. Mais cela n'est pas trop grave.
-plus embêtant, quand on regarde la structure de la table il y a de gros problèmes qui peuvent notamment mener a des impasses dans l'évolution du module:
ex:
extrait
Citation :
`login` varchar(800) NOT NULL
`nom` varchar(200) NOT NULL
`prenom` varchar(200) NOT NULL
`lieu` varchar(200) NOT NULL default '0'
`sexe` varchar(20) NOT NULL
`jour` varchar(20) NOT NULL default '0'
`mois` varchar(20) NOT NULL default '0'
`annee` varchar(20) NOT NULL default '0'
`nationalite` varchar(200) NOT NULL default '0'
`situation` varchar(200) NOT NULL default '0'
`ville` varchar(200) NOT NULL
`pays` varchar(200) NOT NULL default '0'
`cp` text NOT NULL
`email` varchar(200) NOT NULL
200 caractères pour le nom, 800 pour le login, 200 pour le lieu, etc. Autant dire que ta table va occuper un espace exorbitant pour ps grad chose.
par exemple le login 800 caractères alors que 12 serait largement sufisant, et est-ce le login utilisé par xoops, dans ce cas est-il vraiment utile?
Un champ test pour le code postal ? un varchar(6) serait plus judicieux.
etc..
Cela fait un total approximatif de plus de 8500 octets par enregistrement (8.5 mo), c'est énorme. Pour ceux qui sont un peu limités de part leur hébergeur, attention en utilisant ce module.
Je ne sais pas comment mySql gère ça mais la il y a un gros problème.
autre extrait
Citation :
`per1` varchar(100) NOT NULL
`per2` varchar(100) NOT NULL
`per3` varchar(100) NOT NULL
`per4` varchar(100) NOT NULL
`per5` varchar(100) NOT NULL
`per6` varchar(100) NOT NULL
`des1` text NOT NULL
`des2` text NOT NULL
`des3` text NOT NULL
`des4` text NOT NULL
`des5` text NOT NULL
`des6` text NOT NULL
`peri1` varchar(100) NOT NULL
`peri2` varchar(100) NOT NULL
`peri3` varchar(100) NOT NULL
`peri4` varchar(100) NOT NULL
`peri5` varchar(200) NOT NULL
`peri6` varchar(200) NOT NULL
`peri7` varchar(200) NOT NULL
`peri8` varchar(200) NOT NULL
`peri9` varchar(200) NOT NULL
`peri10` varchar(200) NOT NULL
`desc1` text NOT NULL
`desc2` text NOT NULL
`desc3` text NOT NULL
`desc4` text NOT NULL
`desc5` text NOT NULL
`desc6` text NOT NULL
`desc7` text NOT NULL
`desc8` text NOT NULL
`desc9` text NOT NULL
Quand on voit la duplication de champs numérotés comme ici, cela signifie que probablement (pas obligatoirement cependant) le modèle de données n'est pas adéquat.
Des tables enfants dans ce cas seraient plus appropriées.
Du coup, moi qui suis un vieux routier (qui a dit très vieux !!!), il n'y a pas assez de champs pour indiquer les 36 sociétés et 76 emplois que j'ai assumés dans ma carrières (bon j'exagère peut être un peu mais pas tant que ça !!!)
Désolé si je suis un peu critique, mais un module bien conçu est un module susceptible d'évoluer sans problème.
Je vais quand même le tester, mais tu devrais reprendre ces éléments.
Courage le plus dur est fait, tu as fais le premier pas!
JJDAI
