Discussion :

[mumen]

Ibelieve, merci de ces éclaircissements.

Il semblerait que j'ai mal interprété ton message, puisque je l'ai compris comme étant dédié à ma partie, la gestion, alors qu'il n'en parlait même pas. Je comprends bien que la génération d'application ne concerne que très difficilement une prédilection comme la tienne, qui comporte sans doute assez peu de code automatisable et que donc mes remarques ne s'y appliquent pas.

En tout cas, en gestion, de l'automatisable, il y en a encore énormément. C'est un gisement à peine entamé, un chaînon manquant. Dans ce domaine les remarques que tu fais sont cohérentes et représentent des limites classiques de la pensée du codeur. Elles ont quelque chose d'universel. Je me les suis appropriées et elles me guident dans la mise en séquence de mes idées . En français, ça s'appelle un plan et c'est là où je pêche pas mal. Donc merci du coup de main.

Je ne comprends pas grand chose aux discussions sur les logiciels de gestion, ni sur les bases de données (domaine auquel je n'ai pas touché depuis mes études).

Je tiens cependant à apporter une précision par-rapport à ce que je dis dans mon passage quoté dans le premier post de ce sujet.

Je suis personnellement un pratiquant convaincu du code généré. Il y en a peu, en proportion, dans mes programme, mais il y en a. C'est d'ailleurs la principale raison pour laquelle je continue de temps en temps de programmer en LISP entre deux épaisses tranches de C. Les macros de LISP sont excellentes pour générer du code.

Mais je n'utilise que des générateurs de code que j'écris moi-même, et qui produisent du code ni plus ni moins lisible et ni plus ni moins long que celui que j'écrirais entièrement à la main. Je ne pourrais pas avoir confiance en un truc qui produit cinq mille nouvelles lignes de code imbuvables dans douze langages différents dès que je clique sur un bouton. Je n'en peux plus de ces applis qui tournent à un centième de leur vitesse théorique tout en nécessitant 1Go de mémoire et de disque pour faire pas mieux que ce que j'utilisais il y a dix ans sur mon ordinateur de l'époque (Un pentium 166 avec 2 Go de disque dur qui était déjà dépassé à ce moment-là mais sur lequel je n'utilisais que des logiciels corrects pas du tout générés).

Par ailleurs je n'ai jamais réussi (en fait je n'ai jamais osé essayer, et j'ai peut-être tort ?) à générer "automatiquement" une application complète et je ne vois même pas comment cela serait possible dans mes domaines de prédilection (le traitement d'image et l'analyse d'image).

[mumen]

C'est juste oublier que ce qui est automatisable l'est souvent au prix d'une perte de souplesse et / ou de performance.

Ici, c'est le contraire qui est arrivé.

Ce qui s’est imposé à moi à partir de la génération de formulaires, je l’ai vu en très peu de temps. Et je savais pertinemment que le temps considérable que je gagnais quotidiennement avec la génération ne serait jamais égalé par ce travail incontournable et autrement plus complexe. Il me fallait le faire quand même, parce que j’avais un certain nombre de chantiers en cours et deux ou trois prescripteurs pas manchots. Je ne devais pas perdre le fil.


UN CORDONNIER BIEN CHAUSSÉ

D'abord, il me faut indiquer une chose qui a son importance. Les tables système que j’avais déclarées étaient le support de l'IHM côté client. Bien. Si cette IHM était assez bonne pour mes clients, elle le serait sans doute aussi pour moi développeur, dans l'idée d'exposer mes propres objets, c'est-à-dire le système lui-même.

C’est ce qui fait que, à un certain moment, le contenu des tables systèmes est venu s'étoffer des définitions des tables système elles-mêmes. Dès lors, puisqu'il existait un formulaire qui permettait d’éditer les formulaires, ce formulaire lui-même pouvait aussi être édité. De même il y avait un formulaire qui présentait une table qui était la table des tables, un champ qui affichait le champ utilisé, etc. Quand ce genre de situation advient, celles où le serpent semble se mordre la queue, et qu’elles n’amènent pas la moindre difficulté particulière, cela peut être considéré comme un excellent signe que les choix effectués sont corrects.


SORTIR LA DÉFINITION

Toute mon expérience en développement de gestion me disait de sortir la définition du système de ma base de travail. J’avais depuis mes débuts procédé à ce type d’extraction, en créant un fichier texte à plat qui décrivait mes tables et champs en mettant cette déclaration à disposition de toutes les parties de mes applications. Je savais que j’aurais la même chose à faire, et même plus. J’avais déjà la certitude que je pourrais et que je devrais ajouter un ensemble de propriétés supplémentaires. Cette définition portait à priori uniquement sur les bases de données, les tables, les champs et les relations.

Conformément à mon expérience, j’ai opté pour un fichier de définition à plat, organisé en colonnes et lignes. L’éditeur idéal pour ce type de fichier s’est avéré sans discussion possible être le tableur. À la naissance de ce format est apparu le sous-projet suivant de ma recherche, celui de la création proprement dite de la structure. Deux appellations sont apparues simultanément à cette occasion, celle de Feuille d’Analyse pour désigner le fichier à plat et celui d’Analyste pour désigner l’application dédiée à la lecture de ces feuilles et à leur transformation en une base d’application fonctionnelle, où tout est pris en charge en un seul clic, de la création/maintenance de la base frontale à celle de la base dorsale. La génération de formulaires restant l’apanage du frontal, à l’aide de la bibliothèque commune à toutes les applications du projet général, que j’ai nommé Nakedata.

Du point de vue de la définition, la feuille d’analyse apporte en plus d’un schéma classique de définition des données, quelques propriétés qui permettent la prise en charge de l’identification par l’humain des enregistrements, la déclaration des champs considérés par la relation comme les champs de la table étrangère et un ensemble déclaratif très succinct d’une couverture minimale de l’application par les formulaires des trois types, Recherche, Détail, Sous Formulaire en plus des États. Par la suite, des propriétés sont apparues, quand elles permettaient de factoriser des développements clairement vus comme universels. Ce dernier point à lui seul valait tous les efforts consentis jusqu'alors et le temps gagné commençait tranquillement, au grès de petites victoires, à devenir beaucoup moins ridicule face à celui obtenu par la génération de formulaires.

J’espère qu’on se fait une assez bonne idée de ce qui se passe ici, car la suite est excessivement importante.

Je récapitule donc. J’ai un fichier de définition à plat, qui recense tout ce qu’il y a à savoir sur la structure de l’application à venir, plus quelques informations de navigation et de cosmétique. Un programme totalement indépendant du système, contenu dans une application nommée Analyste (en référence à son utilisateur type), lit cette source de structure et fabrique à partie de zéro une base de données dorsale comportant les tables du client, plus une application frontale comportant tout ce qu’il faut pour saisir les données client, pour administrer et pour développer et distribuer. Un processus de génération est ensuite appliqué à cette base frontale, processus de création de l’IHM. Cet ensemble de choses requiert quelques clics de souris et suffit à fabriquer une application installable en réseau chez le client et directement utilisable.

Pour la petite histoire, les signes de la qualité de mes choix se répètent ici aussi : l'Analyste qui est d'abord un pur code est aussi l'outil de gestion des applications du développeur. En tant que tel, il est une application du système, une application qui s'autogénère sans problème.

Pour l’instant, je n’ai encore rien montré de véritablement extraordinaire et les esprits aiguisés se demandent comment je vais pouvoir résoudre le problème central de la génération d’application, problème qui par sa simple évocation a retenu si longtemps cette possibilité.


LE SURTYPAGE

Eh bien, vous allez le voir, finalement la solution, c’était de faire ce qui était évident, c'était de se laisser guider par la nature des choses. Une fois que mon application est générée, dans la mesure où mon IHM est assez bonne pour permettre de faire tout ce qu’il y a à faire, il n’y a plus aucune raison que l’on passe ailleurs pour faire les mises à jour des données, qu’elles soient client ou système. Dès lors, on peut envisager d’avoir une structure événementielle, qui va permettre de gérer des conditions et des actions. En mode c/s, on laisse faire ces choses par le serveur, puisqu'il est le seul garant de la rigueur de l’application de ces règles. Mais, dans le cas qui est ici advenu, de par toutes les spécificités que j’ai mentionnées depuis le début, il est pratiquement équivalent de faire appliquer des règles par le frontal que par le dorsal. Et c’est bien plus facile et surtout bien plus universel.

J’ai ajouté aux tables du système un événement après mise à jour qui mémorise chaque changement effectué dans chaque champ. Le voilà le secret. Encore fallait-il avoir un système.

Quand l’Analyste effectue une feuille d’analyse, il efface d’abord totalement les tables système du frontal avant de les recréer. Dans une seconde étape, il reprend la liste de toutes les modifications précédemment effectuées et les réapplique sur ce système tout neuf, le remettant exactement au même niveau qu'avant si la feuille d’analyse n’a pas changé entre-deux.

J’ai baptisé cette opération le surtypage. Le système tel que déclaré dans la feuille est dit surtypé par tout ce qui a été mémorisé lors de la phase de saisie, qui se situe dans l’application même. Tout ce qui est surtypé l’est soit pour faire du cosmétique, soit pour développer. Ce dernier point est capital : tous les objets que crée le développeur sont forcément référencés dans le système par le biais des multiples appels au code ou aux requêtes. Ces points de contact vitaux entre le monde théorique de l’analyse et le monde pratique du développeur sont tous regroupés sous le nom de surtypage. Le surtypage est le no man's land entre deux terres jamais franchement séparées avant lui. Celles de l'analyste et celle du programmeur. À partir de lui, plus besoin de coder pour faire des applications de bases de données relationnelles développables.


CONCLUSION

J’ai dû être très rapide et je l’espère suffisamment clair pour cette partie. Ne pas la comprendre revient à ne rien comprendre à ce que j’essaye de faire. Je conçois ce que, sans l'avoir pratiquée, cette méthode du surtypage peut avoir de peu convaincant. Néanmoins, rappelons-nous que, quand je l'ai généralisée en une deuxième passe de programmation, elle est devenue tellement pratique et indispensable qu'elle m'a imposé de baptiser la version de mon grand projet du millésime deux, l’intronisant en tant que système. Depuis une dizaine d'années, la version de Nakedata que j'utilise sur tous mes sites n'a pas changé. Le surtypage me donne une liberté et une qualité de fonctionnement telles, qu'il mérite amplement son appellation de clé de voute du système.

La deuxième partie de ce chapitre portera sur une conséquence totalement inespérée et fortement structurante qu'a permis cette généralisation. Harmonie. Les plus rationnels apprécieront la possibilité tout à fait innovante pour un analyste de pouvoir déclarer un grand nombre de calculs formels au fil de la relation, au sein même du fichier de définition de l’application. C’est-à-dire sous une forme complètement abstraite de tout codage. Incontournable.

[Logan Mauzaize]

La première précision qui s'impose est que je n'ai pas le niveau de vocabulaire et de connaissance théorique pour être certain de te comprendre entièrement : je suis formé sur le terrain. Mais je veux bien apprendre.

Je suis pas sûr que les problèmes de compréhension (s'il y en a) viennent de ton niveau de connaissance mais plutôt de ma manière de m'exprimer Ne t'en fais pas, j'ai l'habitude et j'essaye de me soigner

Ma spécification, qui permet de générer une application, n'est pas en langage naturel !

C'est déjà un premier point à préciser.

Non, c'est une définition formelle à plat qui comporte une liste exhaustive des tables, champs, relations avec leurs propriétés, plus, et c'est là un premier changement de paradigme de la formalisation dont je parlerai ensuite, plus donc, un saupoudrage d'informations concernant l'IHM et la navigation. Ma définition demande à l'acteur analyste d'indiquer formellement au système ce type d'information. En quelque sortes, ces informations sont la partie visible par l'utilisateur final qui s'appuie sur la modélisation classique qui, elle, lui est invisible.

Je pense qu'il aurait été bien de préciser quels éléments tu prends en entrée et ce à quoi tu tends arriver. Difficile d'apprécier "l'histoire d'une analyse", si on ne sait pas d'ou tu pars et là ou tu veux en arriver.

Ce ne serait un problème que si mon choix impliquait une restriction dans la possibilité de représenter une relation. Ce que je ne crois pas. Si j'ai fait ce choix, c'est pour deux raisons opportunistes. D'une part ma représentation à plat se trouve fortement simplifiée, ce qui m'autorise une grande lisibilité sans avoir à l'encapsuler dans un développement que je ne voulais pas faire, celui de l'éditeur de ces définitions. Cet éditeur, c'est Excel, utilisé de façon basique. D'autre part, la programmation de l'IHM repose énormément sur l'enchaînement relationnel et je n'ai pas voulu m'encombrer de complexités dont l'utilité n'était pas démontrée à mon niveau.

En fait je me demandais la raison pour laquelle tu t'imposes cette "contrainte". Quel PoC nécessite cette précondition ? Et je m'interroge toujours sur cette "complexité".
La création de ces définitions est de toutes facons nécessaire pour les réaliser dans l'IHM (recherche, affectation, rapport, ???)

Il est possible que mon étude ne permette pas de tout représenter en terme d'informatique de gestion, mais il faudra me le montrer, car je ne l'ai jamais rencontré. Et je le redis, même si je n'ai pas la source à citer, c'est une chose reconnue et même préconisée par de vrais théoriciens. Ce cher Brouard doit bien savoir ça.

Rien d'impossible dans cette représentation. C'est juste que c'est moins naturel quand tu dois attaquer par le bas : développement ou support. Et ca devient très chiant quand tu as des batchs de chargement (ou des tables de travail).

Je suis entièrement d'accord. C'est le prix que j'ai accepté de payer. Mon choix amène d'ailleurs d'autres complexités, lors du développement du système particulièrement. Je reste persuadé que c'est très secondaire eu égard aux résultats que j'ai obtenu dans un contexte pas aussi exigeant qu'en c/s. C'est un débat dans lequel je ne me noierais pas : comme je l'ai indiqué, s'il fallait redévelopper aujourd'hui, il faudrait en tenir compte.

Qu'entends-tu par "C/S" ?

il permet d'aboutir à un de mes buts : oublier des choses.

J'avoue ne pas saisir.

[mumen]

Je pense qu'il aurait été bien de préciser quels éléments tu prends en entrée et ce à quoi tu tends arriver. Difficile d'apprécier "l'histoire d'une analyse", si on ne sait pas d'ou tu pars et là ou tu veux en arriver.

Mon prochain texte fera la part belle à la feuille d'analyse et permettra de mieux raconter cette histoire.

En fait je me demandais la raison pour laquelle tu t'imposes cette "contrainte". Quel PoC nécessite cette précondition ? Et je m'interroge toujours sur cette "complexité".

Tu n'a pas compris comment je fonctionne, cette contrainte était une libération pour moi à plusieurs égards lors de la conception initiale. Comme je te l'ai dit précédemment j'ai fait ce choix comme une opportunité de simplifier mon code et mon travail. A la réflexion, je clarifierai certainement quelque chose pour toi en te disant que l'abstraction que représente le relationnel était extrêmement difficile à maîtriser pour moi. Il faut juste admettre ce handicap pour comprendre ce qui fonde réellement mon choix. J'ai tenté au début de modéliser "comme il faut" et j'ai échoué, emmêlé dans les fils. J'avais à faire et j'ai tranché le noeud gordien à ma manière.

Aujourd'hui, je le paye parce que mon système est compatible avec très peu des bases de données existantes. D'un autre côté, il est compatible avec toutes les bases de données qu'il génère : cela suffit pour les objectifs que je m'étais fixés à l'époque et cela suffit pour réaliser ce que je désire faire, la présentation d'une maquette, d'une preuve du concept, d'une démo.

Rien d'impossible dans cette représentation. C'est juste que c'est moins naturel quand tu dois attaquer par le bas : développement ou support. Et ca devient très chiant quand tu as des batchs de chargement (ou des tables de travail).

A partir de "C'est juste que..." je ne comprend pas de quoi tu parles, mais j'imagine.

Merci de ton intérêt

[mumen]

Bonjour

Nemek, je n'ai pas répondu à tes deux dernières questions.

c/s c'est mis pour client/serveur.

il permet d'aboutir à un de mes buts : oublier des choses.

Quand un code d'automatisation remplit vraiment sa tâche, il m'enlève le souci de me rappeler que je dois faire telle ou telle chose. Par exemple quand je génère une base de données à travers une feuille, je ne dois pas me soucier de tout un énorme travail d'initialisation et d'administration des bases frontale et dorsale : je peux l'oublier pour me concentrer sur le besoin du client. Mon travail sur l'Analyste et sur ma bibliothèque est un énorme travail d'oubli.

[mumen]

C'est juste oublier que ce qui est automatisable l'est souvent au prix d'une perte de souplesse et/ou de performance.

Je vais commencer ce chapitre, plus long que les précédents, par un passage plutôt technique et même un peu rébarbatif. J’ai dû réécrire les deux premiers sous-chapitres plusieurs fois pour réussir à en être content… en théorie. Ils ont l’intérêt de me positionner sur certains points pas évidents et d’exposer assez finement les cheminements d’une évolution vécue sur un temps assez long. Ce qui suit ces deux chapitres, esquisse une description de la feuille d’analyse et comporte les notions de Champ Distant et de Champ Somme qui sont deux façons originales de formaliser des règles métier. Il s’agit là du cœur battant de la partie analytique du développement sous Nakedata. Si vous n’êtes pas ébouriffé par ces notions, je retourne me coucher. À la fin, je vous raconte une petite tranche de vie, que je mets en perspective par un peu de matériel (copies d’écran, feuille minimaliste).


LE SQUELETTE DU SYSTÈME

La source de la structure des données du développement se situe classiquement dans le moteur de base de données employé. Le concepteur de la base dorsale manipule ses entités (tables, champs, etc.) soit directement en SQL, soit au travers d’un éditeur (tables Access, PHPmyAdmin, etc.), soit au travers d’une couche d’abstraction, comme le sont les objets TableDefs (DAO/ADO) d’Access.

L’idée du Système Nakedata est d’asservir la conception de la structure des données en général (dorsales plus locales), par le biais d’une déclaration formelle rigoureuse. À partir de cette définition, la structure finale de la base de données est créée/mise à jour par code.

Pour ce qui concerne la définition de structure de données, chaque moteur ressemble terriblement à tous les autres, mais chacun a ses spécificités. Pour tout moteur de données, il est absolument certain que l’on a affaire à des bases de données, qui contiennent des tables, qui contiennent chacune des champs, des index et des relations. L’ensemble minimal des propriétés de la structure du dorsal constitue donc un squelette standard que l’on pourrait exprimer comme suit :

• les bases de données, les tables et les champs ont un nom ;
• les champs comportent en plus une définition de type et de taille ;
• les index comportent une liste de champs appartenant à une table ;
• les relations comportent une liste de paires de champs appartenant à deux tables.

Sur ce squelette se posent diverses propriétés universelles, comme la clé primaire de la table, le fait qu’un champ soit requis, que l’index est unique, etc. C’est précisément ce squelette qui a fondé à l’origine la version zéro du Système : il se devait d’être en mesure de représenter de façon formelle toute structure de données possible, d’un point de vue fonctionnel.

Au-delà de ce squelette, le Système permet d’encoder une foule de choses supplémentaires, tant au niveau de la structure, qu’au niveau de l’interface homme/machine (IHM) et qu’au niveau de la navigation (menus, menus contextuels avec appels au code, etc.). C’est ce qui le distingue de la simple structure définie par le moteur et c’est ce qui fait son utilité et sa force. Il est une couche intermédiaire entre la structure et le développement. D’un côté la structure se voit asservie par le système et de l’autre l’IHM se voit asservie par le système. Cette dernière constatation est exceptionnelle par sa portée. Elle a certainement le potentiel de faire rêver pas mal de monde… Mais ne mettons pas la charrue avant les bœufs, n’est-ce pas ?

Nous l’avons vu, le Système est autodéfinissable. Il expose une interface qui permet plusieurs niveaux d’intervention sur le projet global du client.

• Il permet à un agent, jamais encore défini à ma connaissance dans le métier du développement et que j’ai nommé faute de mieux le [/I]cosméticien[I] d’intervenir sur des aspects utilitaires de l’interface, sans entrer dans le codage.
• Il permet au programmeur d’insérer ses points d’appels interactifs au code.
• Il permet en théorie d’intervenir directement sur la structure de la base de données, principalement en tant qu'analyste.

On pourrait dire que le développeur au sens où je l'emploie est chacun de ces agents : analyste, cosméticien et programmeur.

La troisième possibilité d’intervention est le point d’inflexion qui a présidé à la création de la Feuille d’Analyse. Quand j’ai mis en œuvre les premières implémentations du système, je créais la structure à la main, donc de façon redondante. Il aurait été envisageable de faire que le système s’autofabrique par la main du développeur. La création d’un enregistrement dans la table système des champs d’une table client aurait pu entraîner la création physique du champ. C’était la solution la plus simple. Mais je dois avoir du sang de Shadock. J’ai choisi de ne pas faire cette règle de mise à jour instantanée de la structure, mais d’isoler sa création en une passe globale, depuis un fichier de définition extérieur. Je pense pouvoir dire que ce qui m’a vraiment motivé à amorcer cet énorme travail, c’est, de par mon incompétence crasse en analyse, le fait de vouloir y voir clair, et peut-être même de la laisser faire par d’autres…


LA FEUILLE D’ANALYSE

La Feuille d’Analyse est le fichier à plat qui permet de générer la première fois le Système et de le mettre à jour ensuite sans perte, grâce à la réplication de la structure et au mécanisme du Surtypage.

La Feuille d’Analyse permet d’encoder un sous-ensemble du Système. Parvenir à appréhender l’horizon de ce sous-ensemble est assez délicat. Disons que cette limite pourrait se dire par parvenir à « générer une application finale fonctionnelle, du dorsal au frontal, en quelques clics ; intégrer tout automatisme considéré comme suffisamment universel pour trouver sa place, ceci dans l'idée de libérer du temps de programmation en augmentant la puissance déclarative de celui qui procède à l'analyse ».

La feuille d’analyse est peut être un mauvais choix à terme pour ce type de développement. Un fichier XML aurait aussi bien convenu et aurait été beaucoup plus simple à intégrer. Paradoxalement, la feuille d’analyse peut sembler une escapade inutile, mais c’est elle qui permet d’esquisser une séparation entre les deux extrêmes du développement, celui de la programmation et celui de l’analyse. C’est cet exercice de style qui m’a permis d’avancer : l’unique volonté d’avoir une représentation synthétique à la source de mes applications. La feuille a été le point de cristallisation de toute ma réflexion et permettra sans doute de démontrer que je suis parvenu à la rendre réelle.

Concevoir la feuille d’analyse a donc été un exercice de style. Son format est une contrainte qui ne permet pas de représenter intégralement le système. Il est important de réaliser qu’à l’intérieur de cette contrainte du format de définition, chaque détail va prendre son sens, se mettre en place « tout seul », pour définir ce que je peux nommer sans rougir une écriture relationnelle.


DÉFINITION DE LA FEUILLE

Nous voici enfin dans le vif du sujet. Je vais survoler les choses « évidentes » pour focaliser sur les nouveautés. Ce que j’appelle évident, c’est ce que tout développeur comprendra comme n’étant qu’une autre façon de représenter de ce qu’il connaît déjà.

Colonnes de structure

J’ai défini dans ma feuille de base tout ce qui concerne la structure proprement dite : quatre colonnes dans un tableau Excel, nommées Table, Champ, Type et Relation. Une cinquième colonne est apparue aussitôt, celle des Propriétés. Une sixième a suivi, celle des Libellés pour l’utilisateur final.

Chaque ligne du tableau a un sens donné. Par exemple, si je renseigne la colonne Table, on ne s’attend pas à ce que la colonne Champ soit renseignée. Le programme Analyste veillera au grain et génèrera son rapport d’erreur. Il permettra optionnellement de formater la feuille et de lui donner des couleurs.

- Champ calculé

Les champs peuvent être le résultat d’un calcul. Dans ce cas ils sont des champs de requête qui n’ont pas d’existence physique. Le système évoluant ils se sont agrémentés de la possibilité de faire référence à tout champ de l’analyse à travers le schéma relationnel montant et descendant.

- Champ distant

Le champ distant est capable de remonter le flux relationnel à la recherche de l’information qui s’y trouve. Pour illustrer le cas, la ligne de commande peut afficher le numéro de commande à l’aide de cette syntaxe : CléCommande:NuméroCommande où CléCommande est le nom du champ étranger de la ligne de commande établissant leur interrelation. De la même façon, le client peut être rapatrié dans un formulaire de la ligne de commande : CléCommande:CléClient:NomClient. Une valeur numérique peut aussi être rapatriée au cœur d’un calcul : PrixTTC = Arrondir( PrixUnitaire * Quantité * CléCommande:CléClient:CléTypeClient:CléTauxTva:Taux). Cette syntaxe est disponible aussi dans la définition des valeurs par défaut des champs, par exemple, dans la colonne des propriétés du champ PrixAchat de la ligne de commande, la déclaration ValeurParDéfaut = CléProduit:PrixAchat, fera en sorte que le prix d’achat soit mis dans la ligne lors de l’appel du produit. L’existence de cette possibilité déclarative originale permet de réduire de beaucoup le besoin d’accéder manuellement au code SQL, dans la mesure où ce qui est demandé le plus souvent est obtenu par une déclaration dans la feuille.

- Champ somme

Nous voici devant une amélioration très significative du travail d’analyste : le champ somme. Le champ somme ou encore champ@ (sans rapport avec le séparateur des e-mails) est le champ qui permet, symétriquement au champ distant, de descendre le flux de la relation. Il ne concerne que les champs de type numérique, pour lesquels il est justifié de vouloir faire une somme. Ces champs sont des champs physiques et donc existant réellement dans la base de données. Ils contiennent la somme des valeurs contenues dans une entité inférieure, descendante dans le flux de la relation. Ce champ est à redondance automatisée.

Pour illustrer ceci, le champ somme nommé TotalCommande est constitué de la somme du champ TotalLigne de la table des lignes de commandes. Il se déclare indifféremment dans la commande comme suit : TotalCommande@LigneCommande = TotalLigne ou bien TotalCommande@LigneCommande = Quantité * PrixUnitaire. Sur ce champ, il est possible de s’appuyer pour connaître le Total des commandes du client TotalCommande@Commande= TotalCommande.

La syntaxe de ce champ permet plusieurs déclarations successives pour un même champ séparées par un point-virgule. Dans une gestion de stocks, on peut représenter la quantité en stock de l’article comme suit : (sur une seule cellule)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
QuantitéStock@VenteLivraisonLigne= -Quantité; 
    @AchatRéceptionLigne= Quantité;
    @InventaireEcartLigne= Quantité

La puissance d'expression de cette syntaxe est tout simplement prodigieuse. Je l'ai faite sans trop savoir où j'allais. Je voulais juste essayer de formaliser les calculs en temps réel de certaines de mes applications gourmandes en code indigeste et pénibles à maintenir du dedans pour moi et du dehors pour mes utilisateurs. Pour deux lourdes applications de suivi prévisionnel en temps réel, j'ai tout simplement remplacé tout le code de recalcul par cette syntaxe et je l'ai ainsi entièrement relocalisé dans la feuille d'analyse. Depuis lors, soit plus d'une décennie, je n'ai jamais eu besoin de faire appel à une quelconque autre technique de stockage redondant automatisé manuel. Cette technique est à la source de mon second gain de temps significatif en développement, après la génération de formulaires. Les classiques chaînes d'achat et de vente reposent fondamentalement sur les champs sommes et ne pourraient s'en passer.


Pour un développeur, le champ somme est tout bêtement une chose que l’on peut réaliser à l’aide d’un code SQL. C’est trivial. Mais pour un analyste, c’est autre chose. S’il peut facilement s’en sortir dans une ligne de commande avec la création de l’entité TotalLigne, il en est autrement avec celle de variable intermédiaire utilisable dans un calcul, comme TotalCommande. Le concept de somme intermédiaire optimisée, utilisable dans tout calcul n'existe pas ailleurs à ma connaissance.


C'est ce qui fait que dans un développement traditionnel, ce type de formalisation est impossible et donc est considérée comme du développement. Au moment de l’impression du rapport de développement, il devient délicat de connaître exactement les tenants et les aboutissants de ces calculs disséminés dans le développement et même parfois répétés à plusieurs endroits en son sein. Dans le cas de la feuille d’analyse, le rapport de développement est la feuille source. En voilà, un changement de paradigme.


Colonne des propriétés

La colonne des propriétés comporte un grand choix selon les différents contextes. Par exemple un champ numérique peut recevoir la propriété Somme qui indique que chaque pied de formulaire en colonnes comportera la somme de ce champ. Cette somme peut être définie par une expression SQL, permettant par exemple de déterminer une moyenne. Autre exemple, une table reçoit une propriété Protection, comportant un nom, un message et une condition booléenne. Cette propriété se répand aux tables enfants par les relations typées Enfant de. La liste des propriétés est vaste. Elle correspond à l’extensibilité de la feuille d’analyse, que ce soit d’un point de vue général ou d’un point de vue opportuniste, puisque des propriétés spécifiques peuvent être déclarées au sein d’une feuille d’analyse en fonction du développement qui s’y réfère.

Les colonnes décrites ensuite exposent forcément des conceptions nouvelles puisque l’on y sort expressément de la définition de la structure.


Colonne de menu

La feuille contient une colonne Groupe Table qui permet d’aérer la présentation de la feuille. C’est à partir de cette colonne que sera généré le menu initial de l’application.

L’ordre d’apparition des entités dans la feuille est toujours significatif. C’est là où commence le travail d’IHM.


Colonnes d’IHM

La colonne Vues déclare quels champs vont apparaître dans les formulaires en colonnes. Sauf mention contraire, tous les champs apparaissent dans les formulaires Détail.

La colonne Formulaires va permettre de faire certaines déclarations spéciales d’IHM. C’est une espèce de fourre-tout incontournable dont j’ai toujours refusé d’abuser, eu égard à sa portée trop floue. En particulier, elle permet de déclarer l’apparition de sous-formulaires dans les formulaires Détail et, en conjonction avec la colonne Groupe Champ, d’y définir les regroupements de champs en pavés ou en onglets.


Colonne de navigation et identifiant

La colonne Navigation ne se conjugue qu’avec trois mots-clefs. Identifiant, ComboDéfaut et ClicDroit.

Nous avons vu que la clé primaire de la table est privée, qu’elle n’apparait jamais à l’utilisateur final. La notion d’identifiant est ce qui vient prendre la place de la clé primaire pour l’utilisateur. Le champ type Identifiant est un champ calculé, supposé représenter de façon unique et lisible par l’utilisateur final, un enregistrement d’une table. Il est obligatoirement défini en premier champ d’une table. Il est bien sûr optionnel, car toute table ne peut prétendre à recevoir un tel identifiant. Pour une ligne de commande, ce champ peut être déclaré, conformément aux champs distants : CléCommande:NuméroCommande & " " & NuméroLigne

Le ComboDéfaut est obligatoire si la table est au moins une fois déclarée comme table étrangère d’une relation. Il permet de fabriquer la liste déroulante qui sera affichée dans la table d’origine pour déterminer sa clé étrangère. Cette propriété est certes miraculeuse, mais en tant qu’exclusive solution à un problème, elle comporte pour l’heure ses dangers… Quand je parlais précédemment de gavage de combo, je faisais référence à cette propriété de navigation. En fait, une parade est envisageable à cette problématique, qui rendrait possible de choisir un mode d’interrogation et d’affichage moins pratique à l’usage, mais plus léger, selon les circonstances. Dans le monde réel, je n'ai jamais vraiment eu besoin d’une telle adaptation. Une seule fois en clientèle les combos étaient devenus monstrueux et cela posait vraiment des problèmes, d’autant que le nombre de postes dépassait nettement ce que Jet est supposé fournir... La réalité, c’est que mon client avait vu son activité croître fortement, au point de devoir changer d'outil pour un ERP du marché. Exit mon développement, exit le problème.

La propriété de navigation ClicDroit désigne le champ de la table qui permettra d’ouvrir le formulaire détail, et aussi d’ouvrir le menu contextuel dont nous parlerons la prochaine fois. C’est cette propriété qui indique que le formulaire détail sera généré.

UNE ILLUSTRATION

Je suis arrivé, comme d’habitude, chez mon client ce matin à 9 heures. Nous avons passé une heure ou deux à regarder ses notes et remarques sur mon travail de la semaine dernière. Il m’expose une liste de corrections mineures, puis nous décidons de la liste de choses à ajouter aujourd’hui en conformité (ou non) avec la discussion initiale décrivant le périmètre de cette série d’interventions hebdomadaires en cours. La semaine précédente, j’avais clôturé la chaîne des achats par l’avis de facture fournisseur. Cet avis est généré par la réception de marchandises, générée elle-même par la commande. À cette occasion il m'annonce un imprévu : cette facture peut comporter des frais de tous ordres, éventuellement plusieurs par facture. C’est simple et c’est entièrement dans la feuille. Durée de développement, un quart d’heure sans forcer. Mais quand un client demande une entité, c'est qu'elle va servir...

Vers la fin de journée, je fais avec lui le tour de mon travail, avant de répandre, de faire mes sauvegardes et de fixer le prochain jour. Il me dit une chose qu’il avait oubliée le matin : il faut que les frais supplémentaires soient répercutés dans la ligne de facture, pour pouvoir connaitre le « prix réel unitaire du produit ». Sur une facture, il achète 10 couteaux à 2 euros plus 10 fourchettes à 1 euro. Les frais supplémentaires sur la facture s’élèvent à 5 euros. Il veut connaitre son prix réel unitaire tenant compte des frais, soit 1,167 euro la fourchette et 2.333 le couteau. Il faut établir un ratio de la somme des frais sur la somme des lignes, le répercuter sur le prix de la ligne et le diviser par sa quantité.

Qu’auriez-vous fait à ma place ?

J’ai donné une demi-heure de plus. J’ai implanté cette fonctionnalité entièrement dans la feuille d’analyse. Quand je pars ce soir-là, les trois champs de la ligne (Frais, Prix Réel Unitaire et Prix Réel à la Ligne) sont disponibles dans l’IHM. Ils s’affichent en temps réel sans perte de performance lors de tout affichage d’une ligne de facture, quel que soit le contexte (IHM générée ou toute requête). Ce travail a consisté à créer les liges 27 à 30 et 47 à 49 de la feuille d’analyse que vous trouverez en pièce jointe de ce message. Si j’ai passé autant de temps à faire ce travail, c’est que j’ai vraiment ramé dans la conceptualisation, comme d’habitude !

En pièce jointe, j’ai mis une feuille d’analyse autonome permettant la mise en valeur de cette dernière demi-heure de ma journée de travail chez cet industriel. Les copies d’écrans qui sont jointes indiquent fort bien ce que fait l’analyste : il génère et met à jour automatiquement tout ce que vous y voyez. Au risque de me répéter, entre la feuille d’analyse que vous avez dans les mains et l’application dont vous voyez l’interface sur la copie d’écran, il n’y a que deux ou trois clics de souris.


CONCLUSION

Je suis loin d’avoir fait le tour de la feuille d’analyse. C’est une source beaucoup plus dense qu’il ne semble au premier regard. La mise au point d’une feuille d’analyse prend du temps et demande d’incessants allers et retours entre elle et son résultat généré. Le travail cosmétique et la programmation à proprement parler sont possibles dès le début de la conception de la feuille, mais s’impose un temps, celui de la stabilisation, qui coïncide avec la maturation de l’analyse. Sa pratique simplifie drastiquement la conception d’applications de gestion, la mettant à la portée du débutant, mais ne mâche pas le travail d’analyse qui doit conserver toute sa rigueur et son exigence.

Pour revenir à l’incise sur laquelle se fixe mon plan, l’automatisation, comme je l’ai dit en première partie de ce chapitre, l’automatisation a eu un effet contraire : j’ai gagné énormément en souplesse et en performances. La raison tient dans le mot « souvent » de cette citation qui ne ferme pas la porte à un travail cohérent en vue de cette optimisation.

Merci à Claude Leloup pour la correction orthographique.

[mumen]

C'est juste oublier que le mélange code généré / code écrit à la main est une horreur à maintenir.

Dans le système Nakedata, tout code généré est contenu dans l'IHM. L'IHM ne peut pas être modifiée manuellement.

Quasiment tous les appels à du code écrit à la main, sont contenus dans le système. Ils sont référencés par le surtypage.



MENUS CONTEXTUELS

La première formation que je donne à mes utilisateurs, c'est sur l'utilisation du bouton droit de la souris. J'explique que tout élément de l'interface répond au clic droit par un menu contextuel, et qu'il y en a deux principaux. Le menu contextuel de l'enregistrement et celui du formulaire.


Menu contextuel de l'enregistrement

Le menu contextuel de l'enregistrement est toujours disponible sur les fonds jaune clair. Il y a deux teintes de jaune, la plus foncée indiquant que l'on a affaire à un enregistrement de la même table que le formulaire et la plus claire à un enregistrement en relation avec elle.





Un clic droit sur le fournisseur du deuxième écran aura le même effet que sur le premier.
Le menu contextuel de l'enregistrement propose par défaut l'ouverture du formulaire détail déduit de la feuille d'analyse. Il est possible d'en créer plusieurs autres qui se présenteront dans le sous-menu. De même d'autres formulaires de recherche peuvent être créés et seront aussi proposés dans ce sous-menu. Le formulaire de recherche actif apparaît en grisé parce qu'il est le formulaire courant. Les divers affichages peuvent être conditionnés, avec ou sans code, par des droits donnés à l'utilisateur.


Menu contextuel du formulaire

Le menu contextuel du formulaire est disponible sur le fond gris du formulaire, partout où il n'y a pas de contrôle.




Ce menu contextuel concerne d'une part le jeu d'enregistrements en cours, avec ses sélections et son tri et d'autre part le formulaire en tant qu'objet.

L'aperçu est un état conçu comme un formulaire de recherche. Le premier état est la copie conforme du formulaire de recherche déduit de la feuille d'analyse, mais d'autres peuvent être conçus. Ils apparaîtront alors dans le menu contextuel du formulaire. Leur résultat sera affiché en fonction de la sélection et du tri courants.

L'état apporte sur le formulaire de recherche la notion de rupture et donc, de sous-total. Chaque champ de relation reçoit par défaut cette propriété. Les champs date sont aussi des champs de rupture, mais le type de rupture est choisi (jour, semaine, mois, etc.) lors de l'édition.



Les états, en conjonction avec les possibilités des formulaires de recherches prennent en compte une somme impressionnante des demandes d'impressions des clients. Leur emploi est intuitif et ne requiert pas de formation. Dans l'exemple d'un formulaire des lignes d'achat du chapitre précédent, il est très facile de répondre à des questions du type "Achats réalisés par mois pour un fournisseur donné sur l'exercice précédent", ou encore "Achats réalisés par produits le mois dernier". Depuis que j'ai ces états, la demande d'états standards à usage interne est tombée à zéro. Si une demande semble sortir du cadre, soit au plus simple j'ajoute un état ou une recherche, soit au plus complexe, je crée une requête complexe (avec jointures, unions, etc.) sur diverses tables de l'analyse, requête que je viens intégrer dans la feuille d'analyse rigoureusement comme une table en dur. Il suffit d'assigner à cette table la propriété "Requête" pour que toutes les possibilités cosmétiques lui soient allouées automatiquement.

Les seuls états que je crée désormais sont les états sophistiqués destinés à l'usage externe (factures clients, devis, commandes fournisseurs) ou certains états analytiques fortement paramétrés à usage interne ou non.



AJOUT D'APPELS AU CODE PAR MENUS

Les affichages de menus contextuels précédents ne montrent pas encore d'appel à l'interface du développeur. Le système permet d'ajouter divers appels au code. Ces appels sont définis par :

• une icône ;
• une conditionnelle évaluée en fonction du contexte (droits utilisateurs en particulier ) ;
• un libellé évaluable en fonction du contexte ;
• un nom de procédure et ses paramètres.

Pour la copie d'écran suivante, j'ai ajouté un de ces appels dans la partie « AutreChoix » de l'enregistrement de la table Fournisseur :



L'appel au code peut se réaliser avec passage de paramètre explicite ou bien le codeur s'appuiera sur le contexte fourni par l'interface à la bibliothèque système. Pour "Envoyer un mail", la procédure pourra s'écrire "Fournisseur_EnvoiMail()" et le contexte fournira au développeur l'ID du fournisseur, ou bien elle pourra s'écrire "Fournisseur_EnvoiMail( IdFournisseur)", le remplacement par la valeur correcte étant pris en charge par l'automatisme d'appel au code.

Les possibilités d'ajout de ces autres choix dans le système sont au nombre de cinq selon la partie concernée :

• enregistrement ;
• jeu d'enregistrements ;
• jeu d'enregistrements d'un formulaire ;
• champ ;
• champ d'un formulaire.

Ces points d'appels se retrouvent tout naturellement dans les menus contextuels.

Ces cinq emplacements d'autre choix m'ont toujours suffi à placer l'énorme majorité des points d'appel au code de toutes mes applications.

Le plus souvent, quand un client habitué à mon interface me fait développer quelque chose, je termine ma journée en lui disant : "c'est fait". Je sous-entends par là que je n'ai pas besoin de lui dire où il va trouver la fonctionnalité, car il le sait déjà. Mieux, il savait d'avance où je la créerais en me la demandant.

Aux points d'appel standards au code, il reste à ajouter une possibilité qui s'impose quand le traitement demandé ne correspond pas à une entité particulière de l'application, comme une table ou un formulaire. Dans ce cas, c'est tout simple, c'est un menu. Le menu est constitué d'une liste d'items organisés hiérarchiquement et comportant, comme pour les autres choix une icône, une évaluation conditionnelle, un libellé évaluable et un nom de procédure.

Les appels au code par les autres choix sont très bien vécus par les utilisateurs. Les fonctionnalités sont toujours disponibles là où on les attend, c'est-à-dire dès que l'on voit l'entité intéressée. Si dans l'exemple précédent, je visionne la facture fournisseur et que je désire lui envoyer un mail, je n'ai pas à ouvrir un choix de menu pour trouver la fonction et ensuite chercher le fournisseur : je fais le clic droit et je trouve directement la fonction. Cela fait partie du rangement spontané que j'ai déjà évoqué. Ce rangement est aussi bien effectif pour l'utilisateur que pour le programmeur. D'ailleurs, il a lieu majoritairement lors de l'analyse.



AJOUT D'APPELS AU CODE PAR LA STRUCTURE


Champs calculés

La première possibilité d'appel au code de la structure provient des champs calculés, bien sûr. Dans la feuille d'analyse, une procédure nouvelle doit être référencée en en-tête.


Appels événementiels

Dans le cas des appels structurels au code, il faut bien entendu mentionner la structure dite des règles de validation. Cette table du système rattache à la table de l'analyse un certain nombre de conditions et d'actions liées à l'événementiel. Les règles et actions déclarées seront lancées lors des événements correspondants des formulaires : avant ou après mise à jour, sur insertion, avant ou après suppression, etc.

Je ne serais pas exhaustif si je ne mentionnais pas l'appel au lancement de code au démarrage de l'application.



AJOUT D'APPELS AU CODE PAR LA PERSONNALISATION DE FORMULAIRES

Avant d'envisager de sortir du système pour réaliser une fonctionnalité qui lui serait hors de portée, il faut d'abord épuiser les possibilités du langage de formulaires. Par son biais, un langage déclaratif primaire, il est possible de se référer à toute propriété du formulaire généré, ce qui inclut évidemment tout l'événementiel. La porte est largement ouverte.

J'aurai plus vite fait de mentionner la grande lacune du langage déclaratif que d'énumérer ses possibilités. Ce langage a toutes les possibilités techniques de l'éditeur de formulaires natif d'Access, mais il devient compliqué si l'on veut dessiner finement un formulaire joli, qui sorte de l'ordinaire. On peut ajouter des boutons à un formulaire donné si l'on veut, mais l'intérêt est faible si l'on considère que les menus contextuels par « Autre choix » répondent extrêmement bien aux contraintes du développement.



AJOUT D'APPELS AU CODE HORS SYSTÈME

Quoi qu'il en soit, la base de données reste une base de données et le formulaire un formulaire. Rien n'empêche un programmeur de concevoir son formulaire de façon traditionnelle. Je fais cela régulièrement lorsque je conçois des questionnaires destinés à gérer des états complexes. J'ai même un procédé qui me permet de fabriquer à la main un état sur une table et de l'asservir au formulaire de recherche de mon choix.

De même les états complexes font lourdement appel à du code, que l'on peut considérer comme hors du système.

La porte n'est fermée ni au code ni à l'interface hors système. C'était d'ailleurs la condition sine qua non à l'origine de ce développement, de pouvoir reprendre le contrôle si le système venait à faillir.



UNE MISE EN SITUATION

Mon client me demande la possibilité d'envoyer des mails groupés. Pas besoin de pièces jointes, mais besoin de pouvoir sélectionner dans tous les sens. C'est un expert-comptable qui a quelques collaborateurs. Pour la petite application de suivi que je lui ai faite (250 lignes dans la feuille, 20 tables et 200 champs), le client est central. Les entités majeures sont des obligations, des lettres de mission, un planning.

Je crée une structure de mails à deux tables, le modèle est le parent et le détail l'enfant.

D'abord le collaborateur doit renseigner les divers champs du modèle de mail, principalement l'objet et le message, ensuite il lui faut alimenter le détail et enfin envoyer le mail.



Les champs apparaissant en vert clair sont des autres choix des champs. Ils sont secondaires pour ce problème, ils simplifient le fait d'insérer des clients manuellement à un mail.

Pour gérer l'ensemble des fonctions de mail, j'ai ajouté ceci à ma table MailModèle, dans le champ "Autre choix du jeu d'enregistrements" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
=\IsNull([DateEnvoi])\"Ajouter des clients au mail"\MailModèleAjouterClient_Q()
=\Not IsNull([DateEnvoi])\"Réinitialiser le mail entier"\MailModèleRéinitialiser()
=\\"Envoyer le mail"\MailDétailEnvoyer([CléMailModèle])

Voici le menu suite à cette modification :



Le premier choix va chercher parmi une liste, si un et un seul formulaire de recherche est ouvert. Il récupère la source des enregistrements du formulaire (donc selon ce qu'a sélectionné le collaborateur), ajoute les clients au mail et demande confirmation avant d'entériner la transaction de création. La liste des formulaires valides est calculée en fonction du fait qu'une relation avec le client y apparaît. En d'autres termes, tout formulaire de recherche présentant le client est un candidat à l'alimentation du mail. Donc, toutes les entités voulues au départ (planning, obligations, etc.) sont présentes sous toutes leurs formes. Ceci inclut bien sûr le détail du mail, permettant de dupliquer un mail antérieur ou de s'en servir comme d'un groupe.

Voici le message qui apparaît si aucun formulaire valide n'est ouvert :



J'ai fait ce développement en une bonne demi-journée, de l'interview à la formation. J'ai utilisé la génération rapide de la structure et de l'IHM depuis la feuille d'analyse, j'ai bénéficié de points de branchement naturels, mais surtout, grâce à l'impeccable homogénéité de mes interfaces, j'ai pu aisément transcender la notion la plus complexe (sourcer le mail) de ce petit travail en faisant un véritable code "méta" de recherche sur la structure. Lors de l'interview préliminaire, mon client était empêtré avec la détermination des entités nécessaires à l'alimentation de ses campagnes de mails. Il changeait d'avis tout le temps. Parce que j'avais de bons outils, j'ai pu trancher pour l'oubli définitif de cet aspect du problème.




CONCLUSION

C'est juste oublier que le mélange code généré/code écrit à la main est une horreur à maintenir.

En évitant de générer du code, j'ai évité cette horreur-là. En générant mon IHM, je me suis enlevé une dose énorme de code répétitif. En systématisant/automatisant à chaque fois que possible les différentes tâches du développement, je me suis encore libéré des contraintes lourdes.

C'est ce qui fait que quand je travaille sur besoin du client, je ne pense qu'à ce besoin, de l'interview, en passant par l'analyse, le cosmétique et enfin le codage. Ces différentes spécialisations sont clairement séparées et je peux me reposer sur des choses fiables et dans lesquelles j'ai confiance.

Remerciements à ClaudeLeloup pour sa relecture orthographique

[mumen]

C'est juste oublier que le seul moyen pour que les spécifications soient assez précises pour être "traduites" directement en code, dans le cas général du moins, c'est qu'elles contiennent au moins autant d'infos que le code lui-même. Autrement dit le code est plus facile à écrire.

Nous ne sommes effectivement pas dans le cas général. Nous sommes dans le cas particulier de l'informatique de gestion, qui est un sous ensemble du développement en général auquel se réfère I Believe.


LE SYSTEME


La source système

La véritable source interne de l'application sous Nakedata, celle qui contient en puissance tout ce qui est sera généré, c'est la base de données source de l'application frontale. Dans l'application finale, elle a son menu, nommé « Système », qu'on ne peut voir qu'en mode développement.



Cette base de données système est hautement plus compacte que les objets d'IHM générés. Elle est reconstituée à chaque génération, par la somme de la feuille d'analyse et du surtypage.


Les sous-applications

Chaque application finale est définie par la somme de plusieurs feuilles d'analyse. Chacune de ces feuilles est une sous application de l'application finale qui comporte ses menus, ses formulaires, etc.

La sous-application principale, celle du client, est toujours accompagnée des sous-applications « Fichier », « Administration » et « Système ». Ces trois sous applications sont communes à tous les développements d'applications finales. La sous-application « Système » sert uniquement au développeur et n'est donc pas incluse lors de la publication sur les postes du réseau (commande « Répandre l'application »).

Les trois sous applications communes comportent leur propre surtypage indépendant. Il est localisé dans la base commune à tous les développements : Système_Data. C'est ce qui fait que les modifications du développeur sur son propre outil le suivent dans toutes ses applications & sans qu'il y pense -.


Vue d'ensemble

Nous avons donc pour définir le système complet de Nakedata :

• trois feuilles d'analyse « Système » ;
  
  
• une feuille d'analyse décrivant l'application dite « Analyste » ;
• une application dite « Analyste », qui inclut le code zéro de génération d'applications, plus l'environnement de génération d'applications ;
• une base de données Analyste_Data de l'application Analyste, qui contient les données de l'environnement de génération ainsi que d'autres informations ;
  
  
• une bibliothèque dite « Système » comportant le code zéro de génération d'IHM, plus le code de fonctionnement de l'IHM ;
• une base de données Système_Data, commune à tous les développements et qui ne comporte que des tables, dont le surtypage système, diverses préférences, ainsi qu'une bibliothèque d'informations du développeur.

L'application client comporte :

• une feuille d'analyse au nom de l'application qu'elle décrit ;
• une application frontale, générée d'abord, développée ensuite ;
• une ou plusieurs bases de données dorsales, comportant les données client ;
• tout fichier utile aux spécificités du développement.

Les deux processus de génération

• Avec les quatre feuilles d'analyse plus le surtypage, au moyen du code zéro de génération d'applications, on fabrique :
  
  • la structure de la base de données dorsale ;
  • la structure et le contenu de la base de données source de l'application frontale.
  
  
  
• Avec la base de données source de l'application frontale, au moyen du code zéro de génération d'IHM, on construit :
  
  
  • l'application frontale, du client (sous applications Fichier, Client et Administration) ;
  • l'application développeur (sous application Système).
  
  

L'ANALYSTE


Répertoire de l'analyste

Le répertoire de développement contient à sa racine l'application autogénérée dite l'Analyste. Ce répertoire contient, en plus de la feuille Analyste, les feuilles Fichier, Administration et Système. La feuille Analyste décrit l'interface IHM sur laquelle s'appuie l'acteur analyste pour générer les bases de données système de ses applications client.


Répertoires des applications

Les applications « normales » sont situées dans des sous-répertoires de l'analyste comportant au minimum la feuille d'analyse qui représente la première source du développement. Après génération, les sous-répertoires vont forcément contenir l'application frontale, sous la forme d'une base de données Access, nommée comme la feuille. Cette base de données est constituée de deux types d'objets. Les objets recalculables et les objets du développeur.

Le contenu de la table des surtypages constitue le point de départ de ce qui est la deuxième source du développement. Le reste provient des objets créés par le développeur (modules, requêtes, états personnalisés, etc.).

Le sous-répertoire de l'application contient aussi en général la base dorsale, initialement nommée comme la feuille plus la mention « _Data », ou du moins une copie de celle-ci en mode de développement réel. La logique du système permet de maintenir plusieurs bases dorsales, soit par exemple pour partager une source commune à plusieurs applications compatibles, soit encore, pour permettre de scinder le dorsal en plus petites parties.


Utilisation de l'analyste

Un code balaye le répertoire courant et ses sous-répertoires à la recherche de feuilles d'analyses. Il localise les bases frontales déjà générées, ainsi que leurs connexions aux bases de données dorsales, par la base de registres. Il charge un ensemble de statistiques, dont on retrouve une partie dans ces deux écrans majeurs de l'Analyste.



Nous reconnaissons évidemment le type d'IHM déjà montré auparavant. Chaque champ vert clair recouvre un menu d'appels de fonctions. Les libellés des contrôles sont explicites, mais ne sont pas exhaustifs. Un double clic fera ce qui est dit, mais le clic droit ouvrira un menu contextuel dont l'ensemble, assez fourni, regroupe toutes les fonctions annexes utiles à l'analyste. « Mise en forme de la feuille », « Répandre l'application », « Créer base à générer », « Ajouter à la sauvegarde du jour », « Changer la connexion », etc.

La commande « Créer une base à générer » permet d'établir une copie de la base en question, à l'exclusion des objets régénérables, ne conservant ainsi que les objets créés par le développeur.


Quelques statistiques de l'analyste

Trois colonnes du formulaire de recherche des applications sont extrêmement parlantes, si l'on s'y attarde un peu. Il s'agit des colonnes :

• « Feuille » = nombre de lignes dans la feuille d'analyse ;
• « Surtyp. » = nombre d'enregistrements dans la table de surtypage ;
• « lig. Code » = nombre de lignes de code dans l'application finale.

Les trois applications qui comportent le plus grand nombre de lignes dans la feuille d'analyse (autour de 700) sont trois de mes applications client :

• 730 correspond à un industriel qui gère ses achats et ses expéditions avec ce logiciel ;
• 677 est un équipementier pour qui ne je ne gère plus que la partie ingénierie (PDM), puisqu'il a opté pour un ERP du marché en remplacement du suivi d'affaire en temps réel (32 champs@), achats, vente, production et stock, que je lui avais développé jusqu'alors (1160 lignes dans la feuille) ;
• 744 est un couvreur qui gère avec cette application son suivi de chantier en temps réel (44 champs@), ses achats, ses ventes, son stock et d'autres choses.

Le système n'est pas une application, mais il partage certains éléments de comparaison avec elle :

• Lignes de code dans Système.mdb : 34636 ;
  
  
• Lignes de feuille dans Système.xls : 394 ;
• Lignes de feuille dans Administration.xls : 216 ;
• Lignes de feuille dans Fichier.xls : 8 ;
  
  
• Lignes de surtypage dans Système_Data.mdb : 600.

Environnement de l'analyste

En plus des fonctions directement utiles à la génération d'application, telles que les références des propriétés et fonctions, j'ai pu générer d'autres outils qui trouvent naturellement leur place au centre des applications, tels qu'un historique de révision des applications, une centralisation du code de toutes les applications pour recherche d'algorithmes, une compilation de bases de connaissance internet à une époque le modem limitait les vitesses connexions. La structure de ces outils est déclarée en toute logique dans la feuille d'analyse de l'Analyste.



LES FORMULAIRES


Génération de formulaire suite à génération/régénération de l'application

Lorsqu'une feuille d'analyse est modifiée avec impact sur la structure, quand ensuite, l'application finale est générée puis lancée, alors apparaît une question rituelle, qui témoigne de toute l'attention qu'il faut pour développer l'IHM :



Si nous regardons l'écran précédent de l'analyste, à la ligne de l'application dans la colonne « Révision », nous trouvons le chiffre « 7 ». Ce chiffre indique que j'ai généré sept fois l'application de démo qui m'a servi lors du troisième chapitre de cette publication.

Cela implique que j'ai dû répondre, au plus, sept fois à cette question par la positive, pour que toute l'IHM qui est contenue dans cette copie d'écran soit fabriquée.


Modification manuelle d'un formulaire

Quand une application est ouverte en mode développement, les menus contextuels comportent des choix supplémentaires permettant d'accéder aux objets de développement (table, champ, formulaire, etc.). Voici le menu obtenu par un clic droit dans le formulaire que je désire modifier.



Je clique le choix en surligné dans la copie d'écran et j'obtiens le formulaire qui permet de modifier les formulaires :



Je clique sur l'onglet « Contenu » et j'obtiens ainsi la source du formulaire détail de la facture fournisseur :



Il s'agit d'un champ texte éditable. Si je fais un clic droit dans ce champ, une ligne du menu contextuel m'indiquera que ce champ n'est pas encore surtypé. Je peux choisir de modifier ce que je désire dans cette définition, par exemple de déplacer le détail de la facture dans un onglet, ou bien d'enlever un champ, etc.

Pour recréer le formulaire détail de la facture fournisseur selon mes modifications, un choix contextuel du formulaire système est à ma disposition, ainsi qu'une touche d'accès rapide lui correspondant.

Si après mise à jour, je refais un clic droit dans le champ « Contenu », le menu contextuel m'indiquera qu'il est surtypé et me permettra de localiser ce surtypage dans la table des surtypages. Il est à noter que, du coup, toute modification du contenu du formulaire en question en provenance de la feuille, ne sera plus intégré dans le formulaire final. Le formulaire théorique créé par l'Analyste sera visible dans la table du surtypage, mais c'est la modification que j'ai apportée manuellement qui aura la primeur.

C'est cet état de fait qui impose des phases d'analyse par parties de la feuille. Quand une partie de feuille est stabilisée, alors on peut commencer à surtyper.



CONCLUSION


C'est le dernier texte technique d'une liste que je me suis imposée avec plaisir, même si c'était la liste d'autre chose ! I_Believe_In_Code me pardonnera sans doute cet emprunt maladroit, mais pratique, je l'en remercie grandement.

Je ne sais pas faire de plan, j'écris comme je code ! Comme je l'ai dit ailleurs, je ne sais jamais ce que je vais coder d'avance, je sais juste où j'aimerais aller et j'y vais par essai/erreur. J'ai eu, au cours de ces rédactions, l'impression d'en dire beaucoup sur ce qui est indiscutablement pour moi, une réalité : on peut générer des applications à partir d'un code dense et abstrait, la feuille d'analyse. Je ne sais pas si j'ai été clair, je sais juste que j'ai essayé d'enfoncer le clou et d'améliorer ma propre vision des choses pour vous la communiquer au mieux. Je n'ai pas obtenu de retombées ou très peu de mes lecteurs. Si j'avais été à côté de la plaque, j'en aurais eu de sérieuses. Je considère comme positif de ne pas avoir reçu de volées de bois vert. A moins que personne n'ait réussi à me comprendre ! C'est une position difficile à décrire et à vivre. Comme il est dit en science de l'éducation : « On ne sait pas ce que l'on a écrit tant que l'on n'a pas été lu » ! et commenté. Je serai très content de savoir si quelques personnes ont réussi à me suivre.

[nnovic]

Hello,
Personnellement, je n'ai rien compris... Je ne connais pas bien les bases de données ou les applications de gestion, alors je n'ai toujours pas saisi en quoi le système que tu décrits est révolutionnaire...
Je me suis probablement perdu en chemin: tes messages gagneraient à être plus concis, peut-être...
Mais bon, ça à l'air vraiment bien, donc je dis bravo et merci d'avoir partagé cela avec nous.

[deathness]

Pour avoir fait un générateur d'application (un gros : plus de 4 ans de boulot), son but n'était pas qu'en quelque clic on pouvait générer ce que l'on voulait.

Son but était de pouvoir permettre à des gens purement métier (pas des programmeurs donc) de pouvoir spécifier (avec une notation standard donné) le comportement de son application (processus, construction d'ihm avec un éditeur WISIWIG, base de donnée très simple à faire).

Il y a bien sur pas mal de boulot de spécif à faire, mais moins qu'en codant tout et surtout on a "transvasé" les compétences à avoir. Bien sur, ce logiciel permet de décrire des processus uniquement dans un domaine précis, le métier de nos clients! Cette limitation est, il est vrai, assez essentiel pour avoir réussi à le faire en moins de 10 ans... Même si on pourrait l'étendre à bien d'autre domaine, il a ses limitations.

Le pari est plutôt réussi, une personne sans connaissance en info arrive aujourd'hui a faire des appli professionnel complète et complexe, avec ou sans base, en ligne ou non. D'autre avantage c'est l'uniformisation du code des applis et des plateformes sur lequel il tourne, autant de boulot en moins de maintenance derrière.

[mumen]

Les textes que j’ai publiés sur ce fil, s’ils n’ont pas le bonheur d’être limpides, ont quelques qualités quand même.

D’abord celle d’exister : ils montrent que je sais de quoi je parle. Ensuite ils donnent des indices de compréhension à qui veut bien prendre le temps d’y pénétrer. Et enfin, ils me permettent, à moi, de savoir de quoi je parle.

J’ai découvert en l’écrivant, en suant, que le cœur du paradigme de ma recherche, c’était la base de données système. Une dernière phrase indigeste : c'est l'ajout d'une couche d'abstraction normalisée entre la donnée et l'interface homme/machine qui fait tout l’intérêt de cette recherche et qui en est l’idée la plus pure. Le reste en découle. Feuille d’analyse + surtypage d’un côté et IHM client et développeur générées.

Cette séparation entre le moteur et l’IHM permet de penser deux axes fondamentaux :

• pour une analyse donnée, voire pour une partie de l’analyse, un développement final, quel que soit le moteur de données, à condition qu’il ait été intégré, bien sûr. Il suffirait qu’une propriété de la base de données déclare le nom et sa version du moteur de la base de données pour que le code multimoteur s’adapte à ses spécificités ;
  
  
• pour une analyse donnée, un développement d’interfaces quel que soit le langage ou l’environnement. Je parle des environnements tels qu’Access, bien sûr, mais aussi, pourquoi pas Excel ou Word ? Qui dit que les aficionados d’Excel ne seraient pas heureux de pouvoir interagir facilement avec une base de données depuis leur environnement favori ? Il suffirait qu’un très bon codeur Excel fabrique une interface type, pensée comme le sont les miennes, que je puisse intégrer dans Nakedata, pour que des macros VBA Excel soient générées. Facile pour moi, moins pour ce codeur. Et internet ? Aujourd’hui, si je ne génère pas d’interface HTML/CSS/PHP/JAVA, c’est parce que je ne sais pas écrire dans ces langages. Fournissez-moi un template (il y a du boulot), ensuite vous verrez comme c’est facile de transformer en un clic une feuille d’analyse, la vôtre, n’importe laquelle, en un code internet qui attaque une base de données.

Et le mieux, c’est qu’une même application peut être pensée d’entrée de jeu multi environnement : je crée une base MySQL que je présente avec une interface générée en HTML ; en plus, j’attaque la base MySQL, avec la même interface générée autrement, directement par un frontal de type Access ou autre, que je choisis selon un des deux modes d’approche : soit le mode économe, directement connecté et à l’enregistrement ; soit un mode caché localement qui permet les listes gourmandes ; soit les deux.


Je n’ai pas terminé. Une autre qualité de ces textes était de préparer au meilleur.


Vous voulez de la concision ? Je vais être concis : croyez-moi.


Croyez-moi quand je vous dis que demain, ma mère fera du relationnel comme elle fait du traitement de texte, croyez-moi quand je dis que je sais comment faire pour que ce jour advienne.

Croyez-moi quand je vous dis que le petit entrepreneur fera lui-même sa base de données, que des générations de stagiaires pourront faire du travail propre et maintenable dans ce domaine.

Croyez-moi quand je vous dis que la notion d'interface du système d'exploitation peut changer du tout au tout en s'homogénéisant fortement pour servir la base de données et l'utilisateur final.

Croyez-moi quand je vous dis que la base de données va servir comme jamais encore.

Croyez-moi quand je vous dis que l'on a un chaînon manquant de l'informatique à portée de main. Venez le déployer avec moi, pour qu'il soit libre d'aller jusqu'où il doit.

Croyez-moi et venez, vous laisser tenter par un jeu nouveau, aux règles encore à écrire, dont j'ai à peine esquissé les fondements, dont je peux démontrer la possibilité. J'ai du matériel pour faire vraiment rêver les visionnaires, les Early Adopters qui existent forcément en nombre en un lieu tel qu'ici.

Croyez-moi enfin si je vous dis que, ici sur Développez, tout le monde peut virtuellement se sentir concerné par ce projet, pour ainsi dire quelque soit le langage qu'il utilise.

Le nouveau paradigme, c'est la programmation méta généralisée d'applications de bases de données, c'est la mise à distance de la base de données et de son interface homme/machine. C'est très important, c'est énorme, cela ouvre la porte à ce que très peu de gens ont fait ici, même les plus puissants d'entre vous : la méta-méta-programmation.

Quand on maîtrise la fabrication d'applications comme je le fais depuis douze ans avec Nakedata, on pense différemment : on peut commencer à fabriquer des applications par code (faire des feuilles d'analyses par code)... Le domaine est vaste et fascinant. Ceux qui ont fait beaucoup de conversion d'application, au point de la généraliser, peuvent peut-être en comprendre un des aspects. Les chercheurs et théoriciens qui ont planché sur des analyses "universelles" trouveront ici de l'outillage expérimental incomparable. Je me suis beaucoup amusé avec cette notion qui m'a fait même expérimenter l'intégration en douceur de toutes les analyses éparses (tableaux Excel entre autres) disséminées sur les postes de l'entreprise en automatisant leur raccordement à la base de données centrale.

Quand on maîtrise la fabrication d'applications comme je le fais avec Nakedata, on peut commencer à prendre un recul tel, qu'on puisse se mettre à penser une surinterface universelle qui englobe une vision "sujet" sur tout "objet" de l'analyse. Imaginez un système qui permette nativement de prendre des notes sur tout, de faire forum, vote, associations d'images, plans, fichiers, co-association, et ceci sur toute entité de l’analyse... C'est de la méta-utilisation, qui réunit deux problématiques élémentaires de la mémorisation d'informations en un dualisme objet/sujet, qui vient combler une lacune profonde du développement de gestion. Un de mes plus beaux rêves.

Vous ne connaissez pas encore l'ivresse que cette maîtrise procure, celle de se sentir démiurge de la base de données.

Vous savez ce qu'il y a de pire dans l'ivresse ? C'est de s'y retrouver seul.

Comment procède-t-on dans notre monde à l'heure actuelle pour faire connaître une technologie, un concept nouveau ? On monte une structure commerciale, on lève des fonds et on communique par les canaux reconnus. On fait la preuve par l'argent. Quand ça passe à TF1, tout le monde ou presque y croit.

Moi, ce n'est pas la voie que j'ai choisie. Je n'ai pas de désir de monter une startup à partir de mon invention et de me faire, selon l'expression consacrée des "parties génitales en métal précieux". Je me suis usé très vite sur cette obsession universelle. Ce n'est pas ce qui me fait rêver.

Je sais que le brevet bloque l'innovation. Je ne sais aussi que trop que, si mes idées sont bonnes, à les lâcher dans la nature, elles seront récupérées sans vergogne et sans honte par les rois du pétrole, je sais que l'avidité mène le monde et qu'elle écrase les "faibles". Je sais que je prends la voie du faible.

Je ne peux être fort qu'accompagné par d'autres faibles. Richard et Linus ont montré la voie. Voilà ce que je veux à terme : mettre en licence libre mon matériel. Développer en équipe une version solide de Nakedata.

Qu'est ce que j'attend de vous ?

Soyez curieux. Questionnez moi et je vous répondrai, motivez moi et je vous fournirai largement de quoi vérifier ce que je dis.

[nnovic]

Je crois surtout, comme dirait Boileau, que ce qui se conçoit bien s'énonce clairement.

[mumen]

Bonjour

Nnovic je te remercie pour tes encouragements.

Je crois surtout, comme dirait Boileau, que ce qui se conçoit bien s'énonce clairement

Quand tu dis cela, je me demande si tu réalises ce qu'un telle réflexion peut avoir de blessant pour quelqu'un qui prend tous les risques. Je me répète, mais il s'agit d'innovation et donc de choses encore jamais expliquées et plus encore, je suis la dernière personne à pouvoir survoler ce travail pour un fournir quelque chose de facile à comprendre. Oh je ne t'en veux pas , mais laisse moi ajouter ceci en guise de réponse du berger à la bergère : "it takes two to tango".

Au plaisir


Deathness, ton témoignage montre que la voie que j'ai prise avec Nakedata à déjà été explorée par d'autres et que c'est une voie féconde. J'en suis ravi, merci. La seule chose qui me désole, c'est que la chance que j'ai de voir ce travail en action et de pouvoir le comprendre vraiment, est sûrement proche de zéro. Tu confirmes ?

[mumen]

Bonjour

J'ai préparé deux applications de démonstration que je met à votre disposition.



ACCESS

Pour que mes démos puissent fonctionner, il faut avoir une version d'Access installée entre 2000 et 2010. Normalement. J'ai testé vraiment sur 2010.

Ceux qui n'ont pas Access peuvent télécharger le runtime Access 2010 à cette adresse Microsoft Access 2010 Runtime

J'espère que tout se passera bien de ce côté-là.



MONDIAL

J'ai fabriqué cette démonstration à partir de données publiques situées ici : Mondial

Il s'agit de données géographiques compilées depuis diverses sources.

Le travail que j'ai effectué pour obtenir cette base de données est double. D'abord j'ai lu la structure des fichiers pour créer la base réceptacle et ensuite j'ai créé le code de recopie des données. En deuxième temps, j'ai mis au point la feuille d'analyse. Cette feuille est contenue dans l'archive. Elle permet de constater ce qui se passe entre la feuille et l'application.

Télécharger l'application Mondial

Cette application ne comporte ni surtypage ni code. Ce qui signifie qu'elle est égale à sa feuille.



SUIVI

J'ai créé la feuille d'un suivi de chantier qui correspond à une petite entreprise du bâtiment désireuse de suivre son réalisé au jour le jour en fonction de ses prévisions, ainsi que de gérer le compte de ses clients. Cette feuille emploie une dizaine de champs sommes, ce qui en fait une bonne démonstration de cette technique. Ouvrez un chantier pour voir où se situent ces champs et comparez avec la feuille.

Télécharger l'application Suivi

Cette application est supposée comporter des appels à du code pour gérer les lettrages. Ils ne sont pas branchés dans cette version.



MISE EN OEUVRE

Extrayez l'archive dans un dans un répertoire. Vous trouverez trois fichiers :

• Application.mdb
• Application_Data.mdb
• Application.xls

Les données sont dans la base Application_Data.mdb. La feuille d'analyse n'est pas utile au fonctionnement de l'application, elle est mise à des fins démonstratives.

Au premier lancement de l'application, l'application va vouloir localiser sa base dorsale, celle qui finit par _Data :



Lors de la toute première utilisation d'une application Nakedata, vous verrez ceci :



Ceci indique qu'une entrée de la base de registre à été créée sur HKCU/Software/Nakedata. C'est l'unique intervention des applicatifs Nakedata sur votre machine.



DEMO

Les applications créées avec Nakedata ne requièrent quasiment pas d'aide ni d'explication à la mise en route.

Le double clic ouvre les formulaires détail dans les champs jaune clair. Le clic droit ouvre un menu contextuel à tout endroit des formulaires.

Les lignes bleu clair sont les lignes de sélection. Certaines optimisations de saisies, contrairement aux classiques "wildcards" (*, ? et []) ne sont pas intuitives, notamment dans les dates. L'utilisation de séparateur point-virgule permet d'ajouter une recherche de type "OU" et "ET" par l'ajout de deux points-virgules consécutifs.

Chaque formulaire en colonne est redimensionnable. Pour les formulaires de recherche, la zone sensible est située sur et sous les boutons de tris, en un endroit pas forcément évident à trouver à priori. Toute modification de taille est mémorisée pour l'utilisateur en cours.



?

1700 visites et plus sur ce fil. Quelques enthousiasmes, quelques réflexions périphériques, quelques sarcasmes, le tout sans suite. Qui m'a suivi ?

Par le fait du laconisme rencontré en écho sur mon fil depuis près de deux mois que je le maintiens, je ne sais quasiment rien des pensées et réactions de mes lecteurs. Je suis juste toléré. C'est un manque assez cruel, considérant mon investissement.

Ce projet a dépassé ce que peut faire un homme seul. Je ne vois pas d'autre moyen à ma portée pour le faire connaître et parvenir à mon objectif que de publier sur un site constitué de mes pairs en développement.

Il y a un pouvoir individuel à prendre temporairement sur l'innovation, dans l'esprit du libre. Il y a une foule de petits professionnels qui sont en manque de gestion. Il y a une incapacité de chacun à faire du relationnel pour s'organiser. Je montre une voie, je donne mes recherches et on me regarde à peine, pourquoi ? Ne laissez pas passer l'occasion, au moins, de vous y intéresser, de me permettre de répondre aux questions. Ne laissez pas crever ce qui est si prometteur, pour de mauvaises raisons, comme une personnalité qui pourrait vous déplaire et/ou la certitude qu'un homme isolé ne peut rien faire de nouveau en informatique. Rappelez vous php.

[Pierre Fauconnier]

Salut.

J'ai lu, et relu toutes tes interventions (si si, je le jure). J'ai même téléchargé ton exemple de suivi de chantier sur une vm de test, histoire de ne pas mettre ma machine de prod en rade (on n'est jamais trop prudent). Au passage, je ne comprends pas pourquoi j'arrive sur le site d'Etienne Pailleret après le téléchargement (en plus sur un lien de téléchargement d'un pdf qui renvoie une jolie 404).

Ok, il y a une application qui permet de gérer un chantier (enfin, je suppose, je n'ai pas testé). Mais je me demande pourquoi il faut du 2010 alors que l'interface ressemble à de l'Access 97, voire encore plus vieux et que l'appli gère des bases JET (mdb), qui ne permettent notamment pas les triggers.

Je suppose que cette application a été autogénérée. Donc ok, tu as créé une application qui crée des applications. C'est une prouesse technique que je peux reconnaitre, et je dis "chapeau", sincèrement.

Mais j'utilise depuis longtemps une application qui fait la même chose (en mieux, désolé, et sur base d'une "feuille d'analyse" bien plus ergonomique que ta feuille Excel - et je suis pourtant un fan d'Excel! - et qui m'offre beaucoup plus de possibilités). Cette appli de création d'appli s'appelle ACCESS.

A ce stade, je ne comprends pas le but de ta démarche. Tu as essayé de réinventer Access? Parce que dans les faits, tu as créé une sorte de "complément" Access qui permet de créer une appli Access au départ d'une table d'analyse Excel. Or, même si j'adore Excel, je préfère concevoir mes tables, requêtes, formulaires et états dans un environnement graphique plutôt que spécifier toutes les propriétés dans une feuille Excel.

Parce que créer une petite application de suivi de chantier, de stock, de recettes de cuisine, de facturation, ... Quelqu'un formé à Access peut faire en peu de temps, sans une ligne de code, avec des assistants Access pour générer des formulaires, des états, des requêtes, des menus, tout cela en quelques clics et quelques drag-and-drop, au travers d'un interface graphique époustouflant de possiblités.

si je réutilise très peu tables et formulaires d'une appli à l'autre, j'ai évidemment une bibliothèque de code dans laquelle je vais piocher procédures, fonctions, classes personnalisées en fonction de mes besoins.

On peut utiliser des outils de génération de code pour créer des classes perso rapidement sur base des tables "métier", de façon à créer l'ossature des propriétés et méthodes des objets personnalisés (non natif dans Acces, mais la page Outils renseigne des trucs sympas à utiliser).

En créant des impléments, on peut aussi imposer l'ossature des méthodes des formulaires, états et objets personnalisés, ce qui est déjà pas mal. A charge pour le développeur de créer son code à l'intérieur des blocs de procédure.

Tu parles de pouvoir (facilement?) transposer pour des applis Web ou autres. Mais une appli Web, notamment pour l'ergonomie, ne fonctionne pas du tout comme une appli Access. Il y a du langage serveur, des scripts clients, les contingences du HTML... Même si l'utilisation finale est plus ou moins la même dans ces deux systèmes, les mécanismes mis en place sont très différents, et ton générateur est très fortement, voire exclusivement, typé Access.

Alors, au delà de la prouesse technique que tu as réalisée et que je reconnais, je ne vois pas la finalité, l'enjeu.

Désolé de paraître si négatif, mais vraiment, je ne saisis pas l'importance de l'apport.

Quoi qu'il en soit, je suis content de savoir que cela te permet de créer tes applis de gestion facilement.

[Pierre Fauconnier]

[...]
Son but était de pouvoir permettre à des gens purement métier (pas des programmeurs donc) de pouvoir spécifier (avec une notation standard donné) le comportement de son application (processus, construction d'ihm avec un éditeur WISIWIG, base de donnée très simple à faire).[...]

J'ai déjà vu des équipes de développement qui utilisaient Access pour le prototypage d'outils de gestion, avant de passer sur du plus lourd pour la réalisation de l'outil final.

[mumen]

Désolé de paraître si négatif, mais vraiment, je ne saisis pas l'importance de l'apport.

Enfin une vraie critique ! Merci Pierre.

Je reviens sous peu.

[nnovic]

Quand tu dis cela, je me demande si tu réalises ce qu'un telle réflexion peut avoir de blessant pour quelqu'un qui prend tous les risques. Je me répète, mais il s'agit d'innovation et donc de choses encore jamais expliquées et plus encore, je suis la dernière personne à pouvoir survoler ce travail pour un fournir quelque chose de facile à comprendre. Oh je ne t'en veux pas , mais laisse moi ajouter ceci en guise de réponse du berger à la bergère : "it takes two to tango".

Au plaisir

Ma remarque n'avait pas pour but d'être blessante mais plutôt de souligner que fédérer du monde autour d'un projet ambitieux nécessite plusieurs ingrédients qui font défaut dans tes messages:
- l'objet du projet n'est pas clair. L'application existe déjà, donc pourquoi demander de l'aide à d'autre développeurs ?
- en quoi ta solution est meilleure que d'autres ? S'il te faut plus de dix phrases pour l'expliquer, personne ne t'écoutera.
- "croyez-moi" n'est pas un argument recevable.

[mumen]

Bonjour

J'ai lu, et relu toutes tes interventions (si si, je le jure). J'ai même téléchargé ton exemple de suivi de chantier sur une vm de test, histoire de ne pas mettre ma machine de prod en rade (on n'est jamais trop prudent). Au passage, je ne comprends pas pourquoi j'arrive sur le site d'Etienne Pailleret après le téléchargement (en plus sur un lien de téléchargement d'un pdf qui renvoie une jolie 404).

Merci pour ta patience et ton opiniâtreté. Concernant le comportement étrange de mes liens, je ne comprends pas, cela ne m'arrive pas.

Ok, il y a une application qui permet de gérer un chantier (enfin, je suppose, je n'ai pas testé). Mais je me demande pourquoi il faut du 2010 alors que l'interface ressemble à de l'Access 97, voire encore plus vieux et que l'appli gère des bases JET (mdb), qui ne permettent notamment pas les triggers.

Je développe encore sous Access 97 (à cause de l'impossibilité de mémoriser la bibliothèque depuis le projet). Pour l’exécution sur les postes (run-time), je génère une base de données au format quelconque. Pour ces démos, j'ai choisi le format compatible avec le plus grand nombre possible d'installations, soit de 2000 à 2010. La base dorsale elle, est restée compatible avec Jet 3.51.

N'ayant pas upgradé Access depuis Access 97, je n'ai pas été en mesure de développer les nouvelles fonctionnalités Access (Triggers, Format conditionnels, Ruban, etc.).

Si demain je décide de passer à Access 2010 en production, je fabriquerai les outils à la maison, et il me suffira de régénérer chaque application finale en clientèle pour que ces possibilités leur soient appliquées. Idem pour le look. Donc l'apparence et les fonctionnalités absentes de ces démos n'est pas un problème. Il faut voir ces démos, non comme la dernière application sexy à la mode, mais bien comme une preuve du concept.

Je suppose que cette application a été autogénérée. Donc ok, tu as créé une application qui crée des applications. C'est une prouesse technique que je peux reconnaitre, et je dis "chapeau", sincèrement.

Mais j'utilise depuis longtemps une application qui fait la même chose (en mieux, désolé, et sur base d'une "feuille d'analyse" bien plus ergonomique que ta feuille Excel - et je suis pourtant un fan d'Excel! - et qui m'offre beaucoup plus de possibilités). Cette appli de création d'appli s'appelle ACCESS.

Excel n'a rien à voir : la feuille d'analyse est d'un format à plat qui s'édite sous un logiciel généraliste, largement sous-employé pour l'occasion, qui s'appelle un tableur. La différence entre ce format à plat et l'application Access, c'est que ce format est synthétique, facile à apprendre et qu'il ne requiert pas de connaître les arcanes d'un outil de développement complexe, comme c'est le cas pour Access.

J'ai fait développer une application de suivi de SAV en temps réel pour des engins de chantier par une personne de 25 ans qui ignorait tout d'Access en particulier et du développement en général. Ce jeune homme était très motivé, il avait la "foi" pour l'analyse qu'il n'avait jamais apprise. Une histoire de famille. Je l'ai formé sur la feuille et l'analyste. Je l'ai laissé dessiner entièrement seul cette application d'une bonne trentaine de tables. Il est allé en interview, il a développé la feuille, il a installé l'application, formé la responsable, ceci sur trois cycles. Tout cela à pris deux mois. Je suis intervenu une journée à la fin, pour créer un état complexe et d'autres choses de pure programmation. Je suis quand même intervenu derrière lui sur l'analyse, pour enlever des choses que la cliente avait demandé, mais qui n'étaient pas réalistes, ce qu'un vrai pro de l'analyse aurait certainement décelé.

Pierre, dis-moi si la foule de débutants que l'on guide sur les forums Access ont cette puissance de développement. Dis-moi, si avec Access (ou n'importe quel autre environnement de développement) on peut dire qu'une analyse est égale à une application fonctionnelle comme le sont vraiment (si, si) mes deux démos. Non, évidemment. Un analyste a toujours besoin d'un programmeur pour voir son étude fonctionner. Il n'y a pas d'exception, aujourd'hui c'est la norme. Et cette norme rend d'une rigidité implacable le développement d'applications de gestion en totale contradiction avec la réalité. Je suis bien obligé de citer en rappel la signature d'un digne contributeur de Développez, el_slapper :

Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

La réalité du développement, c'est que ça bouge tout le temps. Nous savons très bien toi et moi que les assistants sont inadaptés à cette réalité. Ils sont incroyablement puissants et magnifiques dans les cinq premières minutes et tout d'un coup ils deviennent une horreur sans nom. Ce "tout d'un coup", arrive vite quand on travaille pour un client. Les assistants sont des jouets destinés à repousser la limite du vrai développement, là où il faudra de toute façon mettre les mains dans le cambouis d'Access.

Avec la notion de définition à plat de l'application, un changement de structure se résume en développement à une question : recalculer l'IHM maintenant ou plus tard. J'exagère un peu, le surtypage impliquant parfois de revoir à la main les définitions tardives. Mais dans ce cas, il s'agit de revoir des définitions, pas des objets bourrés de code, de références, de propriétés et d'événements fignolés à la main et à modifier, à refabriquer, à déboguer à nouveau à chaque fois. Le code spécifique, véritablement métier doit aussi être impacté, bien sur, je ne prétends pas à la magie, mais il est le seul.

Quand mon client me demande un champ nouveau, une structure en plus, un changement de relation, je l'applique dans la feuille et c'est tout. Non seulement, la feuille me permet de définir la vision de toutes les entités par l'utilisateur final (ce que ne font pas les développeurs classiques, concentrés sur les formulaires clefs), non seulement je n'ai pas une ligne de code, une propriété à définir, un événement à programmer, mais je n'ai pas de débogage à faire !

Même toi, Pierre, professionnel du développement tu en rêves !

Avec une telle conception, construire de l'IHM pour le site, table par table, est révolu. Cette construction est un travail de type méta, et donc le développeur de l'application finale peut choisir l'interface qui lui convient, parmi celles développées par des tiers. Ma preuve du concept n'en expose qu'une seule, mais rien ne m'empêcherait d'en développer d'autres, par exemple sous Access, et compatibles avec l'état d'esprit d'un site exposant des ressources qui ne devraient pas faire appel à une bibliothèque, ou encore ressemblant trait pour trait aux assistants proposés par chaque version nouvelle d'Access, mais leur ajoutant le système de définition les rendant recalculables.

Parce que créer une petite application de suivi de chantier, de stock, de recettes de cuisine, de facturation, ... Quelqu'un formé à Access peut faire en peu de temps, sans une ligne de code, avec des assistants Access pour générer des formulaires, des états, des requêtes, des menus, tout cela en quelques clics et quelques drag-and-drop, au travers d'un interface graphique époustouflant de possiblités.

si je réutilise très peu tables et formulaires d'une appli à l'autre, j'ai évidemment une bibliothèque de code dans laquelle je vais piocher procédures, fonctions, classes personnalisées en fonction de mes besoins.

On peut utiliser des outils de génération de code pour créer des classes perso rapidement sur base des tables "métier", de façon à créer l'ossature des propriétés et méthodes des objets personnalisés (non natif dans Acces, mais la page Outils renseigne des trucs sympas à utiliser).

Pierre, toutes les possibilités d'Access que tu décris sont bonnes dans un cadre de développement rigoureux, celui où l'analyse est finalisée et figée avant le développement. Dans ce cas Access est crédible pour un développement de projet par un programmeur débutant. Mais nous savons très bien que cette cible est loin d'être la norme des développeurs sous Access. Et nous ne pouvons pas non plus nous voiler la face devant le fait que le développement d'applications de gestion est loin d'avoir rencontré le succès populaire du traitement de texte et du tableur, que des tas d'entreprises de petite taille en sont encore à l'age du papier pour leur gestion, que l'outil le plus utilisé pour faire de la gestion aujourd'hui est le tableur. Il y a indubitablement un chaînon manquant qu'Access, le logiciel le plus évolué dans ce domaine est loin, très loin de combler. Ma mère n'est pas prête à faire du relationnel, nous le savons tous pertinemment. Nos bureaux informatiques et tous nos arcanes de rangement sous système d'exploitation ne connaissent qu'un niveau, l'arborescent. L'absence de rangement est tellement une évidence qu'on est incapable de penser autre chose. Imagine ton bureau avec directement la possibilité que confère la base de données, imagine la possibilité native de créer sa propre architecture, sa propre structure...

Tu parles de pouvoir (facilement?) transposer pour des applis Web ou autres. Mais une appli Web, notamment pour l'ergonomie, ne fonctionne pas du tout comme une appli Access. Il y a du langage serveur, des scripts clients, les contingences du HTML... Même si l'utilisation finale est plus ou moins la même dans ces deux systèmes, les mécanismes mis en place sont très différents, et ton générateur est très fortement, voire exclusivement, typé Access.

Une IHM est une interface entre la base de données et l'utilisateur. Quand j'expose ceci Mondial sur Internet, je montre bien une interface HTML sur une base de données. Ce n'est pas parce que celle-ci est absolument primaire qu'elle n'en est pas une. Il s'agit de fabriquer un site comportant des formulaires en HTML/CSS avec du PHP et du Java s'il le faut. La facilité de réaliser ceci est à prendre à deux niveaux. Au niveau méta, c’est très difficile, comme tout développement méta et il faut beaucoup de connaissances et de temps. Mais au niveau final, pour toute feuille d'analyse donnée, ce sera fait en un clic de souris. Pense-y vraiment, en un seul clic de souris, tu décides de fournir une interface internet pour ton application Access développée pour le moteur MySQL ou autre.



Je ne tente pas de réécrire Access, je m'en sers. C’est un outil exceptionnel pour faire ce que j’ai fait. C’est une recherche que j’ai commencée sous Basic 86 compilé et qui a évolué avec les différentes versions de QuickBasic. J’ai dû développer moi-même le séquentiel indexé, la gestion d’écran en assembleur, les tris en assembleur, l’évaluateur d’expressions, etc. Je sais ce qu’Access m’apporte, et j’ai mis longtemps à savoir qu’il devait être dépassé pour continuer d’avancer. Si Access adoptait une généralisation dans l’esprit de ce que je propose, il sortirait de l’éternelle impasse des assistants. D’ailleurs on voit bien que certaines évolutions d’Access me donnent raison quand elles utilisent l’information contenue dans les définitions pour améliorer avec aisance l’expérience utilisateur, en particulier dans l’utilisation des relations et des champs calculés. Mais pour Access, la définition de structure est relativement stoppée : on ajoute des propriétés géniales, il faut le dire, mais pas d’entités ; et surtout, on a un éditeur spécifique par entité et pas de structure définitionnelle commune. Les sources des objets d’IHM sont inexploitables en tant que telles, comme l'est le XML. On ne peut finalement que faire du développement pointilliste, pas "à la grosse" comme avec ma feuille. Quand une application doit comporter des centaines de formulaires, on doit les créer un par un en les figeant.

La stratégie d'Access, c’est une stratégie de continuité, c’est une stratégie protectionniste, ce n’est pas une stratégie d’innovation.

Dans les faits, je n’édite aujourd’hui quasiment plus jamais de table ou de formulaire à travers l’interface Access. Pour développer ce qui reste à développer quand on n’a pas à se soucier de développer l’IHM (et d'administration), j’ai un IDE VBA extraordinaire même s’il n’a quasiment pas évolué en quinze ans, j’ai un formidable éditeur d’états et j’ai un éditeur de SQL dont je ne saurais me passer. Je suis développeur Access, je reste Développeur Access. Ce que j’ai fait pour mon usage personnel est comme tu le dis une sorte de complément d’Access. Mais j’ai toujours pensé « indépendant », je ne suis marié à Access que par la force des choses, pas par l’irrationnelle sensation d’être le meilleur développeur sur le meilleur produit. La conception que je propose avec Nakedata peut continuer d'être développée sous Access. C’est ce que j’aimerais vraiment, mais qui est impossible à cause de ma volonté de rendre ce développement libre.

[mumen]

Ma remarque n'avait pas pour but d'être blessante mais plutôt de souligner que fédérer du monde autour d'un projet ambitieux nécessite plusieurs ingrédients qui font défaut dans tes messages:
- l'objet du projet n'est pas clair. L'application existe déjà, donc pourquoi demander de l'aide à d'autre développeurs ?
- en quoi ta solution est meilleure que d'autres ? S'il te faut plus de dix phrases pour l'expliquer, personne ne t'écoutera.
- "croyez-moi" n'est pas un argument recevable.

Je sais ce que tu dis, je rame seul depuis assez longtemps et les yakafautque, j'en ai soupé. Tu ne veux pas blesser, mais tu y parviens.

Tu crois que c'est simple ? Pourquoi je te dis qu'il faut être deux pour danser le tango ? Pourquoi ?

Si les ingrédients manquent dans mes messages, ils ne manquent pas dans mes réalisations. Ne restes pas alangui au bord de l'eau à juger celui qui agit et se démène. Viens mettre au profit d'un vrai projet tes qualités en essayant de comprendre ce qui est difficile.