Re: [Dolibarr-dev] les incohérences

[Régis Houssin]

je ne vois pas dans quel cas tu aurais un soucis si on met les
paramètres dans la fonction, à ce que j'ai compris c'est dans ta
tentative d'inclure du jquery dans la GED ?

je t'avais déjà dit que j'avais fait un module gérant l'arborescence
avec possibilité de copier/coller, déplacer, créer fichier, supprimer,
renommer etc.. tout ça avec menu et/ou clique droit sur le rep ou le fichier





Le 08/06/12 23:03, Laurent Destailleur (eldy) a écrit :
> 
> 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=clone || $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,
> 

Cordialement,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------