Desenvolvedores JSF Descubra quais são os principais erros na construção de aplicações JSF e aprenda como evitá-los.

Transcrição

1 a r t i g o Os 10 Maus Hábitos dos Desenvolvedores JSF Descubra quais são os principais erros na construção de aplicações JSF e aprenda como evitá-los. Rafael Ponte (rponte@gmail.com): atua com desenvolvimento de software há mais de 4 anos, com foco no desenvolvimento de aplicações Web. Atualmente é sócio e consultor na TriadWorks, entusiasta Java, JSF e por Design de Software. Também é coordenador da lista de discussão JavaServer Faces International Group (JavaSF). Nos tempos vagos, mantém um blog em JavaServer Faces introduziu uma arquitetura de componentes de interface na plataforma Enterprise Edition, fazendo com que os desenvolvedores Web, que até então lidavam com frameworks action-based, precisassem mudar a sua forma de construir aplicações e pensassem mais orientada a objetos. Com esse novo modelo, também vieram vícios que os próprios desenvolvedores trouxeram devido a anos de trabalho em frameworks procedurais. Conheça quais são esses maus hábitos e aprenda como eles podem ser evitados. Tarso Bessa (tarso.bessa@gmail.com): é um entusiasta Java e atua no desenvolvimento na plataforma há 7 anos. Possui foco em tecnologias Web e gosta de ler bastante sobre novas tecnologias, tendências de mercado e computação distribuída. Atualmente trabalha na Dataprev, é formado pela UNIFOR e possui algumas certificações da Sun, entre elas a SCEA. Tem um blog aqui: J avaserver Faces (JSF) é a tecnologia padrão da plataforma Enterprise Edition (EE) para construção de aplicações Web. Baseada em uma arquitetura de componentes, JSF promete agilizar o desenvolvimento encapsulando a complexidade de se trabalhar com a API de Servlets e JSP. Hoje, há uma série de conjunto de componentes que trazem recursos além da especificação, como suporte a temas em CSS, AJAX, Javascript e outras tecnologias que precisam ser combinadas na construção de interfaces para aplicações Web. Antes de JSF, os frameworks MVC consagrados no desenvolvimento, como o Struts, possuíam em comum uma estrutura de processamento de requisições conhecida como action-based e a necessidade de lidar bastante com a especificação de Servlets. O costume de se pensar voltado a aplicações action-based ainda se manteve em desenvolvedores que 38

2 começaram a fazer suas primeiras aplicações em JSF. Isso fez com que eles tivessem bastante dificuldade porque JSF traz uma arquitetura diferente, incluindo um mecanismo capaz de disparar eventos semelhantes a Swing, e também incompatibilidades com JSP e JSTL. Esse modo de programação criou maus hábitos na utilização dessa tecnologia nova. O objetivo deste artigo é discutir os dez erros mais comuns que desenvolvedores iniciantes na tecnologia cometem, principalmente por trazerem uma bagagem de muitos anos desenvolvendo em outros tipos de frameworks MVC. Os tópicos deste artigo estão organizados de uma forma que permitem a leitura individual, pois o mínimo de conhecimento necessário para a compreensão é fornecido em cada tópico, mas eventualmente é necessário conhecer o ciclo de vida da tecnologia, que pode ser conferido no 1º mau hábito. Todas as discussões neste artigo são frutos da experiência profissional dos autores durante o desenvolvimento de vários sistemas com o uso da tecnologia JavaServer Faces (JSF), de suas discussões em fóruns, listas de discussão e também provenientes de consultoria para algumas empresas. Usar JSTL combinada com componentes JSF JSTL é a biblioteca de tags padrão da especificação JSP que fornece uma série de tarefas de controle de fluxo, formatação de dados, manipulação de XML e outras operações. Esta biblioteca é indispensável no desenvolvimento Web em sua forma mais tradicional. A versão 2.0 de JSP ainda trouxe um novo recurso chamado Expression Language, que combinado com JSTL, tornou a manipulação dinâmica de conteúdo muito mais simples. O trecho de código a seguir exemplifica como é essa geração dinâmica de conteúdo usando JSTL: <c:if test= ${user.admin > Bem vindo, admin! </c:if> A primeira versão de JSF mudou completamente o modo de desenvolver porque trouxe para a plataforma uma arquitetura baseada em componentes, inexistente até então nas especificações padrões, e uma Expression Language totalmente incompatível com JSP. Um componente JSF tem três partes: uma classe de tag, uma classe de componente e outra específica para renderização do conteúdo do componente. Muitos desenvolvedores ainda confundem as tags dos componentes JSF com os próprios componentes JSF, mas, na verdade, o único papel das tags é instanciar os componentes e inicializar os atributos e, a partir daí, o ciclo de vida do JSF toma conta de cada instância dos componentes tornando as tags coadjuvantes. Essas diferenças na arquitetura provocaram incompatibilidades entre as tags tradicionais de JSP (incluindo JSTL) e os componentes JSF, pois as tags tradicionais têm seu conteúdo resolvido externamente ao ciclo do JSF, o que dificulta bastante a integração. Mesmo com a EL Unificada, criada em JSP 2.1 e JSF 1.2, as incompatibilidades ainda existem. Uma página com componentes JSF se transforma em uma árvore de objetos que é persistente entre requisições e controlada pela própria tecnologia. Quando JSTL é usada em conjunto com componentes JSF, há a possibilidade das tags JSTL estarem alterando dinamicamente essa árvore de componentes, destruindo ou criando instâncias novas de componentes. Esse comportamento pode provocar erros no código de um Managed Bean que tenha uma referência a uma instância de um componente através de binding, pois haverá momentos em que a referência estará nula, o que não aconteceria usando apenas JSF. O efeito colateral de se remover ou criar instâncias é fazer com que os componentes percam seus valores locais, ou seja, todos os atributos de um componente modificados por um Managed Bean terão seus valores descartados. A Listagem 1 exibe um exemplo da tag <c:if> de JSTL sendo usada para controlar a visibilidade de um componente JSF. Listagem 1. Mau hábito usando JSTL para controlar visibilidade de componentes JSF. <c:if test= #{bean.admin > <!-- esse componente pode sumir da árvore e provocar erros --> <h:inputtext value= #{bean.value/> </c:if> Os componentes visuais em JSF possuem um atributo chamado rendered, que podem receber uma EL que avalia para true ou false. Se avaliada para true, o componente é exibido (ou renderizado) e se avaliada para false, o componente não é renderizado. A diferença com relação à JSTL é que o componente vai sempre existir na árvore de componentes e, portanto, terá seu estado persistido entre as requisições. Dessa forma, é seguro um Managed Bean obter uma referência para um componente e usá-lo da forma como bem entender. A Listagem 2 exemplifica como os componentes visuais podem ter sua visibilidade através do atributo rendered. Listagem 2. Uso do atributo rendered para controlar a visibilidade de componente(s). <!-- Um panelgroup pode ser usado para englobar mais de um componente --> <h:panelgroup rendered= #{bean.admin > <h:inputtext value=#{bean.value/> <h:commandbutton value= Submit /> </h:panelgroup> Os cuidados com a JSTL não param por aí. Por exemplo, se a tag c:foreach for combinada com JSF, ela vai criar sempre uma nova instância de um componente para cada item que está iterando. Isso é muito diferente do comportamento de UIData (classe base da h:datatable), por exemplo, que possui uma única instância de cada componente filho e a reusa para cada item de sua coleção, sendo mais econômica em recursos. A tabela 1 mostra componentes JSF que podem ser usados para substituir algumas tags em JSTL. Usar stateless EL em atributos de componentes que disparam eventos Um dos requisitos impostos pela arquitetura de componentes da tecnologia JSF é que a aplicação precisa ser stateful, ou pelo menos parte dela. Os dados que alguns componentes manipulam precisam estar disponíveis durante várias requisições para que o comportamento do componente seja estável com relação a eventos, ou até mesmo para que certos componentes consigam editar valores em objetos gerenciados. 39

3 Cenário Em JSTL Em JSF Considerações Controlando a visibilidade de um trecho da página Controlando a visibilidade em grupo Iterando itens em formato tabular Iterando itens com estrutura livre c:if c:choose c:foreach c:foreach Atributo rendered dos componentes Componente h:panelgroup Componente h:datatable - t:datalist, do MyFaces Tomahawk - tr:iterator, do MyFaces Trinidad Não modifica a árvore de componentes. Não é igual a c:choose, mas agrupa logicamente componentes e possui o atributo rendered. Possui melhor gerenciamento de componentes filhos, além de gerenciar melhor seus ids.. As mesmas vantagens que a h:datatable, mas com layout livre. É comum associar uma propriedade de um Managed Bean a um atributo de um componente através de Expression Language. A EL que representa essa ligação é conhecida como Value Expression (antigamente, Value Binding). A Listagem 3 mostra um exemplo de uma EL associada ao atributo rendered de um componente. Listagem 3. Value Expression associando a propriedade de um Managed Bean com o atributo rendered de um componente. <!-- Visível apenas na edição --> <h:commandbutton rendered= #{bean.editing value= Update action=... /> <!-- Visível apenas na inserção --> <h:commandbutton rendered= #{bean.inserting value= Save action=... /> Quando se associa uma expressão a um componente, é preciso ter em mente em quais momentos o componente vai necessitar daquele valor, pois, dependendo do caso, pode ser possível que um componente precise daquele valor até mesmo entre requisições, afinal os componentes são persistentes (stateful). Um desses casos se refere a ELs associadas ao atributo rendered. O que se encontra em documentações é que o rendered controla se um componente terá seu conteúdo gerado na resposta, ou seja, visível ao usuário, mas não é apenas isso. Esse atributo também controla se o componente deverá se processar no início de uma nova requisição, pois, se ele não é renderizável no início do ciclo, supõe-se que o usuário não conseguiu interagir com o componente, logo, o componente nem examina o que vem nessa nova requisição se o atributo rendered for false. As expressões associadas ao rendered são avaliadas em dois momentos, durante a fase Apply Request Values, que é a segunda fase do ciclo e na fase Render Response, que é a fase que gera a resposta dos componentes. Se a expressão avaliar para false durante a Apply Request Values, o componente não vai receber os dados da requisição, consequentemente, não vai se processar, nem empilhar eventos. É preciso ter muito cuidado quando se usa expressões no atributo rendered que dependem de Ma- naged Beans em escopo de requisição, especialmente se o componente estiver presente em múltipas requisições. A tabela 2 mostra em detalhes um exemplo para esse cenário. Na maioria dos casos, os desenvolvedores associam uma expressão que depende de objetos no escopo de requisição fazendo com que a expressão avalie para true na fase de renderização da primeira requisição, mas na requisição seguinte, a expressão acaba avaliando para false porque o Managed Bean não existe mais e o componente não se processa. CommandButtons e CommandLinks são vítimas frequentes dessa forma de programação Eventos da 1ª Requisição 1. Ao iniciar uma requisição, um componente é criado e tem seu atributo rendered associado à expressão #{bean. visible. Ex.: <h:commandlink rendered= #{bean.visible /> 2. O objeto bean é instanciado e atribuído ao escopo request. A propriedade visible do objeto está com o valor padrão para boolean, que é false. 3. Em outro momento da aplicação, o desenvolvedor atribui true a propriedade visible de bean. 4. Na Render Response, a expressão #{bean.visible é avaliada para true e o componente é renderizado. 5. A requisição acaba e o objeto bean é destruído. Eventos da 2ª Requisição 1. A requisição 2 começa quando o usuário aciona o componente renderizado anteriormente, o commandlink. 2. Na fase Apply Request Values, os componentes irão obter seus valores da requisição, exceto aqueles cujos atributos rendered possuem valor false. 3. O commandlink do exemplo avaliará a expressão #{bean.visible e o Container vai procurar um objeto de nome bean em um dos escopos. 4. O objeto bean não existe porque ele foi destruído na última requisição. 5. O Container vai criar o objeto com os valores padrões, logo, a propriedade visible ganha o valor false. 6. O commandlink avalia a expressão #{bean.visible para false e não se processa, ou seja, não empilha o evento e nenhum método será chamado. 7. O fluxo vai até o final e a página é reexibida sem com que o evento seja processado. Tabela 2. Exemplo detalhando o comportamento de componentes quando associados à Managed Beans com escopo curto demais. O termo stateless EL não existe na literatura, mas a palavra stateless é a melhor para descrever expressões que avaliam de forma inconsistente entre requisições, ou seja, não guardam estado entre duas ou mais requisições consecutivas na qual um componente depende. Ter um modelo stateless influencia também no comportamento de eventos de outros componentes. O componente UIInput, por exemplo, dispara eventos para notificar mudança de valores sempre que a sua propriedade value sofrer alterações. Se houver uma EL associada à propriedade value, o componente vai avaliar a EL e comparar o valor antigo com o valor novo. Se forem diferentes, o evento é disparado. Agora, o que acontece se a EL associada ao value de um UIInput depender de objetos em escopo de requisição? O evento de mudança acaba sendo disparado sempre, mesmo que o valor não mude aos olhos dos usuários. Com certeza esse comportamento não é desejado, mas acontece porque objetos no escopo de requisição têm o ciclo de vida muito curto e são descartados ao final das requisições junto com seus dados internos. Na requisição seguinte, eles são recriados com os valores padrões e o UIInput acaba avaliando a expressão que retorna um valor diferente do anterior, provocando o evento. 40

4 Esse comportamento do UIInput não é tão impactante para a aplicação porque o valor do componente acaba sendo atribuído à EL e a aplicação pode seguir com o seu fluxo. Já a UIData (classe base para Datatables) atua de maneira diferente quando uma EL é associada a sua propriedade value. Normalmente, associa-se uma lista de objetos ou uma instância de javax. faces.model.datamodel contendo os itens a serem exibidos. Se essa EL depender de algo em escopo curto demais e na requisição seguinte o valor for avaliado para nulo (ou lista vazia), nenhum evento de componentes internos à UIData será processado, muito menos nenhum dado alterado. Existem algumas estratégias para se resolver esse tipo de problema. Uma delas é ampliar o escopo dos objetos dos quais as ELs dependem e garantir que as ELs sejam avaliadas de um modo consistente entre requisições. Nem sempre ampliar o escopo de um objeto (ou um Managed Bean) significa ter que colocá-lo na sessão. Os objetos que residem na sessão persistem até a sessão ser invalidada ou ter seu tempo expirado e, às vezes, esse período pode ser muito longo para que todo tipo de objeto seja armazenado lá. Para se livrar desses comportamentos descritos anteriormente, os Managed Beans acabam sendo declarados em escopo de sessão prejudicando a escalabilidade (pelo fato da sessão estar sendo usada indiscriminadamente) e a usabilidade do próprio usuário, que não vai conseguir abrir duas abas do navegador e executar mais de uma tarefa sem que uma influencie na outra. Por limitações da própria especificação de Servlets e JSP, que só disponibiliza três escopos, as soluções mais indicadas giram em torno de contextos de conversação, que duram apenas por um determinado tempo, como é o caso do JBoss Seam e do MyFaces Orchestra. Além dessas opções, há o pageflowscope, um escopo que persiste ao longo do fluxo de navegação de páginas, do MyFaces Trinidad e outros dois similares, o t:savesate do MyFaces Tomahawk e o a4j:keepalive do JBoss RichFaces, que guardam os objetos com a árvore de componentes. Usar <redirect/> nas regras de navegação para forçar a mudança de URL Uma das mudanças trazidas por JSF é a ausência de processamento baseado em URLs, como é bem comum em frameworks actionbased. Toda ação que acontece em uma aplicação JSF é fruto de um evento disparado por um componente, então não há como mapear uma URL para um método de uma classe ou um Managed Bean. Em JSF, o desenvolvedor não informa para onde as requisições estão indo, como nos frameworks action-based. Ao invés disso, o Container se preocupa em gerar uma URL que apenas passe pelo FacesServlet, que é o componente principal da tecnologia. Somado a isso, o padrão das navegações é server-side, ou seja, o navegador não percebe quando ocorre a navegação entre páginas. O resultado é uma URL na barra do navegador sempre desatualizada com a página atual. Muitas soluções de segurança para aplicações JEE são baseadas em filtros HTTP, seguindo o padrão Intercepting Filter. Um filtro capta a requisição antes de chegar ao FacesServlet. O que acontece é que filtros configurados para capturarem requisições não conseguem capturar a URL da página atual corretamente, pelo fato de JSF não ser voltado a URLs. Para solucionar este problema e forçar sempre o acesso à página atual através do navegador, alguns desenvolvedores se utilizam da tag redirect nas regras de navegação do arquivo faces-config.xml. Essa tag indica ao Container que aquela regra de navegação deve gerar uma nova requisição. A Listagem 4 mostra uma tag redirect sendo usada para provocar um redirecionamento entre páginas que podem ser de um mesmo caso de uso. Listagem 4. Mau hábito Usando redirect para forçar mudança na URL. <navigation-rule> <from-view-id>/pages/pesquisa.jsp</from-view-id> <navigation-case> <from-outcome>cadastrar</from-outcome> <to-view-id>/pages/cadastro.jsp</to-view-id> <redirect /> </navigation-case> </navigation-rule> Muitos desenvolvedores pensam que a única finalidade da tag redirect é basicamente mudar a URL na barra de endereço do navegador durante a navegação entre páginas. Ela realmente muda e o filtro de segurança passa a capturar a URL correta, mas aí é que começam os problemas, pois a aplicação começa a comportar-se de maneira estranha. Como um redirecionamento implica em uma segunda requisição, os Managed Beans em escopo de requisição têm seus valores perdidos e as mensagens de sucesso (ou erro) adicionadas ao FacesContext não são mais exibidas ao usuário como esperado. Prever quais os possíveis problemas do uso indevido da tag redirect não é uma tarefa tão simples assim. Pode-se dizer que a solução mais simples seria apenas a remoção da tag redirect da regra de navegação ou a utilização de um framework como JBoss Seam. Para a questão do filtro de segurança, basta configurar o filtro para capturar forwards (se a aplicação estiver usando JSF e JSP). Mesmo assim, o problema é bem mais grave do que muitos imaginam. A solução mais apropriada, na verdade, é o desenvolvedor entender os fundamentos básicos sobre desenvolvimento Web. Mais especificamente, para este mau hábito, o desenvolvedor deve saber a diferença entre um forward e um redirect, e quando usar cada um deles durante a navegação entre páginas na aplicação. Um Servlet (controller) pode realizar tanto um forward ou um redirect no fim do processamento de uma requisição. Entender a diferença entre eles é realmente importante, principalmente quando se considera a possibilidade do usuário fazer reload das páginas pelo navegador. A tabela 3 sintetiza as características impostas por forwards e redirects. 41

5 Forward está ocorrendo durante o processamento no servidor, ou seja, não sabe por quais Servlets ou páginas a requisição está passando. da requisição, a URL da barra de endereços do navegador não muda. te irá executar a requisição original. Redirect ao receber uma requisição a aplicação web pede ao navegador para acessar uma segunda URL. Por isso, a URL muda. a requisição original, mas sim a nova URL (2ª requisição). to que um forward, pois são necessárias duas requisições, e não uma. po de requisição original são perdidos durante a segunda requisição, assim como as mensagens. como o Struts, têm o hábito de alterar a estrutura da página via Javascript por vários motivos, seja por questões de usabilidade ou facilidade, e no final esperam ter esta alteração refletida no lado servidor. Como os componentes JSF se processam apenas no servidor, tentar adicionar um elemento HTML ou até mesmo tentar modificar o valor de um componente que é read-only (somente leitura) ou disabled, é inútil. A insistência neste (mau) hábito acaba frustrando os desenvolvedores porque suas alterações no lado cliente não refletem como o esperado na aplicação. Enquanto uns podem reclamar que esse modelo proposto pelo JSF não é flexível, vale ressaltar que esse modelo promove uma maior segurança, pois um usuário mal intencionado não vai conseguir, através da alteração do DOM (Document Object Model) de uma página, modificar valores no servidor. Um bom exemplo disso pode ser mostrado na figura 1, em que se tenta usar o Firebug, um plugin para o navegador Firefox, para modificar informações da página. Em geral, um forward deve ser utilizado em operações que podem ser seguramente repetidas pelo navegador, por outro lado, se uma operação modificar registros no banco de dados, um redirect deve ser utilizado, aplicando a estratégia Redirect After Post. Desta maneira, evita-se que um reload na página provoque a possibilidade de inadvertidamente duplicar registros no banco de dados (um problema conhecido como double submit). JSF puro não possui um mecanismo completo para Redirect After Post. Para isso, precisa-se usar o JBoss Seam ou implementar a própria solução para que as mensagens adicionadas ao FacesContext sejam preservadas. Caso não se deseje utilizar o padrão Redirect After Post, tem-se a opção de controlar o problema do double submit através de tokens. Assim, um reload pode ser impedido porque o token da requisição seguinte já foi processado. O JBoss Seam, mais uma vez, traz uma solução para isso. Usar Javascript para alterar o estado de componentes Em aplicações Web construídas com um framework mais simples, os desenvolvedores costumam enriquecer o desenvolvimento agregando outros recursos e linguagens, como Javascript, que muitas vezes são usados para alterar o conteúdo de uma página no lado cliente (no navegador). Este tipo de prática torna as aplicações muito mais interativas com os usuários, mas também podem trazer maus hábitos se não for usada corretamente com JSF. JSF é uma tecnologia em que todo o seu processamento ocorre no lado servidor e, além disso, tem uma estrutura baseada em componentes que realizam o processamento das requisições. Os componentes são mantidos em uma estrutura de árvore para representar uma página e esta árvore é persistente entre requisições. Nada além dos componentes que estão na árvore será processado em JSF. Alguns desenvolvedores, por terem vindo de frameworks action-based, Por mais que o input text tenha seu valor alterado e o read-only removido na página gerada pelo JSF, o valor desse componente não será avaliado no ciclo de vida, pois no lado servidor o componente continua possuindo o estado read-only e, consequentemente, a tecnologia respeita isto. Desta forma, durante o processamento do componente, o framework irá ignorar qualquer valor submetido pelo usuário. O mesmo comportamento se aplica também a componentes de seleção múltipla (como o h:selectonemenu) em que o desenvolvedor insere ou remove itens dinamicamente via Javascript, e espera que ao submeter o formulário, a tecnologia JSF entenda e permita que estes novos itens sejam processados normalmente. Não é que não seja possível usar Javascript com JSF, pelo contrário, muitos conjuntos de componentes usam bastante Javascript para ter recursos como AJAX, como é o caso do RichFaces e o MyFaces Trinidad. Este último, por exemplo, possui uma API de validação client-side toda construída em Javascript. A questão é não usar Javascript para alterar o estado dos componentes. Para mudar este mau hábito, é necessário que o desenvolvedor altere o estado do componente (ou Managed Bean) no lado servidor via AJAX e renderize novamente o componente com o novo estado para o usuário. Assim, qualquer mudança necessária na GUI será informada ao JSF, processada e, por fim, refletida para o usuário após a atualização parcial da página. Infelizmente, algumas aplicações, por motivos particulares, não podem 42

6 adotar AJAX para um desenvolvimento mais rico. Logo, a equipe de desenvolvedores acaba sendo obrigada a atualizar a página completamente após alterar o estado de algum componente. Utilização de parâmetros de requisição O envio de informações de um navegador para um servidor se dá por meio de parâmetros, devido a natureza do protocolo HTTP. Então, baseado nisso, o desenvolvimento na web, usando a API de Servlets, tem sido por muito tempo uma troca de valores que eram usados para identificar o que o usuário estava fazendo e assim continuar um processo. Claro que algumas informações poderiam ficar no escopo de sessão, mas para não prejudicar a escalabilidade, as informações que ficam na sessão normalmente são aquelas que são restritas ao usuário e não ao processo que ele está fazendo (levando em consideração uma época sem gerenciamento de sessão, pré JBoss Seam). Se fosse necessário disparar um processo que dependesse da identificação de um dado que estivesse armazenado no banco de dados, era muito comum usar a chave primária do objeto para identificar a escolha do usuário. Por exemplo, para remover um item em um cadastro, um link poderia disparar uma ação e enviar como parâmetro o valor que identificasse o objeto a ser removido, como mostrado na Listagem 5. No servidor, o parâmetro seria usado para fazer uma consulta, obter o registro e removê-lo. Listagem 5. Link passando um parâmetro que identifica um objeto a ser usado. <table...> <tr> <td>john Doe</td> <td><a href= /context/process/remove?id=5 >Remove...</a></td> </tr> </table> Quando se traz essa cultura para aplicações JSF, os componentes acabam sendo subutilizados e se tornam meros substitutos para tags HTML. Isso é muito ruim porque o desenvolvedor acaba programando o que o componente poderia estar fazendo para ele. Na Listagem 6, o exemplo anterior é convertido para JSF, mas ao invés de se usar o CommandLink para realizar uma ação, o componente é usado apenas para passar um parâmetro. Listagem 6. Mau hábito Uso de componentes para passagem de parâmetros. <h:datatable value= #{users var= user > <h:column...> <h:commandlink value= X action= #{bean.remove > <!-- Passagem de parâmetro em links --> <f:param name= id value= #{user.id /> </h:commandlink> </h:column> </h:datatable> O código que interpreta o parâmetro é mostrado na Listagem 7, logo a seguir. O problema com o código é a manipulação direta do parâmetro extraído da requisição. Para que o objeto seja identificado, ainda é necessário converter para um tipo do domínio da aplicação e a partir daí, usar o valor. Listagem 7. Exemplo de como obter parâmetros da requisição HTTP usando JSF. public void remove(){ //Converte o valor manualmente Integer id = new Integer( facescontext.getexternalcontext(). getrequestparametersmap(). get( id ) ); User user = search(id); if(user!= null){ //manipula o objeto. Os componentes JSF conseguem otimizar esse tipo de tarefa para que o desenvolvedor não precise programar baseado em parâmetros. Por exemplo, um componente de seleção, como o <h:selectonemenu>, consegue saber qual foi o item selecionado (ver o quadro Métodos equals e hashcode) e atribuir o item a uma propriedade de um Managed Bean. Dessa forma, o desenvolvedor lida direto com o objeto e deixa o trabalho de manipular parâmetros para o próprio componente. A Listagem 8 mostra como o mesmo problema pode ser simplificado usando de uma melhor forma os componentes. Listagem 8. Exemplo de como obter um objeto selecionado em uma Datatable. <h:datatable value= #{users var= user > <h:column...> <h:commandlink value= X action= #{bean.remove > <!-- Realiza a atribuição do objeto selecionado --> <f:setpropertyactionlistener value= #{user target= #{bean.user /> </h:commandlink> </h:column> </h:datatable> O código também fica mais legível, pois agora o CommandLink vai atribuir o objeto selecionado à propriedade de um Managed Bean. Para desenvolver bem em JSF, é preciso pensar mais orientado a objetos e deixar com que os componentes realizem as tarefas repetitivas, para que haja ganho de produtividade. A Listagem 9 mostra como fica o código do Managed Bean. Listagem 9. Código de um managed bean que tem objetos atribuídos por componentes. public class Bean { public void setuser(user user){ this.user = user; public void remove(){ //não precisa pesquisar mais, pois a atribuição é feita pelos componentes. if(user!= null){ // manipula o objeto 43

7 Como JSF trabalha muito com objetos e coleções, especialmente listas, é essencial que os métodos equals e hashcode sejam implementados nos objetos de modelo da aplicação. Por exemplo, os componentes de seleção sempre verificam se o item selecionado pertence à coleção de dados que foi usada para renderizar as opções. Se os métodos equals e hashcode não forem implementados, o componente vai disparar um erro informando que aquele valor é inválido, pois mesmo que exista um elemento na lista de opções com os mesmos dados, sem equals e hashcode fica impossível determinar se os dois objetos são idênticos. Usar o valor de submittedvalue como se fosse o valor real de um componente É comum uma página de uma aplicação ter mais de um botão que dispare eventos. Alguns desses eventos irão obter os dados do formulário e processá-los da maneira mais adequada, porém, em algumas situações, certos eventos não precisarão manipular dados, pois eles servirão apenas para cancelar uma operação e navegar para outra página. Em JSF, alguns componentes possuem um atributo chamado immediate capaz de alterar o comportamento dos componentes para que eles se processem em fases diferentes, incluindo a chamada a seus eventos. Os componentes não-imediatos processam seus eventos na fase Invoke Application, ou seja, após a validação, conversão e atualização de valores em Managed Beans. Dessa forma, é seguro obter um valor de uma propriedade gerenciada por um componente e armazená-la em uma base de dados, por exemplo. Já os componentes imediatos processam seus eventos na fase Apply Request Values, ou seja, logo após receberem os seus dados da requisição e isso é antes da validação, conversão e atribuição de valores em Managed Beans. Um componente imediato, por exemplo, seria o responsável por navegar para outra página, fazendo com que o usuário saia de uma página que tenha um formulário de dados a ser preenchido. Esse exemplo é o de um botão Voltar ou Cancelar em uma página de cadastros que tenha campos obrigatórios. A Listagem 10 mostra um exemplo de um formulário com dois botões, um imediato e outro não-imediato. Listagem 10. Exemplo de botões imediatos e não-imediatos. <h:form>... <h:inputtext required= true value= #{bean.name /> <!-- Só dispara o evento se o campo nome acima for preenchido --> <h:commandbutton value= Salvar a Informação action=... /> <!-- Ignora o preenchimento do nome e navega para outra página --> <h:commandbutton value= Ir para o Index immediate= true action=... /> </h:form> Existe um desentendimento bem comum por parte de alguns desenvolvedores que pensam que os eventos de componentes imediatos pulam a etapa de validação (Process Validations). Isso não é completamente correto. O correto é afirmar que um componente imediato se processa antes da etapa de validação. Se o componente for um UICommand (botões e links), o evento interrompe o ciclo evitando a etapa de validação, mas se o componente for EditableValueHolder (inputs e selects), o componente se processa por inteiro, incluindo a sua própria validação, e o ciclo de vida ainda continua disparando mais adiante a validação dos componentes não-imediatos. Se houverem dois ou mais inputs imediatos junto com um botão imediato em um formulário, os inputs serão validados antes do evento do botão ser chamado. Nesse caso, mesmo todos sendo imediatos, os inputs se validarão antes da chamada ao do evento do botão. Existem certos cenários em que é preciso obter o valor de um componente dentro de um evento disparado por outro componente imediato. Um exemplo disso é um botão que, quando acionado, obtenha o valor de um input, calcule um valor qualquer e exiba no formulário. Se o formulário tem 10 campos obrigatórios, seria indesejável obrigar o usuário a digitar cada um dos campos só para poder acionar o botão de cálculo. Portanto, esse botão tem chances de ser imediato. Assim, a ação acontece antes da validação dos demais campos e o usuário não precisa digitar campos que não tenham nada a ver com aquela informação. Como obter o valor de um componente dentro de um evento imediato? Se o evento é imediato, o valor não estará na propriedade de uma Managed Bean, portanto só há uma alternativa: realizar um binding de um componente e obter o valor diretamente da instância do componente. Aqui começa a armadilha! Durante a Apply Request Values, que é a fase onde os eventos imediatos são chamados, é muito cedo para se obter o valor de um componente. O principal objetivo dessa fase é para que cada componente guarde o valor que lhe foi informado pela requisição. Esse valor é uma espécie de cache e é armazenado na propriedade submittedvalue do próprio componente. O ciclo de vida do JSF prevê o seguinte: se as validações falharem, os dados em Managed Beans não serão atualizados e os valores informados pelo usuário serão reexibidos no formulário, junto com as mensagens de erro produzidas por cada validador ou conversor associado a cada componente. O que é reexibido é esse cache, ou seja, o submittedvalue. Como os dados enviados em formulários HTML são sempre String, os dados armazenados também são sempre em String, independentemente se o componente está ligado a uma propriedade de um Managed Bean de outro tipo (ex.: java.lang.integer, java.util.date etc.). O problema é que esse é o único valor que está disponível em um componente durante um evento imediato, fazendo com que o desenvolvedor o use para saber qual foi o dado digitado ou selecionado pelo usuário. As Listagens 11 e 12 mostram, nessa ordem, um exemplo de uso com componentes imediatos e um mau exemplo de como obter o valor de um componente usando o submittedvalue. O valor que é atribuído ao Managed Bean, na fase Update Model Values, não é o valor do submittedvalue (exceto se a propriedade do Bean for String, claro), e sim um valor validado e convertido de acordo com o tipo da propriedade do Bean ou de acordo com os validadores e conversores do componente. É importante ressaltar que o valor armazenado em 44

8 Listagem 11. Formulário com um botão imediato, que precisa executar uma ação antecipadamente. <h:form>... <h:inputtext required= true value= #{bean.name />... <h:inputtext binding= #{bean.iptdate required= true value= #{bean.date > <f:convertdatetime pattern= dd/mm/yyyy /> </h:inputtext> <!-- Botão precisa ser imediato --> <h:commandbutton immediate= true value= Calcular Valor action=... /> <h:inputtext required= true />... </h:form> Listagem 12. Mau hábito Obtendo o valor de um componente do formulário através de submittedvalue. public class Bean { //Binding para um componente que edita datas private UIInput iptdate; //Evento imediato. Obtém valores através de bindings de outros componentes public void calcvalue( ActionEvent evt ){ String datestr = (String) iptdate.getsubmittedvalue(); /** * O problema está na manipulação desse dado. Se o valor usado é String e * a conversão/validação é manual, para que serve o componente? */ Date datevalue = convert( datestr ); if ( datevalue!= null && datevalue.after( otherdate ) ) { //realiza a ação submittedvalue não reflete, na maioria das vezes, o valor da propriedade do Bean, então essa propriedade não deve ser usada para obter o valor de um componente. A tentação cometida por desenvolvedores é obter esse valor em String e realizar a conversão e validação manual dentro de um evento imediato em um Managed Bean. O problema com esta abordagem é que o componente perde a utilidade de automatizar tarefas repetitivas, como validação e conversão, além do código ter grandes chances de ser alterado para manter a sincronia sempre que um novo comportamento for adicionado ao componente. Por exemplo, se o componente possui dois validadores associados, um que verifica qual a data mínina que pode ser fornecida e outro que verifica o intervalo máximo de um período, o desenvolvedor precisa programar esse mesmo comportamento no método de um Managed Bean para manter a consistência dos dados. Uma solução parcial para este tipo de problema é marcar todos os outros componentes que serão utilizados dentro de um evento imediato como imediatos. Dessa forma, o componente se processa na mesma fase e já consegue produzir o valor que será atribuído ao Managed Bean em fases futuras. A Listagem 13 mostra um exemplo de como fica o código se todos os componentes forem imediatos. Listagem 13. não definitiva marcando todos os componentes envolvidos como imediatos. public class Bean { //Binding para um componente que edita datas. //Marcado como immediate=true private UIInput iptdate; //Evento imediato. public void calcvalue( ActionEvent evt ){ /** * O código foi refatorado porque o componente iptdate é imediato e já * possui o valor em sua propriedade value. A conversão e a validação * passa a ser feita pelo próprio componente. */ if ( iptdate.isvalid() ) { Date datevalue = (Date) iptdate.getvalue(); if ( datevalue.after( otherdate ) ) { //realiza a ação O código da Listagem 13 está mais adequado porque o componente está realmente sendo utilizado. Dentro do Managed Bean não há mais métodos para converter e validar. Nesse cenário, a chamada ao método isvalid se faz necessária porque os eventos imediatos acontecem sempre na mesma fase, então uma falha de validação não impede outros eventos da mesma fase de serem chamados. Falha de validação só impede a fase seguinte de executar. Se o botão é imediato e precisa obter o valor de um input também imediato, ele precisa checar se o valor é válido. Essa solução é parcial porque acaba produzindo outro problema. Se existir um terceiro componente imediato, como um botão Voltar, ele acaba fazendo com que todos os inputs imediatos sejam também processados. Isso faz com que um botão imediato, que apenas precise navegar para outra página, dispare a validação de um input imediato e que pode produzir uma mensagem de erro de validação. Em JSF, não há uma maneira de desligar o mecanismo de validação. A solução definitiva é usar Subforms. Subforms separam o formulário principal em regiões independentes. Todo evento que acontece dentro de uma área dessas permanece naquele escopo até o fim da requisição e as demais regiões têm seus dados preservados. Com essa estratégia, é possível deixar em um subform aqueles componentes que precisam executar um fluxo à parte do fluxo principal de um formulário, reduzindo ou anulando a necessidade de componentes imediatos. Componentes de subforms estão presentes nos seguintes kits de componentes, Tomahawk (t:subform), Trinidad (tr:subform) e RichFaces (a4j:region). As Listagens 14 e 15 mostram, respectivamente, como ficariam a página e o código do Managed Bean refatorados com Subforms. 45

9 Listagem 14. Página com componentes separados por Subforms. <h:form> <!-- subform do Tomahawk --> <t:subform id= regiaoa > <h:inputtext required= true value= #{bean.name /> </t:subform> <t:subform id= regiaob > <!-- É obrigatório, afinal é necessário para o cálculo. --> <h:inputtext required= true value= #{bean.date > <f:convertdatetime pattern= dd/mm/yyyy /> </h:inputtext> <!-- Botão não precisa mais ser imediato. Não influencia regiões A e C --> <h:commandbutton value= Calcular Valor action=... /> </t:subform> <t:subform id= regiaoc > <h:inputtext required= true /> </t:subform>... </h:form> Listagem 15. Código de um Managed Bean que processa uma região marcada por subforms. public class Bean { //Sem Bindings private Data date; //Evento não-imediato. public void calcvalue( ActionEvent evt ){ /** * Com subforms, a necessidade de bindings e eventos imediatos diminui ou * reduz a zero, permitindo que o código fique muito mais simples. */ if ( date.after( otherdate ) ) { //realiza a ação Como subforms permitem que as áreas sejam processadas independentes, não se faz necessário marcar os componentes como imediatos. Resultando em um código no Managed Bean mais simples e deixando o trabalho de conversão e validação para os componentes. Implementar o próprio mecanismo de segurança É fato que uma aplicação corporativa precisa usar uma solução de segurança e as aplicações construídas em JSF não estão isentas dessa possibilidade. Segurança em aplicações na plataforma JEE geralmente é feita com filtros, JAAS ou uma combinação de ambos. O problema é quando os desenvolvedores encontram uma aplicação que acham simples demais e decidem criar um mecanismo novo baseado em PhaseListeners, com a desculpa de que vai ser apenas para aquela aplicação. Um PhaseListener é uma interface que pode ser implementada por algum mecanismo que deseja receber notificações do Container antes e após a execução de cada fase do ciclo de vida. Uma ou mais implementações de um PhaseListener podem ser configuradas no faces-config.xml. Por ser um mecanismo que recebe notificações de fases, é muito comum ver implementações de dentro de uma aplicação que usam PhaseListeners para controlar a segurança da aplicação. A Listagem 16 mostra um trecho de como seria um PhaseListener que controla a segurança. Listagem 16. Exemplo de um PhaseListener que controla segurança. public class LoginPhaseListener implements PhaseListener { //on RESTORE_VIEW public void afterphase(phaseevent e) { if(!isloggedin() &&!islogin() ){ //navigate to login page O problema com esta abordagem é que a solução fica completamente atrelada à tecnologia JSF, ou seja, outras aplicações feitas em outras tecnologias Web, na mesma empresa, que necessitam de um mecanismo de segurança não vão aproveitar a lógica interna desse PhaseListener e, além disso, surgem sempre novas necessidades de configuração que implicam em novas programações do mecanismo, fazendo com que ele cresça demasiadamente tornando-o difícil de manter. É importante observar que segurança é um assunto sério e não deve ser tratado por uma implementação qualquer, principalmente se for feita durante o desenvolvimento de um produto, pois o tempo do projeto vai estar andando e muitas vezes a implementação não estava agendada no cronograma, fazendo com que exista pressão para conclusão da atividade. Uma solução adequada para segurança seria usar um mecanismo robusto, como o Spring Security para aplicações que usam o Spring, ou então, as extensões de segurança do JBoss Seam para aplicações que o usam como container. Ambas as soluções cobrem autenticação e autorização e são bastante extensíveis, além de que é bem mais simples programar extensões para o Spring Security ou o JBoss Seam que simplesmente acessem a base de regras da aplicação a ter que construir um mecanismo de segurança dentro da aplicação. Mais informações sobre segurança podem ser obtidas na edição nº. 28 da Mundoj, que traz o artigo Os Sete Pecados do Controle de Acesso em Aplicações Java EE. É necessário usar o Spring ou JBoss Seam na minha aplicação JSF? Usar apenas a especificação JSF, como ela está hoje na versão 1.2, é praticamente inviável para uma aplicação corporativa porque a limitação de recursos é muito grande: o número de componentes é altamente restrito e as características do Container são limitadas. Recursos como AJAX, temas e outros mais interessantes como AOP não existem na especificação, então haverá necessidade de complementar a tecnologia JSF com algo a mais, que pode ser o Spring ou JBoss Seam, dependendo das necessidades do projeto. Ambos têm um container poderoso e é bem mais 46

10 vantajoso que o Container do JSF seja complementado pelo container de uma dessas soluções Paginação de registros na sessão Paginação é um processo para dividir um conteúdo com muitos dados em várias páginas menores. Com isso, ganha-se em usabilidade, pois é impossível para um usuário visualizar milhares de dados de uma vez só, e em desempenho, já que a aplicação lida com um número pequeno de informações a cada vez. Alguns conjuntos de componentes para JSF, como o Trinidad e o RichFaces, fornecem componentes que fazem a paginação de registros com algumas poucas linhas de código e isto é algo realmente simples para quem está começando. Basta uma lista de registros (muitas vezes entidades) e pronto, já se tem uma tabela com paginação capaz de usar AJAX sendo exibida ao usuário em questões de minutos. É importante observar que a paginação que estes componentes realizam é apenas uma paginação visual, ou seja, renderizam apenas um intervalo determinado de dados. Estes componentes não gerenciam os dados, apenas os exibem em intervalos. Mesmo assim, essa facilidade de exibir dados em intervalos faz com que os desenvolvedores fiquem tentados a jogarem os dados no escopo de sessão e se darem por satisfeitos com a paginação visual dos componentes. Com certeza este é um dos maus hábitos mais recorrentes no desenvolvimento em JSF. Um exemplo de componente de paginação do Richfaces pode ser visto na Listagem 17. Listagem 17. Exemplo de paginação com o componente rich:datascroller do Richfaces. <!-- o atributo rows define a quantidade registros exibidos por página --> <rich:datatable id= tbl rows= 10 value= #{bean.listadeprodutos Durante o desenvolvimento, esta abordagem com paginação em memória não aparenta ser um problema, porém quando a aplicação vai para produção e o número de usuários simultâneos cresce, cada vez mais dados vão parar na sessão, fazendo com que a memória do servidor fique cheia de dados que não estão sendo usados. O problema só tende a piorar com o tempo, já que o número de registros no banco de dados tende a crescer também. Um das melhores maneiras de matar a escalabilidade da aplicação é a utilização indiscriminada da sessão. var= produto > <!-- Colunas da tabela --> </rich:datatable> <!-- Componente que controla a mudança de página para a tabela --> <rich:datascroller for= tbl maxpage= 20 /> Independentemente do framework Web, a melhor solução hoje em dia para este tipo de problema é paginação sob demanda. Com a paginação sob demanda, a aplicação somente recuperaria os dados necessários para visualização do usuário. Portanto, se existe um resultado de uma consulta com 40 mil registros e um componente que apresenta 15 registros por página para o usuário, não há motivos de trazer todos os 40 mil registros para memória. Simplesmente, a cada página, o componente recuperaria apenas 15 registros do banco de dados e, durante a navegação entre as páginas, efetuaria novas consultas para recuperar os 15 próximos ou os 15 registros anteriores do banco de dados. Utilizar uma solução como paginação sob demanda é essencial para o bom funcionamento de um sistema e para o próprio servidor de aplicação. O JBoss Seam, com o seu Seam Application Framework, já fornece uma solução pronta para paginação sob demanda. Já em blogs, fóruns e listas de discussão é fácil encontrar outras soluções, algumas bem elaboradas e outras nem tanto. Contudo, a mais comum e mais prática, sem dúvida, é estender a API do JSF, mais especificamente a classe javax.faces.model.datamodel, e implementar o conceito de paginação sob demanda. Um exemplo pode ser visto na Listagem

11 Listagem 18. Exemplo de implementação do DataModel para paginação sob demanda. public class DynamicDataModel extends DataModel { //Método chamado pela Datatable para obter cada item da lista public Object getrowdata( ) { //índice atual que a Datatable está acessando int index = getrowindex(); //verifica se o item está em cache if (! cachemap.containskey( index ) ) { //busca novos dados no banco de dados Object newobject = fetchnewdata(index); cachemap.put( index, newobject ); return cachemap.get(index); //retorna a quantidade de registros previamente //determinada para a consulta public in getrowcount(){ return count; //Usado pela DataTable para saber se um registro está disponível. public boolean isrowavailable(){ return getrowindex() >= 0 && getrowindex() < count; O código da Listagem 18 não está otimizado e é apresentado aqui apenas para fins de didática. Para a paginação sob demanda funcionar corretamente é necessário saber, antes de sair paginando, quantos registros retornam em uma consulta. Essa informação é importante para que o componente de paginação consiga calcular quantas páginas serão exibidas. A DataTable irá usar o método getrowcount do DataModel para saber sobre essa informação. Após isso, a DataTable irá chamar três métodos do DataModel consecutivamente, setrowindex, isrowavailable e getrowdata. O método setrowindex será usado para informar ao DataModel que índice a DataTable está tentando acessar. Logo depois, a DataTable vai chamar o método isrowavailable para saber se aquele índice existe nos dados do DataModel. Se o retorno for true, a DataTable vai finalmente chamar o getrowdata. Dentro do método getrowdata é que acontece a lógica da paginação sob demanda. A implementação pode verificar se o item requisitado pela DataTable está em cache e, se tiver, retorná-lo. Se o item não tiver em cache, o DataModel consulta o item (ou um intervalo deles) no banco de dados e armazena em cache antes de retorná-lo. Por último, basta associar a implementação do DataModel, chamada neste exemplo de DynamicDataModel, com a DataTable. O não uso de paginação sob demanda em projetos sérios pode trazer problemas de escalabilidade, desempenho ou até mesmo a inviabilidade do uso da aplicação. Realizar consultas em propriedades de managed beans expostas a componentes É bastante comum, para uma aplicação corporativa, exibir dados em combos ou tabelas. Em JSF, os componentes destinados a esta tarefa são, respectivamente, os componentes de seleção (ex.: classes que estendem UISelectOne e UISelectMany) e a DataTable (ex.: classe que estende UIData). O que esses componentes têm em comum é a possibilidade de se trabalhar com listas de objetos e, em JSF, esses dados podem ser fornecidos aos componentes através de Expression Languages (ELs) que, quando avaliadas, retornam os dados que serão exibidos pelos próprios componentes. Na maioria das vezes, a expressão avalia para uma propriedade de uma Managed Bean. A Listagem 19 mostra uma DataTable sendo associada a uma Value Expression. O problema não está na associação de uma expressão ao componente, mas sim na forma como os desenvolvedores suprem a lista de dados aos componentes. Listagem 19. Associação de um valor a um componente via Value Expression. <!-- tabela associada a uma lista de usuários --> <h:datatable value= #{bean.userslist var= user > <h:column...>... </h:column> </h:datatable> O mais lógico e tentador, quando se tem esse cenário, é implementar a chamada a uma consulta (que retorne uma lista de dados) dentro do método get de um Managed Bean, como mostrado na Listagem 20. O que pode parecer uma solução simples se torna um problema. Os componentes acabam precisando dos dados mais de uma vez durante uma requisição e isso faz com a EL associada seja avaliada sempre que necessário. Essas inúmeras avaliações da EL provocam várias chamadas ao método do Managed Bean e que, por sua vez, também disparam a consulta várias vezes. Esse erro pode ser percebido através dos logs da aplicação, pois o registro da consulta sempre vai aparecer repetido. Disparar consultas em métodos get é prejudicial ao desempenho da aplicação. Listagem 20. Mau hábito Uso de consultas em métodos 'get' de Managed Beans. public class Bean{ //Retorna uma lista de objetos public List<Users> getuserslist(){ return service.findallusers(); 48

12 A solução para este tipo de cenário é simples: o método que realiza a consulta deve ser movido para dentro de uma callback ou para dentro de um evento, dependendo do momento que aquele dado será utilizado. Se o dado for utilizado logo ao entrar em uma página, a consulta pode ser levada para um método com a como mostrado na Listagem 21. A marca um método para ser chamado logo após a inicialização de um managed bean, mas antes dele ser disponibilizado para uso. A vantagem da é que o método marcado só será executado apenas uma vez na inicialização do bean, evitando a chamada repetida. Listagem 21. Uso para efetuar consultas na inicialização do bean. ciclo de vida Uma das coisas mais importantes para quem desenvolve aplicações em JSF é entender o ciclo de vida de uma requisição. Conhecer apenas a documentação dos componentes não é suficiente para aproveitar o máximo de JSF, pois é entendendo o ciclo de vida que se compreende a ordem dos eventos e do processamento dos valores dos componentes, além de ter respostas a perguntas rotineiras como porque um evento não está sendo chamado?, porque um componente está sem o valor? ou porque os valores não estão nas propriedades dos managed beans?. O ciclo de vida em JSF é dividido em seis fases, como ilustrado na figura 2, que são: Restore View, Apply Request Values, Process Validations, Update Model Values, Invoke Application e Render Response. Cada uma dessas fases será comentada nos tópicos a seguir. public class Bean{ Immediate Events Value Change public void initialize(){ //só é chamado uma vez REQUEST Restore View Apply Request Values Process Validations this.users = service.findallusers(); RESPONSE Render Response Invoke Application Update Model Values public List<Users> getuserslist(){ return this.users; Como é voltado para inicialização de beans, nem sempre será possível usar consultas que dependem da interação do usuário. Para esses casos, um evento é mais indicado. Outro cenário em que o evento se adequa mais é quando o dado só for requerido a partir de um determinado passo (ou página) de um caso de uso. A vantagem de se usar o evento é que a consulta, além de ser disparada uma única vez, só será chamada sob demanda. Um exemplo de como usar um evento para disparar consultas é mostrado na Listagem 22. Listagem 22. Uso de eventos para efetuar consultas sob demanda do usuário. public class Bean{ public void search(actionevent evt){ this.users = service.findusers(parameters); Restore View Apply Request Values Action Events Figura 2. Fases do ciclo de vida da tecnologia JSF. A primeira fase é responsável por construir uma árvore de componentes que representa a página que está sendo acessada. Essa construção acontece de duas formas: se for o primeiro acesso àquela página, os componentes serão instanciados sob responsabilidade das suas tags e, em seguida, a resposta é imediatamente gerada, ou seja, vai para a fase Render Response; se a requisição for um postback, significa que a árvore de componentes já foi criada em uma requisição anterior, então o processo restaura a árvore, faz a associação com o FacesContext e o fluxo parte para a segunda fase, a Apply Request Values. Após a restauração da árvore de componentes, cada componente será responsável por obter seu novo valor através dos parâmetros enviados pela requisição HTTP. Esse valor será armazenado em cache, pois se ocorrer problemas com a validação ou conversão, esse valor será reexibido mais adiante. public List<Users> getuserslist(){ return this.users; Para os componentes que possuem o atributo immediate com o valor true, a conversão, validação e seus eventos serão processados nesta fase. Componentes que implementam EditableValueHolder (inputs, selects) executarão o processo da fase Process Validations neste momento. É incorreto afirmar que componentes imediatos pulam a etapa de validação. O correto é afirmar que o processamento deles é antecipado para a segunda fase. 49

13 Process Validations A terceira fase é responsável por disparar o processo de validação de cada componente. É nesse momento que o componente deve verificar, junto com os validadores, se o valor que foi armazenado na Apply Request Values é correto. Se ocorrer falha de validação, os validadores adicionam uma mensagem de erro ao FacesContext e sinalizam ao Container que o fluxo não deve seguir para a próxima fase, mas sim para a Render Response. A validação em JSF sempre é precedida pela conversão do valor, seja na Apply Request Values ou na Process Validations. Em outras palavras, os validadores dos componentes sempre validam o valor convertido para o modelo da aplicação e nunca o que está vindo na requisição HTTP (sempre em String). Update Model Values Se o processo de validação for bem-sucedido, significa que os componentes podem atualizar as propriedades dos Managed Beans que estiverem associadas aos seus valores (via Value Expression). Invoke Application É nesta fase que o evento de um botão ou link que submeteu o formulário será chamado, exceto se tiver sido marcado como imediato. Neste momento, é seguro executar a lógica da aplicação porque os valores já passaram por conversão e validação. A partir do método que processa esse evento, um Managed Bean pode sugerir qual será a próxima página a ser renderizada retornando um outcome, que é uma String que será usada para localizar uma regra de navegação. Render Response A última fase é responsável por gerar a resposta e persistir o estado da árvore de componentes para ser usada em próximas requisições. A persistência do estado da árvore pode ser no cliente ou no servidor dependendo da escolha da aplicação. Considerações finais Como se pode ver, a maioria dos maus hábitos apresentados neste artigo está intimamente ligada à carência ou ao não conhecimento dos desenvolvedores sobre o Ciclo de Vida do JSF e da arquitetura de componentes. Entender o Ciclo de Vida é obrigação de qualquer profissional que tenha a intenção de trabalhar com a tecnologia, bem como ter o mínimo de conhecimento sobre desenvolvimento Web. Dessa forma, a maioria dos maus hábitos discutidos aqui podem ser evitados. Vale ressaltar também que é importante que um arquiteto ou um desenvolvedor experiente em JSF esteja por perto para orientar uma equipe que esteja iniciando nessa tecnologia. Possuir alguns destes maus hábitos é algo completamente normal para alguém que está começando a desenvolver com JSF, principalmente se este alguém tiver vindo de um paradigma action-based. De fato, a mudança de paradigma nem sempre será um passo relativamente fácil, mas o grande objetivo deste artigo foi facilitar essa adaptação para os novos desenvolvedores. A dificuldade na mudança da filosofia action-based para component-based não difere tanto assim na dificuldade da mudança da programação procedural para programação orientada a objetos; ou do desenvolvimento Desktop para o desenvolvimento Web. Conhecer o caminho das pedras requer tempo, estudo e experiência, e obviamente que isso não acontece da noite para o dia. Referências