domogest

Shell
Règles de développement

Version 1 du 27/10/2021

​

Ergonomie de l'application

La première version de Domogest était basée sur le mode Utilisation directe qui a très vite montré ses limites, car incompatible avec le concept de menus.

La deuxième version a introduit un fonctionnement mimant le mode utilisation directe mais fonctionnait en mode Menus créés. La mise au point fut un peu laborieuse et complexe mais fonctionnait parfaitement.

Sur le plan ergonomique, ce n'était pas terrible ; exemple si on créait une enregistrement dans une table N et qu'il manquait un enregistrement dans la table 1, il fallait soit abandonner, créer l'enregistrement T1 puis celui TN ou créer l'enregistrement T1 dan sun process parallèle.

Un autre limitation venait de la création de plusieurs process par utilisateurs avec des milliers de variables globales qui auraient rendu pratiquement impossible le fonctionnement en multi-utilisateurs.

Une amélioration importante de l'ergonomie a été apportée par les fonctions métier regroupées dans un seul formulaire et pouvant appeler des fonctions de plusieurs modules.

L'introduction des objets, d'ORDA et des classe a permis de mettre au point des techniques visant à changer complètement les méthodes de développement et l'ergonomie, ce qui fait l'objet d'une troisième grande version.

Ergonomie

Fonctions métiers

Cette version sera entièrement basée à terme sur des fonctions métiers.

Exemple de fonction métiers : la gestion des locations.

Elle comporte :

- module ADR ; gestion des entités (personnes et sociétés)

- module VEN ; gestion des contrats, facturation, relance,...

- module ACC ; comptabilisation des factures, gestion du compte client

- module OFF ; édition de documents, factures, lettres de relance, situation de comptes

- module TRE ; indices d'actualisation.

Mise à jour automatique

Les deux premières versions étaient basées sur une validation systématique des données, nécessitant un passage en modification, la modification des données et l'enregistrement avec le mode pessimiste de 4D.

La troisième est basée sur le fait que les modifications sont volontaires et qu'on n'a pas envie de perdre du temps à valider toutes les modifications.

Développement

Modules

L'application est organisée en modules fonctionnels et techniques.

La communication entre modules fonctionnels est basée sur des points d'entrée et des messages standardisés.

Classes

Des classes sont créées pour regroupe de manière simple les fonctions précédemment dispersés ; le This permet de mémoriser des valeurs dans l'instance.

Héritage

Lorsqu'on a des classes avec héritage, prenons l'exemple des formes géométriques : la classe polygone est la plus générique, puis la classe qudrilatère, la classe rectangle et la classe carré.

La méthode "officielle" consiste à créer l'objet au niveau le plus bas ; si on veut représenter un carré, il faut créer une instance "Carré" qui hérite des propriétés du rectangle, du quadrilatère et du polygone.

S'il est impossible de créer un objet directement au plus bas niveau, parce qu'on n'a que les coordonnées des sommets, la méthode que j'adopte consiste à le créer au niveau supérieur, à tester son appartenance au niveau immédiatement en dessous et, s'il satisfait aux critères, à le recréer au niveau inféreur.

Exemple de la gestion de fichiers ; la classe standard File() ne convient pas à tous les usages, notamment parce que l'objet n'est pas modifiable ; j'ai donc recréé une classe fileMananger mais les fichiers peuvent avoir des particularités, par exemple être une image ; lorsqu'on crée l'instance fimeManager, on sait pas si c'est une image ; il faut donc la tester ; si c'est une image, on la recrée dans la classe pictureManager avec le même nom d'objet ce qui permet de lui ajouter les propriétés spécificiques des images..

Gestion des formulaires

L'utilisation des sous-formulaires rationalise la construction.

Principe de communication entre les niveaux de formulaires

Il est basé sur une idée de JPR.

Chaque formulaire est associé à une variable objet Form ; les objets étant manipulés par des références, rien n'empêche de recopier un form dans un autre.

Si on a l'organisation :

Formulaire

Sous-formulaire​

Sous-sous-formulaire

La variable Form est commune à tous les niveaux, ce qui facilite la communication.

Si on veut ajouter des propriétés particulières à un sous-formulaire, il ne faut pas les ajouter dans la proriété subform mais dans Form ; ici aussi le choix des libellés est important pour s'y retrouver !

Notation des objets

Nomenclature

Le système précédent de nomenclature très détaillé est abandonné ; les nouvelles règles sont :

- tables : nom en majuscules avec un préfixe de module en 3 lettres suivi d'un '_' puis des mots en majuscules avec un minimum d'abréviations et séparés par des '_' ;en pratique, règles inchangées à part l'usage de l'anglais

- champs, variables et propriétés : adoption du cameCase, mots en anglais dans l'ordre du langage courant, donc pas d'accentuation, pas de '_', ; l'abandon du typage visuel impose une clarté du libellé pour comprendre le type d'un coup d'oeil

'dateOperation' doit être une date ; si c'est une date sous la forme d'un texte, il vaut mieux mettre 'dateOperationText'.

Nom des objets

L'utlisation des objets fait que la structure d'un objet à un endroit de la base se retrouve à plein d'autres endroits, contrairement aux variables locales qu'on pouvait renommer aisément.

Il faut donc bien réfléchir aux noms pour les utiliser avec une bonne efficacité.

La programmation générique demande que les mêmes types d'objets aient les mêmes strutures. Exemple des listboxes :

- les listboxes ont un certain nombre de propriétés qui doivent être toujours les mêmes pour être facilement gérés par une classe :

. nom ; il désigne l'objet qui reçoit une collection ou une entitySelection, donc le contenu ; le nom sera 'maListbox.content'

. variable ; toujours 'Form.' suivi du nom, donc 'Form.maListbox.content'

- source de données ; les 3 objets sont nommés

. 'Form.maListbox.currentItem',

. 'Form.maListbox.currentItemPosition'

. 'Form.maListbox.selectedItems'

=> ce vocabulaire reprend celui de la documentation et il est plus simple que de le personnaliser à chaque création de lisbox.

​

Historique du document

V1 : création du document ; remise à zéro de la rédaction de la documentation en raison du passage aux objets et à ORDA.