SubMundo Java

Tenho conversado com alguns amigos sobre os projetos que tenho participado no emprego novo e uma das dúvidas que surge é como utilizar repositórios em entidades, para tornar o domínio um pouco mais rico.

Obviamente, este POST não tem o intuito de levantar nenhuma discussão sobre como você deve tratar sua camada de persistência e o seu domínio, mas sim, mostrar como é possível injetar repositórios dentro de entidades de maneira transparente usando Spring.

Para saber mais a respeito do conceito por trás desta solução, leia este POST

O problema

Ao recuperar uma entidade (user, por exemplo) de um repositório, as dependências desta entidade devem ser injetadas manualmente dentro do método find.

Exemplo:

public User findById(Long id) {
    User user = entityManager.find(User.class, id);
    user.setUserRepository(this);
    user.setRoleRepository(...);
    user.setXXXRepository(...);
}

Você talvez queira injetar só um repositório, mas talvez não. Imagine, se ao invés de todos estes setters eu apenas usasse a annotation @ResolveDependencies no método e todas as dependências (no caso, repositórios) fossem injetadas automaticamente na entidade. Um outro problema é que a cada nova dependência (não que eu pretenda ter muitas), mais um set você tem que efetuar no método find e isso daria um pouco mais de trabalho. Além disso, muitas vezes seus repositórios já estão sendo gerenciados pelo container de injeção de dependências e você não gostaria de criar uma nova instância a cada find que efetuar.

A solução

A classe ApplicationContext do Spring possui recursos para resolver as dependências de um objeto não gerenciado pelo Spring. Desta forma, se a minha entidade User possuir um atributo chamado userRepository anotado pela annotation @Autowired (Spring) ou @Inject (JSR-330), através da chamada do método ctx.getAutowireCapableBeanFactory().autowireBean(user), todas as dependências serão injetadas. Onde, ctx é uma instância de ApplicationContext, user é uma instância de User e userRepository é uma instância de UserDAO gerenciada pelo Spring.

A seguir, as classes citadas:

UserRepository.java

public interface UserRepository {
    public User findById(Long id);
    public void save(User user);
}

UserDAO.java

@Named("userRepository")
public class UserDAO implements UserRepository {
 
    @Override
    @ResolveDependencies
    public User findById(Long id) {
        return new User(id);
    }
 
    @Override
    public void save(User user) {
        System.out.println("salvando user id=[" + user.getId() + "]");
    }
 
}

A classe UserDAO, foi anotada pela annotation @Named que faz parte da JSR-330 (Dependency Injection) suportada pelo Spring, o parâmetro passado (userRepository) é a String que identifica o DAO dentro do container de injeção de dependência (no caso, Spring). Toda classe anotada por esta anotação, será gerenciada pelo Spring.

O método save, simplemente imprime uma mensagem com o id do user.

O método findById, foi anotado pela a annotation @ResolveDependencies, que utilizaremos para indicar que a entidade retornada por este método deve ter todas as suas dependências resolvidas (injetadas).

A mágica

Como foi dito anteriormente, o Spring tem condições de resolver dependências de objetos não gerenciados pelo mesmo, desta forma, utilizaremos este recurso para o exemplo acima:

SpringUtils.java

public abstract class SpringUtils {
 
    public static void autowire(Object obj, ApplicationContext ctx) {
       ctx.getAutowireCapableBeanFactory().autowireBean(obj);
    }
 
}

Esta classe abstrata possui um método chamado autowire que, simplesmente, injeta as dependências (contidas no container, no caso, ApplicationContext) em um dado objeto (obj).

Para juntarmos tudo, utilizaremos AOP para interceptarmos os métodos anotados por @ResolveDependencies e, através da classe SpringUtils, resolvermos as dependências do objeto de retorno, conforme demostra a classe a seguir:

DetachedSpringBeanDependencyResolver.java

@Aspect
@Named
public class DetachedSpringBeanDependencyResolver {
 
    @Inject
    @Named("applicationContext")
    private ApplicationContext applicationContext;
 
    @AfterReturning(value="@annotation(br.com.submundojava.ResolveDependencies)", returning="retVal")
    public void resolve(Object retVal) throws Throwable {
 
        if(retVal != null)
            SpringUtils.autowire(retVal, applicationContext);
 
    }
 
}

Aqui complica um pouco, mas é bem simples:

@Aspect, sucintamente informa que esta classe utilizará AOP.

@Named, um objeto gerenciado pelo Spring.

@Inject + @Named(”applicationContext”), como esta classe também será gerenciada pelo Spring e no próprio Spring existe uma instância de ApplicationContext (obtida pelo nome applicationContext) podemos então injetar o applicationContext dentro do aspecto, pois o SpringUtils precisa do applicationContext para obter as instâncias que serão injetadas no objeto retornado.

@AfterReturning, indica que após o retorno do método anotado pela annotation @ResolveDependencies e antes de retornar ao cliente, o aplicativo deverá passar pelo método resolve.

Método resolve(retVal), acho que fica óbvio que retVal é o valor retornado pelo método anotado por @ResolveDependencies. No caso o retorno é uma instância de User.

SpringUtils.autowire, resolve todas as dependências contidas em applicationContext, do objeto retornado.

Para finalizar, a entidade User, a anotação @ResolveDependencies e o application-context.xml

User.java

public class User {
 
    private Long id;
 
    @Inject
    @Named("userRepository")
    private UserRepository userRepository;
 
    public User(Long id) {
        this.id = id;
    }
 
    public Long getId() {
        return id;
    }
 
    public void save() {
 
        if(userRepository == null)
            throw new IllegalStateException("userRepository == null");
 
        userRepository.save(this);
 
    }
 
}

ResolveDependencies.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ResolveDependencies {
}

application-context.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context 
http://www.springframework.org/schema/context/spring-context-3.0.xsd">
 
    <!-- Procura por classes anotadas nos sub-pacotes do base-package -->
    <context:component-scan base-package="br.com.submundojava" />
 
    <!-- Ativa suporte a aspectos -->
    <aop:aspectj-autoproxy />
 
</beans>

Executando

public static void main(String argz[]) {
 
    ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:application-context.xml");
    UserRepository repository = ctx.getBean("userRepository", UserRepository.class);
    User user = repository.findById(1L);
    user.save();
 
}

A saída deverá ser algo parecido com:

salvando user id=[1]

Conclusão

O que tentei demonstrar aqui é uma maneira simples de resolver dependências de objetos que não fazem parte do container de injeção de dependências. Esta abordagem está sendo utilizada atualmente nos meus projetos e tem solucionado uma porção de problemas.

Para ter uma melhor visualização você pode abaixar o projeto aqui. Certifique-se de ter java 5+ e maven 2 instalados.

Dúvidas, críticas ou sugestões. Deixe um comentário.

Abraços.

Na semana passada, Martin Fowler escreveu um artigo demonstrando as práticas que ele costuma utilizar ao trabalhar com expressões regulares. Neste artigo, o senhor Fowler propõe uma maneira de separar uma expressão regular em partes menores, recompondo tal expressão posteriormente para, entre outra coisas, dar maior legibilidade ao código. Ao acabar de ler o artigo a primeira coisa que veio em minha cabeça foi Fluent Interfaces. Na atualização de seu artigo, Martin Fowler cita este assunto (inclusive expôe sua preferência por não utilizar Fluent Interfaces) e sugere uma alternativa fluente criada por Joshua Flanagan para C#.

Este post não tem como  objetivo discutir se utilizar Fluent Interfaces, ou não, é a melhor maneira de resolver problemas relacionados a expressões regulares, mas sim, propor um exercício a fim de criar uma possível API fluente e, ao final do artigo, demonstrar uma pequena porção de código Java que pode solucionar alguns problemas relacionados a expressões regulares utilizando esta abordagem.

O problema

O grande problema de quando trabalhamos com expressões regulares é conhecer todos os recursos disponíveis (metacaracteres, quantificadores gananciosos, possessivos, relutantes, etc) para validarmos determinada String e posteriormente recuperarmos os grupos que nos interessa para aplicarmos a lógica que necessitamos. Além disso, quanto maior for a expressão mais difícil será de interpretá-la, por isso, utilizar a abordagem “Divisão e Conquista” é uma boa prática a ser seguida.

A solução

Criar uma API para abstrair os recursos (metacaracteres, quantificadores, etc) e disponibilizar ao usuário, métodos mais legíveis e simples de escrever. Para chegar a este fim, me propus a analisar as expressões regulares que mais utilizo no dia-a-dia, “mapeá-las” para o português estruturado e, então, escrever uma porção de código que reflita a interpretação do português estruturado o mais fluente possível.

Interpretando Expressões Regulares

Analisando uma expressão regular que tem como objetivo validar se Strings representam uma data em um formato dd/mm/aaaa (em java dd/MM/yyyy), temos:

Expressão Regular: \\d{2}/\\d{2}/\\d{4}

Português estruturado: A String em questão: Inicia com dois dígitos (numéricos), seguido de uma barra, seguido de dois dígitos (numéricos), seguido de uma barra e finaliza com quatro dígitos (númericos).

Código Java:

RegexComposer composer = RegexComposer.getInstance();
composer
    .startsWith(exactly(2, digit()))
    .followedBy(exactly(1, literal("/")))
    .followedBy(exactly(2, digit()))
    .followedBy(exactly(1, literal("/")))
    .finishedWith(exactly(4, digit()));

Parece bacana, mas não está ao contrário? Porque o quantificador vem antes do dígito no código Java e na expressão regular não? Pois ao interpretarmos a expressão regular em português estruturado, também passamos o quantificador a frente do dígito e é essa a diferença, pois, ao interpretarmos uma expressão como: \\d{2} nós não escrevemos “Esta expressão representa digítos (numéricos) dois“, e sim “Esta expressão representa dois dígitos (numéricos)”.

Este foi o meu principal questionamento quando analisei a API do senhor Joshua Flanagan, pois acredito que ao utilizarmos a abordagem fluente, devemos valorizar a maneira  como escreveríamos em uma língua (português/inglês) e não como é a sintaxe de uma determinada linguagem (de programação).

Delimitadores

Uma ocorrência constante (inclusive citado no artigo do Martin Fowler) é a utilização de delimitadores para separarmos os dados em Strings (tokens). São exemplos disto, os arquivos CSV (valores separados por vírgula) e também a data do exemplo anterior (separados por barra “/”). Desta forma, seria conveniente se pudessemos configurar a API para interpretar delimitadores. A seguir, demostro um exemplo de como isto poderia ser feito:

Expressão Regular: \\d{2}/\\d{2}/\\d{4}

Português estruturado: A String em questão: Inicia com dois dígitos (numéricos), seguido de dois dígitos (numéricos), finaliza com quatro dígitos (númericos) e é delimitada por uma barra.

Código Java:

RegexComposer composer = RegexComposer.getInstance();
composer
    .startsWith(exactly(2, digit()))
    .followedBy(exactly(2, digit()))
    .finishedWith(exactly(4, digit()))
    .delimitedBy(exactly(1, literal("/")));

Tá começando a melhorar, mas existe um recurso muito importante que deve ser considerado, os agrupamentos.

Agrupamentos

Os agrupamentos em Java são efetuados através inserção da expressão em parênteses, isto possibilita recuperar a String de determinado grupo uma vez que foi validado que a String se encontra no padrão requerido. A seguir demonstro uma maneira que, inicialmente, acreditei ser adequada para este fim.

Imagine que, após validar uma determinada data, você queira recuperar o dia, mês e ano separadamente para efetuar alguma lógica, então, teríamos algo como:

Expressão Regular: (\\d{2})/(\\d{2})/(\\d{4})

Português estruturado: A String em questão: Inicia com dois dígitos (numéricos) agrupados, seguido de dois dígitos (numéricos) agrupados, finaliza com quatro dígitos (númericos) agrupados e é delimitada por uma barra.

Código Java:

RegexComposer composer = RegexComposer.getInstance();

Pattern p = composer
                 .startsWith(exactly(2, digit()).grouped())
                 .followedBy(exactly(2, digit()).grouped())
                 .finishedWith(exactly(4, digit()).grouped())
                 .delimitedBy(exactly(1, literal("/")))
                 .compile();

Matcher matcher = p.matcher("05/01/1979");

if(matcher.matches()) {

    System.out.println("Dia: " + matcher.group(1));
    System.out.println("Mes: " + matcher.group(2));
    System.out.println("Ano: " + matcher.group(3));

} else {

     System.out.println("Formato invalido");

}

Legal, ao menos à primeira vista, entretanto eu ainda precisaria saber em qual grupo está o dia (matcher.group(1)), o mês (matcher.group(2)) e o ano (matcher.group(3)) e isto não é muito bacana. Creio que o ideal seria criarmos um alias para cada grupo e depois recuperarmos o número do grupo através do alias. Seria algo como .startsWith(exactly(2, digit()).grouped(usingAlias(”dia”))) e depois recuperarmos o grupo usando matcher.group(composer.getAliasGroup(”dia”)). Uma outra questão é que há outra interpretação para expressões agrupadas, por exemplo, “A String em questão: Inicia com um grupo de dois dígitos …”. Isto quer dizer que escreveriamos algo como: .startsWith(groupOf(exactly(2, digit())).usingAlias(”dia”)).

Embora eu considere estas opções adequadas, não escrevi nada disso ainda. No exemplo, a seguir, irei demonstrar um pouco mais de detalhes do que já implementei.

Exemplo prático

Utilizando o exemplo que o Martin Fowler deu em seu artigo, irei validar se a String “score 400 for 2 nights at Minas Tirith Airport” se encontra no padrão correto e ,após isto, recuperar os números 400 e 2.

Código Java:

import br.com.submundojava.regexcomposer.RegexComposer;
import static br.com.submundojava.regexcomposer.quantifier.Quantifiers.*;
import static br.com.submundojava.regexcomposer.value.MetaCharacters.*;
import java.util.regex.Pattern;
import java.util.regex.Matcher;

/**
 *
 * @author Henrique Lima
 */
public class Test {

    public static void main(String argz[]) {

        RegexComposer composer = RegexComposer.getInstance();

        Pattern pattern = composer
                        .startsWith(exactly(1, literal("score")))
                        .followedBy(oneOrMore(digit()).grouped())
                        .followedBy(exactly(1, literal("for")))
                        .followedBy(oneOrMore(digit()).grouped())
                        .followedBy(exactly(1, literal("night")))
                        .followedBy(zeroOrOne(literal("s")))
                        .followedBy(exactly(1, literal("at")))
                        .delimitedBy(zeroOrMore(whiteSpace()))
                        .finishedWith(oneOrMore(any()))
                        .compile();

        Matcher matcher = pattern.matcher("score 400 for 2 nights at Minas Tirith Airport");

        if (matcher.matches()) {

            System.out.println(matcher.group(1));
            System.out.println(matcher.group(2));

        } else {
            System.out.println("Formato inválido");
        }

    }

}

Muito simples! Veja que não utilizamos nenhum metacaracter, nenhum quantificador, agrupamos os dados necessários e ainda utilizamos um delimitador. Uma pessoa nem precisaria conhecer de expressões regulares para validar a String (embora seja desejável).

Perceba que novas coisas aconteceram e utilizamos import static do Java 5 para disponibilizarmos os métodos necessários à nossa classe. Além disso, utilizamos novos métodos quantificadores (não regex) que são: zeroOrMore(), para zero ou mais ocorrências (análogo a *), oneOrMore(), para uma ou mais ocorrências (análogo a +), zeroOrOne() para zero ou uma ocorrência (análogo a ?) e por final utilizamos o método compile() para obtermos um objeto do tipo java.util.regex.Pattern para podermos validar a String.

Código fonte

Abaixo segue o projeto que criei para efetuar este post.

Para netbeans: download
Para eclipse: download

Considerações Finais

Procurei demonstrar uma maneira fluente de trabalhar com expressões regulares, abstraindo seus recursos e disponibilizando métodos de alto nível. O exemplo que escrevi ainda está muito “verde”, com nomes esquisitos para algumas classes, métodos e pacotes. Na verdade, em alguns casos, nem sei se o inglês está correto.

Além disso, existem muitas limitações, por exemplo, se eu quiser usar um delimitador e ao mesmo tempo validar um dos tokens com um outro RegexComposer, não é possível. Seria desejável poder aninhar RegexComposer’s para este fim. Outro detalhe é que os métodos da classe RegexComposer recebem sempre uma instância de Quantifier e deveriam receber uma instância de uma classe com um nome mais adequado, como Expression ou ExpressionGroup. Detalhes a serem resolvidos.

Aguardo seus comentários e quem quiser entrar em contato, meu twitter é hgflima

Um abraço.

Na verdade, quero ser breve neste POST. A questão é que ontem comecei a escrever um novo POST e precisei instalar o eclipse numa máquina antiga e depois de alguns minutos trabalhando lentamente o tão temido “permgen” (para os íntimos) apareceu. Toda vez que isso aconteceu eu preciso entrar no google e lembrar dos valores que eu utilizava para a minha máquina. Segue abaixo o meu eclipse.ini.

-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms128m
-Xmx512m
-XX:MaxPermSize=128m

E se por um acaso alguém quiser saber mais detalhes sobre este problema, recomendo a leitura do POST dreaded “java.lang.OutOfMemoryError: PermGen space” error.

Foi liberado ontem (17/12/2007) mais uma nova versão do conjunto de componentes para JSF conhecido como JBoss RichFaces. Nesta nova versão foram corrigidos dezenas de bugs, aperfeiçoados alguns componentes, atualizados os frameworks Prototype e script.aculo.us(para 1.6.0 e 1.8.0 respectivamente), além da adição de 4 novos componentes: Ordering List, List Shuttle, Component Control e Context Menu. Para mais informações sobre as novidades desta versão leia o WhatsNew. Faça download dos fontes, binários e documentação na página oficinal.

Introdução

Dando continuidade ao meu último POST, estarei apresentando uma maneira simples de trabalhar com Ajax utilizando componentes JSF.
As aplicações que usufruem de recursos Ajax têm evoluído de diversas maneiras nos últimos tempos e um dos aspectos importantes é a produtividade. Quando iniciei os meus estudos sobre Ajax, era necessário escrever uma quantidade significativa de código javascript, manipulando o objeto XmlHttpRequest diretamente, além de uma porção adicional de código em alguma linguagem server side (para gerar XML dinamicamente). Depois de um certo tempo vieram os frameworks javascript que diminuiram a quantidade de código a ser escrito e atualmente é possível desenvolver aplicações inteiras sem utilizar nenhum código javascript, através dos componentes do RichFaces (entre outros).

Requisitos

Antes de seguir os passos aqui descritos, é recomendável que você leia o POST Java Server Faces 1.2 Hello World ou tenha conhecimentos compatíveis.

Configurando o ambiente

Para rodar aplicações Java Server Faces 1.2 é necessário um container que implemente a especificação da JSP 2.1. Para este tutorial iremos utilizar o container Tomcat 6.0.
Download: http://tomcat.apache.org/download-60.cgi

Além dos jars para rodar o Java Server Faces 1.2 serão necessários mais 3 jars do RichFaces. Quando este POST foi escrito a versão mais recente do RichFaces era a 3.1.2. Desta forma, os nomes dos jars são: richfaces-api-3.1.2.GA.jar, richfaces-impl-3.1.2.GA.jar e richfaces-ui-3.1.2.GA.jar e se encontram dentro da pasta lib do arquivo disponível para download.
Download: http://labs.jboss.com/jbossrichfaces/downloads/

Para configurar o RichFaces serão necessárias algumas pequenas modificações no web.xml demonstrado no POST Java Server Faces 1.2 Hello World. A listagem 1 apresenta o código completo do novo web.xml.

Listagem 1

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/webapp_2_5.xsd">
<display-name>JSFAjax</display-name>

	<context-param>
		<param-name>com.sun.faces.verifyObjects</param-name>
		<param-value>true</param-value>
	</context-param>

	<context-param>
		<param-name>com.sun.faces.validateXml</param-name>
		<param-value>true</param-value>
	</context-param>

	<context-param>
		<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
		<param-value>clien+t</param-value>
	</context-param>

	<context-param>
		<param-name>org.richfaces.SKIN</param-name>
		<param-value>blueSky</param-value>
	</context-param>

	<filter>
		<display-name>RichFaces Filter</display-name>
		<filter-name>richfaces</filter-name>
		<filter-class>org.ajax4jsf.Filter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>richfaces</filter-name>
		<servlet-name>Faces Servlet</servlet-name>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>INCLUDE</dispatcher>
	</filter-mapping>

	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>/faces/*</url-pattern>
	</servlet-mapping>

	<welcome-file-list>
		<welcome-file>faces/index.jsp</welcome-file>
	</welcome-file-list>

</web-app>

Um novo parâmetro de contexto foi adicionado para configurar qual skin o RichFaces irá utilizar. Por padrão, podem ser utilizados 8 valores: DEFAULT, plain, emeraldTown, blueSky, wine, japanCherry, ruby, classic e deepMarine. É possível criar novas skins e modificar os estilos dos componentes através de CSS, entretanto, este assunto será abordado em uma outra oportunidade.
Para utilizar o restante dos recursos do RichFaces o filtro org.ajax4jsf.Filter deverá ser configurado. Existem algumas opções de configuração e até diferentes tipos de configurações para um grupo de páginas. Para maiores detalhes sobre configurações dos filtros do RichFaces utilize a seção 5.5 – Filter Configuration da documentação.

Criando o javabean

Utilizaremos um simples javabean para efetuarmos um CRUD. Na listagem 2 será apresentado a classe Contato.java que deverá ser criada no pacote br.com.jsfajax.entity.

Listagem 2

package br.com.jsfajax.entity;

import java.util.Date;

public class Contato {

	private String nome;
	private Date dataNascimento;
	private String email;

	public String getNome() {
		return nome;
	}

	public void setNome(String nome) {
		this.nome = nome;
	}

	public Date getDataNascimento() {
		return dataNascimento;
	}

	public void setDataNascimento(Date dataNascimento) {
		this.dataNascimento = dataNascimento;
	}

	public String getEmail() {
		return email;
	}

	public void setEmail(String email) {
		this.email = email;
	}

}

Criando o Bean Gerenciado (Managed Bean ou Backing Bean)

Crie no pacote br.com.jsfajax.web.mbean o arquivo ContatoManager.java conforme demostra a listagem 3.

Listagem 3

package br.com.jsfajax.web.mbean;

import br.com.jsfajax.entity.Contato;

import java.util.ArrayList;
import java.util.List;

import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.faces.event.ActionEvent;
import javax.faces.model.DataModel;
import javax.faces.model.ListDataModel;

public class ContatoManager {

	private Contato contato;
	private List<Contato> contatos;
	private DataModel contatosData;

	public ContatoManager() {

		contato = new Contato();
		contatos = new ArrayList<Contato>();
		contatosData = new ListDataModel(contatos);

	}

	public Contato getContato() {
		return contato;
	}

	public void setContato(Contato contato) {
		this.contato = contato;
	}

	public List<Contato> getContatos() {
		return contatos;
	}

	public void setContatos(List<Contato> contatos) {
		this.contatos = contatos;
	}

	public DataModel getContatosData() {
		return contatosData;
	}

	public void setContatosData(DataModel contatosData) {
		this.contatosData = contatosData;
	}

	public void salvar(ActionEvent e) {

		// Se o contato já existia antes na lista de contatos, atualiza os dados. Do contrário adiciona.
		if(contatos.contains(contato))
			contatos.set(contatos.lastIndexOf(contato), contato);
		else
			contatos.add(contato);

		// Zera o contato para que os campos do formulário sejam limpos.
		contato = new Contato();

		// Cria uma nova mensagem de informação para o JSF
		FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_INFO,
							"Contato adicionado com sucesso!",
							"Contato adicionado com sucesso!");

		// Adiciona a mensagem ao formulário de cadastro
		FacesContext.getCurrentInstance().addMessage("formularioCadastro", message);

	}

	public void deletar(ActionEvent e) {
		contatos.remove((Contato)contatosData.getRowData());
	}

	public void editar(ActionEvent e) {
		contato = (Contato)contatosData.getRowData();
	}

	public boolean isRendered() {
		return !contatos.isEmpty();
	}

}

Configurando o Bean Gerenciado no faces-config.xml

Adicione ao faces-config.xml o código conforme demonstra a listagem 4:

Listagem 4

<managed-bean>
	<managed-bean-name>contatoManager</managed-bean-name>
	<managed-bean-class>br.com.jsfajax.web.mbean.ContatoManager</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

Criando a página JSP

Crie um arquivo chamado index.jsp, no diretório WEB-INF/ de sua aplicação WEB, com o conteúdo demonstrado na listagem 5.

Listagem 5

<%@ taglib uri="http://richfaces.org/a4j" prefix="a4j"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://richfaces.org/rich" prefix="rich"%>
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
		<title>Contato CRUD</title>
	</head>
	<body>
	<f:view>
          <h:form id="formularioCadastro">
         	<rich:panel id="cadastro" header="Cadastro de Contatos">
         		Nome:
         		<h:inputText value="#{contatoManager.contato.nome}" id="nome" required="true"
				requiredMessage="Digite o nome corretamente!"/> <br />
         		Data Nascimento (dd/mm/aaaaa):
         		<h:inputText value="#{contatoManager.contato.dataNascimento}" id="dataNascimento"
				required="true" requiredMessage="Digite a data de nascimento!"
				converterMessage="Digite a data de nascimento no formato correto!">
         			<f:convertDateTime pattern="dd/MM/yyyy"  />
         		</h:inputText> <br />
         		E-mail:
			<h:inputText value="#{contatoManager.contato.email}" id="email" required="true"
				requiredMessage="Digite o e-mail corretamente!"/> <br />
         		<a4j:commandButton value="Salvar"  actionListener="#{contatoManager.salvar}"
				reRender="cadastro,formularioLista" /><br /><br />
         		<h:messages errorStyle="color:red" infoStyle="color:#5ac67e"  />
         	</rich:panel>
           </h:form>
           <h:form id="formularioLista">
           	<rich:dataTable value="#{contatoManager.contatosData}" var="contato"
			id="listaContatos" rendered="#{contatoManager.rendered}">
           		<h:column>
				<f:facet name="header">
					<h:outputText value="Nome" />
				</f:facet>
				<h:outputText value="#{contato.nome}"/>
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="Data Nascimento" />
				</f:facet>
				<h:outputText value="#{contato.dataNascimento}">
					<f:convertDateTime pattern="dd/MM/yyyy"/>
				</h:outputText>
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="E-mail" />
				</f:facet>
				<h:outputText value="#{contato.email}"/>
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="Editar" />
				</f:facet>
				<a4j:commandLink value="Editar"
					actionListener="#{contatoManager.editar}" reRender="cadastro"/>
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="Deletar" />
				</f:facet>
				<a4j:commandLink value="Deletar"
					actionListener="#{contatoManager.deletar}" reRender="listaContatos"/>
			</h:column>
           	</rich:dataTable>
           </h:form>
        </f:view>
     	</body>
</html>

Conforme demonstrado na listagem 5, serão utilizadas mais duas taglibs responsáveis pelas funcionalidades Ajax, http://richfaces.org/a4j representada pelo apelido a4j e http://richfaces.org/rich representada pelo apelido rich.
Foram utilizados 2 formulários pois todo formulário com campos cujo atributo required possua o valor true só pode ser submetido se tais campos estiverem preenchidos. Desta forma, se os botões de editar e deletar (quando em um mesmo form) forem acionados e os campos (com required=true) estiverem vazios uma mensagem de erro será apresentada.
O atributo requiredMessage do componente h:inputText é utilizado para configurar a mensagem de erro a ser apresentada quando este campo não for preenchido e seu atributo required possuir o valor true.
O converter f:converterDateTime é utilizado para transformar a String digitada (no campo em que este converter for aplicado) em um objeto do tipo java.util.Date e vice-versa.
O atributo converterMessage do componente h:inputText é utilizado para configurar a mensagem de erro a ser apresentada quando não for possível efetuar a conversão da String para o objeto java.util.Date ou vice-versa.
Os componentes commandButton e commandLink do a4j serão responsáveis por efetuar as chamadas assíncronas. No atributo actionListener destes componentes é configurado qual método do managed bean será executado. No atributo reRender será configurado quais componentes serão atualizados depois de ser executado o método do managed bean. Desta forma, quando o botão salvar for pressionado o método salvar do managed bean será executado e o componente cujo ID é listaContatos será atualizado com um novo registro.
O componente h:messages é reponsável por apresentar as mensagens adicionadas ao FacesContext através da classe FacesMessage.
É possível customizar os estilos CSS das mensagens em função do tipo de mensagem. Um FacesMessage pode ser classificada em 4 tipos:

• FacesMessage.SEVERITY_ERROR – Indica que um erro ocorreu.
• FacesMessage.SEVERITY_FATAL - Indica que um erro grave ocorreu.
• FacesMessage.SEVERITY_INFO - Mensagem com caráter informativo.
• FacesMessage.SEVERITY_WARN - Indica que um erro pode ter acontecido.

Para utilizar estilos de CSS diferente para cada tipo de mensagem existem atributos correspondentes no componente h:messages, são eles: errorClass, fatalClass, infoClass, warnClass, errorStyle, fatalStyle, infoStyle e warnStyle. Estes atributos são correspondentes aos atributos style e class dos componentes html.

Considerações Finais

Através da utilização de componentes JSF é possível ganhar produtividade, diminuindo a quantidade de código e, na maioria das vezes, ganhar performance. Entretanto, em muitas situações isto não ocorre, devido a grande quantidade de chamadas assíncronas, consultas à base de dados desnecessárias, utilização indevida de session entre outros fatores. Em uma próxima oportunidade darei continuidade a este POST adicionando recursos da Java Persistence API e mostrando como otimizar o desempenho desta pequena aplicação.

Requisitos

Será necessário o conhecimento dos seguintes itens para a criarmos nosso primeiro exemplo:

1. Nível básico de conhecimento de orientação a objetos utilizando Java.
2. Nível básico de conhecimento na criação de aplicações WEB utilizando Tomcat, de preferência versão 6.0.
3. Manipulação de bibliotecas jar. (Utilizando IDE ou não).
4. Nível básico de conhecimento de HTML e XML.

Configurando o ambiente

Para rodar aplicações Java Server Faces 1.2 é necessário um container que implemente a especificação da JSP 2.1.

Para este tutorial iremos utilizar o container Tomcat 6.0.
Download: http://tomcat.apache.org/download-60.cgi

Serão necessários 8 arquivos jars que devem estar no classpath ou no diretorio WEB-INF/lib de sua aplicação WEB, são eles:

• jsf-api.jar e jsf-impl.jar
  Download: https://javaserverfaces.dev.java.net/download.html
• commons-beanutils.jar
  Download: http://commons.apache.org/downloads/download_beanutils.cgi
• commons-colletions.jar
  Download: http://commons.apache.org/downloads/download_collections.cgi
• commons-logging.jar
  Download: http://commons.apache.org/downloads/download_logging.cgi
• commons-diggester.jar
  Download: http://commons.apache.org/downloads/download_digester.cgi
• jstl.jar e standard.jar (Standard Taglib)
  Download: http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi

Para que o Java Server Faces funcione adequadamente se faz necessário a configuração do Faces Servlet para que este
atenda às requisições das páginas JSF. A Listagem 1 mostra um exemplo de configuração do web.xml.

Listagem 1

<?xml version="1.0" encoding="UTF-8"?><web-app version="2.5"

xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/webapp_2_5.xsd">

<context-param>

 	<param-name>com.sun.faces.verifyObjects</param-name>

 	<param-value>true</param-value>

</context-param>

<context-param>

 	<param-name>com.sun.faces.validateXml</param-name>

 	<param-value>true</param-value>

</context-param>

<context-param>

 	<param-name>javax.faces.STATE_SAVING_METHOD</param-name>

 	<param-value>client</param-value>

</context-param>

<servlet>

<servlet-name>Faces Servlet</servlet-name>

<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>Faces Servlet</servlet-name>

<url-pattern>/faces/*</url-pattern>

</servlet-mapping>

<welcome-file-list>

<welcome-file>faces/index.jsp</welcome-file>

</welcome-file-list>

</web-app>

Como pode-se observar foram configurados 3 parâmetros de contexto. A utilidade destes será descrita a seguir:

• com.sun.faces.verifyObjects
  Esta flag é configurada como true quando se quer que implementação do Java Server Faces verifique se os objetos da aplicação
  (conversores, etc) foram criados adequadamente. Seu valor padrão é false, por afetar a performance no início da execução
  da aplicação.
• com.sun.faces.validateXml
  Esta flag é configurada como true quando se quer que a implementação do Java Server Faces verifique a integridade do arquivo
  faces-config.xml em função do seu DTD correspondente. Seu valor padrão é false.
• javax.faces.STATE_SAVING_METHOD
  Esta flag é usada para configurar em que lado da aplicação o estado da “view” deve ser salvo.
  Existem 2 valores possíveis: server e client. Quando configurado como client o estado de toda camada de visão será renderizado
  em um campo hidden na página jsp. Seu valor padrão é server.

Criando o Bean Gerenciado (Managed Bean ou Backing Bean)

O Bean Gerenciado é a camada de negócios das aplicações JSF. Sua principal função é compartilhar seus atributos e métodos
com as páginas JSP. Cada campo de um formulário da página JSP é integrado com uma atributo e cada ação e/ou evento
com um método do Bean Gerenciado, resultando numa ótima separação da camada de negócio da camada de visão. Crie no
pacote br.com.jsftutorial o arquivo HelloWorldBean.java conforme demostra a listagem 2.

Listagem 2

package br.com.jsftutorial;public class HelloWorldBean {private String nome;

public HelloWorldBean() {

}

public String getNome() {

return nome;

}

public void setNome(String nome) {

this.nome = nome;

}

public String acao() {

return "sucesso";

}

}

Todo Bean Gerenciado deve possuir o construtor default (sem nenhum argumento), do contrário será lançado uma java.lang.InstantiationException.
Todo atributo integrado à página JSP deverá possuir seus métodos setters e getters mesmo que seu modificador de visibilidade
seja public, como por exemplo o atributo nome do HelloWorldBean.

Configurando o Bean Gerenciado no faces-config.xml

O arquivo faces-config.xml é o arquivo de configuração do Java Server Faces.
Este arquivo deve estar na pasta WEB-INF/ de sua aplicação e contém entre outras configurações as declarações dos Beans Gerenciados que deverão ser instanciados pela
implementação do JSF. Na listagem 3 é apresentado um modelo típico de configuração de um Bean Gerenciado.

Listagem 3

<?xml version='1.0' encoding='UTF-8'?>

<faces-config version="1.2"

 	xmlns="http://java.sun.com/xml/ns/javaee"

 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

 	http://java.sun.com/xml/ns/javaee/webfacesconfig_1_2.xsd">

<managed-bean>

<managed-bean-name>hwBean</managed-bean-name>

<managed-bean-class>br.com.jsftutorial.HelloWorldBean</managed-bean-class>

<managed-bean-scope>request</managed-bean-scope>

</managed-bean>

</faces-config>

Entre as tags <faces-config> e </faces-config> se localizam toda a configuração da aplicação JSF.
A configuração necessária para um Bean Gerenciado é bem intuitiva, abaixo segue a descrição das tags utilizadas:

• managed-bean
  Toda a configuração de um, e apenas um, Bean Gerenciado deve estar contido nesta tag.
• managed-bean-name
  Nome utilizado para referenciar o Bean Gerenciado nas páginas JSP.
• managed-bean-class
  O caminho completo para a classe que representa este Bean Gerenciado.
• Managed-bean-scope
  Indica de qual escopo (scope) este Bean Gerenciado será resgatado. Existem 4 tipos possíveis.
  • none
    Só poderá ser utilizado como propriedade de um outro managed bean.
  • request
    Estará disponível através do request, ou seja, seu tempo de vida acaba após a submissão do formulário.
  • session
    Estará disponível através da session, ou seja, seu tempo de vida é o mesmo que o tempo de vida da session configurada no web.xml.
  • application
    Estará disponível através do objeto application, ou seja, seu tempo de vida é o mesmo da aplicação.

Existem outras tags que adicionam funcionalidades ao Bean Gerenciado, aconselho a utilizar o
Java (TM) EE 5 tutorial capítulo 5 item Backing Beans que pode ser acessado
através da url http://java.sun.com/javaee/5/docs/tutorial/doc/.

Criando o index.jsp

Crie a página index.jsp na pasta de arquivos WEB (mesma altura que WEB-INF/ e META-INF/) de sua aplicação com o conteúdo da Listagem 4.

Listagem 4

<%@page contentType="text/html"%><%@page pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>

<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>Java Server Faces Tutorial</title>

</head>

<body>
	<f:view>
<h:form id="formulario">
<b>Nome:</b>
<h:inputText id="nome" value="#{hwBean.nome}" required="true" requiredMessage="O campo nome deve ser preenchido!"/>
<h:commandButton value="GO" action="#{hwBean.acao}" /><br>
<h:message for="nome" errorStyle="color:red"/>
</h:form>
</f:view>
</body>
</html>

Nas linhas 3 e 4 temos as declarações das taglibs core e html do Java Server Faces que serão utilizadas para criarmos os
componentes na página JSP.

A tag <f:view> deve conter os componentes JSF.

A tag <h:form> é análogo a tag <form> do html.

Através da tag <h:inputText> será criado um componente input do html e do tipo text (<input type=”text”>).
O atributo value permite integrar o valor deste componente a uma propriedade do Managed Bean, ou seja, quando o formulário for
submetido o valor deste componente será copiado para a propriedade “nome” do Managed Bean configurado no faces-config.xml
cujo o nome foi configurado como hwBean (<managedbean-name>hwBean</managed-bean-name>). O atributo
required determina que o formulário não poderá ser submetido caso este campo não seja preenchido.
O atributo requiredMessage determina a mensagem de erro que será apresentada caso, ao submeter o formulário, este componente não seja preenchido.

Através da tag <h:commandButton> será criado um componente button do html (<input type=”button”>).
O atributo action determina o método do Managed Bean que será executado quando este botão for pressionado.

A tag <h:message> é um componente utilizado para apresentar as mensagens ao usuário. O atributo “for” deve ser
preenchido com o id do componente que desejamos que esta mensagem seja integrada, ou seja, serão apresentadas as
mensagens referentes apenas ao campo cujo o id é “nome” do formulário. O atributo errorStyle permite aplicarmos um estilo
CSS ao componente quando a mensagem for de erro.

Criando o resultado.jsp

Crie a página resultado.jsp na pasta de arquivos WEB (mesma altura que WEB-INF/ e META-INF/) de sua aplicação com o conteúdo da Listagem 5.

Listagem 5

<%@page contentType="text/html"%><%@page pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>

<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>Java Server Faces Tutorial</title>

</head>

<body>

<f:view>

Ola, <h:outputText value="#{hwBean.nome}" />!

</f:view>

</body>

</html>

Criando o fluxo do aplicativo

Para determinarmos o fluxo do aplicativo adicionamos uma “navigation rule” ao faces-config.xml.
Ao executarmos o método acao() do Managed Bean, a String “sucesso” será retornada e pela “navigation rule” determinamos que a página resultado.jsp
deverá ser apresentada. A listagem 6 demonstra o conteúdo do faces-config.xml.

Listagem 6

<?xml version='1.0' encoding='UTF-8'?>

<faces-config version="1.2"

xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/webfacesconfig_1_2.xsd">

<managed-bean>

<managed-bean-name>hwBean</managed-bean-name>

<managed-bean-class>br.com.jsftutorial.HelloWorldBean</managed-bean-class>

<managed-bean-scope>request</managed-bean-scope>

</managed-bean>

<navigation-rule>

<navigation-case>

<from-outcome>sucesso</from-outcome>

<to-view-id>/resultado.jsp</to-view-id>

</navigation-case>

</navigation-rule>

</faces-config>

Após a submissão do formulário, a propriedade “nome” do Managed Bean terá o valor digitado no componente <h:inputText> do index.jsp,
então a página resultado.jsp será apresentada (conforme configurado no faces-config.xml).
Para testar a aplicação inicie o tomcat e acesse a url: http://localhost:8080/HelloJSF/faces/index.jsp

Próximos Passos

Existem ainda diversos recursos e componentes do JSF, aconselho a leitura da referência da API,
acessando a url http://java.sun.com/javaee/javaserverfaces/reference/api/index.html.
Além disso, existem outras ótimas implementações que disponibilizam novos componentes e
recursos como a utilização de Ajax e DOM na renderização das páginas. Recomendo o estudo do IceFaces e do Ajax4Jsf, ambos open source.

Conclusão

Apesar de muita discussão sobre a qualidade dos diversos frameworks open source do mercado, Java Server Faces se apresenta
como uma ótima opção no desenvolvimento de interfaces para aplicações JEE. Com a inclusão deste framework na JEE 5,
existe uma grande tendência ao crescimento de sua utilização o que torna indispensável o conhecimento de seus recursos e
de suas diversas implementações. Neste tutorial foi abordado o conceito básico do funcionamento deste framework e em
uma nova oportunidade voltarei a escrever sobre esta tecnologia. Até lá.