|
|
|
|
|
|
|
|
|
|
- Présentation
- Comment le faire ?
- Les étapes de la génération de la fenêtre
- Les éléments générés par le RAD
- Gestion des erreurs dans les classes générées par le RAD MVP
- WLangage : Spécificités permettant de simplifier l'architecture MVP
- Présentation
- Attribut "mapping"
- Mots-clés MonFichierMappé et MaCléUniqueMappée
- Attribut "associé"
- Attribut "présentation" : gestion de l'actualisation des vues
WINDEV propose un RAD MVP qui génère les fenêtres "table" et "fiche" et les classes Présentation et Modèle nécessaires. Les fenêtres correspondent aux Vues du MVP. Le code généré est librement et entièrement adaptable en fonction des besoins : il s'agit de la génération d'un squelette de base de l'application. Attention : Ce mode de développement utilise la POO : il est obligatoire d'en maîtriser les concepts. Ce mode de développement est un mode de développement avancé. WLangage : Spécificités permettant de simplifier l'architecture MVP Présentation Afin de simplifier la mise en oeuvre d'une architecture MVP, il est important de connaître et de comprendre les éléments spécifiques du WLangage : - l'attribut mapping (ainsi que les mots-clés MonFichierMappé et MaCléUniqueMappée),
- l'attribut associé,
- l'attribut présentation,
- les fonctions DemandeMiseAJourUI et DemandeMiseAJourUIParent et l'événement "Mise à jour" de la fenêtre (ou de l'état).
Le RAD MVP utilise ces fonctionnalités, mais elles sont utilisables librement dans tout type d'architecture.
Attribut "mapping" L'attribut mapping permet de réaliser une "liaison directe" entre la classe et le fichier de données. Exemple :
MMonFichierExemple est une Classe,mapping = MonFichierExemple
Grâce à cet attribut : - la fonction MémoireVersFichier va automatiquement recopier la valeur des membres de la classe dans les rubriques de l'enregistrement en cours du fichier de données.
- la fonction FichierVersMémoire va automatiquement recopier les rubriques de l'enregistrement en cours du fichier de données dans les membres de la classe.
Important : - Par défaut, pour que ce mécanisme fonctionne, les noms des membres de la classe doivent être identiques aux noms des rubriques dans le fichier de données.
- En cas de besoin : l'attribut mapping permet d'utiliser des préfixes ou des noms différents de ceux de l'analyse. Il suffit de réutiliser le mot-clé mapping sur les membres de la classe pour recréer la liaison entre le membre et sa rubrique de l'analyse.
Exemple :
m_sTitreBien est une chaîne ANSI <MAPPING=TitreBien>
Mots-clés MonFichierMappé et MaCléUniqueMappée Dans la classe MBase générée par le RAD MVP, deux mots-clés sont utilisés pour simplifier la gestion du mapping : MonFichierMappé et MaCléUniqueMappée. Ces mots-clés servent à connaître, au niveau de la classe de base MBase, le fichier et la clé unique du modèle : - MonFichierMappé référence le fichier de données défini avec le mot-clé mapping dans la classe "Modèle".
Par exemple, le code suivant est utilisé dans la méthode bEnregistrer de la classe MBase :
Ce code va effectuer un appel à la fonction HRAZ sur le fichier de données pour lequel le RAD a été généré. - MaCléUniqueMappée référence la rubrique définie par le mapping "clé unique" dans la classe "Modèle".
Par exemple, dans la classe MMonFichierExemple, MaCléUniqueMappée est équivalent à la rubrique IDMonFichierExemple :
m_nIDMonFichierExemple est un entier<MAPPING=IDMonFichierExemple, clé unique>
Ces mots-clés permettent de faire du code générique dans cette classe de base.
Attribut "associé" L'attribut associé permet d'accéder aux membres, aux méthodes et aux propriétés d'une classe Modèle depuis sa classe Présentation, sans avoir à effectuer de "rebonds". Exemple : PFicheMonFichierExemple est une Classe
PROTÉGÉ
m_clModeleCourant est un MMonFichierExemple <associé>
Dans l'exemple ci-dessus, les objets PFicheMonFichierExemple ont un membre "associé" de type MMonFichierExemple. Les objets PFicheMonFichierExemple exposent alors directement les méthodes, propriétés et membres de la classe associée, sans avoir besoin de les redéfinir. Grâce à l'attribut associé, il n'est plus nécessaire de recréer systématiquement toutes les propriétés dans la classe présentation pour exposer les membres du modèle. L'architecture MVP générée par le RAD contient des classes génériques et des classes spécifiques au projet. Elle est entièrement personnalisable ! Il suffira de créer les méthodes et les propriétés souhaitées dans la classe "Présentation" pour surcharger les comportements du modèle. Il est possible de lier un champ à un membre ou à une propriété de classe "Présentation". Il est donc possible d'effectuer cette liaison sur tous les membres ou propriétés du "Modèle", exposés par la classe "Présentation" grâce à ce mécanisme de "façade". Attribut "présentation" : gestion de l'actualisation des vues L'attribut présentation est utilisé lors de la déclaration globale des fenêtres générées. Il permet d'associer une classe de la couche présentation à une vue (fenêtre ou état). Par exemple :
PROCÉDURE FEN_Table_MonFichierExemple(...
gclPresentation est un PTableMonFichierExemple dynamique<présentation>=Null)
Grâce à cet attribut, l'appel de l'événement de mise à jour de l'affichage de la fenêtre sera déclenché par : Par exemple, lors de la suppression d'un élément dans une fenêtre Table générée par le RAD MVP, une demande de mise à jour de l'UI est effectuée par l'appel à la fonction DemandeMiseAJourUI : - MTableauMonFichierExemple est un membre associé de PTableMonFichierExemple,
- PTableMonFichierExemple est défini comme "présentation" de la fenêtre "FEN_Table_MonFichierExemple".
L'événement de mise à jour de la fenêtre table "FEN_Table_MonFichierExemple" sera alors automatiquement appelé lors d'une suppression d'un élément. L'événement de mise à jour de l'UI permet de regrouper tous les traitements de mises à jour de l'affichage de la fenêtre plutôt que de les répartir dans plusieurs événements (clic, etc.). Ce mécanisme se retrouve également dans la fenêtre fiche. La fenêtre fiche est liée à la classe présentation PFicheMonFichierExemple contenant un membre associé MMonFichierExemple. Les demandes de mise à jour effectuées dans MMonFichierExemple "impactent" donc bien la fenêtre fiche. Attention : L'événement de mise à jour de l'UI ne doit pas être exécuté "n'importe où". Important : les fonctions DemandeMiseAJourUI et DemandeMiseAJourUIParent sont asynchrones : l'événement de mise à jour de l'UI est exécuté à la fin du traitement en cours et les appels à la fonction DemandeMiseAJourUI ou DemandeMiseAJourUIParent ne sont pas empilés. Ces fonctions et ce mécanisme très pratique sont utilisables même en dehors d'une architecture MVP. Ce fonctionnement offre un gros avantage : si une boucle de traitement dans le modèle fait 50 appels à la fonction DemandeMiseAJourUI, le WLangage ne réalisera qu'un seul et unique appel en sortie du traitement (évite de voir l'UI "clignoter"). Note : pour effectuer une demande de mise à jour de l'UI de manière synchrone, il suffit d'utiliser la fonction WLangage ExécuteMiseAJourUI (ou ExécuteMiseAJourUIParent).
Documentation également disponible pour…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|