Re: [Dolibarr-dev] les incohérences

[Régis Houssin]

dernier coup de gueule du week end ;-)
il faudrait qu'on prenne du temps pour uniformiser à fond les

propale -> propal
projet -> project
contrat -> contract -> contracts
etc...
et j'en passe...

car souvent on a des soucis lorsqu'on veut faire du code commun


Le 09/06/12 11:43, Régis Houssin a écrit :
> 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,
> 

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