Author: Fabrice Nordmann

L’expérience de la formation FileMaker m’a entre autre appris que parmi les nombreuses fonctions de calcul de FileMaker, il en est une qu’il est toujours difficile d’expliquer à une personne n’ayant pas de notions de programmation orientée objet.

Apparue avec la version 9 de FileMaker, la fonction Contenu (Self en anglais), est classée dans les fonctions logiques. C’est une fonction tellement particulière qu’elle a droit à un message d’erreur particulier quand vous l’utilisez dans certaines formules. Toutes les autres fonctions de calcul peuvent être utilisées dans n’importe quelle formule, mais pas celle-ci. Dans la plupart des cas, un message apparaît vous indiquant que vous ne pouvez utiliser cette fonction.

De plus, elle ne prend pas de paramètre, ce qui est assez rare (mais pas unique ! Alea par exemple n’en prend pas non plus)

Au caractère abstrait de cette fonction s’ajoute pour les francophones une difficulté de traduction. Self veut dire “soi-même”, mais on peut en Anglais parler du self d’un tiers (c’est d’ailleurs un concept de psychanalyse inventé par Winnicott).

Plus loin dans l’Histoire de la psychanalyse, Freud parlait du “Moi” (concept très différent mais autre traduction possible de la fonction de calcul – juste pour redescendre un peu. Entre parenthèses le “Moi” freudien est déjà une traduction très controversée de “Ich”, qui signifie littéralement “Je”, qui pour le coup serait une traduction inappropriée de la fonction)

Beaucoup de détours me direz-vous ? Pas tant que ça je crois. Car ces différents concepts (que je ne détaille pas ici mais que rien ne vous empêche d’explorer en suivant les liens) permettent d’approcher la fonction Contenu et ses évolutions. Car oui, vous avez bien lu, à cette complexité conceptuelle s’ajoutent les évolutions de cette fonction, qui est devenu beaucoup plus puissante au fil des versions.

FileMaker 9 : Une référence au contenu

Telle qu’apparue avec FileMaker 9, on peut dire que la traduction française (Contenu) était plus pertinente que la VO (Self). En effet, la fonctionnalité se résumait à peu de chose.

Il n’était alors possible d’utiliser cette fonction que dans deux situations :

• un calcul auto-entré dans les options d’entrée automatique d’une rubrique

• dans la définition du formatage conditionnel

• il est également possible d’utiliser Contenu dans une rubrique calcul, mais très honnêtement nous nous lancerions ici dans une explication à côté de laquelle la psychanalyse serait futile.

Je vous passe le détail de deux bugs qui m’avaient fort énervé (et qui n’ont pas été réglés avec les mises à jour de FileMaker 9 mais seulement en FileMaker 10), mais en gros ils rendaient l’utilisation de Contenu impossible, et dans bien des cas celle du formatage conditionnel également. (Pour les historiens que ça intéresse vraiment, je suis prêt à développer mais le simple fait d’évoquer ces bugs titille mon ulcère)

Donc, si tout avait bien marché, qu’aurions-nous pu faire avec ça dès la version 9 ?

• Modifier une donnée qui vient d’être entrée par l’utilisateur ou lors d’un import. Par exemple on pouvait supprimer les espaces avant et après le texte ainsi : Supprespaces ( Contenu ). Rien de neuf sous le soleil, mais cela permettait d’utiliser la même formule pour nettoyer plusieurs rubriques, alors qu’auparavant ce résultat n’aurait été obtenu que par la formule : Supprespaces ( nomDeLaRubrique ), qui aurait donc été différente d’une rubrique à l’autre.

• Se référer au contenu d’une rubrique (ou d’un objet de modèle) pour le formater. Ainsi on peut, par exemple, colorer une rubrique différemment en fonction de la valeur qu’elle contient. Là encore, l’intérêt est de pouvoir utiliser la même formule pour le formatage de différents objets de modèle. Il y a là un second intérêt qui est que tout objet contenant quelque chose peut éventuellement être formaté en fonction. Petit bémol, seuls peu d’objets peuvent alors être formatés de la sorte. Seuls les éléments de texte et les rubriques sont concernés. Depuis FileMaker 12, les onglets peuvent également être formatés conditionnellement en fonction de leur libellé.

Pour comprendre ces utilisations, il faut se demander qui exécute le calcul, ou plutôt qui demande à l’exécuter. Dans le cas de l’auto-entrée, c’est la rubrique qui demande l’évaluation de la formule afin de définir son propre résultat, Contenu retourne donc le contenu de la rubrique avant l’évaluation du calcul. (Si la rubrique contient 1, alors Contenu + 1 = 2). De même, si l’objet de modèle contient la date du jour (indépendamment de la nature de cet objet, un symbole de modèle, une rubrique de fusion, une rubrique classique…), la formule ObtenirDate ( Contenu )) > Dossier ::dateLimite permettra de formater l’objet si la date limite du dossier est dépassée.

Note : il ne faut pas confondre Contenu et Obtenir ( ContenuRubriqueActive ). Cette dernière fonction renvoie exclusivement le contenu de la rubrique dans laquelle est le curseur, il n’y a pas d’auto-référence induite dans cette fonction.

FileMaker 10 : un pointeur multiple

Avec FileMaker 10, outre le fait que les deux principaux bugs (ceux de l’ulcère) ont été réglés, la fonction a gagné en puissance. Sa traduction (Contenu) est devenue désuète, même si elle n’a pas changé pour ne pas dérouter les quelques utilisateurs qui ne l’étaient pas encore.

Self est désormais porteuse de deux pointeurs. L’un au contenu, comme avant, et l’autre à la rubrique en tant qu’élément de structure de la base de données. (Si vous n’avez rien compris à cette phrase, c’est normal. Moi-même, je ne suis pas très sûr… mais nous sommes en psychanalyse, souvenez-vous…)

Il faut ici rappeler que FileMaker 10 a également apporté deux fonctionnalités majeures et complémentaires : Définir Rubrique par nom (action de script), et ObtenirNomRubrique (fonction de calcul). Vous trouverez de nombreux exemples d’utilisation dans cet excellent article.

Or, si l’on s’amuse à créer une fonction personnalisée (FileMaker Pro Advanced requis) telle que Moi ( _parametre ), avec la formule suivante : ObtenirNomRubrique ( _parametre ), et que l’on utilise cette fonction dans la formule d’un calcul auto-entré d’une rubrique :

Moi ( Contenu )

Que croyez-vous qu’on obtiendra ?

La logique vue précédemment voudrait que Contenu pointe vers le contenu de la rubrique, et le transmette à la fonction qui, essayant d’extraire un nom de rubrique à partir d’un paramètre n’ayant rien à voir avec un nom de rubrique, retournerait un beau point d’interrogation.

Concrètement, si une rubrique MaTable ::MaRubrique contient

“Ça va ? vous suivez toujours ?”

et que la formule d’auto-entrée est

Moi ( Contenu )

on aurait pu penser, puisque la fonction s’appelle contenu, que la fonction Moi évaluerait le calcul :

ObtenirNomRubrique ( “Ça va ? vous suivez toujours ?” )

et qu’elle n’aurait pas su répondre à cette question, car il n’existe pas de rubrique de ce nom.

Or -c’est là que ça devient subtil- le résultat de la fonction sera bien :

MaTable ::MaRubrique

En utilisant la fonction Contenu comme paramètre de la fonction personnalisée, on envoie en fait deux informations de natures différentes : le contenu de la rubrique et l’identité de la rubrique. Selon le traitement effectué ensuite par la fonction personnalisée, l’une ou l’autre de ces informations sera traitée.

En réalité, c’est la fonction ObtenirNomRubrique qui est ici “magique” puisqu’elle traite une autre information que celle qu’on croyait passer. Mais il est remarquable que Self puisse passer cette information.

FileMaker 13 : de nouvelles possibilités

Un petit saut dans le futur, ou plutôt dans mes rêves (c’est une expression, il serait curieux de commencer un article en parlant de psychanalyse et de le terminer en rêvant de FileMaker 13 !)

Self est donc capable de représenter des entités différentes (une rubrique, un objet de modèle), et de référencer des informations de natures différentes (une valeur, un élément de structure de la base de données). Autrement dit cette fonction a de sérieux atouts qui pourraient régler des problèmes que nous rencontrons quand nous développons nos solutions FileMaker.

• référence de l’objet de modèle. A ce jour, il n’est toujours pas possible de connaître le nom de l’objet de modèle ayant déclenché un script, soit qu’il s’agisse d’un déclencheur ou simplement d’un bouton. Si on pouvait passer Self en paramètre de script et dans le script connaître tout de l’objet qui a déclenché le script, ce serait un grand progrès…

• référence de la variable ou de la rubrique que l’on est en train de définir. Par exemple Définir variable [ $i ; Self + 1 ] au lieu de [ $i ; $i + 1 ] ou Définir rubrique [ Commissions ::liste ; Liste ( Self ; “Artichauts” )] au lieu de [ Commissions ::liste ; Liste ( Commissions ::liste ; “Artichauts” )]

C’est tout pour aujourd’hui, notre séance s’arrête là. Ça n’est pas remboursé. 🙂

Avec la sortie de FileMaker 12, la fonction ExecuterSQL permet au développeur FileMaker de formuler des requêtes complexes beaucoup plus facilement qu’avec le graphique des liens et des calculs.

Un autre -immense- avantage des requêtes SQL est qu’elle sont exécutées indépendamment du contexte. Il n’est donc plus nécessaire, dans un script, de multiplier les changements de modèles ou ouvertures de fenêtres, coûteux en temps de chargement et inesthétiques en FileMaker Go ou sous Windows.

Et puis, il y a cet immense avantage par rapport aux plugins : la fonction est compatible avec FileMaker Go !

Tout est pour le mieux donc, mais il existe des limites à cette “magie”.

• la fonction ExecuterSQL est limitée à la requête SELECT, c’est-à-dire que l’on peut lire, mais pas écrire dans la base de données. Cette limite est d’autant moins compréhensible que les plugins ou des clients ODBC sont autorisés à effectuer ces opérations via l’interface sql.
• dans la même veine, on peut regretter l’absence de paramètre nous permettant de préciser à quel fichier FileMaker on s’adresse. Les plugins, ainsi d’ailleurs que les fonctions de conception de FileMaker, peuvent interroger un autre fichier que le fichier actif (à condition qu’il soit ouvert), sans même que le fichier soit référencé par le fichier actif. Ceci est très pratique car cela permet d’éviter des dépendances inutiles. Intéressant par exemple quand on a un fichier embarqué sur un iPhone qui doit régulièrement synchroniser ses informations avec un fichier sur serveur, sans pour autant que l’on souhaite une connexion permanente. Cette absence est d’autant pus surprenante que le nouveau support du protocole URL nous donne une nouvelle arme pour cette communication entre fichiers.
• l’interface SQL travaille sur son propre système d’indexation, ce qui veut dire que la première requête sur une rubrique d’une table comportant beaucoup d’enregistrements va potentiellement prendre plusieurs secondes là où un lien FileMaker aurait donné un résultat immédiat. Fort heureusement, une fois cette première requête effectuée, les opérations seront très rapides. Etrangement, on voit là encore une différence dans les performances, au très net avantage des plugins, notamment du meilleur d’entre eux, DoSQL de myFMbutler.
• le pendant de l’indépendance du contexte, c’est que… ExecuterSQL ne peut pas du tout tirer parti du contexte. On ne peut pas influencer le résultat d’une requête avec le graphique des liens. Mais est-ce vraiment une limite ?
• cela nous mène à la quatrième limite, la plus importante sans doute, parce qu’elle se situe “entre la chaise et le clavier” : la plupart des utilisateurs ou développeurs FileMaker n’ont pas l’habitude de formuler des requêtes SQL. La logique du graphique des liens et des calculs nous a “formatés” et il ne nous est pas forcément évident de tirer profit.

C’est sur cette dernière limite que nous nous penchons aujourd’hui, parce qu’elle semble être la seule sur laquelle nous puissions influencer à court terme.

Car fort heureusement, nous sommes humains (enfin, je ne peux le garantir pour vous, mais en ce qui me concerne, c’est une certitude). Or homo sapiens est très doué pour l’apprentissage, et en particulier avec un sujet aussi “simple” que SQL. Sérieusement, les rudiments de SQL (ceux que l’on utilise pour 95% des requêtes) s’apprennent en quelques minutes. Personnellement, quand je sèche, je regarde ici.

Il existe aussi de nombreux forums dédiés à SQL, où certains ont déjà publié des requêtes compliquées. Ainsi, si je n’ai aucune idée de la manière de sélectionner les factures de 2009 à 2012, regroupées par mois et classée par montant décroissant… je pose ma question littéralement sur Google. Si j’ai la chance de parler l’anglais, je la pose en Anglais pour plus de réponses. Et il est rare que je ne trouve pas une réponse toute faite ou approchant sensiblement.

Mais puisqu’il faut s’y mettre, autant essayer un peu par soi-même. Et vous le verrez, on arrive très vite à quelque chose.

Seulement, au bout de quelques requêtes plus ou moins péniblement formulées, vous vous rendrez compte que :

• le nom des rubriques et des tables est “hard-codé” dans la requête. SQL nous ferait donc perdre l’avantage immense de FileMaker de ne pas avoir à se soucier du nommage ?
• vous utilisez exactement la même requête plusieurs fois, pour des rubriques et des tables différentes. Typiquement, c’est celle-ci : “donne moi la liste du (des) enregistrement(s) dans la table X dans lequel (lesquels) la rubrique Y a le contenu Z. Plus concrètement : “donne-moi tous les ID de mes pots de confiture dont le fruit est Abricot.” Ou au contraire, “donne-moi le fruit du pot de confiture dont l’ID est 348”

Pour pallier à ces deux “problèmes”, qui encore une fois ne viennent pas de la technique mais de nous-mêmes, j’ai publié une fonction personnalisée qui devrait nous aider à nous lancer.

Voici comment l’utiliser :

sql.match ( _requestedFieldName ; _matchFieldName ; _match )

• _requestedFieldName : le nom complet de la rubrique que l’on souhaite obtenir (respectivement potDeConfiture ::ID et potDeConfiture ::fruit dans les exemples précédents)
• _matchFieldName : le nom comple de la rubrique à tester (l’autre rubrique)
• _match : le critère d’égalité (“abricot” ou 348)

Le plus simple est de l’utiliser en combinaison avec la fonction ObtenirNomRubrique, afin de ne pas dépendre du nommage.

Exemple : sql.match( ObtenirNomRubrique ( PotDeConfiture ::ID ) ; ObtenirNomRubrique ( PotDeConfiture ::fruit ) ; "Abricot" )

renverra une liste des ID (séparés par des retours chariot) des Pots de confiture d’abricot

Ah ! un dernier détail. Afin de pouvoir observer la requête effectivement exécutée, une variable $sql.match.query sera déclarée.

Nom de la table Et puis, je ne résiste pas au plaisir de vous signaler cette autre fonction fm.basetable.name. Ceci résout un manque que je trouvais patent depuis de nombreuses années : la possibilité de connaître par calcul le nom de la table représentée par une occurrence de table.

Alors ? on s’y met ? Joyeux SQL à tous !