Ajuda: Validação de campos em aplicações Swing

Programação Arquitetura
#1

Pessoal, (Feliz Natal e Ano novo)

Estamos migrando um aplicativo bem antigo que não possui MOUSE, lá o usuário deve ir de campo a campo com o mouse, em ordem (ida ou volta) até chegar ao confirmar ou cancelar.

Cada campo tem todo tipo de validação imaginável, o dono do software (e cliente) quer que tenhamos o mesmo comportamento, mas que funcione idêntico ao antigo (em relação as validações nos campos). Fizemos algumas poucas telas onde isso foi necessário e tivemos um trabalho imenso, sem contar que fica um código confuso e não funciona em muitos casos (cada dia o cliente descobre algum bug). Acho que isso não se sustenta.

Por exemplo, validação de DE / ATÉ para datas. Vira um inferno.

Obviamente, desde o começo sugeri que a grande maioria (se possível TODAS) as validações ficassem ao concluir a transação, ou seja, no botão confirmar, mas o cliente diz que isso afeta a produtividade do atendente (eles realmente não param de entrar com dados no sistema, o tempo todo).

A aplicação é em Swing (embora não utilizamos Swing diretamente, tem um framework fornecido pelo cliente) e o uso mouse é obrigatório.

Reforçando, minha opinião é que deveria haver um novo design para a parte de telas para que essas validações campo a campo fossem minimizadas, mas o cliente está intransigente em relação a isso.

Fica a pergunta, o que podemos fazer para ter validação campo a campo e não continuarmos nesse inferno de cross-field-validation, que no final não atende 100%.

Alguém sugere alguma leitura, pattern ou algo do tipo?

Muito obrigado

#2

pen_fold_uk,

Feliz ano novo!

Essa questão de validar só quando vc vai “commitar” as informações pode resolver em alguns casos, mas acredito que por ter muitos campos e ser necessidade da aplicação a validação logo após a digitação/mudança de campo será difícil seu cliente abrir mão .

Como são implementadas as validações nos textfield’s ? O próprio framework que vc’s usam implementa ou vc’s estão criando do zero?

#3

Especifique um pouco melhor quais são os problemas que você está enfrentando

#4

Obrigado pela resposta.

Fazemos o código de validação através de codificação, o framework não proporciona nada para isso. Inclusive se houver problema no campo, tempos que forçar para o foco ficar nesse campo até que ele tenha um valor válido.

:slight_smile:

#5

Também não entendi o problema. Por que o JFormattedTextField e uma série de InputVerifiers não atende?

#6

Obrigado,

Realmente não está claro, vou ver se consigo um exemplo real para passar aqui, e ver o que vocês têm de sugestão.

Não temos acesso ao Swing diretamente, temos apenas a opção de colocar validações em eventos: ao perder foco e ao ganhar foco.

Como ficaria uma validação de DE / ATÉ com apenas esses eventos? DE não pode ser maior que ATÉ e, por exemplo, o período total não pode ser superior à 2 meses? Isso considerando que a validação está nos próprios campos (através de seus eventos) e permitindo saltá-los para outros campos (pois pode-se utilizar o mouse). Ou seja, posso entrar com o DE e depois ir para NOME, e depois voltar para completar o ATÉ.

Eu acho que o problema é conceitual, não dá para imitar o comportamento de validações de um sistema que vai para frente e para trás nos campos de forma SEMPRE sequencial em um outro sistema que possui mouse e pode ter uma ordem arbitrária de execução dos eventos de cada campo.

Talvez eu não esteja saindo da caixa para olhar o problema, por isso gostaria de dicas de vocês.

Não conhecia InputVerifiers, vou dar uma olhada, e ver se de alguma maneira essa ferramenta do cliente pode expor isso para gente (caso InputVerifiers seja o que precisamos).

Obrigado

#7

Só com eventos não tem como. Você não tem como validar nada no lostFocus. É por isso que existe a classe InputVerifier e a classe Document.

#8

Muito obrigado,

Vou ver o que consigo aqui com InputVerifier e Document (não conhecia), pois a ferramenta é bem engessada.

:slight_smile:

#9

Pen, sendo um problema que você vai ter que resolver em toda e qualquer tela, acredito que seria interessante tbm desenvolver uma API de validações, concentrando validações de “tipos” comuns das telas em uma unico lugar.

Claro, depois de resolver o problema com os eventos

#10