-------- Message original --------
Il y a bien 7 lignes de codes en plus mais qui corrigent 2 autres bugs
en plus du pb de _javascript_ mal placé, mis en évidence par le test sur
le if _javascript_.
Pour le pb propre à cela d'ailleur, ma correction n'a ni doublé les
appels (L'utilisation du plugin firebug confirme cela), ni le code
d'ailleurs (26 additons - 19 deletions - les 7 qui corrigent les 2
autres bugs de gestion d'erreurs et de message manquant = 0).
Mieux 7 lignes de code en plus et 3 bugs de moins que l'inverse. Je ne
partage donc pas le point de vue du colmatage.
La quantité de code est certes importante à optimiser mais cela ne doit
pas être au détriment de la lisibilité et de la séparation bien marqué
du code "serveur" du code "client". Je pense sincèrement que ma
correction respecte bien ces bonnes pratiques en corrigeant a la fois
plusieurs bugs qui n'avaient pas était identifié (probablement du fait
d'une injection trop massive ou non conditionné de _javascript_), tout en
optimisant la quantité de code.
Le cas cité est donc un parfait exemple que ma position est bien la
bonne: 1 seule ligne de code (if ! _javascript_), donc rien de
contraignant, a certes rendu quelquechose qui semblait fonctionner ko
(d'ou l'enervement), mais c'est pour la bonne cause car ce qui semblait
fonctionner, en fait ne fonctionnait pas malgré les apparences, en
introduisant un bug tres vicieux, tres durs a identifé (et dont le temps
d'identification aurait été bien supérieur a l'ajout de cette ligne): En
remontant les variables dans la fonctions, ces variables ne sont plus
prises en compte dans le cas d'utilisation de la fonction confirm au
sein d'une page elle même issue d'un appel ajax (Un 4eme bug). C'est un
cas rare mais c'est le cas dans le module GED utilisé en mode ajax.
Je cherche une solution pour cet autre bug.
La morale est que tout ce qui est fait coté client (_javascript_) doit se
faire en indépendance de la partie serveur. Car l'utilisation de code
coté client a des conséquences complexes à analyser et source de bugs
très vicieux dont il faut tenir compte et s'armer pour les futurs
diagnostiques (et les actuels).
Le 08/06/2012 21:49, Régis Houssin a écrit :
> ta correction ne fait que doubler les appels, alors que justement
> j'avais corrigé l'appel ajax pour que ca ne se reproduise plus, c'était
> les variables _javascript_ qui était déclarées en dehore de l'appel de la
> box, du coup ce sont elles qui créaient le soucis.
>
> j'ai l'impression qu'on colmate toujours en doublant le code, mais à
> force on perd un temps fou quand il faut modifier un paramètre
>
>
>
> Le 08/06/12 20:40, Laurent Destailleur (eldy) a écrit :
>> Je dirais que dans 100% des cas l'utilisateur choisi _javascript_.
>> Mais l'interet n'est pas la. Le but est d'assuré qu'il y a bien une
>> isolation entre le code coté serveur et coté client et qu'il n'y a pas
>> de code croisé. Du genre un debut d'action qui est mis coté serveur avec
>> une fin coté client.
>> Des tonnes de bugs ont été trouvé/corrigé grace a cela pour un sucrout
>> nul (car c'est un simple if a jouter). Et si cela genere un bug quelque
>> part, c'est qu'il y avait un bug ailleurs, d'ou tout l'interet.
>> Cela garanti aussi une meilleure isolation permettant d'interchanger les
>> technos ou librairies plus facillement (exemple la suppression des lib
>> graphique en _javascript_ faite en 1 heure sur toute l'appli avec garantie
>> de non régression), chose qui aurait été impossible sans cela.
>>
>> L'exemple cité est le bon, il y avait un bug justement sans rapport avec
>> le _javascript_ et c'est cela qui l'a mis en évidence (meme si ma
>> correction récente était incomplete, mais ca c'est une autre histoire).
>> Dopnc avoir des bugs de conceptions majeures qui appraissent au prix
>> d'un simple if a ajouter. Je prend sans hésiter.
>>
>> Etant celui qui assure le plus de correction de bugs (encore 200 juste
>> sur la beta 3.2), je pense être bien placé pour dire que le maintien de
>> la séparation du code de manière rigoureuse fait beaucoup plus gagner de
>> temps qu'en perdre.
>>
>>
>>
>> Le 08/06/2012 16:05, Régis Houssin a écrit :
>>> Bon je persiste et signe
>>>
>>> il faut qu'on fasse un choix soit on s'emmerde avec du "_javascript_" pas
>>> "_javascript_", soit on dit _javascript_ par défaut pour certaines
>>> fonctions, car avoir le choix complexifie inutilement l'application et
>>> dans 99% des cas l'utilisateur choisit _javascript_/ajax
>>>
>>> exemple : avec la dernier snapshot, je veux supprimer un produit il me
>>> le clone après validation. pourquoi ? et bien les connaisseurs regarde
>>> le fichier /product/fiche.php et il comprendront !!
>>>
>>> voilà la condition sur le clonage et la suppression
>>>
>>> if($action="" || $conf->use_javascript_ajax)
>>>
>>> idem pour l'action delete
>>>
>>>
>>> ce qui donne une activation des deux conditions quoi qu'il arrive si on
>>> utilise _javascript_, d'où la dernière condition qui prend le dessus,
>>> c'est à dire le clonage lorsqu'on veut faire un delete.
>>>
>>> bref: JE VOTE POUR UN _javascript_/AJAX PAR DEFAUT !!!
>>>
>>>
>>> Cordialement,
> Cordialement,
--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: address@hidden
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: address@hidden
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
|