Rafael Ponte

Dificuldades todos temos, principalmente quando estamos aprendendo uma nova tecnologia, framework ou paradigma, e isso torna-se ainda pior quando não temos qualquer interesse em aprender sobre os mesmos.

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.

É engraçado o número de desenvolvedores que se utilizam da tag de navegação <redirect/> quando configuram suas regras de navegação no faces-config.xml sem entender o porquê de sua finalidade, na maioria das vezes a única coisa que eles tem conhecimento -e acreditam que esta é finalidade da tag- é que ao utiliza-la a url na barra de endereços do browser muda.

Depois disso eles não entendem porque os valores não existem mais no managed bean ou porque as mensagens de erro não são mais exibidas ao usuário ou mesmo porque uma nova instância do managed bean foi criada, enfim, eles não entendem porque afinal a aplicação parou de funcionar!

Tentarei com este post esclarer a diferença entre um redirect e um forward e como contornar o problema acima para que novos desenvolvedores não caiam em “maus lençóis”.

Redirect não é forward

Um servlet (controller) pode executar tanto uma operação de um redirect como de um forward no final do processamento de uma requisição, e isso influencia como as páginas no browser serão recarregadas. É importante que um desenvolvedor entenda os fundamentos por trás de uma aplicação web, e um deles é a diferença entre redirect e um forward.

Segue abaixo a diferença entre eles:

Forward

• É executado internamente pelo servlet (controller);
• O browser não sabe o que está ocorrendo durante o processamento no servidor, ou seja, não sabe por quais servlets ou páginas a requisição está passando;
• No final do processamento da requisição a url da barra de endereços do browser não muda;
• O reload da página resultante irá executar a requisição original;

Redirect

• É um processo de dois passos, ao receber uma requisição a aplicação web “pede” ao browser para acessar uma segunda url, por isso a url muda;
• O reload de página não repetirá a requisição original, mas sim a nova url (2ª requisição);
• É um processo muito mais lento que um forward, pois são necessárias duas requisições, e não uma;
• Objetos colocados no escopo do request original são perdidos durante o segundo request;

Resumindo, um redirect é uma nova requisição que o cliente (browser) faz a pedido da aplicação web, logo ele fica ciente sobre como está ocorrendo a navegação e para onde ele está sendo redirecionado, enquanto um forward pode executar várias requisições no lado servidor sem o conhecimento do cliente e no final retornar uma página qualquer. Atentem também que um forward mantém os atributos e parâmetros do request original, já um redirect não.

Como podem ver, de maneira sútil eles fazem a mesma coisa, mas são bem diferentes.

O problema

Vamos observar um caso clássico abaixo:

Imagine que temos um managed bean configurado em escopo de request e que temos uma regra de navegação no nosso faces-config.xml na qual explicitamos o uso de redirect através da tag <redirect/>:

<navigation-rule>
	<from-view-id>/pages/pageX.jsp</from-view-id>
	<navigation-case>
		<from-outcome>nova_pagina_com_redirect</from-outcome>
		<to-view-id>/pages/pageY.jsp</to-view-id>
		<redirect />
	</navigation-case>
</navigation-rule>

E em uma determinada página X o usuário clica em um botão que executa um método no managed bean e depois disso o usuário é enviado para uma outra página Y com uma mensagem de sucesso (ou erro) e alguns objetos populados no managed bean para serem exibidos, logo teríamos um método no managed bean semelhante a isso:

public String submit() {
	// processa algo
	BacalhauService.processaRequisicao();

	// popula atributo do managed bean
	this.att1 = "A ligeira raposa marrom saltou sobre o cão preguiçoso.";

	// adiciona mensagem de sucesso
	FacesContext ctx = FacesContext.getCurrentInstance();
	ctx.addMessage(null, new FacesMessage("Operação concluída com sucesso."));

	return "nova_pagina_com_redirect";
}

Imagine que quando o usuário executou a ação o processamento no método do managed bean ocorreu, a navageção para a página Y funcionou perfeitamente e a url na barra de endereços do browser mudou como previsto, mas espere um pouco! “What the hell is this?” A mensagem de sucesso e os dados contidos no managed bean não foram exibidos, onde elas foram parar afinal de contas?

No caso acima nós navegamos da página X para a página Y através de um redirect (lembram da tag <redirect/> na regra de navegação?), e já sabemos que quando há um redirect todos os dados no escopo de request são perdidos, logo o nosso managed bean e nossa mensagem de sucesso foram perdidos.

Agora que já entendemos o funcionamento do redirect não foi uma surpresa o managed bean ter sido perdido (reinstanciado) pois sabiamos que ele estava configurado com escopo de request, mas e a mensagem de sucesso? Bem, isso fica óbvio ao saber que as mensagens do JSF são adicionadas no escopo de request, mesmo que seu managed bean esteja noutro escopo.

A solução

Como resolver isso? Bem, existem algumas soluções, porém a mais simples sem dúvida é remover a tag <redirect/> da regra de navegação, assim a navegação entre páginas ocorrerá através de forward (que é o default do framework), e os dados do seu managed bean e mensagens serão exibidos ao usuário como esperado.

Na maioria das aplicações web um dos motivos para se utilizar um redirect é para evitar que no reload/refresh da página ocorra uma resubmissão do form, evitando-se assim resultados inesperados na aplicação, sendo, uma solução para isso seria a utilização do Post-Redirect-Get Pattern (PRG). Uma excelente solução é a implementação do padrão PRG através deste Phase Listener implementado pelo BalusC.

Não tenho certeza, mas acho (quase certeza) que o JBoss Seam já tem algo implemetado para solucionar o problema. Se alguém puder confirmar, eu ficaria grato

Felizmente hoje em dia as aplicações web estão caminhando para uma GUI mais rica e versátil, e ao abrir mão da “velha escola” conseguimos contornar os problemas citados acima facilmente, como também obter inúmeras outras vantagens.

Concluindo

Como podem ver, o problema não era do JavaServer Faces (JSF) ou mesmo de qualquer outro framework MVC, mas certamente da falta de fundamentos sobre a web. Espero sinceramente que os desenvolvedores busquem entender os fundamentos dos frameworks, padrões e da web antes de desenvolver uma aplicação web, pois utilizar algo nas cegas provavelmente trará vários problemas mais cedo ou mais tarde.

Enfim, este é um problema decorrente na lista de discussão do javasf, e sempre acabamos por explicar a diferença entre as duas operações, que no final resolve-se apenas seguindo o caminho mais simples. Fico aqui e espero que este post tenha servido de ajuda a muitos desenvolvedores.