Arquivos XHTML, no JSF, são bem mais que estruturas de páginas

Provavelmente todo mundo que utiliza o JSF já passou por algum problema que estava relacionado ao seu famoso ciclo de vida.
Existem vários pontos que podemos estudar relacionados a este assunto, mas hoje quero focar no que realmente representa sua página (geralmente com extensão .xhtml) para o ciclo de vida do JSF.

Muitas vezes os programadores ainda olham para uma página xhtml e associam apenas com a geração do HTML final, o que em algum momento até vai ser verdade.
Vamos analisar o código abaixo:

	<h:form>			
		<h:outputLabel value="Nome:" for="nome" />
		<h:inputText id="nome" value="${produtoBean.produto.nome}" />
		<h:outputLabel value="Descrição:" for="descricao" />
		<h:inputTextarea id="descricao" value="${produtoBean.produto.descricao}" />
		<h:outputLabel value="Preço:" for="preco" />
		<h:inputText id="preco" value="${produtoBean.produto.preco}" />
		<h:commandButton value="Gravar" action="#{produtoBean.grava}" />
		
	</h:form>
	<h:dataTable value="#{produtoBean.produtos}" var="produto" id="tabela">
		<h:column>
			<f:facet name="header">Nome</f:facet>
		          #{produto.nome}
		</h:column>
		<h:column>
			<f:facet name="header">Descrição</f:facet> #{produto.descricao}
		</h:column>
		<h:column>
			<f:facet name="header">Preço</f:facet> #{produto.preco}
      	</h:column>

	</h:dataTable>

Temos um formulário e uma tabela. Mas, o mais importante para mim, neste momento, é o que representa os bindings que colocamos nos elementos. Por exemplo, usamos a expression language no commandButton para informar um método que deve ser invocado.
O engraçado é que para quem vem de um framework action based significa que este método deveria ser chamado no exato momento que a expressão #{…} fosse interpretada.

Só que pensando pelo lado do JSF isso não faz muito sentido, já que no primeiro request para essa página, nenhum botão foi clicado ainda.

Você pode usar a mesma linha de pensamento para os bindings que foram feitos nos inputs dentro do formulário: quando que ele deve chamar o getter ou o setter? 

Percebe que depende do momento?

Ele sempre vai querer chamar o getter do objeto associado, já que existe a necessidade popular os campos que serão enviados para o cliente. Só que o setter só faz sentido ser chamado quando alguém fizer o submit do formulário, para que as informações do objeto em questão possam ser populadas.

Para finalizar, podemos analisar a tag dataTable, que também faz uso do binding. Ela está relacionada com o método getProdutos e podemos pensar de novo, em qual momento ele deve ser chamado? Nesse caso a resposta vai ser: sempre! 
Isso porque o tempo todo queremos popular a nossa tabela.

É interessante notar que os próprios componentes decidem quando as expression languages associadas a eles vão ser interpretadas. É por esta razão que sua página é muito mais que uma montagem do seu HTML, ela serve de configuração para o JSF saber o que precisa fazer, a cada novo request.

Essa é uma parte bem importante da manutenção de estado dos componentes da sua tela, que o JSF provê. O que ele mantém no servidor é justamente quais são os componentes e quais são seus respectivos bindings. Uma parte desses bindings é processada, por exemplo, na fase APPLY_REQUEST_VALUES, dependendo do comportamento do componente em questão.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s