Arquivo Discussoes de Programacao e Tecnologia 
Amigos,
Todos as pessoas que pergunto sobre o que eles acham do JSF ele sempre respondem que é um LIXO.
Então decidi criar um Tópico para deixarem as opiniões sobre:
Devo usar o JSF no desenvolvimento WEB?
Se não o que você sugere para uso?
Na realidade gostaria de saber onde investir para obter mais conhecimentos no desenvolvimento WEB, qual a forma mais segura, a menos complexa e etc…
Eu sempre indiquei. [=
Lógico que tem seus problemas como qualquer outra tecnologia web, mas eu o acho bem flexível. Gosto pacas.
a resposta para a a pegunta do tópico é curta e direta: dizem isso por que são fanáticas. Simples assim.
Tem seus pontos fracos, é um pouco mais lento do que vários outros frameworks mas a diferença é minima, você ao desenvolver com este framework tem um pouco menos de controle da parte javascript por exemplo mas a idéia do framework é justamente essa, o desenvolvedor não mecher com isso e focar na regra de negócio. A maioria dos frameworks que não tem estes problemas também não são tão produtivos quanto JSF para se desenvolver… você perde de um lado mas ganha do outro, então escolhe o que lhe valer mais a pena de acordo com os requisitos do projeto. Simples assim.
Cara eu já trabalhei com diversos frameworks do mercado, e os que me chamaram mais atenção foram o wicket e o JSF 2.0, mais com o wicket tinha que criar a interface toda na mão podendo usar componentes do jquery, mais comecei a usar o JSF 2.0 com primefaces e me apaixonei e hoje indico para todos que me pergunto, claro que tudo deve ser avaliado de acordo com a necessidade antes de montar uma arquitetura, mais vai que vc aprenderá muito com ele. Talvés alguém passou pelo JSF 1.3 e conserteza não gostou mais o 2 ta matando…
Aprenda os fundamentos básicos de web JEE…servlet e JSP.
kkkk isso não existe!!! Construir aplicações web hoje é uma atividade complexa, requerendo dos responsáveis uma serie de conhecimentos… Se vc é daqueles desenvolvedores RAD “desktopzeros” dos anos 90 pode se preparar para a borrachada…
Minha maior aplicação web hoje conta com 10 mil usuários habilitando com a media de 1000 sessões por minuto em JSF. Ambiente de produção = 1 Linux com 2GB + tomat e SQLServer.
Que lixo em??? kkkkkkkkkk
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
Agora que vc pode usar…sim.
Já vi muita gente falando por aí que JSF era ruim. Eu até já fis parte delas Oo. Na verdade quando comecei a aprender frameworks MVC, meu primeiro framework foi JSF e realmente eu não tinha gostado. Eu achava chato pra caramba ter que aprender todos os componentes html de novo para seguir os padrões do jsf, que na minha opinião, realmente não é muito bom sozinho. Então depois de estar desenvolvendo a algum tempo em VRaptor + Hibernate + Spring, tive a curiosidade(esses dias mesmo) de ver um tal de primefaces que li em alguns sites. Depois de entrar nesse site: http://www.primefaces.org/showcase-labs/ui/home.jsf e ver como é simples fazer muita coisa que com jquery + css + html é complicadíssimo, eu mudei de idéia. Hoje estou fazendo uma aplicação em (JSF + Primefaces) + (Hibernate + Spring) e estou gostando bastante. Mas quem deve optar é você mesmo. De uma olhada nesse site do primefaces e veja como é simples usar coisas que com html + jquery + css são muito difíceis.
Utilize frameworks como VRaptor, Play ou Rails. Abuse da arquitetura Restful. Estude muito e abuse de Javascript, ExtJS, jQuery. Abuse dos componentes JEE6 como JPA e EJB, Jax-RS. Mas pelo amor do Ser Superior no qual voce acredita, não use JSF-lixo.
Eu gosto e defendo muito as especificações. Gosto de EJB, JPA, Servlets, Jax-WS e RS. Mas JSFail não.
@FernandoFranzini, se sua aplicação suporta várias pancadas, nao é mérito somente do JSF, e o Container JEE? Boas Praticas? Os recursos do JEE? A infra? acho que JSF é o que menos influencia ai.
Repito, utilize frameworks com arquitetura Restful e SOA-ready como Vraptor, Rails, Play, Servlet, abuse do JS, Extjs, jQuery, e por favor, ajude para que JSFail nao cresça na comunidade Java, deixando de usa-lo.
Utilize frameworks como VRaptor, Play ou Rails. Abuse da arquitetura Restful. Estude muito e abuse de Javascript, ExtJS, jQuery. Abuse dos componentes JEE6 como JPA e EJB, Jax-RS. Mas pelo amor do Ser Superior no qual voce acredita, não use JSF-lixo.Eu gosto e defendo muito as especificações. Gosto de EJB, JPA, Servlets, Jax-WS e RS. Mas JSFail não.
@FernandoFranzini, se sua aplicação suporta várias pancadas, nao é mérito somente do JSF, e o Container JEE? Boas Praticas? Os recursos do JEE? A infra? acho que JSF é o que menos influencia ai.
Repito, utilize frameworks com arquitetura Restful e SOA-ready como Vraptor, Rails, Play, Servlet, abuse do JS, Extjs, jQuery, e por favor, ajude para que JSFail nao cresça na comunidade Java, deixando de usa-lo.
Obrigado amigos pelas respostas, eu tambem estou usando em um sistema que estou criando JSF + PrimeFaces + Hibernate 3 + Spring Security e não estou me arrependendo só queria entender por que JSF é um lixo.
Pode responder isso lucasmurata?
Pois realmente a versão 1.2 do JSF era horrivel, mas a 2.0 parece estar muito estável e bem bacana.
Obrigado amigos pelas respostas, eu tambem estou usando em um sistema que estou criando JSF + PrimeFaces + Hibernate 3 + Spring Security e não estou me arrependendo só queria entender por que JSF é um lixo.Pode responder isso lucasmurata?
Pois realmente a versão 1.2 do JSF era horrivel, mas a 2.0 parece estar muito estável e bem bacana.
Eu nao trabelhei com JSF 2.0, nem primefaces, entao o que eu digo eh sobre JSF 1 e richfaces.
Atende de maneira pratica 90% das suas necessidades. Mas se voce precisa qualquer coisa diferente, um javascript, ou uma chamada AJAX que nao tenha que passar pelo ciclo de vida dele voce ta f…
Customizar um componente entao era um parto.
Tem habito tenebroso de falhar silenciosamente. (Ah, voce que nao soube configurar/usar) Eh, tem isso tambem, o ciclo de vida nao eh nenhum pouco intuitivo.
Gera um html terrivel, aplicar css nele eh um saco.
O famoso e maravilhoso sistema de binding de componentes dele nunca funcionou direito (pelo menos eu nunca consegui fazer funcionar direito, olha eu de novo nao sabendo configurar, lembrando que tenho pelo menos uns quatro livros sobre ele aqui em casa, ja li todos e mesmo assim ele vivia me surpreendendo com erros silenciosos inesperados).
Pessoalmente prefiros os frameworks action based, voce tem um pouco mais de trabalho ate criar uma boa infra-estrutura, componentes etc… mas depois eh bem mais produtivo e bem mais facil de dar manutencao.
Quanto ao desempenho, nunca tive problemas com JSF.
O principal problema do JSF é que ele gerencia a criação da HTML final e também o formato das URLs. Em aplicações RIA para web 2.0, aonde você tem que mexer diretamente na estrutura DOM da página gerada e se preocupar com o formato e estrutura das suas URLs, você acaba se ferrando por causa do JSF.
Para demonstrar isso dê uma olhada na HTML gerada pelo JSF e você vai ver muita coisa gerada automaticamente. Então tente implementar no seu template JSF, sem usar nenhuma gambiarra escrota, algum efeito na página via javascript (com ou sem jQuery). Provavelmente você vai quebrar a cara. Se conseguir, tente então baixar algum conteúdo por ajax e alterar a estrutura da página dinamicamente com base na resposta do ajax. Vai quebrar a cara de novo. Tente personalizar algum detalhe do CSS, quebrou a cara de novo!
É aí que está o problema do JSF: Uma vez que ele toma para si a tarefa de gerenciar a criação da HTML, você acaba perdendo a liberdade de personalizá-la, sendo obrigado a seguir as regras impostas pelo JSF, e para alguns tipos de aplicações, estas regras impostas não são aceitáveis.
Uma possível saída para esse problema é você criar os seus componentes JSF personalizados para fazer isso, mas aí você acaba perdendo a produtividade prometida pelo JSF e tem ainda a tarefa extra de ajustar os seus componentes as necessidades do JSF, uma tarefa árdua. Assim acaba sendo mais simples, mais fácil e mais rápido fazer tudo com javascript e HTML você mesmo, pois o JSF vai acabar se tornando um elefante branco inútil no sistema.
Para sistemas que são compostos basicamente de telas de cadastro, consultas e relatórios CRUD, você pode usar o JSF e seja feliz. No entanto, você também pode usar uma grande gama de outras ferramentas (ex: REST + JSP + jQuery) e também ser do mesmo jeito.
No entanto se você quer fazer um site cheio de animações e efeitos, carregamento dinâmico de dados em tempo real, etc, o JSF não é uma boa ideia.
Talvez você decida que o que você precisa é simples o suficiente para que o JSF dê conta e você vai produzir muito bem e mais rápido do que se estivesse usando alguma outra coisa. Até que em uma bela sexta-feira 13 de lua cheia, o cliente chega com um requisito de fazer a sua tela de consulta de situação de venda de produtos que é completamente estática, ter que monitorar em tempo real a atividade do fluxo de provisionamento de venda de produtos, para que o operador não precise ficar dando F5 a toda hora e possa agir imediatamente sem estourar o prazo máximo de 30 minutos para a conclusão da venda. Isso daí você pode fazer com Ajax e jQuery, mas… OH NO!
O principal problema do JSF é que ele gerencia a criação da HTML final e também o formato das URLs. Em aplicações RIA para web 2.0, aonde você tem que mexer diretamente na estrutura DOM da página gerada e se preocupar com o formato e estrutura das suas URLs, você acaba se ferrando por causa do JSF.Para demonstrar isso dê uma olhada na HTML gerada pelo JSF e você vai ver muita coisa gerada automaticamente. Então tente implementar no seu template JSF, sem usar nenhuma gambiarra escrota, algum efeito na página via javascript (com ou sem jQuery). Provavelmente você vai quebrar a cara. Se conseguir, tente então baixar algum conteúdo por ajax e alterar a estrutura da página dinamicamente com base na resposta do ajax. Vai quebrar a cara de novo. Tente personalizar algum detalhe do CSS, quebrou a cara de novo!
É aí que está o problema do JSF: Uma vez que ele toma para si a tarefa de gerenciar a criação da HTML, você acaba perdendo a liberdade de personalizá-la, sendo obrigado a seguir as regras impostas pelo JSF, e para alguns tipos de aplicações, estas regras impostas não são aceitáveis.
Uma possível saída para esse problema é você criar os seus componentes JSF personalizados para fazer isso, mas aí você acaba perdendo a produtividade prometida pelo JSF e tem ainda a tarefa extra de ajustar os seus componentes as necessidades do JSF, uma tarefa árdua. Assim acaba sendo mais simples, mais fácil e mais rápido fazer tudo com javascript e HTML você mesmo, pois o JSF vai acabar se tornando um elefante branco inútil no sistema.
Para sistemas que são compostos basicamente de telas de cadastro, consultas e relatórios CRUD, você pode usar o JSF e seja feliz. No entanto, você também pode usar uma grande gama de outras ferramentas (ex: REST + JSP + jQuery) e também ser do mesmo jeito.
No entanto se você quer fazer um site cheio de animações e efeitos, carregamento dinâmico de dados em tempo real, etc, o JSF não é uma boa ideia.
Talvez você decida que o que você precisa é simples o suficiente para que o JSF dê conta e você vai produzir muito bem e mais rápido do que se estivesse usando alguma outra coisa. Até que em uma bela sexta-feira 13 de lua cheia, o cliente chega com um requisito de fazer a sua tela de consulta de situação de venda de produtos que é completamente estática, ter que monitorar em tempo real a atividade do fluxo de provisionamento de venda de produtos, para que o operador não precise ficar dando F5 a toda hora e possa agir imediatamente sem estourar o prazo máximo de 30 minutos para a conclusão da venda. Isso daí você pode fazer com Ajax e jQuery, mas… OH NO!
Olá! Eu concordo com você do jsf gerar o html final e ser um pouco chato de mecher nele. Mas só não entendi quando você falou em quebrar a cara para mecher no css. Você estava falando do JSF puro ou com Primefaces por exemplo? JSF puro realmente não é muito legal, mas com primefaces fica muito melhor. Os temas do primefaces já são legal, e ainda você pode criar seu tema em css no site do jquery tudo visual e depois baixar o css gerado. O que em termos de alteração visual fica bem mais legal.
Desde o início do ano passado, quando comecei a estudar mais a fundo Java, ouço dizer que JSF não é legal.
Resolvi estudar JSF e estou achando o framework muito interessante. Principalmente com PrimeFaces como muitos disseram nesse tópico.
Posso citar vários motivos do porque o JSF ser um lixo e ser fail. Motivos técnicos, pragmático, comunitario e pessoal.
Primeiro gostaria de salientar, antes que digam que nao conheço o framework tecnicamete, tenho sim experiencia com JSF 2. Estudei livro e tutoriais, desenvolvi um sistema do zero (que inclusive esta rodando em produção com sucesso e estamos migrando para VRaptor). Usei JSF 2 mais de 1 ano. Entao não é de repente que eu e outros desenvolvedores Java chegamos a esta conclusao do JSF ser ruim. São muitos os desenvolvedores Java com esta visão.
Posso citar aqui alguns motivos rapidamente para que o meu post nao fique grande:
1 - Dependecia excessiva de biblioteca de terceiros. Tente desenvolver voce mesmo seus componentes sem usar Prime, Open ou Richfaces. Para isso voce precisa entender o ciclo de vida de uma requisicao em JSF, e criar voce mesmo seus componentes em cima desse ciclo que nao é nada elegante. Ah, faz assim, cria um componente que renderiza rapido no browser e que trabalhe com requisicoes GET, PUT ou DELETE. Boa sorte.
2 - Voce ja lidou com um usuario de sistema? Voce esta usando seu componente pronto em Primefaces. Seu cliente pede pra voce mudar uma coisa no seu Datatable. Boa sorte com as gambiarras. Ou faz o seguinte: espere por uma atualizacao do Rich ou Primefaces que demoram eternidade para ver se vem com a mudanca.
3 - Impressao que da é que JSF nao foi desenhado para WEB. HTTP? REST? HTML, CSS e JS? XHTML do JSF 2 é um xml sem flexibilidade. Tente ter um controle fino de Javascript, de Ajax e de CSS. Tente estilizar seus componentes. Voce verá estrelinhas rodando na cabeça.
4 - Mistura entre cliente-side e server-side, acho que este é o seu pior ponto. Nao há transparencia. Voce chama componete da View no seu ManagedBean, e chama ManagedBean no seu View. Atualmente eu utilizo uma arquitetura que me permite independecia entre Client e Server usando VRaptor e Rails. O desenvolvimento Web tende a isso.
5 - Muita imaturidade para um projeto que esta ai desde 2003. Sao quase 9 anos. Nao vejo amadurecimento. Na web a evolucao é muito rápida. Menos com JSFail que é um framework mal acabado. 9 anos pra sair da versao 1 pra 2?
6 - Ele é Statefull e depende muito de sessions por ser component-based.
7 - Ele é um atrativo para os novatos e para os que nao gostam de estudar. “Olha! É tao simples. Basta esta tag e aparece esse componente!!” e caem na armadilha.
8 - Pesquise no proprio GUJ quantos e quantos topicos sobre, por exemplo, atualizar uma combobox com outro, combobox aninhados, atualizar datatable, etc, em JSF. Sao muitos desenvolvedores batendo a cabeça numa coisa que com jQuery + Ajax faria rapidamente.
9 - Sucetivel a POG, mesmo voce seguindo boas praticas no backend.
10 - Quase impossivel de integrar com outras tecnologias. Uma vez JSF, seu projeto sera JSF.
E posso citar tambem outros motivos.
Olha aqui uma lista de grandes figuras e desenvovedores Java criticando JSF (citacoes de 2004 a 2011): http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ (JSF Sucks). Tem inclusive o video do James Gosling, pai do Java dizendo: “I hate JSF with a passion” - Eu odeio JSF com paixao. Isso pode te ajudar a se definir tecnicamente o que é mais importante.
Ponto positivo do JSF:
1 - Fazer CRUD. Ok, voce vai viver de CRUD?
Hoje tem tanta coisa legal pra aprender e usar nos seus projetos. Largue o JSF, livre-se enquanto é tempo. Estude frameworks Restful como Vraptor, Rails, Grails, Play, aprenda Javascript (de verdade), para view use Extjs, jQuery UI, YUI, Dojo toolkit. Faça o que quiser. Mas nao contribua para que este cancer chamado JSFail se alastre na comunidade Java.
O único problema do JSF é que ele tem uma curva de aprendizado um pouco mais complexa e muitas pessoas desistem de “bater a cabeça” com ele muito rápido, eu particularmente já apanhei muito, mas depois de algumas horas de estudo hoje desenvolvo bem nele, acho uma ótima tecnologia.
Justamente…
eu desenvolvo com JSF 2.0 + Primefaces 3.0 + Hibernate, acho muito legal e facil de usar, uso o JSF 2 por conta do primefaces que é uma ótima biblioteca de componentes.
P/S: estou aprendendo Grails e achei bem legal, VRaptor achei um saco para configurar (Bibligoteca X+Y+Z+++++) quase nunca eu acertava porém é um framework muito bom !
Posso citar vários motivos do porque o JSF ser um lixo e ser fail. Motivos técnicos, pragmático, comunitario e pessoal.Primeiro gostaria de salientar, antes que digam que nao conheço o framework tecnicamete, tenho sim experiencia com JSF 2. Estudei livro e tutoriais, desenvolvi um sistema do zero (que inclusive esta rodando em produção com sucesso e estamos migrando para VRaptor). Usei JSF 2 mais de 1 ano. Entao não é de repente que eu e outros desenvolvedores Java chegamos a esta conclusao do JSF ser ruim. São muitos os desenvolvedores Java com esta visão.
Posso citar aqui alguns motivos rapidamente para que o meu post nao fique grande:
1 - Dependecia excessiva de biblioteca de terceiros. Tente desenvolver voce mesmo seus componentes sem usar Prime, Open ou Richfaces. Para isso voce precisa entender o ciclo de vida de uma requisicao em JSF, e criar voce mesmo seus componentes em cima desse ciclo que nao é nada elegante. Ah, faz assim, cria um componente que renderiza rapido no browser e que trabalhe com requisicoes GET, PUT ou DELETE. Boa sorte.
2 - Voce ja lidou com um usuario de sistema? Voce esta usando seu componente pronto em Primefaces. Seu cliente pede pra voce mudar uma coisa no seu Datatable. Boa sorte com as gambiarras. Ou faz o seguinte: espere por uma atualizacao do Rich ou Primefaces que demoram eternidade para ver se vem com a mudanca.
3 - Impressao que da é que JSF nao foi desenhado para WEB. HTTP? REST? HTML, CSS e JS? XHTML do JSF 2 é um xml sem flexibilidade. Tente ter um controle fino de Javascript, de Ajax e de CSS. Tente estilizar seus componentes. Voce verá estrelinhas rodando na cabeça.
4 - Mistura entre cliente-side e server-side, acho que este é o seu pior ponto. Nao há transparencia. Voce chama componete da View no seu ManagedBean, e chama ManagedBean no seu View. Atualmente eu utilizo uma arquitetura que me permite independecia entre Client e Server usando VRaptor e Rails. O desenvolvimento Web tende a isso.
5 - Muita imaturidade para um projeto que esta ai desde 2003. Sao quase 9 anos. Nao vejo amadurecimento. Na web a evolucao é muito rápida. Menos com JSFail que é um framework mal acabado. 9 anos pra sair da versao 1 pra 2?
6 - Ele é Statefull e depende muito de sessions por ser component-based.
7 - Ele é um atrativo para os novatos e para os que nao gostam de estudar. “Olha! É tao simples. Basta esta tag e aparece esse componente!!” e caem na armadilha.
8 - Pesquise no proprio GUJ quantos e quantos topicos sobre, por exemplo, atualizar uma combobox com outro, combobox aninhados, atualizar datatable, etc, em JSF. Sao muitos desenvolvedores batendo a cabeça numa coisa que com jQuery + Ajax faria rapidamente.
9 - Sucetivel a POG, mesmo voce seguindo boas praticas no backend.
10 - Quase impossivel de integrar com outras tecnologias. Uma vez JSF, seu projeto sera JSF.
E posso citar tambem outros motivos.
Olha aqui uma lista de grandes figuras e desenvovedores Java criticando JSF (citacoes de 2004 a 2011): http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ (JSF Sucks). Tem inclusive o video do James Gosling, pai do Java dizendo: “I hate JSF with a passion” - Eu odeio JSF com paixao. Isso pode te ajudar a se definir tecnicamente o que é mais importante.
Ponto positivo do JSF:
1 - Fazer CRUD. Ok, voce vai viver de CRUD?Hoje tem tanta coisa legal pra aprender e usar nos seus projetos. Largue o JSF, livre-se enquanto é tempo. Estude frameworks Restful como Vraptor, Rails, Grails, Play, aprenda Javascript (de verdade), para view use Extjs, jQuery UI, YUI, Dojo toolkit. Faça o que quiser. Mas nao contribua para que este cancer chamado JSFail se alastre na comunidade Java.
bom…descordo da maioria, alguns dos seus argumentos por outro lado considero válidos mas vamos la:
1 - Ué não é uma coisa completamente normal ter bibliotecas de terceiros quando desenvolvemos na plataforma java? Vai me dizer que nunca reparou na quantidade que o hibernate por exemplo usa? Quanto a trabalhar com requisições put, delete, etc, se você precisa fazer isso, você pode integrar o jsf com spring e usar o controller do spring para isso, me parece uma excelente dupla mesmo que você não precise disso.
2 - Eu não tive estes problemas… com um simples reRender e o código de como tem que ficar nesse caso você resolve isso (e não é nenhuma gambiarra).
3 - Você tem como chamar funções js suas no que você precisa na imensa maioria dos casos, normalmente em algum evento de algum componente, até hoje no que eu precisei (normalmente chamar em algum evento como onblur da vida) nunca tive problema. Quanto a css os componentes tem um styleClass, isso normalmente resolve meu problema (nem preciso tanto por que normalmente deixo o estilo pego do skin do rich faces…). Casos onde isso não atende são bem raros (normalmente é por que o programador “quer” fazer com js, não por que ele “precisa”).
4 - Pera ai, você tem como chamar componente do managed bean na view e da view no managed bean e não ha transparência? A unica coisa que vejo de ruim ai é um possível mau uso, um uso excessivo de binding. Tem casos onde considero uma boa por exemplo para preencher menus, mas acho que tem que ser o minimo usado possível por uma questão de camadas.
5 - Eu concordo quanto a lerdeza neste ponto, poucas versões novas saem… mas isso não muda o fato de que jsf 2 hoje é um framework recente e bem aceito pela comunidade, bastante produtivo.
6 - De uma forma geral ele é statefull, o comum com ele é que muitos managed beans fiquem com escopo de sessão e muitos dados dados fiquem carregados, mas não é dificil trabalhar com estes beans em escopo de requisição e passando parâmetros via get por exemplo. Para ser sincero eu acho que certas coisas vale bem mais a pena ser statefull mesmo por que não pesam na memória, podem ser aproveitadas por vários dos muitos usuários logados (configurações relacionadas a perfil de acesso por exemplo) e assim evitam novos acessos a base de dados, além de ser mais fácil programar assim, o problema é quando o individuo deixa tudo statefull, mas isso não é problema do framework, mas sim de quem o usa.
7 - Ele é mesmo um atrativo para novatos por que esse negocio de “só por a tag” faz parecer que é simples programar com jsf, e na verdade é simples mesmo, mas programar “bem” envolve conceitos que estes novatos normalmente não conhecem ou ao menos não na prática. Ai que entra o problema mas novatos vão fazer “novatisses” com qualquer framework…
8 - Cara isso de preencher um combobox depois que o usuário selecionar uma opção no outro usando jsf (com algum outro add como o rich ou o prime) é uma coisa simples, com o rich por exemplo é só colocar no primeiro um a4j:support no evento onblur chamando o método que preenche os itens do segundo combo e colocando no reRender um painel de onde esteja o segundo para atualizar. Se tem um monte de tópico perguntando sobre isso é por que tem um monte de gente que não conhece abrindo tópico perguntando, mas é simples sim.
9 - Qualquer framework é suscetível a pog. Nunca duvide da criatividade de certos individuos e como eu disse novatos vão fazer “novatisses” com qualquer framework…
10 - Integrar com outras tecnologias tipo o que por exemplo?
quanto ao ponto positivo que você deu, bom acho que não é novidade pra ninguém que você foi meio tendencioso quanto a isso.
hum…bom saber. Tira o primefaces, crie seus proprios componentes e taglibs que tenha boa performance e com suporte a arquitetura Restful e que seja stateless, vai querer continuar a usa-lo? Esse é um ponto que citei acima como uma das coisas que torna JSF um lixo.
Quanto ao VRaptor, acho que voce se equivocou. Nunca precisei configura-lo. As bibliotecas adicionais são as mesmas que voce colocaria em qualquer outro framework. No site do VRaptor voce pode baixar o blank-project que ja esta configurado e pronto para o uso.
Fala Lucas !! Preciso falar com vc mas perdi seu email…vc pode enviar um e-mail para mim? To aguardando…
Algumas coisas q vc falou no seu texto existe, outras podem ser contornados e outras eu acho que vc pode estar equivocado em algumas conclusões. Eu não vou entrar em “flames” contradizendo seu texto…prefiro ficar aparte disso. Por exemplo, a partir do momento que vc configura o estado da arvore do JSF para a “client”, o JSF se torna STATELESS. E por ai vai.
JSF é um framework objetivado para um fim. Usa-lo para um fim diferente, realmente terá que contornar situações. Tudo na vida é assim…Não existe um framework MVC lindo maravilhoso bala de prata…Existe? kkkkk Ja existe gente levantando issues destes frameworks que vc indicou ai…e avida é assim…a coisa gira.
Quando vc idealiza uma solução, vc precisa buscar no mercado ferramentas/frameworks para te ajudar…mas mesmo assim vc terá issues para resolver…
Eu na verdade fico feliz por ter toda essa gama de opções para minha escolha…
Resumindo bastante os dois lados:
BOM:
O JSF traz uma produtividade incrível na criação de UI, fazendo automaticamente coisas que dariam um trabalho imenso.
RUIM:
O principal problema do JSF é que ele gerencia a criação da HTML final e também o formato das URLs. Em aplicações RIA para web 2.0, aonde você tem que mexer diretamente na estrutura DOM da página gerada e se preocupar com o formato e estrutura das suas URLs, você acaba se ferrando por causa do JSF.Para demonstrar isso dê uma olhada na HTML gerada pelo JSF e você vai ver muita coisa gerada automaticamente. Então tente implementar no seu template JSF, sem usar nenhuma gambiarra escrota, algum efeito na página via javascript (com ou sem jQuery). Provavelmente você vai quebrar a cara. Se conseguir, tente então baixar algum conteúdo por ajax e alterar a estrutura da página dinamicamente com base na resposta do ajax. Vai quebrar a cara de novo. Tente personalizar algum detalhe do CSS, quebrou a cara de novo!
É aí que está o problema do JSF: Uma vez que ele toma para si a tarefa de gerenciar a criação da HTML, você acaba perdendo a liberdade de personalizá-la, sendo obrigado a seguir as regras impostas pelo JSF, e para alguns tipos de aplicações, estas regras impostas não são aceitáveis.
Uma possível saída para esse problema é você criar os seus componentes JSF personalizados para fazer isso, mas aí você acaba perdendo a produtividade prometida pelo JSF e tem ainda a tarefa extra de ajustar os seus componentes as necessidades do JSF, uma tarefa árdua. Assim acaba sendo mais simples, mais fácil e mais rápido fazer tudo com javascript e HTML você mesmo, pois o JSF vai acabar se tornando um elefante branco inútil no sistema.
Para sistemas que são compostos basicamente de telas de cadastro, consultas e relatórios CRUD, você pode usar o JSF e seja feliz. No entanto, você também pode usar uma grande gama de outras ferramentas (ex: REST + JSP + jQuery) e também ser do mesmo jeito.
No entanto se você quer fazer um site cheio de animações e efeitos, carregamento dinâmico de dados em tempo real, etc, o JSF não é uma boa ideia.
Talvez você decida que o que você precisa é simples o suficiente para que o JSF dê conta e você vai produzir muito bem e mais rápido do que se estivesse usando alguma outra coisa. Até que em uma bela sexta-feira 13 de lua cheia, o cliente chega com um requisito de fazer a sua tela de consulta de situação de venda de produtos que é completamente estática, ter que monitorar em tempo real a atividade do fluxo de provisionamento de venda de produtos, para que o operador não precise ficar dando F5 a toda hora e possa agir imediatamente sem estourar o prazo máximo de 30 minutos para a conclusão da venda. Isso daí você pode fazer com Ajax e jQuery, mas… OH NO!
Acho engraçado que vejo milhares de pessoas reclamando do Ciclo de Vida do JSF mas nunca pararam para aprender/estudar.
Para aprender OO o cara estuda, agora para aprender sobre JSF quer um texto de 3 linhas explicando tudo?
Se tudo em Java fosse simples e objetivo…
Quantas vezes já vi pessoas usando actionListener quando elas precisam de um action?
As vezes dá vontade de perguntar para as pessoas que abrem um post sofre JSF: “vc a diferença entre action e actionListener?”, “Vc sabe oq acontece se um método de uma action retornar um null?”
Serinho, não entendo esse povo que quer que a solução caia no colo deles. E ao ver que vai precisar estudar para entender alguma coisa começa a reclamar… pfff.
Queridos amigos, segue minha opinião como arquiteto…
Se vc concluiu que um framework não é adequado para seu cenário, não quer dizer que ele não presta, ou que é um lixo, ,flames ,flames… Não é positivo para nenhum profissional se posicionar dessa forma. Simplesmente não é o adequado para ser adotado na solução A. Mas num outro momento, pode ser perfeito para ao cenário da solução B. Não se torne um profissional fanático contra ou nem a favor. Entenda um framework, para que serve, como funciona, quem ta usando, resultados desse uso, pros e contras e use para seu próprio beneficio.
olha pessoal eu descordo um pouco se dizem que o JSF é ma droga
eu sou um cara bem doido e uso o minimo do JSF puro, mas sabe o que ele tem de melhor e muitos não observam
é que com ele você pode jogar qualquer ou pelo menos a maioria das tecnologias nele
eu consigo juntar tudo que é tranqueira no JSF seja javascript, CSS , prime, my, rich, flash, o que tiver de interessante eu coloco tudo e vira uma zona que só eu entendo mas é divertido além disso estou criando meu próprios componentes
sugiro a vocês que leiam
Pro JSF e Ajax
construindo componentes ricos para a Internet
uma coisa que eu percebo, não quero ofender ninguém, é que o pessoal está mal acostumado e que querem coisas rápidas
sei que o mercado exige, mas eu tomo muito cuidado quando são rápidas de mais já que pode vir problemas mais tarde que vai saber onde é o erro
a unica coisa que eu não gostei é que levei umas duas semanas para aprender usar o JSF
ou seja tem muito tempo para aprender a brincar com o JSF
Fernando,vc tocou num ponto importante.
Em que situação vc,que é um cara experiente com JSF em sistemas de grande porte,deixaria JSF de lado?
Se vc comparar JSF e Struts 1 por exemplo, tudo que vc faz em JSF vc pode fazer com Struts 1, mas o contrário não é verdade. O mesmo se aplica a Play, Rails, VRaptor e outros contra JSF.
Pra mim nao existe este papo de framework-web certo para cada tipo de problema. Framework web é gosto pessoal, ou tu sente prazer programando nele ou nao.
Desde que seu sistema seja um backend (apenas telas administrativas) ainda acho aceitavel alguem gostar e escolher JSF. Agora se vc chegar no nivel de escolher JSF para desenvolver front-ends, o JSF nao tem culpa, o problema é vc quem é muito ruim!
Simples assim!
Fala Lucas tudo bem?
Alguns pontos me chamaram atenção:
Pra que eu iria querer reiventar a roda criando meus próprios componentes se já tenho a disposição toda essa gama de bibliotecas que vc mesmo citou?A necessidade de criação de componentes me parece dispensável na maior parte dos casos.
Quanto ao ‘controle fino’ eu concordo com vc,a tonelada de javascript/css que é gerada por baixo dos panos torna praticamente inviável qualquer customização mais detalhada.
Como assim “para os que nao gostam de estudar”?Experimenta entrar num projeto sem conhecer pelo menos razoavelmente o funcionamento da tua biblioteca de componentes e vc vai ver a surra que vc leva 
Aqui me pareceu uma predisposição a falar mal.Meus projetos utilizam Spring,JPA+Hibernate,Webservices p/autenticação;Uma vez Rails,meu projeto não será sempre Rails?Ou então eu não entendi direito o que vc quis dizer com ‘outras tecnologias’
Um abraço.
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
Fernando,vc tocou num ponto importante.
Em que situação vc,que é um cara experiente com JSF em sistemas de grande porte, deixaria JSF de lado?
Eu não em acho muito experiente(mas um dia chego la kkkk) e tb acho até hoje nunca fiz nada de GRANDE PORTE (talvez tenhamos parâmetros diferentes de coisas de “grande porte”, mas ok…).
Muitas razões, por exemplo, se vc for desenvolver uma solução interna de uma corporação que vc tenha controle das workstations e navegadores que usaram o sistema. Vc pode optar por FLEX como camada de apresentação ou inves do JSF. Flex é realmente super lindo e vc consegue com menos tempo interfaces gráficas com gráficos maravilhosos conversando com seu back-end java. E por ai vai…
Como eu falei, tudo depende aonde vc quer chegar…ou seja requisitos.
Entretanto pode haver cenários no qual múltiplos frameworks concorrente podem ser usados intercambialmente. Ou seja, tanto A ou B ou C pode ser usado que tb chegara no mesmo resultado. Para esses casos vc pode optar pelo gosto pessoal, aquele que a equipe ja saiba ou aquele que a equipe deseja aprender a usar (sem alterar a data de entrega é claro kkkkk)
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
Fernando,vc tocou num ponto importante.
Em que situação vc,que é um cara experiente com JSF em sistemas de grande porte,deixaria JSF de lado?
Enquanto o JSF pode se sair muito bem em aplicações empresariais, não é uma boa idéia para Sites de internet por exemplo (redes sociais, loja virtual, etc) devido a duas características que já foram citadas aqui:
Falta de controle sobre o HTML gerado.
Para Internet, um design inovador e detalhes de usabilidade podem fazer toda a diferença. Usando JSF você tem certas limitações que não permitirão colocar em prática todas as suas idéias.
Número de usuários desconhecido.
Com JSF, o uso da sessão está fora de controle do desenvolvedor (seja por objetos do próprio framework, seja por managed beans que por motivos diversos só funcionam assim). Isso exige um cuidado todo especial com a infra-estrutura, instalando servidores que dêem conta do número de usuários planejado. Como na Internet o número de usuários não é previsível, existem boas chances de o servidor acabar não suportando.
Ola Rafael, como vai, tudo bem?
E se se tornar necessário? Ou será que desenvolvimento de software é tão previsível que posso apontar e falar: “Vou usar esses X componentes visuais dessa biblioteca e me basta”?. Se teus requisitos, em questão de front-end, se adequa aos N componentes de uma biblioteca, tudo bem. É só torcer pro cliente nao pedir alteração ou customização em algum componente.
Sim, é a mesma questao da situação acima. Mas isso não é pior parte do JSF. Isso é um probleminha a mais.
Sim, exatamente é o que quis dizer. Muitos novatos se encantam com “facilidade” de gerar o componente com as tags e levam uma surra posteriormente.
Hoje eu utilizo uma arquitetura que me permite ter várias tecnologias (web) por trás. A minha view é totalmente independente de Servidor. Ela nao é gerada no servidor como JSP, JSF ou PHP. Eu integro minha View de uma forma transparente, principalmente atraves de JSON. Hoje tenho aqui na mesma App módulos em VRaptor /Servlet e outros em Rails (e agora estamos pensando em usar JAX-RS em EJBs também para disponibilizar seviços para view), na mesma App.
Minha View nao conhece o server. Isso me permite ter uma arquitetura mais Restful possível, stateless, desacoplado e muito leve. Hoje o desenvolvimento web em geral estao caminhando para este lado.
Se voce usar JSF, sua View é praticamente 98% dependente de Server, depende dos Managed Beans. Há altíssimo acoplamento. Isso é um dos piores pontos do JSF.
Isso não é tão verdade assim,
Hoje eu utilizo uma arquitetura que me permite ter várias tecnologias (web) por trás. A minha view é totalmente independente de Servidor. Ela nao é gerada no servidor como JSP, JSF ou PHP. Eu integro minha View de uma forma transparente, principalmente atraves de JSON. Hoje tenho aqui na mesma App módulos em VRaptor /Servlet e outros em Rails (e agora estamos pensando em usar JAX-RS em EJBs também para disponibilizar seviços para view), na mesma App.
Minha View nao conhece o server. Isso me permite ter uma arquitetura mais Restful possível, stateless, desacoplado e muito leve. Hoje o desenvolvimento web em geral estao caminhando para este lado.
Se voce usar JSF, sua View é praticamente 98% dependente de Server, depende dos Managed Beans. Há altíssimo acoplamento. Isso é um dos piores pontos do JSF.
Oi Lucas, vc tem razão. Mas o JSF é server side…ou seja, JSF não para ser usado como estilo REST (digo a comunicação da VIEW para o CONTROLLER dentro do MVC). Mas vc tem razão, algumas aplicações hoje tendem a usar essa arquitetura sim.
Diante disso, vc ta usando o framework errado… oque vc esperava? Ligar as ações e os componentes visuais do JSF em um REST? quem sabe não acontece num futuro…mas atualmente JSF não foi estabelecido para essa filosofia.
Nesse ponto eu me baseei mais na minha experiência msm,nunca tive(e não conheço quem teve) necessidade de criação de algum widget que a biblioteca que eu uso (no caso o RichFaces) não forneça.
Quanto a estilizar componentes e mexer em CSS ,esse é o único tradeoff que me incomoda,vc fica refém demais do que a ferramenta gera pra vc.
Isso não é tão verdade assim,
Sim, você tem a possibilidade de realizar o setup mais adequado ao seu cliente (e por que não dizer, talvez tenha bastante sucesso nisso). Só que no fim das contas tudo se baseia em “trade-offs”, por exemplo, ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. Tudo isso requer um conhecimento do cenário de utilização, o que não acontece com sites de Internet…
FernandoFranzini interessante 1000 req por minuto.
Vc pode falar mais sobre essa solucao? Que outras praticas usou como cache, pool e etc?
abrassss
FernandoFranzini interessante 1000 req por minuto.Vc pode falar mais sobre essa solucao? Que outras praticas usou como cache, pool e etc?
abrassss
Eu disse 1 mil usuarios por minuto e não mil request. Bem diferente…
Detalhes arquiteturais vc pode falar comigo pelo meu email particular…
"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "
desculpa mas não entendi essa parte, vc poderia explicar melhor?
"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "desculpa mas não entendi essa parte, vc poderia explicar melhor?
"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "desculpa mas não entendi essa parte, vc poderia explicar melhor?
Leia - http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/
Você sabe se existe na web algum comparativo mais detalhado ao respeito, tipo:
consumo de banda da rede / cliente(dados) x servidor(dados), e por ae vai…
"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "desculpa mas não entendi essa parte, vc poderia explicar melhor?
Leia - http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/Você sabe se existe na web algum comparativo mais detalhado ao respeito, tipo:
consumo de banda da rede / cliente(dados) x servidor(dados), e por ae vai…
citei errado desculpem…
E se se tornar necessário? Ou será que desenvolvimento de software é tão previsível que posso apontar e falar: “Vou usar esses X componentes visuais dessa biblioteca e me basta”?. Se teus requisitos, em questão de front-end, se adequa aos N componentes de uma biblioteca, tudo bem. É só torcer pro cliente nao pedir alteração ou customização em algum componente.
Nesse ponto eu me baseei mais na minha experiência msm,nunca tive(e não conheço quem teve) necessidade de criação de algum widget que a biblioteca que eu uso (no caso o RichFaces) não forneça.
Quanto a estilizar componentes e mexer em CSS ,esse é o único tradeoff que me incomoda,vc fica refém demais do que a ferramenta gera pra vc.
bom vc acaba de conhecer um, trabalho numa empresa que usa zkoss, agora estão querendo um supervisório que tenha gráficos, áreas de texto e tals dentro do mapa do gmaps. o componente do zkoss para gmaps só atende até para desenhar poligonos e parou por ae. Agora tenho que achar um jeito de correr atrás do prejuizo…
Que ninguém se engane: só se consegue a simplicidade através de muito trabalho.Valeu JSF…
Eu não gosto do JSF porque ele é muito amarrado. Cara, uma das coisas mais básicas no desenvolvimento de software é a questão do ACOPLAMENTO. A visão é totalmente acoplada com o controlador. Cara, se você desenvolve um sistema utilizando VRaptor para implementar a camada de controle e jQuery na visão, e depois você se depara com um ExtJS e fica maravilhado com seus componentes (coisa que aconteceu comigo recentemente), você tem TODO O CONTROLE para substituir sua visão. Agora tenta fazer isso com JSF!!!
O principal motivo de não gostar do JSF é esse simples princípio de desenvolvimento (acoplamento), mas também porque ele deixa vazar muito da abstração que ele se propõe a fazer. Ter que escrever a navegação entre beans e visão no faces-config.xml (vi que foi corrigido na versão 2, mas era tão ruim na versão 1.2 que não tive saco pra conhecer a 2). Não gosto de frames component-based porque a WEB NÃO É DESKTOP. HTTP é requisição-resposta e, acima de tudo, STATELESS, uma de suas grandes vantagens.
Portanto, vale a pena você conhecer pra tirar suas prórpias conclusões, mas sugiro estudar melhor as tecnologias envolvidas numa aplicação web (http - tem gente que não sabe a diferença entre um forward e um redirect-, css, html, javascript, jsp, servlets) e aconselho fortemente a preferir frames action-based. Um que gosto muito é o VRaptor, não precisa configurar nada e é fácil integrar com qualquer outro framework…
eh por ae mesmo bob_sponja, eu trabalhei numa empresa que usava flex no front-end e web services no back-end, agora que o flex ta meio que indo pra ponte que caiu o pessoal lá está procurando uma alternativa no cliente, vc sabe quantas linhas de código vão precisar mexer no back-end? nem uma vírgula!
Pois é, o pessoal fica discutindo as funcionalidades, os componentes, o fato de ser uma especificação, mas se esquece dos princípios básicos de desenvolvimento. Como um frame tão acoplado pode ser bom?! E o engraçado é que esses que defendem falam que nós que criticamos somos os fanáticos!!! Será mesmo?! =)
mhjmhj2002, é bom ver histórias de quem se safou do uso do JSF pra mostrar pra esses “standard defenders” que nem sempre o fato de ser uma especificação é sinônimo de qualidade…
Não gosto de usar JSF (não estou dizendo que é lixo, ok?) pois prefiro algo “action-based” ao invés de “component-based”.
To programando web, sistemas complexos, requisitos que mudam, preciso sempre alterar regras no client, regras de SEO, flexibilidade para estilo da aplicação, comunicação assíncrona com o server, adaptações, mudar menus…na boa, já tentei solucionar uma pêra dessas com JSF e não vi vantagem alguma. Aí veio alguém e disse: mas você pode desligar isso, desligar aquilo, deixar pro container, e tudo mais. No final me vi programando desktop, com todo controle tirado do jsf, e pensei: WTH então estou usando JSF?
Crud pro mercado do Zé? “rails new mercadinho_do_ze”, obrigado.
Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
Com todo o respeito, eu discordo. Não vejo nenhum problema em utilizar JSF para fazer uma aplicação web, como você citou, sejam com muitos ou poucos formulários, ou seja lá o que for.
O mais engraçado é ver pessoas falando mau do JSF se baseando apenas no JSF 1.2.
Enquanto nem para para ver como funcionam o 2.0.
Triste isso viu. =/
Todo mundo vê apenas os defeitos do JSF e colocam VRAPTOR como a bala de prata, a salvação, mas ninguém para para pensar que o próprio VRAPTOR tem seus defeitos e suas limitações. As vezes as pessoas vêem apenas aqui que elas querem ver.
Visão seletiva.
Não acho o JSF 2.0 a salvação do mundo, mas nunca seria louco de afirmar que é lixo. As pessoas devem perceber que para cada situação, existe uma ferramenta que é melhor aplicada.
Fala quem JSF é lento? o xhtml chega a ser 60% melhor em performance que o JSP. Mas para utilizar o xhtml as pessoas precisariam entender como funciona o JSF 2.0 e para isso, ninguém está disposto… Triste isso! =/
Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
Bom,essa eu queria entender,pois uso o JSF no caso ‘1’ e sempre rolou muito bem,obrigado.
O mais engraçado é ver pessoas falando mau do JSF se baseando apenas no JSF 1.2.Enquanto nem para para ver como funcionam o 2.0.
Triste isso viu. =/
Todo mundo vê apenas os defeitos do JSF e colocam VRAPTOR como a bala de prata, a salvação, mas ninguém para para pensar que o próprio VRAPTOR tem seus defeitos e suas limitações. As vezes as pessoas vêem apenas aqui que elas querem ver.
Visão seletiva.
Não acho o JSF 2.0 a salvação do mundo, mas nunca seria louco de afirmar que é lixo. As pessoas devem perceber que para cada situação, existe uma ferramenta que é melhor aplicada.
Fala quem JSF é lento? o xhtml chega a ser 60% melhor em performance que o JSP. Mas para utilizar o xhtml as pessoas precisariam entender como funciona o JSF 2.0 e para isso, ninguém está disposto… Triste isso! =/
Velho, se vc quiser se referir a mim, por favor me cite ao invés de jogar ao vento que ALGUMAS PESSOA falam isso ou aquilo…
Em nenhum momento falei que o VRaptor é bala de prata, só frisei o quanto ele te proporciona de controle sobre seu projeto, coisa que o JSF não faz. Então não coloque palavras na minha boca… Outra coisa, o VRaptor têm suas limitações, claro, mas ele é BEM MAIS FÁCIL de ser estendido que o JSF, fora que já vem com um mecanismo nativo com suporte a injeção de dependência, e é MUITO, mas MUITO MESMO, fácil de se integrar com qualquer outra biblioteca ou framework… Além disso ele não exige que você tenha que aprender nova tags, compreender um ciclo de vida nada intuitivo para uma simples requisição e não incha o seu controlador com gets e sets (para pegar as propriedades dos ManagedBeans)… Ou seja, ele é muito mais simples de se usar e muito menos intrusivo do que o JSF.
Outra coisa, não tive saco pra conhecer a versão 2.0 pelo simples fato das coisas acontecerem muito devagar quando se trata do JSF… Quanto tempo eles demoraram pra sair da 1.2 pra 2.0?! Mesmo sabendo das inúmeros pontos negativos e das reclamações que existiam por parte da versão 1.2 demoraram uma eternidade… Então eu simplesmente não cultivo o pensamento “na próxima especificação eles vão corrigir isso”…
Já que você tá falando aí, me mostra como vc usa ExtJS com o JSF? Ou qualquer outra biblioteca javascript sem ter que contornar o JSF a todo tempo?! JSF surgiu quando essas tecnologias WEB (que fizeram surgir o termo WEB 2.0) não estavam tão desenvolvidas, maduras e possibilitando tanta interatividade na parte cliente… Hoje em dia não é necessário que a parte do servidor se ocupe em como renderizar as coisas no cliente, você tem trocentas opções para isso… Por isso não gosto do JSF, mas se você gosta, blza é opinião sua… Mas vc pelo menos se questionou o quanto de acoplamento ele te impõe? E vc acha isso bom? Como afirmei antes, depois nós que criticamos que somos os fanáticos e temos visão seletiva…
Velho, se vc quiser se referir a mim, por favor me cite ao invés de jogar ao vento que ALGUMAS PESSOA falam isso ou aquilo…
Em nenhum momento falei que o VRaptor é bala de prata, só frisei o quanto ele te proporciona de controle sobre seu projeto, coisa que o JSF não faz. Então não coloque palavras na minha boca… Outra coisa, o VRaptor têm suas limitações, claro, mas ele é BEM MAIS FÁCIL de ser estendido que o JSF, fora que já vem com um mecanismo nativo com suporte a injeção de dependência, e é MUITO, mas MUITO MESMO, fácil de se integrar com qualquer outra biblioteca ou framework…Outra coisa, não tive saco pra conhecer a versão 2.0 pelo simples fato das coisas acontecerem muito devagar quando se trata do JSF… Quanto tempo eles demoraram pra sair da 1.2 pra 2.0?! Mesmo sabendo das inúmeros pontos negativos e das reclamações que existiam por parte da versão 1.2 demoraram uma eternidade… Então eu simplesmente não cultivo o pensamento “na próxima especificação eles vão corrigir isso”…
Já que você tá falando aí, me mostra como vc usa ExtJS com o JSF? Ou qualquer outra biblioteca javascript sem ter que contornar o JSF a todo tempo?! JSF surgiu quando essas tecnologias WEB (que fizeram surgir o termo WEB 2.0) não estavam tão desenvolvidas, maduras e possibilitando tanta interatividade na parte cliente… Hoje em dia não é necessário que a parte do servidor se ocupe em como renderizar as coisas no cliente, você tem trocentas opções para isso… Por isso não gosto do JSF, mas se você gosta, blza é opinião sua… Mas vc pelo menos se questionou o quanto de acoplamento ele te impõe? E vc acha isso bom? Como afirmei antes, depois nós que criticamos que somos os fanáticos e temos visão seletiva…
Desculpe se te ofendi.
Não sei pq eu ainda abro a boca pra falar nesse tipo de tópico… É a mesma coisa que falar pra um religioso fanático que ele tem que abrir a cabeça…
Prezado bob_sponja, com todo o respeito à sua opinião, eu tambem discordo de alguns pontos que voce colocou. Embora concorde com outras, hehe. Tenho mais experiência com a versão 1.2 do JSF, e muitas vezes também me frustei. No entanto acho o JSF uma excelente opção para desenvolvimento web com Java, e na minha opinião, JSF+SEAM é a melhor conjunto para trabalhar com web Java hoje. Mesmo na versão 1.2 do JSF o Seam já fazia maravilhas. Enfim, falemos do JSF.
Sobre os pontos que colocou achei interessante o que colocou sobre o acoplamento da view->controller que existe no JSF, concordo com o que disse. Não obstante, se você usar o VRaptor, ou o SpringMVC, por exemplo, você não fará o controller pensando especificamente em uma página? Os seus métodos não serão feitos pensando na funcionalidade da view? Imagino que sim. Esse acoplamento página->classe quase sempre existirá. Não vejo isso como um problema, com todo o respeito à sua opinião.
A proposito, o JSF também tem “suporte nativo” à injeção de dependência, via managed-properties. E não vejo dificuldade alguma em integrar um managed-bean
com qualquer outro framework que seja usado na aplicação. E se puder, sugiro o estudo da versão 2 do JSF que está excelente.
Um outro ponto que voce levantou que outros colegas do fórum tambem questionaram aqui, sobre integrar o JSF com frameworks Javascript. Nesse tópico há muitas críticas nesse sentido. Particularmente não vejo problema algum em fazer isso. Com o Facelets (view-handler padrão do JSF), é possível criar uma pagina HTML comum, com seu framework Javascript preferido e com o CSS que quiser. Não entendo a dificuldade nesse sentido, é perfeitamente viável e tão factível quanto seria criar uma página com qualquer outro framework. O PrimeFaces e o RichFaces tem componentes que usam o JQuery e Prototype (como exemplo), e são feitos para aplicações JSF…não é “impossível” como colocaram aqui. Mas ainda no ponto “componentes”, o EXT JS tem componentes visuais muito bonitos, fato. Mas duvido que utilizá-los seja mais fácil do que usar o PrimeFaces ou o RichFaces, como exemplo. Acho esse detalhe importante no JSF, pois a especificação permitiu que fossem criados uma gama de frameworks de componentes que encapsulam muito do trabalho que seria feito na view (Javascript, manipulação do DOM, Ajax, etc). E olha que até que não sou ruim no Javascript, hehe, mas se eu posso jogar uma taglib que já faz o trabalho, por que não?
Obrigado.
Só esclarecendo a questão que citei do acoplamento, o que quis dizer é que você muitas vezes não tem liberdade em fazer o que quiser na visão com JSF, sendo que com outras tecnologias é possível. A questão do acoplamento em nomes de parâmetros, atributos de EL, isso é inevitável…
As pessoas lancam um framework.
Versão 1.0 => LIXO TOTAL
Aí jogam fora e fazem outro:
Versão 2.0 => Apenas lixo
Aí jogam foram e fazem outro:
Versão 3.0 => Ok
Se vc trabalha em cima de um lixo durante muito tempo, ele fica aceitável. Isso é fato. EJB3 está aí para provar isso.
O problema é a filosofia de trabalho que assassina o KISS (Keep It Simple Stupid).
JSF é muito amarrado e burocrático. Usá-lo para um sistema web cheio de formulários e cheio de Ajax até pode se justificar.
EDIT: O Robert da equipe do Mentawai fez um sistema sinistro de reserva de passagens online com Mentawai e depois migrou para JSF. O que ele fala é muito interessante… Lembre-se que um sistema de reserva de passagens tem formulários pra caramba e vc pode se dar bem usando um component-based approach.
Agora é claro que para o cara que só trabalhou com JSF e já se acostumou com aquela bagunca isso não faz o menor sentido. Ele vai achar o JSF ótimo.
De novo: só há como comparar dois frameworks pegando um cara que NUNCA programou em nenhum dos dois e falar para ele gastar uma semana brincando com um e uma semana brincando com outro. APENAS ASSIM.
"Qualquer um pode escrever código complexo que funciona… Poucos vão conseguir escrever código simples que funciona, é fácil de entender, usar e manter."
Agora é claro que para o cara que só trabalhou com JSF e já se acostumou com aquela bagunca isso não faz o menor sentido. Ele vai achar o JSF ótimo.Já trabalhei com Struts 1.x. Eu não gostava dos formulários e do monte de xml. Não sei como está a versão 2, mas não vejo ela sendo muito solicitada no mercado.
Já trabalhei Servlet/JSP/Javascript. Era bom pacas pois você tem o comando todo na mão. O chato é ter que fazer get/set para tudo na unha.
Trabalhei e trabalho com JSF. Infelizmente no meu trabalho utiliza o 1.2. Não gosto mesmo. Tenho um sistema por fora em que uso o JSF 2.0. Muito bom, fácil e prático. E ainda espero o 2.2 que tem muita coisa boa. Uma delas é Converters, Validators, etcs aceitar injeção tipo @EJB.
Já li sobre VRaptor e sempre pergunto sobre ele a um amigo que gosta desse framework. Até então, gostei do que vi. O que eu não gostei muito é da parte de que não tem injeção e você tem que controlar o javascript por fora (isso pode ser vantagem ou desvantagem).
Se aparecer algo melhor no mercado, eu caio dentro sem pensar duas vezes. Mas eu não vejo por que não indicar JSF ou achar que é lixo.
Mas é como dizem… Opinião é igual orelha, cada um tem a sua. E alguns tem mais de uma! [=
O projeto de migração foi abortado depois de 5 meses com 3 programadores.
Precisavamos muita interação ajax, e com o JSF o sistema começou a ficar muito lento nas principais telas, e nada podíamos fazer para os responses fossem mais leves ou algo assim.
O sistema é este: http://www.lemontech.com.br/index.php?pg=interno&id=selfbooking
Resumindo, não deu certo.
Com o Menta, customizamos os responses com JSON, colocamos nas chaves apenas uma letras etc, para diminuir o overhead das informações, e depois disso compactamos as respostas.
ao meu ver o jsf melhorou bastante a partir da versao 2…
Mas as vezes acho que o jsf é uma tecnologia meio que forçada pra java web.
acho mto dificil alguem q desenvolva com jsf nunca ter ficado dias tentando resolver algum problema, que em outras tecnologias e linguagens seria super fácil de se resolver.
Enfim, é muito burocrático!
Mas apesar de tudo, ele tem qualidade. Com MUITA força de vontade e reza brava vc consegue se virar…
EDIT: O Robert da equipe do Mentawai fez um sistema sinistro de reserva de passagens online com Mentawai e depois migrou para JSF. O que ele fala é muito interessante… Lembre-se que um sistema de reserva de passagens tem formulários pra caramba e vc pode se dar bem usando um component-based approach.
O projeto de migração foi abortado depois de 5 meses com 3 programadores.
Precisavamos muita interação ajax, e com o JSF o sistema começou a ficar muito lento nas principais telas, e nada podíamos fazer para os responses fossem mais leves ou algo assim.
O sistema é este: http://www.lemontech.com.br/index.php?pg=interno&id=selfbooking
Resumindo, não deu certo.Com o Menta, customizamos os responses com JSON, colocamos nas chaves apenas uma letras etc, para diminuir o overhead das informações, e depois disso compactamos as respostas.
Eu trabalhei com o Robert nesse projeto de migração e também vou dar minha opinião.
Não existe o bom e o ruim, existe o melhor para cada situação.
Tínhamos um problema pontual na tela de consulta de voos. Essa tela precisava trabalhar com um grande volume de dados, nesse caso tínhamos que ter controle do html gerado e ai esta o X da questão.
Seu sistema precisa manipular o HTML, CSS e etc que é gerado pelo JSF? Então não use JSF.
No sistema em que eu e o Robert trabalhamos poderíamos ter feito a parte consulta de voos com RestFul passando por fora de todo o ciclo de vida do JSF, assim eliminaríamos o problema citado. O resto do sistema era todo CRUD e para isso o JSF é muito bom.
Infelizmente por uma decisão de empresa o projeto foi abandonado, e isso não tem haver com a tecnologia que foi utilizada mais sim com uma ?estratégia de empresa?.
Um ponto interessante é:
O melhor na grande maioria das vezes é o que você conhece bem.
…
JSF é muito amarrado e burocrático. Usá-lo para um sistema web cheio de formulários e cheio de Ajax até pode se justificar.
…
Lembre-se que um sistema de reserva de passagens tem formulários pra caramba e vc pode se dar bem usando um component-based approach.
…
Prezado saoj, se me permite citar esses dois trechos pontuais do seu post, com todo o respeito, não concordo muito com essa visão. Você parece concordar com outros colegas do fórum que o JSF presta “apenas” para formularios, CRUDS, etc. Sinceramente, para qualquer tipo de funcionalidade que se queira na aplicação, não vejo nenhum impeditivo em usar JSF. Afinal, existem bibliotecas de componentes para trocentas funcionalidades diferentes, e sempre se pode utilizar unicamente HTML e CSS, assim como com o JSP. Com o perdão da ignorância, não compreendo direito essa crítica da comunidade, de que o JSF só presta pra formularios basicos, o resto “não dá pra fazer”. Com todo o respeito à sua opinião.
O que me leva ao ponto que o colega oliveira.caio comentou:
Prezado oliveira.caio, por gentileza, se puder pode detalhar melhor a dificuldade nesse detalhe? Trabalho com o JSF fazendo o HTML manualmente, manipulando o DOM, construindo o CSS, como eu faria uma página com qualquer outro framework, e não enxergo essa dificuldade. Ademais, as tags previstas na especificação renderizam tags basicas do HTML (input, button, a, select, e outras) e não geram nenhum CSS nem Javascript.
Concordo em absoluto. 
Obrigado.
Caro Alias. Vc pode discordar de tudo que eu falei. Sem problemas. Principalmente porque em matéria de JSF entendo pouco e estou baseando minha opinião no que escuto por aí e nos diversos exemplos que já vi. Claro que JSF3 vai ser melhor que JSF2 que vai ser melhor que JSF1. Muitas vezes jogam a coisa inteira fora e recomecam do zero. Struts1 não existe mais, foi descontinuado e abandonado para usarem o Struts2 (WebWork). EJB1 foi para o museu como um caso magnifiíco de uma expecificacao das melhores cabecas da industria que simplesmente fracassou com todas as forcas. Quando muita gente se junta para dar pitaco, geralmente sai caca, mas essa é a minha opinião pessoal. As melhores coisas são geralmente feitas por UMA cabeca seguindo UM principio correspondente a SUA conviccao, que obviamente não pode ser a de todos. Olhando a história parece que isso acontece mais vezes que o oposto.
Quando eu falo que meu carro é rápido, essa afirmacao é totalmente vazia. Como sabemos, tudo depende de um referencial.
Então vc pode achar JSF maravilhoso assim como eu posso achar o meu carro super rápido, cometendo o erro de ignorar o referencial.
Dizer que JSF é menos burocrático e enrolado do que Mentawai, Play, Ruby on Rails, Stripes, etc. me parece loucura porque esses frameworks abracaram desde o início (DESDE DA versão 0.1.1) o conceito KISS.
Posso estar errado e se for esse o caso por favor clareia minhas idéias para que eu possa aprender mais.
component-based é mais indicado quando vc tem vários formulários e muito AJAX/JavaScript no client side para ligar e reaproveitar tudo. Ao invés de codificar um caminhão de JavaScript no client-side (penoso) faća a coisa no server-side usando componentes.
action-based é mais próximo do mundo web / HTTP. Do MVC clássico. Do request-response paradigm, etc.
Um site de reservas online é um SISTEMA complexo. Ele é muito diferente por exemplo do que um site de relacionamentos, um JForum, etc. Quantos CRUDS vc tem no JForum? E num site de reservas? Já pensou na administracao disso? Na quantidade de telas e formulários? Por que o Robert que é um baita desenvolvedor (um dos mais pragmáticos que já vi) decidiu se aventurar migrando tudo para JSF?
Eu realmente sou suspeito para falar, pois tenho bastante experiencia com action-based e muito pouca com component-based.
Alguém que trabalhou nos dois mundos poderia opiniar. O Robert é um deles. O que eu posso falar é que fazer o simples com JSF é tortura. E isso filosoficamente é algo que não tolero. Outros toleram e até gostam. E viva a diversidade. Eu sou burro e preguicoso para complexidade por isso gosto das coisas simples. Em algo que suporta abstracao (OOP) complexidade é quase sempre um ERRO. Já conheci os dois mundos: sistemas super complexos feitos de forma simples e sistemas muito complexos feitos de forma complexa. Para o cara que nunca viu o simples, o complexo é simples, esse é o problema. 
Struts 2? Spring? VRaptor? Xml (a lot) acabou há tempos…
Nunca se aventurou a nenhunzinho “Hello World”? Não tem injeção? (aqui não entendi muito o que quis dizer)
Sobre o javascript, qual seria a desvantagem em usá-lo para controlar as coisas no client?
Não trabalho full-time com JSF, mas já utilizei em algumas aplicações, já li bastante sobre e procurei entender o mecanismo e as ideias para poder tirar conclusões, enfim. Cheguei a conclusão (não só eu mas uma gama de comunidade) que ele foi concebido numa época em que recursos http eram escassos e imaturos. Vai ver por isso que a galera demora tanto pra soltar release de JSF…
Sério, não gosto de criticar algo sem conhecer nem testar. Mas já tentei colocar JSF em diversas soluções e nunca consegui ver vantagem, nem em app com uma penca de forms como o saoj comentou…por outro lado, talvez nunca tive capacidade de enxergar tais vantagens
Prezado saoj, novamente respeitando muito sua opinião, interessante o que comentou sobre os paradigmas component/action base. O meu pensamento segue a linha que você citou. Apenas para constar, não pretendo defender apaixonadamente o JSF (minha experiencia maior é com a versão 1.2 com a qual já arranquei alguns cabelos), porém eu o vejo como uma excelente alternativa, embora respeite quem não goste.
Sobre o que disse, acrescento um raciocinio que pode soar absurdo mas ao menos é o que penso hoje com meu parco conhecimento. Tenho a opinião de que pode-se dizer que boa parte das interfaces web hoje “são” component-based, dado o seu nível de complexidade. Explicando: em uma página “rica”, usando livremente o termo, elementos específicos dessa página serão manipulados, carregados, descarregados, vão sumir, reaparecer com outra cor, etc. Vejo os elementos como componentes. A partir daí vem o meu pensamento que não há nada que não se faça no Mentawai ( ), no VRaptor, no SpringMVC, no Grails, que não se possa fazer com o JSF. Verdade, no JSF os elementos serão componentes também no lado do servidor, criando uma “web STATEFULL”, que foge do funcionamento do HTTP como você mencionou. Isso não me agrada no JSF. Mas gosto da abstração que isso proporciona, de enxergar os componentes do HTML como componentes de fato da aplicação. Como disse, dado o nível de complexidade das interfaces web existentes hoje, eu creio que essa abordagem se justifica. Suponho que isso foi mais ou menos o que voce disse, ao dizer que o JSF se justifica quando usado em interfaces muito complexas, estou correto?
Mas nem sempre (ou nunca?) isso é o que se quer. Daí vem os action-based, com uma abordagem diferente do JSF, e talvez mais adequada para outros cenários. Mas voltando ao meu pensamento, do qual se a aplicação/site for voltado para os “componentes” e sua interação, eu continuo achando o JSF uma excelente opção.
Obrigado.
Prezado saoj, novamente respeitando muito sua opinião, interessante o que comentou sobre os paradigmas component/action base. O meu pensamento segue a linha que você citou. Apenas para constar, não pretendo defender apaixonadamente o JSF (minha experiencia maior é com a versão 1.2 com a qual já arranquei alguns cabelos), porém eu o vejo como uma excelente alternativa, embora respeite quem não goste.Sobre o que disse, acrescento um raciocinio que pode soar absurdo mas ao menos é o que penso hoje com meu parco conhecimento. Tenho a opinião de que pode-se dizer que boa parte das interfaces web hoje “são” component-based, dado o seu nível de complexidade. Explicando: em uma página “rica”, usando livremente o termo, elementos específicos dessa página serão manipulados, carregados, descarregados, vão sumir, reaparecer com outra cor, etc. Vejo os elementos como componentes. A partir daí vem o meu pensamento que não há nada que não se faça no Mentawai (
), no VRaptor, no SpringMVC, no Grails, que não se possa fazer com o JSF. Verdade, no JSF os elementos serão componentes também no lado do servidor, criando uma “web STATEFULL”, que foge do funcionamento do HTTP como você mencionou. Isso não me agrada no JSF. Mas gosto da abstração que isso proporciona, de enxergar os componentes do HTML como componentes de fato da aplicação. Como disse, dado o nível de complexidade das interfaces web existentes hoje, eu creio que essa abordagem se justifica. Suponho que isso foi mais ou menos o que voce disse, ao dizer que o JSF se justifica quando usado em interfaces muito complexas, estou correto?
Mas nem sempre (ou nunca?) isso é o que se quer. Daí vem os action-based, com uma abordagem diferente do JSF, e talvez mais adequada para outros cenários. Mas voltando ao meu pensamento, do qual se a aplicação/site for voltado para os “componentes” e sua interação, eu continuo achando o JSF uma excelente opção.
Obrigado.
não to querendo fazer você pensar como eu, apenas pretendo discutir alguns impedimentos/beneficios de uma ferramenta ou outra.
Um coisa que percebi na prática é o seguinte: Hoje um site descente sem Ajax e sem uma interface minimamente rica fica complicado. Então vc sempre vai ter um quantidade excessiva e desorganizada de JQuery / JS / JQueryUI no client-side. JQuery é muito bom mas dá para comparar a organização de um código OO com a bagunca do JS no client-side? É mais ou menos comparar quando as pessoas programavam CGI com PERL estrutural no server-side. Então fica a minha dúvida: Como organizar a bagunca do JS no client-side sem abandonar o action-based em prol do component-based? Há soluções no meio do caminho para isso?
EDIT: Um exemplo prático: Olhem a quantidade de JS/JQuery/JQueryUI nessa página do Kawai Wiki: http://websvn.mentaframework.org/filedetails.php?repname=Kawai+Wiki&path=%2Ftrunk%2Fsrc%2Fmain%2Fwebapp%2Fshow_page.jsp
Como eu poderia ter organizado essa zona sem partir para o component-based?
muito interessante sua colocação!
percebi que você pesa mais o fato da orientação a componente.
mas por outro lado, não seria menos trabalhoso usar javascript/jquery/ajax de forma decente e correta, podendo ser beneficiado por tais manipulações dos elementos? (eu disse elemento, pois vejo elemento como elemento). É ruim usar JQuery?não to querendo fazer você pensar como eu, apenas pretendo discutir alguns impedimentos/beneficios de uma ferramenta ou outra.
Você tem razão, acho que eu tendo a por em alta conta a orientação a componente (embora muito me agrade a natureza stateless do HTTP). Mas como expliquei, da maneira como vejo os sites e apps web hoje, as páginas ricas são orientadas a componente, pois os elementos são tratados dessa forma. Na minha opinião, é claro :lol:
Interessante o ponto que voce levantou, e não vou discordar. Os próprios componentes que fazem a fama do JSF (PrimeFaces, RichFaces, SeiLáOQueFaces, etc), fazem uso pesado de MUITO Javascript. Portanto os componentes bonitos do Prime poderiam ter sido feitos (e o são por aí com certeza) em um cenario “não-JSF”, como você disse, apenas usando Javascript da maneira correta e adequada. Mas aí volto ao que disse, que a “componentização” da coisa traz uma abstração que eu acho interessante, no sentido de tratar aquele elemento como algo unico e especial na página, e que receberá um tratamento e um comportamento específico. Eu vejo que tratando os elementos dessa forma cada um deles ganha um significado no sentido de agregar alguma funcionalidade ou participar da interação na página. Eu penso que tratar um elemento da página com essa perspectiva é benéfico.
E eu tambem muito gosto do JQuery, hehe. Não aprecio muito trabalhar diretamente no Javascript, mas mesmo que nem fosse o caso, meu pensamento pende mais para o que escrevi acima, embora eu NÃO discorde do que escreveu. Nem eu tenho a esperança de convencer alguem que o que estou dizendo é o correto (se nem eu estou convencido que dirá convence-los :lol: ), eventualmente estarei completamente equivocado e certamente terei aprendido mais com os colegas do fórum.
Obrigado.
EDIT: Um exemplo prático: Olhem a quantidade de JS/JQuery/JQueryUI nessa página do Kawai Wiki: http://websvn.mentaframework.org/filedetails.php?repname=Kawai+Wiki&path=%2Ftrunk%2Fsrc%2Fmain%2Fwebapp%2Fshow_page.jspComo eu poderia ter organizado essa zona sem partir para o component-based?
Enfim, claro que não tem comparação OO com script. Mas utilizando bem os recursos que o jquery oferece, dá sim pra montar uma galeria de scripts bem modularizada e reusável.
Pra 99% dos problemas que relatam do JSF, o que acontece é pura falta de informação. Todos os desenvolvedores de componente indicam nos manuais como modificar o css, layout, embutir javascript e etc. JSF 1 realmente era horrível porque era imaturo e não tinha passado pelo crivo dos usuários, mas hoje em dia o cenário é diferente.
Muito curioso essas discussões na comunidade Java, como ontem postei aqui http://www.guj.com.br/java/222158-jsf-struts-2-ou-vraptor-3/2 não entendo pq no caso de vocês do Java existe essa valorização tão grande por framework baseado em componentes, onde no caso da comunidade .NET ocorre o inverso. Como o ASP.NET nasceu baseado em componentes, passei boa parte da vida fechado a esse mundo, depois que finalmente a Microsoft copiou o Struts 2 não voltei mais ao mundo dos componentes, onde deixo de ser refém de controles pro framework do lado servidor e tenho toda liberdade de usar de forma limpa um jquery ui, css, frameworks visuais de diagramação de formularios como o formee, e diversos plugins jquery, e meus jquerys controlando o que quiser, tudo de forma mais natural, sem precisar ficar se preocupando com muitos “segredos” ou intervenções do framework server ou componente pra fazer algo diferenciado no resultado pro lado client, além de termos melhor colaboração do designer. Como muitos falam “web não é desktop”, isso é verdade.
Com todo o respeito, apesar de ambos serem component-based, não vejo mais nenhuma semelhança entre ASP.NET e o JSF. Ao que me lembro, o modelo do ASP.NET é de fato transformar a página em um “win-form”, onde os componentes são diretamente manipulados na classe que fica atras da pagina. Apesar de também ser possível, ninguém faz isso no JSF (não é nada legal e nunca vi uma dúvida aqui no fórum sobre como utilizar uma instancia de HtmlInputText ou coisas do genêro. Já no ASP.NET, bom, é só isso que você tem). E TUDO isso ai que voce comentou (jquery, css, e tal) podem perfeitamente ser utilizados com JSF.
As palavras acima dizem muita coisa. Nessa thread que o colega javaflex citou, há diversos outros colegas do fórum dizendo ser “impossível” usar javascript e css no JSF, e, com todo o respeito, creio ser pura falta de conhecimento. Uma coisa é não gostar, outra coisa é não conhecer.
Com todo o respeito, apesar de ambos serem component-based, não vejo mais nenhuma semelhança entre ASP.NET e o JSF. Ao que me lembro, o modelo do ASP.NET é de fato transformar a página em um “win-form”, onde os componentes são diretamente manipulados na classe que fica atras da pagina. Apesar de também ser possível, ninguém faz isso no JSF (não é nada legal e nunca vi uma dúvida aqui no fórum sobre como utilizar uma instancia de HtmlInputText ou coisas do genêro. Já no ASP.NET, bom, é só isso que você tem). E TUDO isso ai que voce comentou (jquery, css, e tal) podem perfeitamente ser utilizados com JSF.
As palavras acima dizem muita coisa. Nessa thread que o colega javaflex citou, há diversos outros colegas do fórum dizendo ser “impossível” usar javascript e css no JSF, e, com todo o respeito, creio ser pura falta de conhecimento. Uma coisa é não gostar, outra coisa é não conhecer.
Sim ele deixa fazer isso, mas dependendo do padrão de arquitetura utilizado isso não rola, MVP por exemplo. Não sou defensor de ASP.NET WebForm, sei que JSF é muito melhor, só foquei na questão component-based.
Não disse ser impossível, disse não ser natural. Sim, gosto conta muito também, era um saco ficar decorando várias propriedades de vários componentes que na verdade só são coisas intermediárias, onde a realidade acaba sendo os elementos HTML mesmo, melhor então concentrar num lugar só, onde for mais perto do resultado. Fora que é um lado que já está no sangue, independente da linguagem server, tendo apoio infinitamente maior de todas as comunidades de desenvolvimento web, não só Java.
Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.
Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.
Com todo o respeito, mas se com todos os diversos frameworks de componentes não der pra fazer uma “ui diferenciada e complexa” com JSF, bom…conforme discutido no tópico um cenario adequado para o paradigma component-based é justamente esse: páginas diferenciadas e complexas.
Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.
Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.Com todo o respeito, mas se com todos os diversos frameworks de componentes não der pra fazer uma “ui diferenciada e complexa” com JSF, bom…conforme discutido no tópico um cenario adequado para o paradigma component-based é justamente esse: páginas diferenciadas e complexas.
Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.
Não conheço os trocentos Faces, mas os poucos que conheço mantem a usabilidade desktop, ai sim JSF ganha. Entendi que é perfeitamente possível fazer algo personalizado, mas me tira uma dúvida, supondo que junto a um designer temos que fazer uma página de consulta tipo essa http://globoesporte.globo.com/futebol/libertadores/, que nem é muito complexa, mas tem uma interface gráfica personalizada, qual seria a vantagem de usar solução component-based? Teríamos que parar pra criar um componente server pra abstrair a solução jquery personalizada ou deixar de lado o componente que é o motivador do JSF?
Suponho que o que voce chama de “usabilidade desktop” sejam os componentes dos frameworks (Rich, Prime, etc) que se assemelham a componentes de desktop? Se for o que quis dizer, entendo mas respeitosamente discordo, os componentes desses frameworks são apenas CSS e Javascript (na view), eles se parecem com componentes “desktop” como poderiam se parecer com qualquer outra coisa.
Eu particularmente, como disse antes, vejo valor em tratar os elementos da página como “componentes” individuais, cada qual com o seu comportamento. De qualquer forma, esses componentes são apenas taglibs…apenas passo os parametros e elas fazem o que fazem, seja lá o que for.
Algo que gosto no JSF é como os dados manipulados nesses componentes são atrelados ao servidor, atribuindo assim ao componente uma responsabilidade no funcionamento da página; o componente, em si, é apenas Javascript. Qualquer um desses componentes dos SeiLaOQueFaces poderiam ser feitos sem JSF. Mas uma coisa “boa” que vejo na especificação é que a partir dela foram gerados muitos desses frameworks; poderia fazer cada um desses componentes apenas com Javascript/Jquery/Prototype/Scriptaculous, mas eles estão aí, prontos.
A interação com o usuário pertence ao client-side, e isso não muda, sendo JSF ou sei lá o que. Com JSF podemos a partir do servidor parametrizar o comportamento do componente, mas penso que não deve sair disso; uma vez que o componente foi renderizado, ele faz com Javascript o que o mandamos fazer com os dados que mandamos pra ele. E só. No exemplo da página que voce citou, voce quer/precisa parametrizar esse componente de interação com o usuário e o estado desse componente a partir do servidor? Ou quer só enviar dados pra ele ler no client-side e deixar o Javascript se virar pro que ele tem que fazer lá, e caso necessite, ele volta ao servidor? Acho ambas as abordagens válidas. Entao o uso ou nao de JSF ou qualquer outra coisa vai do que voce quer fazer.
No fim das contas, como disse outro colega nesse tópico, “O melhor na grande maioria das vezes é o que você conhece bem.”
Obrigado.
Não conheço os trocentos Faces, mas os poucos que conheço mantem a usabilidade desktop, ai sim JSF ganha. Entendi que é perfeitamente possível fazer algo personalizado, mas me tira uma dúvida, supondo que junto a um designer temos que fazer uma página de consulta tipo essa http://globoesporte.globo.com/futebol/libertadores/, que nem é muito complexa, mas tem uma interface gráfica personalizada, qual seria a vantagem de usar solução component-based? Teríamos que parar pra criar um componente server pra abstrair a solução jquery personalizada ou deixar de lado o componente que é o motivador do JSF?Suponho que o que voce chama de “usabilidade desktop” sejam os componentes dos frameworks (Rich, Prime, etc) que se assemelham a componentes de desktop? Se for o que quis dizer, entendo mas respeitosamente discordo, os componentes desses frameworks são apenas CSS e Javascript (na view), eles se parecem com componentes “desktop” como poderiam se parecer com qualquer outra coisa.
Eu particularmente, como disse antes, vejo valor em tratar os elementos da página como “componentes” individuais, cada qual com o seu comportamento. De qualquer forma, esses componentes são apenas taglibs…apenas passo os parametros e elas fazem o que fazem, seja lá o que for.
Algo que gosto no JSF é como os dados manipulados nesses componentes são atrelados ao servidor, atribuindo assim ao componente uma responsabilidade no funcionamento da página; o componente, em si, é apenas Javascript. Qualquer um desses componentes dos SeiLaOQueFaces poderiam ser feitos sem JSF. Mas uma coisa “boa” que vejo na especificação é que a partir dela foram gerados muitos desses frameworks; poderia fazer cada um desses componentes apenas com Javascript/Jquery/Prototype/Scriptaculous, mas eles estão aí, prontos.
A interação com o usuário pertence ao client-side, e isso não muda, sendo JSF ou sei lá o que. Com JSF podemos a partir do servidor parametrizar o comportamento do componente, mas penso que não deve sair disso; uma vez que o componente foi renderizado, ele faz com Javascript o que o mandamos fazer com os dados que mandamos pra ele. E só. No exemplo da página que voce citou, voce quer/precisa parametrizar esse componente de interação com o usuário e o estado desse componente a partir do servidor? Ou quer só enviar dados pra ele ler no client-side e deixar o Javascript se virar pro que ele tem que fazer lá, e caso necessite, ele volta ao servidor? Acho ambas as abordagens válidas. Entao o uso ou nao de JSF ou qualquer outra coisa vai do que voce quer fazer.
No fim das contas, como disse outro colega nesse tópico, “O melhor na grande maioria das vezes é o que você conhece bem.”
Obrigado.
Desculpe, me expressei mal, dei a entender que voce quer desenvolver a tal pag ai do Globo Esporte quando na verdade você a citou como exemplo, correto? A não ser que de fato trabalhe na Globo :-o
Pois é, JS com ajax calls por demanda é uma abordagem minimalista que eu gosto. Hoje alguns componentes do PrimeFaces funcionam assim, mas enquanto ai eu imagino que o ajax seja direcionado para um serviço que retorne um JSON da vida para o Javascript e tal, no Prime (no JSF na verdade) a requisição iria para o managed bean. É esse tipo de detalhe que eu acho importante conhecer; component-based e action-based são paradigmas diferentes, é interessante conhecermos o que a plataforma nos oferece para termos como decidir o que é adequado. Ou no mínimo, termos os melhores argumentos pra xingarmos os frameworks que não gostamos :lol:
Obrigado.
Desculpe, me expressei mal, dei a entender que voce quer desenvolver a tal pag ai do Globo Esporte quando na verdade você a citou como exemplo, correto? A não ser que de fato trabalhe na Globo :-oPois é, JS com ajax calls por demanda é uma abordagem minimalista que eu gosto. Hoje alguns componentes do PrimeFaces funcionam assim, mas enquanto ai eu imagino que o ajax seja direcionado para um serviço que retorne um JSON da vida para o Javascript e tal, no Prime (no JSF na verdade) a requisição iria para o managed bean. É esse tipo de detalhe que eu acho importante conhecer; component-based e action-based são paradigmas diferentes, é interessante conhecermos o que a plataforma nos oferece para termos como decidir o que é adequado. Ou no mínimo, termos os melhores argumentos pra xingarmos os frameworks que não gostamos :lol:
Obrigado.
Muito bom esse tópico. Inicialmente achei que seria mais um daqueles inflamados por argumentos vazios e fanáticos, porém o que estou vendo é uma discussão de alto nível.
Agora voltando ao tópico…
Normalmente, em uma aplicação de “verdade” temos a integração de várias tecnologias e modelos de desenvolvimento. O JSF, componet-based, além das vantagens já citadas,
eu reforço o fato dele fazer parte do JEE6, nesse sentido, penso que JEE6 ficou devendo uma alternativa action-based, nada que SpringMVC, VReptor etc não resolva.
Por outro lado, não vejo nada que inviabilize a cooperação dos dois modelos, por exemplo: JSF para necessidade componet-based e JAX-RS + (JS-extensions ou componentes JSF especializados) para o action-based.
–
Rei
Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.
Ora pois,mas se é pra deixar as facilidades do framework de lado e fazer tudo na mão é melhor nem usar,né não?
Muito bom esse tópico. Inicialmente achei que seria mais um daqueles inflamados por argumentos vazios e fanáticos, porém o que estou vendo é uma discussão de alto nível.
Agora voltando ao tópico…Normalmente, em uma aplicação de “verdade” temos a integração de várias tecnologias e modelos de desenvolvimento. O JSF, componet-based, além das vantagens já citadas,
eu reforço o fato dele fazer parte do JEE6, nesse sentido, penso que JEE6 ficou devendo uma alternativa action-based, nada que SpringMVC, VReptor etc não resolva.
Por outro lado, não vejo nada que inviabilize a cooperação dos dois modelos, por exemplo: JSF para necessidade componet-based e JAX-RS + (JS-extensions ou componentes JSF especializados) para o action-based.–
Rei
Eu concordo. Parece que a especificação, ao valorizar a evolução do JSF (pro bem ou pro mal hehe), meio que “largou” o JSP e a abordagem action-based, o que é uma pena. Claro que há excelentes alternativas como as que você citou, mas acho chato ver o JSP um tanto quanto “estacionado”.
Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.Ora pois,mas se é pra deixar as facilidades do framework de lado e fazer tudo na mão é melhor nem usar,né não?
Bom, na verdade eu concordo contigo, prezado colega , talvez eu tenha me expressado mal. O que quis argumentar é que é possível injetar algum comportamento via Javascript no JSF, ao contrário do que alguns colegas do fórum argumentaram aqui, que “não é possível” fazer customizações no client-side com JSF. É claro que, dada a vastidão de componentes existentes, provavelmente haverá algum que faz o que voce quer; mas se não, basta ajustar, ou criar um comportamento seu a partir de um elemento qualquer. Com JSF isso é tão possível quanto seria com qualquer outro framework.