Boa tarde pessoal.
O que vocês acham dessa combinação JPA 2, EJB 3 e JSF 2.0?
E referente ao EJB alguem tem uma opinião sucinta sobre ele, pois ainda nao consegui formar uma opinião sobre ele, onde ele irá atuar entre o JPA.
A combinação é, atualmente, o padrão JEE, não?
Como assim descrição sucinta? Depende muito do que será feito e de como você pretende fazer.
[quote=drsmachado]A combinação é, atualmente, o padrão JEE, não?
Como assim descrição sucinta? Depende muito do que será feito e de como você pretende fazer.[/quote]+1
Eu particularmente sou contra JSF. É a pior parte da especificação EE. O resto ainda escapa 
E você prefere o que? Servlets e jsp?
Conhece bem de JSF 2?
Por que quem realmente conhece não acha ruim.
Oi cara!
Conheço bem sim. Uso JSF desde a especificação 1.0. Infelizmente sou obrigado a continuar usando porque muitas vezes é uma exigência contratual. Quando depende exclusivamente da minha escolha, tenho optado por Apache Wicket.
Então sempre que posso, sou um ativista anti-jsf sim
[quote=rodrigo.uchoa]Oi cara!
Conheço bem sim. Uso JSF desde a especificação 1.0. Infelizmente sou obrigado a continuar usando porque muitas vezes é uma exigência contratual. Quando depende exclusivamente da minha escolha, tenho optado por Apache Wicket.
Então sempre que posso, sou um ativista anti-jsf sim :)[/quote]
esse wicket parece webforms misturado com swing rsrs.
me diga abaixo qual framework é melhor em relação ao outro, coloque a frente J para Jsf e W para wicket (levando em consideração novos projetos)
1 - Aprendizado
2 - Documentação
3 - Tempo e facilidade de Desenvolvimento
4 - Tempo e facilidade de Manutenção
5 - Maior Coesão
6 - Menor aclopamento
7 - Facilidade no Layout, animações e ajax
8 - menos Engessado
9 - maior probabilidade de continuar em uso nos proximos 5 à 10 anos.
Sem nenhum exagero, marcaria wicket em todos os itens que você citou, menos no 9 que eu colocaria empate. E JSF só fica no mercado por imposição dos gigantes mesmo, nada mais. Se JSF não fosse especificação já teria morrido a muito tempo.
Vou acrescentar alguns pontos que acho relevante sobre wicket vs jsf:
[list]Delimitação clara de papeis. Com o wicket é possível ter uma equipe de design que saiba somente html/css, e os protótipos produzidos por eles podem ser quase que integralmente usados no sistema. Os desenvolvedores não farão design, somente código. Em JSF isso não é possível, pois os protótipos feitos pela equipe de design muitas vezes ainda precisam ser “transformados” no seu equivalente em JSF pelos programadores. O que acarreta em diferenças que muitas vezes o cliente se recusa a aceitar.[/list]
[list]Separation of concerns. Usando wicket a lógica de tela fica somente em código java, e não também nas telas como acontece em JSF (uso dos reRender, rendered, etc).[/list]
[list]Facilidade para testar. Uma vez que wicket usa somente código java, escrever testes é possível. Em JSF por outro lado, com toda a lógica de tela distribuída entre “actions” e “xhtmls”, escrever testes para camada de visão é um mito. Não dá pra fazer.[/list]
[list]Facilidade para criar componentes. Criar componentes no wicket é simples. Se você já teve que criar uma tag JSF, não estou falando de facelets, você sabe exatamente o que estou falando. E facelets, por mais que seja uma alternativa menos complexa à criação de componentes, ainda não ganha do Wicket.[/list]
[list]O ciclo de desenvolvimento é mais rápido. É possível desenvolver usando Jetty, um servidor embutido que sobe em 2 segundos. É instantâneo. JSF usariámos o Jboss 7 ou similares, que mesmo sendo um progresso enorme com relação as versões anteriores, ainda é pelo menos 10x mais lento. Vai subir em cerca de 20 segundos. Pra um desenvolvedor que faz esse start/shutdown dezenas de vezes por dia, isso conta.[/list]
[list]Wicket é completamente desacoplado do ambiente, portanto portar uma aplicação usando Wicket/Spring para um servidor diferente, por exemplo do Jboss 5.1 para Jboss 7.1, é indolor. Se você for tentar migrar alguma aplicação JSF 1.2/Seam 2.2 para Jboss 7, esteja pronto para sentir uma dor que poucos seres humanos experimentaram :)[/list]
[list]Como única vantagem do JSF, do ponto de vista de uma empresa, é que é mais fácil achar mão de obra. Pouca gente no mercado conhece Wicket.[/list]
Abraços.
[quote=rodrigo.uchoa]Oi cara!
Conheço bem sim. Uso JSF desde a especificação 1.0. Infelizmente sou obrigado a continuar usando porque muitas vezes é uma exigência contratual. Quando depende exclusivamente da minha escolha, tenho optado por Apache Wicket.
Então sempre que posso, sou um ativista anti-jsf sim :)[/quote]Por curiosidade, estudou a versão 2.0?
A 1.0 eu concordo com você que é horrível mesmo. ^^
Conheço a 2.0 sim
Na prática acaba não sendo tão diferente. Tudo que a 2.0 faz hoje já era possível fazer na 1.2. Só que dependíamos sempre de terceiros: JBoss Seam, Richfaces e etc. Mas é a mesma coisa, mudou só o namespaces das classes e anotações
Editado: Falha minha, acabei comparando com a 1.2… Realmente a 1.0 era bem pior!
[quote=rodrigo.uchoa][list]Delimitação clara de papeis. Com o wicket é possível ter uma equipe de design que saiba somente html/css, e os protótipos produzidos por eles podem ser quase que integralmente usados no sistema. Os desenvolvedores não farão design, somente código. Em JSF isso não é possível, pois os protótipos feitos pela equipe de design muitas vezes ainda precisam ser “transformados” no seu equivalente em JSF pelos programadores. O que acarreta em diferenças que muitas vezes o cliente se recusa a aceitar.[/list][/quote] Oi? Conheço sistema enormes que foram construídos com designs trabalhando na tela.
[quote=rodrigo.uchoa][list]Separation of concerns. Usando wicket a lógica de tela fica somente em código java, e não também nas telas como acontece em JSF (uso dos reRender, rendered, etc).[/list][/quote]Você poderia ter essa lógica em ManagedBean o que para falar a verdade é boa prática…
[quote=rodrigo.uchoa][list]Facilidade para testar. Uma vez que wicket usa somente código java, escrever testes é possível. Em JSF por outro lado, com toda a lógica de tela distribuída entre “actions” e “xhtmls”, escrever testes para camada de visão é um mito. Não dá pra fazer.[/list][/quote]Cara, é só chamar o método no ManagedBean que você vai poder realizar seu teste… Dá para testar tranquilamente… Já fiz isso sem grande esforço.
[quote=rodrigo.uchoa][list]Facilidade para criar componentes. Criar componentes no wicket é simples. Se você já teve que criar uma tag JSF, não estou falando de facelets, você sabe exatamente o que estou falando. E facelets, por mais que seja uma alternativa menos complexa à criação de componentes, ainda não ganha do Wicket.[/list][/quote]não estou falando de facelets a ta, pq veio justamente para corrigir o problema da criação de componentes…
[quote=rodrigo.uchoa][list]O ciclo de desenvolvimento é mais rápido. É possível desenvolver usando Jetty, um servidor embutido que sobe em 2 segundos. É instantâneo. JSF usariámos o Jboss 7 ou similares, que mesmo sendo um progresso enorme com relação as versões anteriores, ainda é pelo menos 10x mais lento. Vai subir em cerca de 20 segundos. Pra um desenvolvedor que faz esse start/shutdown dezenas de vezes por dia, isso conta.[/list][/quote]HEIN?! Desde quando JSF é só com JBoss ou qualquer outro full profile???
[quote=rodrigo.uchoa][list]Wicket é completamente desacoplado do ambiente, portanto portar uma aplicação usando Wicket/Spring para um servidor diferente, por exemplo do Jboss 5.1 para Jboss 7.1, é indolor. Se você for tentar migrar alguma aplicação JSF 1.2/Seam 2.2 para Jboss 7, esteja pronto para sentir uma dor que poucos seres humanos experimentaram :)[/list][/quote]Realmente, JSF 1.2 é terrível.
Depois dessa… deixa pra lá…
Vamos lá, Hebert… Vou abordar seus comentários ponto a ponto:
Eu também conheço vários, onde isso não foi possível. De grandes clientes, caixa, banco do brasil, policia federal, anvisa, anatel, etc etc etc, etc… O que se faz normalmente é ensinar alguma coisa de JSF pro designer. A experiência acaba sendo frustrante pra todo mundo. Quase nenhum designer quer aprender JSF. E chegar a um nível onde ele consegue criar seu design de acordo com as limitações dos componentes do JSF, apesar de possível, é mais difícil e ainda é frustrante para o profissional.
Infelizmente não entendi. Você quis dizer criar todas as telas programaticamente? Fazer um bind da tela inteira em um backing bean, e programar tudo na mão sem usar tags? Acho pouco provavel disso dar certo, e tb no contexto do JSF não diria que seria uma boa prática. E o que quis dizer é que as telas JSF sempre estão repletas de lógica. Em wicket, por outro lado, vc não tem lógica nenhuma. Lógica é só em código java.
Também não entendi bem. Se você puder me mostrar exemplos, é melhor do que a gente ficar discutindo em vão.
COncordo que o facelets é uma melhoria. Mas ainda é MUITO RUIM.
Eu sei que não. Mas na prática é o que acontece em 99% das vezes. Quem usa JSF, vai usar Java EE de maneira geral. E a primeira opção de quem usa Java EE é usar um servidor full profile (mesmo que seja somente web profile ainda é ruim)
Enfim nós concordamos.
E não, NA PRÁTICA fazer um projeto com JSF 1.2 não é tão diferente de usar 2.0. Eu já participei de vários projetos usando as duas tecnologias. A forma de fazer é a mesma. Onde antes era um @Validator do Seam, agora é um @FacesValidator do JSF. Onde antes era um “a4j:support”, agora é um “f:ajax”. As especificações são bem diferentes, mas a 2.0 só fez incorporar features que já existiam em bibliotecas disponíveis no mercado e que as pessoas já utilizavam.
Pra encerrar, cara, gostaria de dizer que acho válido discussões. Mas não precisa essa atitude agressiva. Você conhece Wicket? Da uma oportunidade. Pode ser que mude de idéia. Eu mudei.
Abraço.
[quote]Oi? Conheço sistema enormes que foram construídos com designs trabalhando na tela.
Eu também conheço vários, onde isso não foi possível. De grandes clientes, caixa, banco do brasil, policia federal, anvisa, anatel, etc etc etc, etc… O que se faz normalmente é ensinar alguma coisa de JSF pro designer. A experiência acaba sendo frustrante pra todo mundo. Quase nenhum designer quer aprender JSF. E chegar a um nível onde ele consegue criar seu design de acordo com as limitações dos componentes do JSF, apesar de possível, é mais difícil e ainda é frustrante para o profissional. [/quote]Existe tanta técnica para facilitar a vida do design… Pois é, você teve experiência ruim e eu a boa… então não há o que mais discutir aqui.
[quote][quote]Você poderia ter essa lógica em ManagedBean o que para falar a verdade é boa prática…
Infelizmente não entendi. Você quis dizer criar todas as telas programaticamente? Fazer um bind da tela inteira em um backing bean, e programar tudo na mão sem usar tags? Acho pouco provavel disso dar certo, e tb no contexto do JSF não diria que seria uma boa prática. E o que quis dizer é que as telas JSF sempre estão repletas de lógica. Em wicket, por outro lado, vc não tem lógica nenhuma. Lógica é só em código java.[/quote][/quote] rendred=“managedBean.metodo()” com isso aqui você deixa a lógica no MB.
Também não entendi bem. Se você puder me mostrar exemplos, é melhor do que a gente ficar discutindo em vão.[/quote]Agora não tenho código aqui. [=
COncordo que o facelets é uma melhoria. Mas ainda é MUITO RUIM.[/quote]Bem, aí é gosto… E achei bem prático e fácil.
Eu sei que não. Mas na prática é o que acontece em 99% das vezes. Quem usa JSF, vai usar Java EE de maneira geral. E a primeira opção de quem usa Java EE é usar um servidor full profile (mesmo que seja somente web profile ainda é ruim)[/quote]De maneira geral… Bem, isso aí é algo que eu não vejo… Mas talvez o mercado de trabalho que você atua passou essa experiência para você.
[quote]E não, NA PRÁTICA fazer um projeto com JSF 1.2 não é tão diferente de usar 2.0. Eu já participei de vários projetos usando as duas tecnologias. A forma de fazer é a mesma. Onde antes era um @Validator do Seam, agora é um @FacesValidator do JSF. Onde antes era um “a4j:support”, agora é um “f:ajax”. As especificações são bem diferentes, mas a 2.0 só fez incorporar features que já existiam em bibliotecas disponíveis no mercado e que as pessoas já utilizavam. [/quote]Cara, então desculpe mas não vou argumentar mais nada. Falar que do 1.2 para 2.0 é a mesma coisa simplesmente confirmou o que eu pensei quando li sua primeira argumentação sobre jsf: experiência de jsf 1.2. Desculpe, mas seria falar em vão.
[quote]Pra encerrar, cara, gostaria de dizer que acho válido discussões. Mas não precisa essa atitude agressiva. Você conhece Wicket? Da uma oportunidade. Pode ser que mude de idéia. Eu mudei. [/quote]Não tenho problema algum em aprender outros frameworks. Hoje trabalho com Spring sendo que a 9 meses atrás sabia -1 dele. Só vejo que você ta colocando o Wicket como mil maravilhas, mas eu já vi muita gente descendo o pau nele. Não gosto disso. Hoje não tenho tempo para aprender o Wicket, mas quando o tiver não terei problema algum, não sou e nunca serei xiita. Já cansei de aconselhar pessoas a não utilizarem o JSF por diversos motivos, e incrivelmente, nenhum deles foram citados aqui.
QUando você tiver oportunidade, da uma olhada no wicket sim. Ai você vai entender melhor o que eu quis dizer, principalmente nos pontos do uso de designers, facilidade pra testar, e ausência de lógica nas telas.