Por que muitos desenvolvedores tem restrições contra esse framework?
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?
[quote=antoniopopete]Por que muitos desenvolvedores tem restrições contra esse framework?
[/quote]
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!
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…
[quote=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!
[/quote]
Não estou querendo utilizar nenhum framework.
Já utilizei struts e hoje utilizo jsf, gostaria de saber porque MUITOS desenvolvedores repudiam tanto o jsf…
Isso que o TiagoSenna falou é mals mesmo de ter que subir o servidor para ver um erro de tag, mas nos action-bassed, também são assim, com suas taglibs.
É 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
[quote=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. [/quote]
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
… 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: :
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.
[quote=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
… sinceramente, não vejo onde mora a dificuldade.[/quote]
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?).
[quote=Lezinho]Se você acha “difícil” desenvolver seus próprios componentes:
https://facelets.dev.java.net/[/quote]
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.
[quote=Lezinho]Se mesmo assim tudo isso é (por algum motivo que desconheço) complicado :twisted:
http://www.seamframework.org/ [/quote]
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).
[quote]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[/quote]
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?[/quote]
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.