Geração automática de formulários de dados

6 respostas
fbdo

Olá a todos!

Estou começando um projeto do zero no meu novo trabalho, e estou tentando começar direito. Vai ser uma aplicação 3 camadas, usando Hibernate+Spring no servidor, e NetBeans RCP no cliente. Aliás, se alguém tiver alguma crítica a estas escolhas, ou sugestões, serão bem-vindas.

Mas a questão não é essa. Seguindo o mais puro pricípio DRY, estou planejando gerar as telas básicas de cadastro usando reflection/annotations onde for possível. Me parece uma idéia muito óbvia, fico até com vergonha de tentar fazer do zero, mas fazem uns 3 dias que procuro algo satisfatório no google, e não acho nada! Alguém sabe de algo promissor nessa área?

Várias vezes pensei em usar a própria arquitetura JavaBeans, com seus BeanInfos e PropertyEditors para gerar interfaces. Tudo bem, é uma certa distorsão em relação a intenção inicial, mas… porque não? E de novo, me parece uma idéia tão óbvia, que não entendo pq não encontro nada relacionado na web, alguém saberia de um forte argumento contra?

Agradeço muito qualquer ajuda!

6 Respostas

ASOBrasil

Será que esse te ajuda?

https://genesis.dev.java.net/nonav/3.0/maven-site/pt-BR/index.html

O pai (ou um dos) é esse cara aqui: Michael Nascimento (http://weblogs.java.net/blog/mister__m/), qualquer coisa manda um e-mail para ele, acho que ele pode te ajudar quanto ao Genesis.

fbdo

Opa, obrigado pela resposta!

Já tinha encontrado com este carinha, aliás muito interessante. Mas ele não trabalha com a parte que estou envolvido no momento: a parte visual. Ele ajuda mais é com a ligação, fazer as coisas funcionarem, eu preciso de geração automática de formulários de dados. Claro que ele pode ajudar depois de definido como fazer.

Eu estou muito inclinado a fazer um Property Sheet especializado (ver http://platform.netbeans.org/tutorials/nbm-property-editors.html para um exemplo de uso no PropertyEditor), usando a especificação de JavaBeans. Minha preocupação fica em que essa não é uma aplicação muito convencional da especificação, queria mesmo saber se alguém vê algo muito contra.

Valeu!

sergiotaborda

Eu uso um sistema de metadados para criar as telas e já te aviso que não é simples obter telas bonitas com um sistema automático. Vc pode usar Reflection no seus beans de tela ( não necessáriamente são os beans de negocio)
para montar a tela. Provavelmente vc vai querer usar um FormLayout (JGoodies) ou algo assim. Mas ainda fica o problema de definir a posição e o tamanho dos campos.
A minha sugestão é que use Annotations no bean de tela. Para uma criação automática vc vai precisa definir a ordem dos campos e/ou a posição de cada um, além do tamanho (um textArea ocupa mais que um texfField)
Embora exista um esforço em construir esse tipo de framework é compensador porque vc não tem que contruir as telas na mão.

Mas atenção que ao construir a tela vc tai ter que amarrar certos eventos dos componentes para poder responder a eles. Ou vc faz isso antes ou durante : por exemplo vc pega o primeiro campo , verifica que ele é do tipo string, ai sabe que tem que usar um JTexfField (logo vai precisa de uma parametro na anootation se quiser usar um JTextArea) vc cria o JTextField dinamicamente e associa os eventos dele a algum objeto controlador e assim vai.

Para que funcione de forma mais simples vc precisa usar o padrão MVP (não o MVC) porque ele separa por completo o modelo da view e deixa todas as logicas num só objeto o Presenter. E é isso que vc quer. Criar o View dinamicamente, anexar os Listeners de evento automaticamente ao Presenter da tela de forma que ele possa responder aos eventos e consulta o modelo quando necessário.

Outra ideia para construir a tela dinamicamente é implementar seu proprio LayoutManager. Os controles são adicionados ad doc com um parametro de nome ( o nome do campo,por exemplo) ai o LayoutManager consulta algums metados em xml ou em annotations para saber em que posição e com que tamanho pintar o componente.
Esta estratégia nunca experimentei , mas é uma ideia.

Pesquise sobre MVP, FormLayout do JGoodies e Reflection

fbdo

Graaande Sergio!

Este é o caminho que resolvi seguir. Ontem já consegui implementar um formulário já usando reflection e BeanInfo. Vou substituir o BeanInfo com annotations em breve. Sobre a questão da posição dos campos no formulário, li um artigo do Jakob Nielsen (respeitado pesquisador UI, ver http://www.useit.com/jakob) que a melhor coisa que podemos fazer para nossos usuários são formulários simples, campos um embaixo do outro. Usar a criatividade e criar formulários com campos em posições imprevisíveis só complica. Vou seguir esta linha, por usabilidade e facilidade na implementação…

Para meu público, algo como um Property Sheet, comum em IDEs, é suficiente.

Mas valeu mesmo as dicas, se puder e quiser, vamos trocar algumas figurinhas, o que acha?

Um grande abraço!

sergiotaborda

fbdo:
Sobre a questão da posição dos campos no formulário, li um artigo do Jakob Nielsen (respeitado pesquisador UI, ver http://www.useit.com/jakob) que a melhor coisa que podemos fazer para nossos usuários são formulários simples, campos um embaixo do outro. Usar a criatividade e criar formulários com campos em posições imprevisíveis só complica. Vou seguir esta linha, por usabilidade e facilidade na implementação…

Isso é muito bom na teoria e parece que nos EUA eles não têm problemas com usuários mala. A verdade é que se a sua tela tiver muitos campos a estratégia de um por baixo do outro não funciona pelo simples fato que a altura da tela é limitada e ninguém gosta de formulários com scroll ( não em desktop , na web é aceitável).
Outro detalhe importante é atender à resolução do monitor e aos settings do desktop. Se vc fizer a tela em 1024x768 quando o seu usuário for usar o sistema numa tela 800x600 vai ficar uma porcaria. O FormLayout ajuda um pouco nisso com o conceito de dlu que é uma medida independente do tamanho da tela. O moral da historia é que construir telas swing é dificil e é bom que o seu framewok dê possibilidade de ajuste fino ou vai ter problemas depois. Claro que se vc tem a certeza absoluta que as telas têm poucos campos e que o design não será problema, então não complique. A questão é :vc tem a certeza ? :wink:

BiraBoy

Nos projetos que trabalhei até agora, web tbm não é aceitável não :smiley:

Criado 4 de dezembro de 2007
Ultima resposta 6 de dez. de 2007
Respostas 6
Participantes 4