Conhecendo o Ajax4Jsf

Rafael de Paula Souza (rafael.bnc@gmail.com), está cursando Engenharia de Computação na FURG. Atualmente faz estágio na área de soluções para Web em Java, utilizando JSF e demais frameworks.

Introdução

Ajax4Jsf é um framework que adiciona capacidade Ajax nas aplicações que utilizam JSF sem recorrer ao JavaScript. O principal objetivo do framework é fazer chamada das Actions ou ActionListeners no Managed Bean de forma assíncrona, obedecendo todo ciclo de vida do Faces, e depois fazendo uma atualização de um ou mais componentes especificados nos atributos da tag.

 

Instalação

A instalação do Ajax4Jsf é muito fácil, para isso basta seguir os passos a seguir.

·         Fazer download da distribuição em – http://labs.jboss.com/portal/jbossajax4jsf

·         Copiar os Jars “ajax4jsf-1.1.0.jar” e “oscache-2.3.2.jar” do Ajax4Jsf para a pasta WEB-INF/lib da sua aplicação.

·         Adicionar as configurações do filter do Ajax4Jsf no arquivo web.xml.  

·         Importar o ajax4jsf nas paginas da sua aplicação.

 

 

Configurando o web.xml

Adicione a seguinte configuração no arquivo web.xml:

<context-param> 

        <param-name>org.ajax4jsf.SKIN</param-name>

        <param-value>classic</param-value> 

</context-param>

<filter> 

<display-name>Ajax4jsf Filter</display-name>

<filter-name>ajax4jsf</filter-name>

<filter-class>org.ajax4jsf.Filter</filter-class> 

</filter>

<filter-mapping>

<filter-name>ajax4jsf</filter-name>

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

<dispatcher>REQUEST</dispatcher>

<dispatcher>FORWARD</dispatcher>

<dispatcher>INCLUDE</dispatcher>

</filter-mapping>

 

E para importar o ajax4jsf na sua pagina jsp use:

<%@ taglib uri=https://ajax4jsf.dev.java.net/ajax&#8221; prefix=“a4j”%>

 

Se você estiver trabalhando com facelets:

<xmlns:a4j=https://ajax4jsf.dev.java.net/ajax&#8221;>

 

AJAX Requests

Existem diferentes formas para fazer que suas paginas enviem AJAX requests. Para isso, você pode usar as seguintes tags: <a4j:commandButton>, <a4j:commandLink>, <a4j:poll> e <a4j:support>.

 

Essas tags escondem do programador o JavaScript que é necessário para enviar AJAX requests,  o que facilita muito o desenvolvimento de aplicações que utilizam essa tecnologia. Elas também permitem que você escolha quais componentes de sua pagina que serão “modificados” após o AJAX response (você pode listar os IDs desses componentes através do atributo “reRender”).

 

<a4j:commandButton> e <a4j:commandLink>: essas tags são usadas para enviar AJAX request através do evento “onclick”.

<a4j:poll>: usada para enviar AJAX request em um determinado tempo.

<a4j:support>: permite que qualquer componente JSF faça AJAX request através de um determinado evento JavaScript: “onkeyup”, “onmouseover”, etc.

 

Exemplos:

<h:inputText value=“#{pessoa.nome}”>

        <a4j:support event=“onkeyup” reRender=“texto”/>

</h:inputText>

<h:outputText id=“texto” value=“#{pessoa.nome}”/>

 

 

<h:form id=”form”>

        <h:inputText value=“#{pessoa.nome}”/>

        <h:inputText value=“#{pessoa.rg}”/>

        <h:inputText value=“#{pessoa.cpf}”/>

        <a4j:commandButton reRender=“form” action=“#{pessoa.atualizar}” value=“Atualizar” oncomplete = “alert(‘Dados atualizados’)”/>

</h:form>

Anúncios

O que o AJAX.NET não tem?

 

Vale a pena utilizar o AJAX.NET da Microsoft ou construir a própria biblioteca AJAX?Já coloquei muito a mão na lama, mas depois de algum tempo, você passa a gerenciar projetos ou tocar uma empresa e perde o contato com os detalhes das coisas.

Por outro lado é necessário tomar decisões tecnológicas que irão afetar a empresa onde você trabalha. Estive nessa situação há alguns meses. Ir de AJAX.NET ou desenvolver uma biblioteca AJAX própria?

Pedi uma análise e uma indicação para dois dos engenheiros de software da nossa empresa sobre a proposta da Microsoft. Eis aqui o relatório.

Problemas do ASP.NET

Tudo começou quando a Microsoft introduziu o ASP.NET, uma versão aprimorada do ASP. Ela adicionou a arquitetura .NET uma tecnologia para produção de páginas web, os WebForms. Com eles se pode criar uma interface visual com o usuário de forma semelhante à feita usando o Visual Basic. A sua arquitetura é baseada no servidor.

Para criar uma página ASP.NET você tem a disposição os HTMLControls, que não são processados pelo servidor quando o usuário interage com os mesmos, e os WEBControls, que são processados pelo servidor quando existe interação.

Ao abrir uma página ASP.NET, o cliente (navegador do usuário) exibirá o resultado HTML/JavaScript de um WebForm processado pelo servidor. Quando o cliente interagir com a página, ela será transmitida de volta ao servidor, alterada e depois restaurada de volta ao cliente. E sempre que ocorrer uma interação do usuário com um controle que disparar um evento, este caminho será seguido, do cliente para o servidor e de volta ao cliente. Deu-se a isto o nome de postback.

Nessa arquitetura, o cliente é “burro” e 100% da lógica de negócio fica a cargo do servidor. Do ponto de vista do desenvolvedor isso é ótimo, facilita o desenvolvimento com a utilização dos WebControls. Mas e o usuário, onde fica?

Assim, para cada interação complexa existe um postback e para cada postback um tempo de espera. Você provavelmente estará destruindo a usabilidade de seu site e a paciência de seus usuários.

Em um exemplo simples, basta imaginar um formulário com quatro combos encadeadas e algumas validações. A página executará no mínimo quatro postbacks. A página inteira irá quatro vezes para o servidor e retornará ao cliente. Haja paciência.

Solução aos postbacks?

O modelo ACSC (Asynchronous Client/Server Communication) é muito mais interessante para o usuário que o modelo WebForm/Postback do ASP.NET e abre um leque de possibilidades de interação antes impraticáveis.

O amadurecimento e a consolidação das tecnologias ACSC (e a popularidade da implementação desse modelo com o AJAX), onde o recarregar de páginas inteiras é substituído por requisições assíncronas do cliente ao servidor e atualização somente da parte onde ocorreu interação com o usuário, obrigou a Microsoft a atualizar sua arquitetura para suportar o modelo ACSC, de modo a evitar que o ASP.NET não perdesse seu mercado.

Para manter a compatibilidade com códigos já existentes em ASP.NET 2.0, a Microsoft desenvolveu parte do Atlas baseada em sua antiga arquitetura, a centralizada no servidor (Server centric), onde o comportamento de postback dos WebControls é modificado, mas ainda assim a lógica do negócio fica toda no lado servidor. Isso é contrário ao verdadeiro modelo ACSC, onde a lógica do negocio é dividida entre o cliente e o servidor e centralizada no cliente (Client centric).

O Atlas Server Centric é baseado em painéis Ajax onde é possível inserir os WebControls já existentes do ASP.NET. Uma vez dentro do painel Ajax o postback do WebControl será substituído por uma requisição assíncrona ao servidor. O modo centralizado no servidor é na verdade apenas uma “maquiagem” para as páginas ASP.NET, já que toda lógica de negócio fica no servidor.

Nenhuma inteligência complexa é mantida no cliente. Todos os postbacks continuam sendo realizados por baixo da “máscara” do XMLHttpRequest e, como todos os WebControls ainda continuam sendo processados no servidor, o retorno do Atlas Server Centric é HTML (AJAH – Asynchronous JavaScript and HTML) e não AJAX.

Isso torna o overhead e o trafego muito maiores já que ao invés de retornar uma estrutura apenas com os dados relevantes o Atlas Server Centric retorna os dados em conjunto com HTML.

Decisão: nossa Biblioteca vs. Atlas

Tomamos a decisão de construir uma biblioteca própria para diminuir o overhead de transmissão de dados – já que isso é crítico -, a serialização e os recursos encapsulados para facilitar realmente a vida do programador. Criamos a Naja.NET.

O Atlas Client Centric tem uma arquitetura muito parecida com o framework Naja.NET. Segue o mesmo modelo, porém o Atlas Client Centric é um framework sem todos os recursos do Naja.NET, sem toda a extensão do JavaScript e sem todos os objetos portados do .NET que o framework Naja.NET possui.

A falta de serializadores e conversores de tipos complexos (como DataTable, XmlDocument, etc.) também é uma desvantagem do Atlas Client Centric em relação ao Naja.NET, que consegue converter praticamente qualquer tipo do .NET para qualquer tipo do JavaScript.

A serialização do Naja.NET também tem a vantagem de ser mais inteligente e com maior desempenho. Conforme o problema o framework escolhe entre a serialização JSON (JavaScript Object Notation) ou o retorno puro de JavaScript. Outra grande vantagem do Naja.NET é o suporte ao Framework .NET 1.1 e 2.0. O Atlas suporta apenas o framework 2.0.

A extensão do JavaScript padrão também é superior no framework Naja.NET, e conseqüentemente facilita a vida do desenvolvedor que não precisará estender o JavaScript por conta própria para atender suas necessidades e nem utilizar bibliotecas de terceiros que podem apresentar problemas de compatibilidade.

* Otávio Medeiros Dias e Marcell Dietrich Felipe Duran são engenheiros de software da Voxel Informática e colaboraram com os dados relevantes desta coluna.

Nivaldo Foresti é programador há 30 anos, desde a jurássica era do mainframe. Foi consultor e desenvolvedor de produtos na internet como o BOL e hoje tem uma empresa de webcasting, com software nacional. Neste espaço, o colunista revela o que os desenvolvedores podem esperar da profissão, além de analisar as novas eras tecnológicas que se aproximam. E-mail: nforesti@yahoo.com .