Il faut se rappeler cependant pourquoi on fait cela : dans un but de clarté, et de rapididité de relecture, quand on revient soi-même sur un développement que l’on a pas touché depuis un an, ou quand un autre développeur veut modifier celui-ci.

Je partage entièerement les grands principes de nommage décrit par FileMaker : utilisation des majuscules, minuscule, des caractères « _ » ou « - »   . Mais sur les rubriques clé (primaires, secondaires…) mon expérience m’a poussé à utiliser une autre politique de nommage. En effet, FileMaker nous conseille d’ajouter les lettres suivantes, z k, p, l, a, t,     etc.. pour non seulement identifier rapidement la rubrique clé en question mais aussi pour  savoir tout de suite comment elle est faite, tout cela sans avoir à aller dans la fenêtre d’edition des rubriques.

Mon expérience m’a plutôt poussé à utiliser le système suivant : une clé commence toujours par « Id« . Si je suis dans la table Factures, la clé primaire de cette table s’appelera tout simplement IdFacture. Toujours dans le même principe, les clé secondaires seront IdClient, IdProjet etc… Le nom me dit tout de suite si je manipule une clé primaire ou secondaire: dans la table Facture, la clé IdClient ne peut être que secondaire, et ainsi de suite….

Quand à vouloir connaitre la nature elle-même de la clé (texte, nombre etc…), pour moi, quand je suis en train de développer un script par exemple, cela ne présente pas beaucoup d’intéret, car les opérations que l’on programme à ce moment là sont essentiellement des copies de valeur d’une table à une autre, et aussi parce que mes clés sont presque essentiellement des clés numériques automatiquement incrémentées.

Le résultat est là, beaucoup simple et lisible, presque « littéraire »:

 Ce fichier fonctionne comme une application indépendante , ou peut-être facilement greffé sur une application déjà existante.

Appliquer ce calendrier sur une de vos application , pour visualiser n’importe quelle table dans laquelle figure des dates par exemple, est très simple. Cela nécessite de construire 1 rubriques supplémentaire et 1 autolien sur la table en question, puis d’importer 1 script et 1 écran 

Ce fichier FileMaker nécessite la version 11 absolument, car il utilise abondamment la fonction de Filtre de table externe.

Le fichier est ouvert, vous avez la possibilité de le modifier et de le compléter selon votre besoin.

Télécharger fichier Calendrier exemple en FileMaker 11

- Utiliser les techniques de développement « agile et léger »
- Privilégier la simplicité (voir mes articles sur les plug-ins, et sur les façons de développer et documenter simplement …)
- Développer de façon modulaire
- Développer de façon standardisée
- Bien distinguer les parties standard à développer et les parties spécifiques au « métier » du client

Si je développe une solution pour répondre à un besoin spécifique, une fonctionnalité, et que cette solution demande un grand script complexe, avec de nombreuses étapes, je me dis que j’ai échoué, et je recommence mes devoirs. Je tourne et retourne le problème dans tous les sens pour construire une solution, La solution élégante, qui ne demande que la construction d’un script simple, et par exemple l’ajout d’une occurence de table dans le graphe des relations.

Pour moi si la solution n’est pas simple, j’ai mal compris le besoin, il me manque une partie du besoin, je n’ai pas compris ni saisi la fonctionnalité dans son ensemble……

(on ne parle pas ici du conseil général que l’on donne quand on développe des scripts qui est de fractionner un script complexe, en plusieurs petits scripts: pour moi c’est pareil, cela restera une solution avec un grand nombre de ligne au total, une solution qui demande plusieurs script ce qui pour moi reste louche tout autant).

À bien y réfléchir, quand je repense à ces dizaines d’applications développés pour une soixantaine de client, je m’aperçois que ce n’est même pas moi qui en décide ainsi, mais bien mon client lui-même.

En effet, dans ma relation-client je vends FileMaker comme un produit permettant la simplicité, la rapidité de développement, l’évolutivité. Dans l’analyse des besoins et la construction de la solution, j’explique exactement à mon client jusqu’ou peux aller la simplicité de FileMaker, je lui montre aussi les limites de FileMaker. Si mon client veut aller plus loin, pour répondre à un besoin particulier, je lui montre quelles en sont les conséquences exactes: coût de licences d’un éventuel plug-in, surcoûts de développement etc… C’est à lui que revient la décision finale.

Pour moi, ajouter un plug-in à une solution, c’est multiplier les coûts de licence comme je l’ai dit, mais c’est aussi multiplier les problèmes d’installation, les interlocuteurs en cas de besoin de support, c’est complexifier mon développement en  y ajoutant un autre « langage », c’est donc aussi complexifier la maintenance de mon application. C’est aussi multiplier les risques de bugs éventuels. Tous ces problèmes, multipliez les par le nombre de plug-in nécessaires à l’application développée.

C’est ce que je pense, et apparemment mes clients pensent la même chose.

Après de nombreuse années passées à modifier des fichiers installés, soit sur mon ordinateur local, et ouvert directement, ou encore sur des fichiers partagés sur un petit réseau et ouvert par une version standard de FileMaker Pro, ou enfin sur des fichiers installés sur une version de FileMaker serveur en bonne et due forme, je peux  conclure que je préfère largement travailler sur un serveur directement.

La raison en est très simple: mon expérience m’a montré que, quand l’ordinateur sur lequel je travaille plante, ou quand FileMaker se ferme inopinéement, je n’ai jamais de corruption de fichier quand celui ci est sur le serveur. Alors que dans les autres cas oui.

Souvent, dans une connexion lente ou qui perd facilement sa connexion , je suis allé changer le graphe des relations sans avoir peur de corrompre mon fichier, même s’il peut m’arriver au moment de la fermeture de la fenêtre, quand FileMaker sauvegarde mes modifications, que je perde la connexion avec le serveur.

Quand je développe et que je documente, ou plutot que je commente mon développement, je pense toujours au développeur qui dans le futur voudrait faire une modification dans l’application que j’ai développé, que ce développeur soit moi-même qui un an après aurait un peu oublié les avenues que j’ai prises à l’époque, ou à tout autre développeur qui ne connaitrait pas mon application.

Le code que j’ai développé ne peut grosso-modo se retrouver que dans 3 endroits principaux: la rubrique avec son graphe des liens, le modèle, ou le script, ainsi, les commentaires insérés systématiquement dans mon code (par les commentaires de script, et  commentaire de rubriques) permettent de saisir rapidement les particularités du code.

Si l’on étudie un exemple simple, une valeur calculée présente dans un champ, celle-ci peut être calculée de plusieurs manières:
-  dans un bouton présent dans un écran (modèle)
- Dans la définition de la rubrique elle-même
- dans un script
- Dans une fonction personnalisé, appelée par un script ou un calcul de rubrique

Tout ceci conduit à une dispersion du code. Cela nous oblige, pour effectuer une maintenance ou une modification, à une recherche et un débroussaillage qui peut être fastidieux et générateur de pertes de temps.

Pour ces raisons, l’expérience et l’habitude m’ont petit à petit pousser à laisser de coté des fonctions comme les menus ou les fonctions personnalisés.

–