Discussion :

[Djsven]

Bonjour,

J'aimerais savoir qu'elle serait la meilleure méthode à utiliser afin de stocker les paramètres généraux d'une application C/S.

J'ai pensé à créer une table Parametre. Cependant, je ne sais pas qu'elle est la meilleure solution entre :

Solution 1 :
- Créer une table Parametre avec une colonne "Code paramètre unique", une colonne "Nom paramètre" et une colonne Valeur (La valeur du paramètre).
- Importer les lignes de paramètres prédéfinies.
- A l'ouverture de l'application par un utilisateur, charger tout les paramètres dans un tableau mémoire et utiliser dans mon application le "Code paramètre" pour faire le lien.

Le problème ici c'est qu'il faut obligatoirement que les lignes de paramètres aient été importées au préalable, sinon l'application ne fera pas le lien avec le code paramètre souhaité.
Un autre problème, c'est que vu que je chargerais tout les paramètres dans un tableau mémoire à l'ouverture de l'application afin d'éviter les retours serveur, si un autre utilisateur modifie un paramètre entre temps, le paramètre de mon côté ne sera pas à jour tant que je n'aurais pas relancer l'application...
De plus, si lors d'une mise à jour j'ajoute de nouveaux paramètres, comment faire pour mettre à jour le contenu de la table Parametre des clients lorsqu'ils vont faire la mise à jour de leur coté ?


Solution 2 :
- Créer une table Parametre avec une colonne par paramètre, avec une seule ligne dans cette table. L'application vérifie que cette ligne existe au démarrage de l'application.

Dans ce cas, les problèmes de la solution 1 ne se posent plus, un hmodifiestructure suffira pour ajouter les nouveaux paramètres lors d'une mise à jour, mais le soucis c'est que si j'ai 200 paramètres, j'aurais également 200 colonnes dans cette table pour une seule et unique ligne, pas top ?


Qu'en pensez-vous ? Comment faites-vous pour gérer le stockage des paramètres généraux d'une application C/S ?

Merci


Cordialement

[frenchsting]

Bonjour,

Dans notre appli principale, il y a 1300 paramètres (et ça augmente régulièrement). On utilise la version 1 de ton idée.

La question que tu dois te poser, c'est est-ce que le paramètre est "sensible", du genre modifié plusieurs fois par jour.
Pour bous, les paramètres sont des paramètres qui changent peu (1 fois par jour grand max).
Si c'est un paramètre sensible (par exemple, un n° de facture), on les stocke dans une table lue et mise à jour à chaque besoin.

[djejackk]

Bonjour,

Selon le nombre, l'importance, le contenu, ... et comme le dit "frenchsting", la sensibilité / fréquence de mise à jour, il est aussi possible de stocker les paramètres au niveau de la base directement, sans table spécifique.

Voir la fonction HSauveParametre (et HChargeParamètre)

[philouZ]

Pour nous c'est stocké dans une table parametre dans la base avec une clé, une valeur, une colonne json pour les paramètres multiples.

Ensuite on charge ça dans des classes et le tour est joué.

[Djsven]

@Frenchsting
Du coup pour récupérer la valeur d’un paramètre, vous chargez tout dans un tableau mémoire au lancement de l’appli et vous attaquez ce tableau mémoire ? Ou bien vous envoyez directement une requête sur la base à chaque fois que vous avez besoin de la valeur d’un paramètre souhaité ?
Pour moi, les paramètres seront modifiés que très rarement, les paramètres de type compteur (n° client etc.) sont stockés dans une table Compteur. Cependant, bien qu’ils soient modifiés que très rarement, si je stock tout mes paramètres dans une table mémoire au lancement (toujours dans le but d’éviter les retours serveur répétitifs), il suffit qu’un autre utilisateur modifie un paramètre pour que mon tableau ne soit plus à jour (tant que je ne me reconnecte pas), et dans ce cas, si j’ai besoin d’utiliser ce paramètre, la valeur utilisée sera faussée.

De même, comme pour ton cas, le nombre de paramètres risque d’augmenter au fil du temps, et dans ce cas, je me demandais, avec la solution 1, comment faire pour inclure automatiquement les nouveaux paramètres dans la table paramètre des clients lorsqu’ils vont télécharger la mise à jour du logiciel au démarrage ? Je ne sais pas si vous avez le cas ?

@Djejackk
Je ne connaissais pas, il y a-t-il un avantage par rapport à une table paramètre ? Je vais également regarder, merci !

@philouZ
Solution 1 également du coup, par contre comment gérez-vous le cas lorsqu’un paramètre est modifié par un autre utilisateur si vous stockez ça dans des classes ? Certains paramètres ne sont peut-être pas forcément à jour lors de leurs utilisations ? Ou bien j’ai mal compris.
Sinon c’est plus ou moins l’idée que j’avais également mais mêmes interrogations que pour @Frenchstring, notamment comment inclure automatiquement de nouveaux paramètres dans la table paramètre des clients lorsqu’ils téléchargent la mise à jour du logiciel ?


En tout cas merci à vous trois pour vos avis, la solution 2 semble être à éviter déjà

[philouZ]

Le fait de stocker les paramètres dans une classe suffit à rajouter les paramètres. On rajoute les membres nécessaires dans la classe et on renvoie la version modifiée. Maintenant nos paramètres n'ont pas vocation à bouger en permanence.

[Djsven]

Le fait de stocker les paramètres dans une classe suffit à rajouter les paramètres. On rajoute les membres nécessaires dans la classe et on renvoie la version modifiée. Maintenant nos paramètres n'ont pas vocation à bouger en permanence.

Je vois, du coup à chaque lancement, tu check que tous les paramètres stockés dans ta classe font bien partis de ta table Parametre ? Dans le cas où de nouveaux auraient pu être ajoutés ou seraient manquants ?

[philouZ]

En fait je stocke les paramètres sous forme de json. De cette manière je n'ai pas des centaines d'enregistrement dans la table parametre et j'ai une souplesse au niveau des paramètres qui est vraiment géniale. J'ai créé une colonne de type json dans ma table et je stocke

Code json :

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

{"param1":"valeur1","param2":"valeur2"...}

ensuite je fais

Code :

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

1
2
HLitRecherche(parametre,cle,valeur,hidentique)
clparametre = parametre.colonne_json

[frenchsting]

Bonjour,

Les paramètres sont chargés au démarrage de l'application dans un tableau associatif. On a créé des procédures globales pour y accéder / écrire.

[kunnskap]

Pour ma part solution 1. Table TBL_PARAMETRE_PRM (avec en rubrique un id unique, un code, un libellé, une valeur) car les noms de mes tables sont normalisés, et cette table possède sa classe associée, où chaque paramètre est dans une énumération.

Donc dans chaque application où j'ai besoin de paramétrage je n'ai qu'à créer cette table et importer la classe, et c'est tout.

L'accès à chaque paramètre se fait en temps réel, on le get à chaque fois qu'on veut le lire il est donc toujours à jour au prix d'allers retours serveurs, m'enfin, c'est ridicule. Et au pire, enrichir la classe est toujours possible pour le gérer différement.

[Djsven]

Bonjour,

Merci à tous pour vos réponses.

@kunnskap "Où chaque paramètre est dans une énumération". C'est à dire ? Quelle est l'avantage de cette méthode ?


Sinon suivant vos conseils et mes compétences, je pense partir sur la solution 1 avec une table Paramètre avec pour rubrique un ID unique, un code (1A, 1B, 2A, 2B, 2C ... afin de regrouper et filtrer les paramètres par catégorie, le chiffre étant la catégorie, la lettre l'indice du paramètre pour cette catégorie) et une valeur.

Ensuite je créé une classe mappée à la table Paramètre CParametre et une classe tableau CTableauParametre où dans cette dernière j'aurai une méthode possédant une chaine contenant les différents paramètres de l'application. (Code paramètre <TAB> Libellé du paramètre <TAB> Code catégorie <TAB> Type de paramètre (texte, numérique, booléen...) <TAB> Taille max <TAB> Valeur par défaut <TAB> Aide), séparés par un RC.

Au démarrage de l'application, je charge tous les paramètres de la table Paramètre dans ma classe CTableauParametre, je vérifie que le dernier paramètre présent dans la chaine ci-dessus fait bien parti du tableau chargé dans CTableauParametre. (Si c'est pas le cas, je lance un traitement qui va parcourir tous les paramètres de la chaine ci-dessus et ajouter les paramètres manquants dans la table Paramètre avec pour valeur par défaut celle décrite dans ma chaine). De cette façon, il me suffit de rajouter les nouveaux paramètres à la fin de ma chaine, et au démarrage de l'appli mis à jour par les clients, ils seront automatiquement ajoutés à leur table Paramètre.

Pour récupérer la valeur d'un paramètre, j'ajoute simplement une méthode dans ma classe CTableauParametre qui attend comme paramètre le code paramètre et qui me retourne la valeur associé à ce paramètre.

Ensuite, j'ai ajouté dans ma chaine, le type de paramètre (Texte, numérique, booléen), la taille max autorisée afin de pouvoir créer une fenêtre de gestion des paramètres dynamique, autrement dit, dans cette fenêtre j'aurai un menu regroupant les catégories de paramètres. Au clic sur une des catégories, je récupérerais les paramètres correspondants à cette catégorie grâce à ma chaine (pour le libellé etc) ainsi que les valeurs de la table Parametre rechargées. Je créerais dynamiquement les champs associés aux paramètres associés à cette catégorie, avec le libellé, le type de champ, la taille max, l'aide etc (Via ChampClone ou une zone répétée?). Avec un enregistrement pour chaque catégorie où je vérifierais que les valeurs saisies pour chaque paramètres de cette catégorie sont bien conformes (Méthode bVerifParametre avec la liste des valeurs autorisées pour chaque paramètre) avant d'enregistrer en BDD. Au changement de catégorie, je supprime tous les champs créés dynamiquement et je répète la même méthode. De cette façon, j'ai juste à ajouter mes nouveaux paramètres à ma chaine et tout est fait automatiquement.


Qu'en pensez-vous ? Il y a sans doute mieux et plus simple mais bon !

[frenchsting]

Bonjour,

Ce qui me "dérange", c'est ton histoire de chaîne. Pour retrouver un paramètre, je ne suis pas sûr que ce soit très simple. Un tableau associatif me semble plus simple à gérer... Dans notre ERP, on a un nom unique pour le paramètre.

Gâteau sous la cerise, rien ne t'empêche (comme nous l'avons fait), de créer des groupes de paramètres (Vente, Achat, impression,...). Dans ce cas, tu peux également, si besoin, faire la recherche de tous les paramètres d'un groupe.

[philouZ]

Moi ce que j'en dis c'est que le système de nommage des paramètres va vite poser problème. Un jour tu vas vouloir rechercher un paramètre dans la base pour le modifier, sauf que tu ne sauras pas comment il s'appelle.

Ensuite la création dynamique des champs me parait lourde et au final tu reviendras à un système classique parce que tu finiras par ne plus t'y retrouver surtout s'il y a un grand nombre de paramètres.

Ce n'est que mon avis et cela n'engage que moi.

[Djsven]

Bonjour

@frenchsting

En faite la chaine de paramètres sert uniquement à renseigner la table Paramètre (Code paramètre et valeur par défaut) quand celle-ci est vide ou pas à jour, et à récupérer les infos de base (libellé, type de champs, taille, groupe de paramètre) non stockés en BDD afin de créer dynamiquement mes champs paramètres pour la fenêtre paramètre.

Sinon au démarrage, je chargerais la table paramètre dans un tableau de classe (ayant pour membres Code paramètre, Valeur paramètre mappés par rapport à ma table Parametre), donc pour récupérer la valeur, j'aurais simplement une méthode dans ma classe du style:

Code :

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

1
2
3
4
5
6
7
8
 
PROCÉDURE sGetValeurParametre(LOCAL sValeurParametre est une chaine) <métier>
soit nIndice = TableauCherche(m_tabParametre,tcLinéairePremier,"m_sPRMcode",sValeurParametre) 
si nIndice <> -1 alors
renvoyer m_tabParametre[nindice].m_sPRMvaleur
sinon
renvoyer ""
FIN

Du coup si je veux récupérer la valeur du code paramètre "1A" par exemple, j'aurais simplement à faire gpclTabParametre.sGetValeurParametre("1A").

Pour le tableau associatif, je comprends bien que ça soit plus simple à gérer, mais comment je stock toutes les autres informations (libellé, type de champ, taille, catégorie) ? Vu qu'un tableau associatif attends uniquement une clé et une valeur ?


Comment vous vous stockez le libellé, code groupe de paramètre etc. pour chacun de vos paramètres ? Directement dans votre table Parametre en BDD ?
Et votre fenêtre de gestion des paramètres, elle se remplie dynamiquement ? ou vous rajoutez à la main vos champs sur la fenêtre pour chacun de vos paramètres ?


@philouZ

Oui dans ce cas, je serais obligé de faire la correspondance avec ma liste de paramètre stockée dans ma classe afin de voir à quel code correspond le paramètre que je souhaite modifier. Tu conseillerais plutôt un nommage en toute lettre ?

Je pensais créer dynamiquement mes champs justement pour éviter de devoir ajouter à la main sur la fenêtre des champs pour chacun des paramètres, surtout si j'en ai 300, ça me paraissait plus simple à maintenir sur le long terme

Merci

[philouZ]

Oui dans ce cas, je serais obligé de faire la correspondance avec ma liste de paramètre stockée dans ma classe afin de voir à quel code correspond le paramètre que je souhaite modifier. Tu conseillerais donc de mettre le libellé directement en BDD ?

Je pensais créer dynamiquement mes champs justement pour éviter de devoir ajouter à la main sur la fenêtre des champs pour chacun des paramètres, surtout si j'en ai 300, ça me paraissait plus simple à maintenir sur le long terme

A long terme, si tu as 300 paramètres, tu ne retrouveras jamais celui que tu veux modifier. Je trouve qu'il est préférable de regrouper les paramètres qui vont ensemble, de cette manière c'est bien plus simple à retrouver lorsque tu veux en modifier un.

[Djsven]

Je suis d'accord avec toi mais si j'ai bien compris ta réponse c'est ce que je comptais faire justement puisque j'ai bien un code catégorie pour chacun de mes paramètres, juste que je ne le stock pas en BDD mais dans une chaine dans ma classe (Code paramètre <TAB> Libellé du paramètre <TAB> Code catégorie <TAB> Type de champ (texte, numérique, booléen...) <TAB> Taille max <TAB> Valeur par défaut <TAB> Aide).

Donc à l'ouverture de ma fenêtre de gestion des paramètres, j'aurais une liste de catégories de paramètres (Comme un menu). Au clic sur une des catégories, je parcourrais la chaine ci-dessus afin de récupérer les données des paramètres liés à cette catégorie (Libellé, type de champ, taille) afin de créer dynamiquement les champs de saisies sur la fenêtre pour cette catégorie. Ensuite, je récupère en BDD les valeurs des paramètres correspondantes à la catégorie cliquée afin de remplir les champs de saisies créés avec les valeurs à jour.

En faite je devrais peut-être plutôt tout stocker en BDD, (code paramètre, code catégorie, libellé, type de champ, taille, aide, valeur) dans la table Parametre, au lieu d'uniquement le code parametre et la valeur ? Comme ça au clic sur une des catégories, j'ai juste à faire une requête sur la base sur le code catégorie afin de récupérer la liste des paramètres correspondant avec directement toutes les informations pour pouvoir créer mes champs dynamiquement par rapport à la catégorie cliquée. Dans ce cas, ma chaine me sert uniquement à remplir/mettre à jour la table Parametre si les paramètres ne sont pas à jour ou manquants au lancement de l'appli.


Pour reprendre l'exemple des 300 paramètres, je ne chargerais pas directement les 300 champs à l'ouverture de la fenêtre. C'est uniquement au clic sur une catégorie que je créerais les champs de saisies pour les paramètres liés à la catégorie cliquée. Je n'aurais donc pas 300 champs à la suite mais peut-être une dizaine maximum par catégorie. Au clic sur une autre catégorie, je supprime tout les champs créés (après enregistrement en bdd si modification), et je recrée les nouveaux champs pour les paramètres liés à la nouvelle catégorie cliquée.


Je ne sais pas si je suis bien claire dans mon explication

[frenchsting]

Tu peux très bien faire un tableau associatif de structures.
Nous, on a uniquement table[Clé] = Valeur en chaîne.

Ton ajout / vidage dans la table me pose souci. A un moment donné, tu auras un paramètre de la catégorie vente à lire et un paramètre de la catégorie achat à utiliser (par exemple)...

On charge nos 1300 paramètres au démarrage. Si dans l'exécution, on fait une modif de valeur, alors elle est enregistrée en base et stockée dans le tableau associatif.
Pour vérifier et faire une modification (pour un paramétrage spécifique), on utilise une table dans laquelle on va mettre toutes les infos : Clé, Valeur, description, ... On a 2 champs de saisie pour les recherches : un pour la catégorie, l'autre pour la clé.

[Djsven]

Pas bête pour le tableau associatif de structures, je ne savais pas qu'on pouvait faire ça !

Pour l'ajout / vidage, je parlais uniquement pour la création dynamique des champs sur ma fenêtre de gestion des paramètres. Au clic sur une catégorie, je supprime tous les champs de saisies précédemment créés, et je créé les nouveaux champs par rapport à la catégorie cliquée. Mais ma variable globale contenant le tableau de classe des paramètres "gpclTabParametre", remplie à l'ouverture de l'application, n'est jamais vidée et contient toujours tous les paramètres de toutes les catégories. Au clic sur une autre catégorie sur ma fenêtre de gestion, ou en cliquant sur le bouton enregistrer, j'enregistre les éventuelles modifications en BDD et je mets à jour les valeurs des paramètres modifiés dans le tableau de paramètres présent dans ma classe "gpclTabParametre".

Le libellé, la description de vos paramètres etc. sont stockés directement en BDD dans votre table de paramètres, en plus de la clé et de la valeur ?

[frenchsting]

Bonjour,

Eh oui, avec Windev, il y a des trucs sympas !

Non, ce n'est pas stocké en mémoire car cela n'est pas utile. Lorsque l'on veut éditer des paramètres, on va dans la fenêtre et tout est chargé dans une table. En HF, le chargement est "instantané".
L'intérêt de n'avoir qu'une fenêtre est que tu n'as qu'un endroit à interdire aux utilisateurs.

Autre point que je n'ai pas précisé : on a 2 "groupes" de paramètres : ceux autorisés aux utilisateurs, et ceux qui ne peuvent être édités que par le superutilisateur. Cela permet que seul le SU puisse activer des modules payants. Un simple booléen dans une rubrique du fichier suffit.

[Djsven]

Bonjour,

Super merci beaucoup, je vais reprendre cette idée pour l'édition des paramètres plutôt que ma fenêtre à champs dynamiques, ça sera plus simple à gérer. L'idée du booléen pour des droits accessibles uniquement par le superviseur est également une bonne idée. Merci !

Juste une dernière petite question concernant le nommage des paramètres (clés). Comment les nommer pour qu'ils soient utilisables facilement ? Car se souvenir par exemple que le paramètre qu'on souhaite utiliser dans l'appli porte la clé "78" si on utilise des nombres, c'est pas super pratique, de même pour la relecture du code à l'avenir (ou alors utiliser des commentaires pour préciser dans le code à quel paramètre fait référence la clé utilisée mais bon !). Utiliser des clés en toutes lettres ? Genre "PRM_Devise" par exemple pour la clé de la devise utilisée au lieu de "78" ? Ou bien il y a une méthode plus simple pour faire le lien entre des clés numériques en BDD et un nommage en toutes lettres dans l'appli ?

Merci