Artigo Java Magazine 72 - Desenvolvendo com JavaServer Faces – Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Aprenda os fundamentos e os principais componentes para criar aplicações robustas para Web.

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

[links]Desenvolvendo com JavaServer Faces – Parte 2[/links] [rotulo-curso/]

[lead]De que se trata o artigo:

Apresentação dos principais fundamentos do JSF de maneira simples e prática. O JavaServer Faces é um framework que estabelece um padrão para criação de componentes web. Veremos ao longo do artigo o ciclo de vida, a criação de validadores, conversores e conhecer as principais tags que o framework nos oferece por padrão.

Para que serve:

Este artigo serve para desenvolvedores que desejam conhecer os conceitos básicos necessários para iniciar o desenvolvimento web com JSF. Ele fornece toda a infra-estrutura básica para criar aplicações de maneira ágil.

Em que situação o tema é útil:

As pessoas que estão iniciando com desenvolvimento JSF encontrarão neste artigo uma abordagem simples e direta dos fundamentos essenciais para desenvolver aplicações robustas voltadas à web. O desenvolvedor irá conhecer como criar uma aplicação e como configurá-la.

Desenvolvendo com JavaServer Faces – Parte 1:

O JavaServer Faces é um framework web baseado em componentes de interface gráfica. Mais do que componentes, o Faces fornece uma série de mecanismos para conversão, validação, execução de lógica de negócios e controle de navegação.

Por ser baseado em componentes, o framework possui um workflow diferenciado do modelo tradicional de aplicações web, e conhecer o ciclo de vida JSF passa a ser essencial para páginas com interfaces gráficas mais complexas.

Temos ainda diversos outros frameworks complementares que auxiliam o desenvolvedor para propósitos variados, como é o caso do RichFaces para construção de aplicações em AJAX, do Facelets para criação de templates, ou do JBoss Seam para integração de camadas. [/lead]

O JavaServer Faces é o framework para desenvolvimento de aplicações web padrão da Java EE. Ele é mantido pela Java Community Process JSR-314, que define o padrão para desenvolvimento de interfaces dentro do modelo orientado a componentes. Essa característica é, na maioria das vezes, o maior obstáculo para o aprendizado da maioria dos desenvolvedores, principalmente os que conhecem algum framework baseado em ações, como por exemplo, Struts.

A arquitetura JSF favorece o surgimento de ferramentas RAD (desenvolvimento rápido de aplicações) através da arquitetura de componentes, da infra-estrutura da aplicação e do conjunto de componentes padrões. Para a IDE Eclipse, há diversos plugins, como o WTP, o JBoss Tools e MyEclipse. Já o NetBeans oferece um suporte avançado com recursos de drag-and-drop para montagem de páginas, além de oferecer componentes mais avançados que os padrões, cabe ressaltar que estes recursos estão atrelados a um modelo de desenvolvimento que o usuário deve seguir, caso contrário os recursos são bem limitados.

Os componentes JSF são orientados a eventos, ou seja, é possível processar eventos gerados pelo cliente, como um clique no botão ou alteração do valor de campo texto. Por padrão, há um conjunto de componentes básicos para manipulação de formulários, mas o Faces oferece uma infra-estrutura para criação de novos componentes. Dentre os componentes de terceiros, os mais conhecidos são o JBoss RichFaces e Apache Tomahawk.

O presente artigo objetiva mostrar uma visão geral sobre as principais características do JSF, as quais ajudarão o leitor que está iniciando o trabalho com o framework e também aquele que já trabalha com ele. Todos os conceitos abordados serão baseados na versão 1.2, a versão oficial na data em que o artigo foi escrito. Vamos iniciar analisando o ciclo de vida do Faces, que é essencial para desenvolver interfaces mais complexas e resolver problemas que são comuns durante o desenvolvimento de uma aplicação.

[subtitulo]Como é o ciclo de vida? [/subtitulo]

Toda requisição realizada dentro do contexto JSF passa por um processo de seis fases, conhecido como ciclo de vida JSF. Em suma, durante esse processo é restaurada a árvore de componentes, os valores são lidos, convertidos e validados; eventos são executados e uma resposta é gerada para o usuário. Os eventos são executados, na grande maioria, após uma dessas seis fases.

A Figura 1 mostra o fluxo de execução de uma requisição gerada pelo cliente pelo ciclo de vida JSF. O processo inicia-se assim que a requisição é recebida pelo servlet do JSF. É importante lembrar que o JSF é construído em cima da API do Servlet.

Figura 1. Ciclo de vida JSF

[subtitulo]Restore View [/subtitulo]

A requisição é recebida pelo FacesController, que extrai a View ID usada para identificar a página JSP associada a ela. Uma View é a representação de todos os componentes que compõem uma determinada página. Uma vez que a página está em mãos, é realizada uma tentativa de restauração desta View que, geralmente, é restaurada com base em um campo oculto, ou baseada na sessão de usuário. A árvore de componentes da View é obtida através de duas formas: Initial View e Postback, que são executados de maneiras distintas.

A Initial View ocorre quando a página é acessada pela primeira vez ou quando a página é acessada via HTTP GET. O contexto JSF cria a árvore de componentes, com base na View acessada, e a mesma é gravada na propriedade viewRoot do objeto FacesContext. Esse objeto contém todas as informações relacionadas à requisição que são necessárias para manipular o estado dos componentes GUI de uma página de uma determinada requisição. Como não há nenhum valor de entrada a ser processado, o fluxo avança para a última fase, a Render Response.

Já o Postback ocorre quando o usuário interage com o formulário da página, seja alterando um valor de um campo de texto ou clicando num link ou botão. Nesses casos, a requisição é enviada para a mesma página da qual foi submetido o formulário. Como a View já existe, ela precisa ser restaurada; nesse caso, o JSF utiliza as informações restauradas para reconstrução do estado da View. Uma vez reconstruído o estado, o fluxo passa para a próxima fase do ciclo de vida.

[subtitulo]Apply Request Values [/subtitulo]

Também conhecido como processo de decodificação, a fase Apply Request Values é responsável por atribuir aos componentes o valor submetido através de parâmetros enviados no request. Todo componente que aceita a entrada de valores possui uma propriedade que recebe o valor original enviado pelo usuário. Esse valor é obtido com base no ID do componente. Um componente pode ser renderizado mais de uma vez, geralmente em virtude de uma interação. Para garantir um ID único para cada componente, o JSF adiciona como prefixo o ID do componente pai, o ID resultante é conhecido como Client Id. Por exemplo, o Client Id de uma caixa de texto com ID “nome” dentro de um formulário com ID “cadastro” será “cadastro:nome”.

Todo componente possui uma propriedade immediate que indica se o valor deve ser convertido e validado nesta fase. Já em componentes do tipo comando, como um link ou botão, essa propriedade é usada para ignorar todos os valores do formulário. Você utilizará esta opção para botões cancelar ou para links que aceitam valores de um controle específico.

Concluída a decodificação, é verificado se houve algum erro de validação ou conversão. Caso exista algum erro, o ciclo avança para a fase Render Response; caso contrário, o ciclo avança para a próxima fase.

[subtitulo]Process Validation [/subtitulo]

Nesta fase é assegurado que todos os valores enviados são válidos. A validação é desempenhada diretamente pelo componente e também pode ser delegada para um ou mais validadores. Antes disso, o valor submetido pelo usuário precisa ser convertido, o que é feito por meio de um conversor padrão ou através de um conversor específico – mais adiante veremos como implementar um conversor JSF.

Considerando o exemplo da Listagem 1, temos um campo de e-mail com validação de obrigatoriedade, por meio da propriedade required, e com validação específica por meio do validador jm.validator.emaila criação de validadores é discutida mais adiante. Primeiramente, é validado se o campo não está vazio; caso a validação falhe, é mostrada a mensagem de obrigatoriedade para o campo "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?