Website + Sistema Web

Esse é um dos pontos (dos muitos) onde JSF é um lixo. Você vai ter que reescrever as telas novamente, em JSF.

Infelizmente essa é a solução, acho que compensa o trabalho para trabalhar com Java.

Ou simplesmente não use JSF. É ruim demais

Eu sugiro Apache Wicket, ou então qualquer tecnologia HTML/REST, como o bootstrap.

Mas eu posso usar bootstrap com Java ?

rodrigo.uchoa:

Ou simplesmente não use JSF. É ruim demais

Eu sugiro Apache Wicket, ou então qualquer tecnologia HTML/REST, como o bootstrap.

Ruim demais? Baseado em…?

Uma coisa, se o design foi feito corretamente, o css estruturado e tal, você pode reutilizar e fazer alguma modificações pra se adequar ao JSF, mas ai vai aproveitar mais o css mesmo.

Ruim demais? Baseado em…?

Uma coisa, se o design foi feito corretamente, o css estruturado e tal, você pode reutilizar e fazer alguma modificações pra se adequar ao JSF, mas ai vai aproveitar mais o css mesmo.

Baseado em tanta coisa que acho que não cabe aqui. Seria melhor abrir outro tópico.

Pra mim, cogitar que o “o design tem que ser feito corretamente” para poder se adequar ao JSF é um paradoxo. O correto é fazer exatamente sem ter que ter JSF em mente.

rodrigo.uchoa:

Ruim demais? Baseado em…?

Uma coisa, se o design foi feito corretamente, o css estruturado e tal, você pode reutilizar e fazer alguma modificações pra se adequar ao JSF, mas ai vai aproveitar mais o css mesmo.

Baseado em tanta coisa que acho que não cabe aqui. Seria melhor abrir outro tópico.

Pra mim, cogitar que o “o design tem que ser feito corretamente” para poder se adequar ao JSF é um paradoxo. O correto é fazer exatamente sem ter que ter JSF em mente.

Bom, não sei em quais contextos você teve tantos problemas com o JSF, porém eu mesmo com alguns problemas que tive, principalmente integrando com o spring, continuo gostando bastante de JSF, e gostaria de saber alguns motivos que te fazer pensar o contrário, caso já não haja outro tópico sobre isso.

[]'s

Vou citar alguns pontos aqui porque JSF sucks:

• Não permite separação de papeis. Principalmente para realidade de empresas, onde há uma tendência de existir o designer e o programador, JSF não permite que o designer se preocupe somente com HTML/CSS. O mesmo problema que o amigo que abriu esse tópico relatou. Chega em um ponto onde o designer é obrigado a fazer já em JSF, que nenhum designer vai querer, ou então os programadores tem que refazer a tela em JSF depois, o que também é ruim pois acabam surgindo diferenças que nem sempre são aceitáveis.

• Difícil de manter. Sistemas JSF tendem a ter lógica de apresentação espalhada pelas telas xHTML e pelos Managed Beans (render, reRender, etc). Tende a ser muito pior manter do que se o código fosse centralizado somente em classes java.

• Difícil (ou seria impossível) de escrever testes unitários. Relacionado ao motivo acima, Existe lógica nas telas que é simplesmente difícil de testar.

• Complexidade para criar componentes. Estender um componente JSF mesmo, programaticamente, é o caos. Facelets ajuda um pouco, mas não atende todos os casos.

• JSF é um negócio inerentemente difícil de entender, com todas aquelas milhões de fases e etc. Acaba que a chance de algum programador júnior fazer uma besteira e nunca nem entender como fez, é muito maior.

• JSF normalmente é “acoplado” ao servidor. Se você um dia for querer migrar uma aplicação JSF do JBoss 5 pro 7 por exemplo, é dor de cabeça na certa.

No geral, é improdutivo e difícil de manter. Essa pelo menos é minha opinião depois de ter passado anos com JSF 1.2, e agora 2.0, e depois de algumas experiências sem ele.

Abs!

Só uma observação, o meu “viés” de comparação ai foi com Apache Wicket.

rodrigo.uchoa:

Vou citar alguns pontos aqui porque JSF sucks:

• Não permite separação de papeis. Principalmente para realidade de empresas, onde há uma tendência de existir o designer e o programador, JSF não permite que o designer se preocupe somente com HTML/CSS. O mesmo problema que o amigo que abriu esse tópico relatou. Chega em um ponto onde o designer é obrigado a fazer já em JSF, que nenhum designer vai querer, ou então os programadores tem que refazer a tela em JSF depois, o que também é ruim pois acabam surgindo diferenças que nem sempre são aceitáveis.

• Difícil de manter. Sistemas JSF tendem a ter lógica de apresentação espalhada pelas telas xHTML e pelos Managed Beans (render, reRender, etc). Tende a ser muito pior manter do que se o código fosse centralizado somente em classes java.

• Difícil (ou seria impossível) de escrever testes unitários. Relacionado ao motivo acima, Existe lógica nas telas que é simplesmente difícil de testar.

• Complexidade para criar componentes. Estender um componente JSF mesmo, programaticamente, é o caos. Facelets ajuda um pouco, mas não atende todos os casos.

• JSF é um negócio inerentemente difícil de entender, com todas aquelas milhões de fases e etc. Acaba que a chance de algum programador júnior fazer uma besteira e nunca nem entender como fez, é muito maior.

• JSF normalmente é “acoplado” ao servidor. Se você um dia for querer migrar uma aplicação JSF do JBoss 5 pro 7 por exemplo, é dor de cabeça na certa.

No geral, é improdutivo e difícil de manter. Essa pelo menos é minha opinião depois de ter passado anos com JSF 1.2, e agora 2.0, e depois de algumas experiências sem ele.

Abs!

Então, sobre a parte de papeis, acho que é só uma questão de “inversão”, pois ja tive trabalho onde o front-end trabalhava no design encima dos componentes renderizados do jsf, e o trabalho final ficou show de bola… acho que é só questão do front-end entender a renderização dos componentes utilizados… o que fez não reclamou do “desafio”.

Sobre a questão de logica nos xhtml, apliquei em um projeto MVP ao invés de MVC, mais trabalhando com conceito de backing bean, assim consegui separar muito bem as logicas, direto nas classes… fiz isso em casos em que realmente havia lógica que seria aplicada no xhtml.

Sobre testes unitário, usando MVP ficou mais sussegado, justamente por ter acesso aos componentes por bind, nos meus backing beans.

Sobre o resto, não lembro de ter tido problemas.
Cheguei a trabalhar muito pouco com o JSF 1.2, peguei pra mexer mais a partir do 2 mesmo.

[]'s

Então, sobre a parte de papeis, acho que é só uma questão de “inversão”, pois ja tive trabalho onde o front-end trabalhava no design encima dos componentes renderizados do jsf, e o trabalho final ficou show de bola… acho que é só questão do front-end entender a renderização dos componentes utilizados… o que fez não reclamou do “desafio”.

Sobre a questão de logica nos xhtml, apliquei em um projeto MVP ao invés de MVC, mais trabalhando com conceito de backing bean, assim consegui separar muito bem as logicas, direto nas classes… fiz isso em casos em que realmente havia lógica que seria aplicada no xhtml.

Sobre testes unitário, usando MVP ficou mais sussegado, justamente por ter acesso aos componentes por bind, nos meus backing beans.

Sobre o resto, não lembro de ter tido problemas.
Cheguei a trabalhar muito pouco com o JSF 1.2, peguei pra mexer mais a partir do 2 mesmo.

Mesmo sendo possível atingir essas coisas que você falou, acaba sendo mais difícil do que simplesmente não usar JSF e usar outra coisa. Eu sempre sou a favor do “keep it simple”

rodrigo.uchoa:

Então, sobre a parte de papeis, acho que é só uma questão de “inversão”, pois ja tive trabalho onde o front-end trabalhava no design encima dos componentes renderizados do jsf, e o trabalho final ficou show de bola… acho que é só questão do front-end entender a renderização dos componentes utilizados… o que fez não reclamou do “desafio”.

Sobre a questão de logica nos xhtml, apliquei em um projeto MVP ao invés de MVC, mais trabalhando com conceito de backing bean, assim consegui separar muito bem as logicas, direto nas classes… fiz isso em casos em que realmente havia lógica que seria aplicada no xhtml.

Sobre testes unitário, usando MVP ficou mais sussegado, justamente por ter acesso aos componentes por bind, nos meus backing beans.

Sobre o resto, não lembro de ter tido problemas.
Cheguei a trabalhar muito pouco com o JSF 1.2, peguei pra mexer mais a partir do 2 mesmo.

Mesmo sendo possível atingir essas coisas que você falou, acaba sendo mais difícil do que simplesmente não usar JSF e usar outra coisa. Eu sempre sou a favor do “keep it simple” :)

Então, não sei exatamente, no caso que você mencionou o wicket, ainda nunca usei.
Posso comparar (acredito eu) com o zk, que me parece ser um pouco semelhante, porém só utilizei o ZK com Grails… ai comparar questão de facilidade fica até sem graça rs
Mas comparando somente o fato do zk em si, não vejo motivos que me faça trocar zk por jsf+prime, pelo menos ainda não vi nenhum.

[]'s

Bom, eu me segurei muito para não entrar na discussão de vocês, mas se é tão difícil assim fazer um “site” com JSF o pessoal do BRADESCO deve ser fora do normal, pois o acesso a conta é todo em JSF.

Sem mais, não quero ficar aqui discutindo o que já foi discutido um milhão de vezes.

Cara usa o HTML5 friendly markup( http://docs.oracle.com/javaee/7/tutorial/doc/jsf-facelets009.htm#BABGECCJ ), ai tu consegue mapear o designer que te enviaram.

Acaba sendo gosto pessoal mesmo. Compartilho da opinião do rodrigo.uchoa. E olha que defendi JSF muito tempo, justamente por não ter conhecido outras tecnologias e estar acostumado à ele.

Hoje o JSF com certeza não está em minha primeiras opções de desenvolvimento, prefiro frameworks action-based.

Ah e quanto à solução do problema, seria melhor disponibilizar as informações que o site precisa via WebServices e o site (feito em qualquer linguagem / framework / plataforma) poderia consumir.

Eu já cansei de criticar o JSF por muitos motivos citados aqui e mais outros, então nem vou alongar. E não defendo nenhuma solução baseada em componentes server. É um desnecessário aprendizado para ficar num “mundo a parte” da comunidade de desenvolvimento web geral (não só Java).

Tive um problema parecido recentemente e até abri um tópico. Resultado? Larguei o JSF e estou estudando os actions based. Bem mais fácil pra minha vida.

Bom, eu me segurei muito para não entrar na discussão de vocês, mas se é tão difícil assim fazer um “site” com JSF o pessoal do BRADESCO deve ser fora do normal, pois o acesso a conta é todo em JSF.

Sem mais, não quero ficar aqui discutindo o que já foi discutido um milhão de vezes.

Nunca disse que era impossível. Mas no meu entender existem escolhas bem melhores Como já foi dito, as possíveis estratégias que podem ser utilizadas para minimizar os problemas, são necessárias pela própria escolha do JSF! Melhor do que criar uma estratégia para contornar esses problemas, é simplesmente não passar por eles.

Com relação ao friendly markup do JSF 2.2, ainda vejo sim como só mais uma tentativa de contornar um problema de algo que está errado na sua essência. A solução não é contornar todos os problemas criados pela própria tecnologia, e sim pensar em algo completamente diferente para que esses problemas não existam.

Abraço a todos.