Durante os treinamentos em JSF da TriadWorks, nós nos preocupamos em, juntamente com os alunos, desenvolver uma aplicação Web que explore cenários o mais próximo da realidade, trazendo diversos problemas à tona para que desta forma possamos escrever a solução mais adequada utilizando o framework. Entre estes problemas, existe um absolutamente incomodo, que é a limpeza da árvore de componentes, mais precisamente dos formulários - ocasionado pela natureza stateful da tecnologia, claro.

Há mais ou menos um mês o @DaniloMagrini pediu uma ajuda no Twitter sobre um problema que a equipe dele estava enfrentando, e o problema era justamente a limpeza da árvore de componentes. Um dos membros da equipe do Danilo, o @NeiAlcantaraJr, postou o problema no GUJ e explicou o mesmo de maneira simples e objetiva, sendo, eu acabei respondendo na própria thread.

Problema

A primeira vez que bati de frente com este problema foi por volta de 2006-2007, logo quando comecei a trabalhar com JSF e os componentes do Ajax4Jsf, e a partir daí já expliquei o mesmo inúmeras vezes na lista de discussão da #javasf - você pode encontrar as threads no histórico do grupo - porém, até hoje, não entendi o porquê de eu nunca ter blogado sobre o assunto.

Para não prolongar muito esse post tentando exemplificar como e quando o problema ocorre, eu vou pegar o gancho na thread do GUJ e somente apresentarei a solução aqui no blog - quase que um copy’n paste da minha resposta na thread, porém com mais alguns poucos detalhes.

Portanto, se você não conhece ainda o problema você pode ler o inicio da thread no GUJ. Alias, melhor ainda se você ler a thread inteira.

Mas para os preguiçosos de plantão, o resumo da novela é: nem sempre limpar os dados no managed bean é suficiente para limpar o formulário da página.

Componentes de input

Antes de irmos direto à solução, vale a pena revisarmos como os componentes de input são processados durante do ciclo de vida do faces, pois eles são um pouquinho mais complicados do que você pensa.

Os componentes de input (todos que implementam EditableValueHolder) possuem 3 (três) tipos de valores que são alterados durante o ciclo de vida de uma requisição, eles são:

1. Submitted Value
2. Local Value
3. Value Binding (aka model value)

Esses 3 valores mudam nos componentes durante o ciclo de vida da seguinte maneira:

• Quando você submete um formulário todos os inputs da página são submetidos como string (parâmetros de request) no corpo HTTP, e na APPLY REQUEST VALUES (2a fase) estes valores são setados nos seus devidos componentes de inputs como “submitted value”;
• Após isso, na fase de validação (PROCESS VALIDATIONS - 3a fase), cada componente de input tenta converter e validar seu “submitted value”, em caso de sucesso o componente define seu novo valor convertido como “local value” e seta para null seu “submitted value”, continuando assim o ciclo de vida. Em caso de erro de conversão ou validação o componente não define seu “local value” e marca o componente como inválido, que por fim pula para última fase (RENDER RESPONSE);
• Se não houver erro na fase de validação o ciclo de vida continua na UPDATE MODEL VALUES para popular o modelo (managed bean, entidades etc), ou seja, o “model value”. Para cada componente de input setado no modelo o seu “local value” é setado para null, daí o ciclo passa pela fase INVOKE APPLICATION e termina na RENDER RESPONSE exibindo os valores do modelo (através das EL’s);

Entre tantos benefícios dessa abordagem apareceram alguns problemas que também não estávamos acostumados a lidar, como saber o que enviar e repintar antes de uma requisição Ajax, ou saber limpar um formulário adequadamente quando necessário ou mesmo repintar determinados componentes de exibição dinâmica.

Pegando este último problema como tema deste post, o que eu tenho notado é que ainda hoje em dia ele é um dos problemas mais comuns de acontecer e ao mesmo tempo um dos mais discutidos em fóruns e listas de discussão. Sendo, nada mais justo do que explana-lo aqui no blog e facilitar a vida de muitos, assim como a minha.

Problema

Este problema, que muitos ainda desconhecem, é comumente conhecido como “problema do rendered dinâmico” (bem, ao menos é como eu o chamo!) e só acontece quando trabalhamos com JSF e Ajax - independente do conjunto de componentes - mais especificamente após tentarmos repintar (ou rerenderizar, como você queira chamar) um componente com o atributo rendered dinâmico, como este:

Este componente poderia ser repintado após algum evento Ajax disparado pelo usuário na tela, como por exemplo ao selecionar o tipo de cadastro entre pessoa física ou jurídica, algo similar a isto:

Aparentemente não há qualquer problema com os trechos de código acima, principalmente se o componente iniciar visível para o usuário (ou seja, a EL ${myBean.pessoaFisica} do rendered estiver sendo avaliada para true).

Após mudar para o tipo pessoa jurídica é disparado um evento Ajax, o componente é repintado e desaparece da tela, como era de se esperar, claro. Contudo se você alterar a opção para o tipo pessoa física o componente não reaparecerá para o usuário. E é aí onde está o problema!

Se você for esperto, após alguns minutos analisando o problema, notará que a requisição Ajax foi disparada pelo componente tipoDePessoa (Firebug, plugin para Firefox, pode te ajudar aqui), o estado do managed bean foi alterado e o ciclo de vida do Faces foi processado sem qualquer erro.

E a partir daí, depois de refazer e analisar todos os passos básicos e sensatos, perde-se inúmeras horas tentando descobrir onde está de fato o problema neste simples cenário. A primeira vista parece ser um bug do JSF ou do conjunto de componentes, mas na verdade não é.

Solução

Sendo direto e sem rodeios: você não pode rerenderizar um componente na qual possua o atributo rendered dinâmico, ou seja, o componente não pode possuir EL para definir seu estado de visibilidade para o usuário.

Para resolver isso, repinte o componente parent do componente que possui o rendered dinâmico. Lembrando que este componente parent não pode ter o atributo rendered dinâmico, ou seja, ele sempre precisa ser renderizado.

Componentes como a4j:outputPanel ou mesmo h:panelGroup são excelentes componentes para servirem como componente parent. Sabendo disto, o código apropriado seria algo como:

E o componente responsável pelo evento Ajax deve repintar, no caso acima, o a4j:outputPanel (componente parent sem rendered dinâmico) e não mais o h:panelGroup.

Entendendo o problema

Para quem ainda não sabe, o atributo rendered (que por padrão é true) dos componentes é responsável por tornar o componente visível ou não para o usuário, ou seja, sempre que este atributo for true o componente poderá gerar código XHTML para ser exibido na página. Caso ele seja false, normalmente, nenhum código XHTML é gerado. Vale lembrar que mesmo o rendered sendo false o componente ainda existe na árvore de componentes no lado servidor.

Não é interessante tentar rerenderizar um componente com rendered dinâmico pois quando o atributo rendered é avaliado para false o componente (código XHTML na verdade) não aparece na árvore DOM da página. Sendo, após repintar este mesmo componente (agora com rendered avaliado para true) o código JavaScript do Richfaces responsável por atualizar o bloco de código onde se encontraria o componente na árvore DOM não consegue achar a posição exata para repintar na página (para injetar o novo código XHTML), já que o código XHTML do componente não existe mais. Então, no final, o Javascript do Richfaces acaba simplesmente não fazendo nada.

Por isso, quando você repinta um componente parent qualquer (que sempre tem o atributo rendered avaliado para true) o Richfaces consegue encontrar a posição exata deste componente na página e injetar o novo código XHTML, e como o componente com rendered dinâmico é um nó (filho) do componente parent ele também é repintado.

Concluindo

O problema é simples e a solução mais simples ainda! Nada como ler a documentação do seu conjunto de componentes favorito para entender e evitar este problema. Vale salientar que este problema ocorre com praticamente todos os conjuntos de componentes Ajax.

Acho que para um assunto simples como este eu falei mais do que devia. Espero que tenha ficado claro ou ao menos tenha dado uma luz para quem está enfrentando essa dor de cabeça. Caso queria saber mais sobre o assunto você poderá consultar a documentação do Richfaces, mais especificamente os tópicos 5.5 e 5.6.1.

Enfim, estou feliz por ter tirado mais um post antigo da minha lista de drafts! Atualmente minha rotina diária não tem me permitido investir o tempo que eu gostaria para blogar, mas cá estamos nós novamente, certo?

Esta será a 5ª  edição deste evento iitinerante, que já passou por Brasília, Salvador, Fortaleza e Belém. O objetivo do Maré de Agillidades é disseminar o conhecimento de metodologias ágeis de desenvolvimento, promover networking, criar parcerias, fortalecer a empregabilidade e gerar negócios. Os mini-cursos, workshops e palestras serão ministrados nos dias 20 e 21 na unidade Pitágoras do Bairro Cidade Jardim (Rua Madalena Sofia, 30, no Shopping Jardim, e no dia 22, no pólo presencial da Unopar virtual, na Avenida Alfredo Camaratti, 121 – Pampulha.

Responsabilidade Social

Esta 5ª edição do Maré de Agilidade vai doar toda da renda obtida com as inscrições do evento (descontadas as despesas) para o Centro Espírita Bezerra de Menezes, de Pedro Leopoldo (MG), em homenagem ao centenário de nascimento de Chico Xavier.

Fundado em junho de 1962, a entidade presta vários serviços de utilidade pública para populações carentes da cidade mineira de Pedro Leopoldo (MG), como assistência odontológica, alimentação, distribuição de agasalhos, cestas básicas, entre vários outros benefícios.

Streaming

Quem se inscrever no streamming terá acesso privilegiado aos seguintes conteúdos:

• Pedro Valente – Yahoo – Product Owner na prática
• Rodrigo Yoshima – Aspercom – Implantando Scrum - experiências de um Agile Coach
• Guilherme Silveira – Caelum – Deploy Contínuo: pois integração contínua não basta
• Heitor Horiz – AdaptWorks – Planejamento e estimativas em projetos ágeis.
• Carlos Barbieri – Fumsoft – MPS.BR com metodologias ágeis
• Alexadre Gomes – Sea Tecnologia – Escolhas 2.0
• Manoel Pimentel – Stefanini – Coaching e Facilitação de equipes ágeis
• Renato Willi – Sea Tecnologia – Agilidade e Licitações

Para quem não foi ágil o bastante e ainda quer participar desta onda, não perca esta segunda oportunidade e inscreva-se no streaming ou junte-se ao pólo de transmissão mais perto de você. Mais informações no site: www.maredeagilidade.com.br.

Assim como no ano passado, eu irei participar do evento. No entanto, este ano eu, juntamente com um amigo, submetemos um trabalho, que por sua vez foi aprovado. Então nós dois estaremos ministrando uma palestra nesta edição do evento.

A palestra será “Os 10 maus hábitos dos desenvolvedores JSF“, e será apresentada por mim e pelo Tarso Bessa no último dia do evento, quinta-feira, dia 17, às 13:00h.

Um resumo da palestra pode ser visto logo abaixo:

Serão apresentadas 10 discussões sobre os maus hábitos mais comuns entre os desenvolvedores JSF, hábitos encontrados não somente entre iniciantes, mas também entre alguns desenvolvedores mais experientes, e por sua vez serão apresentadas soluções para cada um deles.

O conteúdo da apresentação será bem objetiva e simples. Muitos dos maus hábitos apresentados serão reconhecidos por alguns profissionais, e provavelmente as soluções propostas por nós para cada um deles. O mais interessante mesmo são as discussões e questionamentos durante a palestra sobre cada mau hábito, discussões estas que agregam grande valor a apresentação.

Enfim, eventos como o Just Java são muito bons pela excelente grade de palestras técnicas e principalmente pelo networking que acabamos fazendo durante o evento. Tenho certeza que este evento irá superar os anteriores em vários aspectos.

Espero ver muitos amigos e profissionais que conheço apenas de listas e fóruns de discussão, e se possível trocar algumas idéias com cada um deles.

Para ver a grade do evento:
http://grade.justjava.com.br/

Para maiores informações sobre o evento:
http://www.sucesusp.org.br/eventos2009/justjava/

No início era só mais um “observer” entre tantos, apenas lia as threads que ali rolavam e por poucas vezes postei algo ou até mesmo respondi alguma dúvida. Na época meu conhecimento ainda era muito limitado, e minha timidez e baixa-estima não me permitiam colaborar com o grupo.

Aos poucos fui (re)conhencendo certos nomes, membros que postavam e ajudavam bastante com o grupo. Ficava claro quem realmente tinha alguma estima pelo grupo. Ficava claro quem realmente eram os verdadeiros formadores de opinião no grupo e mais ainda, porque eles realmente tinham o respeito merecido na lista.

Graças aos poucos eventos da época e a estas pessoas eu, sem perceber, me envolvi com o grupo. Passei a participar ativamente da lista, a fazer questão de ir aos eventos e principalmente divulga-los em outras listas de discussão, instituições e empresas.

Estava mais que óbvio que o grupo, CEJUG, se tornara algo importante no meu dia-a-dia, e principalmente era importante para o nosso mercado de trabalho, aqui em Fortaleza. Cada dia mais eu passei a me dedicar de alguma maneira para grupo, e foi daí que, depois de algum tempo, tive a oportunidade e o privilégio de ajudar o grupo de uma forma mais direta: minha primeira palestra no CEJUG.

Houveram muitos altos e baixos no grupo, tenho o orgulho de dizer que participei da maioria deles. Fiz muitos amigos, e até mesmo alguns poucos “inimigos”. Mas tudo que houve agregou valor a minha vida profissional e como pessoa.

Café com Tapioca

Hoje, depois de quase 5 anos caminhando junto com o grupo, eu tenho o prazer de anunciar que no dia 19 de Setembro irá ocorrer o Café com Tapioca do 7º Aniversário do CEJUG.

Assim como nos eventos de aniversário anteriores, este será um grande evento para o nosso mercado e trará grandes nomes nacionais e locais. Alias, o número de palestras, e o próprio evento em si, está bem maior que nos anos anteriores.

Teremos 7 palestras sobre vários assuntos técnicos, desde TDD, JME, frameworks web, até metodologias ágeis. Todos os assuntos estão diretamente relacionados ao atual cenário do nosso mercado. Vale ressaltar que as palestras serão ministradas por Paulo Silveira, Rodrigo Yoshima, Jeveaux, Bruno Pereira, Tarso Bessa, eu, Régis Melo e Victor Oliveira.

Com toda certeza este será um evento que marcará, com Java, o ano de 2009 no Ceará. Um dia inteiro de palestras, networking com grandes profissionais, brindes (quem não gosta!) e muita troca de informações sobre a plataforma Java. Vale muito a pena sair de casa neste sábado, dia 19 de Setembro, e investir seu tempo neste evento.

Espero encontrar todos lá, se não a maioria dos profissionais e estudantes membros dos CEJUG no evento. Até o dia 19.

Sim, eu estou falando dos, já muito conhecidos, managed beans. Eles são os responsáveis por intermediar a comunicação entre nossas páginas e o nosso modelo. Até aí tudo bem, não existe qualquer mistério, basta entender um pouco sobre MVC que isso torna-se óbvio.

Se você observar, quando está trabalhando com JSF, notará que cerca de 50-70% do seu esforço é dedicado na implementaçao do managed bean. E que as futuras alterações e correções de bugs estão intimamente ligados a ele. Implementar corretamente um managed bean pode evitar muita dor de cabeça e facilitar na manutenção da aplicação.

Mas você já se perguntou como e qual seria a melhor forma de implementá-los? Não que exista apenas uma única maneira de escreve-los, longe disso, mas em contra partida existem inúmeras maneiras de torna-los realmente ruins.

Escrever um managed bean de forma porca incorreta pode dificultar e muito sua vida e da sua equipe. Falta de legibilidade, dificuldade para escrever testes de unidade e principalmente medo de alterar o código são apenas alguns dos possíveis problemas.

Agora pare e imagine a vida do próximo desenvolvedor que deverá manter tal código. É, não parece algo divertido.

Managed Beans mais responsáveis

A principal responsabilidade de um managed bean é intermediar a comunicação entre as páginas (componentes do JSF) e nosso modelo. Escutar eventos, processa-los e delegar para a camada de negócios são apenas algumas de suas responsabilidades.

Talvez devido a experiência com frameworks action-based muitos desenvolvedores acabam subutilizando os managed beans e sobrecarregando as páginas com lógicas e dados desnecessários. Os managed beans e as páginas usam a abusam do modelo “pull” durante a renderização e (re)construção da árvore de componentes, isto é, basicamente as páginas é quem decidem (através de EL) quais os dados e lógica necessária para que possam ser processadas.

Graças a este modelo nós conseguimos retirar toda lógica de renderização da página e colocando-a onde jamais deveria ter saído, no managed bean. Esta lógica estará localizada nos métodos públicos do managed bean que serão acessados através de EL pela página.

Não importa se a lógica é simples ou complexa, é quase que mandatório que ela esteja localizada no seu managed bean. Então bizarrices lógicas de apresentação nas páginas, que não são difíceis de se encontrar por aí, como esta deveriam ser evitadas:

<h:panelGrid id="pnl" rendered="#{loginBean.usuario.admin == 1 or loginBean.permissao('exibir_painel_de_usuarios')}" />
	...
</h:panelGrid>

Reparem que a lógica de apresentação está, representada através de EL, na página. Se você teve a infelicidade de encontrar códigos assim então há grandes possibilidades de você também encontrar regras de negócio nas páginas, o que é muito pior que encontra-las no controller.

E olha que este foi apenas um exemplo simples e ligeiramente legível, já encontrei códigos mais complicados que este de dificil leitura e horrível de dar manutenção.

O problema disso é se houver a necessidade de mudar a regra (o que muitas vezes ocorre), mas e se ela estiver duplicada por dezenas de páginas, como você faria? Como testa-la? Pense um pouco sobre isso.

Imaginem um código um pouco pior que este (com 3 ou 4 condicionais), mas dentro de um componente de iteração (como h:dataTable ou ui:repeat). É, você nem vai querer imaginar.

A regra de visualização acima deveria está encapsulada no managed bean, a página não deveria conhecer a regra, mas apenas quem a conhece. Então pensando nisso nós poderíamos alterar nosso código para algo melhor, algo como isto:

<h:panelGrid id="pnl" rendered="#{loginBean.permitidoExibirPainelDeUsuariosLogados}" />
	...
</h:panelGrid>

O componente não conhece a regra, mas sabe exatamente a quem perguntar. O código está bem mais legível pois revela sua intenção. Agora está bem mais fácil mudar a regra (pois temos apenas um único ponto de manutenção) e principalmente testa-la através de testes automatizados.

Um managed bean deveria ao máximo tentar esconder a complexidade das páginas através de métodos que revelem a devida intenção, ou seja, a nomenclatura dos métodos é realmente importante e você deveria dar importância a legibilidade do seu código.

Comunicação entre managed beans

O que eu tenho para falar, de longe, se iguala ao que pode ser encontrado no excelente conteúdo sobre comunicação no JSF neste post no blog do BalusC, além de que para mim ele aborda 99% sobre como managed beans podem se comunicar.

O que pretendo falar está mais relacionado em como manter uma conversa (troca de mensagens) saudável entre managed beans. Em como explicitar os parâmetros esperados e como passar parâmetros de um managed bean para outro de maneira coerente.

A comunicacão entre managed beans não difere da troca de mensagens entre componentes de software na orientação a objetos. Cada componente (managed bean) conhece a interface pública do outro componente para que eles possam trocar mensagens.

Sendo, ter esta interface pública bem definida pode facilitar muito a “conversa” entre os managed beans, facilitar os testes, evitar problemas inesperados, diminuir o acoplamento, aumentar a coesão e assegurar contratos e invariantes do componente.

Nada mais claro que um exemplo para assimilar a idéia:

<h:dataTable var="item" value="#{compraBean.itensNoCarrinho}">
    <h:column>
        <h:commandLink value="detalhe" action="#{itemBean.exibirDetalhesDoItem}">
            <f:setPropertyActionListener value="#{item}" target="#{itemBean.itemSelecionado}" />
        </h:commandLink>
    </h:column>
</h:dataTable>

O código acima não tem nada de errado ou anormal, nada do que não estejamos acostumados a ver quase todos os dias. Se repararem há um pequeno “dialogo” entre dois managed beans - compraBean e itemBean - que estão trocando informações.

O problema não está na comunicação em si, pois isso teria que acontecer de um jeito ou de outro, mas sim em como eles se comunicam. O managed bean compraBean conhece detalhes de como o itemBean se comporta, ou seja, ele sabe mais do que o necessário.

Um maneira de melhorar isso seria ter uma interface pública bem definida no itemBean. Algo semelhante ao código abaixo:

<h:dataTable var="item" value="#{compraBean.itensNoCarrinho}">
    <h:column>
        <h:commandLink value="detalhe" action="#{itemBean.exibirDetalhesDoItem(item)}" />
    </h:column>
</h:dataTable>

Além de todos os benefícios (baixo acoplamento, alta coesão etc) citados acima, nós ganharíamos de cara maior legibilidade no código, o que é algo realmente importante quando a comunicação foge do trivial.

Vale ressaltar que independente da comunicação ocorrer na página (por meio da JBoss-EL) ou diretamente dentro do managed bean, essa abordagem poderia -e até deveria- ser utilizada. Para o segundo caso, frameworks como JBoss Seam ou Spring ajudam a injetar as dependências de maneira simples através de anotações.

Um ou vários managed beans?

Não tenho uma opinião realmente formada quanto a isso, ainda não. Já pensei várias vezes sobre o assunto, e sempre me pego vislumbrando cenários nada comuns. Que no caso os considero como casos excepcionais.

Desde 2006 eu trabalho com JSF, ministro cursos e treinamentos e presto consultoria para algumas empresas. E posso dizer que somente três vezes eu precisei ter mais de um managed bean para resolver uma tarefa. Dentre todas eu tenho a ligeira impressão que segui o caminho errado mais complicado, e que se tivesse pensado mais um pouco eu poderia ter evitado tais soluções.

Managed beans são componentes, em sua grande maioria, intimamente ligados a(s) página(s) e que deveriam ter apenas o estritamente necessário para representar a GUI. Dificilmente você terá um managed bean genérico (CRUD não conta) que poderia funcionar em todo lugar. Você precisa fazer um esforço hercúleo para conseguir isso, e as vezes parece que não vale a pena.

A idéia de um managed bean ter dados (entrada pelo usuário e estados) e comportamentos (eventos e regras ligadas a apresentação) juntos segue o princípio básico da OOP, o que torna o trabalho mais simples e coeso. Tentar ir contra isso (ao estilo ActionForm e Action do Struts) pode te trazer muita dor de cabeça a médio-longo prazo.

Neste post do Neil Griffin, um dos autores do primeiro livro de JSF2.0, ele sugere alguns “rótulos” para os diversos tipos de managed beans que podem haver numa aplicação, e ainda por cima ele incita que seria uma boa prática trabalhar com vários managed beans por questões de SoC, baixo acomplamento etc.

De fato, devido ao modelo “pull” podemos ter managed beans atuando como componentes menores, mais reutilizáveis e mais orientados a objetos. Ter componentes (managed beans ou não) de granularidade fina colaborando para construção da página é algo bastante comum, e eu mesmo me utilizo muito disso. Mas não são destes tipos de componentes que falo, muito menos o Neil.

Eu, particularmente, não concordo com quase nada no post do Neil. Para mim ele se utilizou de argumentos isolados e vagos para defender sua idéia. Managed beans por sua natureza deveriam ser simples, contudo a abordagem do Neil, definifitivamente, vai contra tudo isso. Eu a considero um overkill, e ela torna qualquer aplicação web difícil de manter.

Bem, se dois ou mais managed beans relacionados -delimitados a um contexto- estão servindo para você e sua equipe, ótimo. Continue assim, não tem porque mudar. O framework (JSF) te permite isso, contudo eu tenho sérias dúvidas se essa abordagem vale a pena.

Conclusão

Este post estava em draft faz um bocado de tempo, mas a falta de tempo e a coragem não me permitiam finaliza-lo. Felizmente resolvi tira-lo do baú e posta-lo.

Tudo que comentei aqui está mais ligado a minha experiência e o que aprendi durante estes anos como desenvolvedor (e conversando com outros profissionais) do que eu pude encontrar em livros de JSF sobre o assunto. Existem muitos livros bons, assim como artigos em blogs e sites especializados sobre o assunto, mas nada melhor que a experiência do dia a dia para nos mostrar caminhos mais adequados de como solucionar determinados problemas.

Por mais longo que o post tenha ficado, eu ainda sinto que falta complementa-lo em alguns aspectos e pontos. Pois o que falei acima acaba te levando a aderir outras soluções não menos importantes, mas que já foram bastante citadas neste blog e discutidas em listas de discussão.

Entre os três tópicos abordados aqui eu ainda tenho algumas dúvidas quanto ao último, principalmente depois desta resposta do @edburns a minha pergunta no Twitter. Hoje minha opinião está mais para o lado “um managed bean é suficiente” por não ter encontrado respostas que me convencessem do contrário.

Enfim, como disse antes, se vários managed beans intrinsecamente relacionados estão resolvendo teu problema por algum motivo, ótimo! Continue assim. Se você tiver um tempinho e puder comentar sobre tua decisão eu ficaria grato.

Todo design pattern existe para resolver um problema comum de software, e não apenas para ser utilizado como uma receita de bolo em qualquer projeto. E com DAO não seria diferente. A finalidade do DAO é prover uma interface com operações para acesso a dados que abstraiam os detalhes do mecanismo de persistência (seja um banco de dados, ou não), ponto final.

Sua utilização há alguns 5 ou 6 anos atrás fazia todo sentido pois naquela época ainda erámos obrigados a trabalhar com JDBC puro e frameworks de persitência bem precários. Isto é, não tinhamos bons frameworks que abstraíssem de maneira satisfatória o acesso aos dados da aplicação (99% das vezes um banco de dados).

Por isso todo projeto de software daquela época implementava seu próprio DAO para evitar a mistura de código de negócios com código SQL (e mais alguns objetos de persistência), e assim diminuir o acoplamento entre as camadas (layers).

O problema é que hoje em dia com todos os consagrados frameworks para persistência ainda temos arquitetos implementando seu próprio DAO em todo e qualquer projeto de software que eles ponham as mãos. Mesmo que na arquitetura tenha-se adotado algum framework ORM (como JPA ou Hibernate) ainda assim temos os benditos DAO’s espalhados pela aplicação.

Sempre que vejo um projeto que adotou algum ORM (muitas vezes JPA) para persistência e me deparo com o famigerado DAO eu pergunto para o arquiteto da solução qual motivo o levou a colocar uma layer a mais na aplicação sobre o JPA. E como sempre recebo a seguinte resposta:

“Ah! para abstrair a camada de persistência. Assim se futuramente for necessário mudar de JPA para qualquer outra tecnologia, como JDBC puro, vai ser bem simples, pois bastaria criarmos outra implementação.”

Este tipo de argumento demonstra puro e simplesmente senso comum. Arquitetos que pensam assim pararam no tempo e não acompanharam a evolução das tecnologias ORM para plataforma Java. Outros mesmo atualizados seguem o senso comum. Pois é muito mais cômodo e simples para estas pessoas repetirem sempre a mesma “solução” em cada novo projeto do que se manterem atualizadas e avaliarem outras possíveis soluções.

O mais interessante disso tudo é que basicamente foi criada outra camada genérica para abstrair algo que por si só já é nossa abstração. O que estou querendo dizer, e que certamente foge ao senso comum, é que você não precisa de outra camada, o JPA já abstrai a persistência para você, ele além de muitas outras coisas já está atuando como nossa DAO layer.

A partir do momento que um arquiteto cria esta camada genérica ele está abrindo mão de features importantes de qualquer framework para persistência que ele venha a adotar. Todos os frameworks de persistência seguem filosofias e possuem features diferentes que agregam valor ao software de uma maneira ou de outra, mas que por termos esta camada de abstração não poderemos utiliza-las, caso contrário estaríamos detonando com a “portabilidade” da camada.

Quando adotamos um framework ORM como o JPA/Hibernate, não importa o motivo, já temos que ter em mente que nossa aplicação (principalmente o domain model) estará “mergulhada” nas features do framework, como anotações, contexto de persistência, lazy loading, dirty checking etc. Simplesmente mudar a implementação do DAO -como muitos acreditam- não garantirá que nossa aplicação continuará funcionando.

Ter esta camada extra de abstração (seu próprio DAO) pode matar o que de melhor seu framework ORM pode te oferecer, já que sua aplicação deverá funcionar independente da implementação utilizada. Por isso reflita se é melhor ter um full-ORM com um half-DAO do que ter um switchable-DAO com um half-ORM. Eu, particularmente, prefiro um full-ORM.

Antes que algum fanático por DAO venha aqui me crucificar, eu não tenho nada contra DAO layers, assim como também não acho que JPA tenha vindo para mata-lo. Mas acredito que este design pattern tem o seu lugar e deveria ser utilizado adequadamente, e não como uma camada obrigatória na aplicação.

Não existe uma receita de bolo para quando utilizar seu DAO genérico particular ou não. Cada projeto tem suas peculiaridades e estas devem ser analisadas com seus devidos cuidados. Mesmo eu achando que hoje em dia (a não ser que você esteja implementando o framework caseiro da sua empresa) não precisamos de tanta preocupação quanto a isso.

Para o caso especifico do JPA, utilize diretamente o EntityManager no lugar da sua abstraçao de DAO genérica, principalmente se você estiver implementando CRUDs, e utilize DAO’s onde for realmente necessário e fizer sentido. Bem mais simples, e bem menos artefatos na tua aplicação para manter.

Enfim, esse tipo de discussão sobre abstrair um framework ORM com uma camada DAO não vem de hoje, datam de meados de 2005 ou até menos. Meu conselho é que você não crie uma camada a mais para tentar abstrair o que por si só já é sua abstração. Trabalhe com o que o framework ORM te fornece, de preferência da melhor forma possível.

Eles não irão colaborar entre si para definir a identidade visual da aplicação [não que não seja possível], mas sim para acertarem os detalhes “baixo nível” da interface ou mesmo como definir melhor a experiência do usuário. No final das contas, eles podem discutir sobre css, javascript, tags de marcação XHTML ou uma melhor disposição dos componentes visuais.

E isso é comum com qualquer tecnologia para web, seja ela PHP, RubyOnRails, .Net ou mesmo Java.

Mas o que eu realmente não entendo é porque muitos profissionais (desenvolvedores, gerentes, designers etc) encaram que desenvolvedor e designer não precisam -ou mesmo não deveriam- discutir sobre o design da interface da aplicação.

O que difere a comunicação entre um desenvolvedor e um analista de negócios que tentam definir ou acertar detalhes sobre o modelo de domínio da aplicação, e a comunicação entre um desenvolvedor (ou analista) e um designer que tentam acertar detalhes da interface com o usuário?

Nenhuma! Não há qualquer diferença, eles conversam e colaboram entre si com a mesma finalidade: terem software funcionando e que agregue valor ao cliente.

O que leva tantos profissionais a pensarem que desenvolvedor e designer são “peças” isoladas durante o desenvolvimento do software? Um modelo em cascata, talvez. Por estarem trabalhando num processo fabril de fábrica de software, talvez.

Não sei ao certo o motivo, mas sei que uma boa parte da culpa está na “balela” que algumas empresas-de-três-letrinhas tentam empurrar sobre seus clientes e/ou desenvolvedores que utilizam suas tecnologias/ferramentas. Um bom exemplo disso é a tecnologia JSF, na qual temos a descrição abaixo dada pela Sun:

Ease-of-use being the primary goal, the JavaServer Faces architecture clearly defines a separation between application logic and presentation while making it easy to connect the presentation layer to the application code. This design enables each member of a web application development team to focus on his or her piece of the development process, and it also provides a simple programming model to link the pieces together. For example, web page developers with no programming expertise can use JavaServer Faces UI component tags to link to application code from within a web page without writing any scripts.

Por mais bonito que isto pareça ser, eu tenho o dever de alertar aos mais desavisados: isso dificilmente irá funcionar durante o desenvolvimento com JSF - para falar a verdade, eu acho muito dificil que qualquer tecnologia hoje em dia consiga prover tamanha separação de responsabilidade (entre designer e desenvolvedor) de forma transparente e produtiva.

Qualquer desenvolvedor web que se preze possui, ao menos, os conhecimentos mínimos sobre XHTML, css e javascript para entender e manter algum código escrito por outra pessoa ou mesmo por um web designer. Se você é um desenvolvedor web e não possui qualquer conhecimento sobre o que eu disse acima então já está mais do que na hora de você aprender.

Não subestimando os designers, pois eu conheço alguns muito bons, mas se levássemos essa separação de responsabilidades ao pé da letra você acha mesmo que eles conseguiriam desenhar excelentes interfaces utilizando apenas as taglibs dos componentes ou conjuntos de componentes JSF?

Alias, você acha mesmo que um designer teria produtividade ou conseguiria expressar sua criatividade limitado apenas a algumas dezenas de tags, por mais ricos que sejam os componentes, visualmente falando? Isso pode piorar ainda mais se este designer for obrigado a utilizar algum editor -com o qual ele nunca trabalhou- apenas por causa do suporte a code-completion para as tags dos componentes.

JSF é uma boa tecnologia, e por mais que ela nos forneça centenas de componentes, frameworks para templating de páginas e estes componentes possuam um sistema de skinning ainda assim no final das contas teremos XHTML (css e javascript também) gerado. Sendo, de duas, uma: ou o designer deve ter conhecimento sobre o código gerado pelos componentes ou ele deve ter conhecimento de como trabalhar com o suporte a skinnking dos componentes.

Qualquer que seja a opção acima, o designer estará com mais responsabilidades do que o necessário. Por isso é tão importante a interação entre um designer e um desenvolvedor para solucionar problemas decorrentes da tecnologia adotada.

Eu falo tudo isso por experiência própria, pois há alguns meses eu tive uma razoável dificuldade para aplicar o css, definido no prótotipo do sistema, nos componentes JSF da aplicação, atividade esta que deveria ser relativamente simples. Sim, o conjunto de componentes que eu utilizei suportava skinning, mas quem disse que isso é suficiente quando o XHTML gerado por alguns componentes mais complexos é totalmente diferente do XHTML escrito pelo designer?

Foram vários dias adaptando o css da aplicação e, ao mesmo tempo, discutindo e redefinindo com os designers alguns pontos do css do prótotipo para que no final tivessemos o resultado ideal. E com certeza eu não teria sucesso nesta atividade se não fosse pelos dois grandes designers da equipe, Carlinhos e Anderson, que sentaram ao meu lado algumas longas horas durante a semana para me ajudar.

Certamente que há casos onde não podemos contar com um designer na equipe, como:

• projetos em que a presença do designer é inexistente na equipe e algum desenvolvedor precisa assumir mais este papel;
• o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;
• ou nos piores casos, o protótipo da aplicação foi criado por outra empresa.

Para cada situação é possível chegarmos a uma solução milhares de vezes melhor do que apenas ignorar o problema de que não há um designer na equipe - mas não é esta a questão do post.

Enfim, é muita ingenuidade (ou falta de conhecimento) destas pessoas que acreditam que desenvolvedores e designers [ou quaisquer membros da equipe] não precisam colaborar entre si para alcançar um resultado ideal que agrade o cliente.

Não é de hoje que percebo que a maioria das dúvidas postadas sobre JSF em listas de discussão e fóruns estão intimamente ligadas a falta de conhecimento base sobre a tecnologia ou mesmo sobre os conceitos na qual o framework (JSF) foi construído - sim, estou falando de conceitos sobre desenvolvimento web e component-based.

É óbvio que JSF existe para tentar abstrair toda a complexidade existente no desenvolvimento web Java, complexidade esta que deveríamos evitar, mas é indispensável termos o mínimo de conhecimento sobre a mesma. Pois se você acha que apenas conhecendo os componentes você construirá uma aplicação decente então você está enganado.

Assusto-me com o número de dúvidas na javasf em que o mínimo de conhecimento sobre web seria suficiente para solucionar o problema, independente do framework utilizado. Evidente que muitas das dúvidas estão ligadas a tecnologia, JSF no caso, mas estes mesmos problemas também seriam facilmente resolvidos se os desenvolvedores se dessem ao trabalho de tentar entender os fundamentos do framework.

Quando falo dos fundamentos de JSF eu estou me referindo ao ciclo de vida, comunicação entre managed beans, escopos de conversação, árvore de componentes, a idéia por trás dos converters e validators, phase listeners, modelo dos componentes etc.

Desenvolver aplicações JSF guiado por “brute-force” é algo que todo desenvolvedor deveria evitar, de fato, ver um exemplinho (ou demo) básico de um componente, copiar o código, joga-lo na aplicação e ainda por cima achar que deveria funcionar é algo ingénuo demais até mesmo para um programador iniciante.

Pior que isso é continuar tentando fazer o componente ou bloco de código funcionar a todo custo sem nem ao menos ler a documentação do mesmo [por isso o termo "brute-force"].

Não adianta correr para tentar usar os componentes se você não possui os fundamentos básicos sobre JSF ou mesmo sobre desenvolvimento web.

Saber o básico é importante

Saber o básico de qualquer tecnologia é obrigatório, e com JSF não seria diferente. Acredito que em primeiro lugar é importante entender o que é JSF e qual a diferença entre uma implementação e um conjunto de componentes.

Criar e configurar um projeto web JSF faz parte do aprendizado, independente da IDE, claro. Como disse, o interessante é não depender exclusivamente da IDE, mas sim conhecer o mínimo necessário para configurar e rodar um projeto com faces (como as libs necessárias e configuração do web.xml).

Entenda que um managed bean é apenas um POJO e que deveria ser o mais simples possível (refletindo estritamente o necessário da GUI). E por favor, coloque uma vez por todas na sua cabeça que os componentes (através de EL) acessam os valores dos managed beans através dos métodos assessores (getters e/ou setters) e não das propriedades.

Depois disso eu aconselharia o entendimento sobre converters e validators, pois eles tornam o desenvolvimento bem mais simples se comparado a outros frameworks MVC. Principalmente os converters, pois eles sim “quebram um galho” danado!

Entenda como o framework e os componentes disparam/tratam os eventos e listeners, e principalmente quando utiliza-los, pois utilizar um listener incorreto para um determinado cenário pode dificultar muito a sua vida, mesmo que no final a coisa funcione. Praticamente tudo o que você precisa saber estará na documentação do componente.

Procure entender o sistema de regras de navegação entre páginas do JSF, principalmente quando e porquê você deveria usar redirect ao invés de um simples forward. E claro, lembre-se que JSF trabalha (submete formulários) apenas com o método POST, não com GET.

Quando as páginas tornam-se grandes e até complexas vale a pena organizar os blocos de componentes através de componentes “maiores”, ou seja, componentes do tipo naming containers, com eles se torna possível manipular os componentes tanto no lado cliente quanto no lado servidor de forma mais simples.

Os fundamentos chaves do framework também fazem parte do conhecimento básico, ou você acha que apenas saber utilizar os componentes, navegar entre páginas e criar seu próprio validator são suficientes?

Sendo, é muito importante que você os compreenda da melhor forma possível. Provavelmente alguns deles você terá alguma dificuldade de entender no inicio, isto é normal, mas é interessante que você ao menos conheça superficialmente cada um deles.

Comece entendendo como e quando a árvore de componentes é gerada (está muito ligado ao ciclo de vida), busque entender como o JSF persiste o estado da árvore de componentes entre requests e porque utilizar JSTL no momento certo é importante.

Os passos necessários para estender ou construir seu próprio componente é algo também importante, mesmo que você não seja um expert nisso, conheça estes passos. Eu particularmente nunca tive a necessidade de criar um componente, apenas estendi um [uma única vez], e com a gama de componentes hoje em dia eu acho muito difícil -mas não improvável- você precisar criar seu próprio componente.

Um fundamento extremamente importante é conhecer as maneiras como os objetos e managed beans se comunicam entre si numa aplicação JSF, pois sem este conhecimento provavelmente você cometeria erros e subutilizaria o framework na sua aplicação.

E por fim, o mais importante fundamento, sem sombra de dúvidas, é entender o ciclo de vida (lifecycle) das requisições no JSF. Procure entende-lo muito bem, pois assim você evitará horas quebrando a cabeça com problemas relativamente simples (quem nunca teve dificuldades de entender como funciona o atributo immediate?).

Vale salientar que independente do(s) conjunto(s) de componentes que você pretenda utilizar os conceitos acima te permitirão trabalhar de forma prática, correta e produtiva.

Mas vá além do básico

Os conhecimentos básicos são obrigatórios quando se pretende desenvolver qualquer aplicação com JSF, por menor que ela seja, mas a partir do momento que se desenvolve aplicações maiores e até complexas se faz necessário adotar certos frameworks, abordagens e até conhecer ou saber que existem algumas soluções mais interessantes.

Assim como a maioria dos frameworks web, JSF trabalha com páginas, muitas páginas para falar a verdade, e isto nos leva a necessidade de um framework para templating. E sempre que falamos em um framework com esta finalidade para JSF nós não devemos esquecer: Aplicações sérias em JSF usam Facelets.

Para quem ainda acha que deve criar seu converter apenas para formatar e remover máscaras de strings deve se interessar por abordagens mais práticas e produtivas de se trabalhar com componentes e conversão de entidades de domínio da aplicação.

Um dos grandes problemas para quem está começando com JSF e componentes AJAX é a maneira como estes desenvolvedores subutilizam os recursos AJAX do framework e dos componentes. Sendo, vale a pena estudar e adotar uma abordagem mais eficiente para isso, uma abordagem com foco em navegação orientada a estados.

Uma abordagem orientada a estados é realmente eficaz e produtiva, mas em certos momentos precisamos “tunar” as requisições AJAX dos componentes ou mesmo diminuir os gargalos em determinadas páginas, buscar melhores práticas para os conjuntos de componentes e/ou frameworks AJAX adotados para um projeto é dever do desenvolvedor, sejam estas práticas para JBoss Richfaces, Myfaces Trinidad ou qualquer outro.

A Expression Language (EL) do JSF por padrão ainda é bem limitada, porém muito extensível, e muitas vezes precisamos de features bem mais arrojadas, logo, não podemos abrir mão de extensões como a JBoss EL para que assim evitemos implementar soluções bizarras.

Como havia dito antes, JSF trabalha apenas com POST, porém algumas vezes precisamos submeter formulários via GET ou disponibilizar links (bookmarking) que acessam recursos ou executam algum método no managed bean antes de renderizar uma página. E antes que você implemente seu próprio phase listener ou alguma solução nada elegante eu indico a você o framework Restfaces.

Nem todas as aplicações web necessitam de um mecanismo arrojado de segurança, muitas vezes uma simples página de login para autenticação e um Servlet Filter (ou phase listener) para autorização de recursos resolve o problema. Mas qualquer coisa além disso você deveria, obrigatoriamente, partir para um framework especializado no assunto: como o Spring Security ou JAAS.

Já cansei muito de bater na tecla que não existe arquitetura de referência (aka bala-de-prata) para solucionar todos os problemas de softwares, já discuti muito isso na lista do javasf, cejug e já comentei sobre isso em vários posts meus e de colegas.

Mas também sei que muitos desenvolvedores/arquitetos tem dificuldades em dar inicio numa arquitetura base que se integre bem com JSF, desta forma, eu aconselho a leitura de dois excelentes posts do Cagatay como referência básica. 1) sobre a integração de JSF+JPA+Spring com o uso massivo de anotações e 2) com a integração anterior mais o Spring Security e Myfaces Orchestra.

Se por algum motivo você não gosta ou não se dá bem com Spring então vale a pena dar uma olhada em um projeto recente de integração entre JSF e Guice, o Guicesf. O Guicesf foi uma iniciativa do Volnei, um dos membros do JavaServer Faces International Group (javasf), e que está caminhando muito bem diga-se de passagem.

Ainda assim, acredito que se você tem tempo para estudar e levantar uma arquitetura para seu projeto então corra e dê uma olhada no JBoss Seam, pois todos os problemas (escopos conversacionais, LazyInitializationException, bookmarking etc) que você encontrará com JSF e solucionará com a integração de alguns frameworks e componentes você com toda certeza poderá ter a mesma solução muito mais simples e muito melhor implementada no JBoss Seam, ou seja, soluções prontas!

Concluindo

A maior parte do conhecimento que você precisa para se tornar um bom desenvolvedor JSF está ligada aos fundamentos do framework, e aos fundamentos sobre desenvolvimento web. Com estes conhecimentos alinhados você não terá muitas dificuldades.

Além do mais, não se assuste se você tiver alguma dificuldade no inicio, principalmente se você já trabalhou com algum framework action-like, como Struts ou Webwork, pois a maioria dos desenvolvedores vindos do “mundo” action-like são os que mais possuem dificuldades em desenvolver aplicações com JSF.

Não pare por aqui, continue pesquisando e estudando sobre a tecnologia, principalmente sobre as novidades do JSF2.0 que estão por vir. Se você já possui experiência com JSF integrado a outros frameworks então aproveite seu tempo e dê uma chance ao JBoss Seam, pois sem dúvida alguma ele está trazendo grande produtivade no desenvolvimento “Enterprisey”.

Enfim, o intuito do post é abrir os olhos de novos desenvolvedores -e até de alguns veteranos- sobre como desenvolver melhor com JSF, e claro, disponibilizar fontes de estudos (quase todos os links levam a outros posts).

No final de tudo, este post nada mais é do que a minha opinião.

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