Re: [Dolibarr-dev] Presentation / Critiques / Participation

[R. Quiedeville]

le Wed, 10 Sep 2003 15:07:30 +0200
Brian FRAVAL <address@hidden> a écrit :
> Salut à tous,
> Cela fait un petit bout de temps que je suis le projet
> Dolibarr avec beaucoup d'intérêt, je lis réguièrement
> les mails des listes de discussions, 
> address@hidden et
> address@hidden depuis la version 0.3.0 du 24/07/2003.

Bonjour,

Cela fait toujours plaisir de voir que l'on s'intéresse à ce que l'on
fait.

[...]

> J'ai quelques critiques à faire, à propos essentiellement
> des sources du projet, notamment parce que je trouve que 
> l'application ne respect pas certaines règles qui me semble
> importantes lors du développement d'un logiciels libres.
> 
> 
> - Il n'y a pas de séparation entre le code et l'interface
> 
> Actuellement il est possible de changer les CSS, mais il n'y 
> pas du tout de séparation entre les sources PHP et l'interface 
> HTML.
> 
> Je sais que ce point est discutable, notamment parce que
> l'avènement du PHP tiens essentiellement, depuis ses débuts,
> à la possibilité de mélanger les tags HTML et le code PHP.
> 
> Mais la séparation complète de l'interface et du code PHP,
> facilite l'internalisation de l'application. Actuellement 
> ceci n'est pas du tout mis en place.

Tout d'abord je crois que pour bien appréhendez ce point quelques
eclaircissements historiques sont nécessaires. Dolibarr dans sa forme
actuel est un fork de la partie admin du projet lolix que j'avais écris
à l'époque pour gérer la facturation et les propales. A cette époque
j'étais le seul à utiliser cet outil, et la priorité était la
fonctionnalité de l'outil et aucunement la beauté de la chose. Point
sur lequel je suis souvent en désacord avec pas mal de monde, mais je
préfère un code sale et fonctionnel qu'un projet magnifique qui
marchera peut-être dans 6 mois. J'ai lus pas mal de code d'autres
projets PHP qui codent "à la C", il ne faut pas oublier non plus que
ce n'est pas du compilé que l'on fait et inclure 200 fichiers pour
séparer l'interface du code est néfaste pour la vitesse d'exécution et
désastreux lors de la montée en charge.

Toutefois depuis le fork beaucoup d'effort on été fait dans ce sens
(apparition des classes), mais la structure du code reste en priorité
moindre par rapport aux nouvelles fonctionnalités. Alors oui la
séparation de l'interface et du code est idéale, mais ce n'est pas la
priorité, l'axe de développement reste fonctionnalité+rapidité.

> - Les différentes fonctions, classes ne sont pas documentés ou en
> Français..

La doc, la doc, oui on en manque, on fait un peu d'effort mais comme
tous les dev on préfère passer 2 heures à coder qu'une demi-heure plus
une heure et demie de doc. Quand au Francais je ne vois pas ou est le
problème ?

> Mais j'ai lu que c'est un point sur lequel vous avancez.
> 
> 
> Sinon j'ai quelques petites remarques qui n'ont rien à voir
> avec le développement de logiciels libres, mais qui permet 
> de gagner beaucoup de temps lors du développement.
> 
> - Il serait bien d'utiliser des constantes et de faire le ménage
> par exemple, pour n'utiliser que .php comme extension de fichier.

Cette effort de nommage a commencer, j'ai déjà renommer tous les
index.php3 en index.php pour simplifier la conf d'Apache, je suis
surpris que cela t'ai échappé ;-) Et dolibarr utilise aujourd'hui une
cinquantaine de constantes.

> - Personnellement je stocke dans un fichier toutes les fonctions
> avec les requetes SQL, cela est notamment très utile dans un
> environnement professionnel, avec des DBA de la mort qui optimisent
> les requetes... De plus cela permet d'allèger les sources et donc de
> rendre plus lisible de code pour les développeurs qui viendront se
> gréffer au projet..

Donc tu inclus à chaque requète un fichier qui contient toutes les
requetes SQL pour n'en utiliser qu'une partie infime à chaque fois,
cela a un intéret pour les DBA, mais en terme de perf cela me parait
un peu dangeureux non. As-tu des retours d'experience et des mesures
de perf qui validerait l'interet d'une telle méthode ?

> Exemple : avec utilisation de PEAR/DB qui vous utilisez : function
> getNumVote() { global $db;
> 
>   $sql = "SELECT SUM(VOTE_NB) FROM ".PREFIX_TABLE.TBL_VOTE."";
>   
>   $res = $db->getOne($sql);
>   
>   errorSql($res, $sql, "getNumVote");
>   
>   return $res;
> }
> ...
> autre requete
> ..
> 
> Maintenant que les critiques sont données, pour qu'elle soient
> constructivent, c'est ma participation que je vous propose.

Tes critiques sont constructives et je t'en remercie, ta participation
est acceptée avec grand plaisir, je suppose que tu as un login sur
Savannah ? Transmets le moi et je t'ajouterais aux membres du projet
tu pourras écrire dans le CVS.

Tu trouveras aussi un channel IRC #dolibarr sur le réseau Freenode, on
y utilise le bot CIA qui permet de voir passer en temps réel les CVS
commit, c'est trés pratique. Je t'invite aussi si ce n'est déjà fait à
t'inscrire à la ML dolibarr-cvs


[...]

-- 
Rodolphe Quiedeville
 Artisan Logiciel Libre - http://rodolphe.quiedeville.org/
      Travaillons Libre - http://fr.lolix.org/
Réseau Libre Entreprise - http://www.libre-entreprise.com/