Re: [Dolibarr-dev] les incohérences

[Régis Houssin]

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