Como você lida com formulário personalizações para diferentes clientes?

Question

Em nossa aplicação às vezes temos de fazer modificações menores GUI para diferentes clientes:

• Um cliente tem um campo de entrada os outros não têm.
• Outro cliente tem todos os campos padrão, mas um dos campos de entrada opcionais é obrigatória.
• Um terceiro cliente tem os campos padrão, mas um campo tem sua legenda mudou
• Um quarto cliente tem vários novos campos de entrada e um campo de entrada de múltiplas linhas existente tem de ser alterado para um campo de entrada de linha única (para dar espaço para os novos campos)
• ...

(Nota: Embora estes exemplos pode soar estranho, essas são coisas que nossos clientes pediram)

Como você lida com esses casos?

• Em geral
• Em Java / Swing

Atualmente nós projetamos a forma da maneira mais comum. Em tempo de execução fazemos ajustes como esconder, redimensionamento ou reposicionamento campos. Na validação de entrada que validar o conteúdo dependendo do cliente ativo.

Answer 1

Esta questão tem três aspectos:. Layout do formulário, armazenamento de dados e lógica de negócios configurável

Configuração de forma orientada esquema

A abordagem flexível para o layout do formulário pode ser obtido movendo o layout para um arquivo descritor. toolkits três GUI que suportam isso são QT, WPF e XUL. No entanto, AFAIK balanço não suporta diretamente essa capacidade. QT Jambi não permite que você use QT em Java como uma alternativa ao balanço e QT 4.5 vai estar disponível com licença LGPL. Esta não é uma solução puro-java, mas pode ser uma possibilidade se este eo atendente re-escrever o código UI é aceitável.

A vantagem do layout do formulário impulsionado configuração é que as personalizações podem ser feitas sem ter que manter uma compilação separada para cada cliente, por isso mesmo se você tiver uma base de código em exercício, você pode querer analisar se existe um caso de negócios para adoptar esse kit de ferramentas vs. manutenção específica do cliente várias construções. No entanto, para uma linguagem compilada, você ainda pode precisar configurar algum tipo de plug-in quadro para o código de formulário gerado.

armazenamento de dados configurável

Este é mais complexa. Você pode fazer isso de três formas, que têm os seus prós e contras.

1. A primeira abordagem é ter uma série de campos 'usuários' sobre a mesa, como 'User1', 'User2' etc. campos configurados nos formulários podem ser mapeados para esses campos - e um usuário genérico campo de recurso de mapeamento não deve ser difícil de implementar. Este é o mais eficiente do ponto de vista de consulta de banco de dados, mas sofre com a limitação de um número finito de campos possíveis. Se você tiver campos 'User1' para 'User20' você só pode apoiar 20 atributos definidos pelo usuário. Além disso, eles terão de ser agradável, de largura varchars genéricos, assim você vai ter nenhum tipo de segurança do banco de dados.

2. A segunda abordagem é ter uma cortina mesa atributos fora da entidade. Isso não lhe dá segurança de tipo, mas não deixá-lo ter tantos atributos como você quer. Construindo um manipulador genérico para isso também é bastante viável, mas o desempenho da consulta será afetado como você faz várias associações contra a mesa atributos.

3. Persistir campos definidos pelo usuário em um blob XML. Isso tem pouco a recomendá-lo, uma vez que torna os dados mais difíceis de acesso através do banco de dados. No entanto, tenho visto isto ser feito.

lógica de negócios configurável

Esta é uma questão muito mais espinhoso. Sem adição de código personalizado e mudando a sua construção, você tem algumas opções para fazer regras configuráveis ??de negócios: motores de regra, linguagens de script ou um conjunto de padrão de ligar / desligar recursos como campos obrigatórios

.

1. motores

   regra: Você realmente tem que criar seu aplicativo a partir do zero para usá-los, e eles têm as suas próprias limitações e fraquezas. ILOG, o titular neste campo, também é bastante caro. Para java, JESS pode ser uma opção.

2. Incorporado linguagem de script: Ao adicionar um intérprete para Jython, Groovy ou alguma outra linguagem interpretada-friendly JVM, você pode escrever plug-ins para o sistema sem ter que emitir uma nova compilação. Alguns carga de trabalho de testes ainda serão suportados, mas isso pode ser uma manutenção vencer geral.

3. configuração

   On / Off para recursos. Esta é a opção menos flexível, mas é relativamente simples e adiciona relativamente pouco em termos de dependências externas e custos de licenciamento. Ele também pode ser sua única opção se você está tentando configuração retrofit a algo que começou a vida como um bespoke aplicação.

Nenhum dos Acima

Se a resposta for 'nenhuma do acima', provavelmente você está preso com o costume constrói. Nesse caso, faça uma arquitetura plug-in para as formas para que você possa, pelo menos isolar os itens específicos do cliente em um módulo separado.

Answer 2

Há um par de maneiras diferentes de fazer isso. No entanto, é muito situacional dependente.

1. Em vez de adicionar a lógica de cliente diferente na mesma tela, tem uma tela diferente por cliente com um padrão usado por todos.

2. Custom constrói ou ramos de clientes. Embora isso pode ficar muito complicado.

3. Do exatamente como você fez e incorporar lógica específica do cliente nas telas.

4. Use algum tipo de mecanismo de regras para conduzir a sua interface.

Answer 3

Não consigo pensar em 4 abordagens:

1. Não faça isso. Sim, eu sei que é tarde demais agora, mas se você pode obter afastado com ele, sempre vender um produto padrão.

Se isso não for possível ...

2. Criar uma matriz de recursos, onde cada cliente pode definir os seus próprios requisitos, assinalando caixas (campo desativado, Present obrigatória, Presente Opcional etc). Ela limita como você pode apresentar suas informações na interface do usuário -. Você tendem para um design mais simples, mas é escalável e flexível
3. Ter uma página personalizada por cliente, onde cada página em si apoios em termos de lógica de negócios e validação. Talvez você pode começar afastado com 3 ou 4 variantes que são oferecidos a cada cliente.
4. Ramificação. Se você fizer isso, certifique-se que o cliente paga, porque é um PITA caro.

Answer 4

Eu não tenho certeza que tipo de aplicação é isso, mas quando se conflitantes pedidos de funcionalidades, que normalmente se ramificam a versão de cada cliente, e incluem apenas o código relevante em cada ramo.

Você está usando qualquer tipo de controle de código / sistema de controle de versão? SVN é o que usamos, e isso permite que você atualize cada ramo como você fazer alterações no código principal, de modo que o código nunca está fora de data.

Answer 5

Eu faria algo semelhante à tela dentro criação formas de MS Access, permitir que o cliente para adicionar / remover / modificar e entradas set por conta própria. Ele também lhes permitiria definir quais campos são obrigatórios e quais não são. Isso significaria mais trabalho no front-end para você, mas menos na parte de trás.

Answer 6

Gostaria de sugerir o uso de algum tipo de sistema de plugins. Para cada cliente, basta criar um plugin que modifica UI de seu aplicativo e tê-lo carregado na inicialização. Eu não sou um programador Java, então eu tenho medo que eu não posso publicar quaisquer trechos de código específico, apesar de tudo.