Do meu ponto de vista, layout ainda é uma questão bem complicada em java para quem não conhece a fundo a questão.
Como eu também não desenvolvo muito para desktop, utilizado o MigLayout, que substitui todos os outros layout managers e possui uma referência única e razoável.
A melhor escolha depende dos requisitos não-funcionais do projeto. Por exemplo:
Pode ser necessário evoluir a tela em questão e a ferramenta (netbeans) passar de facilitador a impedimento, devido a limitações técnicas ainda desconhecidas?
A ferramenta (netbeans) estará sempre disponível no ambiente de desenvolvimento para manutenções futuras?
O programa tem possibilidade de ter uma vida longa e futuras versões do netbeans não serem compatíveis com a atual (o que já aconteceu antes)?
O impacto de mudar do netbeans para outro tipo de design seria muito grande?
Enfim, se for um utilitário específico, não há problema nenhum.
Já se for um projeto longo, com muitas telas, a dificuldade inicial de usar um gerenciador de layout mais conceituado vale a pena, pois vai gerar mais benefícios no decorrer do tempo.
O código gerado pelo Netbeans é detestável. [/quote]
Pode até ser,mas o fato é que com ele eu fiz em 15 min o que não fiz em uma manhã toda [/quote]
É isso mesmo.
O problema é que depois o que ele faz é difícil de ajeitar - normalmente o principal problema que você costuma ter é que é difícil fazer coisas centralizadas, se usar o GroupLayout.
Outra coisa chata no NetBeans é que até você se acostumar ao jeito que ele funciona, você acaba fazendo uma barbaridade, que é a de ficar editando o código Java “por fora” para que você possa fazer certas coisas que na verdade até são possíveis, mas estão um pouco escondidas.
Gosto mais do WindowBuilder porque, fora dar suporte ao GroupLayout, ele permite que você use o MigLayout e até converta algum projeto de um layout para outro. Além disso, você pode editar seu código à vontade (guardadas as devidas proporções) e não proíbe você de editar um pedaço do código da tela. Ele até permite que você crie aquelas telas onde você cria os componentes dinamicamente (por exemplo, um array de botões) e ele não se perde “muito” como o NetBeans.
O código gerado pelo Netbeans é detestável. [/quote]
Pode até ser,mas o fato é que com ele eu fiz em 15 min o que não fiz em uma manhã toda [/quote]
É isso mesmo.
O problema é que depois o que ele faz é difícil de ajeitar - normalmente o principal problema que você costuma ter é que é difícil fazer coisas centralizadas, se usar o GroupLayout.
Outra coisa chata no NetBeans é que até você se acostumar ao jeito que ele funciona, você acaba fazendo uma barbaridade, que é a de ficar editando o código Java “por fora” para que você possa fazer certas coisas que na verdade até são possíveis, mas estão um pouco escondidas.
Gosto mais do WindowBuilder porque, fora dar suporte ao GroupLayout, ele permite que você use o MigLayout e até converta algum projeto de um layout para outro. Além disso, você pode editar seu código à vontade (guardadas as devidas proporções) e não proíbe você de editar um pedaço do código da tela. Ele até permite que você crie aquelas telas onde você cria os componentes dinamicamente (por exemplo, um array de botões) e ele não se perde “muito” como o NetBeans. [/quote]
Sem falar que com ele você também 15 minutos para fazer uma tela que na mão você levaria a manhã inteira.
E o pior é que com o WindowBuilder as coisas ficam bem mais arrumadinhas que se eu fosse fazer no braço - já redesenhei algumas telas que estavam feitas com o NetBeans com o WindowBuilder e elas ficaram mais legíveis também (e passei o layout para o MigLayout).
Sabe quano você tem vontade de chorar porque você se esqueceu de fazer um backup (ou de subir para o controle de versão) daquele arquivo de definição de telas que o Netbeans gera para ele poder gerar código a partir dele? E então você teria de desenhar tudo no Netbeans de novo (argh)?
Então… - o WindowBuilder lê o código gerado pelo NetBeans e você pode então jogar fora esse tal arquivo de definição de telas do NetBeans.
Pode ser necessário evoluir a tela em questão e a ferramenta (netbeans) passar de facilitador a impedimento, devido a limitações técnicas ainda desconhecidas?
-[color=red]Muito provavelmente não.[/color]
A ferramenta (netbeans) estará sempre disponível no ambiente de desenvolvimento para manutenções futuras?
-[color=red]Sim.[/color]
O programa tem possibilidade de ter uma vida longa e futuras versões do netbeans não serem compatíveis com a atual (o que já aconteceu antes)?
[color=red]Não creio.[/color]
O impacto de mudar do netbeans para outro tipo de design seria muito grande?
[color=red]Não.[/color]
O caso é bem esse que vc citou,um aplicativo especifico pra suprir uma necessidade emergencial.
Tenho uma aplicação web responsável pela funcionalidade de venda de produtos.Essa aplicação é responsável por executar os processos de negócio da venda no BD.
O problema é que(me corrijam se eu estiver errado) a aplicação web não consegue instanciar as DLL´s da impressora fiscal que está na máquina cliente.
A minha solução foi criar um aplicativo Swing que acessa os dados da venda via REST e se comunica com o ECF.