|
Ç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="" || $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, --
| ||||
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
