Olá, é com grande satisfação que gostaríamos de compartilhar com você nosso novo curso curso online, o Imersão ExtJS 4 que será ministrado pelo Christiano Milfont que irá tratar sobre as melhores práticas para desenvolver WebApps com riqueza de usabilidade usando ExtJS 4.

O Framework Javascript de propósito geral ExtJS possui Widgets [componentes] que fascinam e agilizam o desenvolvimento principalmente de aplicações comerciais que são migradas do Desktop.

Existem bons livros já publicados, como o da brasileira Loiane Groner, que também está publicando um curso gratuito no formato de Screencasts cobrindo o básico do ExtJS e aprofundando com muitos exemplos. O próprio Framework contém uma excelente documentação, uma gama enorme de exemplos, abrangendo inúmeras situações.

Bootstrapping

Uma grande dificuldade para desenvolver WebApps, principalmente para desenvolvedores especializados no Backend, é a aridez de desenhar a interface com CSS e trabalhar o comportamento da visão com Javascript.

Enquanto os sistemas operacionais fornecem um conjunto de componentes de Interface por meio de API e Look’n'Feel padronizado para você simplesmente construir a aplicação, na Web o trabalho é bastante artesanal, inclusive com a necessidade de trabalhar com ferramentas especializadas de design como GIMP ou Photoshop.

Não é à toa que o Toolkit Bootstrap disponibilizado pelo Twitter faz tanto sucesso, inclusive com o mesmo nome da técnica de construir um modelo de layout com componentes padronizados para facilitar a construção de aplicações web.

O ExtJS já fornece embutido no seu Framework todo um conjunto de templates e elementos gráficos para utilizar com seus componentes, além da abertura para customização caso seja necessário. Além disso existem diversos templates distribuídos por terceiros.

Diferencial do Curso

Como já mencionado, existe uma infinidade de materiais disponíveis na Web onde você pode aprender por conta própria.

O diferencial do nosso curso não é simplesmente aprender sobre os Widgets e montar telas ricas, é a experiência de quem desenvolve com o Framework desde que ele era uma extensão do YUI [Framework do Yahoo].

Iremos demonstrar as melhores práticas de como construir aplicações verdadeiramente ricas que são proibitivas de serem construídas num processo artesanal por meio de JS e CSS por dar muito trabalho.

Vamos tratar sobre assuntos espinhosos, como extender componentes, modificar o comportamento natural de elementos do próprio HTML, como navegação por meio de eventos que não existem e ainda vamos dar uma palhinha de como construir uma aplicação que se adapte a dispositivos móveis usando o SenchaTouch com o mínimo de esforço dentro do possível.

Matricule-se já e garanta sua vaga.

Apresentei no QCON São Paulo 2011 um Lightning Talk: “Engine de template em Javascript com HTML Sprites”. A estratégia consiste em montar um template com suas Partials no mesmo arquivo html para facilitar o trabalho de renderização usando DIVs como “sprites”, assim como fazemos com CSS.

Para a estratégia eu construí uma Engine de Templates minimalista quase Logic-less baseada na EL do JSP. Quase Logic-less porque a única lógica permitida são sentenças como IF Ternário, comparações e o conceito de Helpers (como no Rails), que não passam de funções javascript simples que retornam alguma formatação para a VIEW.

No meu curso Javascript Fundamental, um dos exercícios é construir essa engine que chamei de ELJS.

A grande diferença entre o ELJS e o Mustache (Engine Logic-less famosa) são os Helpers e o conceito de compilação separado da própria renderização. A grande vantagem da compilação é fazer um parser das marcações e deixar o template preparado para interpolação sem precisar tratar sentenças a cada chamada de “render”.

Assim como o Mustache, o tratamento dos Partials é feito fora da Engine, no meu caso eu tratei no plugin para jQuery (TODO: terminar plugins para outras bibliotecas/frameworks).

Atualizei o plugin para jQuery apresentado no evento com a última versão que usamos nos nossos projetos e tornamos Open Source. Criei uma página de exemplo como funciona a estratégia, mas os testes facilitam a compreensão, principalmente o teste do plugin.

Dá uma olhada nos slides novamente para entender a evolução dessa estratégia.

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.

Fui convidado pelo Daniel Lopes para palestrar no primeiro Café com TOM da famosíssima @egenial em 5 de fevereiro próximo. Essa palestra será sobre o ecossistema Sencha, principalmente sobre o Extjs, a nova versão que vem por aí, o Sencha Touch, experiencias desde ERPs a pequenos sistemas especialistas, além de dicas e problemas que tivemos.

Agora em 2011 a Egenial está vindo com tudo, o curso de node.js surpreendeu, apostaram em um curso sobre uma tecnologia que ainda não está no Mainstream.

A Egenial tem um modelo de negócio que acredito que será exclusivo no futuro e já está estourando agora, treinamento online. Treinamento presencial ainda terá algum espaço pela cultura que crescemos, mas tende a extinguir em um futuro próximo.

Nos encontramos no dia 5 as 14h, como sempre eu estouro o tempo de minhas apresentações, então não tem hora para acabar

Galera da guru_ce está mandando muito bem, dê uma sacada como foi o encontro:

Fiz código na hora e como sempre não deu tempo de mostrar tudo que eu gostaria, estourei o tempo e saímos de lá por volta de 12:30. Espero ter gerado curiosidade na dobradinha sencha e rails, vamos ver se a galera manda dúvidas para a lista.

No meu curso de Javascript Avançado eu dedicava um tempo para trabalhar conceitos básicos dos Frameworks, alguns códigos você ainda encontra no Remendux. Próximo ano voltarei com esse curso.

Agora esse livro concentra praticamente tudo que você precisa saber para entender e estender qualquer framework. Corra lá, baixe, estude e pratique.

Tenho refatorado alguns códigos javascript e o pessoal tem resolvido o conflito de forma confusa e misturando código de dois framework, inclusive código DOM nativo. A documentação recomenda, como uma opção, atribuir o resultado da função noConflict a uma variável e ela será o seu objeto JQuery.

Imagina que você tem Prototype e Jquery na mesma aplicação como no codigo abaixo:

$J = jQuery.noConflict();

//codigo prototype
$("id_de_algum_elemento").hide();
//codigo jquery em seguida
$J("#id_do_elemento").load("caminho.html");

A legibilidade vai ser horrível para manutenção desse código porque você vai ficar com códigos misturados com sintaxes e estilos diferentes, a medida que isso vai crescendo a manutenção vai ficando impossível.

Minha sugestão é utilizarem Closure e Currying para resolver o conflito, isolar o código e deixar bem mais claro. Se ler a documentação lá do noConflict tem exemplo como o código abaixo.

/* essa chamada evita o conflito com outros
   frameworks que usam dollar ($) */
jQuery.noConflict();

(function($) {
   // Seu código jquery vai aqui
  $("#id_do_elemento").load("caminho.html");
})(jQuery);

//codigo prototype
$("id_de_algum_elemento").hide();
//...

Se você preferir deixar claro a diferença entre os frameworks pode continuar a usar outra variável no lugar do $, mas a idéia é isolar o código de cada framework.

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

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.