[Dolibarr-dev] A propos des appels à price2num et price et de l a locale fr_BE

[Antoine Delvaux]

Bonjour à tous,


Comme signalé dans un des articles sur la nouvelle version, depuis ma MAJ vers
la v2.4-final (j'étais à la beta6), j'ai rencontré quelques difficultés pour le
calcul des prix des factures (prix des lignes, reste à payer, etc.).  J'ai
résumé cela dans le bug #24143
http://savannah.nongnu.org/bugs/?24143  C'est bien entendu le bug de la locale
'fr_BE'

Le problème est que cette locale a comme séparateur de millier le '.' (point) et
la ',' (virgule) pour les décimales.  J'avais donc proposé un premier patch pour
la fonction price2num (voir savannah).

Cependant, suite à ce patch, d'autres problèmes en cascade surviennent.  Je
pense que beaucoup d'appels à price2num() à divers endroits du code ne devraient
pas être fait.  Il ne me semblent pas respecter la séparation des couches
logique métier et présentation.  Du moins, selon mon analyse.

Un exemple.  Lors de l'ajout d'une ligne de facture, dans le fichier
compta/facture.php on reçoit ou bien le id_prod, ou bien le montant donné par
l'utilisateur.  Dans le premier cas, le montant du produit est pris de la BD,
dans le second, il est donné par l'utilisateur.  Ensuite, on fait appel à
facture::addline avec ces montants.

Dans addline() on trouve des appels à price2num(), ainsi que dans
calcul_total_price() et facture::insert(), autre fonctions et méthodes appelées
par addline().  Pour moi, la fonction price2num() fait partie de la couche
présentation, alors que les autres sont dans la logique métier.  Il me semble
donc que leur utilisation ne devrait pas être mélangées.  D'ailleurs, lorsque
addline() est appelée pour un produit existant, les montants sortent de la BD et
on ne doit alors pas faire appel à price2num, alors que pour un produit définit
à la volée, il le faut.  Je pense qu'il serait plus approprié d'avoir les appels
à price2num dans facture.php uniquement.

N'ayant pas encore une vue complète de l'architecture de Dolibarr, je soumets
cette analyse à votre critique, semble-t-elle correcte ?

Seulement, la solution n'est pas simple, car les appels à price2num() colorent
très fort le code.  J'ai pour le moment contourné le problème, en commentant le
code récupérant le séparateur des milliers de la locale,  L'autre solution est
d'utiliser la locale 'fr_FR' mais aucune des 2 n'est une solution durable.

Bref, qu'en pensez-vous ?  Si je m'attaque au problème, quel chemin me
préconisez-vous ?  Merci pour vos avis !

Antoine.