Du code XHTML conforme

• Le XHTML impose de fermer les balises orphelines (<br>, <hr>, <img>, etc.), en mettant un / avant le > : <br />, <hr />, <img />, etc. Certains vieux navigateurs ne comprennent pas correctement le /> s'il n'y a pas d'espace avant le /. Donc ne pas oublier ce caractère. On va ainsi mettre toutes ces balises en conformité. Pour les autres, on n'oubliera pas de les fermer. Ex: <p> avec </p>.
• Il faut également mettre tous les noms de balises et d'attributs en minuscule.
• On encadrera toutes les valeurs d'attributs par des guillemets : ". Par exemple <div class="wizz">

Séparation du fond de la forme

• Proscrire les balises "<font>" et les attributs HTML "bgcolor", "color", "face", "size", "background", "height", "width", etc.
• Préférer l'emploi des classes de style, en renvoyant la mise en forme dans la feuille de style.

Caractères accentués dans le code HTML et PhP

• Y a-t'il un texte officiel recommandant cela ? Car personnellement je trouve bien plus pratique de saisir directement dans le jeu de caractère d'encodage de la page générée, à la condition obligatoire que celui-ci soit bien spécifié bien évidement. -- ProgFou
  • Je me pose la même question que toi...
  • Avantages des entités SGML : indépendante du codage des caractères (il devient possible de changer instantanément le codage des caractères (par exemple ISO-8859-1 vers UTF-8), sans changer le code).
  • Inconvénient des entités SGML : augmente légèrement la taille du code ; rend le code légèrement moins lisible.
  • .-- CharlesNepote
  • Dans ces conditions, je propose que l'on recommande de coder directement dans le jeu de caractère du Wiki (quitte à passer tous les fichiers .php par un recode ou iconv le moment venu), excepté dans les cas où la spécification du jeu de caractère utilisé ne pourrait être garantie (comme le die en tête des handlers). -- ProgFou
    • Je suis d'avis que tout les sources soient en ASCII et utulisent donc les entités HTML. Cela rendra plus facile une future migration de iso-8859-1 vers UTF-8 (ViWikiNi est une piste à suivre). -- OlivierMengu?é
    • Mhhh... Effectivement : je réfléchissais encore en tant que développeur local ! Recoder tous les sources ne pose aucun problème dans ce cas, mais ça risquerait au contraire de poluer le CVS ! Donc je reviens sur mon choix pour opter aussi pour l'usage des entités SGML dans le code source (mais pas forcément dans les pages installées par le setup). -- ProgFou

Des accès normalisés aux bases de données

Requêtes sur le minimum d'expressions

Éviter l'ajout de méthodes supplémentaires à la classe Wiki (ex Wakka)

Utiliser des constantes quand c'est possible

• Là je ne suis pas sûr de mon coup et je fait appel aux gouroux Php sur la question. Il me semble que les constantes en Php (define ...) utilisent moins de mémoire et sont plus rapides à traiter que les variables. Si c'est le cas je suggère d'inscrire en recommandation de développement leur utilisation systématique quand c'est possible. -- CharlesNepote
  • Oui les constantes sont plus rapides à traiter et leur usage est recommandé par rapport aux variables pour des raisons d'embrouilles dans le "scope" des variables. Je donnerai plus de détails bientôt. --PatrickPaul
    • PatrickPaul n'a pas développé et je ne comprends pas sa remarque... Mais je reviens sur l'usage des constantes : elles posent un problème dans le cas où on doit utiliser d'autres classes dans WikiNi ; ou dans le cas hypothétique ou la classe wiki devrait être employée dans d'autres applications. Je me demande, d'une manière générale, s'il ne vaut pas mieux utiliser $this->variable qui, elle, ne risque pas d'être confondue avec une autre. -- CharlesNepote
    • D'une part il n'est pas si évident que les constantes soient plus rapides à traiter (voir les commentaires associés à la doc PHP sur les constantes), d'autre part je me demande si on y gagne vraiment au final... En effet, autant les constantes sont indiquées pour des valeurs universelles, globales et invariables telles que TRUE, FALSE ou encore WIKINI_VERSION, autant elles peuvent être génantes pour des variables dont la valeur constante est contextuelle (je pense aux textes et à leurs traductions). D'un autre coté, niveau sécurité c'est plutôt bon : une constante ne peut plus être modifiée ou indéfinie une fois définie et la syntaxe PHP ne permet pas de les confondre avec des variables. Donc pour ma part je serais plutôt pour utiliser des constantes uniquement dans un but bien défini et utiliser des variables de classe sinon ; avec le minimum possible de variables globales, sans compter celles gérées par PHP comme $_GET, $_COOKIES et autres $_SESSION, idéalement une seule : $wiki. -- ProgFou
    • Je trouve qu'une constante qui manque franchement, c'est le préfixe des tables... Le seul cas où cela pourrait poser problème c'est si on instancie deux objets wiki connectés à utilisant des préfixes différents, mais je pense que ce ne serait certainement pas le seul problème, et puis surtout je doute que cela serve... Par conte, pour ce qui est des nouvelles constantes introduites dans la version CVS, je n'en vois absolument pas l'intérêt :-S. Surtout qu'elles sont assez mauvaises: elles remplacent pour la plupart des classes d'équivalence regexp déjà existantes: [:upper:], [:lower:], [:alnum:]... Je pense qu'en plus elles n'apportent aucune amélioration... -- LordFarquaad
      • Non, car les regexp [:upper:], [:lower:], [:alnum:] sont sensibles à la locale du serveur que nous ne maitrisons pas : ça pose des problèmes parce que selon les locales, ce qui est reconnu, par exemple, comme un mot wiki diffère. -- CharlesNepote
    • Pour le préfixe des tables, il est mis déjà sous forme de variable. Et comme tu le dis toi-même, ça sera utile le jour ou on permettra d'utiliser un seul moteur pour plusieurs sites. Pour les constantes WN_*, je t'invite à lire la page MotWikiAccentue pour comprendre le pourquoi de la chose. Définir des constantes n'était peut-être pas la meilleure solution, mais ça va grandement nous aider dans une première étape de transition. -- ProgFou
      • D'un autre côté, je doute qu'on ait un jour vraiment besoin d'instancier deux wikis utilisant des tables différentes mais bon... L'avantage à partir du moment où on utilise des constantes pour les tables, c'est qu'on peut créer une constante pour chaque nom de table, de sorte d'avoir à simplement utiliser, par exemple TABLE_LINKS plutôt que devoir faire appel au préfixe suivi de "links". Dès lors, en phase de développement, on peut facilement utiliser des tables copiées et modifiées portant un autre nom que celui par défaut. Par exemple si je veux faire des tests sur ma table wikini_links sans vouloir l'endommager, je n'ai qu'à en faire une copie sous le nom que je veux (par exemple links_test) et modifier la valeur de TABLE_LINKS: à la place de define('TABLE_LINKS', PREFIX . 'links'), il suffit de mettre define('TABLE_LINKS', 'links_test') temporairement... (notez que l'idée ne vient pas de moi, c'est aussi une chose tirée de PhpBB2, qui est extrêmement pratique lorsque l'ont veut le combiner avec un autre logiciel dont certaines tables peuvent être communes mais pas toutes)
      • Ah oui sinon, pour les constantes des regexp, je pense qu'à ce moment là il serait pratique d'avoir à disposition une constante dont la valeur serait la regexp des MotWiki, si je ne me trompe elle sert à plusieurs endroits je crois... -- LordFarquaad

Propositions d'évolution ou de nouvelles normes ou recommandations de développement

Adoption d'un standard de codage PHP

• exit;

• exit;

• 1) [fr] : standard de codage que je préfère : sobre, court, produit un code plus concis.
• 1) Convention de codage de pear [fr] : standard semi-officiel de PHP.
• 1) PHP coding standard [en] : volumineux document, sans doute trop exhaustif pour notre cas.

• Mmm je me disais que le premier avait donc été plus moins choisi, mais, constatant qu'il n'était pas du tout appliqué, je l'ai moi-même vaguement appliqué dans les trois fichiers que j'ai modifiés, mais sans plus (en tout cas j'ai respecté les points 1 à 10...). En fait j'ai mon propre standard personnel si je puis dire... Il y a des choses que j'aime bien dans l'eXtrème PHP, mais il y en a d'autres pour lesquelles je préfère le standard semi-officiel... (je n'ai pas lu le volumineux document...). Je pense qu'il serait bon de créer une page de discussion à ce sujet, avec un standard "WikiNi" qui serait une combinaison de ce que les développeurs de WikiNi aiment respecter comme syntaxe. Comme dit dans l'eXtreme PHP (si je me souviens bien), l'important c'est que l'équipe respecte le standard convenu (et non qu'elle respecte un standard existant). Par exemple je pense que Phpbb a son propre "standard" de développement (et ça ne m'étonnerait pas que j'en sois assez proche en fait puisque j'ai fait mes débuts là-dessus :-j). -- LordFarquaad
  • Très bien : cf. DiscussionsNormeDeCodagePHPPourWikiNi. -- CharlesNepote

Discussion préalable de chaque développement

• J'aimerais bien modifier l'ActionInclude et ajouter un attribut et deux-trois méthodes dans la ClasseWiki (sans modifier le fonctionnement général), c'est où l'idéal pour en parler ? (j'aimerais d'ailleurs aussi savoir où se font les appels des méthodes Header et Footer parce qu'à première vue, je ne trouve pas :-S) -- LordFarquaad

Séparation du fond de la forme / balise <div>

• Employer des balises <div> plutôt que des tableaux
• Les problèmes induits par l'utilisation de tableaux sont nombreux quand ils ne sont pas nécessaires. Plusieurs bonnes synthèses ont été publiées à ce sujet :
  • [fr], par Mathieu Pillard : un document incontournable.
  • Why tables for layout is stupid [en], par Bill Merikallio et Adam Pratt : un diaporama très clair et très complet sur la question.
  • [en] sur le wiki de CSS-Discuss, très simple et claire, à travers un exemple didactique.
  • Un exemple de tableau en CSS [fr] par Karl Dubost, qui inspire à Tristan Nitot une "mise au point" [fr] synthétique sur le sujet.
  • Habillage de tableaux avec des CSS, par Pascale Lambert.

Code XHTML clairement décomposé en blocs non indentés

• L'indentation est consommatrice d'octets aussi nous recommandons de ne pas indenter (ni espace, ni tabulations dans le code)
• En revanche, pour améliorer la lisibilité du code et faciliter le débogage de l'application, nous recommandons quelques règes simples :
  • de ne pas hésiter à employer le retour à la ligne quand c'est utile
    • sauf exception, retour à la ligne après chaque balise fermante
  • de décomposer le code en grands blocs structuraux (reconnaissables à une classe de style particulière), séparés par deux lignes vides (par exemple : bloc du nom du wiki, bloc du titre de la page, bloc du menu, bloc du copyright, etc.)
  • les couples de balises restent sur la même ligne si le contenu est toujours assuré de rester sur la même ligne
    • par exemple : <h1 class="wiki_name">WikiNi</h1>
  • les couples de balises encadrent le contenu avec des retours à la ligne si le contenu est susceptible de faire plusieurs lignes
    • par exemple :
      • <div class="copyright">
      • <a href="http://validator.w3.org/check/referer">Valid XHTML 1.0</a> ::
      • <a href="http://jigsaw.w3.org/css-validator/check/referer">Valid CSS</a> ::
      • -- powered by <a href="http://www.wikini.net/wakka.php?wiki=PagePrincipale">WikiNi 0.1.1.0.3</a>
      • </div>

Archives des discussions

Discussion préalable de chaque développement

Ailleurs

• Convention de codage de DotClear [fr]