====== Développement de plugins : un peu plus de rigueur et de discipline ? ======

===== Introduction =====

Si, en matière de plugins, toute contribution est la bienvenue, il n’en demeure pas moins que respecter quelques critères de qualité sera la garantie d'un accueil bien plus « chaleureux ». Oui, mais voilà : ces fameux critères, quels sont-ils ? Hop ! Passage en revue des troupes.
 
L’objectif n'est pas de traumatiser les auteurs de plugins, non. Il s'agit simplement de garantir aux utilisateurs de DotClear des plugins présentant une qualité de code et une philosophie quasi équivalentes à celles de DotClear lui-même.

Pour que vous ne soyez pas pris au dépourvu, voici une petite compilation des critères qui pourraient être retenus pour l’évaluation des développements. C’est parti.

===== Code PHP en général et commentaires =====
  * Le plugin doit se conformer aux exigences en terme de versions PHP et MySQL retenues pour DotClear (cf. paragraphe « Pré-requis » de [[1.2:admin:install#prerequis|la documentation d’installation]]). Notez qu'une librairie  de compatibilité PHP existe déjà dans la distribution de DotClear (cf.  [[http://www.dotclear.net/trac/file/trunk/inc/libs/lib.compat.php|inc/libs/lib.compat.php]]). Vous pouvez vous en inspirer en cas de besoin.
  * Le code PHP doit suivre les conventions utilisées dans DotClear. Voir la [[coding-standards|page dédiée]].
  * Le code PHP doit être correctement documenté et devrait suivre la syntaxe des commentaires propre à DotClear (cf. [[code-documentation|Documentation du code PHP]]).
  * Le plugin doit utiliser les classes, et classes dérivées, [[api/connection|connection]] et [[api/recordset|recordset]] pour ses accès à la base de données.
  * Le plugin doit recourir autant que possible aux fonctions utilitaires déjà mises à disposition par DotClear (Cf. [[http://www.dotclear.net/trac/browser/trunk/inc/libs/|inc/libs/]]).
  * Le fichier ''functions.php'' du plugin doit contenir une classe primaire nommée selon le plugin pour éviter les collisions.
  * Le plugin doit fonctionner avec des URLs en mode ''querystring'' et ''pathinfo''.
  * Le plugin doit fonctionner avec un encodage ''UTF-8'' et ''ISO-8859-1''
  * Le plugin devrait utiliser un sous répertoire dans ''share/'', du même nom que le plugin, pour stocker d'éventuelles informations liées à son fonctionnement.

===== Code PHP pour les sorties, XHTML et CSS =====
  * Les méthodes du fichier ''functions.php'' générant des sorties doivent offrir la possibilité de reformater celles-ci.
  * Les sorties doivent être en XHTML Strict.
  * Les sorties ne doivent pas utiliser de CSS inline.
  * En cas d’utilisation de classes CSS, ces dernières devraient reprendre autant que possible le nom du plugin afin d’éviter d'éventuelles collisions.

===== « Confort » de l'utilisateur =====
  * Le plugin devrait offrir une procédure d’installation simple, à défaut, il doit offrir une aide à l'installation simple.
  * Le plugin devrait prévoir une prise en charge de la désactivation.
  * Le plugin doit inclure une aide à l’utilisation et à l’insertion dans le template, lisible depuis la page d’administration.
  * Le plugin doit être localisé (au minimum en ''EN'' et ''FR'')
  * L’auteur du plugin doit fournir une adresse email valide lors du référencement du plugin.

===== Licence et copyrights =====
  * L’auteur doit s'assurer que les éléments graphiques du plugin ne violent pas un quelconque copyright.
  * La licence s’appliquant au plugin doit être clairement mentionnée :
    * Pour un plugin utilisant des composants internes de DotClear, la licence appliquée sera la GNU GPL.
    * Pour un plugin totalement autonome, le choix de la licence sera laissé à l’auteur, mais devra se porter sur une licence libre ou OSI.

Toujours là ? C’est bien. De toute manière, vous aurez noté qu’il y a rien de terrible ni d’insurmontable dans cette ébauche des critères.

Avant de se quitter, je vous rappelle que ceci n’est donné qu’à titre indicatif. Néanmoins, vous disposez désormais d’une base de travail supplémentaire.

Zou ! Au boulot !