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

[Jerome Warnier]

Yannick Warnier wrote:
> 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.
>   
Et c'est particulièrement casse-pieds pour l'encodage, d'ailleurs.
> Yannick
>