BoomtchakDocumentation Adéquate
La documentation de votre module est une étape vitale. Il y a 3 zones où votre module pourrait avoir besoin de documentation : Webmaster, Utilisateur et la documentation du code.
Les zones du Webmaster et de l’Utilisateur sont couvertes par la création de manuels placés aux endroits appropriés dans la hiérarchie de répertoires. (Voir plus bas.) L’information destinée au Webmaster démontre comment installer, configurer et gérer le module. La documentation Utilisateur apprendra à l’utilisateur comment se servir du module.
La documentation du code consiste à écrire une courte description de chaque fonction, noter les paramêtres et les valeurs retournées qu’elle peut avoir, et placer le tout à la tête de chaque fonction. Documenter le code selon la méthode de PHPDoc (http://www.phpdoc.de) permettra une analyse automatique de la documentation par d’autres développeurs désirant utiliser votre module.
Création du Module Logiciel
La partie Logicielle du module sera éxaminée pour assurer que les standards d’écriture de code sont suivis. Nous regardons :
Les noms de Variables Réservés
Un certain nombre de variable sont réservées par PostNuke. Ces variables ne doivent pas être dupliquées au sein d’un module car elles pourraient causer des conflits avec le noyau et provoquer des résultats imprévisibles. On peut trouver la liste actuelle des variables réservées dans le Guide de Développement de Module PostNuke.
Arborescence de répertoire du Module
Un module PostNuke a une structure de répertoire bien spécifique. Cela permet au système de PostNuke d’appeler tous les modules sans besoin d’information supplémentaire pour chaque module créé. Suivre la struture de répertoire comme démontré plus bas est un pré-requis obligatoire pour tout module compatible PostNuke.
Note : Les fichiers et répertoires additionnels en plus de ceux affichés plus bas sont acceptés. Aussi, si un des fichiers ci-bas n’est pas obligatoire (ex. : un module n’ayant pas de table spécifique n’a pas besoin du fichier pntables.php) alors, son existence n’est pas nécessaire. Par contre, les fichiers exécutant les fonctions soulignées ci-bas doivent être conformes à la convention des noms de fichiers.
Note : Ceci montre la structure qu’une galerie pourrait avoir. D’autres modules pourraient avoir des noms différents pour leur répertoire racine de module et de bloc et appropriés pour leurs fonctionalités spécifiques.
modules/ [1]
gallery/ [2]
— docs/ [3]
— -credit.txt [4]
— -install.txt [5]
— -changelog.txt [6]
— -licence.txt [7]
— pnadmin.php [8]
— pnadminapi.php [9]
— pnblocks/ [10]
— -snapshot.php [11]
— pnimages/ [12]
— -admin.jpg [13]
— pninit.php [14]
— pnlang/ [15]
— -deu/ [16]
admin.php [17]
init.php [18]
manual.htm [19]
snapshot.php [20]
user.php [21]
— -eng/ [22]
admin.php [23]
init.php [24]
manual.htm [25]
snapshot.php [26]
user.php [27]
...
— pntables.php [28]
— pnuser.php [29]
— pnuserapi.php [30]
— pnversion.php [31]
[1] Le répertoire racine des modules de PostNuke
[2] Le répertoire contenant tout le code du module (Dans le cas actuel, le module de Galerie est nommé "gallery"). Ce nom de répertoire doit être en lettres minuscules. Vous devez aussi enregistrer le nom de votre module à l’adresse suivante : http://centre.ics.uci.edu/ grape/modules.php?op=modload&name=Wiki&file=index&pagename=ModReg afin d’obtenir un Numéro d’identifiant pour votre module.
[3] Répertoire contenant toute la documentation du module.
[4] Fichier contenant toute l’information des crédits du module.
[5] Fichier contenant toutes les instructions d’installation du module.
[6] Fichier contenant tous les changements que le module a subit depuis sa dernière version.
[7] Fichier contenant l’information sur la license du module.
[8] Fichier contenant les fonctions administratives du module.
[9] Fichier contenant toutes les fonctions opérationnelles et administratives du module.
[10] Répertoire contenant tous les blocs associés au module.
[11] Fichier contenant le bloc associé au module ; Dans le cas présent, ce fichier affiche une image aléatoire d’une galerie.
[12] Répertoire contenant toutes les images du module.
[13] Image icône de l’administration du module.
[14] Fichier contenant les fonctions d’initialisation du module.
[15] Répertoire contenant tous les fichiers de traductions du module.
[16] Répertoire contenant tous les fichiers de traduction Allemande pour le module.
[17] Fichier contenant la langue de traduction Allemande pour les fonctions administratives du module (i.e. pnadmin.php).
[18] Fichier contenant la langue de traduction Allemande pour les fonctions d’initialisation du module (i.e. pninit.php).
[19] Fichier contenant la langue de traduction Allemande pour le manuel du module.
[20] Fichier contenant la langue de traduction Allemande pour le bloc snapshot (image aléatoire).
[21] Fichier contenant la langue de traduction Allemande pour les fonctions Utilisateurs du module (i.e. pnuser.php).
[22] Répertoire contenant tous les fichiers de traduction Anglaise pour le module.
[23] Fichier contenant la langue de traduction Anglaise pour les fonctions administratives du module (i.e. pnadmin.php).
[24] Fichier contenant la langue de traduction Anglaise pour les fonctions d’initialisation du module (i.e. pninit.php).
[25] Fichier contenant la langue de traduction Anglaise pour le manuel du module.
[26] Fichier contenant la langue de traduction Anglaise pour le bloc snapshot (image aléatoire).
[27] Fichier contenant la langue de traduction Anglaise pour les fonctions Utilisateurs du module (i.e. pnuser.php).
[28] Fichier contenant les définitions de table de la base de données pour le module.
[29] Fichier contenant toutes les fonctions Utilisateur du module.
[30] Fichier contenant toutes les fonctions Utilisateur d’opération pour le module.
[31] Fichier contenant toutes les informations de versions et crédits pour le module.
Utilisation des noms de fonctions standards
Un certain nombre de noms de fonction sont considérés comme stardard, c’est à dire qu’ils ont un sens connu et sont utilisés dans plusieurs modules. Utiliser des noms des fonctions standards rend la tâche plus facile aux autres développeurs voulant utiliser votre module. Voyez la liste complète dans le Guide de développement de Module pour PostNuke.
Utilisez le pnAPI
pnAPI est l’interface de programmation d’application PostNuke, une façon pour les module d’interagir avec le noyau de PostNuke sans avoir nécessairement toujours accès aux tables et à la structure interne. L’API permet aussi de dissimuler des détails d’implémentation afin que le développeur puisse programmer un module d’une façon standardisée et n’ait pas à se préoccuper de ce qui pourrait changer sous le capot. C’est très important pour un système comme PostNuke qui a subi, et continue à subir des changements radicaux au noyau pour devenir plus rapide et acquérir d’avantages de flexibilité.
Le pnAPI est la seule méthode supportée pour accèder aux informations de noyau. Les développeurs de modules doivent utiliser cette méthode pour obtenir des informations du système interne, faute de quoi, le module pourrait tout probablement ne plus fonctionne lors d’une nouvelle version de PostNuke.
Les Sorties
Toutes les sorties générées (informations) par les fonctions de module doivent être renvoyées au noyau de PostNuke. Aucune sortie de toute sorte ne doit provenir directement du module. (All output generated by module functions must be returned to the PostNuke core. No output of any type should be made directly from the module ; doing this is not supported and will break in future versions of PostNuke. )
Variables Globales
Si votre installation doit définir des variables globales, leur nom doit commencer par un simple souligné _ suivi du nom du module et un autre souligné.
Sécurité.
Continuité
Les pré-requis suivants existent pour assurer que le Module Vérifié peut continuer même si l’auteur original l’abandonne et disparaît.
Usage de la base de données pour les Modules
Abstraction Base de données ADODB (une façon pour PostNuke de supporter les bases multiples comme Oracle, Postgres et ODBC)
Le Test
Support
Module a un support du(des) développeur(s)
Modules Commerciaux
Nous n’avons reçu aucune requête de vérification de module commercial mais nous les traiterons individuellement. Certains critères (i.e. : CVS, Licence Open Source, etc.) peuvent ne pas s’appliquer à un module commercial.
RSS 2.0