Extension de la classe Javascript FileMaker.PerformScript

Avec la sortie de FileMaker 19, il devient plus aisé que jamais (c’était déjà très largement possible avant – j’ai eu l’occasion de montrer le « #hash trick » dans quelques conférences 😉 ) de faire communiquer FileMaker et Javascript. Notamment en exécutant du code Javascript dans un Web Viewer grâce au pas de script Exécuter Javascript dans un Web Viewer (FileMaker demande au Web Viewer d’exécuter un Javascript), et à la classe Javascript FileMaker.PerformScript( « Nom du script FileMaker », « Paramètre facultatif » );

Toutefois, il manque à nos yeux quelques possibilités à cette dernière. Nous avons évoqué ici l’impossibilité de reprendre un éventuel script FileMaker qui serait en pause, mais il y a aussi l’absence de possibilité de différencier le script appelé (callback) en fonction du succès ou de l’échec. Cet article développe ce dernier point et apporte une solution.

La programmation asynchrone

Aucune bibliothèque (library) n’est nécessaire, mais j’ai dû écrire ma propre classe qui étend un peu FileMaker.PerformScript à FileMaker.PerformScript ( scriptName, parameter, successCallback, errorCallback ).

Un petit exemple pour faire une interaction bidirectionnelle entre FileMaker et Web Viewer. Il s’agit d’un système de callback et/ou de promesse, une façon dont le Javascript appelle souvent quelque chose de l’extérieur et selon que tout s’est bien passé (succès) ou mal (erreur), vous laissez quelque chose se produire dans votre application Javascript.

En fait, tout se résume donc à cela : « FileMaker, appelle ce script. Si tout s’est bien passé fais ceci, si tout s’est mal passé fais cela ».

Un exemple concret avec une intégration de calendrier : si l’utilisateur change le lieu d’un événement, il doit appeler FileMaker et l’enregistrer dans la base de données. Si cela n’a PAS réussi (par exemple, erreur d’écriture dans l’enregistrement), il faut annuler la transaction et remettre l’événement à son emplacement d’origine pour que l’utilisateur voie qu’il n’a pas été enregistré. C’est ce qu’on appelle la programmation asynchrone, et c’est quelque chose qu’il faut absolument comprendre si vous voulez continuer avec Javascript.

Donc, en dans le calendrier, voici ce qui se passe réellement :

1. L’action en Javascript est appelée, avec immédiatement les actions : que faire si ça va bien, que faire si ça va mal.
2. En interne, ces actions sont enregistrées, et Javascript appelle FileMaker.
3. Le code Javascript ne « tourne » plus, il n’y a plus de pause, nous avons effectivement atteint la fin du code.
4. FileMaker fait son travail et décide s’il veut dire au Web Viewer si cela s’est bien ou mal passé.
5. Le Web Viewer exécute les morceaux de code (enregistrés à l’étape 1).

En code :

#BUSINESS LOGIC
#add as much logic as you want, for instance try to write to a folder

#DEMO: a custom dialog
Show Custom Dialog [ Title: "Choice"; Message: "Was the record saved?"; Default Button: “Yes”, Commit: “No”; Button 2: “No”, Commit: “No” ]

If [ Get ( LastMessageChoice ) = 1 ]
    #we pass success to the callback
    Set Variable [ $result; Value:JSONSetElement ( "" ;
[ "id" ; JSONGetElement ( Get ( ScriptParameter ) ; "id" ) ; JSONString ]; [ "success" ; Get ( LastMessageChoice ) = 1 ; JSONString ]
)]
Else If [ Get ( LastMessageChoice ) = 2 ]
    #we pass error to the callback
    Set Variable [ $result; Value:JSONSetElement ( "" ;
[ "id" ; JSONGetElement ( Get ( ScriptParameter ) ; "id" ) ; JSONString ]; [ "error" ; Get ( LastMessageChoice ) = 2 ; JSONString ]
)]
End If

#RETURN TO WEB VIEWER
Perform JavaScript in Web Viewer [ Object Name: "wv"; Function Name: "fmcallback"; Parameter 1: $result ]

Comme vous le verrez dans l’exemple, j’y ai mis une bibliothèque. Il m’a fallu beaucoup de sueur et de larmes pour que tout cela fonctionne. J’aimerais vous expliquer comment tout cela fonctionne, mais cela se résume à cela :

J’ai un peu élargi le FileMaker.performScript de sorte que vous pouvez maintenant inclure un callback de réussite et un callback d’erreur. Je l’enregistre, puis j’appelle le script FileMaker. J’ajuste un peu le paramètre, parce que j’ajoute un autre « id » et ensuite le paramètre tel que passé.
Voyez cela comme une sorte de « ligne téléphonique sur laquelle le FileMaker peut se rappeler ». Lorsque FileMaker appelle à nouveau le Web Viewer avec cette identification, le Web Viewer sait de quelle action il s’agit.

En fait, le Web Viewer dit à FileMaker : « Bonjour, je suis l’action 23 et je voudrais que tu conserve cet enregistrement ». Après, FileMaker dit au Web Viewer que l’action 23 s’est très bien passée !

Et voici un exemple, jouez avec et s’il y a des questions, n’hésitez pas à les poser ci-dessous ! C’est un concept assez difficile, mais une fois que vous avez maîtrisé la programmation asynchrone, vous désirerez en faire de même dans FileMaker 🙂

Promesses (promise)

Oh oui, pour les irréductibles : cela fonctionne aussi avec les promesses (sur Mac en tout cas, sur Windows pas sûr), donc vous pouvez faire ça aussi :

fm.performScript ( "getData", "" )
    .then ( (data) => {
       //data is script result of getData
       data.sort();
       fm.performScript ( "storeData", data);
     })
    .then ( ( data ) => {
       //data is script result of storeData
       //do things here
    })
    .catch ( ( error ) => {
        //this is the error of getData or storeData, cool isn't it? :)
        alert(error);
 
    })