Autant pour moi, Cyrille vient de m'expliquer un détail que j'avais
raté à propos de l'AJAX(une petite confusion entre AJAX et JS qui
explique la forme employée lors du dev).
Ne pas tenir compte du deuxième point donc. J'imagine que créer un
fichier ajaxcompta.php sur le modèle d'ajaxcountries ou
d'ajaxcompanies serait une bien meilleure démarche.
[email protected] a écrit :
D'accord, je comprend mieux les problèmes. Effectivement, j'avais
constaté l'impossibilité de faire appel à price2num dans le JS, d'oû
les fonction de conversion . et , ainsi que le round JS, pour
mettre en forme les résultats des calculs.
Je viens de me pencher sur la configuration : un petit point ne
serait pas de refus, est-il préférable de rajouter une option de
conf permettant l'activation du JS ou bien de gérer directement avec
la conf de langue de l'utilisateur? Je reprend actuellement la
tâche en partant du principe que j'active le JS par la conf,
cependant je pense qu'il ne devrait pas être trop difficile
d'automatiser sa gestion en fonction de la langue à partir d'une
liste.
Un dernier point, j'ai essayé de prendre connaissance des fonctions
top_htmlhead et associées, je préfererais en effet passer le JS dans
un fichier séparé qu'on remonte dans le header. Une indication sur
la fonction dolibarr a utiliser pour y parvenir ne serait pas de
refus.
"Laurent Destailleur (eldy)" <[email protected]> a écrit :
Le 30/05/2011 17:26, [email protected] a écrit :
Je reviens sur ce post.
// - Does not support non , and non . decimal
separator. Solution is to enable this feature for only some languages.
Je n'ai pas saisi ce que tu voulais dire Laurent. J'avais eesayé
d'implémenter une fonction JS pour gérer les points et les
virgules, si je ne me trompe pas, tu es en train de me dire qu'il
en existe une dans les lib de Dolibarr que je n'utilise pas,
c'est bien ça?
Il en existe une mais en php (la fonction price2num qui réagit
selon la configuration/langue de l'utilisateur).
Mais il n'y en a pas en js malheureusement, d'ou la situation un
peu bloqué pour ce genre de patch pour les langues qui utilisent
un autre séparateur de decimal ou de milliers.
// - Does not use dolibarr param rounding. Solution is
to enable this feature for only some languages.
Ce n'est pas price2num? Si c'est bien le cas, j'ai du faire une
erreur bête quelque part, je suis sûre d'avoir essayé de
l'utilisée pour chaque round...
Si, c'est bien price2num.
Mais en javascript, price2num n'est pas applicable. D'ou la
proposition de rendre le patch actif uniquement pour des langues
listés en dur dont on est sur qu'elle utilisent le séparateur . ou
, (fr_FR, en_US...)
Ainsi on ne bloquerait pas l'éligibilité du patch, car l'appli doit
etre sans faille pour toutes les langues. Mais il est possible
que pour une langue, elle fasse des choses differentes que pour
une autre.
// - Other minor bugs: Using an array in memory is not
a good choice when we resubmit form because a required parameter is
missing, array is empty but value must be empty. Dev should use value
into input fields and should not duplicate values. For example after
submitting form and forget the payment mode, values are no more
synchronized.
Tu veux dire qu'il faudrait utiliser les fonction DOM pour
récupérer les objets des formulaires plutôt que leurs valeurs,
c'est bien ça?
Oui avec jquery.
Et travailler sur les champs meme et non sur des champs cachés ou
dupliqués en mémoire qui se trouve a un moment donné déphasé avec
la valeur dans le champ.
D'une manière générale, le javascript doit etre produit entierement
en jquery car beaucoup moins intrusif dans le code, ce qui évite
de rendre très compliqué des fonctions javascripts d'autant que
dans notre cas on doit avoir du code actif pour certaines langues
mais pas pour d'autres. Aussi un regroupement du code js en tete
de page pour gérer cela facilite cet objectif, et pour cela jquery
est le graal.
En attendant ta réponse, je vais me remmettre dessus, et voir si
je peux faire avancer tout ça.
Cordialement,
Anthony Poiret
"Laurent Destailleur (eldy)" <[email protected]> a écrit :
I tried to include this patch. But i had to comment it with a condition
to disable it because of several problems:
// - Does not support non , and non . decimal
separator. Solution is to enable this feature for only some languages.
// - Does not use dolibarr param rounding. Solution is
to enable this feature for only some languages.
// - Other minor bugs: Using an array in memory is not
a good choice when we resubmit form because a required parameter is
missing, array is empty but value must be empty. Dev should use value
into input fields and should not duplicate values. For example after
submitting form and forget the payment mode, values are no more
synchronized.
Le 09/05/2011 10:46, [email protected] a écrit :
Bonjour à tous,
Vous trouverez ci-joint un patch pour le paiement des factures,
ajoutant sur la page de règlement un champ pour indiquer le
montant d'un paiement, un bouton par facture pour déduire à ce
total le maximum et l'afficher dans le champ associé (le cas
échéant, ce bouton peut déduire un montant négatif au champ en
question). Calcul et affiche également le montant restant à
affecter en fonction du montant payé, sur la ligne de total et
à chaque changement de valeur d'un des champs ajouté ou clic
sur un bouton js.
Autre sujet, M. De Lambert m'a parlé d'une tâche qui
consisterait à donner la possibilité à l'utilisateur de créer
des champs personnalisés. Si vous avez des infos ou des
détails à ce sujet, je suis preneur.
translation:
Hello everyone,
You will find attached a patch for the payment of the bills,
adding the page a field to indicate the amount of any payment,
a button per invoice to infer that the maximum total and
display it in the associated field (If applicable, this button
can deduce a negative amount to the field in question).
Calculation and also displays the remaining amount to be
allocated according to the amount paid on the total line and
at each change in value of an added field or click on a js
button.
Another subject, Mr. Lambert told me about a task would be to
provide an opportunity for the user to create custom fields. If
you have any info or details about it, I'm interested.
Anthony Poiret
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: [email protected]
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: [email protected]
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: [email protected]
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: [email protected]
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: [email protected]
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: [email protected]
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev