FileMaker : Eviter le « Hard-coding »

Depuis toujours, on est parfois contraint avec FileMaker de « hard-coder », c’est à dire d’insérer en dur et entre guillemets des constantes de texte se rapportant à la structure de la base de donnée.

Par exemple, pour définir un calcul auto-entré en fonction de la rubrique active, on devra écrire :
Si ( Obtenir ( NomRubriqueActive ) = "leNomDeMaRubriqueEnToutesLettres" ; A ; B )
autre exemple célèbre, les listes de valeurs :
ElémentsListesValeurs ( Obtenir ( NomFichier ) ; "leNomDeMaListeEnToutesLettres" )
Ceci est dû à l’absence de fonction permettant d’interroger la structure de la base de données. On ne peut écrire, à la place de la première expression (FileMaker 10 a depuis la publication originale de cet article, introduit la fonction ObtenirNomRubrique, qui rend cette affirmation caduque) :
Si ( Obtenir ( NomRubriqueActive ) = leNomDeLaRubriqueDontJeSuisEnTrainDeDéfinirLeCalcul ; A ; B )
ni, à la place de la seconde :
ElémentsListesValeurs ( Obtenir ( NomFichier ) ; laListeDesBidulesDontJAiOubliéLeNom )
Avec la généralisation de techniques comme l’utilisation de plug-ins pour le déclenchement de scripts -FileMaker boudant décidément la programmation sur événement-, ou des scripts standardisés de navigation comme les LayoutProperties, ce problème a atteint une ampleur critique et touche le nom des scripts et des modèles, et même les occurrences de tables.
Je ne parle même pas de l’API php, qui oblige à TOUT hard-coder, car la technique que je vais vous présenter ne règle pas ce cas. On pourra éventuellement développer l’équivalent pour le côté php.
Mais au fait, quel est vraiment le problème ?
Principalement, le fait de référencer un élément en tant que constante de texte dans un calcul empêche ensuite de modifier le nom de cet élément, à moins d’explorer à fond tout le DDR (Rapport de Structure de Base de Donnée) avant chaque modification.
Imaginons que vous ayez un modèle « Clients_liste », et un script qui active ce modèle en utilisant l’action Activer modèle (nom par calcul) Imaginons qu’au cours de votre développement, ce modèle devienne un format tableau. Vous le renommez fort opportunément « Clients_tableau ». Bien.
Sauf que paf ! votre script ne fonctionne plus (nous partons du principe dans cet article qu’un script qui ne fonctionne plus n’est pas un résultat souhaitable). Avec le temps, votre solution est truffée de choses bizarrement nommées, qui font tout autre chose que ce que leur nom indique, et vous ne vous y retrouvez plus (sans parler de vos éventuels collaborateurs ou de votre client, s’il a accès au code source)
Aussi, vous passez des heures à vous acharner sur un calcul qui ne marche pas, pour finalement vous rendre compte que vous avez fait une petite faute de frappe dans le nom du bidule. Que celui à qui ça n’est jamais arrivé se taise immédiatement, le seul réconfort dans ces situations étant de penser que les autres sont aussi bêtes que nous.

Si j’ai bien travaillé, et même si vous meniez jusqu’à maintenant une vie tranquille, vous êtes maintenant angoissé et vous demandez quels éléments de vos solutions il vous est interdit de renommer.

Non, non, il n’y a pas de quoi, c’est en toute amitié.

Alors nous y voilà, voici la technique promise. Elle tient en une fonction personnalisée, publiée depuis quelques temps sur FMFunctions.com :

FM_Name_ID ( _Name_ID ; _TLFSV ; _fileName ; _layoutName )

Commençons par décrire cette fonction, nous verrons ensuite pourquoi et comment l’utiliser.

Les paramètres sont :

• _Name_ID : on peut y mettre le nom d’un élément ou son identifiant. Prenons par exemple le nom de notre modèle « Clients_Liste » (à ce stade, on ne connaît que son nom)
• _TLFSV : ce paramètre nous servir à dire à la fonction de quoi il s’agit :
  • « Table » ou « T » pour une occurrence de table
  • « Layout » ou « L » pour un modèle
  • « Field » ou « F » pour une rubrique
  • « Script » ou « S » pour un script
  • « ValueList » ou « V » pour une liste de valeurs
• _fileName : le nom du fichier dans lequel cet élément ce trouve. Un paramètre vide («  ») signifie : le fichier courant, Obtenir ( NomFichier )
• _layoutName : ce paramètre ne doit être rempli que si le type est « Field » ou « F ». Là encore, un paramètre vide signifie le modèle courant. (Note : Comme pour les fonctions de Design de FileMaker, ce paramètre prend en fait le nom d’une occurrence de table si elle existe, et le nom du modèle sinon. Par exemple, si vous mettez « Clients » et que vous avez une occurrence de table nommée « Clients », elle sera prise en compte, avec priorité sur un éventuel modèle « Clients ».)

Passons maintenant notre modèle « Clients_Liste » à la moulinette :

FM_Name_ID ( "Clients_Liste" ; "L" ; "" ; "" )

On obtient le résultat 121. Ça ne marche pas chez vous ? vous obtenez 63 ? Mais c’est normal ! L’identifiant du modèle « Clients_Liste » est 121 dans mon fichier, et 63 dans le votre. Mais c’est un identifiant, c’est à dire que son intérêt est qu’il ne changera jamais. Le jour où vous le renommerez « Clients_tableau », il aura toujours l’identifiant 63 (ceux qui pensaient 121 ont besoin de faire une petite pause ;))

Tiens, mais c’est intéressant, ça, un identifiant !

Et si dans le script, au lieu d’appeler mon modèle par son nom, je l’appelais par son identifiant ? mon problème serait réglé ! Il suffit donc de sélectionner, dans l’action de script Activer Modèle, l’option (calcul par ID).

Ah ! on me dit dans l’oreillette que cette option n’existe pas… quel dommage !

Heureusement, notre fonction magique va régler le problème, car elle fonctionne dans les deux sens !

Je sais que mon identifiant est 121 (oui, chez moi, je vous rappelle que c’est 121), je vais donc appeler le modèle avec Activer Modèle (calcul par Nom) avec le calcul suivant :

FM_Name_ID ( 121 ; "L" ; "" ; "" )

Le résultat est… mais oui, vous avez deviné : « Clients_Liste » 
Et dans quelque semaines, il sera « Clients_Tableau » 
Donc mon script fonctionnera tout le temps !

Certains feront sûrement remarquer que FM_Name_ID ( 121 ; « L » ; «  » ; «  » ), ce n’est pas très lisible.

On ne peut pas vraiment leur donner tort.

Une fois de plus, je ne saurais mieux conseiller que de commenter ! Rien ne vous empêche d’écrire :

FM_Name_ID ( 121 ; "L" ; "" ; "" ) // Clients_liste

et le jour où le modèle devient « Clients_tableau », ben ma fois ce n’est pas bien grave. Le commentaire sera suffisant pour comprendre de quoi il s’agit, et on pourra le changer à l’occasion, sans avoir nuit au fonctionnement de la solution.

D’autres feront remarquer (car ils sont très perspicaces, tendance sceptiques), que c’est bien joli d’aller chercher l’identifiant des scripts, modèles, rubriques… mais que cela prend du temps.

Deux choses que vous pouvez faire :

• laisser dans votre Visualiseur de données les formules qui vous permettent d’accéder à l’information rapidement (j’ai par exemple toujours l’identifiant du modèle courant et du script courant sous les yeux.)
• noter les identifiants des éléments pour ne pas avoir besoin de les chercher une deuxième fois. Mais où les noter ? Ben… dans le nom, pardi ! maintenant qu’on peut renommer à coeur joie :). Et comme ce n’est vraiment pas très joli pour les rubriques (Nom_364 et Total_facture_857 ne sont pas très agréables), vous pouvez utiliser la zone de commentaires (au-dessous du nom de la rubrique)

Voilà, c’est tout pour aujourd’hui. J’espère que vous avez apprécié les illustrations ainsi que la musique originale.

Le web en parle

Cet article a été publié en Français dans Le Blog FM, et en Anglais dans FileMaker Advisor (réservé aux abonnés)

Matt Petrowsky a également publié une vidéo dans FileMaker Magazine

Kevin Frank a également écrit un article sur le sujet sur FileMaker Hacks