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 :
- meilleure lisibilité de l'architecture technique de WikiNi : on distingue clairement la classe du coeur
- développement plus facile à suivre : on repère mieux les changements intervenus uniquement sur la classe
- devrait permettre une meilleure modularité de l'architecture technique : il devient en théorie plus facile de créer une ferme de Wiki en ne dupliquant que le coeur (/wakka.php) et le fichier de configuration
- /wakka.php devient plus facile à lire et donc à développer et à déboguer
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,
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 :
- dépendance de WikiNi d'autres classes extérieures au projets
- inflation de la taille du code : ADODB par exemple est très grosse par rapport aux quelques lignes du code de WikiNi relatif aux connexions avec les bdd
- inflation du nombre de fichiers si on externalise chaque classe dans un fichier
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:
- La classe d'accès aux données utilise une librairie genre ADODB
- 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