Documentation Générale
Ceci est une présentation des concepts généraux du framework
La documentation du framework présente systématiquement deux sections :
1) Concept : c'est le cadre et les idées générales qui sous-tendes les thèmes
2) Dev : indique les points d'entrées et méthodologies à respecter
wtools est découpé en six thèmes
L'entité principale Fichier/Métier : Fichier
Un schéma organisationnel
_________________________________________________________________________________
Concept
Le projet wtools est un framework de production de logiciel de gestion
de type desktop utilisant une base de donnée
Le constat :
1) les composants java sont primaires
2) les interfaces graphiques sont complexes (Multi entrée et Nombreux comportements à gérer)
3) les logiciels de gestion sont simples et répétitifs basés sur le template CRUD
Les objectifs de wtools sont :
1) de faire gagner du temps lors du développement
2) d'offrir un cadre de développement simplifié et robuste
3) de limiter l'intervention du développeur aux problématiques métier
wtools fourni une architecture standard compléte, à charge pour le Dev de réaliser la partie métier
wtools défini des entités fonctionnelles nommées Fichier c'est la base de développement des objects métiers
wtools fourni des composants graphique unaire, des templates applicatif, des conteneurs pour construire des UI métier
wtools fourni un interpréteur SQL pour la persistance des données métier
Le Dev se concentre sur trois aspect fondamentaux du développement qui sont :
1) le Modele Conceptuel de Données métier
définir les tables, les relations et les identifiants
2) le Modele Conceptuel de Traitement métier
définir les transitions et les traitements de données
3) les Interfaces Utilisateur
définir l'arborescence des menus et concevoir les écrans
__________________________________________________________________________________
Dev
Pour démarrer le codage, la procédure générale à suivre est toujours la même :
Elle se résume en l'ajout d'une entité fonctionnelle Fichier à l'application
1) le DEV créé un package avec la class principale xxxFICHIER et ses trois class secondaire : xxxSAISIE, xxxLISTE, xxxSTRUCT
Par dérivation des fabriques Template Application
2) il ajoute une entrée dans l'Appliparam en couplant xxxFICHIER et une "Key" unique
3) pour finir, il ajoute une option de menu dans la table s_menus avec cette "Key" unique
4) La compilation et la première exécution terminent le processus
A noter
Suite à la création d'un package Fichier, lors de la première exécution wtools check et compléte automatiquement les tables de l'appli,
wtools est auto-update pour la création des table et l'ajout des champs de ses tables
Les cas de base :
S_THEMES est la table la plus simple
S_FIELD présente une table jointée avec d'autres tables
S_INTERO présente une table groupée sur elle-même
S_MENUS présente une table groupée et filtrée sur elle-même
S_PREFS présente une table composée de nombreux conposants de saisie
S_FILES présente une table qui dispose d'un bouton d'action supplémentaire au CRUD Standard
Les cas complexes :
S_SLCOL présente l'entete d'une saisie en ligne
S_SLCOLDETAIL présente le détail d'une saisie en ligne
Les cas spécifiques :
wConnectPreference utiliser une table de saisie sans CRUD
wDebug boite de dialogue indépendante
wsParamMenus présente une table qui dérive d'une table
__________________________________________________________________________________
Fichier
"Fichier" est l'entité fonctionnelle centrale qui est couplé au menu de l'application par une "Key"
La mise en place d'un "Fichier" passe par Quatre classes issues des templates applicatif
La premiere étape consiste à réaliser deux class de mappage qui assurent la relation entre
données physiques de la base et données logiques de l'appli
A noter que le mappage est nécessaire pour "Sql" et qu'ils sont issus de "AbstractFieldsDef",
les mappages simplifiés ou complets sont dérivés de "AbstractFieldsDef"
"tableLISTE" est la class de mappage d'une table Liste(c'est la plus simple)
Le DEV y défini le nom de la table physique, sa clé d'index soit l'ordre d'affichage puis
le mappage champs par champs
C'est un mappage simplifié à :
le nom du champs
la longueur à affiché
le format d'affichage
le titre de la colonne
Elle est utilisée pour produire les listes écran et imprimantes
"tableSTRUCT" est la class de mappage d'une table Saisie (c'est la principale)
Le DEV y défini le nom de la table physique, sa clé d'index soit l'unicité de sa clé primaire puis
le mappage champs par champs.
C'est un mappage complet :
le nom du champs
la longueur à afficher
le format d'affichage
le titre de la zonne de saisie
l'aide à la saisie
le type de composant de saisie
le format de la saisie
Elle est utilisée pour produire les fiches à saisir et la connexion physique avec sa table
"tableSAISIE" est la classe principale de saisie d'une table
Le DEV y :
Crée les composants de saisie en les liant à "tableSTRUCT"
Compose la fiche de saisie
Organise les controles de saisie
Développe les traitements de données
Gére l'intégrité référentielle des tables
Elle est le composant de saisie de l'interface utilisateur
"tableFICHIER" est la classe de fabrique d'UI
Le DEV y raccroche le :
mappage STRUCT
mappage LIST
UI de SAISIE
mappage PRINT d'impression
mappage RUPTURE d'impression de totaux
Défini les jointures de tables
Une fois, ces quatre classes réalisés, le Module doit-être connectés à l'"Appliparam" par une "Key" unique avec le menu
__________________________________________________________________________________
Un schéma organisationnel