dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] A propos des appels à pric e2num et price et de la lo


From: Eldy
Subject: Re: [Dolibarr-dev] A propos des appels à pric e2num et price et de la locale fr_BE
Date: Thu, 04 Sep 2008 23:50:38 +0200
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

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.

> Antoine.
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>   


-- 
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Author) : http://awstats.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net
Dolibarr (Contributor) : http://www.dolibarr.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]