| Autor |
Mensagem |
|
|
|
Quanto ao instalador, realmente precisa melhorar e muito
|
 |
|
|
Quando fizerm um HTML x que acesse tudo que é periférico na máquina pode até ser.
Agora se restringirem o applet do Java muito sistema vai parar de funcionar.
Tudo que é sistema Web que imprime etiqueta, rótulo, acessa catraca e etc.
Claro dá pra resolver pelo BackEnd, mas é retrocesso.
|
 |
|
|
O UML é uma notação para modelagem.
Quando não precisarmos mais fazer MER pra modelar banco de dados ou modelar as classes antes de programar, o UML será ainda útil na engenharia reversa, ou até que alguém faça uma notação de modelo mais atual.
Se o próprio código for a documentação, e/ou os diagramas forem automaticamente gerados pelo código é óbvio que a UML é desnecessária, porém ela pode ser usada para a comunicação como o VinyGodoy explicou brilhantemente.
A linguagem e os diagramas são formas de nos comunicar, seja com nós mesmos ou com as máquinas
|
 |
|
|
|
Interessante !
|
 |
|
|
mister__m wrote:Muita gente não conhece o CDI e não sabe do que ele capaz. Enquanto solução de DI, é muito superior ao Spring.
A questão é que o Spring não é apenas DI e tem muitas APIs baseadas nele - e, diferentemente do que se vende, amarradas com ele. Se fosse feito um esforço para torná-las independentes do Spring, realmente o Java EE 6 enterraria o Spring.
Trolls em 3, 2...
Eu concordo.
Eu penso que existem tecnologias que são referências e ficam como base para muitos e muitos sistemas, como foi o struts e claro o legado desses sistemas vai levar a muita gente ainda trabalhar com esse framework
Assim como Spring tem muitos e muitos sistemas, mas ficou no passado.
Os frameworks atuais aprenderam com os frames do passado e ficaram melhores, e assim vamos evoluindo.
Um exemplo pode ser o log4j e o slf4j.
Sistemas de ponta, ou de inovação irão usar novos frameworks até para testar se eles dão realmente conta e servirem como benchmark
Então naturalmente as tecnologias vão se sobrepondo.
|
 |
|
|
Paulo Silveira wrote:Bill Burke anuncia uma futura morte do Spring. Bill Burke trabalha no grupo JBoss e sempre teve suas opiniões polêmcias:
http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/
Terminando com "For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.", Burke exprime diversos pontos.
Alguns fazem bastante sentido. O Java EE foi em direção a simplificação, quebrou muitas especificações e agora podemos utilizá-las sem precisar de um container full, colocando apenas o que é realmente necessário. O Spring parece ter indo para um lado um pouco mais complexo.
O que você está utilizando e o que você utilizará em seus próximos projetos Java? O CDI e as anotações realmente tornaram o Spring supérfluo?
Eu pulei direto do Struts pro Seam
E agora vou de Seam3 em um novo projeto.
Na minha visão o spring hoje é sim tecnologia do passado.
|
 |
|
|
|
Tente adicionar o 'schema' no from
|
 |
|
|
|
Windows 7
|
 |
|
|
Muito bom !!!
|
 |
|
|
|
Você está usando através de qual Application Server? Não está usando?
|
 |
|
|
diego.sas wrote:A melhor IDE é aquela que te faz mais produtivo.
Concordo.
Aproveito e digo que eu acho o NetBeans um pouco "engessado" o eclipse é mais mão na roda pra alterar xml e txt e tudo mais.
|
 |
|
|
Você pode usar o fileUpload http://www.primefaces.org/showcase-labs/ui/fileUploadSingle.jsf
Dá uma olha que tem várias opções inclusive com drag and drop
|
 |
|
|
SmartCardMan wrote:a unica coisa que me preocupa alem de tudo que foi falado é a eterna imparcialidade no verdadeiro interesse de uma API unica pra tudo isso, de fato ha algo de estranho quando percebe-se que os specification leads trabalham numa empresa de marketing digital.
Specification Leads: Werner Keil, Antoine Sabot-Durand
E-Mail Address: java-social@catmedia.us
antoine@sabot-durand.net
tendencioso.
Certo, mas em algum lugar eles tem que trabalhar né?
|
 |
|
|
|
Vc tá setando o ID do objeto? Se estiver remova isso e tente gravar
|
 |
|
|
Você pode implementar a segurança em WebServices de várias formas, pois o WebService vai trafegar XML sem criptografia alguma, portanto pode ser interceptado e interpretado
Se você utilizar o HTTPS na comunicação entre os sistemas vai incrementar o nível de segurança, desta forma você garante a segurança na internet/intranet porém permite que qualquer sistema conecte ou seja não é uma implementação na camada do WebServices e sim em uma camada externa a comunicação,
Para evitar de que qualquer sistema conecte você pode criar um método de autenticação que recebe usuário e senha e retorna um token criptografado validado, e esse token será usado em todas as outras requisições de métodos do webservice.
Se não existir o token ou ele restar inválido você não deixa conectar.
Essa camada de segurança você pode delegar para um application server como Websphere por exemplo http://www.ibm.com/developerworks/websphere/tutorials/0905_griffith/
|
 |
|
|