Opiniões sobre echo2/echo3 e GWT

[Sérgio Ferreira]

Olá pessoal,

Faço votos para que as férias tenham sido ou venham a ser boas. As
minhas foram e vão continuar óptimas.

Estive a ler umas coisas e parece-me muito parecido com o GWT mas o
echo2 em vez de gerar html e javascript estático faz tudo dinamicamente.
Desta forma não precisa das RPC(s) do GWT. O echo3 parece-me muito,
muito parecido com o GWT.

Por outro lado tem um studio, coisa que no GWT me parece que tem de ser
feito "à mão".

Alguém já trabalhou com o echo2/echo3 ?
O que acham ?

Obrigado
Sérgio

[Luis Medalhas]

Sérgio,

GWT também tem um designer o GWT Designer, que embora seja um produto comercial tem um preço competitivo.

2008/8/22 Sérgio Ferreira <ser...@moredata.pt>

--
Luís Medalhas

[Joao Nelas]

Nós (Telindus) utilizamos Echo2 nas nossas aplicações e estamos contentes. Na altura em que decidimos pelo seu uso o GWT tinha acabado de ser lançado, e na comparação que fizémos o Echo2 ganhou.

Basicamente programas tudo em Java, e o funcionamento é absolutamente transparente, não precisas de RPCs nem nada do género. Com isto quero mesmo dizer que chamas o mesmo método do teu Service que usarias num servlet, ou qq coisa assim. Se perceberes de Swing é muito simples aprender Echo2, o modelo é o mesmo.

Dito isto, o caso de uso ideal serão as aplicações empresariais, ou seja, que não tenham milhares de utilizadores concorrentes. Porque, para manter esse funcionamento tipo aplicação local, o Echo2 guarda uma grande parte do estado da aplicação no servidor, o que pode levantar problemas de uso excessivo de memória. Nós ainda não tivemos problemas, mas fica o aviso.

De qualquer forma o Echo3 supostamente virá resolver este problema, com uma utilização mais tipo GWT, em que o estado é guardado no cliente.

Por outro lado tem o problema de ser uma camada de abstracção, o que te esconde algumas das realidades da plataforma, e torna algumas acções mais difíceis. Por exemplo, se quiseres mudar o css de um componente, ou se quiseres adicionar um javascript qualquer.

E essencialmente tem muito menos mind-share, uma comunidade mais pequena, etc.

Espero que sirva de ajuda,
João Nelas

2008/8/22 Sérgio Ferreira <ser...@moredata.pt>

[Fernando Fernandez]

Sérgio Ferreira wrote:
> (...

> Estive a ler umas coisas e parece-me muito parecido com o GWT mas o
> echo2 em vez de gerar html e javascript estático faz tudo dinamicamente.
> Desta forma não precisa das RPC(s) do GWT. O echo3 parece-me muito,
> muito parecido com o GWT.
>
> Por outro lado tem um studio, coisa que no GWT me parece que tem de ser
> feito "à mão".
>
> Alguém já trabalhou com o echo2/echo3 ?
> O que acham ?
>

E o ZK?

http://www.zkoss.org/Steps/discover.dsp

--
Fernando Fernandez
http://www.linkedin.com/in/fernandez

[Sérgio Ferreira]

Agora é que me estragaste tudo. Andava eu tão contente com o GWT e já
tenho que ver mais uma :-P

Já alguém experimentou o ZK ?

Fernando Fernandez escreveu:

[Luis Medalhas]

Atenção ao licenciamento do Zk! É GPL para projectos GPL e uma versão comercial para projectos comerciais.

2008/9/18 Fernando Fernandez <ferna...@gmail.com>

--
Luís Medalhas

[Pedro Viegas]

Oi,

GPL por GPL, parece-me melhor a ExtJS...

http://extjs.com/

Polémicas de mudança de licenciamento à parte, parece-me que continua a ser a lib de JS open-source de referência.

E, voltando ao tema original que falava do GWT... eles tem uma implementação de ExtJS por GWT...

http://extjs.com/products/gxt/

Se o licenciamento não for um problema, eu diria... go for it... I did! :-)

Abraço,

2008/9/18 Luis Medalhas <luis.m...@gmail.com>

--
Pedro Viegas

DiF - Making the difference in application development...
http://development.digitalis.pt/apache2-default/dif2/index.html

[Luis Medalhas]

O GWT-Ext(não confundir com o Ext-Gwt) manteve a licença LGPL.

2008/9/18 Pedro Viegas <pvi...@gmail.com>

--
Luís Medalhas

[Pedro Viegas]

Oi,

Bem lembrado, mas levanto a atenção para um pormenor.

O Ext-GWT é a implementação de Ext em GWT feita pela equipa da ExtJS. Como produto deles eles tem a mesma licença que o Ext-JS, e está mapeado para a mais recente versão deles, a Ext-JS 2.1

O GWT-Ext, é uma implementação que não foi feita pela Ext-JS, logo continua com a licença GPL que escolheu. MAS usa a Ext-JS 2.0 que é a última que saiu com licença GPL (sim, os matreiros mudaram de licença agora que já tem a malta agarrada ao produto).

Isto não poderá continuar eternamente dado que terão que evoluir para a versão mais recente algum dia, digo eu (tipo, sai o IE8, com mais um monte de incompatibilidades que eles corrigirão no Ext.2.1 e não no 2.0).

Quando o fizerem dado que usam algo que passa a LGPL, a sua licença passará obrigatoriamente também a ser abrangida pela licença mais restritiva, ou seja, passará a GWT-Ext a ser também LGPL.

Para escolhas a médio prazo é bom ter isto em consideração.

[Ruben Badaró]

Acho que estás a trocar o GPL com o LGPL aí :P

Pelo que me lembro o ExtJS deixou de ser LGPL para ser GPL, esta sim mais restrictiva que a versão lesser.


Ruben Badaró

LinkedIn: http://www.linkedin.com/in/rbadaro
Blog: http://www.zonaj.org

[Fernando Fernandez]

Que linda discussão.

Isto só prova como é muito mais fácil trabalhar sempre em open-source e
só vender serviços. :-)

Infelizmente nem sempre pode ser assim. Para já. :-)

F.

Pedro Viegas wrote:
> Oi,
>
> Bem lembrado, mas levanto a atenção para um pormenor.
>
> O Ext-GWT é a implementação de Ext em GWT feita pela equipa da ExtJS.
> Como produto deles eles tem a mesma licença que o Ext-JS, e está
> mapeado para a mais recente versão deles, a Ext-JS 2.1
>
> O GWT-Ext, é uma implementação que não foi feita pela Ext-JS, logo
> continua com a licença GPL que escolheu. MAS usa a Ext-JS 2.0 que é a
> última que saiu com licença GPL (sim, os matreiros mudaram de licença
> agora que já tem a malta agarrada ao produto).
> Isto não poderá continuar eternamente dado que terão que evoluir para
> a versão mais recente algum dia, digo eu (tipo, sai o IE8, com mais um
> monte de incompatibilidades que eles corrigirão no Ext.2.1 e não no 2.0).
> Quando o fizerem dado que usam algo que passa a LGPL, a sua licença
> passará obrigatoriamente também a ser abrangida pela licença mais
> restritiva, ou seja, passará a GWT-Ext a ser também LGPL.
>
> Para escolhas a médio prazo é bom ter isto em consideração.
>
> Abraço,
>
>
> 2008/9/18 Luis Medalhas <luis.m...@gmail.com

> <mailto:luis.m...@gmail.com>>

>
> O GWT-Ext(não confundir com o Ext-Gwt) manteve a licença LGPL.
>

> 2008/9/18 Pedro Viegas <pvi...@gmail.com <mailto:pvi...@gmail.com>>

>
> Oi,
>
> GPL por GPL, parece-me melhor a ExtJS...
> http://extjs.com/
>
> Polémicas de mudança de licenciamento à parte, parece-me que
> continua a ser a lib de JS open-source de referência.
>
> E, voltando ao tema original que falava do GWT... eles tem uma
> implementação de ExtJS por GWT...
> http://extjs.com/products/gxt/
>
> Se o licenciamento não for um problema, eu diria... go for
> it... I did! :-)
>
> Abraço,
>
>
>
> 2008/9/18 Luis Medalhas <luis.m...@gmail.com

> <mailto:luis.m...@gmail.com>>

>
> Atenção ao licenciamento do Zk! É GPL para projectos GPL e
> uma versão comercial para projectos comerciais.
>
> 2008/9/18 Fernando Fernandez <ferna...@gmail.com

> <mailto:ferna...@gmail.com>>

[Pedro Viegas]

I stand corrected! ;-)

Esta cena das licenças deixa-me sempre todo trocado. :-S

Portanto leiam o post anterior com o mesmo objectivo, mas trocando o GPL e LGPL. :-)

2008/9/18 Ruben Badaró <ruben....@gmail.com>

[PJG]

Boas,

Eu já fiz umas quantas coisas algo puxadas em Javascript e umas brincadeiras em GWT, e deixem-me dizer que a produtividade não tem nada a ver.

Em javascript desenvolvi algumas soluções Ajax. A mais fácil de explicar é o browser de videos do Spot (http://spot.sapo.pt), para quem tiver a pachorra de abrir uma conta.

Resumindo, programei o suficiente com javascript para me sentir bastante confortável com o mesmo ao ponto de - quer acreditem quer não - ter começado a achar que podia ser mais simples fazer uma aplicação web utilizando para o interface javascript + Ajax (via JSON) do que com Struts, JSF, Stripes, etc.(*)

(*) É que, mesmo em javascript directo, o modelo de programação Ajax é muito mais simples do que as "tradicionais" Frameworks Java MVC para Web, logo a começar pela gestão de estado.

Claro que utilizava algumas livrarias para não ter de aprender a conhecer 3 ou 4 browsers como se namorasse com eles (o que eu acharia de uma promiscuidade muito violenta), principalmente com o Prototype e o YUI do Yahoo!, mas também com os templates TrimPath e algum Scriptaculous.

Referências:

http://www.prototypejs.org/

http://script.aculo.us/

http://developer.yahoo.com/yui/

http://code.google.com/p/trimpath/wiki/JavaScriptTemplates

Repito: já sentia um enorme à vontade com o Javascript.

Mas quando peguei no GWT!!!!!!......

Para começar, não existem para javascript as funcionalidades de IDE que existem para Java. Eu ainda tentei o Aptana (plataforma Eclipse) e mais um par deles, mas nem chega perto.

Ora pega-se no GWT no Eclipse e temos um Code Completion muito mais sofisticado, todos os refactorings, todos os auxiliares de geração de código, navegação plena sem ambiguidades, Javadoc ao alcance de um par de teclas, etc. 

Há dúvida sobre uma rotina: F3 e estamos no source da mesma, segue-se um caminho de execução, volta-se atrás etc. Dúvida sobre a hierarquia de uma classe: pede-se o painel de navegação da mesma. Dúvidas sobre a utilização de um método: pede-se a lista de chamadas ao mesmo.

Tudo fácil!

E o compilador valida continuamente se não estamos a enganar-nos, e o debugger que funciona MESMO e não me crasha o browser a toda a hora, etc.

Para não falar na facilidade de reutilizar o mesmo código no lado do cliente e no lado do servidor. (Sim... como, por exemplo, certas validações....)

O ZK é javascript puro. Além do ZK e do Ext-JS existem outras frameworks javascript muito interessantes, como o SmartClient:

http://www.smartclient.com/index.jsp#_Welcome

Mas está-se a tornar TÃO evidente que trabalhar em Java é mais eficiente (pelo menos para quem sabe Java) que duas destas frameworks estão a construir versões GWT de si mesmas:

- O Ext Js com a anexação do MyGwt

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

- O SmartClient através da contratação do Sanjiv Jivan para os ajudar construir um wrapper GWT para o mesmo:

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

Também tentei a obra anterior do Sanjiv, o gwt-ext:

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

Os problemas de adaptação de componentes eram imensos e era mais complicado misturar os componentes do gwt-ext com outros componentes GWT do que com o GXT.

É que o GXT (nome que prefiro, para evitar confusões, a Ext GWT)

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

...é uma cópia em Java, seguindo tanto quanto possível o modelo GWT, do Ext-JS e NÃO um wrapper.

A extensão e adaptação do GXT é muito mais simples e toda a sua integração com outros componentes GWT também. Além disso, a sua evolução tem sido espectacularmente rápida, o que é outra indicação do poder Java/GWT.

O Echo2 já sofre de outro problema: o Java fica todo no servidor. Por exemplo: os eventos do GUI são tratados no servidor. Estão a imaginar o que isto significa em termos de chamadas ao servidor (e respectivo trabalho de manutenção de estado) para uma aplicação com um UI muito sofisticado?

Em GWT o UI só fala com o servidor se precisar mesmo de alguma informação/acção do mesmo. A lógica do UI pode trabalhar indefinidamente em interacções bastante sofisticadas sem dizer nada ao servidor.

E, pelo que li, para as evidentes limitações (ou elevado custo, se preferirem) de escalabilidade do Echo, desconfio que será bem mais complicado criar novos comportamentos de UI em Echo do que em GWT...

Para terem uma noção do potencial de extensibilidade do GWT, apenas alguns exemplos:

http://code.google.com/p/gwt-diagrams/

http://code.google.com/p/gchartjava/

http://code.google.com/p/gwt-canvas/

http://stud-in.fh-swf.de/Oliver.Zoran/gwt-canvas/

http://extjs.com/products/gxt/

http://extjs.com/explorer/#overview

Have fun,

PJG

[PJG]

O GWT NÃO foi feito pela equipe do Ext-JS.

Foi mais assim: o Ext-JS anexou o GWT.

http://www.ongwt.com/post/2008/04/22/MyGWT-is-dead-Long-live-Ext-GWT

Dizem as más línguas que a proposta de anexação terá sido realizada pela apresentação de duas alternativas opostas, estilo: ou vens trabalhar para nós ou processamos-te.

Have fun,

PJG

[Pedro Viegas]

E agora só para levantar confusão... e se o browser do cliente não tiver JS ou for um IE6?

Ou se a pessoa que está a aceder à aplicação for invisual ou tiver outro problema de acessibilidade?

Naturalmente que uma livraria como o ExtJS, ZK, Prototype, Y!, Dojo, etc, nunca teriam grande solução para isto...sem JS não vivem, e em termos de acessibilidade, quem já olhou para HTML que é gerado por estas libs... bom... ver o resultado no ecran é uma coisa... olhar para o HTML, ou ver o resultado de u parse daquilo para invisuais... never mind.

Mas soluções como o GWT não são soluções de JS. O JS é apenas uma ferramenta para a implementação de... um formulário com validação de dados por exemplo. Portanto, que soluções existem para isto.

E não, uma solução não será reimplementa uma versão acessível do mesmo serviço... porque isso é o mesmo e dizer... nunca vais ter a versão acessível ou terás lá 10% dos serviços se tanto.

O que é que a malta diz sobre isto?

Ou ninguem ate hoje se teve que preocupr com acessibilidade?

Se alguem já criou um site governamental durante este ano... certamente que sabe que o mesmo tem que passar o teste de acessibilidade. E tentem passar com codigo gerado por estas libs...

2008/9/19 PJG <paulo....@gmail.com>

[Samuel Santos]

Viva Pedro,

A solução aos teu problemas vem a caminho :)

A resposta às tuas preces vem sobre o nome de WAI-ARIA.

Dá uma vista de olhos nos seguintes links:

http://newgoogleblogs.blogspot.com/2008/09/built-in-accessibility-in-gwt-15.html

http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideAccessibility

http://code.google.com/p/google-web-toolkit/wiki/ARIAImplementationDetails

Dito isto, eu como purista dos standards web e tendo usado já várias vezes GWT tenho de admitir que agora só o uso quando tenho de resolver problemas em projectos que o usaram e estão pela hora da morte graças a essa escolha.

O código HTML gerado por ele é realmente horrível, usando tabelas para tudo e dificultando muito o trabalho de design da aplicação e estrutura do CSS. Sim porque o GWT apenas gere o HTML e JavaScript, se quisermos ter o CSS num ficheiro centralizado faz-se como noutra aplicação qualquer.

Outra desvantagem do GWT para quem não quer comprar uma licença do GXT (que diga-se é o melhor conjunto de componentes disponível para GWT) é a falta de componentes de qualidade usados diariamente (datepicker são maus, listas paginas e ordenáveis também não são grande coisa,...).

Outra vantagem de não usar uma ferramenta deste tipo (GWT) é a searchability de um site. Claro que um site feito em GWT dificilmente aparecerá num motor de busca por este não conseguir fazer crawling do conteúdo.

Outra vantagem de usar as libs JavaScript "tradicionais", pub para o jQuery ;), é que podemos usá-las de forma "não intrusiva" e fazendo com que a aplicação funcione com/sem ele (degrades gracefully).

A desculpa que ouço frequentemente para o uso do GWT é que é difícil encontrar recursos bons em JavaScript. Pois vos digo que isto é o pior problema dos projectos que tenho visto. Os problemas acontecem exactamente porque as pessoas não sabem JavaScript, não percebem como as coisas funcionam no UA (User Agent, browser no nosso caso) e nem sequer os eventos sabem tratar como deve de ser.

De certeza que o GWT tem mais problemas e podia-se falar muito mais sobre estas tools mas acho que por agora chega :)

Cumps,

--
Samuel Santos
http://www.samaxes.com/

2008/9/19 Pedro Viegas <pvi...@gmail.com>

[Pedro Viegas]

Oi Samuel,

Excelente feedback. Muito obrigado!

Não conhecia esta nova especificação, mas vou lê-la com muita atenção rapidamente.

A razão pela qual fiz a pergunta que fiz, é porque não só é uma preocupação que tenho dado que fazemos na empresa onde estou sites/aplicações web para instituições públicas do estado, universidades, e como tal é um tópico quente, mas também porque estamos a desenvolver uma framework de desenvolvimento Java (open-source) onde este é uma das grandes bandeiras "da coisa". RIA mas com acessibilidade.

Nós dado que acreditamos que pelo menos para já não é possível compatibilizar alguns interfaces para RIA com questões de acessbilidade. Ex: Como mostrar uma Live Edit Grid num Reader para invisuais... coitado! Devido a estas situações criamos algo que são os View Modes e uma enorme (pelo menos virá a ser enorme, para já só é grande :-D) biblioteca de componentes que TODOS suportam TODOS estes View Modes.

Portanto teremos uma implementação de um componente todo automatizado que gera uma Grid Editável no interface RIA, mas gera uma normal tabela com links para edição em formulários que tentam mimimicar ao máximo possível o interface RIA, mas sem JavaScript, e com o código a validar a 100% as normas de XHTML/CSS de acessibilidade e sem perca de funcionalidades. Portanto, como disses-te "gracefull degradation".

Até ler estes posts não tinha visto grande trabalho/preocupação de quem cria estas libs nem de quem as usa para estas questões. São sempre marginalizadas para 2º plano. Fico muito satisfeito com o que vi. Certamente podemos esperar também que mesmo as libs de JS como o tão falado ExtJS, ou o Dojo ou Yahoo, venham a cumprir esta nova norma, tal como as libs mais acima de componentes Java (tal como no link que mandas a Google, as usual, lá toma a dianteira).

Já agora, se alguém tiver curiosidade sobre o trabalho que disse estar a fazer, a tal framework Java, pode ver aqui...

Framework: http://development.digitalis.pt/apache2-default/staging/dif2/index.html

View Modes (não há documentação sobre isto ainda, mas a lista está aqui):

http://development.digitalis.pt/apache2-default/staging/dif2/dif-userguide/webdev/tags.html

Livraria de componentes: http://development.digitalis.pt/apache2-default/staging/dif2/dif-presentation/tag_reference.html

Nota: Não tenham demasiada expectativa porque ainda é Beta1 com várias features por implementar (como o suporte AJAX que já está feito e está a ser injectado nos componentes, e não "comitado" no site ainda). Daqui por uns meses anunciarei aqui para tentar evangelizar apoiantes/simpatizantes para a nossa causa! ;-) But not yet...

Abraço,

2008/9/19 Samuel Santos <sam...@gmail.com>

[PJG]

Boas,

Desculpem-me mas devido ao avançado da hora e ao "setup" que estava a utilizar (a escrever no portátil por partilha de ecran mas a ver os URLs no browser do desktop) coloquei uma série de URLs errados no email em anexo.

*** Corrigindo: ***

O ZK é javascript puro. Além do ZK e do Ext-JS existem outras frameworks javascript muito interessantes, como o SmartClient:

http://www.smartclient.com/index.jsp#_Welcome

Mas está-se a tornar TÃO evidente que trabalhar em Java é mais eficiente (pelo menos para quem sabe Java) que duas destas frameworks estão a construir versões GWT de si mesmas:

- O Ext Js com a anexação do MyGwt

http://www.ongwt.com/post/2008/04/22/MyGWT-is-dead-Long-live-Ext-GWT

- O SmartClient através da contratação do Sanjiv Jivan para os ajudar construir um wrapper GWT para o mesmo:

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

Também tentei a obra anterior do Sanjiv, o gwt-ext:

http://code.google.com/p/gwt-ext/

Os problemas de adaptação de componentes eram imensos e era mais complicado misturar os componentes do gwt-ext com outros componentes GWT do que com o GXT.

É que o GXT (nome que prefiro, para evitar confusões, a Ext GWT)

http://extjs.com/products/gxt/

...é uma cópia em Java, seguindo tanto quanto possível o modelo GWT, do Ext-JS e NÃO um wrapper.

*** Fim da correcção ***

Have fun,

PJG

Begin forwarded message:

[PJG]

Olá Samuel,

A mim está-me a parecer que uma boa parte dos problemas que apontas ao GWT são problemas de quem o usa e de algumas das livrarias do mesmo.

Para colocar as coisas em perspectiva, esta é uma página interessante:

http://www.ryandoherty.net/2008/03/28/google-web-toolkit-follow-up/

Para que a perspectiva seja equilibrada, não deixem de ler os comentários do Ray Cromwell  na página acima! 

Quanto a progressive enhancement, há que não esquecer que GWT não é só o widget kit. O GWT PODE ser utilizado em cenários de Progressive Enhancement, como se pode ver em:

http://code.google.com/p/gwtquery/

(Do acima mencionado Ray Cromwell)

Quanto ao HTML produzido, nada te impede de colocar os Widgets GWT sobre um template HTML produzido por um bom webdesigner, e o GWT até te ajuda. Vê o Javadoc do método:

com.google.gwt.user.client.ui.HTMLPanel.addAndReplaceElement()

em:

http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/HTMLPanel.html#addAndReplaceElement(com.google.gwt.user.client.ui.Widget,%20java.lang.String)

Utilizando alguns componentes do GWT incubator:

http://code.google.com/p/google-web-toolkit-incubator/

... como base é fácil optimizar a utilização de múltiplos templates numa página, estilo:

public interface MyPageTemplateResources

extends ImmutableResourceBundle {

@Resource("my/resource/package/login.html")

TextResource getLoginHtml();

@Resource("my/resource/package/menu.html")

TextResource getMenuHtml();

}

E há mais trabalho a ser realizado neste sentido no incubator. Veja-se: 

http://code.google.com/docreader/#p=google-web-toolkit-incubator&s=google-web-toolkit-incubator&t=DeclarativeUi

Os componentes de qualidade, naturalmente, aparecerão com o tempo. O GWT ainda é muito jovem quando comparado com Prototype, JQuery ou YUI.

Note-se entretanto que, com a tenra idade que o GWT tem, nenhuma das frameworks javascript acima referidas dispunha de tantas soluções de terceiros como o GWT (como os que já mencionei nesta thread).

Resumindo, o GWT dá-te todas as escolhas com melhor qualidade que com a maioria das soluções alternativas:

- Tens "progressive enhancement" via GQuery ou através das rotinas de manipulação do DOM

http://code.google.com/p/gwtquery/

- Tens, como referistes, acessibilidade;

- Podes utilizar o desenho/HTML que quiseres e até tirar partido dos Widgets GWT via templates, como com o HTMLPanel:

http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/HTMLPanel.htm

ou com o XTemplate do GXT:

http://extjs.com/deploy/gxtdocs/com/extjs/gxt/ui/client/core/XTemplate.html

e nada te impede de criar outras alternativas com o mesmo tipo de mecanismos.

- Podes integrar com as tuas livrarias e widgets Javascript favoritos via JSNI

http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.JavaScriptNativeInterface.html

...como fazem, por exemplo, em:

http://code.google.com/p/gwt-ext/

- Tens diversas frameworks alternativas de UI bastante completas à escolha:

http://extjs.com/products/gxt/

http://code.google.com/p/gwt-ext/

e em breve:

http://www.smartclient.com/

http://www.jroller.com/sjivan/entry/smartgwt_gwt_api_s_for

- Tens diversas livrarias menores mas com uma enorme diversidade de soluções:

http://code.google.com/p/gwt-diagrams/

http://code.google.com/p/gchartjava/

http://code.google.com/p/gwt-canvas/

http://stud-in.fh-swf.de/Oliver.Zoran/gwt-canvas/

...e muitos outros:

http://code.google.com/hosting/search?q=GWT&btn=Search+Projects

* Ganhas:

- Páginas compactas / performance, sendo o javascript produzido pelo GWT compacto e altamente optimizado:

http://code.google.com/support/bin/answer.py?answer=59657&topic=10211

- As vantagens em produtividade da combo JAVA + IDE moderno.

Have fun,

PJG

[Samuel Santos]

Viva PJG,

Conheço bem a maior parte das libs que referes, inclusive já cedi algum código ao GWT incubator.

Eu percebo que gostes de GWT, mas eu já na altura do Swing não gostava desta forma de implementar. Penso que são mais gostos do que grandes vantagens technológicas.

Em relação as vantagens que referes, não as vejo como tal.

Ao nível do IDE como uso frequentemente o IDEA tenho um autocomplete tão bom em Java como em JavaScript. Para Eclipse tens também o plugin Spket IDE que não é nada mau.

Em relação à performance todos os testes que fiz mostram o contrário. Uma página feita inteiramente em HTML é muito mais rápida do que em GWT, com GWT todos os elementos HTML são criados via DOM trazendo uma grande carga adicional.

Também não acho "elegante" ter de usar HTMLPanel e JSNI para ter no final um código mais limpo. Ou o GWT gere por defeito código decente ou então joga-se com as limitações do que é gerado.

As grandes vantagens que vejo no GWT são o deferred binding e as CSS images sprites. Não é nada que não se fassa sem GWT mas traz um overhead significativo, em GWT é transparente.

Curioso é o GWT-Ext não fazer uso disto e enviar o JS todo para o cliente, isto é muito mau; o GXT já não sofre deste problema.

--
Samuel Santos
http://www.samaxes.com/

2008/9/19 PJG <paulo....@gmail.com>

[PJG]

Olá Samuel,

Resposta inline:

On 2008-09-19, at 14:38, Samuel Santos wrote:

Viva PJG,

Conheço bem a maior parte das libs que referes, inclusive já cedi algum código ao GWT incubator.

Eu percebo que gostes de GWT, mas eu já na altura do Swing não gostava desta forma de implementar. Penso que são mais gostos do que grandes vantagens technológicas.

Bom, eu também preferia que o layout fosse construído de forma mais declarativa / iterativa.

O melhor modelo de construção de GUIs que já utilizei não foi certamente o Swing mas sim o do Delphi.

Em relação as vantagens que referes, não as vejo como tal.

Ao nível do IDE como uso frequentemente o IDEA tenho um autocomplete tão bom em Java como em JavaScript. Para Eclipse tens também o plugin Spket IDE que não é nada mau.

Mas eu não estava a falar apenas do Autocomplete (nesse aspecto o Aptana até me dava alguma coisa). Noutra mensagem desta thread já referi que há muitas outras vantagens da combo IDE-Java (refactoring, detecção de erros, navegação, context sensitive javadocs...).

Em relação à performance todos os testes que fiz mostram o contrário. Uma página feita inteiramente em HTML é muito mais rápida do que em GWT, com GWT todos os elementos HTML são criados via DOM trazendo uma grande carga adicional.

Não necessariamente, como é o caso do HTMLPanel.

Também não acho "elegante" ter de usar HTMLPanel e JSNI para ter no final um código mais limpo. Ou o GWT gere por defeito código decente ou então joga-se com as limitações do que é gerado.

Não sei porquê.

Por partes:

1) O HTMLPanel não é um mecanismo de excepção. É simplesmente um dos modelos de utilização do GWT;

2) O problema não é do GWT como um todo mas sim da respectiva Widget Library que, estamos de acordo, ainda deixa muito a desejar;

3) Mas podes substituir ou modificar os Widgets do GWT, nomeadamente os paineis e listas, que parecem ser a origem da maior parte da porcaria.

Claro que o GWT é (bastante) melhorável, mas é mesmo melhorável. E creio que as bases são boas.

As grandes vantagens que vejo no GWT são o deferred binding e as CSS images sprites. Não é nada que não se fassa sem GWT mas traz um overhead significativo, em GWT é transparente.

Curioso é o GWT-Ext não fazer uso disto e enviar o JS todo para o cliente, isto é muito mau; o GXT já não sofre deste problema.

Não é curioso, é até bastante natural, já que:

- O GWT-Ext é um wrapper GWT em torno do Ext-JS e utiliza apenas os mecanismos de geração de código do Ext-JS;

- O GXT "imita" o Ext-JS mas é implementado a la GWT (embora ainda utilize um pequeno core de Javascript que parece proveniente do Ext-JS.

Na verdade, a experiência de utilização destes dois pode ter semelhanças mas ainda são animais muito diferentes.

Cumps.,

PJG

[Ricardo Cardoso / Gmr]

Nas "brincadeiras" que fiz recentemente com GWT, fiquei um bocado
desiludido com um aspecto. Já repararam no monte de ficheiros que são
gerados após a primeira execução? De histórico e muitos mais... Sempre
que procurava mudar alguma coisa no código fonte, era "obrigado" a
utilizar o Ant para criar um novo ficheiro WAR, o que não é nada
prático para testar uma aplicação em desenvolvimento.
Qual a vossa opinião relativamente a isso? Há forma de evitar este
trabalho adicional?

[António Mota]

14 RIA Frameworks 14

http://commadot.com/ria-frameworks/



2008/9/20 Ricardo Cardoso / Gmr <rcc...@gmail.com>:

--
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile PT: +351919623568 (deprecated)
mobile IE: +353(0)877718363
mail: ams...@gmail.com
skype: amsmota
msn: antoni...@hotmail.com
linkedin: www.linkedin.com/in/amsmota

[PJG]

E repara que ele não conta com o GWT e suas variantes!

O GXT / Ext GWT, por exemplo, embora baseado no Ext JS tem uma base de
código diferente.

Cumps.,
PJG