Discussion :

[R&B]

Bonjour
Au sujet de l'utilisation des composants internes pour structurer un projet, je me confronte à la découpe du modèle de données.
En effet, si l'on suit les possibilités des composants, la découpe fonctionnelle en projets séparés permet de réaliser des composants que le GDS permet de partager avec les projets utilisateurs.
Ce découpage est utile pour faciliter la maintenance des sources : les projets "souces" n'embarquent pas tout le projet et sont donc plus simple à travailler. Les modifications sont alors véhiculées dans les projets utilisateurs via les partages GDS. Il "suffit" de modifier au bon endroit et surtout ne pas se tromper.

Cela se complique (à mes yeux du moins) pour les données. En effet, si les éléments d'IHM et de contrôle que l'on développe au sein des fenêtres, états et classes pour une entité du MCD sont faciles à gérer dans un composant interne, la séparation coté MCD pose un problème pour les relations.
Par exemple on serait tenté de gérer les clients les articles et les documents d'une gestion commerciale dans des composants séparés. Mais coté MCD, je vois mal un système avec une analyse pour les clients, une autre pour les article et enfin une pour les documents.
En effet, la gestion des documents met en oeuvre des relations avec les données des deux autres composants...
La question est simple : une seul analyse ou trois ? et si trois, comment on gère ces relations avec des données externes ?

[frenchsting]

Très bonne question Romu, mais dans je vois également mal comment avoir 3 analyses différentes. Je n'imagine pas devoir changer de connexion en permanence pour passer d'une base à une autre.

Mon avis est une seule analyse... et "promener" nos 3 composants ensemble. Quitte à en avoir un qui ne sert pas...

[R&B]

Je commence ainsi en effet. On m'a par ailleurs soumis l'idée de "programmer" les relations quand cela pouvait être possible avec une interface.
Admettons lors un ensemble de fichier avec une seule relation vers l'extérieur, il est possible de grouper leur gestion et programmer la relation.
Reste que les exemples sont maigres sur une telle problématique qui survient rapidement si on utilise les composants.

En utilisant un nommage adéquat on devrait cependant être en mesure de ne créer que les fichiers nécessaire à mesure de l'activation des composants.

Merci en tout cas.

[michel.souris]

Pourquoi ne pas partager l'analyse entre les 3 projets ?

Il y a aussi la solution de ne pas utiliser d'analyse.

[R&B]

Héhé Michel ;D
En effet le partage entre les 3 projets est la solution sous jascente.
Pas d'analyse ? comment ça ? on passe tout en déclaration externe et se programme la totalité des contrôles (intégrité, doublons etc Oo)

Suite aux problème soulevé en direct avec PCSoft, j'ai pu me rappeler que la LST 97 documentait cela dans les exemples WDPLusieursAnalyses et le composant CI_GestionProduit (échange de données via une passerelle utilisant soit une structure soit des variables de type enregistrement + déclaration externe)

Le plusieurs analyse est une solution qu'on m'avait soumise par ailleurs : le composant délivre des fonctions passerelles pour délivrer les enregistrements des fichiers dont il a la description.
Ce peut être fait au moyen de variable de type enregistrement ou structurée :

Code :

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

VarEnregistement =  CI_Produit.ChargeProduit(Référence)

Si la technique permet de cloisonner l'analyse en sous partie cela ne me résoud pas la question des relations.
Ce peut toutefois être utilisé aisément sur des données qui n'évolue pas ou peu et dont on peut aisément programmer le respect des relations.

[michel.souris]

Pas d'analyse... tout en SQL !

[frenchsting]

Je cherche toujours à faire au plus simple quitte à ce que ce ne soit pas "sexy" (comme me disait mon formateur sur java).

Je n'ai pas regardé l'exemple multi-analyses de la LST. Si ça fonctionne et que ce n'est pas une usine à gaz, alors pourquoi pas...

[R&B]

Précision : l'exemple de la LST ne comporte qu'un unique fichier... plusieurs analyses d'un fichier unique sans relations, faut pas trop aller loin hein ?

@Michel : tout en SQL ok mais tu as bien un descriptif de ton MCD qui traite quelque part (une autre forme d'analyse en somme)... lequel se charge la TOTALITE des descriptions des tables. Imaginons alors travailler avec plusieurs bases et maintenir des relation sur des tables de ces différentes bases.

Bref : si je veux structurer le projet en le découpant un peu, la gestion des frontières des composants se fera sur des parties du MCD qu'on peut facilement isoler (avec peu de relation qui seront alors à programmer et sur des données stables dans le temps).

Merci encore

[michel.souris]

Pas forcément tu maintiens un MCD sur DBDesigner ou ce que tu veux et ton IDE ignore la structure de ta base (pas de requête paramétrée, pas d'autocomplétion...)

[frenchsting]

Pas mal le coup du DbDesigner. +1

Par contre l'autocomplétion, c'est quand même cool. Quand, comme moi, on est obligé de se replonger dans Windev 5.5, on met 3 plombes à rechercher les billes pour les noms des champs...

[Ry_Yo]

Bonjour,

Par rapport à cette remarque :

...

En utilisant un nommage adéquat on devrait cependant être en mesure de ne créer que les fichiers nécessaire à mesure de l'activation des composants.

Merci en tout cas.

Au niveau du MCD, si vous déplacer les descriptions de tables d'un module dans un dossier portant le nom du module, un Hcreation("MonModule") génèrera que les tables HF contenu de ce dossier uniquement... biensûr restera à traiter les exceptions qui ne seraient pas dans le dossier...

[R&B]

@Ry_Yo C'est noté ! merci de la précision.

@Michel : WinDev + DBDesigner et quelle base ?
et pas de EcranVersFichier, de colonnes associées etc alors ?

[michel.souris]

Ben n'importe quoi sauf HF < 18 (de mémoire... avant qu'on ai des instructions de générations de table genre CREATE et ALTER)

Après tout se passe ici : http://doc.pcsoft.fr/?2034001

Bien sûr on oublie pas mal de comportement natif de Windev du style EcranVersFichier, RAD et autres tables sur fichiers.... ce n'est pas forcément le plus PCSoft friendly comme philosophie....