Dans le billet de mercredi dernier, j’ai commencé à analyser le deuxième document publié par FileMaker et appartenant au guide de développement d’app personnalisées s’appelle Créer.
On peut télécharger ces différents documents depuis le site FileMaker après avoir complété un formulaire.
Le plan adopté par l’éditeur est en effet suggestif. Je vous le rappelle ci-dessous :
- En savoir plus sur la base de données (en fait, il y est question de la structure de la base)
- Concevoir un modèle (à lire aussi : l’annexe A, consacrée notamment aux différentes formes d’affichage des données…)
- Concevoir l’interface utilisateur.
- Importer des données
- Intégrer d’autres sources de données
- Créer un logiciel métier et concevoir un flux de travail
- Définir les règles de sécurité
- Tester votre application
Nous avons là de bons points de repères. Je voudrais simplement discuter avec vous, en dehors des ajouts déjà signalés, quelques aspects complémentaires.
Créer la structure est de toute évidence la première étape. Je ne reviens pas là-dessus.
Dans le contenu des chapitres Concevoir un modèle et Concevoir l’interface utilisateur, je ne vois pas de réelle différence entre les deux puisque dans le chapitre Concevoir l’interface utilisateur, on y aborde l’outil de création de modèle, les thèmes, et deux formes de modèles liste et formulaire, les rapports et tableaux de bord.
De mon point de vue, ces deux chapitres n’en forment qu’un seul, avec une possible progression puisqu’on part de la simple mise en page d’un modèle (choix du type de modèle, positionnement des rubriques et objets de modèles, etc.) à la conception d’une interface utilisateur qui va bien au-delà du seul aspect graphique (boutons de navigation et déclencheurs de script, les uns et les autres faisant appel à des scripts, gestion des tris, des recherches, des formatages conditionnels, des éléments invisibles, etc.).
Les deux chapitres suivants peuvent également être fusionnés : Importer des données et Intégrer d’autres sources de données. On peut y ajouter tout ce qui concerne la saisie des données. Étrangement, le chapitre Importer des données commence par une page Comment démarrer. Certes, dans l’une des trois solutions proposées, il y a la conversion d’une feuille Excel en fichier FileMaker. Il y a donc déjà des données. Mais dans tous les cas, y compris celui de l’import, la plupart du temps, beaucoup de choses restent à construire depuis la structure jusqu’aux tests, et à compléter au niveau des données. J’aurais donc placé cette page au tout début du processus, avant ou au début du chapitre concernant la structure de la base.
Au stade où nous en sommes, nous avons bien avancé dans notre base. Nous avons la structure, les modèles, les données à l’état brut. Il nous manque ce qui fait la « personnalisation métier » de la base et sa sécurisation.
Si je comprends bien le document, la « personnalisation métier » de la base (c’est moi qui ait inventé l’expression) permet de mettre en place les processus métiers et du coup, les flux des données. Cela peut comporter par exemple :
- Visualiser des résultats à partir de données existantes, et donc des calculs, des statistiques, des graphiques…
- Partager des données, imprimer, exporter, etc.
- Réaliser des recherches (recherches scriptées, tables externes…) avec traitement du résultat obtenu…
- Réaliser des actions spécifiques propres au métier…
De ce point de vue, cette étape va croiser ou reprendre des notions d’interface utilisateur. Par exemple, pour imprimer, l’utilisateur devra sans doute être emmené sur le modèle du courrier à imprimer, en mode Prévisualisation ou avec la création d’un pdf. Ou une donnée pourra apparaître en rouge pour alerter l’utilisateur qu’un délai est dépassé…
La dernière étape, sécurité, pour la part « base de données » (comptes, droits d’accès, menus personnalisés) trouve effectivement bien sa place en fin de processus. Il est plus facile d’autoriser l’accès de certains modèles lorsque tous ont été créés et que l’on est sûr autant qu’on peut l’être avant les tests qu’il n’y en aura pas d’autre… En revanche, la partie sécurisation des données (limiter les risques de fausses manipulations utilisateur ou conflits d’utilisations en réseau, ou…) se fait généralement au fur et à mesure du développement, au moment de l’écriture des scripts, avec la gestion des erreurs, l’interdiction d’annulation des utilisateurs, etc.
Merci de laisser un commentaire (Pas de commentaire )
Désolé, les commentaires des articles réservés sont eux-mêmes réservés
Il n'y a pas de commentaire pour l'instant, soyez le premier ;-)