json script

Analyse automatique d’un paramètre de script JSON

analyser automatiquement un paramètre de script JSON

Depuis FileMaker 16, de nombreux développeurs utilisent les fonctions JSON pour transmettre des paramètres et des résultats de script, ce qui peut s’avérer très pratique pour transmettre plusieurs paramètres à la fois. Cependant, il peut être fastidieux d’écrire de nombreuses étapes de script « Définir une variable » juste pour extraire les valeurs du paramètre de script.

Cet article de blog vous montrera comment utiliser une fonction personnalisée pour analyser automatiquement les valeurs d’un paramètre de script JSON et définir des variables.

Voici à quoi ressemble un paramètre de script JSON typique :

Dans cet exemple, nous avons 6 paires clé-valeur que nous souhaitons transmettre à un script en tant que paramètres. Traditionnellement, pour extraire ces valeurs, nous utiliserions plusieurs Définir une variable étapes de script, chacune utilisant la fonction JSONGetElement pour récupérer la valeur de chaque clé.

J’utilise la même convention de nommage pour mes clés JSON et mes variables. Ainsi, lorsque j’analyse des valeurs JSON pour définir des variables, je nomme généralement mes variables de la même manière que leurs clés correspondantes.

Pourquoi pas des indices ?

Si j’utilise toujours mes clés pour nommer les variables, puis-je automatiser cette opération afin de ne pas avoir à tout taper ? Comment automatiser la définition des variables ?

Créer un sous-script est la première idée qui vient à l’esprit ; nous pouvons facilement parcourir toutes les clés d’un objet JSON à l’aide de l’étape de script « Loop », puis utiliser « Set Variable » pour analyser les valeurs, mais compte tenu de ce que nous savons sur la portée des variables, ces variables sont locales au sous-script, ce qui signifie que mon script parent n’y aura pas accès. Donc non, nous ne pouvons pas utiliser un sous-script pour analyser les variables que nous avons l’intention d’utiliser dans notre script parent.

Pourquoi ne pas utiliser des variables globales ?

Par mesure de bonne pratique, nous devrions réduire au minimum le nombre de variables globales, car il est facile de les utiliser dans un contexte inapproprié et de provoquer des problèmes. Si vous n’êtes pas familier avec la portée des variables, nous avons créé une vidéo sur ce sujet.

Utilisation des fonctions While (), Let () et Evaluate ()

Outre l’étape de script « Définir une variable », que pouvons-nous utiliser d’autre pour définir des variables ?

Nous pouvons utiliser les fonctions Let () et While () pour définir des variables, y compris des variables locales. Dans ce cas, nous devons utiliser les deux. J’ai besoin de la fonction While () pour la boucle et de la fonction Let () pour créer la variable. Si vous ne connaissez pas bien la fonction While (), nous avons également une vidéo à ce sujet.

Nous savons donc désormais comment créer des boucles et définir des variables à l’aide de fonctions dans le cadre du script actuel. Comment rendre le nom de la variable dynamique ?

La réponse est la fonction Evaluate (), qui évalue l’expression qui lui est fournie. Nous allons construire dynamiquement des fonctions Let () à partir des données du paramètre de script JSON, puis utiliser la fonction Evaluate sur ces expressions pour créer des variables de manière dynamique. Attention toutefois : soyez prudent lorsque vous utilisez la fonction Evaluate. C’est un excellent moyen d’ajouter une couche d’abstraction à votre solution ; assurez-vous de bien comprendre ce que vous faites.

Créons la fonction. Je vais d’abord la créer dans le Data Viewer afin de faciliter les tests et le débogage.

Nous allons commencer par une fonction While (). Pour le premier paramètre, nous devons initialiser certaines variables. Nous savons que nous avons besoin du paramètre script, je vais donc définir une variable pour cela. Ensuite, je dois savoir sur quoi porte la boucle. Dans ce cas, je parcours les clés du JSON, je dois donc lister toutes les clés à l’aide de la fonction JSONListKeys.

Nous devons compter le nombre de clés afin de savoir quand nous arrêter. Comme notre condition de boucle est basée sur le nombre de clés, nous devons disposer d’un compteur de boucle. Ici, par habitude, je nomme mon compteur de boucle i.

Ensuite, la condition de la boucle. Dans quelles circonstances la boucle doit-elle continuer à s’exécuter ? Pour nous, tant qu’il reste des clés à évaluer, la boucle doit s’exécuter. La condition doit donc s’exécuter si i est inférieur ou égal au nombre total de clés.

De plus, nous souhaitons ajouter une autre condition sur l’entrée JSON pour nous assurer qu’elle n’est pas vide.

Vient ensuite le paramètre Logic. Nous allons commencer par récupérer la clé de la boucle actuelle. Ici, je vérifie que la clé existe à l’aide d’une fonction personnalisée de Todd Geist. Et bien sûr, après avoir récupéré la clé, nous voulons également récupérer la valeur. Nous utilisons donc ici JSONGetElement pour extraire la valeur.

C’est là que la magie opère ! À quoi voulons-nous que notre fonction Let () ressemble ? Elle devrait être très simple : nous définissons une variable locale dans le premier paramètre. Comme nous n’avons pas besoin qu’elle renvoie quoi que ce soit, le deuxième paramètre peut simplement être une chaîne vide. Si tel est notre objectif, l’expression devrait ressembler à ceci :

Une fois notre expression définie, nous pouvons utiliser la fonction Evaluate pour créer la variable. Nous pourrions modifier cette partie afin qu’au lieu de construire une fonction Let par boucle, elle construise une grande fonction Let qui définit toutes les variables en une seule fois, mais nous n’aborderons pas cette technique dans cet article.

Bien sûr, comme la condition de la boucle dépend du compteur de boucle, nous devons incrémenter ce dernier d’une unité, sinon nous nous retrouverons dans une boucle infinie. C’est en gros la seule logique dont nous avons besoin.

Résultats

Voyons maintenant le résultat. J’ai créé un fichier de démonstration pour vous montrer cela en pratique. Il comporte un champ « Paramètre de script » et deux boutons.

Le script associé au bouton « Méthode traditionnelle » analyse chaque paramètre un par un à l’aide de la fonction JSONGetElement(), comme indiqué ci-dessous :

Alors que le script associé au bouton « Fonction personnalisée » utilise la fonction personnalisée que nous avons créée précédemment pour analyser différents paramètres en une seule fois :

Si j’utilise les données suivantes, les deux analyseront chaque paramètre avec des résultats identiques.

Les deux entraînent la création du même ensemble de variables.

Cependant, si j’ajoute une paire clé-valeur supplémentaire pour le genre, comme illustré ci-dessous :

La méthode traditionnelle renverra exactement le même résultat que la dernière fois, car elle ne peut pas analyser ce paramètre supplémentaire sans être mise à jour par une autre étape de script « Définir une variable ».

Mais pour la méthode de la fonction personnalisée, comme elle est dynamique et pilotée par les données, elle analysera automatiquement ce paramètre supplémentaire, comme indiqué ci-dessous.

Considérations d’utilisation

En combinant les fonctions While (), Let () et Evaluate (), nous pouvons analyser dynamiquement des objets JSON. Je m’en suis servi pour analyser les paramètres de script, mais vous pouvez bien sûr l’utiliser pour analyser d’autres résultats JSON, par exemple les résultats de requêtes adressées à des services web ou des API.

Gardez à l’esprit qu’en définissant des variables locales à l’aide d’une fonction Let (), il est moins évident pour les autres développeurs de savoir où ces variables sont définies ; veillez donc à la lisibilité du code.

Il peut y avoir des situations où vous souhaitez analyser uniquement des valeurs spécifiques plutôt que toutes les valeurs. Dans ce cas, la méthode traditionnelle vous offrira plus de contrôle.

Nous abordons également ce sujet sur notre chaîne YouTube.

Si vous avez des questions sur la manière d’analyser automatiquement un paramètre de script JSON, n’hésitez pas à nous contacter !


*Cet article a été initialement rédigé pour AppWorks, qui a depuis rejoint Direct Impact Solutions. Cet article est publié à titre informatif uniquement. À notre connaissance, ces informations sont exactes à la date de publication.

Retour en haut