Seam 3.0.0 Versão Final

JavaEvangelist Membro desde: 28/02/2004 22:49:47 Mensagens: 389 Offline

Acaba de sair a versão 3 final do framework que revolucionou o desenvolvimento de aplicações JEE 5, vamos ver o que ele será capaz de fazer pelo JEE 6:

http://in.relation.to/Bloggers/Seam300FinalReleased

The Seam development team is pleased to announce the final release of Seam 3.0. Seam is a modular collection of portable extensions and tooling for Java EE6. This latest version represents a significant milestone in Seam's history, as it is the first release to be based on the standardized component model defined by the CDI (JSR-299 Java Contexts and Dependency Injection) specification.

Seam's goal is to enable developers to create rich, standards-based internet applications by solving many of the challenges encountered when developing software in today's connected world. It achieves this by providing an integrated set of feature-centric modules, each targetted at a single area of concern. This modular design also allows users the choice of using individual Seam modules based on the requirements of their project, without forcing them to adopt the overhead of a monolithic framework stack.

Abs,

Robert

JavaBaby Membro desde: 01/09/2004 15:25:57 Mensagens: 75 Offline

puxa quanta notícia legal, richfaces 4, seam 3

vou ter q tirar um diazinho pra curtir esses frameworks

Para quem usa JSF + JPA, este framework é "tudo de bom".

Flavio Almeida wrote:Para quem usa JSF + JPA, este framework é "tudo de bom".

Aliás, este é também um grande problema dele: ser voltado a JSF.

[]´s

This message was edited 1 time. Last update was at 01/04/2011 08:39:29

Discordo,

Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.

GUJ Master Membro desde: 15/05/2006 16:23:01 Mensagens: 1262 Offline

Ahhh, só pode ser primeiro de abril.

fabiozoroastro wrote:Ahhh, só pode ser primeiro de abril.

eu me lembro que ano passado houve uma notícia de primeiro de abril dizendo que a fundação Apache havia comprado a fundação Eclipse, e que eles haviam trocado a logo do Eclipse rsrs

Melhor remenda para o JSFail.

This message was edited 1 time. Last update was at 01/04/2011 09:17:21

luiz_renato wrote:Discordo,

Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.

Luiz, eu não falei nada diferente do que você acabou de falar. Eu mesmo acho o JBoss Seam um produto excelente (uso sempre que sou obrigado a usar JSF =) ). O ponto é que, por ser voltado a JSF, o Seam tem um defeito. Seria muito melhor se, por exemplo, ele pudesse trabalhar com JSF E JSP, assim ele teria um leque muito maior de usuários. Além disso, o ponto é óbvio: JSF é uma tecnologia deficiente.

[]´s

asaudate, não me entenda mal, gosto sempre dos seus posts, mas há como esmiuçar a sua definição de deficiente? Ficou muito vago, quero saber, por curiosidade, quais os pontos que depreciam o uso da tecnologia JSF.

JavaEvangelist Membro desde: 11/08/2003 09:59:28 Mensagens: 442 Offline

asaudate wrote:
Luiz, eu não falei nada diferente do que você acabou de falar. Eu mesmo acho o JBoss Seam um produto excelente (uso sempre que sou obrigado a usar JSF =) ). O ponto é que, por ser voltado a JSF, o Seam tem um defeito. Seria muito melhor se, por exemplo, ele pudesse trabalhar com JSF E JSP, assim ele teria um leque muito maior de usuários. Além disso, o ponto é óbvio: JSF é uma tecnologia deficiente.
[]´s

O propósito do Seam sempre foi unir JSF ao JEE, pois a sun fez essas duas especificações como se uma não conhecesse a outra. Tornando o desenvolvimento uma dor de cabeça quando se desejava usar JSF/JEE(mais especificamente, EJBs).

Até por isso o nome "Seam".

JavaEvangelist Membro desde: 28/02/2004 22:49:47 Mensagens: 389 Offline

Pessoal, é bom lembrar que, apesar do foco principal ser JSF, nada impede de usá-lo com Wicket ou até mesmo GWT. Na própria documentação tem exemplos dessas e outras integrações.

This message was edited 1 time. Last update was at 01/04/2011 10:16:16

Sem grilo asaudate !!

Boa informação ranophoenix !

[]'s

Entusiasta Java Membro desde: 22/10/2007 17:53:18 Mensagens: 16 Offline

Grinvon wrote:mas há como esmiuçar a sua definição de deficiente? Ficou muito vago, quero saber, por curiosidade, quais os pontos que depreciam o uso da tecnologia JSF.

[2]

This message was edited 1 time. Last update was at 01/04/2011 11:30:49

rubense wrote:

Grinvon wrote:mas há como esmiuçar a sua definição de deficiente? Ficou muito vago, quero saber, por curiosidade, quais os pontos que depreciam o uso da tecnologia JSF.

[2]

Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção...). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.

EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.

Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.

Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.

Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.

[]´s

Notícias, artigos e o maior fórum brasileiro sobre Java