Wikini

DiscussionsNormesEtRecoDeDeveloppement

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-52-91-54-203.compute-1.amazonaws.com
Nous suggérons ici quelques normes et recommandations argumentées pour le développement de WikiNi.


Du code XHTML conforme

La consultation de la norme est nécessaire mais parfois un peu fastidieuse. Par souci d'efficacité, l'application des trois règles suivantes permettra un code conforme dans la plupart des cas (source "Tutoriel : se mettre aux standards du web" (Laurent Jouanneau)) :
Enfin, il est recommandé de valider son code à l'aide du lien "XHTML 1.0 valide ?". Si vous utilisez Mozilla ou Firefox, vous pouvez également valider à l'aide de l'extension Tidy [en].


Séparation du fond de la forme

On consultera la page DiscussionsNormeDeCodageCSSPourWikiNi pour ce qui est de la mise en forme du code des feuilles de style CSS.
J'ajouterais que, dans l'idéal, il faut proscrire du XHtml tout attribut destiné à modifier l'apparence de l'élément (hormis les classes et identifiants bien sûr !) puisque que c'est le rôle des feuilles de styles. -- JmPhilippe


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

Il est recommandé d'utiliser des entités SGML à la place des caractères accentués (par exemple & acute; pour "é").

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

Sauf excpetions, les accès directs à la base de données ne sont effectués que dans la classe principale et nulle part ailleurs.
Et en utilisant uniquement les méthode Query(), LoadSingle?() ou LoadAll?(), sans accès direct ailleurs.


Requêtes sur le minimum d'expressions



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

Pour éviter que wakka.php n'enfle démesuremment, privilégier l'appel direct à la base de données par un LoadAll? ou un LoadSingle? (comme dans lastusers, listpages) et éviter de créer une méthode dans wakka.php qui a peu de chances d'être mutualisée (comme dans orphanedpages).
[Totalement d'accord : je pense que toute nouvelle méthode devrait faire l'objet d'une petite discution préalable entre nous avant d'être développée -- CharlesNepote]


Utiliser des constantes quand c'est possible



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



Adoption d'un standard de codage PHP

Les sources actuelles de WikiNi mélangent plusieurs standards de codage PHP différents. Il n'est pas rare de voir dans le même source :

if (a=b)
{
}
else {
}

Je propose donc de fixer un standard de codage. J'ai trouvé :
-- CharlesNepote
D'accord sur le principe, ma préférence est pour le premier, à utiliser en conjonction avec un truc comme beautifer [en] (non testé) -- DavidDelon

Discussion préalable de chaque développement

Il est utile que chaque nouveau développement soit discuté préalablement à sa mise en oeuvre (sauf s'il s'agit d'un "module" de type "action" n'ayant aucun impact sur les autres fichiers).

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


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


Par exemple, la page :




deviendrait :




-- CharlesNepote

Note : merci ProgFou pour tes remarques ; je n'ai toujours pas eu d'avis sur la question... sans avis de votre part avant vendredi 9/01, je passe cette proposition comme recommandation puiqu'elle est actuellement appliquée. -- CharlesNepote


Archives des discussions


Discussion préalable de chaque développement

Je propose comme nouvelle norme de développement que chaque nouveau développement soit un minimum discuté préalablement à sa mise en oeuvre (sauf s'il s'agit d'un "module" de type "action" n'ayant aucun impact sur les autres fichiers.
-- CharlesNepote
Ok -- DavidDelon
Il me semble que c'est ce que nous faisons déjà quand on discute des nouveaux développements dans les suggestions etc... -- PatrickPaul
Grosso modo oui, mais ce n'est peut-être pas inutile de se le dire : ça permet de voir que nous sommes d'accord sur la façon de travailler et ça permet de communiquer plus facilement aux futurs nouveaux milliers de développeurs quelques règles simples. Par ailleurs, je pense que certaines options actuelles n'ont pas été suffisament discutées (par exemple le choix (heureux) d'harmoniser les sens des diff, le changement de "wakka" pour "wiki" (pourquoi wiki et pourquoi pas "action" ou je ne sais quoi d'autre), l'internationalisation, etc.). Je ne pense pas qu'il soit nécessaire d'arriver un système de décision lourd (genre vote ou autre) ; je pense qu'il ne faut pas brider non plus la vitalité du développement (et à cette occasion je tire mon chapeau à PatrickPaul qui n'a pas chômé ces derniers temps) ; je pense que c'est à chacun de juger si le sujet mérite d'être plus ou moins longuement discuté. Par exemple pour l'internationalisation et le choix du nom, ce sont deux choix importants et qui "engagent" le projet dans des voies dont il ne sera pas facile de revenir : c'est la raison pour laquelle j'ai essayé de temporiser un peu les deux discussions et demandé de re-réfléchir un peu (j'attends d'ailleurs toujours d'autres avis sur l'internationalisation). -- CharlesNepote
Comme je l'ai précisé a Patrick lors d'un chat improvisé, la modification de wakka en wiki dans l'url, m'a fait pester, sur le moment.
Il est vrai qu'on en avait discuté (abandon du nom wakka dans le code ...) mais cet aspect là n'avait pas été evoqué. Ce qui est fait est fait et bien fait finalement, d'autant plus que cela m'a permis de voir quelques bugs qui trainaient par ailleurs et c'est un bon entrainement pour un futur changement de nom ! Pour le sens des diff, cela fait parti de la liste des bugs et je remercie PatrickPaul pour sa réactivité, et ne veut surtout pas le brider dans son développement. A mon avis le meilleur compromis est de retenir la solution que propose CharlesNepote : un minimum de consensus pour une action impliquant l'ensemble du projet, la portée de l'action étant estimée par chacun en ame et conscience ;-).
-- DavidDelon

Je pense que nous sommes tous d'accord. Je précise aussi que m'on idée derrière la répartition des taches est justement de permettre d'alléger la prise de décision. Par exemple lorsque d'autres développeurs voudront joindre leurs efforts ils pourront s'adresser plus directement à l'un d'entre nous pour de nouveaux développements.
Je précise aussi que j'ai pensé aux même choses que David, à savoir que si nous voulons rechanger de nom nous savons maintenant ce que cela implique et comment assurer la transition le plus en douceur possible.
Pour l'instant je trouve que tout ce passe très bien, et je pense que David est de mon avis (d'après ce qu'il m'a dit sur le chat).
--PatrickPaul

Je vois aussi que nous sommes globalement d'accord. Je pense également que tout ce passe bien et que le projet prend joliement forme avec d'inévitables petits soucis de détail ; l'important c'est de pouvoir s'en parler. -- CharlesNepote



Ailleurs


Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]