Problema que detectei em algumas applicações que estamos desenvolvendo com Extjs+Jquery: Na máquina de entrega o request do tipo DELETE funcionava tranquilamente, na máquina de produção hospedada no Rackspace quebrava. Como a máquina de entrega estava dentro da nossa rede, suspeitei logo da conexão, firewall e essas coisas.

O @rponte me deu a dica desse post que ele encontrou com o mesmo tipo de problema. Nunca tinha percebido que a spec HTTP nem proibe e nem recomenda corpo em DELETE. Não faz muito sentido enviar corpo realmente em DELETE, mas até aí tudo bem.

Para completar, o Extjs já previa esse problema e o JsonWriter possui uma propriedade chamada “encodeDelete” para você explicitamente definir que não quer corpo em DELETE, por default já vem assim.

No console do firebug eu utilizava o $.ajax e o Ext.Ajax diretamente com a mesma url para enviar DELETE e funcionava, mas na aplicação não funcionava. Conversando com o pessoal da rede eles me disseram que trocaram o firewall recentemente e observando o log a chamada sequer passava por lá, ou seja, provavelmente ele já rejeita qualquer conexão DELETE com body.

Fui analizar o código do Extjs e ele enviava um body, a diferença é que era vazio, mas ia. Fiz um hack para destruir qualquer parametro quando a conexão fosse para o DELETE e consertou, como pode ver no código abaixo:

Link caso não consiga ver no seu reader.

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.

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

A alternativa para contornar esse problema é usar a estratégia de Scripttag quando o recurso externo permite ou usar um script como proxy no servidor para buscar o recurso e devolver via Ajax. Existem outras formas mais porcas de fazer isso que nem merecem consideração.

O Firefox 3 vem com o recurso de XHR Crossbrowser, agora seguido do IE8. Sinceramente isso não muda nada a curto prazo, até termos as versões anteriores do FF e principalmente do IE aposentadas, teremos que contornar isso com as gambiarras de sempre.

O John Resig (Criador do JQuery) mostra nesse post como usar isso no FF3. Lembrando que isso só funciona no FF3 que ainda é beta.

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.

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.

Sua implementação é possível por causa do objeto javascript XMLHttpRequest que faz uma conexão assíncrona ao servidor e permite que o usuário continue seu trabalho sem bloquear a página. Na época não era especificado ainda pelo W3C.

O XMLHttpRequest surgiu como uma implementação proprietária da Microsoft e posteriormente criado no Mozilla em 2002, logo seguido pelos demais Browsers. A interface definida pelo W3C será o objeto de estudo desse artigo.

Uma conexão remota de forma assíncrona segue o seguinte esquema:

1. Um evento é disparado para dar início a execução;
2. Um objeto XMLHttpRequest é criado e configurado;
3. Uma requisição de um recurso é feita para o servidor;
4. O servidor realizada sua lógica de negócio e devolve o recurso na forma de texto comum (que deve ser um xml em formado);
5. Uma função de callback, previamente informada, manipula os dados retornados;
6. A renderização ao usuário é realizada.

A criação e configuração do objeto, como o envio de requisição pelo XMLHttpRequest para a captura de um recurso remoto segue os seguintes passos:

//instancia um novo objeto
var ajax = new XMLHttpRequest();
//Configura uma function para a manipulação
//da reposta
ajax.onreadystatechange = handler;
//abre a conexão
ajax.open("GET", "test.xml");
//envia a requisição
ajax.send();

Caso a conexão seja pelo método "POST", o método send recebe como parâmetro, as variáveis a serem enviadas.

Criação do objeto

A Microsoft só implementou a interface XMLHttpRequest como um objeto nativo a partir do Internet Explorer 7, antes disso o objeto era um ActiveX. Apesar que os métodos e propriedades haviam sido copiados desse ActiveX, garantindo o funcionamento idêntico a todos os Browsers que suportam o XMLHttpRequest.

Então para as versões anteriores do IE, há a necessidade de criação customizada, eis:

    var http;
    try {
	    //cria o objeto caso o Browser
        //seja compatível com o W3C
        http = new XMLHttpRequest();
    } catch(e) {
        //caso IE < IE7
        //array com versões conhecidas
        //de implementações do ActiveX
        var msxml = [
                   'MSXML2.XMLHTTP.3.0', 
                   'MSXML2.XMLHTTP', 
                   'Microsoft.XMLHTTP'];
        for ( var i=0, len = msxml.length; i < len; ++i ) {
            try {
                //varre o array até identificar qual ActiveX
                http = new ActiveXObject(msxml[i]); break;
            } catch(e) {}
        }
    }

Conhecendo a Interface

Representação da Interface

interface XMLHttpRequest {
  // event handler
  attribute EventListener onreadystatechange;
  // state
  const unsigned short UNSENT = 0;
  const unsigned short OPEN = 1;
  const unsigned short SENT = 2;
  const unsigned short LOADING = 3;
  const unsigned short DONE = 4;
  readonly attribute unsigned short readyState;
  // request
  void open(in DOMString method, in DOMString url);
  void open(in DOMString method, in DOMString url, 
            in boolean async);
  void open(in DOMString method, in DOMString url, 
            in boolean async, in DOMString user);
  void open(in DOMString method, in DOMString url, 
            in boolean async, in DOMString user, 
            in DOMString password);
  void setRequestHeader(in DOMString header, in DOMString value);
  void send();
  void send(in DOMString data);
  void send(in Document data);
  void abort();
  // response
  DOMString getAllResponseHeaders();
  DOMString getResponseHeader(in DOMString header);
  readonly attribute DOMString responseText;
  readonly attribute Document responseXML;
  readonly attribute unsigned short status;
  readonly attribute DOMString statusText;
};

Event Listener

A Interface XMLHttpRequest possui um EventListener denominado "onreadystatechange", que é um manipulador de eventos que é invocado quando o evento readystatechange é acionado. Passamos uma função de tratamento a esse EventListener que verificará os estados da conexão.

//obtem uma instancia
var ajax = new XMLHttpRequest();
//seta o EventListener com o handler
ajax.onreadystatechange = function() {
    //testa se já recebeu e foi com sucesso
    if(this.readyState == 4  && this.status == 200) {
        //obtem o xml enviado pelo servidor
        var xml = this.responseXML;
    }
};

Propriedades

A Interface possui uma propriedade denominada "readyState" que recebe o valor de uma constante que representa o estado atual da conexão. As constantes que representam os estados são definidos como:

1. UNSENT = 0; //Apenas instanciado
2. OPEN = 1; //aberta
3. SENT = 2; //enviada
4. LOADING = 3; //abrindo
5. DONE = 4; //realizada

A propriedade "status" da Interface, representa o código de status do protocolo HTTP enviado pelo servidor, como o código "200" para uma requisição com sucesso. Caso o recurso não esteja disponível, é lançado uma exceção INVALID_STATE_ERR pelo Browser. A lista de "HTTP Status Code" você encontra aqui.

A propriedade "statusText", é a mensagem texto do "HTTP status code", e é recebida logo após ele, como "Not Found" para o "status code" 404, que indica que o recurso não foi encontrado no servidor de destino.

As propriedades "responseText" e "responseXML", devolvem a resposta do servidor na forma de uma DOMString (texto) e Document (da especificação DOM) respectivamente, em outras palavras, devolve um texto puro no caso do responseText ou um xml parseado no caso do responseXML.

Métodos

O método "abort" cancela a requisição, entretanto ele percorre uma série de atividades dependendo do estado da requisição no momento que é invocado. Para uma explanação mais apropriada no mecanismo que o abort realizada, visite esse link da especificação da Interface.

O método "open" é overloaded na Interface, apesar de não existir overloading em javascript. Leve em consideração que é um só, na implementação o número de argumentos passados tem a ver com a funcionalidade dependente do método, exemplo, os parâmetros "user" e "password" são necessários apenas no caso de url restrita no servidor, e caso o parâmetro "async" não seja definido, a conexão é assíncrona por default. Os primeiro parâmetro representa o método HTTP de requisição, que pode ser dos tipos: POST, GET, PUT, HEAD, DELETE e OPTIONS. O segundo parâmetro é a url que receberá a requisição, o terceiro, quarto e quinto são opcionais como já falado.

O método "setRequestHeader" é usado antes do método "send" e habilita enviar informações de cabeçalho na requisição quando for disparado os recursos ao servidor.

O método "send" envia a requisição com o argumento opcional "data" que é do tipo "Text" ou "Document".

Quando o método de requisição escolhido é o GET, os argumentos a serem enviados ao servidor é usado no parâmetro "url", como "/pagina.jsp?id=1&nome=milfont". Já no método POST, os dados serão enviados como argumento do método "send"

Código completo de uma submissão Ajax

    var http;
    try {
        http = new XMLHttpRequest();
    } catch(e) {
        var msxml = [
                   'MSXML2.XMLHTTP.3.0', 
                   'MSXML2.XMLHTTP', 
                   'Microsoft.XMLHTTP'];
        for ( var i=0, len = msxml.length; i < len; ++i ) {
            try {
                http = new ActiveXObject(msxml[i]); break;
            } catch(e) {}
        }
    }
    http.onreadystatechange = function() {
        if(this.readyState == 4  && this.status == 200) {
           var xml = this.responseXML;
        }
    };
    var params = "id=1&name=milfont";
    http.open("POST", "pagina.jsp");
    http.setRequestHeader("Content-type", 
	                  "application/x-www-form-urlencoded");
    http.setRequestHeader("Content-length", params.length);
    http.setRequestHeader("Connection", "close");
    http.send(params);

Para mais features nas próximas versões da especificação mas que já podem existir nas implementações, visite esse link.