Pular para o conteúdo principal

10 reasons why we love JSF

1. One-slide technology: it's so simple that I can explain basic JSF with one slide.
2. Easy to extend: components, listeners, render kit, Events, Controller, etc.
3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ...
4. Architecture model: you can choose between more than 100 different architecture.
5. Open-mind community: using JSF you are going to meet very interesting people.
6. We are using JSF the last 5 years and we found very good market for JSF in Brazil
7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard!
8. Many professionals now available
9. It's a standard. It's JCP. Before complain, report and help!
10. Ed Burns, spec leader, is an old Globalcode community friend!

EXTRA: My wife is specialist in JSF. She's my F1 for JSF :)

Nice job JSF community!
-Vinicius Senger

Comentários

Robson disse…
é brincadeira né?

- vc consegue explicar jsf em 1 slide?
- serio mesmo que ele é facil de estender e tal?
- vc acha que o progresso mega lento da spec realmente é "working hard"?
- e vc realmente acredita que ser uma spec oficial é melhor que outras coisas?
Unknown disse…
Vou gastar espaço no blog para brincadeira?

-Sim consigo explicar o conceito de managed bean + view em um slide. Obviamente que vc é inteligente o suficiente para entender o contexto.
-Sim é fácil de estender. Se vc acha difícil deve ter sérias dificuldades com outras coisas no Java.
- Acompanhei a spec desde seu primeiro release pessoalmente. Se vc tivesse idéia do que é unir Gavin King, Ed Burns, Kito e mais meio mundo da Web, entenderia melhor o valor do JCP.
- Sim acho que é bem melhor usar algo da spec. Simplesmente pelo fato que faço parte dela e posso colaborar com ela.

A propósito, para que mudar o JSF duas vezes por ano se as empresas só sobem a versao do JAva EE a cada quatro anos?

Quer algo que mude rápido, acompanhe a previsão do tempo.

-Vinicius
Ricardo Longa disse…
Rsss...!

Bacana o post Vinicius.
Unknown disse…
placar 1 x 1. rs.

Peço para quem for contra o JSF comentara tecnologia que usa.

Obrigado,
Vinicius
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Ricardo Longa disse…
E será que existe alguém contra o JSF para continuar este assunto (exceto o Robson, claro)? Rsss!

A propósito, será que chove hoje Robson? Haha!
Marcelo Carvalho disse…
Um pouco envergonhado pelo Róbson... mas!
Ótimo post primeira vez que passo por aqui, vou dar uma olhada nos outros artigos!
Unknown disse…
Ricardo,

A Web é muito complicada... Muita gente trabalhando com diferentes tecnologias e existem vários que realmente não gostam de JSF, mas nunca apresentam uma tecnologia concorrente que tenha todas as caracteristcas boas do JSF e algo a mais.

Da forma como foi estruturado o JSF, desvinculando implementação de interface, com várias implementações, altos progressos com AJAX, união de várias empresas e nomes, alta adoção no IDE's faz dele um projeto de muito sucesso na minha opinião.

Agora, o conceito de velocidade de mudança é diferente para cada um, em sua necessidade. Eu poderia passar o resto da minha vida vendendo aplicativos com J2EE usando Struts aqui em Ubatuba. Já no Vale do Silício não.

Alguns precisam programar para surfar, outros para viajar o mundo, outros para comprar uma casa. Os que programam por programar, fica apertando F5 esperando um novo release. Pra ficar tudo mais fácil...

Eu sinto que se ficar mais fácil do que está, eu vou começar a ficar mais burro. RS.

Viajens a parte, desculpem minha opiniões pessoais. Robson e Ricardo venham em casa que faço uma pizza para assarmos junto com os frameworks web tomando uma gelada.

[]s
Vinicius
Anônimo disse…
eu nao gosto de algumas coisas no jsf, mas que é bem produtivo é...

o amigo robson ai, poderia ter sido ao menos mais educado...
Ricardo Longa disse…
Vinicius sempre bem humorado...

Concordo com as suas opiniões, e quanto a pizza eu levo as geladas! =)

Um abraço!
Felipe Cypriano disse…
Algo que vejo muito é falar que o JSF é um padrão, e lógico que é. Mas diferente de um JPA, por exemplo, se você ficar só no padrão não vai ter quase nada é preciso escolher uma boa biblioteca de componentes JSF para ai sim ele ficar bem produtivo e essas bibliotecas não são compatíveis entre si. Isso faz com que não seja fácil trocar de implementação. O que importa aqui é que a escolha seja feita conscientemente, a pessoa tem que saber que não é porque está no JCP que tudo que você fizer é independente de fornecedor, vejo muitos que acham isso.

Eu uso atualmente Grails com ZK, to gostando muito. (Não significa que o que eu uso seja padrão e possível de ser trocado, coisa que claramente não é).
Unknown disse…
Gosto do JSF, além da questão padrão/especificação a possibilidade de utilizar "componentes prontos" agiliza bastante o desenvolvimento. São várias suites de componentes disponíveis:
- RichFaces, IceFaces, PrimeFaces, Tomahawk, Trinidad entre outros.

Eu curto a idéia de desenvolvimento baseado em componentes visuais na web, com uma arquitetura bem bolada no back-end, principalmente em aplicações corporativas.

[]'s
Eder
Também vi o JSF começar. Alias lembro da Yara Senger sendo umas das primeiras profissionais de Java a falar de JSF no Brasil.
A única coisa q a Sun prometeu e não pegou foi poder ter uma paleta de arrastar, soltar e posicionar os componentes como num Visual Studio ou num editor de Swing do NetBeans. Eles implementaram no NetBeans mas os componentes eram proprietários. Quem sabe não podem resgatar isso? Iríamos ganhar ainda mais produtividade e a arquitetura permite.

Bons códigos,

Jeff
Unknown disse…
Felipe, excelente comentário. De fato a compatibilidade entre produtores de componentes foi um assunto muito em pauta no JSF 2. O problema disso é muito semelhante ao de device drivers para sistema operacional: você depende que todos sigam um protocolo / padrão de programação que não podemos checar a incompatibilidade em compile-time, nem em um run-time específicio.

Fazendo esta analogia o problema somente seria solucionado se existisse algo como aconteceu com os drivers Microsoft: haveria um processo de certificação da biblioteca de componentes e se o desenvolvedor utilizar bibliotecas sem o certificado, perde esta garantia.

Enfim, o que não se resolve em compile-time, tem que ser resolvido com altruísmo (ai, essa denunciou que estou bebendo vinho ahahaha).

[]s
Vinicius
Glaucio disse…
Só pra ser do contra:
E como fica na hora de escolher entre as muitas implementações? Você põe a mão no fogo em qual? Citando o Eder: RichFaces, IceFaces, PrimeFaces, Tomahawk, Trinidad entre outros. É nesse momento que a casa cai numa discussão pró e contra JSF.
Anônimo disse…
Pois é Glaucio !!!!

O Core Java não é uma especificação que ainda se possa contar com tendências, até parece que nada mudou e features não são mudadas também, me parece que o Vinicius Senger parou no tempo ou ele entende especificação quando o JCP fazendo sentindo em versões e publicações das chamadas JSR.
Anônimo disse…
Por Vinicius Senger

"Felipe, excelente comentário. De fato a compatibilidade entre produtores de componentes foi um assunto muito em pauta no JSF 2. O problema disso é muito semelhante ao de device drivers para sistema operacional"

Isso é a pior análise pra se pensar em problemas, buscar fatores de implementação em vias sobre especificação de fornecedores, isso não se baseia em nada sobre outras especializações já citadas acima, algo como eu segui-se uma tecnologia a risca como um norte de verdade.

A arquitetura hoje é levada por linguagens que atendem plataformas dinamicas e sejam mais modulares, em vista disso a WEB é sim e a maior nuvem se não a maior CLOUD que vai ter fusões pra muitas midias, hipermidias e URIs de fornecedores de serviços.
Unknown disse…
Fala Glaucio!

Vc tem razão, escolher mais de uma implementação "terceira" no mesmo projeto é complicado, dependendo da situação tem que ralar bastante p/ fazer funcionar.

Agora aproveitando o gancho do Vinicius, melhorar isso foi uma preocupação da spec 314.
De certa forma demonstra a maturidade da tecnologia e a importancia da comunidade e suites de componentes, os caras "baixaram a guarda" pra problemas do dia-a-dia (que a spec ñ resolve).


[]'s
Eder
Yara Senger disse…
Poxa Anônimo, pega leve. É só um post com a opinião de uma pessoa.
Unknown disse…
>1. One-slide technology: it's so simple that I can explain basic JSF with one slide.

Não sei se concordo... acho que precisa de mais de um slide pra ensinar JSF pra alguém

> 2. Easy to extend: components, listeners, render kit, Events, Controller, etc.

Eu trocaria "Easy" por "It's possible". Definitivamente não é Easy.

> 4. Architecture model: you can choose between more than 100 different architecture.

Em quais outros frameworks web você não consegue ter diferentes tipos de arquitetura?

> 5. Open-mind community: using JSF you are going to meet very interesting people.

?

> 7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard!

Demorou vários anos pra arrumarem defeitos bem básicos... não acho o progresso do JSF algo notável
Unknown disse…
Os comentários excedem minha inteligência... Minha opinião esta ai e esqueci de citar um motivo muito muito muito especial pelo qual eu gosto de JSF: eu ganhei muito dinheiro com ele e vou continuar ganhando!!!! JSF vende que é uma beleza. AHAHAHAHAHAH.
Unknown disse…
E até agora ninguém falou o que usa. Por favor me respondam: o que é melhor que JSF e porque?

De preferência sem o anonimato...
Unknown disse…
A propósito, Felipe: eu gosto de Grails apesar de pouco ter usado... Quanto ao fato de ser ou não ser padrão, isso faz muita diferença em ambientes com mais de 100 desenvolvedores. Imagine bancos com 2.000? 10 fábricas de software de 200 aplicativos em produção. O que é melhor usar algo padrão JAva EE ou um framework de terceiro que nunca ninguém rodou em WebSphere?

Tem projetos que qq porcaria de Web resolve. Mas projetos grandes, em grandes servidores, para grandes equipes, com grande contratos o padrão faz total diferença!
Felipe Cypriano disse…
Por Vinicius Senger: "Mas projetos grandes, em grandes servidores, para grandes equipes, com grande contratos o padrão faz total diferença!"

Sim, isso seria um requisito não funcional e, normalmente, imposto por quem paga a conta. Não é, tecnicamente, um diferencial do JSF... seria um diferencial, humm, "executivo" hehehe

Eu ainda não trabalhei em projetos tão grandes, por isso tenho uma certa liberdade de escolher quais tecnologias usar. Eu já me peguei pensando se iria gostar de trabalhar num projeto grande onde eu seria obrigado a usar várias tecnologias sem motivos técnicos só porque a empresa quer.

O ideal seria que as várias aplicações falassem entre si independente da implementação assim cada projeto seria mais livre para escolher o que é melhor pra ele, todo sabemos que não existe bala de prata.
Anônimo disse…
Vinicius Senger disse...

Os comentários excedem minha inteligência... Minha opinião esta ai e esqueci de citar um motivo muito muito muito especial pelo qual eu gosto de JSF: eu ganhei muito dinheiro com ele e vou continuar ganhando!!!! JSF vende que é uma beleza. AHAHAHAHAHAH.

Resposta:
Estamos discutindo a utilidade de uma tecnologia, ao motivo especial isso é mera opinião sua.

Vinicius Senger disse...

E até agora ninguém falou o que usa. Por favor me respondam: o que é melhor que JSF e porque?

Resposta:

Spring-MVC é melhor que JSF, é mais dinâmico tem melhores especializações e não vem com aquela cara de swingão que traz o JSF.
Anônimo disse…
Vinicius Senger disse...

O ideal seria que as várias aplicações falassem entre si independente da implementação assim cada projeto seria mais livre para escolher o que é melhor pra ele, todo sabemos que não existe bala de prata.

Não existe a bala de prata, mas existe o bom design e a visão ao que hoje se atende para plataformas e frameworks funcionais e não funcionais.
O que acontece é a falta de pesquisa e investimento ou mesmo querer estar em forúm somente por uma força de marketing e vendas.
Temos tecnologias poderosas ai para o back-end e outras que tem sua responsabilidade de atender camadas e interfaces.
Mas infelizmente o que esta atrapalhando que todos evoluam é um efeito publicitário esmagador e rotulado que vem embalado "Tipo dessas opiniões chulas, eu ganhei muito dinheiro com JSF", então vamos começar ter novos horizontes e compreender o que nos espera, e na certa vem ai muita convergência e interoperabilidade, desafios novos com Restful entre novas arquitetura.
O legado existe e deve ser planejado o seu recurso para o novo e as novas tendencias da JVM.
Anônimo disse…
Sobre postar em anônimo:

Vem a questão acima, ao anônimo meus pensamentos a minha pessoa a melhor integridade.
Unknown disse…
"Spring-MVC é melhor que JSF, é mais dinâmico tem melhores especializações e não vem com aquela cara de swingão que traz o JSF."

Comparar um framework action-based com um framework component-based faz tanto sentido quanto propaganda política.

Spring MVC pode ter tais vantagens sobre Struts, Webwork, etc. A proposta e forma de implementação do JSF é completamente diferente.

Sem contar que o desenvolvimento da camada view com Spring MVC é delegada para outro framework geralmente, diferente da utilização dos componentes do próprio JSF.

Gostaria de saber também o que o pessoal tem utilizado no lugar de JSF.
Felipe Cypriano disse…
Anônimo do comentário de 10:21. Preste atenção na conversa, não foi o Vinicius que falou que não existe bala prata, foi eu, se soubesse interpretar textos ia ver que eu falei que JSF não é uma.

Spring-MVC não é um framework baseado em componentes como o JSF. E para te poupar o trabalho de entender toda a conversa eu não uso JSF, nem defendo. Uso Grails no back-end e ZK como framework de componentes.
Anônimo disse…
É Rafael,

Me peguntaram o que era melhor, e realmente não dá pra comparar mesmo Spring-MVC com o JSF, e falando em delegação para outros frameworks até com Freemarker, veja quantas soluções temos ai, mas ai vem o Papai Noel dizer que a sacola dele tá minando dinheiro... ;-)
Unknown disse…
Spring é maravilhoso mesmo! Com JSF fica melhor ainda. :)

Felipe, gostei muito dos seus comentários. Principalmente a classificação como "requisito executivo" foi muito inteligente.

Impressão minha ou as opiniões anonimas tem uma qualidade muito inferior das opiniões assinadas?

Risos.

Anonimos também são bem-vindos na minha casa para comer pizza e tomar cerveja. Ai podemos discutir futebol.
Anônimo disse…
Legal Felipe Cypriano

Uso Grails no back-end e ZK como framework de componentes."Legal que você tem uma visão, diferenciada"

Quanto a pergunta do Vinicius Senger Por favor me respondam: o que é melhor que JSF e porque?

Ele foi infeliz, ainda o Rafael tentou passar um cimento branco de mau qualidade em ter que buscar referencias ao JSF sobre Spring-MVC não dá né basta mesmo ver como as ramificações ao Spring se extendem e não dependem do Core J2EE, tem gente querendo vender elefante branco. ;-)
Unknown disse…
Core J2EE, o livro? elefante branco, cimento branco. Xii. Me deu um branco.
Anônimo disse…
Vinicius Senger

Impressão minha ou as opiniões anonimas tem uma qualidade muito inferior das opiniões assinadas?

Risos.

A minha impressão é quem advoga de opiniões a seu favor, faz isso com pessíma qualidade de observação.

Grails no back-end ? é furada tá mais pra uma engine dependente do Core Java a ser uma real full-stack.

Pior falar de implementação JSF e argumentar o que é diferente,isso é não ter senso de profundidade ao que cabe as responsabilidades e aspectos da tecnologias, isso é muito vago.

Observação, acho que estudar conceitos de User Experiencie vai dar melhor referência no que cabe trabalhar com Model View Controller.

É senger essa Pizzaria vai longe ;-)
Unknown disse…
É certeza que vai acabar em pizza! Valeu galera pela participação ativa.
Felipe Cypriano disse…
"Grails no back-end ? é furada tá mais pra uma engine dependente do Core Java a ser uma real full-stack."

A melhor parte do Grails pra mim, ser completamente integrado ao java e de forma transparente. Pude re-usar vários códigos que eu possuia ao invés de reinventar a roda.

Ele te fornece o fullstack ao juntar tecnologias e não ao fazer tudo do zero. Essa informação não fica escondida em lugar nenhum e é um trunfo dele.
Anônimo disse…
Vinicius Camarada, ai vai uma boa leitura !!!!

http://bit.ly/bSvBAb ;-) , senão tiver o JSF não tem importância é só indo aprendendo coisas novas e interessantes !!!

WHAT'S INSIDE

* Build a Java web app with the AppFuse framework and Maven
* Build a rich client with Flex 4
* Connecting to Webservices services
* Connecting to Spring, EJB3, POJOs, and others
* Flex Messaging using JMS
* Securing Flex
* Create custom Flex controls with Degrafa
* Desktop 2.0 with Adobe AIR
* Flex on Grails
* IDE Integration
Anônimo disse…
Felipe Cypriano

Ele te fornece o fullstack ao juntar tecnologias e não ao fazer tudo do zero. Essa informação não fica escondida em lugar nenhum e é um trunfo dele.

Vejamos

Você não atingi um Hyper-Treading como Scala pois groovy é produtivo dentro de uma plataforma, é tem mais escalabilidade é a palavra chave."Scala faz coisas simples serem fáceis e coisas difíceis serem possíveis".

Seu back-end precisa ser revisto. ;-)
Unknown disse…
Scala é show também. Depois que você começou a falar sobre andei lendo um pouco.

A propósito, porque não escreve um artigo de introdução a scala?

O que seria hyper-treading como scala? Não entendi.

[]s
Vinicius
Felipe disse…
Este post é um ótimo exemplo de custo baixo e benefício alto. Poucas linhas resultaram em muitos comentários. :)

Particularmente eu não gosto do JSF porque não gosto do modelo baseado em componentes para a Web. Acho que o modelo proposto pelo HTML5 com JS e CSS é o que deve ser usado para a WEB. Buscar os padrões mais usados (do W3C)é mais legal. Até porque isso te permite uma diversidade maior na escolha de tecnologias de integração.

Também não gosto do JSF porque ele dificulta o REST. (Ainda não suporta requisições GET com parâmetros ou to viajando?)

Mas respeito a opinião de quem gosta de desenvolvimento baseado em componentes e acho que dentro deste modelo o JSF é o melhor. Também concordo que grandes corporações preferem coisas assinadas. Mas eu não gosto de grandes corporações.

Para o Felipe Cypriano, Grails é Front-End e não backend. A camada MVC inteira é front-end por sinal. Isso não quer dizer que não dê pra usar Groovy no backend como o anonimo disse. Se dá pra fazer em Java, dá pra fazer com Groovy.

Scala é uma das linguages que eu mais gosto, porém ela nào simplifica as coisas, pelo contrário. Complica coisas simples. Quem já tentou converter um List que retorna de um driver JDBC para um List em Scala sabe do que eu to falando. Mas é uma boa escolha para algumas situações.

O que eu uso? Eu uso de tudo. De verdade.
Ruby, Python, Java, Scala, Groovy, Ioke, etc...
Tenho mais projetos em Java e Rails.

Pra terminar, sou a favor da escolha certa para a necessidade certa. Ponderar porque e quando usar uma tecnologia é bom. Ser xiita e defender ou criticar até a morte é errado.
Felipe disse…
Eu escrevi um artigo de introdução à scala para a revista Mundo Java. :) Já tá chegando nas bancas.
Anônimo disse…
Ops !!! Vinicius !!

Sim já tive esse pensamento, em escrever um artigo mas existe assuntos que não são visto pelo marketing então não seriam publicado.

O Termo certo é Hyper-Threanding "O que sugere melhor conceito para programação para Cloud Computing".

Na Edição 75 - Java Magazine - Scala é o tema principal.

Em nota tem uma informação sobre:Transparência referencial, pagina 37.

A Revista Java Magazine desta Edição 77 não falou sobre Closure isso foi uma falha ou algo proposital não sei, no Java 7 essa funcionalidade não fora suportava, mas qual a vantagem disso em usar ou não talvez se pergunte: Já lhe respondo a vantagem e de performance e codigo limpo.

Interessante que existe até um site que aborda vários assuntos sobre Scala é o http://javalivros.ning.com ,lá tem vários artigos e informações.

Um video que vi recentemente é o David Pollak On Lift Framework and Scala :

É Bem interessante !!!

http://www.infoq.com/interviews/Lift-Scala-David-Pollak

Mas um cara bom pra conversar e o Jonas Bonér
segue twitter @jboner

http://www.infoq.com/presentations/Scala-Jonas-Boner
Felipe Cypriano disse…
Olá Felipe,
No meu caso eu uso o Grails como backend, pois os códigos de serviço e tudo mais são feitos em groovy e usam as configurações do grails (spring por baixo) para ligar o frontend (ZK, não uso GSP nesse projeto) com os services (groovy / grails). Basicamente.

Estou para ler, assim que arrumar tempo, sobre Clojure. Quero entender melhor sobre programação funcional e não quis aprender em Scala porque ela não é só funcional. Depois que eu entender de programação funcional pura eu vejo o Scala.

Entender várias linguagens é ótimo para todos, o seu código ficar melhor em todas elas. Ruim é a pessoa agarrar em uma só e não soltar nunca mais.
Anônimo disse…
Felipe Cypriano
Ruim é a pessoa agarrar em uma só e não soltar nunca mais.

Eu estou com você nessa idéia também, por isso que temos que procurar trabalhar com linguagens que sejam Cross-Browser e Cross-VM, pois os caminhos são contextos que se integrem e altas camadas de convergencia.

Scala é back-end mas é claro que escalabilidade é tratar com elevar em compativel ao ambiente que se sugere.

Falando em diversidade,eu gosto de vários assuntos e até estou lendo algo sobre Object-C a entender aplicações para iPhone.

O que quero finalizar é que temos que fazer combinações e entendermos responsabilidade, existem interesses e estratégias ,de vendor, Players 3 letrinhas e por ai vai , mas temos que ter cultura, não ficarmos rotulados.
Felipe disse…
@Felipe Cypriano
Ah tah.. agora acho que faz mais sentido dizer que tá usando Grails no Back-end. :)
É legal isso porque já te dá um controle transactional bem legal e uma interface de Criteria bem bacana também. Fora o suporte de integration teste. Muito bom mesmo usar Grails nesse molde.
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Anônimo disse…
Olá Vinícus,
Ótimo post !

Infelizmente criou-se uma legião de críticos bem pouco colaborativos ao redor de tudo que é definido pelo JCP, parece que nada é bom. Seja JSF, EJB, JTA, CDI, JavaRepository, JAXB, etc, nada presta. Parece que ser da esquerda, tá na moda. Quando as críticas são fundamentadas, o que é difícil de se ver, acho bem válida as discussões, quando não são, não vale a pena discutir.

Minha opinião quanto a escolha do JSF como framework web é - "depende". Já falei sobre isso em alguns fóruns, mas a verdade é que tem muita coisa a ser discutida quando escolhemos a tecnologia para um projeto.

Como tbm já citei antes por aí, tome como exemplo algumas aplicações da Red Hat. O jBPM Console e o Guvnor (a GUI de gerenciamento para as regras do Drools), utilizam GWT - são aplicações de pouquíssimas páginas, com muita mudança de estado ajax, bem ao estilo Gmail. Neste contexto, o JSF e sua vastidão de componentes mais voltados para formulários, não iriam ajudar muito, a escolha mais sensata para as equipes destes projetos foi o GWT.
Isso não se repetiu com as ferramentas de gerenciamento e monitoração JOPR e JON. Ambas possuiem muitas páginas com abas, gráficos, formulários, Tree-menus, etc. O GWT além de ser mais burocrático para se desenvolver aplicações com estes requisitos, não daria os componentes que existem prontos em outras bibliotecas para formularios JSF. A tecnologia utilizada foi neste caso o JSF mesmo, nítidamente reconhecido pelos componentes Richfaces espalhados pelas páginas da aplicação. Necessidades diferentes, ferramentas diferentes.

Recentemente conversei com uma equipe onde o framework para seu novo projeto era o Struts 1.1. O projeto era pequeno e precisava ser entregue com máxima urgencia. Me perguntaram se valia a pena arriscar JSF + Seam, eu respondi "NÃO". Migrar todo o conhecimento da equipe para uma nova tecnologia, em um projeto que já esta atrasado, simplesmente por estética técnica, eu não recomendo pra ninguém. Neste caso, o skill da equipe e o prazo do projeto tbm contou para a escolha do framework, mesmo com este débito.

Abraços
Este comentário foi removido pelo autor.
Felipe Kenobi disse…
Aposto uma moedinha que o Anônimo é o Márcio Duran :-)
Anônimo disse…
Aposto duas
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Anônimo disse…
Nossa essa conversa toda meu deu fome, vou pedir uma Pizza + Coca-Cola = a uma boa ideia ;-)
Ismael Stahelin disse…
Acho que se o Vinícuis gosta de JSF e o Robson gosta de outra, cada um deveria falar bem da sua preferida, e não falar mal da outra...
No mais acho que o que valeu foi a discussão. Olha o tamanho da barra de rolagem, tá magrinha já! O importante aqui foi a colaboração.
Abraço.
Isabela Ramos disse…
Vinicius Senger,

E o Seam? O que acha dele?

Gavin King disse que JSF é interessante como um framework para camada de apresentação, principalmente pelo seu ciclo de vida de request extensível e forte modelo de componentes.
Mas e sobre os conceitos de dependency injection, Convention Over Configuration, controle do ciclo de vida dos componentes (EntityManager por exemplo).

Qual sua opinião a respeito do Seam e sobre esses conceitos que o JSF não trata.

Grato pela atenção.
Anônimo disse…
Este comentário foi removido por um administrador do blog.
Unknown disse…
JSF pode ser legal mesmo, mas não trocaria Tapestry por isso jamais. Qualquer coisa no Tapestry é mais intuitivo que JSF, o framework apresenta melhor componentização além do que já vem com diversos itens como IoC out of the box.
Acho engraçado no Brasil essa bajulação do que é "padrão JCP". Primeiro foi a persistência copiada do Hibernate, depois foram as idéias contidas no Spring copiadas para EJB3 e agora o JSF surgindo como cópia de muitos frameworks web components que já existem a anos no mercado. No começo eu idolatrava tudo que era padrão também, até descobrir que haviam coisas muito melhores por aí, e que ninguem precisa criar classes stubs para usar RMI nem implementar 5 interfaces para controlar propagação de transação. Liberte-se você também! q=]
Unknown disse…
Celio, quais os motivos técnicos e mercadológicos do Tapestry no Brasil?

No que Tapestry é melhor que até hoje não pode entrar na spec do JSF?

Cópia do hibernate? Aceitar um projeto open-source para uma especificação é algo ruim então? Acho que o maior beneficiado nisso foi o autor do Hibernate, ou existe algum processo dele contra o JCP?

Então C# é cópia do Java, que é cópia do C++ que é cópia do C, e assim por diante? não tem nenhum sentido, é dizer que injeção eletrônica é cópia de carburador..

Sobre bajular o JCP, gosto da idéia do governo brasileiro poder influenciar o JCP. Vc não?

Que tal um POST aqui sobre o Tapestry? Seria ótimo para a comunidade.

[]s
Vinicius
Anônimo disse…
É Celio concordo com você ...

Tapestry é um framework open-source (totalmente java) baseado em componentes para o desenvolvimento de aplicações Web (dinâmicas, robustas e altamente escaláveis).

Em vez de negociar com a API Servlet ou com as Ações Struts, o programador Tapestry armazena os dados do usuário em propriedades do objeto e manipula as ações deste usuário com métodos manipuladores de eventos;

Outra grande característica do Tapestry é o uso de templates de páginas HTML;
Cada página é um template HTML contendo tags do próprio HTML;

Ao contrário de páginas JSP, JSTL ou JSF, criando páginas Tapestry é relativamente fácil usar ferramentas para desenvolvimento de design Web, podendo inclusive visualizá-las num Browser sem a necessidade de um servidor web instalado.
Unknown disse…
Isabela, o Seam é fantástico e tem várias ideias inovadoras que simplificam demais o desenvolvimento para Web. Usamos bastante. O que poderia dizer que não é bom no Seam é a questão das mudanças que ocorrem a cada versão. Como fomos adotamos bem cedo, pagamos um preço alto a cada upgrade e agora é o Weld...

[]s
Vinicius
Anônimo disse…
Feliz sou eu rapaz!!

Fiz meu framework: cuspidor_dE__HtMl.php e ele é redondinho!!

Hhuahuahahhauhauh

Capaz, JSF é mto bom, pode não ser perfeito, mas tem mto recurso! E prá quem usava 1.X ele está mto mais prático na 2.0!
Unknown disse…
Mas vamos tentar responder. q=] (Mas sem revoltas, por favor xD)

Celio, quais os motivos técnicos e mercadológicos do Tapestry no Brasil?
Na empresa que trabalho se usa este framework. Você usa uma roupa pq ela tem motivos mercadologicos ? vc compra um martelo pq ele tem motivos mercadologicos ? desde quando ferramentas precisam de motivos mercadológico ? Você não quer ficar deixar a empresa na mão certo? Bem ainda não vi nenhuma empresa processando o Tapestry por deixá-la na mão.

No que Tapestry é melhor que até hoje não pode entrar na spec do JSF?
Complementando tudo que vc já pode ler do post do Anonimo (Anonimo, por favor mostre a sua cara! =D), além disso o Tapestry possui suporte a serviços de uma maneira simplificado usando IoC. O suporte a Ajax de tapestry é melhor, e isso vc pode comprovar em qualquer tutorial por aí. A componentização é mais simples para Tapestry porque qualquer componente não passa de mais um template.tml + classe.java, com nada especial (http://css.dzone.com/articles/simple-jsf-20-component-vs-tap). Possui live reloading, possui mecanismos para teste implementados diretamente no framework, etc etc etc. Isso faz de JSF uma merda? Claro que não! Mas lembro novamente a frase que coloquei no meu post: "Existem coisas melhores por aí", não falei nada além disso.
Quanto a entrar nas Specs: Hum, aqui fica complicado. Seria uma questão de influência ? No que o Seam é melhor que o Spring e pq o Spring não entrou na specs do JCP mas o Seam entrou ? Fica aí a dica.

Cópia do hibernate? Aceitar um projeto open-source para uma especificação é algo ruim então? Acho que o maior beneficiado nisso foi o autor do Hibernate, ou existe algum processo dele contra o JCP?
Pra mim é a mesma coisa que direitos autorais, vc pode usar livremente, mas cite a fonte pelo menos! A propósito a JPA é fantastica, eu adoro isso e prefiro usar JPA com eclipselink que é a implementação padrão do que com Hibernate, que bem pouco tempo atrás nem implementava 100% da spec.

Então C# é cópia do Java, que é cópia do C++ que é cópia do C, e assim por diante? não tem nenhum sentido, é dizer que injeção eletrônica é cópia de carburador..
C# tem muita diferença de Java, ja programou em C# alguma vez ? É muito mais proximo de C++ do que o próprio Java. É uma ferramenta, é bacana, é usado por pessoas por aí. Uma linguagem não é cópia da outra, é a evolução da outra, do mesmo jeito que Java um dia pode se tornar um novo cobol, e ele vai tornar-se um novo cobol. Se as evoluções não existissem ainda estariamos usando Gols farol quadrado com carburador até hoje. xP

Sobre bajular o JCP, gosto da idéia do governo brasileiro poder influenciar o JCP. Vc não?
Isso é ótimo, mostra que o Brasil está se mostrando lá fora e certamente teremos retorno sobre isso, como já temos atualmente, centenas de empresas por aí que desenvolvem e exportam software. Mas o que isso tem a ver com essa conversa toda? Eu falei alguma vez que o JCP era uma droga ? Acho que vc se equivocou novamente. O JCP tem feito avanços fantásticos, e devemos muito a eles. Você ja usou o BeansBinding que é a tecnologia para ligar interfaces Swing ? É uma droga, vc tem que escrever um monte de código e cada vez que você precisa exibir um bean diferente na tela vc tem que fazer a ligação toda novamente. É uma péssima API, e mesmo assim todos amam, porque é o Padrão JCP. E qual foi a solução encontrada pelo JCP para isso ? Temos que colocar ferramentas para fazer isso automáticamente, ou seja, cada vez mais Java está se tornando uma linguagem orientada a IDEs.

Que tal um POST aqui sobre o Tapestry? Seria ótimo para a comunidade.
Ja que você está me convidando eu farei isso com imenso prazer. Vou preparar um material, mas não se preocupe, não será um comparativo JSF-Tapestry, isso ja existe aos montes na internet e é ridículo. Mas ao invés de criticar vou tentar adicionar à comunidade.

T+ q=]
Anônimo disse…
Celio,

Bem colocado suas observações frente as indagações fora de conceito do Vinicius Senger.

Não vou postar senão anônimo mesmo porque ao que você observou sobre JCP e Spec já tem empresas consorciadas e envolvida em projetos onde as mesma já se envolve com licitações ou até fechamento sobre soluções politicamente corretas, infelizmente existe ai um cuidado porque como consultor de tecnologia da informação não posso ficar me expondo heroicamente pra não cair em desprestigio com outros leigos que são iludidos , com pseudo-especialista.

Quanto a vender acho que aqui não é o lugar pra isso, ou então muda o discurso pois esse é de péssimo emprego.

Veja ai existe aos montes informações sobre Tapestry mas o Elefante Branco já esta na sacolinha do Papai Noel, e não vai sair de lá tão cedo. ;-)
Unknown disse…
Heheheh, entendo sua posição Anonimo, muito obrigado pelo toque também. Eu não sou defensor de Tapestry também, e confesso que ele também tem limitações, e se em alguma futura versão de JSF ou outra especificação, ou outro framework se mostrar melhor pode ter certeza que vou utilizá-lo, seja padrão ou não. E também não tenho nada contra coisas padrão, JPA é a melhor API para persistência que conheço, as Collections em Java são fantásticas, Generics e Anotations para mim foram as melhores coisas que colocaram em Java até hoje, e quem fez tudo isso foi o JCP. É a primeira vez que posto alguma coisa em um forum e não esperava causar impacto, xD, mas são legais essas discussões, todos estamos aprendendo.

T+ q=]
Dênis disse…
Jsf pode acelerar o desenvolvimento dependendo se já existem componentes para o que se pretende fazer em uma página. Porém coisas que acho uma porcaria: ser statefull em um ambiente que é stateless (web). Isso como consequência ou tenho perda considerável de escalabilidade ou de performance, caso a árvore de componentes fique no lado do cliente (serialização de toda a tela, enviar toda aquela string para o servidor, o servidor processar tudo aquilo para então passar por todas as fases do jsf e retornar ao cliente toda aquela string gigantesca novamente, consumindo banda). O jsf, principalmente o Primefaces, usa o Jquery por baixo. Ou seja, posso ter telas ricas usando Jquery, css. Se decidir usar algum framework action based como Spring ou Vraptor teria muito mais escalabilidade e performance com a mesma infra-estrutura existente. Eu honestamente só usaria o JSF em uma intranet, ou em um sistema onde tenho algum controle sobre a quantidade de usuários conectados simultaneamente. Caso contrário, poderia ter sérios problemas.

Postagens mais visitadas deste blog

Compilador GWT, não se preocupe com JavaScript!

Nesse post vou escrever um pouco sobre o Compilador do Google Web Toolkit , qual é o seu papel no kit, além de algumas dicas para o dia-a-dia no desenvolvimento com a tecnologia. Como exemplo vou usar um novo Projeto Web no Eclipse criado a partir do Google Plugin   para desenvolvimento GWT e/ou App Engine, acesse aqui mais informações e download. Depois de instalar o plugin, dentro do Eclipse siga a sequência para criar o projeto: New - Others - Google - Web Application Project - Defina o nome do projeto e a estrutura raiz de pacotes - Finish. Vou adotar como nome do projeto appGWT e pacote br.com.globalcode . O plugin gera uma aplicativo pronto que permite ao usuário preencher um campo e realizar o envio ao servidor de forma assíncrona (Ajax), quando o servidor responde um Dialog é apresentado com a mensagem de retorno. Para testar a aplicação é só executar o projeto com a opção Wep Application . Veja: O GWT, como já foi comentado , adota um conceito bem interess

O que é Lógica de programação?

Este é o segundo de uma série de posts voltados aos leitores do blog que estão dando início à carreira de desenvolvimento de software. O assunto de hoje é a lógica de programação. Para ler antes: Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados A lógica de programação é um pré-requisito para quem quer se tornar um desenvolvedor de software, independente da linguagem de programação que se pretende utilizar. Mas o que é de fato a Lógica de Programação e como saber se eu tenho esse pré-requisito? A lógica de programação nada mais é do que a organização coerente das instruções do programa para que seu objetivo seja alcançado. Para criar essa organização, instruções simples do programa, como mudar o valor de uma variável ou desenhar uma imagem na tela do computador, são interconectadas a estruturas lógicas que guiam o fluxo da execução do programa. Isso é muito próximo ao que usamos em nosso cotidiano para realizar atividad

JavaMail: Enviando mensagem HTML com anexos

Introdução Depois do post "JavaMail: Enviando e-mail com Java" , que apresentava como enviar um e-mail com Java, resolvi complementar a assunto apresentando como enviar uma mensagem formatada, em HTML , e também como realizar o envio de anexos. Bibliotecas Além da biblioteca JavaMail, veja mais no post anterior , é necessário incluir o JavaBeans Activation Framework (JAF), apenas se a versão utilizada for anterior ao JSE 6.0 , que já tem o JAF incluso. O JAF está disponível em http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html , e neste download encontramos, alguns exemplos na pasta demo , documentação, incluindo javadocs, na pasta docs e a biblioteca activation.jar , que deve ser acrescentada no classpath da aplicação para versões anteriores ao JSE 6.0. Exemplo Primeiramente devemos realizar a configuração da javax.mail.Session e da javax.mail.internet.MimeMessage , estes passos podem ser vistos no post anterior . Agora vamos montar um

Dica rápida: Apagando registros duplicados no MySQL

Ola pessoal, Sei que vocês estão acostumados a ver posts meus sobre tecnologia móvel ou algo relacionado, mas hoje vou falar sobre um pequeno "truque" que usei esse final de semana com o MySQL. Eu estava desenvolvendo o lado servidor de uma nova aplicação mobile (ahh, então "tem a ver" com mobile hehe), e quando fui fazer alguns testes percebi que tinha quase 7 mil registros duplicados (!!!) na minha base de dados! Bom, o meu primeiro reflexo como programador foi pensar em fazer um "programinha" Java para buscar e deletar todos esses registros duplicados. Mas ai, resolvi tirar as teias de aranha dos neurônios e usar os vários anos de experiência que passei com SQL e criar uma query que fizesse esse trabalho todo de uma vez!! E a query ficou assim: delete from TABLE_NAME USING  TABLE_NAME, TABLE_NAME  AS  auxtable WHERE   ( NOT  TABLE_NAME.id  =  auxtable.id ) AND   ( TABLE_NAME.name  =  auxtable.name ) Explicação direta: TABLE_NAME

Saiba como programar para Arduino sem ter nenhum hardware disponível

O Arduino já é uma tecnologia muito difundida entre os amantes de tecnologia. É difícil encontrar um profissional da computação que não brincou um pouco com esta ferramenta de prototipagem ou, que gostaria de fazer isso. Porém, em alguns casos, o programador quer conhecer o arduino mas não dispõe de nenhum hardware, nem mesmo da placa. Como isso poderia ser resolvido? A primeira resposta seria aquela mais simples e direta: ir as compras. Isso pode ser feito em uma loja física ou pela internet. No meu caso, por exemplo, tive a felicidade de encontrar em um site (não me lembro qual) um kit arduino, com um conjunto de sensores e um DVD com 41 vídeo aulas. Mas digamos que o profissional não esteja passando por um bom momento financeiro, ou ainda, simplesmente não queira comprar o Arduino sem antes conhecê-lo um pouco melhor. Para a última situação também já existe uma resposta, e diga-se de passagem, uma excelente resposta. Trata-se do site 123D Circuits.io . Depois de criar seu u

Lançamento do JDK 7 no TDC2011 em São Paulo

O The Developer's Conference foi realmente um grande momento para toda comunidade de desenvolvedores, um encontro de comunidades de TI onde foi possível interagir com pessoas incríveis das comunidades .NET, PHP, Python, Cloud, Games e tantas outras. Com mais de 200 palestrantes e 25 coordenadores é difícil até citar nomes sem ser injusta. Neste post gostaria de falar um pouco sobre um acontecimento muito especial para a comunidade Java, o Lançamento mundial do JDK 7! A história toda começou há muito tempo atrás, num relacionamento construído ao longo de vários anos de atuação dos membros do SouJava, participando do JavaOne, das JSRs e muito networking. Mas, durante o último JustJava conversamos com Roger Brinkley e Bruno Souza, e tivemos a felicidade de ter o TDC2011 exatamente no dia planejado para o Lançamento Mundial do JDK7. O grande mérito foi do SouJava e do amigo Bruno Souza (JavaMan). Com a participação formal no Executive Committeé do JCP estamos ficando cada vez ma