Qual o problema do JSF?

Prefiro usar o VRaptor quando desenvolvendo em Java. Muito mais simples IMO.

Mais simples do que indicara qual o faces e colocar as tags no jsp?
E manter as regras no faces?

antoniopopete:

Por que muitos desenvolvedores tem restrições contra esse framework?

Esta thread se originou desta (http://guj.com.br/posts/list/85314.java), não foi antoniopopete?

Bom, entre optar por um framework action-based ou component-based eu prefiro o component-based. Esse seria um motivo que me faria optar por JSF caso outras opções de frameworks que fossem action-based.

Também não acho que o fato de ser component-based seja tão determinante. O trabalho que teremos com configuração com certeza é diferencial e acho que temos frameworks web em java onde as configurações já são bastante simples.

Sei lá, é opinião pessoal, mas eu vou de Wicket! Quando o assunto é configuração, abstração de sessão, aplicação e facilidade de uso com certeza o Wicket é muito interessante. Não precisar escrever uma linha de JSP ao meu ver é muito bom, já que tudo que é compilavel fica dentro de uma classe java que pode ser compilada pela sua IDE, detectando os erros de compilação ali, na hora do desenvolvimento, sem ter que esperar levantar o servidor de aplicação para saber se o bendito do jsp compila. Acho que estes são bons motivos para não preferir JSF… rsrs…

Luiz Aguiar:

Estude mais de um framework e tire suas conclusões, vai encher de gente falando que gosta mais de X de Y e de Z, cada um tem seus gostos, aprenda um que vc seja mais produtivo e use-o!

É muito útil para algo mais trivial como cadastros.

Mas se você sai do trivial(mais web2) tem que dar voltas e voltas no framework para ter o que vc quer.

Quanto a configurações, IMHO o faces config é uma piada.
O JSF não é tão velho assim para usar uma abordagem tão arcaica.

Não fui a fundo no estudo do JSF 2, mas parece que vem muitas melhorias.
O problema é que quando isso for lançado, já estarão atráz do mercado novamente.
Não demora muito até os frameworks web começarem a abusar do method_missing de ruby.

Opinião pessoal;

Entendo.
Talvez seja por isso que ainda não desgostei dele.
Embora uma vez foi quase um parto tentar implementar aquele lance da URL amigável.
Quer dizer, nem sei como ficou porque acabei saindo do projeto.

antoniopopete, realmente o que fica valendo é o comentário do Luiz Aguiar. Existem muitas opções de frameworks web e é bom você procurar conhecer algumas das opções existentes.

Infelizmente aqui no Brasil o que o pessoal mais usa é Struts e JSF. São poucos os que buscam conhecer outras opções de frameworks. Pelo menos no caso do meu framework web favorito eu descobri ele assim, experimentando e indo conferir os recursos de boa parte das opções existentes.

Como iniciei minha experiência profissional com Swing é bem óbvio que iria preferir Wicket ao invés de um Stripes ou Spring MVC. Enfim, framework é que nem cueca. Cada um tem a sua preferida! As vezes mais de uma.

Uma dúvida: o código html resultante da renderização de uma página JSF passaria numa validação strict?

Um quote de mim mesmo -> http://groups.google.com/group/pbjug/browse_thread/thread/44e2845c93eee8cf/eea8bdbfb1bde335

Maurício Linhares:

Isso com certeza chateia mas eu acho que JSF é um caso especial. JSF
purinho, do jeito que vem da “loja” é praticamente inútil, qualquer
coisa além do trivial, você tem que escrever um monte de código de
“encanação”, um caso clássico é usar selects HTML, tipo quando uma
notícia tem uma categoria, que vem de uma coleção de categorias.

O framework é tão genérico, mas tão genérico, que pra resolver esse
caso simples eu preciso, pelo menos, implementar um converter pra
minha classe de domínio, carregar essa coleção em uma propriedade de
um managed bean e referenciar ela lá no <f:selectItems/>, já que eu
não posso colocar ela relacionada diretamente com o próprio select
(diferente do que eu faria com um DataTable, por exemplo, a própria
API não é unificada, não existe um “jeito” jsf de ser). Se você pega
um ASP.NET da vida, tudo é igual, todos os componentes visuais se
ligam a propriedades dos objetos ou a datasources, e são “preenchidos”
com esses dados, em JSF cada componente costuma defivir o seu próprio
jeito de carregar os dados, o seu próprio modelo, complicando ainda
mais a vida do usuário.

Pra complicar ainda mais, coisas básicas como callbacks pra eventos
que estão acontecendo durante o ciclo de vida de um managed bean são
simplesmente inexistentes, você não sabe quando o managed bean está
criado e vai começar a responder a uma requisição, não sabe quando
acabou a requisição dele, não sabe se é a primeira vez ou a milésima
que o cliente está requisitando esse mesmo managed bean, fato esse que
chega a ser abominável pra um framework que deveria ser baseado em
componentes, a própria página não é um componente (mais uma vez,
diferente do ASP.NET, onde a página é um componente e você preenche a
página em vez de managed beans que são da página mas não parecem ter
relacionamento nenhum com ela).

JSF, pra mim, é mais uma prova de que “design by commitee”, com um
monte de gente que não escreve aplicações metendo o bedelho e querendo
fazer a coisa genérica demais, só dá em merda. A coisa era tão absurda
que o próprio Craig McTãnãnã (não vou caçar o nome dele, é fácil de
vocês acharem) que foi o criador do Struts e era uma das mentes por
trás do JSF foi uma das primeiras pessoas a anunciar um framework pra
simplificar o desenvolvimento de aplicações JSF, o Struts Shale. Se
ele sabia quais eram os problemas que o JSF tinha e ele era um dos
chefões, por que ele não resolveu o problema na raiz em vez de criar
mais um framework pra atrapalhar a vida dos desenvolvedores?

Desde que eu fiz o meu primeiro sistema pra web em Java (na época era
um site de notícias pra empresa aonde eu estagiava) eu precisava de
uma ferramenta de templates pra homogeneizar a aparência do site que
eu estava fazendo (aquela coisa de ter um cabeçalho padrão, ter
rodapés padrão) e eu achava includes do JSP um modo terrívelmente
grosseiro de resolver o problema, já que mesmo com os includes eu
ainda repetia um bocado de código. Na época, pra resolver o problema,
eu usei a engine de templates do Struts, o Tiles, não me deu trabalho,
as páginas funcionavam exatamente do jeito que eu queria. Um tempo
depois eu precisei fazer uma atualização no sistema e achei que talves
fosse a hora de usar JSF pra aprender mesmo, quando comecie a
pesquisar, vi que JSF não tinha nada parecido com o Tiles, o que era
um absurdo, pois o mínimo que se esperava de um framework de
desenvolvimento web baseado em componentes era que ele resolvesse o
básico dos problemas e o uso de templates padrão é praticamente regra
em qualquer aplicação web, tive então que ficar usando JSP com Tiles
por muito tempo.

Mas sem me alongar muito, JSF puro e simples é sofrível, um retrocesso
em frameworks web em Java (e criar componentes é tão complicado que
existem frameworks pra criar componentes em JSF!), com Facelets e o
Seam ele já se torna útil pra fazer telas de cadastro de listagem, mas
mesmo assim o modo de redenrização complica demais a sua vida quando
você quer mexer com coisas mais avançadas com JavaScript (como usar
Ajax) ou interagir com outros tipos de apresentação, como Flash. Eles
queriam criar uma soluão genérica demais, terminaram criando o
framework web Java mais “específico” de todos.

PS: E antes que eu me esqueça, usar POST pra TUDO também é uma das
piores “qualidades” do JSF, porque isso é, pura e simplesmente,
estraçalhar com tudo o que foi feito com o protocolo HTTP desde o
surgimento da internet.

JSF não é ruim.
Sou contra a opinião que JSF é só para cadastrinhos e não entendi o comentário quanto a web2.0. Dificilmente vc encontrará em outro framework suites de componentes tão ricas quanto as encontradas para JSF (vide IceFaces, Richfaces, ajax4jsf)…

Se faces-config.xml é problema, dê um turbo em seu JSF com o Seam e jogue o xml (e até mesmo ManagedsBeans delegadores) no lixo…

Jsf toma o controle de uma maneira que o desenvolvedor não fica livre para sair do básico (CRUD).

Se uma framework precisa de addons para ser util, realmente tem algo muito errado em suas raizes.

Lezinho: Acho que “dificilmente” é uma palavra muito forte, vide que a maioria dos frameworks component based faz o trabalho do jsf com mais simplicidade e sem a necessidade de programar na defensiva.

Continuo sem entender essa afirmação. Trabalho com sistemas corporativos que vão muito além de cadastros e muitos deles foram desenvolvidos com JSF. E pelo contrário da afirmação acima, flexibilidade é o ponto forte do framework, basta saber usá-lo.

Não necessariamente. Se um framework foi concebido para ser trabalhado com add-ons (inclusive podendo ser feito pelos próprios usuários do framework), não vejo mal algum em seu uso (aliás, pelo contrário, essa é mais vantagem do que desvantagem).

O que é programar na defensiva? Bom, se você me apresentar algo mais fácil e rico do que isso eu retiro o dificilmente:

http://livedemo.exadel.com/richfaces-demo/richfaces/dataTable.jsf?c=column

http://component-showcase.icefaces.org/component-showcase/showcase.iface

https://scales.dev.java.net/

… sinceramente, não vejo onde mora a dificuldade.

Se você acha “difícil” desenvolver seus próprios componentes:

https://facelets.dev.java.net/

Se mesmo assim tudo isso é (por algum motivo que desconheço) complicado :twisted: :

http://www.seamframework.org/

Pois é né, o que seria de nós se não fosse a linguagem Java né, cheia de pontos de extensão pra serem “aproveitados”?

Fazer um <select> em JSF sem o Seam é uma penúria tão grande que eu não desejaria nem ao meu pior inimigo. É absolotamente impossível ser realmente produdivo com JSF (se comparado a outros frameworks modernos) sem usar tecnologias de suporte, como o Seam.

Lezinho:

O que é programar na defensiva? Bom, se você me apresentar algo mais fácil e rico do que isso eu retiro o dificilmente:

http://livedemo.exadel.com/richfaces-demo/richfaces/dataTable.jsf?c=column

http://component-showcase.icefaces.org/component-showcase/showcase.iface

https://scales.dev.java.net/

… sinceramente, não vejo onde mora a dificuldade.

Não precisa nem comentar sobre EXT, Dojo ou YUI não né?

Dizer que o RichFaces é “rico” chega a ser até engraçado, “rico” é Flex e Silverlight, o RichFaces é “fancy” pra quem não tem costume de mexer com Ajax. E como sempre pode ficar melhor, é só começar a se integrar com outros conjuntos de componentes (alguém aí falou IceFaces?).

Lezinho:

Se você acha “difícil” desenvolver seus próprios componentes:

https://facelets.dev.java.net/

Ah, quer dizer que fazer componentes em JSF é tão difícil que eu tenho que usar uma engine de templates externa, que anda praticamente morta, pra poder fazer eles de forma produtiva? :lol:

E não vamos esquecer que um “componente” criado usando o Facelets só funciona com Facelets, não é um componente JSF padrão.

Lezinho:

Se mesmo assim tudo isso é (por algum motivo que desconheço) complicado :twisted:

http://www.seamframework.org/

O Seam 1 era uma bela porcaria, só rodava em application servers. O Seam 2 já ficou mais amigável a ambientes menos enterprisey, mas mesmo assim ele continua sendo um enforcador com a corda bem curtinha. Toda aquela falação de “contextos gerenciados”, “conversations” são tiro certo pra fazer um servidor de aplicações sentar com uso descabido de memória e lixo nas sessões. Se o programador entrar no papo dele e realmente for usar todos esses troços, vai se enforcar rapidinho e não adianta esperniar não, quanto mais se mexer, mais a corda aperta.

hãn?

http://livedemo.exadel.com/richfaces-demo/richfaces/comboBox.jsf?c=comboBox

Penúria? Onde esta a dificuldade?

… não preciso nem comentar o parto que é integrar no braço estas tecnologias, não é? As suites JSF citadas utilizam internamente Dojo, Prototype, Scriptaculus entre outros …

Richfaces é mexer com Ajax com produtividade. Compare o uso de ajax4jsf (base do rich) versus DWR… a facilidade do primeiro é gritante sobre o segundo, fazendo as mesmas coisas. Icefaces (sim, mencionei), é outra excelente suíte (sobretudo em sua nova versão, menos bugada).

Ah, quer dizer que fazer componentes em JSF é tão difícil que eu tenho que usar uma engine de templates externa, que anda praticamente morta, pra poder fazer eles de forma produtiva?
E não vamos esquecer que um “componente” criado usando o Facelets só funciona com Facelets, não é um componente JSF padrão

Só se vc achar difícil. De fato é bem mais simples fazendo com facelet. Não vejo desvantagem no fato de se usar ‘apenas’ com facelet… se você fez o bichinho com Facelet, você esta usando ele… logo…

Quanto ao Seam, bom é uma opinião particular sua e pode ter sido resultado de alguma experiência. As minhas experiências tem sido diferentes, desde a versão 1.2.1. A integração das tecnologias é muito satisfatória e o gerenciamento de contexto ajuda mais do que atrapalha. Programador fazer besteira, ele faz com qualquer ferramenta, não é usar o Seam ou Wicket que vai mudar isso.

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:a4j="http://richfaces.org/a4j"
      xmlns:rich="http://richfaces.org/rich">
      <rich:comboBox defaultLabel="Enter some value">
            <f:selectItem itemValue="suggestion 1"/>
            <f:selectItem itemValue="suggestion 2"/>
            <f:selectItem itemValue="suggestion 3"/>
            <f:selectItem itemValue="suggestion 4"/>
            <f:selectItem itemValue="suggestion 5"/>
      </rich:comboBox>
</ui:composition>

Fonte: http://livedemo.exadel.com/richfaces-demo/richfaces/comboBox.jsf

O que que acontece se eu quiser adicionar e retirar itens dinamicamente nessa lista ? Via javascript mesmo ?

É só vc ver o segundo exemplo da mesma página.

Eu falei via javascript, não usando collections.

http://livedemo.exadel.com/richfaces-demo/richfaces/comboBox.jsf?c=comboBox

Penúria? Onde esta a dificuldade?

Cadê ele mostrando o código do bean aonde essas capitais são transformadas em um array de SelectItem? Cadê o converter que vai transformar essas “capitais” em um objeto de negócio lá na aplicação? Ele não mostrou código nenhum ali, ele está é vendendo gato por lebre.

Se isso for só um array de String, me desculpe, mas isso não é caso de uso.

Prototype é uma biblioteca de suporte e Scriptaculous é uma biblioteca de efeitos, nenhum dos dois tem haver com componentes ricos, então eles não vem ao caso.

E qual dessas bibliotecas de JSF usa o Dojo?

Não compare alhos com bugalhos, DWR não é uma bibioteca de componentes, é uma biblioteca de acesso remoto a aplicação. E eu conto nos dedos as pessoas que conseguiram usar qualquer outra biblioteca JSF junto com o IceFaces.

Bem, se você não acha, realmente não tenho argumentos quanto a isso. Quem estiver em dúvida, faz um componente JSF aí (ou melhor, pega o Core JSF e dá uma olhada no capítulo sobre como fazer componentes)

Programador ruim faz porcaria em qualquer lugar, mas o Seam incita o programador ruim a ser pior ainda, guardando informação demais na sessão, o que mata a escalabilidade de qualquer aplicação de tamanho razoável.

Cadê ele mostrando o código do bean aonde essas capitais são transformadas em um array de SelectItem? Cadê o converter que vai transformar essas “capitais” em um objeto de negócio lá na aplicação? Ele não mostrou código nenhum ali, ele está é vendendo gato por lebre.

Se isso for só um array de String, me desculpe, mas isso não é caso de uso.

Não precisa ser simples Strings não …

SelectItem não é problema:
http://myfaces.apache.org/tomahawk/selectItems.html

Conversor de entidade não vem com implementação default, mas você acha uma pilha de exemplos na internet. Fora que você faz isso uma vez na vida e usa em todo projeto(s). Não vejo grande esforço em fazer uma classe com dois métodos (no máááximo 10 minutos?) que será largamente reutilizada. Em contra-partida, se você usa um Wicket da vida você faz classe Java pra tudo, logo escrever um único conversor JSF não é para ser um sacrifício.

Prototype é uma biblioteca de suporte e Scriptaculous é uma biblioteca de efeitos, nenhum dos dois tem haver com componentes ricos, então eles não vem ao caso.

E qual dessas bibliotecas de JSF usa o Dojo?

Scriptaculus possui componentes drag and drop, autocomplete, sliders além de outros componentes interessantes, não é apenas uma lib de efeitos, mas isso não vem ao caso… O Tomahawk e seu Sandbox tem alguma coisa de DOJO, coisa simples como o Fish-Eye e um Initializer para o toolKit. Não é nada de muito sofisticado ainda, mas a tendência é que a integração aumente (basta dar uma olhadinha no Jira do projeto).

Quanto a minha citação ao ajax4jsf vs DWR foi apenas para dizer o quanto é trivial a manipulação de ajax…

Uma aplicação de tamanho razoável não armazena conversação em sessão, aliás a própria JBoss desencoraja isso… O modelo proposto é a utilização de Statefuls, mas essa já é uma outra discussão …

Eu falei via javascript, não usando collections.

Pelo que eu tinha entendido sobre sua pergunta (em itálico na primeira citação), era se eu removia os elementos declarados estaticamente na página via Javascript. Bom, se os elementos não são estáticos (podem ser removidos dinâmicamente), logo não há pq eu declara-los de maneira estática na página… logo, sempre serão coleções, que posso manipular dinamicamente via ajax ou request convencional.

Lezinho:

Não precisa ser simples Strings não …

SelectItem não é problema:
http://myfaces.apache.org/tomahawk/selectItems.html

Igual a tag do Seam, diga-se de passagem. De qualquer forma, não é padrão, mas deveria ser, praticamente tudo em JSF “puro” é sofrível.

A falta de uma base decente faz com que todos os outros frameworks tenham que fazer serviço de encanadador, como os eventos de ciclo de vida de um bean, que existem em ASP desde “sempre” e em JSF foram sumariamente ignorados.

A parte de componentes do Scriptaculous é bem restrita, mas isso realmente não vem ao caso. Interessante saber que o Tomahawk está indo pra algum lugar, porque o MyFaces anda comendo poeira faz tempo pro RI.

Independente do lugar aonde eles vão ficar (não vai ser na sessão, mas vai ser na memória do servidor de qualquer forma, então o problema é o mesmo), você acha uma boa idéia usar Statefuls em um ambiente com cargas altas e mais do que uma máquina como servidor de aplicação?

Não tenho como discordar que algumas coisas deveriam vir por padrão no JSF, mas enquanto isso os componentes não standards estão cumprindo bem o papel.

Em relação ao Seam e o uso de Stateful, no ambiente que você descreveu, acho uma boa idéia como também acho a melhor situação. Os dados não ficam em memória o tempo todo como HttpSession, se o servidor precisar ele passiva o bean para atender a mais demanda, de acordo com seu algoritmo para passivação e local para store dos dados, preservando seu estado conversacional e liberando memória. Se o bean expira ele move de Passivated para DoesNotExist e encerra a conversação, caso contrário e for invocado, o bean volta ao estado ativo de Method-Read.
A replicação em um ambiente como parque de clusters, tbm não é igual a tradicional replicação stick-session de um HttpSession (já foi um dia). Os servidores de aplicação sincronizam o cache com granulariedade fina, replicando apenas o valor alterado de um atributo. Os Statefuls tem má fama devida as implementações antigas de replicação… hoje isso esta muito diferente (vide jbossCache do jBoss AS).

Implementar AJAX com JSF é algo realmente simples, hoje você consegue pegar uma aplicação JSF convencional (sem uso de AJAX) e inserir AJAX transparentemente através do Ajax4jsf, na maioria dos casos o que você mudará são algumas linhas nas páginas, e só.

DWR é na minha opinião o melhor framework AJAX para Java, isso claro se eu não estiver em uma aplicação que utilize JSF, daí sem dúvida eu vou de AJax4jsf

Se a vantagem do JSF é a gama enorme de componentes, você tem praticamente componente para quase tudo Utilizar outros componentes JSF não doi, até alivia a dor de ter que implementar um componente próprio.

Não entendo porque você critica isso, você faria o mesmo se estivesse utilizando outro framework como SpringMVC ou Struts, teria que juntar várias APIs para contornar carências de javascript e/ou css para conseguir o que os componentes JSF te proporcionam! No final seria bem mais trabalhoso!

Mesmo utilizando-se de APIs como Extjs para conseguir GUIs ricas você terá um grande problema, a enorme dificuldade em encontrar desenvolvedores que saibam realmente utilizar javascript de forma decente. A maioria só sabe utilizar javascript para criar funçõeszinhas de validação

Isso é verdade, infelizmente por JSF não contar ainda com uma padronização para AJAX nós temos algumas incompatibilidades como essa do Icefaces e outros conjuntos de componentes como Trindad, ou Richfaces ou algum proprietário, mas mesmo com as incompatibilidades eles conseguem conviver juntos no mesmo projeto. JSF 2.0 resolverá isso, sorte nossa!

Outra coisa que você tem razão e eu não discordo. Desenvolver componentes com JSF é algo sofrível, e eu acho que dificilmente vai valer a pena. Porém com Facelets e outros frameworks você consegue facilitar isso, mas ainda assim dá um trabalhinho Mas com a gama enorme de componentes você ainda acha que há tanta necessidade para reclamar disso? Eu sinceramente nunca precisei criar qualquer componente JSF, e se precisasse tentaria evitar isso até não ter mais jeito.

Alguns pontos negativos na minha experiencia com jsf.

1 - Jsf puro é tão ruim quanto struts, se vc precisa copiar algo da internet para fazer sua aplicação funcionar tem algo muito errado, a documentação deveria ser suficiente.

2 - Integração com jstl é uma piada.

3 - Problemas com CSS, relacionados aos atributos gerados pelo jsf (outra piada)

4 - Problemas com customização de js.

5 - JSF é baseado em post, então esqueçam query string.

6 - Problemas relacionados aos botões de voltar e refresh.

7 - Muito lixo (html e javascript) gerado.

8 - Tente convencer um webdesigner que algumas coisas não podem ser mudadas.

Pessoal, respeito que alguns usem o jsf e gostem de suas “features”, mas defender algo que não segue o principio do KISS e o mesmo que nao querer assumir que seguiu o caminho errado. (quantas pessoas vcs conhecem que defendem fervorosamente o struts?).

Existem soluções melhores, mas claro que o jsf “funciona”. Porém, a maneira que o pessoal anda defendendo o jsf me parece que ele é a unica solução e deve ser utilizado independente dos milhoes de problemas.

Atualmente para mim, o jsf é algo promissor, porém fica nisso.

Ok não sou dos mais fãs de JSF, mas justiça seja feita com relação a esses dois pontos:

2 - Isso era no 1.1… no 1.2 não é mais não.

6 - Existe o para vc colocar no faces-config.xml (isso sim uma precariedade, mas no 2.0 deverão tornar isso opcional).

pafuncio:

aleck:

2 - Integração com jstl é uma piada.

6 - Problemas relacionados aos botões de voltar e refresh.

Ok não sou dos mais fãs de JSF, mas justiça seja feita com relação a esses dois pontos:

2 - Isso era no 1.1… no 1.2 não é mais não.

6 - Existe o para vc colocar no faces-config.xml (isso sim uma precariedade, mas no 2.0 deverão tornar isso opcional).

Pois eh, não tive a honra de mecher no 1.2 : 8)

De qualquer forma, acho que o 1.x deveria ser considerado beta pelo tamanho das modificações do 2.0

:twisted:

Olá Aleck,

1 - Jsf puro é tão ruim quanto struts, se vc precisa copiar algo da internet para fazer sua aplicação funcionar tem algo muito errado, a documentação deveria ser suficiente.

Tirando o primeiro item que eu não entendi, os demais não são problemas hoje com JSF1.2 e alguns já tinham soluções mesmo com JSF1.1

JSF é bem simples, talvez a única coisa complicada dele seja a construção de componentes, fora isso não há complicações. Além do mais ter que criar um componente novo é algo difícil de acontencer, mas não improvável claro.

Existem soluções melhores, mas claro que o jsf “funciona”. Porém, a maneira que o pessoal anda defendendo o jsf me parece que ele é a unica solução e deve ser utilizado independente dos milhoes de problemas.

Assim como Java não é a solução para tudo JSF também não o é Nesse caso não é problema da tecnologia em si, mas sim de quem decidiu utiliza-la.

antoniopopete:

Por que muitos desenvolvedores tem restrições contra esse framework?

A idéia é: Conhecer toda a teoria e partir para pratica ou partir para pratica sem conhecer a teoria…

JSF= Não precisa de teoria, pega meia-dúzia de tag e sai arregaçando… Se um dia der um pau, senta e chora…

Outros Frameworks: Arquitetura Simples, fácil entendimento e lhe permite conhecer o fluxo a fundo sem nada de bizarro!!!

Estudei muito JSF, realizei alguns projetos e minha conclusão é: Se tiver oportunidade de NÃO USAR… Aproveita, tem coisa melhor!!!

Programador preguisoço gosta de JSF e provalvelmente nunca vez 1 “hello word” em qualquer outro framework, tem que mastigar e por na boca!!!

JSF é assim, toma nenem na boquinha… Se der algo errado, literalmente vai morrer de fome porque provalvelmente não conhece a API de Servlets!!!

Há… E detalhe…

Se um dia escrever um artigo sobre Frameworks Web, o título seria o seguinte: “1001 Motivos para NÃO USAR JSF”

Acabei achando JSFUnit que talvez possa ajudar, alguém já usou??

dders:

Há… E detalhe…

Se um dia escrever um artigo sobre Frameworks Web, o título seria o seguinte: “1001 Motivos para NÃO USAR JSF”

Oi galera.

Pelos comentarios notei que alguns de vocês tem bastante conhecimento e experiencia em JSF.

Estou estudando e tenho algumas dúvidas sobre a aplicação prática deste framework.

Gostaria de saber se vocês desenvolvem as páginas na “unha” ou estão utilizando os recursos drag and drop das IDEs.

Sou do tipo que gosta de fazer as coisas na unha mas as vezes esse negócio de arrastar e soltar me chama atenção por parecer mais produtivo.

No caso do JSF drag and drop vale a pena?

Olá Maurício, tudo bem?

Acho que temos que levantar alguns pontos que pelo visto tu não conhece… Antes de eu começar a argumentar, gostaria de saber: há quanto tempo tu trabalha com JSF? Tu já trabalhou com JSF 1.1 e JSF 1.2? Sabe a “real” da existência do MyFaces IMPL? E do Tomahawk/Sandbox/Trinidad/Tobago? E ajax4JSF? E principalmente, Facelets?

Antes de tudo, também queria dizer que acho que o JSF é limitado (o RI), tendo em vista que é a “primeira” versão dele. Quando o JSF saiu, até mesmo a SUN dizia que o RI servia somente como referencia mesmo, e que a melhor maneira de aproveitar o mesmo era utilizando suas impls (vide MyFaces) ou sua extesões (daí vem aquela porrada: richfaces, icefaces, adf faces, tomahawk (e outras impls do capeta que me esqueci o nome hehhe).

sobre as extensões (ajax e afins), tu pode ver que vários componentes do JSF já implementam isso automaticamente. Se você olhar por exemplo o Richfaces, ele facilitar um monte a tua criação de efeitos. Você não precisa tocar em Javascript pra fazer, por exemplo, um fade do script.aculo.us. Sandbox já implementa DOJO, só ver por exemplo o ModalPanel e o richtext edit.

Ah, quer dizer que fazer componentes em JSF é tão difícil que eu tenho que usar uma engine de templates externa, que anda praticamente morta, pra poder fazer eles de forma produtiva? E não vamos esquecer que um "componente" criado usando o Facelets só funciona com Facelets, não é um componente JSF padrão

Como citado anteriormente, parece que vocês estão julgando o framework como se ele fosse simplesmente ser como ele foi na primeira versão. JSF saiu por meados de 2002, 2003, não lembro, essa API do facelets não server somente para templating e no final das contas é um utilitário. Struts teve o tiles também, né? Tapestry desde que saiu teve templating? Spring-MVC também?

sobre isso:

posso responder com isso

caramba, fazer isso

<h:selectOneMenu value="#{person.continent}" required="true"> <s:selectItems value="#{continents.resultList}" var="continent" label="#{continent.name}" noSelectionLabel="Please Select..."/> <s:convertEntity /> </h:selectOneMenu>

mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar…

e novamente

Programador ruim faz porcaria em qualquer lugar, mas o Seam incita o programador ruim a ser pior ainda, guardando informação demais na sessão, o que mata a escalabilidade de qualquer aplicação de tamanho razoável.

mas uma coisa eu concordo contigo

também acho que falta algumas coisas, mas eu discordo complemanete que deveria vim tudo duma vez só. Não sei se você quis dizer isso, mas por exemplo, eu sou completamente a favor que haja várias implementações de bibliotecas porque muitas podem ser usadas pra aplicações específicas, cujo qual não haveria necessidade de ter quilos e quilos de componentes, efeitos ou novas operações. E sim, tudo no JSF puro é ruim, mas

Hoje em dia ninguém mais usa outra implementação de RI do JSF 1.2. Não há mais necessidade. Na época do JSF 1.1. o MyFaces se mostrava superior à impl do 1.1 (basta ver os erros de messages e afins), mas no JSF 1.2, basta usar as outras component suites que já faz com que o trabalho seja interessante, sem muitos erros e nem stress =D

Tapestry tem templates desde sempre, o Sprinng MVC é view-agnostic, então você sempre pode usar tudo com ele (como freemarker, velocity, JSP puro, JSP com tiles ou qualquer um dos anteriores com Sitemesh). A falta de uma engine de templates padrão no JSF é uma briga muito antiga.

O maior problema do Facelets é que você não pode simplesmente chegar lá e colocar ele na sua aplicação, você tem que ter certeza de que todos os componentes que você está usando tem a configuração contendo os mapeamentos do Facelets, o que já foi um pé no saco logo quando o Facelets começou e só o Tomahawk tinha taglib.

posso responder com isso

caramba, fazer isso

<h:selectOneMenu value="#{person.continent}" required="true"> <s:selectItems value="#{continents.resultList}" var="continent" label="#{continent.name}" noSelectionLabel="Please Select..."/> <s:convertEntity /> </h:selectOneMenu>

mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar…

Você é cego ou está ignorando a afirmação sobre [size=24][color=red]sem usar o Seam[/color][/size] de propósito?

lhe sugiro a ler novamente a documentação do Seam e ver que a maneira que ele guarda as coisas na sessão não é uma maneira comum, já é otimizado e, além disso, você guarda na sessão se quiser. Não entendi a parte que tu cita que incita o programador ruim a guardar coisas na sessão. Dá uma lida aqui http://docs.jboss.com/seam/2.0.1.GA/reference/en/html/pr01.html que ele fala desse gerenciamento de estados e contextos que ele o fazer

Uma maneira otimizada? Otimizada em quê? Ele faz compressão dos objetos?

Não há otimização nenhuma, ele bota na memória e pronto. O máximo que você vai ter é session passivation/activation se as aplicações estiverem em cluster (e o servidor tiver caído gracefully, o que na maioria das vezes não é o caso) e quem já usou sessões em cluster sabe que é muito melhor não usar isso. Se pra você isso não faz diferença, ótimo, mas eu já escrevi aplicações grandes o suficiente pra saber que guardar estado de usuário demais na memória do servidor é uma péssima idéia.

ah perdão, eu achava que tu tava se referindo ao seam

sobre o facelets, pelo que eu ví ele só tem problema com alguns poucos componentes do tomahawk. Com richfaces não tem nada por exemplo

Mauricio Linhares:

Não há otimização nenhuma, ele bota na memória e pronto. O máximo que você vai ter é session passivation/activation se as aplicações estiverem em cluster (e o servidor tiver caído gracefully, o que na maioria das vezes não é o caso) e quem já usou sessões em cluster sabe que é muito melhor não usar isso. Se pra você isso não faz diferença, ótimo, mas eu já escrevi aplicações grandes o suficiente pra saber que guardar estado de usuário demais na memória do servidor é uma péssima idéia.

Isso se vc usar websession no lugar de SFSB … como já citado …

Oba! Esta discussão está (ou estava) bonita!

Cheguei um pouco atrasado, mas surgiram algumas dúvidas…

Para o time do JSF (é só uma brincadeira):
Estou pensando em iniciar o desenvolvimento de uma aplicação utilizando JSF com RichFaces + a4j + Facelets + Spring + JPA (hibernate + hibernate validator)
Será uma aplicação cliente servidor com um volume de acessos entre baixo a médio.

O que acham dessa idéia?

E para o time do anti-JSF (Repito, é só uma brincadeira!):
Para a camada de view, algo como Dojo + JSP ficaria legal? Têm outras idéias legais?

E pra todo mundo… colocar o JavaFx nessa história seria prudente? Ou ainda é muito verde pra se pensar?

Desculpem se falei besteira e, por favor, me ajudem a desfazer esse nó na mente do iniciante!

[]s