[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dolibarr-dev] A propos des appels à pri ce2num et price et de la lo
From: |
Jerome Warnier |
Subject: |
Re: [Dolibarr-dev] A propos des appels à pri ce2num et price et de la locale fr_BE |
Date: |
Sat, 06 Sep 2008 09:01:04 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080725) |
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
>