Para que tu quer entender isso? Desenvolvedores não pensam, desenvolvedores seguem casos de uso. Programadores só deveriam pegar o caso de uso, ler e seguir o que ele diz, nada mais. Não há porquê entender as regras de negócio, o caso de uso tem tudo que se precisa saber. Blah blah blah..

Wow! Depois de ouvir isso eu me calei por alguns segundos e pensei comigo mesmo, “Será que ele tem noção do que acabara de me dizer?”, e o pior é que este analista disse isso com uma certa arrogância, na frente de outros analistas (que calados pareciam concordar), logo começamos a discutir, eu tentando dizer que não havia fundamentos no comentário dele e que eu não entendia como ele acreditava naquilo.. depois de alguns minutos eu resolvi encerrar a discussão para evitar constrangimentos para ambos (pois estávamos no cliente).

Parece brincadeira, mas aquilo aconteceu mesmo (eu deveria estar realmente surpreso?!). Pergunto-me como em pleno ano da graça de 2008 um analista com anos de experiência em diversos projetos, formado em uma das melhores universidades do estado, e com certeza com mais alguns (ou até vários) diplomas e certificados debaixo do braço consegue verbalizar tamanha asneira. Mais incrível ainda é como um analista desses consegue acreditar tão fervorosamente que está certo, como ele consegue acreditar que um desenvolvedor é apenas mais um recurso comum para um trabalho manual, e facilmente substituível dentro da famigerada fábrica de software que ele tanto venera, alias, qual é a dificuldade em compreender que um programador não é um “digitador de luxo”? Será que depois de tanto tempo de profissão ele ainda não entendeu que desenvolver software é essencialmente um ato de criação? É, parece que não.

Um desenvolvedor mais do que ninguém deve entender sobre o negócio do cliente, um desenvolvedor deve estar mergulhado no negócio na qual pretende desenvolver o software ou parte dele, de fato, como será que este analista imagina que um desenvolvedor pode implementar algo minimamente decente sem entender o problema? Através da ajuda de alguma entidade sobrenatural?

No fundo, acho que ouvir isso de qualquer profissional no ramo de desenvolvimento de software é um absurdo, e para mim está óbvio que esta pessoa precisa urgentemente voltar a estudar sobre o assunto (pois ela parou de estudar há muito tempo, 10 anos talvez), e claro, mais do nunca ela precisa de uma “reciclagem”.

Engraçado é que este fato me fez lembrar de um acontecimento um tanto quanto embaraçoso interessante que ocorreu no inicio da minha carreira como desenvolvedor, há mais de 3 anos, eu possuía menos que um ano de experiência na época, e havia enviado o currículo a uma empresa que estava ofertando uma oportunidade para desenvolvedor Java, parecia uma boa empresa, depois de enviado o currículo eu recebi uma ligação alguns dias mais tarde para uma entrevista, na época eu fiquei super excitado, e parei para rever meu currículo cuidadosamente, ao reler o currículo vi que não sabia exatamente sobre o que se tratava 2 (dois) projetos na qual havia participado na primeira empresa que trabalhei, eu tinha uma vaga e distante idéia do que havia desenvolvido (em termos do negócio do cliente), mas ainda assim eu não conseguiria explicar a alguém (principalmente a quem fosse me entrevistar) sobre a finalidade dos projetos.

Então durante a semana, eu -na minha mais pura ingenuidade- enviei um e-mail ao meu antigo chefe (que além de ser um empresário, ele também era um talentoso desenvolvedor e amigo) pedindo informações sobre o que se tratavam os projetos que eu havia participado. A resposta dele não foi bem a que eu esperava [rs], porém me abriu os olhos na época. Alguns trechos do e-mail seguem abaixo:

De:rponte@gmail.com Para:boss

Fala amegão,

[...] Seguinte, tu pode me passar um resumo pequeno mesmo, porém decente das aplicações que eu participei ai na empresa para que eu possa colocar no currículo, pode? :))) [...]
De ante mão eu te agradeço, abraços.

De:boss Para:rponte@gmail.com

Você não sabe pra que serviam os projetos que participou? rs Então não vale a pena colocar no currículo né? Você coloca que nesses projetos só fez programação pura.

Depois desse e-mail eu fiquei realmente envergonhado, vi que por mais que gostasse de desenvolver software eu não me interessava pelo negócio do cliente, eu não me interessava em entender e aprender sobre ele, o que sempre me interessava eram as tecnologias e os frameworks mais “hypes” do mercado. Entendendo como funcionava o mais novo framework da época já valia a pena estar desenvolvendo algo.

A partir dai, eu resolvi mudar isso, foi um processo lento mas contínuo, graças a certos amigos, blogs (Shoes, Guilherme etc), discussões em listas e fóruns, e muitas linhas de código mal implementadas (claro, como eu poderia implementar algo decente sem entender o problema?) eu procurei compreender sobre o problema do cliente e como expressa-lo em código, eu procurei ler sobre metodologias agéis, abordagens e boas práticas de design de software, maneiras de melhorar a comunicação entre os membros da equipe e várias outras coisas que me ajudaram e me ajudam até hoje.

Depois de tudo que eu estudei e procurei aprender eu ainda tenho que ouvir de um analista que eu não preciso entender sobre o negócio do cliente? Ah, por favor, eu não sou um “programador” que não pensa e simplesmente segue algumas folhas de papel com vários diagramas UML e fluxos alternativos escritos por analistas de sistemas, eu -como desenvolvedor- devo estar tão próximo do negócio quanto for necessário, mas isso é bem complicado quando trabalhamos num modelo em cascata em que a comunicação entre os membros da equipe ocorre através da troca de documentos e diagramas, e pior, quando trabalhamos com “profissionais” que acreditam que isso funciona.

Enfim, já basta os softwares bolovos e sem testes que temos que manter, já basta os processos burocráticos que temos que participar, já basta estarmos rodeados de fábricas de software e code-monkeys preguiçosos, já basta a desvalorização e os péssimos salários pagos aos desenvolvedores, e agora me vêm com analistas de sistemas retrógrados (oops!, pareço redundante) ? Por favor, me perdoem, mas as vezes acho que o mercado local está caminhando para trás quando se fala em desenvolvimento de software, mesmo conhecendo algumas poucas empresas, grupos e bons profissionais dispostos a mudarem isso.

Pensando no que eu disse acima, um dos problemas comuns e chatinhos quando se trabalha com SelectOneMenu (ou SelectManyMenu) e entidades em JSF ocorre quando queremos que o value do nosso SelectItem seja a própria entidade, e não o “id” da mesma. Bem, o que estou querendo dizer é exatamente isso:

public List<SelectItem> getEmpresas() {
	List<SelectItem> items = new ArrayList<SelectItem>();
	for (Empresa e : this.empresas) {
		// observem que o value do meu SelectItem é a própria entidade
		items.add(new SelectItem(e, e.getNome()));
	}
	return items;
}

Isso acaba se tornando trabalhoso pois somos obrigados a implementar um converter para cada entidade, o que particularmente eu não gosto. Levando em consideração que não queremos criar um converter para cada entidade, quais outras soluções temos?

Cenário

Antes de explicar cada solução, vou demonstrar um cenário qualquer para facilitar o entendimento, ou seja, vou demonstrar os artefatos necessários, eles seguem abaixo:

1) Nosso managed bean

public class EmpresaBean {

	private Empresa selectedEmpresa;
	private List<Empresa> empresas = new ArrayList<Empresa>();

	public EmpresaBean() {
		empresas.add(new Empresa(7, "Triadworks"));
		empresas.add(new Empresa(88, "Ivia"));
		empresas.add(new Empresa(921, "Thoughtworks"));
		empresas.add(new Empresa(15, "Caelum"));
		empresas.add(new Empresa(2, "ImproveIT"));
	}

	public List<Empresa> getEmpresas() {
		return empresas;
	}
	public Empresa getSelectedEmpresa() {
		return selectedEmpresa;
	}
	public void setSelectedEmpresa(Empresa selectedEmpresa) {
		this.selectedEmpresa = selectedEmpresa;
		System.out.println("Empresa selecionada: " + selectedEmpresa.getNome());
	}
}

2) Nossa entidade (já implementando a interface BaseEntity para a solução do SimpleEntityConverter)

public class Empresa implements BaseEntity, Serializable {

	private static final long serialVersionUID = 1L;

	private Integer codigo;
	private String nome;

	public Empresa(Integer codigo, String nome) {
		this.codigo = codigo;
		this.nome = nome;
	}

	public Long getId() {
		return new Long(codigo);
	}

	// Métodos getters e setters
	// Não esquecer os métodos equals e hashCode
}

Por favor, não esqueçam de implementar os métodos equals e hashCode, evitemos cair naquele velho probleminha, ok?

3) Nosso formulário

<h:form id="form">
	<h:panelGrid columns="2" border="1">
		<h:outputLabel value="Empresa" for="empresa"/>
		<h:column>
			<h:selectOneMenu id="empresa"
				value="#{empresaBean.selectedEmpresa}"
				converter="simpleEntityConverter" required="true"
				requiredMessage="Valor é obrigatório">
				<f:selectItem itemValue="" itemLabel="Selecione uma empresa"/>
				<t:selectItems value="#{empresaBean.empresas}" var="o" itemLabel="#{o.nome}" itemValue="#{o}"/>
			</h:selectOneMenu>
			<br/>
			<h:message for="empresa" errorStyle="color:darkred;font-size:11px;"></h:message>
		</h:column>
		<f:facet name="footer">
			<h:commandButton value="Submit"/>
		</f:facet>
	</h:panelGrid>
</h:form>

Reparem que nosso componente h:selectOneMenu possui um converter declarado, ou seja, será necessário alterar o converter de acordo com a solução escolhida.

Nada de complexo, certo? É um básico cenário comum.
Então vamos as possíveis soluções

EntityConverter

O componente/feature EntityConverter foi desenvolvido pelo Rogério Araújo, que é um dos coordenadores do JavaServer Faces International Group. O componente em si foi pensado inicialmente para o cenário em que é necessário carregar a entidade de um banco de dados, mas isso não impede que a entidade seja obtida de qualquer outro recurso externo, como um web service ou EJB, por exemplo.

O componente funciona perfeitamente bem e é muito simples de configurar, porém ainda assim eu o acho interessante somente em alguns casos específicos, como no caso em que a entidade precisa ser carregada do banco de dados com todos seus atributos e/ou relacionamentos ao submeter o formulário, evitando-se assim onerar o servidor com grandes entidades em memória.

Alguns desenvolvedores reclamam porque o componente -idealmente- efetua uma requisição ao bando de dados para obter a entidade, mas venhamos e convenhamos, isso não deveria ser uma preocupação, principalmente para quem vem de algum framework “action-like” como o Struts. Além do mais, se você possui algum recurso de cache na camada de persistência -como o fornecido pelo Hibernate- não deveria se preocupar tanto com isso.

Eu não pretendo explicar como configurar o componente, pois na wiki do Myfaces você tem tudo que precisa saber, além do mais o criador do componente é coordenador da Javasf e é brasileiro

SimpleEntityConverter

Esta solução foi baseada no caso mais comum de um converter para cada entidade, a única diferença é que tentei torna-la “genérica” para qualquer entidade, evitando-se escrever um converter para cada entidade (é esta nossa intenção, certo?).

Sendo, segue abaixo o código do nosso converter:

public class SimpleEntityConverter implements Converter {

	public Object getAsObject(FacesContext ctx, UIComponent component, String value) {
		if (value != null) {
			return this.getAttributesFrom(component).get(value);
		}
		return null;
	}

	public String getAsString(FacesContext ctx, UIComponent component, Object value) {

		if (value != null
				&& !"".equals(value)) {

			BaseEntity entity = (BaseEntity) value;

			// adiciona item como atributo do componente
			this.addAttribute(component, entity);

			Long codigo = entity.getId();
			if (codigo != null) {
				return String.valueOf(codigo);
			}
		}

		return (String) value;
	}

	protected void addAttribute(UIComponent component, BaseEntity o) {
		String key = o.getId().toString(); // codigo da empresa como chave neste caso
		this.getAttributesFrom(component).put(key, o);
	}

	protected Map<String, Object> getAttributesFrom(UIComponent component) {
		return component.getAttributes();
	}

}

Como podem ver, o que basicamente ocorre é que armazenamos as entidades como atributos do nosso componente no método getAsString(), e recuperamos a entidade correta através da chave (neste caso o Id) associada a ela, no método getAsObject(). Mas quem é este BaseEntity?

public interface BaseEntity {

	public Long getId();

}

BaseEntity é uma interface com um método em comum entre as entidades, ou seja, nossas entidades precisarão implementar esta interface para que nosso converter funcione de acordo.

A solução é funcional, porém há algumas ressalvas que gostaria de explicitar. 1) Eu particularmente não gosto da idéia de “sujar” minhas entidades estendendo alguma interface ou classe para poupar código ou resolver problemas não-funcionais, mas isso é uma opinião minha. 2) Outro problema que vejo é que este converter acaba consumindo um pouco mais de memória no servidor por você está alterando o estado do componente, principalmente se sua lista de itens for muito grande, mas não é nada que você deva se preocupar inicialmente, ou seja, somente esquente a cabeça com isso se for realmente necessário.

SimpleIndexConverter

Esta solução eu tomei emprestada dos componentes do Myfaces Trinidad, que por sinal é excelente. A diferença é que eu a simplifiquei um pouco (o código para ser mais exato), logo ela não está tão robusta quanto a original (que se preocupa com casos mais específicos), mas funciona muito bem na maioria dos casos.

Sua idéia principal é utilizar o index da lista de items como chave para cada entidade, assim o que submetemos no formulário é o index da lista, e não um valor (Id?) da entidade como de costume.

O código do converter ficou grandinho, mas é possível enxuga-lo movendo alguns métodos para alguma classe utils. Segue abaixo o código do nosso SimpleIndexConverter:

public class SimpleIndexConverter implements Converter {

	private int index = -1;

	/* (non-Javadoc)
	 * @see javax.faces.convert.Converter#getAsObject(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.String)
	 */
	public Object getAsObject(FacesContext ctx, UIComponent component, String value) {

		SelectItem selectedItem = this.getSelectedItemByIndex(component, Integer.parseInt(value));
		if (selectedItem != null)
			return selectedItem.getValue();

		return null;
	}

	/* (non-Javadoc)
	 * @see javax.faces.convert.Converter#getAsString(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)
	 */
	public String getAsString(FacesContext ctx, UIComponent component, Object value) {
		index++;
		return String.valueOf(index);
	}

	/**
	 * Obtem o SelecItem de acordo com a opção selecionada pelo usuário
	 */
	protected SelectItem getSelectedItemByIndex(UIComponent component, int index) {

		List<SelectItem> items = this.getSelectItems(component);
		int size = items.size();

		if (index > -1
				&& size > index) {
			return items.get(index);
		}

		return null;
	}

	protected List<SelectItem> getSelectItems(UIComponent component) {

		List<SelectItem> items = new ArrayList<SelectItem>();

		int childCount = component.getChildCount();
	    if (childCount == 0)
	      return items;

	    List<UIComponent> children = component.getChildren();
		for (UIComponent child : children) {
			if (child instanceof UISelectItem) {
				this.addSelectItem((UISelectItem) child, items);
			} else if (child instanceof UISelectItems) {
				this.addSelectItems((UISelectItems) child, items);
			}
		}

		return items;
	}

	protected void addSelectItem(UISelectItem uiItem, List<SelectItem> items) {

		boolean isRendered = uiItem.isRendered();
		if (!isRendered) {
			items.add(null);
			return;
		}

		Object value = uiItem.getValue();
		SelectItem item;

		if (value instanceof SelectItem) {
			item = (SelectItem) value;
		} else {
			Object itemValue = uiItem.getItemValue();
			String itemLabel = uiItem.getItemLabel();
			// JSF throws a null pointer exception for null values and labels,
			// which is a serious problem at design-time.
			item = new SelectItem(itemValue == null ? "" : itemValue,
					itemLabel == null ? "" : itemLabel, uiItem
							.getItemDescription(), uiItem.isItemDisabled());
		}

		items.add(item);
	}

	@SuppressWarnings("unchecked")
	protected void addSelectItems(UISelectItems uiItems, List<SelectItem> items) {

		boolean isRendered = uiItems.isRendered();
		if (!isRendered) {
			items.add(null);
			return;
		}

		Object value = uiItems.getValue();
		if (value instanceof SelectItem) {
			items.add((SelectItem) value);
		} else if (value instanceof Object[]) {
			Object[] array = (Object[]) value;
			for (int i = 0; i < array.length; i++) {
				// TODO test - this section is untested
				if (array[i] instanceof SelectItemGroup) {
					resolveAndAddItems((SelectItemGroup) array[i], items);
				} else {
					items.add((SelectItem) array[i]);
				}
			}
		} else if (value instanceof Collection) {
			Iterator<SelectItem> iter = ((Collection<SelectItem>) value)
					.iterator();
			SelectItem item;
			while (iter.hasNext()) {
				item = iter.next();
				if (item instanceof SelectItemGroup) {
					resolveAndAddItems((SelectItemGroup) item, items);
				} else {
					items.add(item);
				}
			}
		} else if (value instanceof Map) {
			for (Map.Entry<Object, Object> entry : ((Map<Object, Object>) value).entrySet()) {
				Object label = entry.getKey();
				SelectItem item = new SelectItem(entry.getValue(),
						label == null ? (String) null : label.toString());
				// TODO test - this section is untested
				if (item instanceof SelectItemGroup) {
					resolveAndAddItems((SelectItemGroup) item, items);
				} else {
					items.add(item);
				}
			}
		}
	}

	protected void resolveAndAddItems(SelectItemGroup group, List<SelectItem> items) {
		for (SelectItem item : group.getSelectItems()) {
			if (item instanceof SelectItemGroup) {
				resolveAndAddItems((SelectItemGroup) item, items);
			} else {
				items.add(item);
			}
		}
	}

}

Não há muito a se explicar sobre o converter acima, a “mágica” toda está nos métodos auxiliares (que por sinal maior parte do código foi retirado do Trinidad, porém enxugado para nossas necessidades).

Este converter diferentemente do SimpleEntityConverter não altera o estado do componente, evitando assim a utilização de mais memória, ele busca as entidades -que já existem- dentro do componente (SelectOneMenu?) como estado do mesmo.

Assim como os outros converters, este também possui algumas ressalvas. O que podemos citar é 1) Por ele se utilizar do index da lista de items talvez não seja possível trabalhar com o componente no lado cliente (javascript) se você depender dos valores (Id?) de cada item.

Concluindo

Dizer que não é possível simplificar a vida com JSF é mentir, a tecnologia te fornece recursos para abstrair a natureza stateless do HTTP, e é interessante que se aproveite destes recursos.

As soluções explanadas acima não são únicas, existem outras com toda certeza, eu tentei demonstrar algumas delas quando não se tem algum framework (Seam?) ou conjunto de componentes (Trinidad?) para nos auxiliar, ou seja, quando contamos apenas com a implementação do JSF, o que -acredito eu- na maioria dos casos é o que ocorre.

É possível estende-las e até melhora-las, você é livre para isso, e dependendo da tua necessidade provavelmente será o melhor caminho, só não deixe de contribuir com o código para a comunidade.

Enfim, todas as soluções são plausíveis e funcionam para a maioria dos cenários, porém em determinados cenários cada uma se adequa melhor, resta a você analisar e ver qual se encaixa nas tuas necessidades. Além do mais, elas não são mutuamente excludentes.

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.

Enfim, vamos ao que interessa..

Entendendo o mecanismo

Uma das caracteristicas do JSF é que todos os seus componentes possuem um atribudo “id” e este atributo deve conter um valor único, caso não seja definido um ID pelo desenvolvedor então será gerado automaticamente um ID único para cada componente durante a construção da árvore de componentes.

Sendo, observem o seguinte trecho de código JSF:

<h:form>
	<h:inputText id="nome"/>
</h:form>

No final será gerado para o cliente (browser) o seguinte código -ou algo parecido- (X)HTML:

<form id="j_id_jsp_1761815803_1" name="j_id_jsp_1761815803_1" method="post">
	<input id="j_id_jsp_1761815803_1:nome" type="text" name="j_id_jsp_1761815803_1:nome" />
</form>

Reparem que o atributo “id” do componente h:form não foi definido, porém o framework gerou um ID único para o componente, no caso o ID foi “j_id_jsp_1761815803_1“, que foi renderizado juntamente com a tag <form/> do (X)HTML.

Atentem também que o ID (gerado) do componente h:form foi concatenado ao ID (que nós definimos) do componente h:inputText separados por ‘:’ (dois pontos) na tag <input/>, logo o ID da nossa tag <input/> é “j_id_jsp_1761815803_1:nome“.

Infelizmente os IDs gerados pelo framework não são nada legíveis para nós desenvolvedores -e provavelmente não deveriam-, então para consertar isso basta definirmos o ID de cada componente na nossa página, logo nosso código JSF ficará assim:

<h:form id="form">
    <h:inputText id="nome"/>
</h:form>

E consequentemente o código (X)HTML gerado será algo semelhante a isto:

<form id="form" name="form" method="post">
	<input id="form:nome" type="text" name="form:nome" />
</form>

Como podem ver, os IDs na página gerada ficam bem mais legíveis, facilitando assim o trabalho com JavaScript no lado cliente.

Naming container

E onde afinal de contas entra essa história de Naming Container?

Se vocês observaram o componente h:inputText teve seu ID concatenado ao ID do formulário no cliente, ou seja, na tag <input/> (X)HTML, e isso aconteceria com todos os componentes dentro do componente h:form. Logo, o componente h:form é um componente e ao mesmo tempo um naming container.

Basicamente, Naming Container é uma caracteristica que alguns componentes possuem, caracteristica essa que o framework utiliza para garantir que dentro de um naming container (componente) seus componentes filhos possuam IDs  únicos, evitando assim a duplicidade de componentes com o mesmo ID na página (viewroot).

Outra caracteristica importante que você deve saber sobre naming containers é que eles podem ser aninhados, logo os componentes mais internos terão seus IDs no cliente concatenados com os IDs dos naming containers mais externos também.

Logo em um caso como:

<h:form id="form">
    <f:subview id="subview">
        <h:inputText id="nome"/>
    </f:subview>
</h:form>

Teríamos o código (X)HTML abaixo gerado:

<form id="form" name="form" method="post">
	<input id="form:subview:nome" type="text" name="form:subview:nome" />
</form>

O componente f:subview também é um naming container, porém ele não gera qualquer output no cliente, ele é utilizado basicamente para servir como naming container, principalmente quando se faz includes de páginas dinâmicas.

Simples até demais, não?

Componentes padrões como h:form, f:subview e h:dataTable são naming containers. A maioria dos conjuntos de componentes possuem alguns naming containers, logo isso depende do conjunto de componentes.

Evitando naming container no formulário

As vezes temos páginas simples em que o único naming container é o próprio componente h:form, e nestas páginas precisamos manipular alguns dados no formulário através de JavaScript, porém é algo realmente chato ficar concatenando IDs para obter o ID de um input do formulário.

Para resolver isso o componente h:form (no JSF1.2) possui o atributo “prependId” que define se o componente se comportará no cliente como naming container ou não. Para evitar que o h:form se comporte como naming container basta setarmos o atributo “prependId” para false. Assim quando o código (X)HTML for gerado para o cliente as tags internas não terão seus IDs modificados.

<h:form id="form" prependId="false">
    <h:inputText id="nome"/>
</h:form>

Sem complicações, certo?

Essa caracteristica funciona somente para os componentes filhos do h:form, caso haja um naming container dentro do h:form então os filhos deste name container terão seus IDs alterados normalmente no cliente.

Concluindo

O post ficou até longo para um assunto básico, mas acredito que consegui abordar os fundamentos sobre naming container para quem pretende apenas utilizar os componentes na construção de páginas. Para quem realmente pretende criar (ou estender) seus próprios componentes seria interessante conhecer o conceito mais a fundo.

Enfim, o conceito é básico, porém fundamental para desenvolvedores que usam JavaServer Faces. Contudo é incrível como a maioria dos desenvolvedores não se interessam pelos fundamentos do framework, fundamentos estes que evitariam diversas dúvidas e problemas durante o desenvolvimento.

Acaba de ser lançado a Reference Implementation (RI) Beta do JSF2.0. Com o nome de Mojarra, continuando com o mesmo nome da versão 1.2 da implementação da Sun,  a nova especificação está trazendo diversas melhorias e acertos em relação as versões anteriores, nesta versão realmente há muitas features interessantes e que alavancará a produtividade no desenvolvimento com JavaServer Faces.

As features

Entre as diversas features e melhorias, existem algumas que eu gostaria de destacar:

• Um novo ciclo de vidas no lado cliente (browser), ou seja, agora será bem mais fácil integrar e criar componentes com frameworks e APIs javascript como ExtJS ou Yahoo API, quem sabe em breve não vejamos um Ext4JSF por aí? Além do mais será mais rápido e prático implementar interfaces do tipo “on a single page interface web application“, já que todo o processamento da interface gráfica ficará no lado cliente!
• Escopos de conversação, finalmente!! Feature esta que realmente fazia (faz?) falta ao se desenvolver com JSF, atualmente somos obrigados a se utilizar de frameworks ou componentes como Myfaces Tomahawk, JBoss Seam, Spring Annotation entre outros.
• Agora teremos “Zero Configuration“, ou seja, esqueça faces-config.xml, esqueça web.xml !! Provavelmente configuraremos tudo por annotations.
• Outra feature necessária e que também fazia uma falta em tanto é a Exception Handler, agora depois de um erro lançado poderemos encaminhar o usuário para uma página de erro.
• Annotations, e muitas annotations para declarar artefatos como managed bean, componentes, regras de navegação etc.
• Suporte a templating, algo próximo no estilo do Facelets.
• Suporte a submissão com método HTTP GET, ou seja, bookmarking.
• Agora com AJAX nativo no ciclo de vida. A incompatibilidade entre os conjuntos de componentes será absurdamente menor, já que a falta de uma especificação AJAX para JSF era um dos maiores causadores de tanta incompatibilidade!
• Acessar recursos JSF através de REST, wow!
• Agora será possível executar uma ação (método?) ao carregar uma página.
• Salvar e recuperar parcialmente estados da árvore de componentes (Isso vai trazer uma melhoria significativa à perfomance).

Como podem ver, são inúmeras melhorias significativas -na minha opiniao- para esta nova versão, e provavelmente surjam outras já que a especificação está ainda em rascunho. No site da JCP há as demais features e melhorias sobre esta versão.

Concluindo

Uma das maiores dúvidas em relação a esta versão é a tal da retrocompatibilidade, eu particularmente acredito que a versão 2.0 do JSF será compatível com as versões anteriores (ao menos com a JSF1.2) pois há o envolvimento de Big Players na especificação e encarar as versões anteriores como legados descontinuados é algo radical demais para o mercado, porém é quase que certo que será necessário abrir mão da compatibilidade em algum ponto para aproveitar os recursos da nova versão.

Enfim, JSF2.0 está vindo com tudo. Enquanto aguardamos a versão final já podemos brincar com a versão beta do Mojarra para JSF2.0.

Christiano Milfont é (foi?) um dos membros mais ativos da lista de discussão do Cejug e com toda certeza um dos maiores formadores de opinião ali dentro, além de ter participado de várias discussões “calorosas” sobre tecnolgias, metodologias, boas práticas, desenvolvimento e design de software ele também ministrou diversas palestras em nome do Cejug, na verdade ele é o membro que mais ministrou palestras pelo Cejug até hoje!

Infelizmente depois de algumas discussões na lista do Cejug e em chat privado, o Christiano com toda sua “grande” paciência decidiu finalmente abandonar a lista de discussão do Cejug que ele tanto frequentou. Mas seus amigos e fãs estão clamando por sua volta desde o inicio da campanha.

A campanha ainda continua, todos continuam insistindo na sua volta ao Cejug, todos estão escrevendo no status do Google Talk o texto da campanha, “Volta para o Cejug Milfont!!” e o perturbando em chats privados para que ele volte! Enfim, está havendo uma enorme pressão psicológica sobre o Milfont!

Acreditamos que ele voltará, pois precisamos dos seus comentários rígidos, irônicos e as vezes sarcásticos nas discussões calorosas do Cejug! Além do mais a pressão psicológica não pára!! Volta Milfonntttt..

Juntem-se a campanha, alterem o status do seu Google talk, comentem aqui pedindo a sua volta, abram chats privados com ele e digam com louvor:

“VOLTA PARA O CEJUG MILFONT !!”

[UPDATE]
Um dos “fiéis” da campanha, Emmanuel Catunda, acaba de criar um cartaz para que todos possam imprimir e colar nas baias de sua empresa com o intuito de forçar a volta do Milfont ao Cejug!!

Aqui está o cartaz!

Eu tentei ao máximo deixar claro que não eram os componentes X, Y ou Z que me forneciam recursos para implementar o conceito, como está bem claro nos trechos do post abaixo:

Utilizar um conjunto de componentes ricos e um framework AJAX. (Neste caso eu optei pelo Richfaces/Ajax4jsf por ser bastante simples de usar e integrar, por ser estável e por ser bastante utilizado na comunidade, contudo, qualquer outro conjunto de componentes AJAX poderia ser utilizado, como Trinidad ou mesmo o IceFaces);

E este,

Eu não me prendi a utilização dos frameworks ou conjuntos de componentes utilizados pois este não era o intuito do post, isso é algo simples e acredito que a maioria dos leitores não tenham dificuldades em relação a isso. Além do mais é possível implementar isso não somente com o Richfaces/Ajax4jsf, mas com qualquer outro framework ou conjuntos de componentes AJAX, por exemplo, [...]

Não é necessário utilizar Richfaces/Ajax4jsf, Tomahawk e Facelets para aproveitar os recursos da tecnologia de forma eficiente, você poderá conseguir isso com qualquer outro framework ou conjunto de componentes que te permitam unir AJAX e JSF de maneira prática, sejam eles Trinidad, JBoss Seam, IceFaces, Ajax4jsf, ADF Faces e/ou JSFTemplating.

Mais claro que isso é impossível.. porém ainda não acabou, um fato engraçado é que alguns desenvolvedores chegaram a se queixar de que eu fui muito radical ao dizer para desenvolverem toda uma aplicação em uma única página. Eu em nenhum momento disse ou mesmo insinuei isto, o que eu disse foi:

A idéia principal tem por objetivo evitar escrever muitas páginas para representar cada view (tela), diminuindo assim o número de páginas no projeto, o número de regras de navegação no faces-config.xml, diminuindo o overhead no servidor e no cliente a cada refresh de página, [...]

Vocês não precisam e provavelmente não deveriam implementar suas aplicações seguindo o exemplo do post, ele é básico, ele serve como referência, possui uma implementação simples e não se preocupa com alguns requisitos não funcionais como a paginação sob demanda ou quais os objetos que deveriam permanecer entre as requisições. Além do mais o exemplo é um CRUD, e não uma interface com o usuário mais complexa no sistema.

Entendam uma vez por todas que não existe uma arquitetura de referência ou receita de bolo para desenvolver sistemas, cada sistema possui suas necessidades e peculiaridades, e estas devem ser estudadas e analisadas para se chegar a uma solução plausível.

O importante é que vocês compreendam o conceito, seus prós e contras e principalmente onde e quando utiliza-lo. Não se prendam ao framework ou conjunto de componentes, a maioria deles hoje em dia te fornecem os recursos necessários para implementar a idéia sem muitas dificuldades.

Enfim, estudem, entendam, aprimorem, façam testes e implementem o conceito onde for necessário, com os componentes e frameworks cabíveis e sempre com bom senso.

Fora o evento ter sido muito bacana eu também gostei da cidade e da receptividade do povo de lá, como o Sidney, o Leonardo e o Carlos, houveram outros, porém não me recordo dos nomes, no entanto gostaria de agradecê-los pela paciência, apoio e boa vontade oferecidos durante nossa estadia em Juazeiro.

Algumas fotos do evento abaixo para recordar:

E os slides apresentados no evento,

| View | Upload your own

Os palestrantes e seus respectivos temas serão:

Rafael Carneiro com o tema Certificação Java, Tarso Bessa com Utilizando o Spring framework em aplicações JEE, Silveira Neto com Conhecendo o NetBeans 6 e por último eu, com o tema JavaServer Faces, desenvolvendo aplicações web com produtividade.

Como podem ver o evento contará com assuntos bem diversificados relacionados a tecnologia Java, e acredito que este é o 1º de muitos eventos que ocorrerão em Juazeiro do Norte

Ah! Também será a primeira vez que visito essa terrinha quente, se der tempo vou tentar conhecer alguns pontos turísticos por lá.

As três palestras foram excelentes, a minha palestra sobre Domain-Driven Design, a de JME ministrada pelo Vando Batista e a palestra sobre Integração Contínua ministrada pelo Luthiano Vasconcelos. Acredito que todos nós conseguimos abordar os temas com objetividade e proficiência. Mas com certeza o Luthiano merece meus parabéns por ter apresentado aproximadamente 25min da sua palestra sem a ajuda dos slides devido a problemas técnicos, ele é o cara!

Neste evento o Rafael Carneiro reforçou o movimento Shoes is Watching, distribuindo uma cópia do folder aos 20 primeiros que chegassem ao evento, foi bem divertido a repercussão desta brincadeira, algumas pessoas gostaram muito, outras odiaram e outras desconheciam o Shoes, porém depois do evento todos sairam de lá sabendo quem era o Phillip Calçado (aka Shoes) e o motivo da brincadeira.

| View | Upload your own

Gostaria de agradecer a coordenação do CEJUG, a FLF por ter cedido o local e o excelente coffee-break, e alguns amigos que me ajudaram direta ou indiretamente durante um estudo mais aprofundado sobre o tema como o Alessandro Lazarotti, Rommel Costa, Christiano Milfont, Rafael Carneiro e Tarso Bessa.