Para suprir essa necessidade de usabilidade tivemos que adotar alguns conceitos, como ser totalmente stateless e modificar a arquitetura MVC2 para o MVC3. No server-side trabalhamos com um domain model baseado em Hibernate, Spring e Facades e Services com DWR. Nada de frameworks MVC2, não nos preocupamos com renderização e sim com a API. No lado cliente usamos Extjs com algumas modificações que fiz para integrar de forma suave com o DWR.

Primeiro precisamos entender como o Extjs trabalha com herança. Basicamente há um método no objeto Ext que faz esse trabalho de extensão dos componentes, funciona da seguinte maneira:

//Formato:
var NovoComponente = Ext.extend(velhoComponente, { 
          /* metodos e propriedades que serão reescritas */ 
});
 
//Exemplo:
var MilfontGridPanel = Ext.extend(Ext.grid.GridPanel, {
        //novo construtor
        constructor: function(config) {
            // Seu preprocessamento vai aqui
        	MilfontGridPanel.superclass.constructor.apply(this, arguments);
            // Seu pos-processamento vai aqui
        },
 
        NovoMethod: function() {
            // algum novo método que você queira criar para o novo componente
        }
    });

Para esse projeto, criei um Ext.data.DataProxy (como visto no artigo passado) especialista para o DWR, criativamente denominado DWRProxy. A idéia é modificar o comportamento de buscar os dados para usar um Creator do DWR.

Definimos primeiro o objeto e suas propriedades necessárias:

Ext.ux.data.DWRProxy = function(dwr_facade, dwr_filter, dwr_errorHandler){
 
    Ext.ux.data.DWRProxy.superclass.constructor.call(this);
 
	/* Propriedade que receberá a classe Java configurada como Creator */
    this.data = dwr_facade;
    /*
	 * Propriedade que receberá uma classe java configurada como converter
	 * que servirá como filtro de busca
	 */
 
	this.dwr_filter = dwr_filter;
 
	/**
	 *
	 * Propriedade para fazer paginação, indica que deve cachear a consulta de
	 * total de elementos o controlador [fachada] deve implementar a logica de
	 * negocios adequada, quando for false consulta o total, quando for true
	 * consulta apenas a listagem e repete o total
	 */
 
	this.dwr_total_cache = false;
 
	this.dwr_errorHandler = dwr_errorHandler;
 
};

Após isso extendemos do Ext.data.DataProxy :

Ext.extend(Ext.ux.data.DWRProxy, Ext.data.DataProxy, {
 
    /**
     * Método Load do Ext.data.DataProxy overrided
     */
 
    load : function(params, reader, callback, scope, arg) {
 
	/**
	 * Escopo "this" mapeado para a variável "s" porque dentro do callback do
	 * DWR o escopo "this" não pertence ao objeto Ext.ux.data.DWRProxy.
	 */
 
	var s = this;
 
        params = params || {};
 
        if(params.cache != undefined) {
		this.dwr_total_cache = params.cache;
	}
 
	if(params.filter != undefined) {
		this.dwr_filter = params.filter;
	}
 
        var result;
 
        try {
		this.data(this.dwr_filter, params.start, params.limit, this.dwr_total_cache, {
			callback:function(response) {
                                //aqui passamos o retorno do DWR 
                               // que chamei de response,  para o extjs
				result = reader.readRecords(response);
				callback.call(scope, result, arg, true);
			},
			errorHandler:function(a, e) {
				scope.fireEvent("loadexception", s, arg, null, e);
				s.dwr_errorHandler(a);
			},
			timeout:100000
		});
 
		this.dwr_total_cache = true;
 
        } catch(e) {
            this.fireEvent("loadexception", this, arg, null, e);
            callback.call(scope, null, arg, false);
            return;
        }
 
    }
 
});

A fachada DWR é uma classe comum, segue um exemplo de uso com Hibernate:

//classe para satisfazer o transporte para o Extjs
public final class DataTransferObject {
    private int total;
    private List<? extends Object> results;
    //sets e gets
}
 
public class AjaxFacade {
    //injeta um repositorio, whatever
    private Repository repository = null;
 
    public DataTransferObject find(Object filter, int start, int limit, boolean cache, HttpSession session) {
        DataTransferObject dto = new DataTransferObject();
        //verifica se o Proxy está passando true 
        // indicando que está paginando
        if (cache) {
            Integer total = (Integer) session.getAttribute("totalObject");
            dto.setTotal(total);
       } else {
            session.removeAttribute("totalObject");
            Integer total = repository.count(filter);
            dto.setTotal(total);
            session.setAttribute("totalObject", total);
        }
        List<Object> retorno = (List<Object>) repository.find(filter, start, limit);
        dto.setResults(retorno);
        return dto;
    }

Para o Grid visto no artigo passado, basta instanciar assim no javscript:

var store = new Ext.data.Store({
    proxy: new Ext.ux.data.DWRProxy(
        AjaxFacade.find, 
        {$dwrClassName:"Project"}, 
        errorHandler
    ),
    reader: new Ext.data.JsonReader({
            root: 'results',totalProperty: 'total',id: 'id'
        }, 
        ['id', 'name', 'manager.name', 'manager.address.country']
    )
});

Para entender o {$dwrClassName:”Project”} visite esse post.

Dessa forma o DWR se torna um proxy para todos os componentes do Extjs.

Código fonte da modificação do javascript eu coloquei aqui no github e uma aplicação demo aqui. No próximo vou integrar o DWR com o Rails, aguardem que sai logo… ou não.

O DWR tem uma vantagem, desde 2005 – em suas primeiras versões – que praticamente é a mesma configuração, com mudanças poucos significativas. Esse material continua válido em sua plenitude.

Até a versão 2 temos que construir métodos no Creator com implementação nos argumentos devido ao DWR não ter como fazer o binding entre o Javascript e o Java sem saber quem é o objeto. Algo assim:

public class AjaxFacade {
 
	public User teste(User param) {
		param.setDescription("Teste funcionou");
		return param;
	}
}

No javascript:

AjaxFacade.teste(
	{
		id:42 //JSON que representa o objeto User
	}, 
	{
		callback:function(retorno) {
			alert(retorno.toSource());
		},
		errorHandler:function(error, message) {
			alert(message);
		}, 
		timeout:5000
	});

Agora foi adicionado a propriedade $dwrClassName no Converter onde você pode trabalhar com a interface ao invés da implementação. Vejamos com o Object como argumento no mesmo método:

public class AjaxFacade {
 
	public Object teste(Object param) {
		//puramente ilustrativo não peça fundamentação lógica :)
		if(param instanceof User) { 
			((User) param).setDescription("Teste funcionou");
		}
		return param;
	}
}

No javascript:

AjaxFacade.teste(
	{
		id:42 //JSON que representa o objeto User,
		$dwrClassName:"User"
	}, 
	{
		callback:function(retorno) {
			alert(retorno.toSource());
		},
		errorHandler:function(error, message) {
			alert(message);
		}, 
		timeout:5000
	});

Agora aquelas centenas de classes que fazem a mesma coisa [CRUDzão velho de guerra] podem ser resumidas em uma única Facade que faz suas validações e aciona um Repository ou sua estrutura de persistência.

public class AjaxFacade {
	@Autowired Repository repository;
	public Object persistir(Object param) {
		if(param == null) ...
		repository.persist(param);
		return param;
	}
}

Agora não tem como não termos um Feliz Natal!

A especificação do XHR define, por medida de segurança, que uma chamada remota só pode ser efetuada ao mesmo caminho de onde o script foi baixado, o JSONRequest resolveria esse problema habilitando o navegador a uma chamada remota a outros servidores diferentes do host original da página, possibilitando a facilidade de acesso a WEB Services REST na camada javascript.

Hoje como alternativa a esse modelo do XHR temos o Scripttag, dessa forma conseguimos acessar recursos remotos de outros servidores mas com o problema de XSS (cross site scripting). O problema principal do XSS é a injeção de código malicioso pelo parser a partir do método “Eval” para processar o código recebido. Vimos uma alternativa de contornar o problema mas mesmo assim não é suficiente. Uma das vantagens principais do JSONRequest seria evitar o XSS.

Esse objeto JSONRequest seria nativo e global, desenhado para ser simples, teria apenas 3 métodos: get, post e cancel.

Existe já plugin para o Firefox que habilita o navegador a oferecer nativamente o objeto JSONRequest.

Para todos os navegadores somente com javascript na camada mais alta, para isso existe também o projeto JSONRequest de Andrea Giammarchi, que criou o objeto em javascript seguindo a especificação. Compatível com os principais navegadores: Opera, IE, Firefox, Safari e konqueror.

try {
    JSONRequest.get("processaJSON.jsp",
        function(sn, response, exception){
             alert(exception || response);
        });
} catch(e) {
 
      alert(e);
 
}

O W3C especificou medidas seguras para acesso a recursos web em outro servidores, assim como já existem movimentos para uma nova especificação do um novo XHR, seria algo como um XHR2. A diferença no meu entendimento é que o JSONRequest trata exclusivamente da troca de objetos nativos com base em JSON entre os dois ambientes físicos, enquanto o XHR trata da troca via XML, portanto uma nova especificação do XHR não seria suficiente para substituir a proposta do JSONRequest, a não ser que ele fizesse o parser também de JSON como faz com XML.

“An ECMAScript object is an unordered collection of properties each with zero or more attributes…”

Essa definição é o que chamamos de objeto literal, uma coleção não ordenada de propriedades com um ou mais elementos, onde esses elementos podem ser valores primitivos comuns a todas as linguagens como: inteiro, string ou char; ou outros objetos.

var Produto = {
	nome:"Microprocessador AMD Turion 64",
	value:150,
	custo:50,
	getValue:function(){
		return (value + custo)
	}
}

Douglas Crockford, propôs um formato de troca de dados simples com base no objeto literal do JavaScript, que denominou de JSON (JavaScript Object Notation). Esse mecanismo simples é um subconjunto do objeto literal e é facil de qualquer linguagem processar e gerar por ser baseado no formato texto, como linguagem completamente independente que usa conceitos similares às linguagens C-like. Esses motivos tornam o JSON o formato ideal de troca de dados.

JSON é construído com base em uma coleção de pares chave/valor (que definem as propriedades e seus valores), iniciado com “{” (chave aberta) e finalizado com “}” (chave fechada) . Cada chave é seguida de “:” (dois pontos) e os pares são separados por “,” (vírgula).

var Contato = {
	"nome":"Christiano Milfont",
	"email":"cmilfont@gmail.com",
	"aniversário":"28/12/1977"
}

Um array pode ser usado como valor para uma chave, iniciado por “[" (colchete aberto) e finalizado por "]” (colchete fechado). Cada valor do array é separado por “,” (vírgula).

var Contato = {
	"nome":"Christiano Milfont",
	"telefones":[
		'91942365',
		'88293759'
	]
}

Um valor pode ser uma String em aspas duplas (em javascript o valor pode ser aspa simples, é preferível que o parser resolva as duas formas, apesar de que em linguagens como java as aspas simples representam um char), ou um número, ou um booleano, ou um null, ou um outro objeto ou um array.

No caso do objeto e do array, essas estrutura podem ser aninhadas.

var Contato = {
	"nome":"Christiano Milfont",
	"endereco":{
		"rua":"Eurico Medina",
		"numero":185,
		"mapa":{
			"latitude":"",
			"longitude":""
		}
	},
	"telefones":[
		'91942365',
		'88293759'
	]
}

String é uma coleção de zero ou mais caracteres Unicode, onde a barra invertida pode ser usada para passar caracteres especais como quebra de linha, tab, entre outros. Números podem ser inteiros ou reais, menos hexadecimal ou octal.

Existem códigos de processamento JSON prontos em dezenas de linguagens, praticamente em todas as linguagens modernas voce encontra no site do projeto.

A vantagem do JSON sobre o XML como formato de troca de dados é a diminuição do tamanho da resposta, facilidade de entendimento para o programador (já que o código é similiar a linguagem que você usa), e principalmente, no caso de javascript, o parser facilitado porque é baseado em sua especificação de objeto.

Código de retorno do Flickr em XML e JSON respectivamente:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<s:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope”>
<s:Body>
<FlickrResponse xmlns=”http://flickr.com/ns/api#”>
<method>flickr.test.echo</method>
<format>soap2</format>
<foo>bar</foo>
<api_key>08d9221b2468be6ccfe5bc229db50181</api_key>
</FlickrResponse>
</s:Body>
</s:Envelope>

 
jsonFlickrApi({
	"method":{
		"_content":"flickr.test.echo"
	},
	"format":{
		"_content":"json"
	},
	"api_key":{
		"_content":"08d9221b2468be6ccfe5bc229db50181"
	},
	"stat":"ok"
})

Dessa forma você pode usar as estratégias de “Eval” ou “Scripttag” para processar o JSON de forma transparente em sua aplicação AJAX. Usado como configuração em aplicações no lado servidor, você pode construir uma arquitetura com base em interfaces para validar os dados, assim como validaria usando schemas no XML.

A maioria das APIs de web services dos principais Players no mercado WEB, passaram a oferecer o JSON como alternativa ao XML pela facilidade de interpretação para a arquitetura REST. Yahoo e Google são os principais expoentes desse mecanismo.