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

[Brian FRAVAL]

Le 10/09/03 à 15:48, R. Quiedeville a écrit:
> 
> 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é.

200 fichiers c'est un peu abusé.. Mais je comprend ta philosophie,
même si je ne la partage pas. Je préfère utiliser des méthodes de
dev propres dès le départ.. Une fois que ces méthodes sont maîtrisées
tu programmes aussi vite.

Bien entendu, il faut prendre le temps de maîtriser ces méthodes et 
je comprend que tu voulais sortir rapidement lolix et dolibarr.

> Quand au Francais je ne vois pas ou est le problème ?

Cela permettrait à des développeurs non francophone de 
participer plus facilement au projet. Mais sur ce point
c'est un peu faite ce que je dis... mais pas ce que je fais..

Je suis null en anglais..
 
> > - 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.

Ha je n'ai pas vue le fichier qui contient les constantes,
je vais chercher.. quoi find va chercher.

 
> > - 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 ?
> 

Je peux t'en procurer... je travail actuellement sur des applications
qui incluent des fichiers qui ont un nombre de ligne impressionnantes :

A chaque requete, il y a plus de 7 fichiers inclus, voici le nombre 
de ligne de chaque fichier. 
3244 lignes
4541 lignes
2188 lignes
496  lignes
65   lignes
354  lignes
58   lignes

Quand je suis arrivé sur les dev de ces applications, j'ai alluciné,
surtout que c'était encore en PHP3. Depuis la migration en PHP4, la
charge des serveurs a baissé, mais les machines non jamais été 
chargées par les applications PHP et c'est pas des ferraris..

> 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.

hitweb

> 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

Ok merci pour ces infos.

-- 
Brian FRAVAL
address@hidden
http://brian.fraval.org/