Discussion module:Outils

Typo

Hello,
ligne 135 (de mémoire) tu écris : local nom = mw.loadData( 'Module:Outil/Data' ).ordinal. Sauf qu'il manque le s à Outils . Cordialement, Hexasoft (discuter) 16 septembre 2013 à 15:21 (CEST)

J'ai tendance à toujours mettre un s à tournoi, même au singulier, et jamais à outil, même au pluriel. Plus généralement je suis fâché avec l'orthographe, les correcteurs ça aide, mais c'est pas parfait, et ça ne corrige pas le code lua .

Initialement j'avais donc programmé ce module avec le nom Outil. J'ai du oublier de modifier l'une des occurrences. Je corrige ça.

Zebulon84 (discuter) 16 septembre 2013 à 17:16 (CEST)

Héhé, ça nous arrive à tous .

Note : tu peux éventuellement utiliser la fonction nombre2texte() pour tes ordinaux : la fonction supporte tous les ordinaux entre -999999999999 et 999999999999. Il faut juste lui passer une frame valide, ou (ce serait plus intéressant) que j'extrais la fonction et que celle exportée soit juste un wrapper (afin de pouvoir l'utiliser sans créer une frame valide depuis un autre module). Après avoir lu ton code j'ai ajouté le paramètre "genre", et si vraiment tu aimes le perfectionnisme je supporte même l'orthographe pré/post 1990 et les particularismes belges et suisses (septante, huitante/octante, nonante) . Hexasoft (discuter) 16 septembre 2013 à 18:45 (CEST)

Voilà : la fonction Outils.nombre2texte_reel(pnombre, ptype, porthographe, pgenre, pmajuscule) est utilisable depuis un module. Les paramètres sont dans l'ordre :

• pnombre : le nombre à traduite (string)
• ptype : ordinal ou nil (cardinal)
• porthographe : réformée ou nil (avant 1990)
• pgenre : féminin ou nil (masculin)
• pmajuscule : oui ou nil (pas de majuscule à la première lettre)

Hexasoft (discuter) 16 septembre 2013 à 20:46 (CEST)

Il y avait plus simple pour ces dernières modifs :

local args = Outils.extractArgs( frame )

récupère dans l'ordre :

• Les paramètres de l'objet frame transmis à #invoke:
• Les paramètres de frame.getParent() transmis au modèle si aucun argument n'est transmis par #invoke
• Les paramètres de la table frame (sans .args) si frame.getParent n'existe pas
• Les paramètres transmis si le premier n'est pas une table (bien sur dans ce cas les paramètres ne sont pas nommé, donc il aurait fallu une petite adaptation pour l'utilisé ici).

Demain j'adapterai ordinal pour utiliser ta fonction.

Zebulon84 (discuter) 16 septembre 2013 à 23:52 (CEST)

Ah ! Pratique ça ! D'une manière générale une fonction "créer frame" ciblée est bien pratique pour ces fonctions qui peuvent à la fois être appelée par un modèle et directement. Bon, là dodo. Hexasoft (discuter) 17 septembre 2013 à 00:10 (CEST)

Tu as utilisé le bon prototype ! Car j'ai fait une faute ci-dessus : les paramètres sont pnombre, plangue, ptype, porthographe, pgenre, pmajuscule, pordinal (j'avais oublié le paramètre "langue").

En fait pour les paramètres venant de frame c'est un peu compliqué : pour certains paramètres je prends ceux de pframe (par exemple le nombre à convertir vient forcément du modèle appelant) et pour certains autres paramètres je prends celui venant du #invoke s'il existe ou celui du modèle sinon (ça permet par exemple de faire des modèles qui fixent une option sans qu'on puisse la modifier depuis l'appel au modèle, comme par exemple dans {{ordinal3}} qui force "type=ordinal"). On peut faire ça facilement ? Hexasoft (discuter) 17 septembre 2013 à 09:38 (CEST)

Oui, Si le(s) paramètre(s) principal(aux) (1 par défaut, ou ceux dont le nom est fournis après frame) n'est pas dan frame.agrs, je prend frame.frame.getParent() et j'y copie les paramètres de frame.args, qui ont donc toujours priorité. J'ai copié le comportement de coord en fait. Le seul but de tester les paramètres principaux est de ne pas accéder à getParent( ) si ce n'est pas nécessaire.

Je suis en train de tester ouvrage, article et lienWeb. Quand j'aurais fini je ferait une doc pour les différents modules notamment celui-ci.

Zebulon84 (discuter) 17 septembre 2013 à 12:57 (CEST)

J'ai déplacé les fonctions nombre2texte et ordinal (ainsi que leurs dépendances) vers un nouveau module Nombre2texte, afin que Module:Outils ne devienne pas un fourre-tout ;-) od†n ↗^blah 29 septembre 2017 à 15:50 (CEST)

espaces insécables dans les paramètres de modèle

Salut !

J'espère que le problème vient bien de là et que je ne me suis pas complètement planté d'endroit...

En fait, je viens rapporter cette discussion. Apparemment, le modèle {{article}} plante si un espace insécable   est mis avant la barre verticale | au lieu d'un espace classique.

Merci Zebulon84 ! (Car j'imagine que c'est toi qui saura le mieux répondre...)

--Pols12 (discuter) 20 mars 2015 à 16:03 (CET)

 Pols12 : pour être exact, dans cet exemple c'est l'espace après la barre verticale qui est un espace insécable.

Il faut comprendre que pour un informaticien, l'espace insécable est un caractère complètement différent de l'espace. Si au lieu d'écrire {{Article | langue = en |...}} j'écris {{Article |Xlangue = en |...}}, cela ne surprend personne que la langue ne s'affiche pas. Pour Mediawiki l'espace insécable est géré comme si c'était une lettre quelconque et non un espace. Ce n'est donc pas le même paramètre.

Si on veux que dans le cas des paramètres de modèle l'espace insécable soit considérer comme un espace, il faut en faire la demande sur Phabricator. Mais je doute que ce soit pris en compte.

Les solutions locales que l'on pourrait mettre en place pour éviter ce problème sont lourdes et à l'encontre de l'esprit dans lequel Mediawiki gère les paramètres, donc je me refuse à les envisager.

Zebulon84 (discuter) 20 mars 2015 à 16:49 (CET)

 Zebulon84 : Donc il s'agit d'un problème interne à MediaWiki. J'avais la flemme de tester, j'aurais dû le faire avant de poster ici... Désolé.

Mais si je comprend bien, alors ça fait appelle à un paramètre  titre. N'est-il pas possible de mettre  titre en alias de la même manière que title est un alias ?

Bon, c'est vrai que ça alourdit le bazar, mais bon...

Merci de ta réponse en tous cas ! --Pols12 (discuter) 20 mars 2015 à 17:05 (CET)

L'espace insécable pourrait aussi être après le nom du paramètre, avant le égal, donc il faudrait aussi créer les alias titre  et  titre , donc multiplier par 4 tous les paramètres ; c'est ce que j'apelle une solution lourde oui. d'autant que l'espace insécable disparait si on fait un copier-collé sous firefox, donc il y a des chance que la solution soit cassé régulièrement lors de modification (car il faut un vrai espace insécable et non sont code html   pour que cette solution marche)...

Pour info, le modèle {{ouvrage}} avec ses alias actuel à plus de 150 paramètres, donc si on multiplie par 4 on arrive à 500

Zebulon84 (discuter) 20 mars 2015 à 17:17 (CET)

Utilisation de notEmpty() ?

Bonjour,

Comment fait-on pour se servir de notEmpty() ? Le résultat obtenu n'est pas du tout ce à quoi je m'attendais :

{{#invoke:Outils |notEmpty | | 2 }} → table

--NicoV (discuter) 17 avril 2015 à 15:35 (CEST)

 NicoV : il me semble que cette fonction n'est pas faite pour être appelée directement : elle prend ses paramètres sous forme "lua" et non sous forme d'appel (en recevant un frame et en accédant à son contenu). La table que tu reçois est sans doute comme ça qu'est perçue la frame qui lui est transmise.

Il faut soit trouver une fonction qui fait l'appel soit la faire. Tu sais faire ? Je peux le faire, c'est pas compliqué, si besoin. Cordialement, Hexasoft (discuter) 17 avril 2015 à 17:52 (CEST)

Merci Hexasoft, si ça ne te dérange pas, je veux bien que tu la fasses . --NicoV (discuter) 17 avril 2015 à 18:25 (CEST)

 NicoV : J'ai regardé entre-temps. Le but de cette fonction me semble un peu trop « compliqué » pour ton besoin. J'ai fait une petite fonction traitant ça. Tu peux voir le résultat au tout début de Utilisateur:Hexasoft/test (regarde le code).

La question c'est de savoir si ça sera appelé directement avec un #invoke où s'il faut prévoir le cas d'un modèle (ça change la façon de traiter les paramètres).

On pourrait ajouter dans le module Outils une fonction de non « premierNonVide » ou quelque chose du genre. Cordialement, Hexasoft (discuter) 17 avril 2015 à 18:29 (CEST)

 Hexasoft :, mon besoin vient de Discussion Projet:Modèle#Première valeur non vide parmi une liste de valeurs ?, l'idée est de pouvoir l’appeler dans un modèle, la première valeur étant le résultat d'une requête à un autre modèle, la deuxième valeur étant une valeur par défaut au cas où le premier résultat est vide. --NicoV (discuter) 17 avril 2015 à 18:56 (CEST)

 NicoV : oui j'avais vu (mais préféré répondre ici, puisque c'est plus spécifique). En fait ma question est de savoir si tu veux appeler un modèle comme dans ton exemple → |{{Première valeur|(…), ou bien si tu veux appeler un module directement → {{#invoke:Outils|premiereValeur|(…).

Le premier choix est plus habituel pour les modélistes, et nécessiterait la création du modèle intermédiaire ainsi qu'une légère modification du code du module. Le second choix est un poil plus performant puisqu'on esquive un appel de modèle intermédiaire (qui ne sert qu'à appeler le module, sans valeur ajouté) mais sans doute moins lisible pour qui n'a pas l'habitude.

C'est comme tu veux .

Est-ce que toutefois le comportement indiqué correspond à tes attentes ? Cordialement, Hexasoft (discuter) 17 avril 2015 à 19:04 (CEST)

 Hexasoft : Merci pour les explications, le second choix m'irait très bien, appeler directement le module dans le code du modèle {{Projet:Communes de France/Mise à jour automatique des données démographiques/Tableau Population Commune}}. --NicoV (discuter) 17 avril 2015 à 19:25 (CEST) PS: le comportement me va très bien

←
C'est fait. La fonction s'appelle premiereValeur (sans l'accent, on ne peut pas sur les noms de fonction).
Pour l'appeler dans un modèle : {{#invoke:Outils|premiereValeur|param1|param2|…}}. Quelques exemples :

• {{#invoke:Outils|premiereValeur|param1|param2|param3}} donne param1
• {{#invoke:Outils|premiereValeur||param2|param3}} donne param2
• {{#invoke:Outils|premiereValeur| ||param3}} donne param3

Cordialement, Hexasoft (discuter) 17 avril 2015 à 19:49 (CEST)

Remarque qui peut être importante : retourne le paramètre non vide passé par trim(), c'est-à-dire après suppression des espaces au début et à la fin du paramètre. Par exemple si le premier paramètre non vide est " x " il va retourne "x".

Si c'est un problème pour toi je peux supprimer ce comportement, mais ça m'a paru logique. Cordialement, Hexasoft (discuter) 17 avril 2015 à 20:00 (CEST)

Merci Hexasoft, je l’ai utilisé sur 2 modèles pour l'instant, ça marche très bien. --NicoV (discuter) 17 avril 2015 à 22:07 (CEST)

Les 2 modèles évoqués par NicoV sont Projet:Communes de France/Mise à jour automatique des données démographiques/Tableau Population et Projet:Communes de France/Mise à jour automatique des données démographiques/Tableau Population Commune. Vous remarquerez que j'ai supprimé l'utilisation de la fonction Lua dans ces modèles. Par volonté de simplifier la base de code Lua, je viens de supprimer cette fonction qui n'est maintenant plus utilisée. od†n ↗^blah 27 septembre 2017 à 02:26 (CEST)

Fonction extractArgs()

Je me suis penché sur cette méthode, car actuellement la boucle for k,v in pairs( frame.args ) modifie directement les valeurs sur la table frame:getParent().args, et comme en Lua les tables sont des objets, transmis par référence et non par valeur, je craignais que la méthode ait pour effet de bord de modifier la table args de la frame parent, ce qui aurait pu engendrer des bugs dans les codes lisant cette table après avoir exécuté extractArgs().

Bonne nouvelle, frame:getParent() fabrique en fait un nouvel objet frame à chaque appel (code), donc uniquement le args de cette instance est modifié, et les autres utilisations de la frame parente ne sont pas impactées.

En revanche, la table retournée par ce extractArgs() est assez particulière… Il s'agit de la table "frame.args" (voir mw:Extension:Scribunto/Lua reference manual#frame.args) issue de la frame parente, qui est une table vide, sur laquelle on accède aux valeurs via des métaméthodes (code), mais à laquelle on a ajouté les valeurs de la table "frame.args" de la frame directe, auxquelles on accède "classiquement" (sans recourir aux métaméthodes)…

Du coup, j'y trouve divers inconvénients :

• Comme pour les tables "frame.args" habituelles, on n'a pas l'opérateur # (nombre d'éléments), la possibilité d'utiliser les méthodes table.*, etc.
  • Pire, comme en fait les valeurs de la frame directe sont présentes "classiquement", on peut utiliser # et les méthodes "table", mais cela ne prendra en compte que les valeurs de la frame directe… d'où la possibilité de bugs bien sournois.
  • Même chose avec pairs() et ipairs(), qui étant redéfinis en métaméthodes, ne prendront en compte que les valeurs de la frame parente cette fois…

od†n ↗^blah 30 novembre 2021 à 05:15 (CET)

Différentes possibilités que je vois :

1. Garder le code actuel.
   • Avantages : Après tout, personne ne s'en est plaint jusqu'à présent et il est fonctionnel pour accéder par index aux valeurs.
   • Inconvénients : Les inconvénients exposés ci-dessus, notamment il n'est fonctionnel que pour accéder par index aux valeurs (pas d'itération, etc.)
2. Utiliser une méthode corrigée : extractArgsGreedy() dans Module:Bac à sable/Outils.
   • Avantages : Corrige tous les problèmes mentionnés. Le code est très simple. On dispose d'une vraie table, que l'on peut donc utiliser avec grande souplesse (itération, méthodes table, etc.).
   • Inconvénients : Toutes les valeurs sont récupérées en amont, et la récupération d'une valeur serait apparemment une opération coûteuse.
3. Utiliser une méthode lazy : extractArgsLazy() dans Module:Bac à sable/Outils.
   • Avantages : Par rapport au code actuel, les valeurs de la frame directe sont récupérées de manière lazy, donc uniformité avec la manière dont les valeurs de la frame parente sont gérées.
   • Inconvénients : Mêmes inconvénients que le code actuel, seul l'accès par index aux valeurs est fonctionnel. Code déjà plus complexe (mais rien de méchant non plus).
4. Utiliser le code de en:Module:Arguments (que d'ailleurs nous avons aussi déjà ici : Module:Arguments).
   • Avantages : Code qui semble avoir été conçu justement pour répondre aux présentes problématiques.
   • Inconvénients : Code extrêmement complexe. En même temps il semble stable depuis 2015. Mais franchement, c'est une sacrée usine que l'on ne peut pas se mettre à utiliser sans en avoir décortiqué le fonctionnement, vérifié les performances, etc.

Pour ma part, je pencherais pour la solution 2 (méthode extractArgsGreedy()), parce qu'elle est simple, avec de nombreux avantages, et si on part du principe que tous les arguments (ou presque) passés au modèle/module seront de toute façon utilisés par le module, cela invalide l'utilité de recourir à une méthode lazy pour accéder aux valeurs.

od†n ↗^blah 4 décembre 2021 à 07:55 (CET)

Bonjour,

Je suis d'accord, extractArgsGreedy est le plus simple et fait bien le job, la plupart des modules utilisent tous les arguments.

Cependant le # doit rarement servir sur args et je suppose que parfois tous les arguments ne sont pas utilisés (je pensais que Module:Bases serait concerné mais après vérification ce n'est pas le cas), donc l'on pourrai proposer extractArgsLazy comme alternatif en le documentant bien (je ne connaissais pas setmetatable).

La documentation de Module:Arguments aurait besoin d'une traduction, mais pour l'instant je n'ai pas envie d'attraper un mal de tête :) — eru ^[Discuter] 4 décembre 2021 à 23:01 (CET)

Et voici, un problème rencontré à cause de cette itération problématique : 197304353 (discussion). od†n ↗^blah 28 septembre 2022 à 04:04 (CEST)