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
Abs,
Robert
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”.
[quote=Flavio Almeida]Para quem usa JSF + JPA, este framework é “tudo de bom”.
[/quote]
Aliás, este é também um grande problema dele: ser voltado a JSF.
[]´s
Discordo,
Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.
Ahhh, só pode ser primeiro de abril. :twisted:
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.
[quote=luiz_renato]Discordo,
Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.[/quote]
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.
[quote=asaudate]
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[/quote]
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”.
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.
Sem grilo asaudate !! 
Boa informação ranophoenix !
[]'s
[2]
[2][/quote]
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
[quote=ranophoenix]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.
[/quote]
Taí, dessa eu não sabia. Continua sendo válido o uso de JBoss EL com essas integrações?
[]´s
[2][/quote]
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[/quote]
Seus comentários são perfeitamente válidos para o JSF 1.x. No JSF 2 muitas coisas foram melhoradas (a criação de componentes beira quase o trivial). Vale a pena dar uma conferida nas novidades. Segue um resumo:
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
[quote=asaudate][quote=ranophoenix]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.
[/quote]
Taí, dessa eu não sabia. Continua sendo válido o uso de JBoss EL com essas integrações?
[]´s[/quote]
Sim.
[2][/quote]
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[/quote]
Seus comentários são perfeitamente válidos para o JSF 1.x. No JSF 2 muitas coisas foram melhoradas (a criação de componentes beira quase o trivial). Vale a pena dar uma conferida nas novidades. Segue um resumo:
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
[/quote]
Sinceramente? Tirando a parte de componentização, que parece um pouco mais simples mesmo, o resto me parece mais do mesmo. A impressão é que ele continua gerando um caminhão de código caixa-preta, e que a maior diferença é que o que antes a gente conseguia usando algumas bibliotecas (como salvar estado, ter ajax nativo, etc.) agora é parte da spec.
Bom, como eu disse, é só uma impressão (não conheço JSF 2). Quando eu tiver um tempinho, faço um benchmark e posto por aqui…
[]´s
Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.
Fábio