Discussion :

[LEK]

Bonjour,
je n'était pas sûr du forum où poser ma question mais je pense qu'ici elle est appropriée : dans ma boîte nous concevons un outil de gestion (pour la création d'un catalogue de produits particuliers avec des tarifs variants suivants les propriétés des produits, leur zone d'achat, etc...).
Nous avons donc un outil de base que nous vendons à nos clients et pour lequel on apporte nos propres évolutions ainsi que des modifications pour rajouter par exemple des propriétés aux produits propres à ceux du client auquel on vend notre solution.
Comme nous avons fait le choix de ne pas avoir une version de notre outil par client, nous nous efforçons de le garder assez génériques pour conserver une seule branche de code que nous ne cessons de faire évoluer. Lorsqu'un client nous demande des variations spécifiques au niveau de notre code nous sommes donc obligés d'utiliser un ensemble de flag qui rend notre code assez indigeste...
Ou alors si ce client demande à ajouter des attributs/propriétés qui se traduisent par un nouveau champ dans nos IHM on essaie (si possible) de lui donner un libellé assez générique pour que nos autres clients ne soient pas complètement déroutés lorsque l'on re-livrera une nouvelle version de notre solution... Mais il n'empêche que plusieurs d'entre eux ne comprennent pas la nouvelle notion ajoutée, car dans leur contexte de travail elle n'a pas de sens.
J'aimerais donc savoir quelles autres solutions existent à ce type de problème.... Dois-je faire en sorte que n'importe quel élément de mes IHM soit masquable suivant le client?

Merci pour toute réponses,
N'hésitez pas si vous avez des questions.

[bruno_pages]

Bonjour,

à priori votre erreur, qui est très commune, est que vous faites tout avec seulement ce qu'il y a dans le code source et rien d'autre. Paramétrez votre application avec un fichier de configuration, vous ferez ainsi un fichier par client indiquant ce qui doit être fait/affiché/etc pour chaque client, tout en gardant un code commun

[LEK]

Bonjour,
merci pour votre réponse. En fait, je me suis peut être mal exprimé mais nous nous basons effectivement déjà actuellement sur une sorte de configuration récupérée depuis une base de données.
Voici un exemple réel :
- Dans un premier temps nous définissions un formulaire pour ajouter des articles, celui-ci contient les informations suivantes :
* CodeArticle
* PrixArticle
*...

- Après avoir vendu notre application à un premier client 1, celui-ci nous demande d'ajouter un code externe et la liste des couleurs disponibles pour l'article dans notre formulaire.
- Nous avons alors 3 choix :
1. Soit afficher ces nouvelles information dans notre ancien formulaire alors quelles n'ont pas de sens métier pour tout nos anciens clients.
2. Ajouter des paramètres en base pour spécifier si le code externe ou la liste des couleurs doivent être proposés dans nos IHM ( ce qui pourrait donner un code du genre if(isFeatureEnabled("AffichageCodeExterne") Display("CodeExterneTextBox") )...
3. Afficher les informations complémentaires pour ce client dans une autre IHM ou un onglet lui étant spécifique mais trés rapidement nous nous retrouvons alors dépassé par le nombre de vues différentes à gérées avec une philosophie commune dans l'évolution de l'application à maintenir....

C'est confronté à ce type de problèmes qui m'ont l'air de s'accumuler de plus en plus que je crains que l'on ne finisse par conserver une véritable usine à gaz...

Mais si je suis votre logique, il faudrait pousser et automatiser la solution 2 c'est cela ? Cela dit nous avons parfois des données qui sont interdépendantes.... Si au regard de mon exemple vous avez d'autres idées, elles sont les bienvenues.
Merci encore.

[souviron34]

Ceci est un problème de modélisation / conception...

Il y a 2 approches :

• Soit les propriétés des objets manipulés sont connues (même si un certain nombre de clients ne les utilisent pas toutes) : alors, avant de concevoir la base, il faut avoir prévu pour toutes les propriétés, et avoir une IHM paramétrable
  
  
• Soit certaines des propriétés sont pour le moment inconnues (on peut permettre d'ajouter à posteriori des propriétés) : alors il faut prévoir une gestion dynamique (création) et de la base et de l'affichage.

En fonction de ceci, soit la paramétrisation peut se faire par un fichier de config, soit elle peut se faire via une requête à la BD.


Puis, comme le dit Bruno Pages, on a un affichage dynamique, qui via le tableau interne de la config du client, affiche ou non les éléments..

[Richard_35]

Bonjour à tous,

Pour rentrer un peu plus dans le détail, il y a, au préalable, un travail important de "listage" des objets que l'on souhaite paramétrables (affichables O/N).

Base de travail :
- tables ;
- champs ;
- formulaires ;
- champs de saisie ;
- boutons de formulaire ;
- ...

Conception :

Entité Client
- Id_Client (PK)
- Nom
...

Entité Objet
- Id_Objet (PK)
- Nom_Objet
- Nom_SousObjet
...
==> index unique Nom_Objet/Nom_SousObjet.

Entité Autorisation
- Id_Objet (PK)
- Id_Client (PK)
- Visible?
- Modifiable?
...

Relations
Client ---(0,n)---[possède les autorisations]---(0,n)--- Objet
==> (n,n) via Autorisation.

Ensuite, tous les Objets devront comporter une même routine événementielle ("avant affichage"), qui analysera la table Autorisation pour appliquer les droits préalablement paramétrés. En général, les Nom_Objet (par exemple, nom du formulaire de saisie) et les Nom_SousObjet (par exemple, nom du champ de saisie) sont "retrouvables" dynamiquement.

Ceci n'est qu'une base de travail "améliorable" qui nécessite une analyse autrement plus poussée...