1-more-thing

Category: Blog

  • Un point de vue sur “le cloud”

    Un point de vue sur “le cloud”

    La planète informatique s’affole, on ne parle plus que de ça dans les services IT ou dans les PME. La sortie imminente d’iCloud -la version d’Apple du “nuage”- provoque un buzz incroyable… bref, vous avez déjà sans doute tout lu ou tout entendu au sujet du cloud.

    Pourtant, en tant que chef d’entreprise -et donc d’utilisateur du nuage- mais également en tant que consultant susceptible de conseiller mes clients dans leurs choix technologiques, j’ai pensé que mon point de vue sur la question pouvait vous intéresser.

    Comme vous l’avez sans doute déjà compris dans le discours ambiant, si vous n’êtes pas utilisateur du nuage, vous êtes has been. Votre entreprise se dirige vers une faillite certaine… c’est l’évidence.

    Ah bon ?

    Ce type de discours est tellement stéréotypé, que sans présager de son inexactitude, il me semble prudent de me demander de qui il émane.

    Or, c’est amusant, je retrouve les mêmes type de discours à propos du nuage que ceux que j’entendais à la fin des années 90 sur “la nouvelle économie”. L’aveuglement de ceux qui les professaient comme de ceux qui les écoutaient devant mener à la constitution puis à l’explosion de “la bulle Internet”.

    Si les discours sur le nuage ressemblent à ceux de l’époque, c’est qu’ils viennent parfois des mêmes auteurs. Aux Etats-Unis, on les appelle des “évangélistes”. Le terme en soi devrait nous appeler à la plus grande méfiance.

    Que l’on s’entende bien : ce qui va suivre dans cet article est un discours dissonant, critique. Mais ne sautez pas à la conclusion que je ne verrais rien d’intéressant dans le nuage. Comme vous allez le voir, un minimum de sens critique peut nous permettre d’utiliser le nuage à bon escient.

    Durant la “bulle Internet”, tout le monde était numéro un mondial dans son secteur… et tout ce qu’on savait faire était programmer un vague site web avec une ergonomie acceptable et, grand luxe, une interface vers une base de données. Peu importait qu’on n’ait jamais eu d’expérience de la logistique pour s’improviser supermarché en ligne, qu’on n’ait aucune expérience du recrutement pour constituer une plateforme sur l’emploi, qu’on n’ait jamais regardé autre chose que son écran pour lancer son business de tirage de photos…

    C’était la “nouvelle économie”, le monde allait marcher comme ça, et tout ce beau monde “levait” des millions pour des startup qui n’avaient oublié qu’un détail : en économie -même “nouvelle” !-, les entreprises doivent générer des richesses.

    Ceux qui faisaient valoir un point de vue critique étaient inévitablement taxés de passéistes peu dignes d’intérêt.

    Le discours dominant sur le cloud est à peu de chose près aussi irrationnel.

    Comme à l’époque, ces fanatiques -j’ose le mot !- sont éblouis par ce qui n’est en réalité qu’un effet de bord. Il est exact que les services proposés par des acteurs majeurs tels que Google ou Apple offrent des fonctionnalités très intéressantes. Celui qui n’a jamais créé un “spreadsheet” (feuille de calcul) sur Google Documents ou équivalent ne peut se rendre compte des avantages que cela représente par rapport à un document Excel résidant sur le disque dur d’un poste de travail.

    Il est exact que cela rend le partage d’informations, et donc la collaboration, extrêmement faciles. Plus besoin de s’envoyer le document Excel, de devoir attendre les modifications de notre interlocuteur avant de pouvoir modifier à nouveau. Plus d’e-mails oubliés ou de mélange de versions de documents.

    Ces possibilités sont perçues comme déterminantes dans l’économie d’aujourd’hui, où les décideurs sont de plus en plus mobiles, où la vitesse à laquelle l’information peut être centralisée et analysée est un facteur clef de réussite, et enfin où Windows a perdu son monopole, notamment à cause (ou grâce) à la spectaculaire remontée du Mac, mais bien davantage encore à l’explosion des smart phones et des tablettes (iPhone, iPad, Android, BlackBerry, Windows Mobile…)

    Déterminantes, elles le sont. Je n’en disconviens pas. Mais ceci ne doit pas occulter les changements fondamentaux qu’entraîne un recours massif aux services du cloud.

    La première conséquence, notamment pour les entreprises, c’est la relocalisation de leurs données. Jusqu’à récemment et encore aujourd’hui, les entreprises prenaient en charge elles-mêmes le stockage, les sauvegardes et la sécurité de leurs données. Un autre avantage du cloud est d’ailleurs d’alléger la facture, notamment en réduisant l’investissement nécessaire pour maintenir des serveurs à jour. Mais attention : les grands acteurs des clouds publics ne peuvent garantir la localisation des données, c’est-à-dire que vous ne savez pas du tout où elles se trouvent. Elles sont même dans certains cas réparties sur des serveurs différents, aux quatre coins de la planète. (J’espère malgré tout que vous les retrouverez plus facilement que les coins du globe…)

    Rien ne dit que la note que vous avez prise sur votre iPhone afin de la retrouver sur votre PC n’est pas entre temps stockée en Chine ou dans une autre contrée.

    Or les lois sur la protection des données ne sont pas les mêmes, loin s’en faut, selon les pays.

    Par exemple, 100% des données stockées sur le service iCloud d’Apple seront localisées aux Etats-Unis, et donc soumises au Patriot Act, Ce qui veut dire qu’elles peuvent être réquisitionnées à tout moment par les autorités américaines. Si j’insiste sur le cas d’Apple, c’est qu’iCloud va sortir dans quelques jours, mais la situation avec Office 365 de Microsoft n’est nullement différente.

    Pire, les sociétés américaines sont susceptible de transmettre l’information que vous leur auriez confiée, y compris si leurs serveurs sont situés en Europe !

    Après tout, si vous avez cru à la nouvelle économie et à ses éléphants roses, pourquoi ne pas croire que l’administration américaine (ou une autre disposant de prérogatives équivalentes ou supérieures) ne fera jamais usage de vos données ?

    Plus immédiatement, la confidentialité est également mise à mal par les conditions générales des services concernés, qui fluctuent à chaque modification du service. Quelle est la PME dont le service juridique a le temps de lire et d’analyser ces dizaines de pages de ces conditions à chaque fois ? Je n’en connais pas. Or la confidentialité (privacy) est une notion en pleine évolution, et entamée par les déclarations régulières de dirigeants du cloud (notamment Mark Zuckerberg pour FaceBook, ou Eric Schmidt pour Google), et donc soumise de manière régulière à des interprétations changeantes exprimées dans ces contrats.

    Il convient désormais de remonter à la question première : le cloud, qu’est-ce que c’est ?

    Le cloud (nuage en français), c’est justement l’idée que les données sont décentralisées, et accessibles par le biais d’une connexion internet, à l’aide d’un logiciel dit client léger, le plus souvent un simple navigateur web.

    Or ce concept est tout sauf nouveau. L’utilisation d’un client léger (terminal) interagissant avec des données sur un système central fût même la réalité de l’informatique jusqu’à l’apparition des ordinateurs individuels (PC) dans les années 80. La grosse différence est qu’au lieu d’être centralisées (sur un serveur bien identifié), elles sont au contraire réparties sur une myriade de serveurs formant une nébuleuse, d’où le nom de nuage. Pour l’utilisateur, cela ne fait pas une grosse différence.

    Mais si ce qui était perçu comme archaïque quand les ordinateurs individuels sont apparus est désormais considéré comme le dernier cri, c’est que les clients légers (navigateurs) permettent désormais un confort de travail (ergonomie) dû notamment à l’évolution des moteurs de rendu, et en particulier de javascript, mais également -surtout- une grande compatibilité. Les normes établies par le W3C permettent à n’importe quel navigateur de traiter une grande variété de fichiers, dont les spécifications répondent à pratiquement tous les besoins. Que vous travaillez sur un texte, une image, un plan, une composition graphique ou musicale, une base de données… il existe un ou plusieurs formats lisibles par un navigateur. Le service cloud n’a plus alors qu’à vous proposer l’interface pour gérer vos documents ou les modifier.

    Les avantages de ces services sont donc nombreux. Parmi eux on citera :

    • la réduction du coût du matériel : plus besoin de serveur local, plus besoin de machines très puissantes -un simple netbook ou un téléphone est aussi bien équipé pour l’utilisation du cloud qu’un monstre de puissance quadri-processeur…
    • aucun logiciel client ne doit être installé sur le poste client -du moins si l’on s’en tient aux services utilisables depuis un navigateur. (d’autres services, comme DropBox, demandent une installation)
    • ces services permettent le travail collaboratif en temps réel (plusieurs personnes peuvent agir simultanément sur le même document)
    • un utilisateur n’a plus besoin de synchroniser ses différents postes de travail (téléphone, PC, tablette…)

    Les inconvénients sont notamment :

    • une perte de contrôle de l’endroit où sont effectivement stockées les données (avec des implications de confidentialité, mais également fiscales).
    • une récupération de sauvegarde dépendant d’un service extérieur à l’entreprise, et donc pas toujours aussi prompte à réagir qu’un service informatique interne.
    • la nécessité d’avoir un accès correct à Internet en permanence, et ce point est extrêmement sous-évalué par les évangélistes du cloud. Pas plus aux Etats-Unis qu’en Europe de tels accès ne sont garantis partout. De nombreuses situations nous laissent sans connexion à Internet (transports, absence ou saturation du réseau 3G…)
    • un impact écologique désastreux. En effet, pour assurer la répartition entre les serveurs (load balancing), et la redondance des données (mirroring), les opérateurs doivent passer par des systèmes de synchronisation complexes (middleware) qui consomment une énergie faramineuse. On nuancera toutefois en remarquant que l’importance du succès des smart phones et tablettes permet de contrebalancer cet effet : si la consommation électrique est multipliée du côté serveur, elle baisse très vite du côté client (un téléphone consommant moins qu’un PC). Il faut donc certainement être prudent sur ce point, voire optimiste sur l’évolution à terme.

    A voir ces deux listes, il apparaît clairement -du moins sur l’aspect “révolutionnaire” du nuage- que les inconvénients l’emportent sur les avantages, quand bien même ceux-ci sont particulièrement alléchants. Mais ceci ne tient pas compte d’une notion fondamentale, et souvent occultée :

    Il y a cloud et cloud.

    D’ordinaire, la multiplication des nuages dans le ciel n’est pas bon signe. Dans ce cas, elle l’est. En effet, les inconvénients majeurs du cloud concernent ce que l’on appelle le cloud public. C’est-à-dire des serveurs mutualisés où vos données côtoient les données d’autres.

    Or il existe aussi la notion de cloud privé. Dans ce cas-ci, l’entreprise mettra en œuvre son propre cloud sur des serveurs qui lui appartiennent ou qui appartiennent à un prestataire bien identifié. Selon les prestataires, elle disposera de tels ou tels services, ou pourra installer ses propres logiciels.

    De nombreux logiciels -souvent Open Source- peuvent ainsi être installés sur un cloud privé. C’est le cas du célébrissime Wikimedia (sur lequel tourne Wikipedia), ainsi que Google Calendar, ou le défunt (et regretté) Google Wave.

    Dans le cas du cloud privé, le problème de confidentialité est -en principe- relégué à une question de sécurité informatique, la récupération d’une sauvegarde peut être contrôlée par l’utilisateur, et l’impact écologique est a priori moindre. Dans le cas où le cloud privé est sur le réseau physique de l’entreprise, la problématique de la connexion à Internet n’est pas plus criant que dans l’informatique “pré-nuageuse”.

    On voit donc qu’il existe des solutions aux principaux problèmes évoqués, tout en gardant la totalité des avantages. Seulement, sauf à créer un cloud privé en louant plusieurs fermes de serveurs (ce qui se fait fréquemment pour des grosses entreprises comme les banques), on passe de la décentralisation sans limite et sans contrôle à une forme de re-centralisation (sur un ou quelques serveurs).

    Autrement dit, nous sommes dans une architecture client/serveur classique, avec un client léger (navigateur). Cette solution est excellente, mais… bienvenue dans les années 1970 ! on n’a rien inventé !

    La révolution qui est en marche comporte bien des pièges. En prenant le recul pour les éviter, nous sommes convaincus que vous sortirez gagnant de votre transition au nuage.

    Et en attendant, au vu de l’été qui vient de s’écouler, espérons qu’il n’apporte pas trop de pluie !

  • Create related records from a field above a portal

    Two easy techniques to improve user experience

    If a user wants to easily create related records, a portal based on a relationship set to allow creation is obviously appropriate.

    Nevertheless, this built-in technique has some cons:

    • the user needs to scroll to the first empty row before being able to create new records.
    • he must know that only the first empty row allows creation.
    • some interface elements are displayed on this empty row, while they make no sense (i.e. a deletion button, useless because there is yet no related record to delete)

    This sample file presents two easy techniques that allow creation from a field placed above the portal.

    The first one, the easiest as well, has been available since FileMaker 7 (although the auto enter calculation would require a little adaptation, because it’s making use of Self function, a FileMaker 9 feature)

    The second one uses filtered portals, a FileMaker 11 feature.

    Download

  • Vidéo : Figer l’ensemble trouvé

    L’ensemble trouvé est un concept-clef de FileMaker, à tel point qu’on oublie parfois de l’expliciter. Or sa maîtrise est indispensable, tant pour le développement que pour l’utilisation de FileMaker.

    Un point méconnu et souvent source de problème dans les solutions multi-utilisateurs est la différence entre afficher tous les enregistrements et figer un ensemble trouvé de tous les enregistrements.

    Au travers d’une courte vidéo, apprenez comment éviter ce piège.

  • Bibliothèques

    Bibliothèques

    Gestion de libraries avec FileMaker

    Dans ce numéro, nous présentons des techniques que nous utilisons souvent pour la gestion des bibliothèques (libraries) dans FileMaker, notamment pour les images de l’interface et les chaînes de texte.

    Ces techniques sont très simples à mettre en œuvre, et facilitent grandement le développement en rendant le contenu de ces libraries toujours disponible, quelque soit le contexte ou le mode.

    Télécharger

  • Des cases à cocher pour un choix exclusif (unique)

    FileMaker propose plusieurs présentations pour sélectionner des éléments dans une liste de valeurs. Or il n’est pas aisé de proposer un choix exclusif parmi plusieurs valeurs.

    Les boutons radio (ou cercles d’options) devraient permettre ceci, mais malheureusement, le maintien de la touche majuscule permet à l’utilisateur de choisir plusieurs valeurs, même avec ces boutons radio.

    Cette astuce permet de contourner cette difficulté, et de proposer de vrais choix exclusifs.

    Télécharger

  • Boucles

    Boucles

    Si vous n’avez pas de notions de programmation, les boucles sont certainement l’aspect le plus déroutant de l’écriture de scripts.

    Si vous êtes au contraire un développeur né, la simplicité des boucles dans FileMaker est également l’aspect le plus déroutant de l’écriture de script.

    Dans cette vidéo, nous explorons plusieurs techniques, trucs et astuces pour faciliter la programmation de de ces fameuses boucles.

    Télécharger

     

     

  • 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

  • FileMaker : Variables et rubriques globales

    FileMaker : Variables et rubriques globales

    le point sur leurs différences, avantages et inconvénients comparés

    A la suite d’un fil de discussion sur le forum FM Source, je me suis dit qu’il fallait peut-être, trois ans après la sortie de FileMaker 8 et des variables, faire un point sur les différences entre variables et rubriques globales.

    L’étendue

    Tout d’abord, il existe trois différentes variables, qui se différencient par leur étendue (scope)

    • les variables de calcul, utilisables uniquement dans la fonction Definir() (Let) : Définir ([variable1 = “salut” ; variable2 = “le monde !”] ; variable1 & ” ” & variable2 ). Ces variables ne sont valables (répétez ça dix fois très vite) qu’au sein de cette fonction Définir. Dès que la parenthèse est refermée, elle sont “oubliées”. Notons que ces variables de calcul ne peuvent être utilisées dans des fonctions Définir emboîtées *. Elles ne passent pas non plus la barrière de la fonction Evaluation**
    • les variables “locales” ou “de script”, notées $ : On peut les déclarer avec une fonction Définir() ou avec l’instruction de script Définir Variable(). Elles ne sont valables que dans le script en cours, et “oubliées à la fin”. Par contre, on oublie souvent qu’elles demeurent pendant tout le script, même si elles ont été déclarées avec une fonction Définir(). Il faut donc se méfier du nommage des variables, afin qu’une fonction Définir() ne vienne pas écraser une variable définie dans le script. On ignore souvent en revanche que des variables locales définies alors qu’aucun script n’est en cours sont valables à chaque fois qu’aucun script n’est en cours. Pour FileMaker, il y a un “script zéro” qui “tourne” quand aucun autre script n’est en cours d’exécution. Définir une variable locale avec la fonction définir alors qu’aucun script n’est en vous permet d’utiliser cette variable à chaque fois qu’aucun script n’est en cours.
    • les variables “globales”, notées $$ : Ce sont celles qui nous intéressent ici, car les seules que l’on puisse confondre avec les rubriques globales. En fait, si FMI les avait nommées correctement, la confusion n’existerait sans doute pas du tout, mais le huitième jour, Dieu, qui avait la gueule de bois, a dit que FileMaker n’aurait pas le droit d’adopter le même vocabulaire que toute l’industrie, et qu’il faudrait dire “rubrique” là où tout le monde parle de “champ”, “modèle” quand les autres parlent de “formulaire”… Je ne vous raconte même pas le 9ème jour, où Il a imaginé Bento !

    * Definir ( var = “bonjour” ; Definir ( var2 = var & ” tout le monde” ; var & var 2 )) ne fonctionnera pas car var n’est pas passée à la deuxième fonction Definir

    ** Definir ( var = 1 ; Evaluation ( var + 1 )) ne fonctionnera pas car var n’est pas passée à la fonction Evaluation.

    Ainsi donc ces variables à deux dollars (et j’ai pas dit deux balles), ne sont en fait pas globales du tout mais “de session”. C’est à dire que leur limite est celle d’une session utilisateur pour un fichier donné.

    Comme leur petites sœurs à un seul $, on les déclare avec la fonction Définir() ou avec l’action de script Définir variable().

    Les rubriques globales, elles, s’apparentent beaucoup plus à des variables globales, puisqu’elles sont valables pour une session de l’application (donc multi-fichiers), et qu’elle contiennent une valeur au début de cette session.

    Notons que la valeur contenue dans une rubrique globale est accessible depuis n’importe quel contexte d’une solution sans avoir à définir de lien. Elles passent même la barrière des fichiers, alors que les variables globales sont propre à une session pour un fichier.

    Ce dernier aspect est particulièrement intéressant pour définir des listes de valeurs relationnelles, accessibles depuis n’importe où, plutôt que de re-créer des liens et une liste de valeurs à chaque fois qu’on en a besoin. Ces listes fonctionnent même en mode recherche !

    Nous retrouvons donc en finale de ce tournoi, à ma gauche, les variables globales (c’est pas tous les jours que les $$ sont à gauche), et à ma droite, les rubriques globales (je les mets à droite parce qu’elle conservent une donnée, elles sont donc plus conservatrices – désolé, je suis aussi drôle que Goscinny depuis qu’il s’appelle Uderzo, c’est lamentable)

    En finale, oui, parce que nous n’avons pour l’instant étudié que leur étendue, mais il reste encore beaucoup à voir. Et d’ailleurs, avons nous vraiment vu tout ce qui concerne l’étendue ?

    Pour ce qui concerne les variables “globales”, c’est assez simple, elle sont définie au cours de la session, et sont “tuées” à la fermeture.

    Il en est autrement pour les rubriques globales, qui conservent une valeur par défaut, valable pour tous les utilisateurs au début de chaque session.

    Pour initialiser la valeur d’une rubrique globale, il faut être l’hôte du fichier. Autrement dit, on ne peut en principe pas modifier cette valeur par défaut si le fichier est servi (partagé par FileMaker Server ou par FileMaker Pro sur un autre poste). Concrètement, chaque utilisateur pourra modifier la valeur d”une rubrique globale au cours de sa session, mais retrouvera la valeur par défaut en fermant et ré-ouvrant le fichier.

    Truc : il existe malgré tout une méthode pour modifier la valeur d’une globale sur le serveur. Elle nécessite (heureusement) l’accès intégral au fichier.

    1. vider la globale
    2. modifier la rubrique globale en calcul de type global, et définir le calcul comme une constante avec la valeur à attribuer (=”MaValeur”) par exemple.
    3. s’assurer que le calcul est effectivement évalué, en consultant le Visualiseur de Données par exemple
    4. repasser la rubrique en globale standard (non calculée)

    Voilà pour l’étendue, je crois que cette fois, nous en avons fait le tour.

    Le stockage

    Le stockage d’une rubrique globale ou d’une variable globale se fait au niveau du poste client, ce qui est bien pratique. Cela veut dire que la valeur est propre à l’utilisateur, et aussi qu’il n’y a pas besoin d’aller chercher une valeur sur le serveur à chaque fois qu’on en a besoin.

    Une rubrique comme une variable peut être multivaluée, mais cela ne présente pas beaucoup d’intérêt pour une variable, car on ne peut pas, contrairement à une rubrique globale, récupérer la liste des valeurs avec la fonction Liste, ou la dernière valeur renseignée avec la fonction Dernière(). En revanche, on peut attribuer n’importe quel entier comme numéro de répétition, qu’il soit négatif, nul ou positif. Considérez que les répétitions d’une variable sont en fait des variables totalement différentes, et vous aurez tout compris.

    Le type de données

    Voyons maintenant quel type de données les variables peuvent contenir, par comparaison aux rubriques globales. Tout d’abord, il faut noter la différence dans la manière dont on type ces données. Dans le cas des rubriques globales, on choisit un type pour la rubrique dans le petit menu où nous retrouvons Texte/Nombre/Heure/Date/Horodatage/Multimedia. Je ne parle pas du type calcul, qui n’est pas à proprement parler un type, puisque le type de résultat d’un calcul se définit en bas à gauche de la définition de calcul. Il peut être global également. Bref, tout ceci prend du sens si on se dit que dans d’autres langages, un “calcul” s’appelle une “requête”, mais bon, le huitième jour, Il avait vraiment mal au crâne.

    Dans le cas des variables, le typage se fait automatiquement, mais c’est parfois quelque chose de méconnu. Si on définit une variable telle que = “bonjour le monde”, le fait de mettre une constante de texte entre guillemets (ou de faire appel à une rubrique de type texte) typera la variable comme texte. Si on n’utilise que des données de type date, la variable sera de type date…

    Je recommande souvent de forcer le type de variable à l’aide des fonctions ObtenirTexte(), ObtenirNombre(), ObtenirDate(), ObtenirHorodatage()…

    Cela rend le code plus lisible et évite les mauvaises surprises.

    En revanche, et c’est également méconnu, les variables peuvent contenir tous les types de données gérés par FileMaker. Tous ? oui ! Cela veut dire que l’on peut parfaitement stocker une image ou un fichier dans une variable globale.

    Truc : on notera toutefois un bug pénalisant si vous essayez de stocker un long texte dans une variable globale. L’application se verra dramatiquement ralentie. Ceci ne se produit pas si vous découpez votre texte en plusieurs variables ou… que vous choisissez de le stocker dans une rubriques globale.

    La méthode pour les définir

    Cela semble assez évident, mais cela a de grandes conséquences : on ne définit pas une rubrique globale comme une variable globale.

    Une variable globale peut être définie soit par script (Définir Variable()), soit par simple calcul, grâce à la fonction Définir() : Définir ( $$maVariable = “bonjour le monde !” ; “” )

    C’est là un immense avantage, car on peut alors dès lors définir des variables sur chaque intervention du moteur de calcul : auto-entrée, contrôle, calcul pour ce qui concerne la définition de la base de données, mais aussi jeux de privilèges, et surtout au niveau du modèle (infobulle, web viewer, formatage conditionnel, et même [[jeux de menus personnalisés]FileMaker Pro Advanced est requis pour mettre en place ces possibilités]).

    Pour définir une rubrique globale, vous devez utiliser l’action de script Définir rubrique(). Personnellement, je rêve d’une fonction de calcul qui définirait une rubrique. On peut faire ce genre de choses (et bien plus) avec un plug-in comme DoSQL de myFMbutler, mais pas avec FileMaker tout seul.

    On en oublierait presque qu’à l’inverse, il existe une méthode de définition de la rubrique globale qui n’existe pas pour la variable, et pas des moindres ! Allez, allez, laquelle ? Votre langue au chat ? Ben… c’est l’utilisateur, pardi ! L’utilisateur est également un très bon moyen de définir une globale. Muni de son petit clavier et de sa petite souris, mais aussi des menus déroulant, cases à cocher, et autres boîtes de dialogue que vous aurez bien voulu mettre à sa disposition.

    Les utilisations

    Du fait que la rubrique globale est propre à l’utilisateur, on l’exploitera justement pour tout ce qui est interface (filtres de table externe, images, libellés que l’on veut voir persister en mode recherche…). L’avantage de la rubrique est ici double : modifiable par l’utilisateur (par exemple pour filtrer une table externe via un menu déroulant), et surtout, affichable sur le modèle ! Second rêve du jour : pourvoir insérer un calcul directement sur le modèle, et en particulier une variable globale. On peut déjà, et depuis toujours, insérer une “rubrique de fusion”, le nom de l’utilisateur, la date courante… je parie qu’insérer une variable ne coûterait pas des mois de développement à FMI !

    Une “rubrique globale” peut également servir de “rubrique clef” au départ d’un “lien” (je vous assure, FileMaker est vraiment un langage codé !), ce qui n’est pas possible avec une variable (troisième songe ?). Ainsi, tous les liens relatifs à l’interface (la vue de l’utilisateur courant) doivent être basés sur des rubriques globales.

    Voilà, j’espère avoir fait à peu près le tour, et que ça aidera certains à y voir plus clair

     

    Cet article a été publié sur Le Blog FM et a été repris par FileMaker Inc. dans sa Newsletter d’Octobre 2008.

  • Commander FileMaker au clavier (Mac OS X)/éviter les clignotements (Windows)

    Deux astuces en un fichier

    Commander FileMaker au clavier (Mac OS X)

    Suite à la FM Conf, j’ai reçu plusieurs demandes d’explication sur un aspect que j’avais abordé un peu vite : la possibilité de piloter l’interface de FileMaker 11 au clavier. Voici donc un petit addendum.

    Éviter les clignotements (Windows)

    Bien que FileMaker 11 ait grandement amélioré cet effet désagréable, les problèmes de clignotement sur PC sont toujours un frein à l’utilisation de l’action de script Rafraichir Fenêtre. Voici une technique toute simple qui règle ce problème.

    Télécharger

  • Transactions

    Transactions

    Voici certainement l’article le plus important depuis la création de 1-more-tube : les transactions dans FileMaker.

    Tout le mérite revient à Todd Geist, qui a exploré les techniques de transactions, et vous trouverez ses articles sur le sujet sur le site de Geist Interactive.

    Cet article est une introduction en français, qui permettra de comprendre l’intérêt que représentent les transactions, en termes d’intégrité des données et de performances.

    Si vous développez des bases de données pour FileMaker Go (la version de FileMaker pour iPhone et iPad), cette technique transactionnelle est tout simplement indispensable.

    Télécharger

  • Utiliser l’heure du serveur dans les logs

    Vous pensez déjà à conserver, pour chaque enregistrement, les dates et heures de création et modification ?

    Mais avez-vous pensé aux problèmes qu’engendrerait un éventuel décalage entre les réglages d’heure des différents postes clients ?

    Dans cette astuce, vous découvrirez comment pallier à ce problème et utiliser l’heure du serveur comme référence unique.

    Télécharger

  • Les fonctions XML au sein de FileMaker

    Les fonctions XML au sein de FileMaker

    “XML”, voilà un terme qui fait peur !

    Et pourtant, l’utilisation du XML est un grand facteur de simplification !

    Avec un temps d’apprentissage quasi-nul, vous ne pourrez plus vous passer des fonctions d’écriture et de traitement du XML au sein de FileMaker.

    Dans cette vidéo, nous explorons trois fonctions personnalisées simplissimes, qui changeront votre vie de développeur si vous ne les utilisez pas déjà.

    Passage de paramètres multiples et complexes, résultats de scripts structurés et utiles, mais également simplification du graphique relationnel. Voici quelques uns des principaux bénéfices de l’utilisation de ces fonctions.

    Télécharger

  • Supprimer une rangée externe

    Dans cette astuce, nous fournirons une technique pour proposer un bouton de suppression unique sous (ou au dessus, ou à côté…) de la table externe, plutôt que sur chaque rangée.

    Gagnez de la place, et ne donnez plus à voir des interfaces aussi pleines de poubelles qu’une rue de Bruxelles un mardi soir !

    Télécharger

  • Fonctions personnalisées 2/2

    Fonctions personnalisées 2/2

    Suite et fin de notre série consacrée à la création de fonctions personnalisées.

    Dans cette vidéo, nous abordons la notion de tail recursion, explorons ses avantages et ses pièges.

    Nous apprenons également quelques trucs pour écrire des fonctions plus faciles à utiliser.

    Télécharger

  • Techniques FileMaker 11

    Techniques FileMaker 11

    Les fichiers présentés à la FMConf 2010

    Voici quelques techniques présentées lors de la FileMaker Conférence 2010 à Paris (Session 21 : FileMaker 11 pour développeurs)

    Les graphiques comme outil de design. Réaliser un fond en dégradé grâce à un graphique et une rubrique calculée.

    Télécharger

    Nouveaux déclencheurs

    Intervenir sur les données pour effectuer des traitements avant validation (par exemple faciliter la saisie d’une date

    Contrôlez la condition de fermeture d’une fenêtre sans passer par les menus personnalisés.

    Télécharger

    Menus dynamiques

    Fonction cachée de FileMaker Pro Advanced 11 ! Il est désormais possible de faire de vrais menus dynamiques.

    Télécharger

    Recherche rapide (QuickFilter)

    Une amélioration du fichier Clairvoyance, présenté lors de la FMConf 2009. Cette version est optimisée, traite tous les types de données, et tire partie de la recherche rapide.

    Télécharger

  • FileMaker 11 Techniques

    FMConference 2010 presentation technique files

    Here are some techniques presented during the 2010 FileMaker Conference in Paris (Session 21 : FileMaker 11 for developers)

    Charts as a design tool

    Embellish your layouts with gradients, using a chart object and a calculated field.

    Download

    New script triggers

    Process your data before it’s rejected by field validation options (e.g. make it easy to enter a date)

    Prevent closing of a window without a specific custom menu set.

    Download

    Dynamic menus

    FileMaker Pro Advanced 11 hidden feature ! You can now add real dynamic menus to the interface.

    Download

    Quick Filter

    An improvement of our Type-Ahead technique presented at FMConf 2009. Optimized for all datatype and takes benefit of FileMaker 11 QuickFind.

    Download

  • Fonctions personnalisées 1/2

    Fonctions personnalisées 1/2

    Les fonctions personnalisées, apparues avec FileMaker 7, ont changé la vie des développeurs.

    Pourtant, il n’est pas rare que ces fonctions fassent peur. Dans cette vidéo, nous verrons l’intérêt d’utiliser des fonctions personnalisées, et nous apprendrons à concevoir une fonction récursive.

    Si vous savez ce qu’est une boucle dans un script, vous verrez que les fonctions récursives ne sont pas plus compliquées !

    Télécharger

  • Mise à jour des données

    [vc_row bg_color=””][vc_column][vc_column_text][OBSOLÈTE] : FileMaker 17 intègre cette fonctionnalité nativement avec le Data Migration Tool (pour les membres FBA)

     

    Suite à la passionnante session de Vincenzo Menanno (FM Nexus) lors de la FM Conférence 2010 à Paris, qui traitait des différentes stratégies de mise à jour de solutions, 1-more-thing a décidé d’emboîter le pas et de lever le voile sa méthode.

    En effet, j’ai été frappé des ressemblances entre notre méthode et celle de Vincenzo, et les petites différences me font penser qu’échanger sur ce thème provoquera des réactions constructives, des ajustements nécessaires. Cet article se veut donc une proposition, et nous espérons apprendre aussi des réactions que vous ne manquerez pas de laisser ci-dessous.

    Tout d’abord, ciblons le cas de figure qui fait l’objet de cet article.

    La méthode exposée ci-après concerne les grosses mises à jour, et non les petits développements ponctuels, que l’on pourra faire directement sur le serveur, pendant que les utilisateurs travaillent (développement live) ou pendant les heures de fermetures, voire en reproduisant sur la version servie les modifications apportées sur une version de développement (développement offline).

    Dans ce cas de grosses mises à jour, nous avons une version de développement qui a été modifiée, et le but est d’importer les données depuis la version précédente. La version de développement est donc destinée à être installée sur le serveur après le processus de migration.

    Précisons également que comme Vincenzo Menanno, nous ne sommes pas convaincus par l’approche séparation données/interface, sauf dans certains cas bien précis. Aussi, nous partons du principe qu’il n’y a pas de différence majeure entre l’approche “en séparation” et l’approche classique, sachant qu’il est rare qu’un changement d’interface n’induise aucun changement dans la structure des données. Nous ne préciserons donc pas ci-après les différences qui peuvent théoriquement exister entre les deux approches.

    Etapes préliminaires

    Avant tout, il va de soi que le transfert massif de données sera beaucoup plus efficace sur un poste client (local) qu’à travers le réseau. Nous devons donc arrêter le serveur (du moins la solution concernée), et en faire une copie sur le poste local.

    Pour éviter toute confusion, nous plaçons ce fichier dans un dossier “Old”, situé au même niveau que la version de développement.

    Nous avons donc une arborescence du type :

    • Solution.fp7 (destination)
    • Old
      • Solution.fp7 (source)

    Mais ceci est en fait un peu trop simple. Lors du développement de la nouvelle version, nous avons peut-être eu besoin de créer des données dont nous aurons besoin, notamment dans les tables de référence (images, libellés, messages, code postaux ou pays…). Ces données ne figurent pas dans la source des données, mais dans la destination.

    Or, comme nous le verrons ci-après, une des premières choses à réaliser est de vider le fichier de destination de ses données. En fonction du volume de données, on pourra choisir de supprimer ces données ou de faire un clone du fichier de destination (beaucoup plus rapide si le fichier contient beaucoup de données, FileMaker étant extrêmement lent à cet exercice)

    Dans deuxième cas, nous créons un clone du fichier de destination dans un dossier Reference. L’arborescence est donc :

    • Solution.fp7 (destination)
    • Old
      • Solution.fp7 (source pour les données)
    • Reference
      • Solution.fp7 (source pour les références)

    Alternativement, on aura pu développer la solution avec un fichier spécifique pour les tables de référence, ce qui simplifie cette étape, mais pose des problèmes de gestion des comptes, comme toute solution multi-fichiers.

    Le renommage des rubriques

    Comme nous le verrons plus loin, la migration des données se fera pas un import basé sur les noms concordants des rubriques. Il est donc nécessaire de s’assurer que les rubriques n’ont pas changé de nom entre les deux versions.

    Pour cela, nous utilisons l’utilitaire FMDiff, qui permet en quelques minutes de comparer deux versions du fichier fp7. Notons que nous utilisons par ailleurs beaucoup Inspector ou BaseElements, mais ces outils d’analyse demandent un import du Rapport de Structure de Base de Données en XML, ce qui prend pas mal de temps et qui est ici inutile : seuls les renommages nous intéressent. Si vous devez investir dans un outil et un seul, il va néanmoins de soi que ces outils d’analyse vont plus loin que FMDiff.

    Une fois ce rapport produit, nous reproduisons scrupuleusement les renommages dans le fichier source.

    Pour plus de sécurité, nous comparons ensuite le fichier source modifié au fichier de destination (on n’est jamais à l’abri d’une faute de frappe)

    Les scripts de migration

    La migration de données est presque entièrement automatisable. Vous n’êtes pas obligé d’attendre la première migration effective pour développer ces scripts, bien que rien ne vous empêche de le faire à ce moment. Pensez toujours néanmoins qu’on travaille mieux sans stress, et qu’une mise à jour d’une solution tournant chez le client doit être faite rapidement, et donc génère pas mal de stress. Si possible, prévoyez donc déjà d’inclure ces scripts dès la première version.

    La première chose à faire sera une référence au(x) fichier(s) source(s), Old/Solution.fp7 et Reference/Solution.fp7

    Puis, dans le cas où l’on n’a pas fait de clône, on exécute dans le fichier de destination un script qui va supprimer toutes les données : MAJ_SupprimerToutesLesDonnées

    (note : tous les scripts décrits ci-après sont destinés à être joués en accès intégral).

    Gestion Erreurs [ Oui ]
    Activer modèle [ par numéro ; 1 ]
    Boucle
    Afficher tous les enregistrements
    Si [ Obtenir ( EnregTrouvés ) ]  // ON GERERA LES EXCEPTIONS SI CERTAINES TABLES DE REFERENCE NE DOIVENT PAS ETRE EFFACEES
    Supprimer tous Enregistrements [ sans dialogue ]
    Fin de Si
    Activer Modèle [ numéro par calcul ; Obtenir ( NuméroModèle ) + 1 ]
    Fin de boucle si [ Obtenir ( DernièreErreur )]
    Fin de boucle

    Bien. Que l’on ait généré le fichier de destination par un clone ou pas, nous sommes maintenant tous dans le même bâteau.

    La prochaine étape consiste à s’assurer que tous les enregistrements vont être importés.

    On crée donc un nouveau script dans notre fichier de destination : “MAJ_Afficher tous les enregistrements de la source”

    Ce script ne fait que qu’exécuter un sous-script dans le fichier source : “MAJ_Afficher tous les enregistrements”

    Ce sous-script, qu’on prendra bien soin de copier dans le fichier de destination également (pour la prochaine mise à jour), est très simple :

    Activer modèle [ par numéro ; 1 ]
    Boucle
    Afficher tous les enregistrements
    Annuler Tri
    Activer Modèle [ numéro par calcul ; Obtenir ( NuméroModèle ) + 1 ]
    Fin de boucle si [ Obtenir ( DernièreErreur )]
    Fin de boucle

    Attention, ceci suppose que l’on ait au moins un modèle pour chaque table de base. Mais ceci est largement à conseiller, et pas que pour les mises à jour. Malheureusement, il n’existe pas de fonction de calcul en FileMaker permettant de s’assurer de cela. Pour cela, nous utilisons régulièrement des outils comme Inspector.

    Un participant de la FMConf a proposé, en lieu et place de Annuler tri, de trier sur la clef primaire (il utilise des clefs primaires séquentielles, ou numéros de série). Il est exact que de manière exceptionnelle, on aura pu modifier un identifiant primaire, et qu’il serait ensuite confortable de voir le enregistrements importés dans l’ordre. Néanmoins, nous pensons différemment, car la procédure de mise à jour serait plus longue (le tri est consommateur de temps), et devrait être “hard-codée” (il n’est toujours pas possible, et c’est dommage, de définir un tri dynamiquement). Cela suppose que ces scripts de mise à jour seront beaucoup plus difficiles à maintenir, et qu’il y a plus de chance de provoquer une erreur. Quand ces cas de force majeure se présentent (modification d’un ID par le développeur ou l’admin), nous préférerons profiter de l’occasion pour réaliser l’opération de maintenance consistant à trier, exporter, puis réimporter les enregistrements, directement après le changement d’ID. Ainsi, nous sommes certains que le dernier numéro de série utilisé est bien le dernier enregistrement.

    Nous effectuons bien sûr la même opération (script ci-dessus) pour le fichier situé sous Reference/Solution.fp7, ou pour les autres fichiers de la solution.

    A ce stade, nos fichiers source et notre fichier de destination sont prêts pour l’importation.

    Nous allons donc écrire un script dans le fichier de destination qui importera toutes les données, et mettra à jour les numéros de série. Comme nous devons ajouter une étape d’import pour chaque table, il est facile de cibler tel ou tel fichier source.

    Pour chaque table, nous avons : (les étapes précédées d’un * sont à configurer pour chaque table)

    *Activer modèle ( un modèle représentant la table) // ceci est facultatif, mais permet un éventuel débogage.
    *Importer Enregistrements // on choisit la bonne table source et la bonne table de destination, et on sélectionne les options "noms concordants" et "Créer des enregistrements" en bas. Cette méthode permettra de ne pas avoir à modifier les ordre d'importation plus tard.
    Très important : après avoir cliqué sur Importer, on s'assure que la case permettant l'exécution des options d'auto-entrée est décochée.
    Activer enregistrement [ dernier ]
    (*)Définir variable [ $nextID ; IncrementSerie ( ResultatRubrique ( "zkp" ) ; 1 )]  // tous nos identifiants primaires sont nommés zkp, ce qui nous permet d'utiliser ce genre de formule générique, mais sinon, il suffit de pointer une rubrique en particulier dans chaque cas.
    *Définir valeur en Série Suivante [ zkp ; $nextID ] // malheureusement, il faut ici préciser quelle est la rubrique dont on veut initialiser le numéro de série, il n'existe pas de manière calculée de le faire, à la manière de Définir Rubrique par nom.
    Définir variable [ $nextID ; "" ]

    Nous répétons cette opération pour chaque table (ce qui peut donner un script assez long). Voilà pour l’import des données.

    Listes de valeurs et comptes utilisateurs

    Il ne nous reste plus qu’à importer les éventuelles listes de valeurs modifiables par les utilisateurs (les listes à valeurs personnalisées). Pour cela, FileMaker 11 apporte une petite nouveauté : la possibilité de trier les listes de valeurs dans la fenêtre Gérer les listes de valeurs. On peut désormais les trier par provenance, ce qui nous évite d’avoir à utiliser une convention de nommage très stricte.

    Mais il faut malgré tout copier/coller d’un fichier à l’autre.

    Idem pour les comptes utilisateurs. S’ils ont été modifiés, si on en a créé de nouveaux ou désactivés certains pendant la phase de développement de la nouvelle version, il faut reproduire les modifications sur la nouvelle version. Là encore, on s’aidera d’un outil de comparaison des versions.

    Il en va de même si vous avez du effectuer quelques menues modifications sur la version servie alors que vous aviez déjà commencé le développement de la nouvelle version sur une copie. Pour cela, pas d’autre moyen que de noter ce que l’on fait. Inspector peut malgré tout vous aider, mais appliquer machinalement des modification sans se souvenir de la raison pour laquelle on a du faire ces modifications n’est jamais à conseiller.

    Enfin (quoi que dans notre cas cette étape soit intégrée à notre script d’import), on n’oubliera pas de documenter le numéro de version, afin qu’il soit clair pour les utilisateurs qu’ils ont changé de version, et afin de pouvoir mieux traiter les éventuels rapports de bugs futurs.

    En espérant avoir rencontré votre intérêt, n’hésitez pas à nous faire par de vos expériences et de vos méthodes.[/vc_column_text][/vc_column][/vc_row]

  • Reporting Excel

    Reporting Excel

    Aller plus loin avec Excel et FileMaker

    On croit souvent que l’interaction entre FileMaker et Excel se limite à des conversions ou à des export de données bruts. Et il n’est pas rare qu’on sous estime la puissance de reporting de ces deux outils combinés.

    Dans cette vidéo de 30 minutes, nous apprendrons à générer un rapport Excel qui contiendra des données, de la mise en forme, des images et même des formules qui fonctionnent directement dans Excel !

  • Définir les numéros de série

    Dans cette astuce, nous répondons à une question posée lors de la FM Conf à Paris.

    La question était : “comment gérer la numérotation séquentielle de documents comme des factures ? comment contrôler les numéros de série, tant dans les données que dans la structure de base de données”.

    Dans cette courte vidéo, nous (re)découvrirons une fonction méconnue de FileMaker, IncrementSerie, ainsi que quelques “trucs à savoir” sur l’action de script permettant d’initialiser une numérotation.

    Télécharger