Re: [Dolibarr-dev] A propos des appels à price2num et price et de la locale fr_BE

[Yannick Warnier]

Le jeudi 04 septembre 2008 à 23:50 +0200, Eldy a écrit :
> Antoine Delvaux a écrit :
> > 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 ?
> >   
> Il y a du juste et du moins juste.
> Tout est bon sauf que price2num, est une fonction de la couche métier et
> non présentation.
> > 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 !
> >   
> Je me suis attaqué au problème.
> Un gros boulot car le seul moyen de s'en sortir en l'état actuel avec
> fr_BE et que tout soit en fr_BE (PHP, OS, Mysql), ce qui n'est casiment
> jamais le cas surtout mysql qui garde quelquesoit la langue, le "."
> comme séparateur de décimal.
> Autre solution, passer tous les code Dolibarr et ne plus permettre la
> saisie ouverte (droit de saisir un nombre sans le séparateur de milliers
> qui emmerdent tout le monde et utilisation obligatoire de la virgule).
> Hors ceci me parait beaucoup trop contraignant juste pour avoir le droit
> de "voir" des nombres affichées au format Belgique.
> 
> Il y a une solution beaucoup plus simple.
> Prendre la version CVS de la branche DOLIBARR_2_4_BRANCH ou la 2.5 dev
> dans laquelle on a modifié le fichier main.lang de fr_BE et la ligne
> SeparatorThousand=.
> par
> SeparatorThousand=
> 
> On enlève le point.
> 
> Avec cela, tout rentre dans l'ordre, hormis qu'a l'affichage les nombres
> longs n'ont pas de séparateur de milliers "." visibles sur les écrans.
> Mais cela me semble un moindre mal car alors tout rentre dans l'ordre.

Si ça avait été un problème de virgule décimale (pour nous, les belges),
on aurait pu obliger tous les encodages de nombres à se faire en deux
cases séparées, pour éviter d'avoir à taper le séparateur décimal. C'est
ce que font la plupart des banques pour éviter les ennuis.

Yannick