jump to navigation

GWT, você entendeu? Server-side code…. Novembro 30, 2006

Posted by felipecruz in GWT, Web.
trackback

Primeiro, como sempre, começo reclamando de alguma coisa; nesse caso é a página inicial do GWT. O que eu espero de uma página inicial de uma ferramenta é uma descrição básica:

1. O que minha ferramenta faz?

2. Como ela funciona?

 

Nada muito extenso, afinal é uma página inicial, mas na do GWT, não tem “Como ele funciona”. Depois de umas buscas no google e uns clicks(3 clicks exatamente), eu descobri como funciona e depois disso eu realmente entendi como o GWT funciona. A documentação é boa e simples, só faltou na pagina inicial uma informação que é essencial. Não é a toa que *muita* gente se enganou a respeito do GWT.

Como eu levantei as 2 informações que eu acho essenciais pra o site de uma ferramenta, eu mesmo vou responder.

1. O que o GWT faz?

É um framework que ajuda na criação de aplicações AJAX, através de um compilador que transforma código JAVA em Javascript. Você não deve se preocupar com tipo do browser, escrever javascript por exemplo. Apesar disso, em um ambiente de desenvolvimento, o código roda na Jvm, ou seja, é possível debugar o código com seu Debugger preferido. Outras features você encontra aqui: http://code.google.com/webtoolkit/overview.html

Não vou continuar muito por aqui, porque documentação é o que não falta e eu não pesquisei muito essa parte do framework. Mas da pra fazer bastante coisa como por exemplo criar um componente a partir da composição de outros.

A parte que confunde a maioria das pessoas

2. Como funciona?

Quando você escreve uma classe como as que estão nos exemplos do GWT, o código java dessa classe é compilado e vira Javascript.

Como usar então classes que não são suportadas pelo compilador(Hibernate, EJB etc..)?

Você tem que criar as classes chamadas serviços. Precisei de 3 clicks pra chegar na documentação de serviços, que devia estar lá no “Getting Started”. A arquitetura do GWT divide sua aplicação em 2 partes. Client-Side Code e Server-Side Code. O client code é o carro chefe do framework, mas você não faz nada pro mundo real sem usar o Server-Side Code, que vou chamar de SSC.

O SSC, é compilado em .class e roda no servidor. Aqui não existe absolutamente nada de cliente(no máximo um callback para chamadas assíncronas), nem javascript. Nas classes SSC, você esta livre pra usar o que você quiser, pois nessa parte da aplicação é tudo 100% Java, então provavelmente aqui você vai usar o hibernate, o EJB ou até mesmo POJOs. Como o foco do post era mais chamar a atenção para uma deficiência na documentação inicial do GWT, vou continuar explicando um pouco mais essa parte que esta distante 3 clicks de você mas é fundamental.

Como criar um Serviço?

Primeiro cria-se uma interface Client-Side que herda de RemoteService.

public interface MyService extends RemoteService {
public String myMethod(String s);
}

A interface síncrona é a versão definitiva da especificação do serviço. Qualquer implementação desse serviço no lado do servidor deve herdar de RemoteServiceServlet e implementar a interface do serviço

public class MyServiceImpl extends RemoteServiceServlet implements MyService {
public String myMethod(String s) {
return s;
}
}

Você pode ter implementações assíncronas, onde a alem da interface que herda de RemoteService, você tem uma interface correspondende para chamadas assíncronas. O sufixxo Async é *obrigatório* e para cada método na interface síncrona você deve fazer um correspondente seguindo a regra abaixo:

De:

public ReturnType methodName(ParamType1 param1, ParamType2 param2);

Para:

public void methodName(ParamType1 param1, ParamType2 param2, AsyncCallback callback);

Mais informações sobre o CallBack aqui: AsyncCallback

Agora que você já sabe criar um serviço síncrono e assíncrono, você só precisa saber como se comunicar com eles do Client-Side Code.

Para isso basta(se o serviço for síncrono):

MeuServico service = (MeuServico) GWT.create(MeuServico.class);

Se o serviço for assíncrono, veja como fazer em: Actually Making a Call . Adianto que não é muito diferente e a grosso modo, você só precisa informar ao endpoint (seu serviço) aonde esta o entryPoint (que é aonde está o código do callback).

Existem outros detalhes que você deve ler aqui Remote Procedure Calls mas nada muito extenso, como eu disse são mais detalhes.

Do aspecto de arquitetura, o pessoal do GWT exemplifica os serviços de 2 modos:

  • Como o Back-End completo da sua aplicação, ou seja, aonde está a lógica de negocio, as chamadas a outros frameworks etc..
  • Como “gateways” leves que irão ser intermediários entre o cliente e outros recursos como um cluster de servidores JEE

Esse foi o primeiro post mais técnico de vários que ainda estarão por aqui. Espero que seja útil. Duvidas, críticas e comentários, escrevam aqui ou me mandem um email felipecruz AT gmail DOT com.

Comentários»

1. vdiniz - Dezembro 1, 2006

Gostaria de falar sobre dois problemas (ao meu ver)…

Primeiro, as pessoas querem fazer antes de ter o básico para saberem o que estão fazendo. O GWT virou a palavra do momento e vejo pessoas usando sem entenderem o real propósito da ferramenta.

Segundo, um erro que eu também cometi quando usei a ferramenta pela primeira vez. Colocar toda a inteligência da aplicação (lógica de negócio) na interface. Uma prática muito tentadora usando o GWT, pois tudo é Java e você acaba entrando no embalo e esquecendo que, como o Felipe falou, essa parte Client-Side vira JavaScript.

O que acontece com isso? Perda de escalabilidade. Se você quiser integrar sua aplicação com um ambiente desktop, mobile, etc etc você terá que reescrever toda a lógica de negócio e pior, se tiver que alterá-la, vai ter que repetir a alteração para todos os ambientes, pois o GWT não se aplica a outro ambiente sem ser Web.

Uma boa prática que eu pensei (estou fazendo uma “lib” para isso, quando tiver pronta disponibilizo aqui mesmo para os que gostarem :) foi em “forçar” o GWT só desempenhar o papel de interface (onde esse é o seu papel). Para isso, qualquer evento na página, deve gerar um pedido ao servidor, encapsulando os dados pertinentes a requisição. O GWT dá suporte a passagem de Objetos nas chamadas assíncronas, e acho que objetos devem ser criados para representar uma chamada ao servidor. Esses objetos podem ser levadas para qualquer ambiente e dessa forma, padronizar as chamadas ao servidor independente do cliente.

Bom, é isso! Espero ter ajudado.

Abs

2. loscar - Dezembro 1, 2006

mto pertinente!!

3. GWT (Parte 1) - Visão Geral « loogica - Janeiro 4, 2007

[...] 1.      Tudo que você codifica em java na parte cliente, vira javascript (Ver o tópico http://loogica.wordpress.com/2006/11/30/gwt-voce-entendeu/) [...]

4. Douglas Dembogurski - Janeiro 16, 2007

Hola Pessoal eu fis un programa de ajedrez en GWT mais não sei como se inicializa u ServerImpl não sei como se configura no tomcat porque não tenho exoeriencia con servlets e esas coisas agradecería me escrevão ao email quein saber un poco disto me vai ser de muinta ajuda

Eu não tenho problema no entendimento do GWT so a parte do Tomcat

Muinto obrigado

Douglas

Encarnación Paraguay

5. joao - Maio 22, 2009

Como fazer a aplicação gwt rodar em ie7 ou firefox?