GWT usando o Padrão MVP

Transcrição

1 a r t i g o Fábio Miranda (fabio@airframes.com.br) é engenheiro de computação, graduado pelo ITA em Programa em Java SE desde 2002, e desenvolve sistemas web desde Trabalha na Airframes Engenharia & Estratégia ( desde 2005, onde atua em projetos na área de aviação civil (controle de manutenção de aeronaves e auditorias de segurança de voo). Participa do fórum RioJUG e mantém o blog Uma Arquitetura de Aplicação GWT usando o Padrão MVP Diferentemente da maioria dos frameworks Web existentes, o GWT não estabelece uma forma rígida de trabalho. Pelo contrário, pode ser integrado a qualquer tecnologia server-side inclusive tecnologias não- Java! Porém, existem boas práticas que permitem que o desenvolvimento GWT seja mais organizado, testável e de fácil manutenção. Este artigo ilustra o desenvolvimento de aplicações GWT usando o padrão MVP, à luz da apresentação GWT App Architecture Best Practices, realizada no Google I/O No artigo Hello GWT!, publicado na edição anterior da revista Mundoj, a aplicação de exemplo criada automaticamente pelo Google Plugin for Eclipse (GPE) foi destrinchada passo a passo, mostrando o funcionamento básico do GWT. Foram apresentados conceitos suficientes para programar aplicações simples. Entretanto, é fundamental estabelecer uma arquitetura-base, que possa ser adotada em aplicações mais complexas. A comunidade GWT vem adotando o MVP (Model-View-Presenter) como padrão elementar em suas arquiteturas. Uma discussão mais abrangente sobre este padrão e suas diferenças em relação ao MVC (Model-View- Controller) pode ser encontrada no blog Mind Share e em artigos facilmente encontrados pela Web. Neste artigo, será adotada uma abordagem prática, através da refatoração do código do artigo Hello GWT!, de modo a alcançar os objetivos propostos pelo MVP. À medida que os objetivos forem alcançados, serão apresentados os conceitos relevantes. 48

2 Refatoração da camada de apresentação A principal responsabilidade da View é exibir a Interface Gráfica para o usuário (User Interface ou UI). Na classe Artigo (em grande parte gerada automaticamente pelo plugin do Eclipse, GPE, e trabalhada no primeiro artigo desta série, Hello GWT! ) é relativamente fácil identificar e separar o código que lida exclusivamente com a construção da UI, conforme mostrado na Listagem 1. Listagem 1. ArtigoView.java. public abstract class ArtigoAbstractView { public static interface Messages extends GreetingMessages, ServerMessages { final Messages messages = GWT.create(Messages.class); final TextBox namefield = new TextBox(); final Button sendbutton = new Button(messages.sendButtonLabel()); public void render() { Window.setTitle(messages.heading()); RootPanel.get( heading ).add(new HTML(messages.heading())); RootPanel.get( textboxlabel ).add(new Label(messages.textboxLabel())); RootPanel.get( namefieldcontainer ).add(namefield); RootPanel.get( sendbuttoncontainer ).add(sendbutton); namefield.settext(messages.defaulttextvalue()); namefield.setfocus(true); namefield.selectall(); sendbutton.addstylename( sendbutton ); insertimages(); inserttemporaryimages(); protected abstract String greet(string text, String serverinfo, String useragent); // por conveniência, foi omitido o código que lidava com imagens e i18n No primeiro artigo foi suposto que a aplicação poderia ter dois tipos de view, uma na qual a resposta seria exibida em um alert e outra na qual a resposta seria exibida em uma caixa de diálogo. A classe da Listagem 1 é abstrata e encapsula o código comum aos dois tipos de view, mostrados nas Listagens 2 e 3. Depois dessa separação forçada, o código que restou em Artigo.java deve aparecer na IDE com indicações de erros de compilação, pois o código que comandava a lógica da apresentação estava altamente acoplado aos widgets da View. Para desacoplar esta lógica, cria-se um Presenter (Listagem 4). Ele possui internamente uma interface chamada Display: uma abstração da view que ele poderá manipular, para poder alterar diretamente a exibição da Listagem 2. View utilizando Alert. public class ArtigoAlertView extends ArtigoAbstractView protected String greet(string text, String serverinfo, String useragent) { return messages.greeting(text) +!\n\n + messages.serverinfogreeting(serverinfo) + \n\n + messages.useragentgreeting() + \n + useragent; Listagem 3. View utilizando caixa de diálogo. public class ArtigoDialogView extends ArtigoAbstractView { final DialogBox dialogbox = new DialogBox(); final Label texttoserverlabel = new Label(); final HTML serverresponselabel = new HTML(); final Button closebutton = new Button(messages.closeButtonLabel()); public ArtigoDialogView() { VerticalPanel dialogvpanel = new VerticalPanel(); dialogvpanel.addstylename( dialogvpanel ); dialogvpanel.sethorizontalalignment(verticalpanel.align_right); dialogvpanel.add(new HTML( <b> + messages.sendmessage() + </b> )); dialogvpanel.add(texttoserverlabel); dialogvpanel.add(new HTML( <br><b> + messages.replymessage() + </b> )); dialogvpanel.add(serverresponselabel); closebutton.getelement().setid( closebutton ); dialogvpanel.add(closebutton); dialogbox.settext(messages.rpclabel()); dialogbox.setanimationenabled(true); dialogbox.setwidget(dialogvpanel); closebutton.addclickhandler(new ClickHandler() { public void onclick(clickevent event) { dialogbox.hide(); sendbutton.setenabled(true); sendbutton.setfocus(true); protected String greet(string text, String serverinfo, String useragent) { return messages.greeting(text) +!<br><br> + messages.serverinfogreeting(serverinfo) + <br><br> + messages.useragentgreeting() + <br> + useragent; UI, bem como para poder responder aos eventos disparados por ela. Note que o presenter não faz referência a nenhum widget concreto (baixo acoplamento com a view), todas as interações com a view são realizadas através de chamadas da interface Display. Note também que o código ficou muito mais limpo e legível, com as responsabilidades melhores organizadas, com a view encapsulando todos os widgets e o presenter lidando com as interações entre a view e o modelo. 49

3 Listagem 4. Presenter registra um handler aos eventos do Display, o qual encapsula os widgets da View. public class ArtigoPresenter { public interface Display { HasValue<String> namefield(); HasKeyUpHandlers namefieldhandler(); HasClickHandlers sendbutton(); void onsend(greetingaction action); void showfailure(); void showgreeting(greetingaction action, GreetingResponse response); private final Display display; private final GreetingServiceAsync service; public ArtigoPresenter(Display display, GreetingServiceAsync service) { this.display = display; this.service = service; binddisplay(); private void binddisplay() { Interactor handler = new Interactor(); display.sendbutton().addclickhandler(handler); display.namefieldhandler().addkeyuphandler(handler); class Interactor implements ClickHandler, KeyUpHandler { public void onclick(clickevent event) { sendnametoserver(); public void onkeyup(keyupevent event) { if (event.getnativekeycode()==keycodes.key_enter) sendnametoserver(); private void sendnametoserver() { String texttoserver = display.namefield().getvalue(); final GreetingAction action = new GreetingAction(textToServer); display.onsend(action); service.execute(action, new AsyncCallback<GreetingResponse>() { public void onfailure(throwable caught) { display.showfailure(); public void onsuccess(greetingresponse response) { display.showgreeting(action, response); ); Obviamente, ArtigoAbstractView (Listagem 1) terá que implementar a interface ArtigoPresenter.Display (Listagem 5). Nas classes das Listagens 2 e 3, é necessário implementar os métodos da interface responsáveis por lidar com a resposta do usuário, seja com alert ou caixa de diálogo, o que é mostrado nas Listagens 6 e 7. Listagem 5. AbstractArtigoView implementa os métodos da interface Presenter.Display que dão acesso aos widgets da tela que disparam eventos. public abstract class ArtigoAbstractView implements ArtigoPresenter.Display { final TextBox namefield = new TextBox(); final Button sendbutton = new Button(messages.sendButtonLabel()); // HasValue<String> namefield() { return namefield; HasKeyUpHandlers namefieldhandler() { return namefield; HasClickHandlers sendbutton() { return sendbutton; void onsend(greetingaction action) { sendbutton.setenabled(false);... Listagem 6. ArtigoDialogView implementa os métodos da interface que o Presenter utiliza para atualizar a tela, ao receber a resposta do serviço. public class ArtigoDialogView extends ArtigoAbstractView { // void onsend(greetingaction action) { super.onsend(action); texttoserverlabel.settext(action.gettexttoserver()); serverresponselabel.settext( ); void showfailure() { dialogbox.settext(messages.rpcfailure()); serverresponselabel.addstylename( serverresponselabelerror ); serverresponselabel.sethtml(messages.servererror()); closebutton.setfocus(true); void showgreeting(greetingaction action, GreetingResponse response) { dialogbox.settext(messages.rpclabel()); serverresponselabel.removestylename( serverresponselabelerror ); String text = action.gettexttoserver(); String serverinfo = response.getserverinfo(); String useragent = response.getuseragent(); serverresponselabel.sethtml(greet(text, serverinfo, useragent)); closebutton.setfocus(true); 50

4 Listagem 7. ArtigoAlertView implementa os métodos da interface que o Presenter utiliza para atualizar a tela, ao receber a resposta do serviço. public class ArtigoAlertView extends ArtigoAbstractView { //... void showfailure() { Window.alert(messages.rpcFailure() + \n\n + messages.servererror()); void showgreeting(greetingaction action, GreetingResponse response) { String text = action.gettexttoserver(); String serverinfo = response.getserverinfo(); String useragent = response.getuseragent(); Window.alert(greet(text, serverinfo, useragent)); sendbutton.setenabled(true); Listagem 8. EntryPoint, que constrói a aplicação GWT. public class Artigo implements EntryPoint { private final GreetingServiceAsync greetingservice = GWT. create(greetingservice.class); private final Display display = new ArtigoDialogView(); // private final Display display = new ArtigoAlertView(); private final ArtigoPresenter presenter = new new ArtigoPresenter(display, greetingservice); public void onmoduleload() { presenter.display.render(); Figura 1. Diagrama de componentes. Pronto! Veja o que restou ao EntryPoint (Listagem 8): ficou enxuto, encarregado apenas de construir a aplicação e conectar os elementos do MVP entre si. O presenter responde aos eventos da view e comanda o modelo, representado pelo serviço. Para alternar entre as implementações da view (escolher se a aplicação responderá ao usuário utilizando caixa de diálogo ou alert), basta comentar a linha apropriada. A troca de uma view por outra não afeta em nada a lógica do presenter! Esta aplicação é bem simples, mas é importante frisar que, em aplicações complexas, o EntryPoint é um dos possíveis lugares onde pode ser montada a aplicação, agregando seus componentes. A figura 1 mostra o Diagrama de Componentes atual da aplicação. Note que o presenter está desacoplado da view, graças à abstração obtida com a interface Display; o presenter liga (binds) um interactor aos widgets da view utilizando esta abstração; através do interactor, o presenter consegue responder aos eventos da view, comandando a contraparte assíncrona do serviço; esta deixa um AsyncCallback aguardando a resposta do servidor; e, por fim, quando a resposta chega, o presenter atualiza a view. Note que o MVP é um padrão da Camada de Apresentação. Todo código desta camada deve estar presente em source packages, os quais são compilados para JavaScript. Por padrão, todo package de prefixo client é um source package, sendo possível adicionar outros prefixos de source packages através do descritor GWT. A figura 2 mostra um modelo geral do MVP, publicado no blog Design Codes, evidenciando que o modelo pode possuir uma parte residindo no lado cliente e outra parte residindo no lado servidor. É fácil correlacionar os elementos das figuras 1 e 2, observando apenas que, no código mostrado neste artigo, a seta que aponta para o elemento Model (Client) da figura 2 é bidirecional: a view está com acesso direto aos objetos GreetingAction e GreetingReponse, que pertencem ao Model; e o modelo consegue notificar as suas mudanças para a view, ainda que indiretamente, através do AsyncCallback. Esta variação do MVP foi catalogada por Martin Fowler como Supervising Controller (figura 3). 51

5 Presenter Command Interaction Selection WEB Model Client View Model Server Database Figura 2. Diagrama MVP (retirado do blog Design Codes ) Only for complex loigc Presenter Command User Action Triggered Update display Model Query (event) View State Changed Figura 3. Supervising Controller Design Pattern (retirado do blog Design Codes ). 52

6 Desacoplamento usando Application Events Analisando a Listagem 4 e a figura 1, pode-se notar um grande esforço para desacoplar o Presenter e a View. Isto é alcançado apenas parcialmente: apesar de o presenter ter deixado de conhecer boa parte dos detalhes da view, a interface Display ainda revela muito: ela força a realização da UI através de widgets que implementam as interfaces HasValue, HasKeyUpHandler e HasClickHandler, pertencentes à biblioteca-base GWT. Isto impede, por exemplo, a construção de UIs que utilizam widgets de outras bibliotecas baseadas no GWT (por exemplo: GXT e Smart GWT), mas que não obrigatoriamente estendem as interfaces da biblioteca-base. É necessário que o presenter desempenhe seu papel de comandar a View sem estar tão fortemente acoplado à API GWT. Para contornar o problema, pode-se deslocar o interactor para a view, onde sua responsabilidade será traduzir estímulos da view em application events, eventos da aplicação. O presenter, ao invés de registrar interactors para widgets, passará a registrar tratadores ou handlers para eventos. Note, na Listagem 10, que a interface Display deixa de dar acesso aos widgets, e passa apenas a fornecer os métodos necessários para o presenter registrar os handlers. A Listagem 9 mostra como criar eventos, que devem implementar a interface GwtEvent. Também é necessário declarar uma interface que estende EventHandler para definir o contrato que os tratadores desse evento deverão realizar. A realização da interface GreetingEvent.Handler é uma classe anônima dentro do método binddisplay() na Listagem 10. A Listagem 11 mostra parte do novo código da view, implementando o método addhandler(), o que permite ao presenter registrar tratadores de application events. Em resumo: teractor: o Cria um application event GreetingEvent populado com os dados aplicáveis. o Aciona o método handler.ongreeting do tratador de eventos. do pelo presenter (Listagem 10) em uma classe anônima que realiza a interface GreetingEvent.Handler. Listagem 9. GreetingEvent e GreetingEvent.Handler estendem GwtEvent e EventHandler, pertencentes à API base do GWT. public class GreetingEvent extends GwtEvent<GreetingEvent.Handler> { public static interface Handler extends EventHandler { public void ongreeting(greetingevent event); public final String message; public GreetingEvent(String message) { this.message = message; // campo estático usado para registrar eventos em um HandlerManager public static final GwtEvent.Type<Handler> TYPE = new GwtEvent.Type<Handler>(); GwtEvent.Type<Handler> getassociatedtype() { return TYPE; // protegido, pois só deve ser invocado por HandlerManagers void dispatch(handler handler) { handler.ongreeting(this); Listagem 10. Presenter registra um Application Handler no display. public class ArtigoPresenter { public interface Display { void addhandler(greetingevent.handler handler); void render(); void showfailure(); void showgreeting(greetingaction action, GreetingResponse response); // private void binddisplay() { display.addhandler(new GreetingEvent.Handler() { void ongreeting(greetingevent event) { final GreetingAction action = new GreetingAction(event.message); service.greet(action, new AsyncCallback<GreetingResponse>() public void onfailure(throwable caught) { public void onsuccess(greetingresponse response) { display.showgreeting(action, response); ); ); 53

7 Figura 4. Diagrama de Componentes, adicionando GreetingEvent e GreetingEvent.Handler, e deslocando o Interactor para a View. Listagem 11. Na View, o método addhandler faz uso de interactors para reagir aos widget events e notificar os application handlers. public void addhandler(greetingevent.handler handler) { Interactor interactor = new Interactor(handler); namefield.addkeyuphandler(interactor); sendbutton.addclickhandler(interactor); class Interactor implements ClickHandler, KeyUpHandler { private final GreetingEvent.Handler handler; Interactor(GreetingEvent.Handler handler) { this.handler = handler; public void onclick(clickevent event) { notifyhandler(); public void onkeyup(keyupevent event) { if (event.getnativekeycode()==keycodes.key_enter) notifyhandler(); private void notifyhandler() { String texttoserver = namefield.getvalue(); handler.ongreeting(new GreetingEvent(textToServer)); Event Bus (barramento de eventos) É possível generalizar ainda mais o conceito dos application events. Eles podem ser utilizados não apenas como um meio mais adequado para o presenter reagir aos eventos da view, como também para prover um meio global de comunicação na aplicação. A esse meio global dá-se o nome de barramento de eventos (event bus). Esta técnica é ilustrada nos slides 35 a 42 da apresentação de best practices do GWT de Ray Ryani. Para exemplificar, será adicionado mais um par view/presenter à aplicação, cuja responsabilidade será listar na tela todas as mensagens enviadas pelos usuários. Portanto, o envio de mensagem deve ser capaz não só de mostrar a resposta do servidor na tela, como também atualizar a lista as mensagens. O event bus ajudará a realizar esta comunicação, mantendo desacoplados os subsistemas ou módulos da aplicação. Para implementar o barramento de eventos, pode-se utilizar a classe HandlerManager, da API GWT. Quando a aplicação necessitar notificar vários presenters para atualizarem suas views, cada presenter terá que adicionar um handler no barramento, informando o tipo de evento (application event) no qual está interessado, e o respectivo tratador (handler), que atualizará a sua view. A figura 5 ilustra o mecanismo. A Listagem 12 mostra a classe MessagesPresenter, responsável por listar as mensagens. O método initbus registra dois handlers no barramento, um para quando a aplicação é iniciada, outro para responder a notificações de novas mensagens do usuário. Quando um evento ocorre, o barramento informa a todos os tratadores registrados para o tipo do evento disparado, e cada tratador pode então atuar sobre a sua respectiva view. 54

8 Figura 5. Através do barramento, um módulo consegue notificar os demais para atualizarem seu estado em resposta a eventos da aplicação. Listagem 12. MessagesPresenter registra handlers para StartupEvent e NewMessageEvent. public class MessagesPresenter { public interface Display { void list(listgreetingresponse greetings); void fail(); void render(); public final Display display; public final GreetingServiceAsync service; public final HandlerManager eventbus; public MessagesPresenter(Display d, GreetingServiceAsync s, HandlerManager bus) { this.display = d; this.service = s; this.eventbus = bus; initbus(); private void initbus() { final AsyncCallback cb = new AsyncCallback<MessageListResponse>() { void onfailure(throwable caught) { display.fail(); void onsuccess(messagelistresponse result) { display.list(result); ; eventbus.addhandler(startupevent.type, new StartupEvent.Handler() { void onstartup() { service.list(cb); ); eventbus.addhandler(newmessageevent.type, new NewMessageEvent.Handler() { void ongreetingresponse(newmessageevent event) { service.list(cb); ); Listagem 13. ArtigoPresenter agora notifica o barramento de eventos quando o servidor responde que recebeu uma nova mensagem. public class ArtigoPresenter { //... public ArtigoPresenter(Display display, GreetingServiceAsync service, HandlerManager bus) { this.display = display; this.service = service; this.eventbus = bus; binddisplay(); private void binddisplay() { display.addhandler(new GreetingEvent.Handler() { ); void ongreeting(greetingevent event) { final GreetingAction action = new GreetingAction(event.message); service.greet(action, new AsyncCallback<GreetingResponse>() { ); public void onsuccess(greetingresponse response) { display.showgreeting(action, response); eventbus.fireevent(new NewMessageEvent()); 55

9 Listagem 14. EntryPoint, SEM Injeção de Dependências. public class Artigo implements EntryPoint { final HandlerManager eventbus = new HandlerManager(null); final GreetingServiceAsync greetservice = GWT.create(GreetingService.class); final ArtigoPresenter.Display greetdisplay = new ArtigoDialogDeclarativeView(); final MessagesPresenter.Display messagesdisplay = new MessagesView(); private final ArtigoPresenter greetpresenter = new ArtigoPresenter(greetDisplay, greetservice, eventbus); private final MessagesPresenter messagespresenter = new MessagesPresenter(messagesDisplay, greetservice, eventbus); public void onmoduleload() { greetpresenter.display.render(); messagespresenter.display.render(); eventbus.fireevent(new StartupEvent()); É necessário atualizar também a classe ArtigoPresenter (Listagem 13), para notificar o barramento quando o servidor informar o recebimento de novas mensagens. Por fim, atualiza-se o EntryPoint (Listagem 14), sem esquecer de disparar um StartupEvent no barramento de eventos quando a aplicação é iniciada. Perceba na Listagem 14 que o eventbus é injetado nos presenters através de seus respectivos construtores (assim como os displays e serviços concretos). É desejável também tornar o barramento único e global, o que pode ser realizado através do padrão Singleton. Porém, a forma mais elegante e poderosa é utilizar um container de injeção de dependências. Dependency Injection na camada de apresentação A aplicação só tem duas telas, mas a Listagem 14 já mostra que começa a ficar trabalhoso criar manualmente os objetos da aplicação, bem como gerenciar seus ciclos de vida. Para criar ArtigoPresenter e MessagesPresenter, o EntryPoint da aplicação precisa criar também as suas várias dependências: ArtigoDisplay, MessagesDisplay, GreetigServiceAsync e HandlerManager. Além de instanciá-las, é preciso passá-las como argumentos nos construtores dos respectivos presenters. Listagem 15. Interface utilizada para obter objetos com dependências injetadas pelo public interface Injector extends Ginjector { HandlerManager eventbus(); ArtigoPresenter sendmessagepresenter(); Listagem 16. Módulo que configura as dependências. EventBus marcado como Singleton. public class ArtigoModule extends AbstractGinModule { void configure() { bind(artigopresenter.display.class).to(artigodialogview.class); bind(messagespresenter.display.class).to(messagesview.class); bind(handlermanager.class).toprovider(handlermanagerprovider.class). in(singleton.class); public static class HandlerManagerProvider implements Provider<HandlerManager> { public HandlerManager get() { return new HandlerManager(null); O barramento de eventos, HandlerManager, oferece dificuldade adicional: precisa ser um Singleton, permitindo que todos os módulos tenham uma forma global, homogênea e desacoplada para se comunicarem. Todo este esforço de configuração é cansativo e muito suscetível a erros. "Entra em cena" o padrão Dependency Injection, e a biblioteca GIN GWT INjection implementação client-side da biblioteca Google Guice, para ser utilizada com o GWT. Trabalhar com GIN é semelhante a usar a API ClientBundle: clarados métodos para obter os objetos já com as suas dependências injetadas. cias (Listagem 16). se o construtor As dependências são configuradas em classes especiais chamadas módulos. Os métodos bind informam para o GIN: ao criar um objeto, caso o construtor dele tenha um argumento da interface X, injete um objeto da classe Y. É possível também pedir ao GIN para não criar os objetos, ao invés disso obtê-los em providers. Desta forma, pode-se ter controle sobre a criação do objeto. Este recurso é utilizado para criar o HandlerManager usado como barramento de eventos da aplicação. Note que também foi informado ao GIN que o barramento é um singleton, ou seja, deve criá-lo uma única vez e injetar o mesmo barramento em todos os objetos que dele dependam. Trata-se, portanto, com uma forma simples e confiável de garantir a globalidade do barramento. Por fim, não é necessário configurar os serviços no módulo. Quando uma dependência não é explicitamente configurada, o GIN tenta automaticamente criar um objeto usando chamadas GWT.create(...) neste caso, o Gin executou a chamada GWT.create(GreetingServiceAsync.class) para poder injetar o serviço no presenter. MessagesPresenter listmessagespresenter(); 56

10 Listagem 17. Dependências de ArtigoPresenter serão injetadas, via construtor, pelo // Construtor de ArtigoPresenter public ArtigoPresenter(Display display, GreetingServiceAsync service, HandlerManager bus) { this.display = display; this.service = service; this.eventbus = bus; binddisplay(); Listagem 18. Dependências de MessagesPresenter injetadas, via construtor, pelo // Construtor de MessagesPresenter public MessagesPresenter(Display display, GreetingServiceAsync service, HandlerManager bus) { this.display = display; this.service = service; this.eventbus = bus; initbus(); Compare a Listagem 14 com a Listagem 19. Quando não é usada a Injeção de Dependências, o código do EntryPoint tende a ficar cada vez mais complexo. Delegando para o GIN a responsabilidade de criar os objetos com suas respectivas dependências, a aplicação fica bem mais organizada, e menos trabalhosa de escrever/manter. Listagem 19. EntryPoint, COM Injeção de Dependências. public class Artigo implements EntryPoint { final Injector injector = GWT.create(Injector.class); public void onmoduleload() { injector.sendmessagepresenter().display.render(); injector.listmessagespresenter().display.render(); injector.eventbus().fireevent(new StartupEvent()); Conclusão Este artigo começou a ser escrito a partir da apresentação de Best Practices de Ray Ryan (Google I/O 2009), da aplicação de exemplo no Blog Hive Development e de algum entendimento sobre MVP, baseado nos conceitos apresentados no Blog Design Codes. Mesmo em posse destas fontes, materializar os conceitos teóricos em uma arquitetura prática não foi nada fácil. Até mesmo a interpretação de todo esse material, sob o prisma da teoria e dos padrões de projeto, não foi nem um pouco trivial. O grande insight ocorreu após o primeiro passo amputar, na força bruta, todo o código de View que permeava a aplicação de exemplo. A única certeza que havia era que aquele código NÃO podia estar ali. A partir daí, com mais e mais tentativas e releituras, as coisas começaram a convergir para seu devido lugar: o papel do padrão MVP na Camada de Apresentação ficou mais claro; a elegância e a flexibilidade em se trabalhar com eventos e com um barramento de notificações; o poder de usar Dependency Injection na camada de apresentação. O GWT pode ser ainda mais produtivo no cenário oposto: tendo em posse apenas os requisitos, aplicar TDD Test Driven Development para desenvolver a aplicação. Esta forma de trabalhar é bem interessante, e será abordada no próximo artigo desta série. Este artigo NÃO apresentou uma forma única de trabalhar, e possivelmente pode não ser a melhor. Pelo contrário, foi fruto de tentativas, ao longo de um árduo processo de aprendizado, no qual a única certeza era que o GWT parecia ser uma ferramenta poderosa para a criação da camada de apresentação de aplicações Web, uma forma interessante de usar todo o poder de AJAX, sem precisar lidar com Javascript. Ainda há vários caminhos para se explorar: testes unitários da camada de apresentação, criação declarativa de UIs usando UiBinder; geração de código client-side (uma espécie de instrumentação, para compensar a inexistência da API de reflection no lado cliente); experimentação das extensões do GWT (entre as quais o GXT e o Smart GWT), comparando suas APIs, seus prós e contras, modelos de licença etc.; e também um exemplo mais abrangente, simulando aplicações CRUD. Estes serão abordados em artigos futuros. Happy GWTing! Referências 57