| Autor |
Mensagem |
|
|
Estou hoje em dia mexendo com um projeto em Grails aqui do JUGMS e tenho gostado muito, mas a abstração que o JSF permite a gente trabalhar em alguns casos faz falta. Mas é obvio que eu consigo fazer de uma forma tão boa/fácil quanto em JSF com Grails, mas fica mais visível o fato de estarmos trabalhando com Web. É diferente, nem melhor nem pior.
No final das contas eu vejo a muito das discussões rolam em cima de gostar ou não do JSF abstrair boa parte da Web (mas deixar muitos furos, principalmente na versão 1). Para mim é indiferente. Mas quem se incomoda com isso não vai nunca gostar de JSF. Eu uso JSF e gosto e uso Grails e gosto também.
|
 |
|
|
vhmolinar wrote:Sobre o JSF, acho que quem tinha que sofrer de verdade mesmo com isso já sofreu com as antigas versões.
Em teoria, do 2 pra frente tudo tende a melhorar de verdade.
Não descarto uso de JSF em aplicações Web que não dependam muito de layout, SEO, COMET , etc.
O problema do JSF que eu mais presenciei é o povo que usa sem entender/escolher e sim porque é uma spec. Aí nessa nóia de spec o cara usa puro. E cá entre nós, JSF 1.x puro não dá. Não tem nem como criar um combo a partir de uma lista de entidades. Por isso sempre usei com facelets e no mínimo alguém que tivesse um t:saveState ou a4j:keepAlive, além é claro de um componente de selectItems que permitisse listar entidades. Agora se o cara vai usar JSF 1 mas não está disposto a "sujar" com outras coisas então não usa que vai passar raiva.
Já a versão 2 melhorou pra caramba, mas muito também graças ao JEE6 com EL mais flexível.
|
|
|
|
O Javaneiros 2009 é um evento regional, promovido pelo Grupo de Usuários Java de Mato Grosso do Sul, a ser realizado no dia 14/11/2009 em Campo Grande/MS, que tratará de assuntos relacionados à tecnologia Java e ao desenvolvimento de software.
O objetivo principal do evento é a troca de conhecimento entre acadêmicos e profissionais de diversas áreas, das quais podemos citar:
- Desenvolvedores e Arquitetos de Sistemas
- Gerentes de TI
- Técnicos de informática
- Estudantes e Professores universitários da área de TI
- Entusiastas e interessados em tecnologia
Confira a grade de palestras do evento que vai contar com nomes conhecidos da comunidade Java.
Entrada: 1 Kg de Alimento não perecível
As inscrições podem ser feitas pelo site javaneiros.com.br
|
|
|
|
bobmoe, se você já conhece facelets, e acha que é uma forma boa de fazer componentes, então vai perceber que na versão 2.0 só melhorou. Tem aquela parte da especificação do componente onde informamos a estrutura dos objetos que o componente manipula, mas você também pode fazer praticamente igual como já fazia no facelets 1.1.x. Uma vantagem do novo facelets é que podemos passar actions como parâmetro, e na versão anterior tinha que fazer uma gambiarra para isso funcionar. Além de outras coisas que podemos fazer também.
Obviamente cada um tem um ponto de vista, mas se você gostava do facelets antigo, provavelmente vai gostar mais ainda do novo. As vezes os exemplos tem coisas a mais do que seria o estritamente necessário justamente para mostrar o maior número de funcionalidades em um exemplo só.
E a parte de ajax é praticamente igual ao que o richfaces (ajax4jsf) faz, com a vantagem de você poder colocar a tag <f:ajax> em qualquer parte da tela e "ajaxiar" todos os componentes que ficaram dentro dela em uma pancada só. Tanto que com essa tag <f:ajax> nem vai mais ter a <a4j:support>, pois a tag padrão faz tudo que a outra faz e mais um pouco ainda. Então como pelo visto você gosta do jeito de trabalhar com ajax do richfaces, provavelmente vai gostar do jeito padrão também. Eu já linkei lá em cima isso, mas caso você não tenha visto, aqui eu dou uns exemplos de como usar essa nova tag.
Valeu!
|
|
|
|
Bom dia JxtaNode,
eu nunca testei, mas dizem que facelets roda mais rápido do que jsp basicamente por 3 motivos: o primeiro é que não existe aquele tempo maior para execução da primeira view, que resulta da transformação do jsf no servlet; e o segundo vem do fato do html em si ser gerado pelo renderizador do jsf, então tanto faz se for por jsp ou facelets a renderização em si seria na mesma velocidade; e um terceiro motivo seria a velocidade do sax, que para gerar a árvore do jsf uns dizem que executa igual, outros dizem que executa mais rápido que o servlet compilado.
Eu acredito mais que o segundo e o terceiro motivo sejam equilibrados, e que o facelets leve vantagem em cima do tempo de compilação do jsp para servlet, mas não fiz testes práticos. Se alguém tiver feito ou se souber de referências confiáveis poste aqui. Na prática mesmo a vantagem que percebi, além de templates e componentização facilitada, foi a maior clareza nas mensagens de erro.
|
|
|
|
Leonardo3001 wrote:... Porque só fica nesse oba-oba de noobs que nunca aprenderam outro framework web? Será que aqueles que tanto se decepcionaram com framework em Java foram para Rails ou Django, e só sobraram os medianos?...
Que interessante... então se alguém não acha a mesma coisa que você é porque é um noob/mediano 
me diz qual o livro que você está lendo atualmente pra eu ler também e assim deixar de ser tão medíocre 
... desculpa a todos, sou contra flames, mas essa não consegui deixar passar  (na próxima não respondo)
|
|
|
|
JxtaNode wrote:Bom dia,
JSF e mesmo, muito simples de usar ou seja 4 ficheiros de base ( jsf-api.jar , jsf-impl.jar , jstl-api-1.2.jar , jstl-impl-1.2.jar) ...
Usando facelets não são necessários os jars do jstl, e como o JSF 2 já tem facelets incorporado, só precisamos mesmo dos 2 jars: jsf-api.jar e jsf-impl.jar.
|
|
|
|
YvGa wrote:Como so vou ter tempo pra ver os links todos com calma a noite, tem uma coisa que me deixou curioso:
Essa versao é compativel com as versoes anteriores?
dá uma olhada aqui que explica certinho o esquema da compatibilidade.
Resumidamente é compatível sim. As principais diferenças em relação à compatibilidade é no Facelets incorporado ao JSF e não no JSF em si. No entanto ao perceber que você usa as classes antigas do facelets 1.1.x o facelets incorporado no JSF 2 não é startado, deixando rodar somente a versão antiga.
Depois de migrar os componentes para deixar de usar as classes do pacote com.sun.facelets, é só tirar os jars antigos e o novo facelets já sai rodando.
ranophoenix wrote:
Muito legal essas novidades do JSF. O bom é que quem utiliza o JBoss Seam já está habituado com algumas delas.
Realmente, com RichFaces + Seam a gente já aproveita de muitas dessas novidades. Mas como ainda tem muitos projetos que se limitam a usar somente as especificações, essas novidades são muito importantes 
|
|
|
|
Acaba de sair oficialmente a versão 2.0 da implementação de referência do JSF.
As novidades eu já havia postado quando saiu a beta1, e são:
 o suporte a anotações
implicit navigations
ajax
suporte a várias VDL (View Definition Language): a implementação deve ao menos suportar JSF e Facelets, sendo o Facelets o default
uma forma nova, mais simples e mais robusta de se construir componentes com Facelets
view scope
custom scopes
suporte à resources
URL's amigáveis (método GET)
Integração com Bean Validation
Além das novas funcionalidades que eu comentei acima (e umas que eu provavelmente esqueci de colocar nessa lista), o JSF 2 vai se beneficiar da nova versão da Unified EL (que sairá no JEE 6), passando a ter suporte a passagem de parâmetros nas expressões
Outros links:
https://javaserverfaces.dev.java.net/
https://javaserverfaces.dev.java.net/nonav/rlnotes/2.0.0/index.html
https://javaserverfaces.dev.java.net/maven2
|
|
|
|
king_of_gods wrote:Será que o JSF 2.0 vai ficar tão bom quanto o Jboss seam 3?
Esse tipo de comparação é complicada pois comparamos coisas muito diferentes. O Seam está um nível acima do JSF. JSF por exemplo não tem ambição de prover Injeção de Dependencia (apesar de suportar desde a versão 1.x), nem iteragir com EJBs 3 nem com JPA. O Seam é um framework muito maior. Já o Seam3 vai ser feito em cima do WebBeans, que vai ser a implementação de referencia da JCDI que também é uma especificação assim como JSF, porém maior.
Com certeza sempre temos uma lentidão maior quando se trata de algo vindo do JCP, mas temos que, até certo ponto, entender que estamos falando de tecnologias que contam com a "bênção" de grandes players, tem muita grana envolvida, não da pra fazer hoje e refazer amanhã.
Na minha opinião a grande vantagem do JSF 2 é que ele veio padronizar muitas das coisas que o JSF 1.x não tinha e precisávamos de outros frameworks como Seam (incluindo JBossEL) e por aí vái. É importante essa evolução para manter a plataforma em evolução, mas não dá pra comparar com um framework. Sem contar que na prática a gente acaba usando frameworks mesmo, as especificações são a base da plataforma, mas o que puxa pra frente são as criações da comunidade.
Agora falar que compensa mais ir pra rails analisando que uma versão de JSF demora pra sair é ser parcial (minha humilde opinião), pois na plataforma Java temos o Grails, que tem a mesma idéia mas usando os principais frameworks que a plataforma Java já consagrou. E outra, Rails é um framework, se for assim o certo é comprar com outro framework, e aí entra o Seam, Grails, etc. E além disso ainda temos que ver se não estamos reclamando de JSF por causa do paradigma diferente. Acho o SpringMVC muito bom, mas prefiro JSF. Quem prefere o SpringMVC provavelmente prefere os frameworks baseado em action, enquanto eu prefiro os baseados em componentes/eventos. Mas é pessoal, não posso afirmar que um é melhor que o outro.
Só reforçando que não quero criar flames nem to falando que disseram que compensa mais ir pra Rails, mas todo mundo sabe que esse tipo de comparação rola solta em listas de discussão, nos corredores, etc. Então a gente tem que ter em mente que só podemos comparar coisas que estão no mesmo nível. Por exemplo o Mojarra, RI do JSF, tem suporte (antes mesmo da versão 2) a Groovy, agora na versão 2 tem como a gente fazer configuração programática, e isso tudo na própria implementação (não especicação).
Então temos que separar bem as coisas. Uma é a produtividade da plataforma Java, com seus frameworks de qualidade inquestionável, inclusive com ótimos concorrentes dentro da própria plataforma. Outra coisa é a parte "oficial" da plataforma que evolui mais lentamente, mas o mais importante é que evolui aprendendo com a comunidade.
Acabei escrevendo um monte porque hoje estou em treinamento e só pude ver a thread agora e depois só a noite, então minhas opiniões pelo que foi discutido até agora são essas. Mas o bacana de fórum é justamente as divergências de idéias, só temos que tomar cuidado pra nã virar flame.
|
|
|
|
Saiu o beta1 da implementação de referência do JSF 2 e o resultado da votação da versão final da especificação: aprovado
Entre as novidades estão:
o suporte a anotações
implicit navigations
ajax
suporte a várias VDL (View Definition Language): a implementação deve ao menos suportar JSF e Facelets, sendo o Facelets o default
uma forma nova, mais simples e mais robusta de se construir componentes com Facelets
custom scopes
suporte à resources
URL's amigáveis (método GET)
e por aí vai...
Frequentemente eu tenho postado aqui sobre essas novidades. Alguns assuntos eu ainda não publiquei nada mas já tenho os exemplos prontos, então logo devo colocar no blog.
Além das novas funcionalidades que eu comentei acima (e umas que eu provavelmente esqueci de colocar nessa lista), o JSF 2 vai se beneficiar da nova versão da Unified EL (que sairá no JEE 6, passando a ter suporte a passagem de parâmetros), e tem integração com a especificação Bean Validation.
|
|
|
|
olha, não tenho como testar aqui agora, mas já tive esse problema quando eu criava um componente e passava um managedBean e/ou uma action dinamicamente. Estatico como esa no teu código eu nunca vi, mas pode ser algum detalhe envolvendo o fato de você estar usando jsfc e não diretamente a tag do jsf. Veja se da seguinte forma funciona:
|
|
|
|
|
toma cuidado com os caminhos que você colocar no template. Caminhos ficam relativos à pagina que usa o template, e não ao arquivo do template, e isso confunde um pouco, pois quando criamos o template muitas vezes colocamos os caminhos relativos pensando nele. Então a melhor coisa é você ter caminhos relativos ao contexto da sua aplicação, e não ao arquivo do template. Faça o teste e comente aqui.
|
|
|
|
O que geralmente a gente faz é incluir menu, topo e rodapé no template. As páginas que usam o template, como seu index, não precisam especificar menu, topo e rodapé de novo, pois a idéia do template é justamente não deixar isso repetitivo. Então na index, você aponta pro template e só preenche o corpo dele, que o conteúdo vai ficar no lugar do <ui:insert/>, ou se você tiver dado um nome específico pra uma área dentro do template e quiser colocar algo dentro dela, coloca esse conteúdo dentro de um <ui:define name="nomeDaArea"> conteudo </ui:define>.
|
|
|
|
Isso é muito bom mesmo, pois dá mais credibilidade para Groovy e Grails. Queira ou não, muitas empresas só confiam se tiver alguém por trás para, caso precise, pagar pelo suporte e ter garantias. E até mesmo dentro da comunidade Java muita gente não acredita nessas outras linguagens em cima da JVM.
Muita gente só vai perceber que outra linguagen na JVM, como Groovy, é uma realidade o dia que ele tiver usando RoR e ouvir falar que o JRuby manda super bem.
|
|
|
|
|
|