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.

Esse tutorial tem o objetivo de preparar o conhecimento para outros posts que estou escrevendo e achei necessário uma introdução apenas nos conceitos do Extjs para não confundir com as tecnologias que uso em conjunto como DWR ou no modelo REST com o RubyOnRails.

O Extjs é um framework javascript de propósito geral, ou seja, tem um conjunto de funcionalidades que tratam Ajax, um conjunto de Widgets bem elaborados [componentes visuais como Grid e TabPanel], manipulação de DOM [Document Object Model] e BOM [Browser Object Model], tratamento de eventos, animações como Fade In e Fade Out, parser de JSON, entre outras coisas. Seus componentes são construídos com técnicas modernas de orientação a objetos no javascript e manipulação de Scripttag para recursos remotos que não suportam Ajax.

Preparação

Após baixar e descompactar o framework [estou trabalhando na versão 2.x que é estável nessa data], recomendo que deixa a disposição das pastas conforme se encontra e coloque no seu projeto de forma que seja acessível via web, já vem com documentação e exemplos que você deve e vai usar durante o desenvolvimento. Temos a opção de montar o Extjs [marcando a opção "Make build available via CacheFly" ] no CacheFly como um servidor CDN para otimizar o tráfego de sua aplicação principalmente se ela será disponibilizada na internet e não apenas na intranet.

É necessário importar o CSS global, o adapter e o Javascript global conforme mostrado abaixo:

<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/ext-all.css" />
<script src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js" type="text/javascript"></script>
<script src="/javascripts/ext-2.2.1/ext-all.js" type="text/javascript"></script>

Pode usar outros temas para o Extjs, estarão na pasta “resources/css“, assim como podemos internacionalizar os componentes com arquivos que se encontram em “build/locale“. Exemplo com o tema “Gray” e i18n em português do Brasil:

<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/ext-all.css" />
<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/xtheme-gray.css">
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/ext-all.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/build/locale/ext-lang-pt_BR-min.js"></script>

Internacionalização é algo pensado no Extjs de forma a facilitar a criação de arquivos de linguagem aproveitando a estrutura da linguagem [dinâmica e fracamente tipada], todas as propriedades de mensagens e textos são públicas para facilitar a reescrita como mostrado abaixo na i18n do componente de DataPicker:

if(Ext.DatePicker){
   Ext.apply(Ext.DatePicker.prototype, {
      todayText         : "Hoje",
      minText           : "Esta data é anterior a menor data",
      maxText           : "Esta data é posterior a maior data",
      disabledDaysText  : "",
      disabledDatesText : "",
      monthNames        : Date.monthNames,
      dayNames          : Date.dayNames,
      nextText          : 'Próximo Mês (Control+Direita)',
      prevText          : 'Mês Anterior (Control+Esquerda)',
      monthYearText     : 'Escolha um Mês (Control+Cima/Baixo para mover entre os anos)',
      todayTip          : "{0} (Espaço)",
      format            : "d/m/Y",
      okText            : " OK ",
      cancelText        : "Cancelar",
      startDay          : 0
   });
}

Se você usar o CacheFly gerado pela página do Extjs, ele incluir o adapter e o global em um mesmo arquivo, vai ser algo como:

<link rel="stylesheet" type="text/css" href="http://extjs.cachefly.net/ext-2.2.1/resources/css/ext-all.css">
<link rel="stylesheet" type="text/css" href="http://extjs.cachefly.net/ext-2.2.1/resources/css/xtheme-gray.css">
<script type="text/javascript" src="http://extjs.cachefly.net/builds/ext-cdn-771.js"></script>

Adapter

Quando o Extjs passou a ser um framework independente do YUI, passou a adotar outros frameworks como base para funções básicas de manipulação de DOM e Ajax, hoje suporta trabalhar em conjunto com YUI, JQuery, Prototype e totalmente independente. Se o projeto já tem Jquery ou outro framework que trabalha com o Extjs, a utilização dos dois é muito fácil e indicada, principalmente para usar os widgets que são provavelmente os mais poderosos hoje em dia em um framework opensource.

//Exemplos de adapters permitidos
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/jquery/ext-jquery-adapter.js"></script>

Widgets

O principal apelo do Extjs que conquista os desenvolvedores é o layout bem trabalhado dos componentes visuais que são de fácil parametrização. Basicamente todos os componentes funcionam da mesma forma, você o instancia passando um objeto literal de configuração com mostrado abaixo:

//Exemplo do grid
var grid  = new Ext.grid.GridPanel({
autoShow:true, width:750,height:250 //mais parametros 
});
//Exemplo de uma Window
var window = new Ext.Window({
autoShow:true, width:750,height:250 //mais parametros 
});
//Exemplo de um Painel
var panel = new Ext.Panel({
autoShow:true, width:750,height:250 //mais parametros 
});

Vamos usar o GRID para exemplificar como trabalhamos com o Extjs, o mesmo comportamente se repete em todos os componentes.
A documentação do Extjs é muito bem feita e praticamente vai ser a única coisa que você vai precisar depois de entender como os componentes são formados, afinal não vale a pena decorar todas as propriedades de todos os componentes, concentre-se apenas em entender os conceitos.

A GRID é o Widget mais famoso desse framework e é formado basicamente por um objeto “Ext.data.Store” [que é a fonte de dados da GRID] e um objeto “Ext.grid.ColumnModel” [que é a definição das colunas], como mostrado abaixo:

var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250, //parametros de configuração de layout
    cm: new Ext.grid.ColumnModel({/*configuração*/}),
    store: new Ext.data.Store({}), //Ou especialização de um Store
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}), //ou outra especialização de um AbstractSelectionModel
});

O objeto ColumnModel é a definição de colunas do Grid, possui propriedades para definição de layout como largura e altura, título da coluna como vai ser exibida e formatação do texto:

var colModel = new Ext.grid.ColumnModel([
    { header: "Ticker", width: 60, sortable: true},
    { header: "Company Name", width: 150, sortable: true},
    { header: "Market Cap.", width: 100, sortable: true},
    { header: "$ Sales", width: 100, sortable: true, renderer: money},
    { header: "Employees", width: 100, sortable: true, resizable: false}
 ]);

A propriedade cm [ColumnModel] pode ser também substituída pela propriedade “columns” que funciona como um “alias”, dessa forma o Grid cria automaticamente um objeto ColumnModel:

var grid = new Ext.grid.GridPanel({
    columns: [
        {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
        {header: "Nome", width: 120, sortable: true, dataIndex: 'name'}
    ]
});

Caso haja necessidade de formatar o conteúdo da célula, você pode usar uma função como “renderer” para tratar esse conteúdo:

var grid = new Ext.grid.GridPanel({
    columns: [
        {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
        {header: "Nome", width: 120, sortable: true, dataIndex: 'name'},
        {header: "Criado em", width: 135, sortable: true, renderer: function(value) {
                    return Date.parseDate(value, 'Y-m-d\\TH:i:s\\Z').format('d/m/Y H:i:s');
                    //2009-06-14T12:51:07Z
        }, dataIndex: 'created_at'}
    ]
});

A propriedade “store” da GRID é uma especialização do componente “Ext.data.Store” que é formado basicamente por um “proxy” e um “reader“:

var store = new Ext.data.Store({
    proxy: new Ext.data.DataProxy(), //ou uma especialização
    reader: new Ext.data.DataReader() //ou uma especialização
});

O “proxy” é o componente que obterá os dados e o “reader” o componente que fará a leitura desses dados para um formato comum a todos os componentes do Extjs na forma de um objeto denominado “Ext.data.Record“. O objeto “Record” representa um registro de dados e é usado seja para GRID, para um Form ou qualquer componente que trabalhe com dados editáveis.

Dessa forma podemos usar uma combinação de Proxy e Reader como HttpProxy e JsonReader:

var store = new Ext.data.Store({
    proxy: new Ext.data.HttpProxy({
        url: 'projects.json'
    }),
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});

Devido o costume do uso do HttpProxy, o componente Store possui uma propriedade chamada “url” que estando presente cria um HttpProxy automaticamente como mostrado abaixo:

var store = new Ext.data.Store({
    url: 'projects.json',
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});

O objeto “Reader” é o único que foge um pouco a regra de instanciação por receber dois parâmetros, um similar aos outros com um objeto literal de configuração e outro com o mapeamento dos dados. O objeto de configuração tem duas propriedades de que representam o total e a lista de dados. O objeto de mapeamento usa um método “estático” do objeto Record para criar um link entre a propriedade do json [com a propriedade "mapping"] e o índice interno do Record [pela propriedade "name"].

 new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))

Dessa forma você tem um link entre o ColumnName pela propriedade dataIndex e o Store por meio do Reader, como abaixo:

Ext.data.Record.create([
         {name:'nome_linkado', mapping:'name'}
    ])
//
 columns: [
        {header: "Nome", width: 120, sortable: true, dataIndex: 'nome_linkado'}
    ]

Para melhorar a navegação da GRID, você pode também acrescentar um componente de Toolbar no header ou no footer:

var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250, //parametros de configuração de layout
    cm: new Ext.grid.ColumnModel({/*configuração*/}),
    store: new Ext.data.Store({}), //Ou especialização de um Store
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}),
    bbar: new Ext.Toolbar(), //Bottom Toolbar
    tbar: new Ext.Toolbar() //Top Toolbar
});

A Toolbar mais usada é sua especialização com paginação, a Ext.PagingToolbar que necessita ser linkada com o Store:

new Ext.PagingToolbar({
    pageSize:10, //propriedade opcional, default é 20
    store: store
})

A PagingToolbar é I18n, mas se as mensagens não agradarem você pode mudá-las [eu sempre faço]:

new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir"
})

Uma coisa bacana nesse componente é que você pode agrupar botões [já que é uma Toolbar] e até padronizar o layout:

new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir",
    items: ['-', {
        pressed: true,enableToggle: true,text: 'Alterar',
        toggleHandler: function(){}
    }, {
        pressed: true,enableToggle: true,text: 'Excluir',
        toggleHandler: function(){}
	}]
})

Código da GRID inteira:

 
var store = new Ext.data.Store({
    proxy: new Ext.data.HttpProxy({
        url: 'projects.json'
    }),
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});
 
var colModel = new Ext.grid.ColumnModel([
    {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
    {header: "Nome", width: 120, sortable: true, dataIndex: 'name'},
    {header: "Criado em", width: 135, sortable: true, 
        renderer: function(value) {
          return Date.parseDate(value, 'Y-m-d\\TH:i:s\\Z').format('d/m/Y H:i:s');
 
    }, dataIndex: 'created_at'}
 ]);
 
var pagingToolbar = new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir",
    items: ['-', {
        pressed: true,enableToggle: true,text: 'Alterar',
        toggleHandler: function(){}
    }, {
        pressed: true,enableToggle: true,text: 'Excluir',
        toggleHandler: function(){}
	}]
});
 
var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250,
    cm: colModel,
    store: store,
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}),
    bbar: pagingToolbar
});

Como eu falei, todos os componentes possuem o mesmo comportamento, notaram que dá para aproveitar esse código semelhante e reaproveitar em todos os CRUDs?
Vou falando de um por um de acordo com os posts que forem saindo, aguardem que o próximo 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!

Esse pequeno tutorial-guia faz parte do material dos meus cursos de Javascript e Ajax e serve para deixar um histórico acessível aos alunos e fácil para leitores que por ventura precisem.

Preparei um ambiente de execução com todas as dependências no projeto Remendux onde vocês podem fazer checkout e rodar o build ant localmente como um projeto do eclipse – estou usando o plugin para o SVN Subclipse.

Montei um script ant padrão bem simples de ser entendido por iniciantes:

<?xml version="1.0" encoding="UTF-8"?>
<project name="jsmin" default="main" basedir=".">
	<!-- Propriedades para definir nomes de pastas que usaremos -->
	<property name="js" value="js"/>
	<property name="build" value="build"/>
	<property name="lib" value="lib"/>
	<property name="output" value="output"/>
	<!-- Propriedades para definir nomes os arquivos necessários -->
	<property name="yui-compressor.jar"
		location="${lib}/yuicompressor-2.4.2.jar" />
	<property name="yui-compressor-ant-task.jar" 
		location="${lib}/yui-compressor-ant-task-0.3.jar" />
	<!-- Incluir as libs necessárias no classpath -->
	<path id="task.classpath">
		<pathelement location="${yui-compressor.jar}" />
		<pathelement location="${yui-compressor-ant-task.jar}" />
	</path>
	<!-- Definição da task para o Ant reconhecer -->
	<taskdef name="yui-compressor" 
classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
	<classpath refid="task.classpath"/>
	</taskdef>
 
	<target name="clean">
		<delete dir="build"/>
		<delete dir="output"/>
		<mkdir dir="build"/>
		<mkdir dir="output"/>
	</target>
 
	<target name="main" depends="clean">
		<!-- Tag do Ant para concatenar arquivos 
		[ http://ant.apache.org/manual/CoreTasks/concat.html] 
		os arquivos são unidos na sequência de definição 
		no fileset
		-->
		<concat destfile="${output}/remendux.js" force="no">
			<fileset file="${js}/util.js" />
			<fileset file="${js}/remendux.js" />
		</concat>
		<!-- Task do yui-compressor -->
		 <yui-compressor warn="false"  munge="true"  
				preserveallsemicolons="false" 
				fromdir="${output}" todir="${build}">
		</yui-compressor>
	</target>
 
</project>

Após a importação, para executar o script – que chamei de build-yui.xml – basta apenas executar com o ant pelo eclipse – vide imagem abaixo – ou em linha de comando. Estou usando o Ant 7.1 com java 6u10 e Eclipse 3.4, portanto caso haja um erro atente para a versão das ferramentas usadas.

Após executar, observe a redução de tamanho na versão minificada [../build/remendux-min.js] para a versão concatenada [../output/remendux.js ]. A versão final ficou com 30% do tamanho com documentação e identação.

Buildfile: C:\workspace\remendux\build-yui.xml
     [echo] Building output
clean:
    [mkdir] Created dir: C:\workspace\remendux\build
    [mkdir] Created dir: C:\workspace\remendux\output
main:
[yui-compressor]
 [30%] remendux.js [5775] ---> remendux-min.js [1734]
[yui-compressor]
 [JavaScript] Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
[yui-compressor]
 [CSS] No files to compress, or all files already up to date
[yui-compressor]
 Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
BUILD SUCCESSFUL
Total time: 12 seconds

Fernando Chucre iniciou o evento palestrando pelo CEPUG sobre PHP Orientado a objetos. Logo em seguida foi a vez do Jefferson [organizador do evento] palestrar sobre Debug no PHP.
Pelo CEJUG o Silveira Neto apresentou uma palestra sobre a comunidade e o poder do Java, seguido por mim sobre Frameworks Ajax focado em Java com utilização de DWR e ExtJS.

O detalhe mais importante foi constatar a maturidade de duas comunidades tão distintas que compartilharam o mesmo evento sem nenhum problema, egocentrismo ou picuinha. Eu já estou cansando de ir em eventos onde o pessoal só fala de outra tecnologia, como eventos de linguagem onde falam mal de Java o evento inteiro. Cada um apresentou sua palestra sem desmerecer nenhuma tecnologia ou ninguém.

Material

Fotos

Picasa do CMilfont
Flcikr do Silveira

Tudo bem que o Javascript tem sua maior utilidade como linguagem a ser utilizada no Browser, mas a explicação da teoria de orientação a objetos na linguagem e técnicas avançadas de contrução dos objetos é precária.

Três bons livros na galeria abaixo se destacam: “Pro JavaScript Techniques” do John Resig (criador do JQuery); Professional JavaScript for Web Developers do Nicholas C. Zakas, software engineer do Yahoo; e o Professional Ajax (Programmer to Programmer) também com o Nicholas mas em parceria com outros dois autores, Jeremy McPeak e Joe Fawcett.

Os dois livros do Nicholas são bem completos, abordam – com fartos exemplos – toda a orientação a objetos na linguagem e fornecem boas práticas de como trabalhar. O primeiro, do Resig já é mais moderno e cobre alguns pontos que faltaram nos demais, como Closure. Basicamente esses 3 livros são necessários.

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.

Dentre as estratégias para essa troca de recursos entre as camadas distintas, temos IFrame, XHR e o Scripttag.

IFrame era uma técnica muito comum na era pré-ajax, mas que causava vários problemas, além da complexidade desnecessária e natureza gambiarrosa. Um dos problemas da técnica era quando se perdia a referência entre os frames e as páginas que os evocam (acontecia com uma frequência não tão insignificante). Geralmente os frameworks implementam a técnica de IFrame por questão de compatibilidade com browsers mais antigos. Quem não se lembra do escondido.jsp (ou escondido.php, escondido.asp, escondido.etc …)?

Como vimos em um post passado, a técnica de usar o XHR nos proporciona trabalhar com o parsing de XML ou a montagem dinâmica de objetos serializáveis, seja com “Eval” ou usando a capacidade dinâmica da linguagem de definir objetos de forma simples em tempo de execução. Vimos que usar Eval não é bom porque “Eval is Evil“.

A técnica de Scripttag está em alta porque aproveita a própria capacidade do browser para instanciar um trecho de código serializável entre as camadas físicas distintas. A técnica está descrita no Pattern Lazy Loading Javascript ou On-Demand javascript

A técnica consiste em se obter um recurso do servidor em forma de texto, mas já formatado como um código (entidade) javascript e adicionar esse trecho na seção head da página, fazendo com que o próprio Browser instancie como se estivesse lendo a página na carga inicial. Vejamos:

function JSONRequest(url) {
   var head = document.getElementsByTagName("head")[0];
   var script = document.createElement('script');
   script.id = 'TriadworksOnDemand';
   script.type = 'text/javascript';
   script.src = url;
   head.appendChild(script)
}
 
function montaGrid(usuarios) {
    //aguarda um array de usuarios
    for(var x in usuarios) {
        //pega usuarios[x]...
    }
}
 
function pesquisar(id) {
    var url = 'http://server_path/usuario/'+id
                 +"/?callback="+montaGrid;
    JSONRequest(url);
}
 
pesquisar(101);

Observe que criamos uma função chamada JSONRequest, que basicamente pega uma url e adiciona dinamicamente na seção head da página. Essa url é uma saída texto pelo servidor no formato JSON, utilizando o modelo REST para obter um recurso, ou seja, o servidor responde com um objeto serializável no endereço /usuario/id porque ele reconhece que as requisições a esse endereço são lógicas CRUD para a captura do recurso “usuário”. Passo como parâmetro uma variável chamada callback para o servidor renderizar a execução dessa função para ser interpretada assim que o Browser anexar a resposta.

A resposta viria mais ou menos assim:

montaGrid( [
          {'id':'101',
           'nome':'Christiano',
           'sobrenome':'Milfont',
           'email':'cmilfont@gmail.com'
          } ] )

AO executar a função JSONRequest, o código anexa a resposta do servidor na seção Head da página e então o Browser interpreta como se estivesse lendo na carga da página, executando a função montaGrid.

Diferenças entre as abordagens Scripttag e XHR.

* – Basicamente poderíamos dizer que é compatível sim, mas com a diferença na implementação. Somente os browsers mais antigos não possuirão o objeto necessário.

Então o uso racional das abordagens vai depender da necessidade de características de cada uma, cada qual possui suas vantagens e desvantagens. Mais em XML.com.