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.

Fiz um resumo da história do padrão MVC com base nesse artigo do Brian McCallister, e cometi o pecado inenarrável de misturar camadas e MVC na mesma descrição sem especificar claramente a diferença de um para o outro e separar na explicação onde entrava cada um dos conceitos na evolução até chegar no Model 3.

Não vou dar desculpas e a única coisa em minha defesa é que foi o primeiro artigo que, diga-se de passagem, passou por 8 revisões até chegar ao nível que a revista queria, tive que limar bastante e deixar a explicação fácil para iniciantes. Limei bastante, cortei muito e deixei uma parte confusa. Erro crucial que pago até hoje, porque muita gente entra em contato para entender melhor o que eu “quis” dizer.

MVC e Camadas

Sendo sucinto, deixando logo claro que MVC não tem a ver com camadas, são dois conceitos que se “completam” e se misturam frequentemente dependendo da situação. Tem uma excelente explicação sobre isso nesse artigo do Phillip “Shoes” Calçado. No Model 3 eu uso duas camadas físicas na implementação desse conceito, vamos a explicação.

O que é o Model 3

O Model 3 é conhecido nas listas de discussões de tecnologias WEB 2 como Model 2 + 1, alguém que não lembro propôs esse termo para o que estamos fazendo. Apelidei de Model 3 [2+1, criatividade heim!, sou foda nisso] para dizer que fui eu que criei o termo e fazer fama e sucesso, mas é mentira, isso já existe bastante tempo, inclusive não trouxe nenhuma tecnologia nova, apenas como organizar as coisas.

Significa que os Frameworks Model 2 são ajaxificados com Frameworks Javascript ou integrados com tecnologias RIA como XUL e Flex onde parte da responsabilidade de controle e toda a visão é transferida para o lado cliente, ou seja, a camada de apresentação [layer] inteira foge do lado servidor para a camada física [tier] cliente.

Onde entra as camadas e o MVC?

Observe na figura 1 que todo o processamento da camada de apresentação de uma aplicação usando um Framework Model 2 é realizado no lado servidor, em uma mesma camada física. No lado cliente só existe a exibição de uma página renderizada no formato HTML.

Figura 1. Model 2.

Na figura 2 temos uma proposta de mudança para o processamento do Model 2, transferindo toda a apresentação para o lado cliente, com visão e parte do controle para uma tecnologia especialista nessa camada física.

Figura 2. Separação em camadas do Model 3.

Há duas vantagens claras, melhor usabilidade por parte do usuário [quando bem construída a aplicação] e desafogamento do servidor em tarefas desnecessárias, como transformação em HTML.

Como construímos uma aplicação com Model 3?

Bem, uso DWR como cola entre as camadas físicas distintas, ele faz a transferência de entities de forma transparente na aplicação.

Para visão eu uso o ExtJS que assume toda a renderização na UI e, integrado ao DWR, coordena o controle da aplicação com uma usabilidade melhor do que a forma tradicional.

No lado servidor o Model segue Hibernate + Spring de forma tradicional usando o DWR como fachada entre o domínio e o controle com POJOS apenas.

Tanto na minha palestra quanto na do Handerson no último CCT, vi que muitos presentes não conhecem o DWR e pior, continuam usando Struts para desenvolvimento de novas aplicações. Nos próximos posts vou abordar mais profundamente esse aspecto do desenvolvimento WEB.

Confira a grade de programação e faça sua inscrição, mesmo que você não seja do Nordeste, vale a pena visitar essas praias lindas. Fui em Natal no ano da graça do senhor de 1999, mas nesse milênio eu ainda não visitei essa cidade maravilhosa.

Vocês sabiam que eu passei na Federal de Natal mas acabei ficando em Fortal mesmo?

Minha palestra terá o tema: Ajaxificando suas aplicações, no horário 17:50h – 18:35h.

Estarei representando nosso estado, o Ceará, e o CEJUG.

Resumo da palestra:

“A plataforma Java para a WEB sempre foi reconhecida injustamente pela complexidade e overhead de abstrações desnecessárias para coisas simples, como operações CRUD. Conheceremos maneiras de evitar essa complexidade, aplicando usabilidade próxima ao desktop com frameworks Ajax, deixando o mais próximo possível do MVC original.”