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

[address@hidden]

Bonjour Brian et les autres,

> - Il n'y a pas de séparation entre le code et l'interface
>
>  
Effectivement, mais dans ce cas, plutôt que réinventer la roue, le plus 
simple est de réutiliser un gestionnaire de template existant, genre 
smarty (qui est très bien).
Ceci induit une réécriture tellement importante pour un gain certe 
important, mais pas en terme de fonctionnalités. IMHO, va falloir faire 
avec (ou plutôt sans).
Cela dit, il y a un autre problème lié : gérer le multilingue. Ca, c'est 
vachement plus important que mettre des commentaires en anglais pour que 
Doli soit utilisé ailleurs qu'en francophonie.

> - Les différentes fonctions, classes ne sont pas documentés
>  ou en Français..
>
>  
C'est pas beaucoup documenté, mais la structure des fichiers et la 
logique de quoi va ou est facile à comprendre.
Sur la langue, la plupart des noms de classes et fonctions sont en anglais.

> - 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..
>
>  
OOh, une belle séparation entre les requêtes SQL d'un côté et le code 
ailleurs. Je voudrais mettre un peu d'ambiance dans la liste, je te 
dirais que cela pue le Meurise à plein nez et que je croyais que la 
France s'était décidée à se débarasser de cette conception du millénaire 
passé (au moins ;).

M'enfin bon, comme je suis pas comme cela, je te propose un autre 
modèle, plus objet :
une classe de base DoliElement qui contient des méthodes select, get, 
write, update...
et des attributs genre table et les requètes SQL qui vont bien.

Chaque object de Doli (une ligne de facture, un compte bancaire...) 
hérite de DoliElement, défini quelques attributs (genre la table) et 
surcharge éventuellement les méthodes et attributs qu'il faut.

Ton DBA (franchement, vu la complexité des requêtes, c'est du luxe ;) 
peut facilement trouver ton SQL qui est toujours au même endroit dans 
les fichiers et quand tu rajoutes une colonne dans ta table (par 
exemple), t'as pas besoin d'aller modifier des fichiers à gauche à droite
Enfin bon, les gouts et les couleurs... de toute façon, c'est beaucoup 
de boulot pour modifier l'existant et IMHO, c'est pas le plus important. 
Par contre, cela me semble une bonne chose pour les nouvelles 
fonctionnalités. Rodolphe à d'ailleurs commencé à faire des trucs dans 
ce sens (je sais plus dans quel module).

> Maintenant que les critiques sont données, pour qu'elle soient
> constructivent, c'est ma participation que je vous propose.
>
> D'une part pour améliorer l'existant, et aussi parce que je 
> travail actuellement avec Thierry DELAMARE sur un projet qui
> va utiliser Dolibarr. Rodolphe est au courrant.. normalement.
>
>
>  
Super, plus on est, plus ça avance vite

X+