Sujet sur Discussion utilisateur:Eru

Bonjour Eru, ta dernière modification sur le module supposait que args était toujours une table et cela a posé un problème : Wikipédia:Le Bistro/7 avril 2020#Message d'erreur. J'ai fait en sorte que le Module:Infobox/Parlement passe une table comme argument pour que le tout fonctionne ! Il ne reste plus qu'à voir si tu veux adapter quelque chose suite à ta Lua-isation de {{Date de décès}}, mais je pense que cela sera bon. Bonne journée.

Enfin je dis qu'il y avait un problème dans ta modification, mais ma modification n'était peut-être pas la plus propre en 2019 sur le module d'infobox.

Merci, on avait essayer de bien tout tester mais je ne connaissait pas cette usage.

Je vais modifier les bac à sables pour trouvé de quand date l'erreur (23 mars ou avant)

Y a pô de soucis !

Je ne suis pas sûr de comprendre pourquoi cela faisait une erreur, mais tester le paramètre pour ne pas affecter un nil semble la résoudre : diff

J'ai fait une page de test ici : Utilisateur:Eru/Brouillon/Test1

Quand on tente d'accéder à un index 'print(pouet.unTruc)) d'une chaîne de caractères (pouet = "hello"), Lua retourne nil. Par contre, quand on tente de définir une valeur pour un index (pouet.unTruc = "truc") quand la variable est une chaîne de caractères, Lua nous retourne une erreur. Je pense qu'il faudrait directement s'assurer du type de args.

D'accord je comprends mieux, le bon test est donc type( args ) == 'table'. J'ai tout de même laissé les deux tests : diff

J'ai vérifié sur Modèle:Date de décès/Test, je n'ai pas remarqué d'effet de bord.

Oui, pas de soucis comme j'ai dit, c'est sûrement de ma faute !

Bonjour, j'ai vu passer la modif et j'ai quelques observations :

• args n'est pas censé être autre chose qu'une table, car dans le local args = Outils.extractArgs( frame ) plus haut, extractArgs() n'est pas censé recevoir autre chose qu'une frame ou une table, s'il retourne autre chose qu'une table, c'est que frame n'était pas une table ou une frame. Voir notamment cette modif dans le module Outils.
• le args.dateNaissanceMort = params.dateNaissanceMort me gêne, car le principe est normalement de fabriquer une table params, à partir de l'input args. Or là c'est une assignation dans l'autre sens.

Merci pour la précision, c'est donc moi qui ai causé le problème avec une mauvaise pratique lors d'une correction d'un autre problème signalé en 2019. Le pire, c'est que j'avais moi-même cité ce diff du module Outils sur Wikipédia:Questions techniques/semaine 16 2019#Erreur de script concernant le module Infobox/Parlement... Quel boulet.

Je trouve l'approche actuelle assez bazardesque, par exemple :

• la ligne ajoutée elseif type( arg1 ) == 'string' and type( arg2 ) == 'string' and arg3 ~= nil and arg4 == nil and ( arg1:match( '[^ ./-][ ./-]+[^ ./-]' ) or dataLiens[arg3] or mw.ustring.match( arg3, '%a %a' ) ) then est quand même assez monstrueuse
• avec le params.dateNaissanceMort = trim( arg2 ) \n params.qualificatif = trim( arg2 ), forcément l'un des deux est erroné
• une partie de la gestion des paramètres se fait encore dans {{Date de décès}}
• complexification de la méthode modeleDate(), qui s'en passerait bien

Du coup, j'ai esquissé une autre approche : Module:Utilisateur:Od1n/DateDeDécès (attention, ce n'est rien d'autre qu'un brouillon)

avantages :

• support de vraiment toutes les syntaxes
• mieux isolé du code de modeleDate(), pour moins alourdir celui-ci

inconvénients :

• code assurément encore très perfectible
• performances pas optimales, avec grande redondance de parsages/vérifications/découpages/recollages/redécoupages des dates…

Merci pour les précisions, je suis d'accord pour args.dateNaissanceMort = params.dateNaissanceMort, je n'aurai pas dû faire comme cela.

• Pour la ligne ajoutée je suis assez d'accord, mais j'ai essayé de rester au plus près de ce qui existait juste au-dessus.

• Parfois le 2ème argument est la date de décès, parfois c'est le qualificatif...
• Malheureusement oui, j'ai essayé de minimiser les modifications tout en gardant l'usage actuel compatible.
• Affectivement partir sur une nouvelle fonction simplifierai le tout, je n'avais pas pensé à cela.

Je regarderai le fonctionnement du nouveau module ce week-end, pour voir s'il peut être encore amélioré

Rappel pendant que j'y repense, une fois le code du module arrangé, le modèle {{Date de décès-}} serait à mettre aussi à niveau, pour des raisons d'harmonisation codebase et syntaxes.

Pour simplifier les choses je pense que l'on pourrait entièrement ce passé de fun.modeleDate et appeler directement fun._modeleDate depuis fun.modeleDateDeDeces.

Au moins il n'y aurait pas à assurer la compatibilité avec les autres fonctions l'appelant, seulement avec {{Date de décès}} (et {{Date de décès-}}).

Pour info, j'ai réussi à rendre ma sandbox fonctionnelle pour ta page de test :)

Merci, je n'avais pas pris le temps de regarder plus que cela, et je me demandais comment tu l'avais tester :)

Salut,

Tous les tests Modèle:Date de décès/Test ne fonctionnait pas, c'est mieux maintenant, il y a même des âges qui peuvent être calculés maintenant pour les tests 19 à 25 : Utilisateur:Eru/Brouillon/Modèle:Date de décès

Personnellement, je serais d'avis de ne pas supporter ces syntaxes 19 à 25 (mélange syntaxes dates "1 paramètre" et "3|paramètres|s"). Le code est déjà assez complexe pour supporter toutes les syntaxes précédentes (c'est déjà un miracle de pouvoir faire un code sachant différencier, relativement sans trop d'ambiguïtés à gérer, toutes ces syntaxes possibles).

Et je ne suis pas sûr qu'il soit bon d'inciter l'utilisateur à employer l'une de ces syntaxes…

Petite hésitation concernant la syntaxe 22 (pas de mélange syntaxes dates, mais qualificatif intercalé). Pour celle-ci, peut-être, mais à conditions de supporter aussi la syntaxe {{Date de décès|24|2|1993|en sport|23|6|1920}} et que le code ne soit pas beaucoup complexifié.

Je suis plutôt d'accord, c'est d’ailleurs pour ça que j'ai laissé la croix, avant elle ne fonctionnait que partiellement, le qualificatif était ignoré.

Mais là elle provoquait une erreur, il faudrait donc vérifier qu'aucun article ne les utilisent.

Je vais voir si j'arrive à faire des recherches les détectant.

J'ai ajouté le test 22b (qui ne fonctionne pas pour l'instant) pour {{Date de décès|24|2|1993|en sport|23|6|1920}}

Fait !

La syntaxe du test 22 n'est pas utilisée actuellement, je l'ai donc retiré du code.

J'ai également enlevé un test inutile pour {{date de décès|31 décembre 2010||en informatique}}

Les regex utilisés sont indiqués ici Utilisateur:Eru/Brouillon/Modèle:Date de décès#Recherche

Salut,

J'ai appliqué la modification à Module:Date/Bac à sable, {{Date de décès/Bac à sable}} et {{Date de décès-/Bac à sable}}, ainsi que les pages de tests Modèle:Date de décès/Test et Modèle:Date de décès-/Test.

J'ai dû ajouter le parcours de frame.args pour gérer le nolinks=1

Bonjour Od1n et Lofhi , cela fait un mois, peut-on appliquer les modifications ?

Contre pour ma part. Pour avoir écrit ce code, je sais à quel point il est sale. Comme indiqué précédemment, ce n'est rien d'autre qu'un essai, pour voir dans quelle mesure l'approche serait envisageable. Mais en l'état actuel, on ne peut pas passer un truc pareil en production.

Ok, je réfléchirai comment faire autrement quand j'aurais un moment.

L'approche ne me semble pas mauvaise, mais dans quelques "branches" de ce module, il y a de la redondance dans l'interfaçage avec le module Date (en gros, la date est découpée, recollée, re-découpée…). En plus d'être peu performant, c'est un signe manifeste que le code aurait matière à être amélioré. De mémoire, c'est surtout dans le module Date qu'il y avait des changements à réaliser (et pas forcément simples), pour avoir quelque chose de plus "modulaire".

Effectivement, je regarderai pour appeler directement _modeleDate sans passer par modeleDate, cela évitera pas mal de redécoupage.