Wikini

DiscussionsArchitectureTechniqueDeWikiNi

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-34-231-21-123.compute-1.amazonaws.com

Proposition 1 : séparer la classe "wiki" du reste du fichier wakka.php

La séparation de la classe "wiki" dans un autre fichier que wakka.php présente plusieurs intérêts :

Le seul inconvénient que j'y vois c'est l'utilisation d'un fichier supplémentaire qui doit très très légèrement jouer sur les performances.
Qu'en pensez-vous ? Je sais que ProgFou est partant sur le principe (pour en avoir discuté avec lui sur Jabber).

Mise en oeuvre


Solution 1

Je propose un fichier wikini.class.php placé dans la racine du site.

Solution 2

On peut aussi créer un répertoire _classes où l'on placera non seulement wikini.class.php mais éventuellement d'autres classes.

Pour le moment ma préférence va à la solution 1, plus simple. S'il n'y a pas d'objection, j'intègrerait dans le CVS lundi 28 mars.
-- CharlesNepote

Solution 3

J'irais plus loins encore. La classe wiki est très monolitique et il faudrait l'éclater en plusieurs classes. Nous aurions alors une modularité très importante pour l'application. Par exemple, une classe d'accès à la base de données permet de changer de SGBD et il est tout a fait envisageable d'utiliser une librairie existane comme ADODB par exemple. Autre exemple, une classe de gestion de l'utilisateur permettrait par exemple de changer le processus d'authentification en utilisant une identification via LDAP ou autre. Dans ces 2 exemples, une classe à changer sans risque d'impact sur le reste de l'application.
Je sais que c'est beaucoup de travail, mais si on commence à revoir l'architecture de WikiNi, autant le faire correctement. --GarfieldFR

Pour le moment, je n'ai pas d'avis sur la question d'une ou plusieurs classes ; je trouve cela séduisant, mais j'ai aussi certaines craintes :
Mais là n'est pas seulement le fond du problème. Le développement de WikiNi avance très lentement, notamment du fait que peu de personnes ont beaucoup de temps à consacrer à des modifications lourdes. Je préfère donc la technique des "petits pas" qui, certe, ne permet que des sauts de puce, mais à l'avantage de pouvoir être mis en oeuvre facilement et faire progressivement avancer le schmillblick. Dans un premier temps, je reste donc attaché à la solution 1, s'il n'y a pas d'objections, celle-ci n'étant pas antinomique avec les solutions 2 ou 3.
-- CharlesNepote

Je comprend tes réticences vis à vis de l'utilisation d'une librairie externe mais nous pouvons très bien cacher cette librairie derrière une classe d'accès au données. Nous aurions donc 2 schémas:
  1. La classe d'accès aux données utilise une librairie genre ADODB
  2. La classe d'accès aux données accède directement à la base de données.
L'avantage est de pouvoir avoir un code léger dans un cas mais uniquement reservé à une base de données ou alors un code plus lourd mais avec la possibilité de changer de base de données.
A mon avis, nous n'arriverons jamais à passer à un WikiNi avec plusieurs objets par petit pas car cela implique un changement profond de l'architecture du projet. Il y aura forcement un moment ou il faudra tout casser. J'avais dans l'idée de faire une architecture du type MVC (Model-View-Controller) qui propose l'avantage de pouvoir facilement étendre les possibilitées de l'application. --GarfieldFr
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]