Re: [Dolibarr-dev] les incohérences

[Régis Houssin]

pour le moment c'est un module externe


Le 09/06/12 10:39, Cyrille de Lambert a écrit :
> Ça, c'est de la fonctionnalité intéressante.
> Ce sera dans le corps ou à coté ?
> 
> 
> Le 09/06/2012 08:29, Régis Houssin a écrit :
>> j'en profite aussi pour dire que j'ai presque finalisé mon module de
>> champs supplémentaire en jquery avec possibilité d'ajouter des champs
>> texte, textarea, liste déroulante, liste déroulante choix multiple, case
>> à cocher, date, etc... tout ça en multilangue et réordonnancement des
>> champs et valeurs de champs sans perdre l'ordre dans les datas et les
>> traductions.
>>
>>
>> Le 09/06/12 08:23, Régis Houssin a écrit :
>>> 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,
>>>
>> Cordialement,
> 
> -- 
> AUGURIA
> Cyrille de Lambert
> address@hidden
> 26 bis rue des olivettes
> 44300 NANTES  Tél : +33 (0) 2 51 13 50 12
> Mobile :+33 (0) 6 29 41 81 22
> Fax : +33 (0) 2 51 13 52 88
> http://www.auguria.net
> 
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> 

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/
---------------------------------------------------------