Comment gérez-vous les personnalisations de formulaires pour différents clients?

Question

Dans notre application, nous devons parfois apporter des modifications mineures à l'interface graphique pour différents clients:

• Un client a un champ de saisie que les autres n'ont pas.
• Un autre client possède tous les champs par défaut, mais l'un des champs de saisie facultatif est obligatoire.
• Un troisième client possède les champs par défaut, mais la légende d'un champ est modifiée
• Un quatrième client a plusieurs nouveaux champs de saisie et un champ de saisie multiligne existant doit être remplacé par un champ de saisie d'une seule ligne (afin de libérer de l'espace pour les nouveaux champs)
• ...

(Remarque: bien que ces exemples puissent sembler bizarres, ce sont les demandes de nos clients.)

Comment gérez-vous ces cas?

• En général
• En Java / Swing

Actuellement, nous avons conçu le formulaire de la manière la plus courante. Au moment de l'exécution, nous effectuons des ajustements tels que le masquage, le redimensionnement ou le repositionnement des champs. Lors de la validation de l'entrée, nous validons le contenu en fonction du client actif.

Answer 1

Ce problème présente trois aspects: la mise en forme du formulaire, le stockage de la base de données et la logique métier configurable.

Mise en forme du formulaire basé sur la configuration

Une approche flexible de la mise en forme du formulaire pourrait être obtenue en déplaçant la mise en page dans un fichier descripteur. Trois kits d’interface graphique prenant en charge cette fonctionnalité sont QT, WPF et XUL. Toutefois, AFAIK Swing ne prend pas directement en charge cette fonctionnalité. QT Jambi vous permet d'utiliser QT sur Java comme alternative à Swing et QT 4.5 sera disponible avec les licences LGPL. Ce n'est pas une solution purement java, mais peut être une possibilité si cela et la réécriture par l'opérateur du code de l'interface utilisateur sont acceptables.

L’avantage de la présentation de formulaire pilotée par la configuration est que les personnalisations peuvent être effectuées sans qu'il soit nécessaire de conserver une version distincte pour chaque client. Ainsi, même si vous avez une base de code pour les opérateurs historiques, vous souhaiterez peut-être vérifier s'il existe une analyse de rentabilisation. d'adopter une telle boîte à outils plutôt que de conserver plusieurs versions spécifiques à un client. Cependant, pour un langage compilé, vous devrez peut-être toujours configurer un framework de plug-in pour le code de formulaire généré.

Stockage de base de données configurable

Ceci est plus complexe. Vous pouvez le faire de trois manières, qui ont leurs avantages et leurs inconvénients.

1. La première approche consiste à avoir une série de champs "utilisateur" sur la table, tels que "Utilisateur1", "Utilisateur2", etc. Les champs configurés sur les formulaires peuvent être mappés sur ces champs - et un utilisateur générique la cartographie sur le terrain ne devrait pas être difficile à mettre en œuvre. C'est la solution la plus efficace du point de vue d'une requête de base de données, mais elle souffre de la limitation d'un nombre fini de champs possibles. Si vous avez les champs "Utilisateur1" à "Utilisateur20", vous ne pouvez prendre en charge que 20 attributs définis par l'utilisateur. En outre, ils devront être des varchars génériques larges et agréables, de sorte que vous n’obtiendrez aucune sécurité de type dans la base de données.

2. La deuxième approche consiste à avoir une table d'attributs suspendue à l'entité. Cela ne vous donne pas la sécurité de frappe, mais vous permet d'avoir autant d'attributs que vous le souhaitez. Il est également tout à fait possible de créer un gestionnaire générique à cet effet, mais les performances de la requête seront affectées si vous effectuez plusieurs jointures dans la table des attributs.

3. Conserve les champs définis par l'utilisateur dans un blob XML. Cela a peu à recommander, car cela rend les données plus difficiles d'accès via la base de données. Cependant, je l’ai vu faire.

Logique commerciale configurable

C’est une question beaucoup plus épineuse. Sans ajouter de code personnalisé ni modifier votre construction, vous disposez de quelques options pour appliquer des règles métier configurables: moteurs de règles, langages de script ou ensemble de fonctionnalités d'activation / désactivation standard telles que les champs obligatoires.

1. Moteurs de règles: vous devez vraiment concevoir votre application à partir de rien pour les utiliser. Elles ont leurs propres limitations et faiblesses. ILOG, le titulaire dans ce domaine, est également assez cher. Pour Java, JESS pourrait être une option.

2. Langage de script incorporé: en ajoutant un interpréteur pour Jython, Groovy ou un autre langage interprété compatible JVM, vous pouvez écrire des plug-ins pour le système sans avoir à générer de nouvelle version. Des travaux de test seront toujours nécessaires, mais il se peut que la maintenance en ressorte gagnante.

3. Configuration On / Off pour les fonctionnalités. C'est l'option la moins flexible, mais elle est relativement simple et ajoute relativement peu de dépendances externes et de coûts de licence. Cela peut également être votre seul choix si vous essayez d’adapter la configuration à quelque chose qui a commencé comme une application sur mesure.

Aucune des réponses ci-dessus

Si la réponse est «Aucune des réponses précédentes», vous êtes probablement bloqué par des versions personnalisées. Dans ce cas, créez une architecture de plug-in pour les formulaires afin de pouvoir au moins isoler les éléments spécifiques au client dans un module séparé.

Answer 2

Il existe différentes manières de s'y prendre. Cependant, cela dépend beaucoup de la situation.

1. Au lieu d’ajouter une logique client différente dans le même écran, placez un écran différent pour chaque client, avec un écran par défaut utilisé par tout le monde.

2. Constructions personnalisées ou branches client. Bien que cela puisse être assez compliqué.

3. Faites exactement comme vous et intégrez une logique spécifique au client dans les écrans.

4. Utilisez un type de moteur de règles pour gérer votre interface.

Answer 3

Je peux penser à 4 approches:

1. Ne pas. Oui, je sais qu'il est trop tard maintenant, mais si vous pouvez vous en tirer, vendez toujours un produit standard.

Si cela n'est pas possible ...

2. Créez une matrice de fonctions dans laquelle chaque client peut définir ses propres exigences en cochant des cases (Champ désactivé, Présent obligatoire, Présent facultatif, etc.). Cela limite la manière dont vous pouvez présenter vos informations dans l'interface utilisateur. Vous avez tendance à adopter un design plus simple, mais il est évolutif et flexible.
3. Créez une page personnalisée par client, dans laquelle chaque page se prend en charge en termes de logique métier et de validation. Vous pouvez peut-être vous en tirer avec 3 ou 4 variantes proposées à chaque client.
4. Branching. Si vous faites cela, assurez-vous que le client paie parce que c'est un PITA coûteux.

Answer 4

Je ne sais pas quel type d'application il s'agit, mais lorsque nous recevons des demandes de fonctionnalités en conflit, nous séparons généralement la version de chaque client et n'incluons que le code correspondant dans chaque branche.

Utilisez-vous un type de système de contrôle de code / de version? SVN est ce que nous utilisons. Il vous permet de mettre à jour chaque branche au fur et à mesure que vous modifiez le code principal. Le code n’est donc jamais obsolète.

Answer 5

Je voudrais faire quelque chose de similaire à l'écran de création de FORMS dans MS Access, permettre au client d'ajouter / supprimer / modifier et de définir ses propres entrées. Cela leur permettrait également de définir quels champs sont obligatoires et lesquels ne le sont pas. Cela signifierait plus de travail au début pour vous, mais moins à l’arrière.

Answer 6

Je suggérerais d'utiliser une sorte de système de plugin. Pour chaque client, créez simplement un plug-in qui modifie l'interface utilisateur de votre application et le chargez au démarrage. Je ne suis pas un programmeur Java, je crains donc de ne pouvoir publier d'extraits de code spécifiques.