Neste último sábado, dia 22 de Novembro, ocorreu o IV Natal Java Day, e diferentemente do ano passado, a qual participei como espectador, este ano eu tive a oportunidade de palestrar sobre o tema “Os 10 maus hábitos dos desenvolvedores JSF“.
Tenho que admitir que o evento desde ano superou o evento de 2007, foram muito mais palestras, todas de alto nível e o melhor, com temas bem diversificados. A equipe do JUG de Natal está realmente de parabéns pela organização, apoio as caravanas e pelo evento como um todo, não tenho nada do que reclamar. Simplesmente posso resumir o evento como “fantástico”.
Neste evento tive a oportunidade de conhecer diversos profissionais de vários cantos do país, profissionais como Serge Rehem, Rodrigo Rebouças, João Paulo Viragine, Igor Medeiros, sem falar que praticamente conheci toda a coordenação do evento do JavaRN JUG e mais alguns profissionais que não me recordo o nome nesse momento.
Bem, este ano a caravana que partiu daqui de Fortaleza-CE estava composta por Handerson Frota, Christiano Milfont, René Araújo, Ythalo Rossy, eu e mais alguns outros membros do CEJUG. Dentre estes, Milfont, Handerson e eu palestramos no evento, cada um com temas bem distintos e de alto nível ténico.
Sendo, segue a minha apresentação, que por sua vez poderá ser baixada no formato PDF:
Esta apresentação seria ministrada por mim e pelo Tarso Bessa [membro do CEJUG e com certeza um dos profissionais mais safos em JSF do nosso mercado], mas infelizmente ele não pôde ir ao evento, logo fiquei incubido de sozinho alertar os desenvolvedores sobre os erros mais comuns durante o desenvolvimento com a tecnologia JSF.
Enfim, gostaria de agradecer ao JavaRN JUG pela oportunidade e principalmente pelo grande evento que sem dúvida foi, e é, impagável. Parabéns a todos, espero nos vermos próximo ano em Natal com muito mais Java e aquele excelente cappuccino depois do almoço 🙂
Rafael Ponte 
Muito bacana a apresentação Rafael.
Um ponto que eu achei de especial relevância é a diferença de paradigma de trabalhar com frameworks tipo “Request-Response” (Struts, Spring MVC e outros) e de trabalhar com frameworks orientados a componentes (como JSF, Wicket e Tapestry).
A abstração introduzida pelos frameworks orientados a componentes pode ajudar bastante em alguns casos, mas te isola um pouco do “desenvolvimento web tradicional”, em que o request e o response são tratados explicitamente.
A minha percepção é de que algumas pessoas se dão melhor com um estilo, e algumas pessoas com o outro. Além disso, alguns projetos têm requisitos mais facilmente atendidos com frameworks “request-response” e outros pedem mais um framework orientado a componentes.
A melhor situação na minha opinião é conhecer de forma produtiva pelo menos uma boa opção orientada a componentes e pelo menos uma opção “request-response”. Eu particularmente tenho gostado mais de trabalhar com “request-response”, mas depois eu falo melhor sobre isso e sobre os motivos.
Parabéns pela apresentação.
[]s
Ótimo post Rafael, estou virando “fã” dos seus posts.
Algumas semanas atrás tivemos uma dor de cabeça com um bean com escopo request, daí pesquisando encontramos o componente saveState do tomahawk e o mais engraçado é que uma das frases de um dos desenvolvedores da nossa equipe foi: “Só queria algo que durasse mais que um request e menos que um session”.
Parabéns pelo blog e obrigado por compartilhar suas experiências.
Abraços,
Muito legal sobre as maus hábitos !! Parabéns Rafael !!
Há alguma informação sobre este assunto em outras línguas?
Muito boa sua apresentação. Confesso que ja cometi vários dos maus hábitos citados.
Cara, em primeiro lugar, gostaria de te parabenizar pelo blog, é de uma ajuda imensurável para todos que o visitam e possuem interesse em aprender JSF, como é o meu caso.
Bom, estou começando a mexer com esta tecnologia, e me deparei com uma coisa que não entendi na tua apresentação:
– Por que falas em não utilizar para não renderizar componentes? Peço isso pois me deparei com um caso onde preciso esconder vários campos e labels que estão em sequencia na página e, por causa disso, encapsulo-os dentro de um único que resolve todo o meu problema. Utilizar o atributo rendered em cada uma das tags seria muito mais trabalhoso.
Gostaria somente de ter uma posição tua sobre este caso. Fora isso, parabéns pelo excelente trabalho no blog!
Um abraço.
Olá Bruno,
Não há nada de errado ou ruim em se fazer isso, principalmente como você está fazendo.
Por você não ter assistido a apresentação fica muito dificil entender qual o problema com apenas alguns poucos slides, ou seja, alguns deles podem não fazer sentido para quem não esteve presente.
O problema está mais relacionado em se preocupar com o escopo dos managed beans do que a utilização do atributo “rendered” dos componentes. O que estou querendo dizer é que ter algum componente que dispare eventos (ou o componente pai deste) tendo sua visualização gerenciado, através de EL, por um managed bean de request pode trazer problemas, como por exemplo a não execução do evento e/ou o reload da pagina.
E isso é um problema muitas vezes dificil de detectar, fazendo o desenvolvedor perder horas sem saber o que fazer. Sendo, a utilização de algum framework ou componente que prolongue o escopo conversacional além do request (e se possível menor que session) é essencial.
Enfim, é um problema bem comum entre os desenvolvedores, principalmente os iniciantes ou o pessoal que vem de frameworks action-like.
Espero que tenha ficado claro.
Um abraço e obrigado pelas considerações.
Olá Rafael…
Teclo apartir de Angola(África), consegui este endereço através de um amigo que fez muito uso dos seus post.
É com enorme prazer que vi e pude ver que são Habitos ou mesmo erros que normalmente cometemos quando estamos a desenvolver um projecto virado para esta tecnologia.
Olha Rafael, eu tenho um problema e espero obter a tua humilde contribuição, é o segte: Trata-se de um sistema que está a ser desenvolvido no ambito de um progama escolar da minha universidade, nós temos que criar um ERP, como é sabido este possui vários módulos, feita a divisão dos modulos surge a preocupação de integração dos mesmos na fase final, visto que cada elemento desenvolveu o seu módulo separadamente.
O IDE que uso é o NetBeans 6.7.1 e o servidor de BD é o MySql 5.1
Um abraço,
Pascoal Morais
Oi Pascoal,
Fico feliz por suas considerações. Obrigado mesmo.
Contudo, eu não consegui entender qual o seu problema exatamente. O problema está relacionado em como integrar estes módulos? Ou seria outro.
Um abraço.
Oi Rafael!
O meu problema é exactamente em como integrar estes módulos.
Só para lembrar, o IDE é o NetBeans 6.7.1 e o Banco de Dados é o
MySql.
Um abraço,
Pascoal Morais.
Pior mau habito: Usar JSF!