« Initiation au Lua avec Scribunto/Gestion de l'environnement » : différence entre les versions

Contenu supprimé Contenu ajouté
m Robot : Remplacement de texte automatisé (- d'utiliser + d’utiliser )
m Robot : Remplacement de texte automatisé (- d'éviter + d’éviter ); changements de type cosmétique
Ligne 61 :
==== Gestion programmée de l'erreur ====
 
Comment remédier à ce problème ? Il nous suffit simplement d'éviterd’éviter que la variable poids soit comparée à un nombre lorsqu'elle contient '''nil''' et que dans ce cas la fonction nous retourne un message d'erreur informant l'utilisatrice de l'erreur qu'elle a commise. Nous devons donc encore perfectionner notre programme en écrivant une nouvelle fonction '''p.alerte5''' qui met en œuvre ce que l’on vient de dire :
 
<syntaxhighlight lang="lua">
Ligne 108 :
Une autre façon de gérer les erreurs pouvant se produire à l'appel d'une fonction est d’utiliser la fonction '''pcall''' dont le rôle est justement de gérer les erreurs à l'appel d'une fonction. Il suffit d'invoquer la fonction en lui donnant comme paramètres : le nom de la fonction, ses paramètres et le message d'erreur s'il y a problème.
 
Pour tester cette fonction écrivons, dans le [[moduleModule:Balance]] une nouvelle fonction p.alerte6 ainsi :
 
<syntaxhighlight lang="lua">
Ligne 274 :
Il est, bien sût, indispensable que les objets que l’on souhaite récupérer ne soient pas déclarés en local.
 
Prenons un exemple : Dans le [[moduleModule:Fonction]], nous avions écrit une fonction '''f''' qui élève un nombre au carré. Dans un autre [[moduleModule:Aspire]], essayons d'y inclure le module Fonction et de créer une fonction '''carre''' qui appelle la fonction '''f''' pour élever un nombre au carré :
 
<syntaxhighlight lang="lua">
Ligne 303 :
C'est un peu comme si l’on souhaitait utiliser la commande '''#invoke''' à partir d'un autre module. Mais cette commande ne marche pas si elle est utilisée dans un module. Nous allons donc transférer le contenu de la table '''p''' dans une table locale au module appelant.
 
Prenons un exemple : Dans un [[moduleModule:Ingère]] écrivons une fonction '''compo''' qui appelle la fonction '''p.cube''' se trouvant dans le [[moduleModule:Réservoir]]
 
Le contenu du module Réservoir est :
Ligne 356 :
== Priorité de l'interpréteur ==
 
En général, l'endroit le plus adéquat pour appeler un module est de le faire à partie d'un modèle. Ceci est fortement conseillé pour éviter de surcharger l'espace principal avec la commande '''#invoke'''. Par conséquent, le plus souvent, les modèles appelleront les modules. Quelquefois, on risque de devoir faire le contraire. C'est-à-dire d'appeler un modèle dans un module. Que se passe-t-il alors ? Nous allons tester cette opération en prenant un exemple. Essayons d'écrire un module qui aurait pour fonction d'encadrer un texte en faisant appel au [[modèleModèle:Encadre]]. Dans un [[moduleModule:Cadre]], nous serions tenté d'écrire une fonction '''p.cadre1''' ainsi :
 
<syntaxhighlight lang="lua">
Ligne 376 :
Et là, avec un grand désarroi, nous constatons que cela ne marche pas. Que s'est-il passé ? En fait, l'interpréteur de mediawiki évalue les modèles avant d’avoir les retours des modules. Et, par conséquent, quand le module Cadre nous ramène <nowiki>{{Encadre|contenu=Coucou, je suis dans un cadre!}}</nowiki>, il est déjà trop tard !
 
Heureusement, la situation n'est pas désespérée car nous disposons, dans notre lua avec scribunto, d'une fonction préprogrammée '''frame:preprocess''' qui va évaluer les modèles avant que ceux-ci ne soient retournés. Pour expérimenter cela, nous allons donc écrire, dans le [[moduleModule:Cadre]], une nouvelle fonction '''p.cadre2''', ainsi :
 
<syntaxhighlight lang="lua">