Google Incorpora Instantiations (Swing Designer, GWT Designer)

Rafael Afonso:

Java Hispano:

…

Fonte: http://www.javahispano.org/contenidos/es/google_adquiere_instantiations/

Pessoalmente espero que o Google libere uma versão open-source do Swing Designer. Assim o desenvolvimento Swing no Eclipse alavanca depois do abandono do Visual Editor.

Também torço para isso. Um bom designer de telas free é uma das coisas que mais faltam no eclipse.

Att.

Se acontecer vai ser uma das coisas mais importantes para o eclipse nos últimos tempos.

Bem… eu concordo que será muito bom para o Eclipse, entretanto nunca gostei de editores D&D.

Eu gostei da notícia. Para os desenvolvedores GWT vai ser legal. Com o lançamento do UIBinder do GWT, não iria demorar para a Google lançar um plugin RAD. Mas em vez de desenvolver um, eles compraram o melhor que existe no mercado. Mas torço que eles mantenham o suporte a GXT, SmartGWT e afins.

Editores Dungeons & Dragons?

Também torço para que o Google libere uma versão open-source do Swing Designer, pois é o que falta no eclipse

Editores Dungeons & Dragons?

Hahuahau…

Drag And Drop, não sei por que mas sempre abreviei assim.

Finalmente !

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Excelente notícia!
Tudo indica mais investimentos no GWT, o que é ótimo!
O UIBinder é uma ídeia muito boa, espero que vingue pois facilita absurdos na montagem de layout.

Então, na verdade esses frameworks que devem se adaptar ao GWT.
O Smart por exemplo tem um suporte muito porco ao UIBinder e muitas vezes aos próprios painéis GWT, obrigando você a fazer TODA a tela em smart por que alguns componentes simplesmente deixam de funcionar senão o fizer assim.
Façamos a seguinte comparação: não é o JSF que tem que ser compatível com RichFaces, mas o inverso, compreendem?

Abraços!!

Tchello:

Excelente notícia!
Então, na verdade esses frameworks que devem se adaptar ao GWT.
O Smart por exemplo tem um suporte muito porco ao UIBinder e muitas vezes aos próprios painéis GWT, obrigando você a fazer TODA a tela em smart por que alguns componentes simplesmente deixam de funcionar senão o fizer assim.
Façamos a seguinte comparação: não é o JSF que tem que ser compatível com RichFaces, mas o inverso, compreendem?

Abraços!!

Isso é obvio. Mas não estou falando das frameworks em si(nem gosto muito do SmartGWT na verdade). Estou falando do suporte que o GWT Designer já tinha a essas frameworks, que o Google poderia continuar a fornecer suporte. Nem entrei no mérito do funcionamento das frameworks e do próprio GWT. Falei do suporte do GWT Designer aos componentes do SmartGWT, GXT e do falecido GWT-EXT(que este o Google pode acabar com o suporte de vez e que descanse em paz).
Mas falando do SmartGWT, ele sofre do mesmo mal que o GWT-EXT sofria. Ele é um monte de wrappers para componentes desenvolvidos diretamente em javascript, e são feitas uma séries de gambi… ops… workarounds para que o treco funcione direito. Até daí que vem grande parte do problema de compatibilidade entre componentes do próprio GWT e os do SmartGWT.

serathiuk:

Tchello:

Excelente notícia!
Então, na verdade esses frameworks que devem se adaptar ao GWT.
O Smart por exemplo tem um suporte muito porco ao UIBinder e muitas vezes aos próprios painéis GWT, obrigando você a fazer TODA a tela em smart por que alguns componentes simplesmente deixam de funcionar senão o fizer assim.
Façamos a seguinte comparação: não é o JSF que tem que ser compatível com RichFaces, mas o inverso, compreendem?

Abraços!!

Isso é obvio. Mas não estou falando das frameworks em si(nem gosto muito do SmartGWT na verdade). Estou falando do suporte que o GWT Designer já tinha a essas frameworks, que o Google poderia continuar a fornecer suporte. Nem entrei no mérito do funcionamento das frameworks e do próprio GWT. Falei do suporte do GWT Designer aos componentes do SmartGWT, GXT e do falecido GWT-EXT(que este o Google pode acabar com o suporte de vez e que descanse em paz).
Mas falando do SmartGWT, ele sofre do mesmo mal que o GWT-EXT sofria. Ele é um monte de wrappers para componentes desenvolvidos diretamente em javascript, e são feitas uma séries de gambi… ops… workarounds para que o treco funcione direito. Até daí que vem grande parte do problema de compatibilidade entre componentes do próprio GWT e os do SmartGWT.

Sim, você tem toda a razão.
Perco os cabelos por conta das gambiarras medonhas que existem no Smart.
Uma coisa que você citou é exatamente a nossa maior reclamação aqui: o smart é um wrapper pra códigos javascript e não um framework para gwt, feito em gwt em sí.
Daí os problemas graves de compatibilidade, muitas vezes até cross-browser.

Meu sonho é poder um dia usar o GWT puro, sem precisar desses frameworks pesados e problemáticos, já que a google tem um cuidado extremo com o GWT, em desempenho, documentação, o próprio incubator é prova disso, antes de adicionar o componente no GWT ele passa um bom tempo por ai sendo amadurecido e testado pela comunidade.

Uma pena também é o GWT visualization depender de acesso a internet. Tivemos que removê-lo de um sistema aqui pois as políticas de acesso a internet do cliente impediam que usássemos o visualization =/

Enfim, o UIBinder na minha opinião vai botar pra quebrar em breve. Só acho que o auto-complete dele no Eclipse poderia ter um suporte mais extenso no xml do UIBinder.

Muito boa a discução, to gostando do rumo dela =D

Abraços.!

Tchello:

Sim, você tem toda a razão.
Perco os cabelos por conta das gambiarras medonhas que existem no Smart.
Uma coisa que você citou é exatamente a nossa maior reclamação aqui: o smart é um wrapper pra códigos javascript e não um framework para gwt, feito em gwt em sí.
Daí os problemas graves de compatibilidade, muitas vezes até cross-browser.

Meu sonho é poder um dia usar o GWT puro, sem precisar desses frameworks pesados e problemáticos, já que a google tem um cuidado extremo com o GWT, em desempenho, documentação, o próprio incubator é prova disso, antes de adicionar o componente no GWT ele passa um bom tempo por ai sendo amadurecido e testado pela comunidade.

Uma pena também é o GWT visualization depender de acesso a internet. Tivemos que removê-lo de um sistema aqui pois as políticas de acesso a internet do cliente impediam que usássemos o visualization =/

Enfim, o UIBinder na minha opinião vai botar pra quebrar em breve. Só acho que o auto-complete dele no Eclipse poderia ter um suporte mais extenso no xml do UIBinder.

Muito boa a discução, to gostando do rumo dela =D

Abraços.!

Na minha opinião o que faltava mesmo no GWT é componentes de listagem(Grids e afins) próprios. Que utilizar o FlexTable para isso é um porre. Mas me parece que o 2.1 irá ter um componente para isso.

E sobre o plugin do Eclipse, acho que com o GWT Designer que vai vir a solução dos problemas dele com o UIBinder. hehehe.

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Bem, depende da pessoa, comigo normalmente é mais rapido programar na mão mesmo. Fora que eu pelo menos tenho (ou pareço ter) mais controle sobre o que faço.

serathiuk:

Tchello:

Sim, você tem toda a razão.
Perco os cabelos por conta das gambiarras medonhas que existem no Smart.
Uma coisa que você citou é exatamente a nossa maior reclamação aqui: o smart é um wrapper pra códigos javascript e não um framework para gwt, feito em gwt em sí.
Daí os problemas graves de compatibilidade, muitas vezes até cross-browser.

Meu sonho é poder um dia usar o GWT puro, sem precisar desses frameworks pesados e problemáticos, já que a google tem um cuidado extremo com o GWT, em desempenho, documentação, o próprio incubator é prova disso, antes de adicionar o componente no GWT ele passa um bom tempo por ai sendo amadurecido e testado pela comunidade.

Uma pena também é o GWT visualization depender de acesso a internet. Tivemos que removê-lo de um sistema aqui pois as políticas de acesso a internet do cliente impediam que usássemos o visualization =/

Enfim, o UIBinder na minha opinião vai botar pra quebrar em breve. Só acho que o auto-complete dele no Eclipse poderia ter um suporte mais extenso no xml do UIBinder.

Muito boa a discução, to gostando do rumo dela =D

Abraços.!

Na minha opinião o que faltava mesmo no GWT é componentes de listagem(Grids e afins) próprios. Que utilizar o FlexTable para isso é um porre. Mas me parece que o 2.1 irá ter um componente para isso.

E sobre o plugin do Eclipse, acho que com o GWT Designer que vai vir a solução dos problemas dele com o UIBinder. hehehe.

SIIMMM!!! Uma tabela bonitinha faz muita falta!

Dei uma olhada no incubator e tem uma tabelinha lá nesses moldes, que estão amadurecendo pra adicionar no GWT em breve.
Olhei o código dela pra ver como funciona e ficou bem feito, orientado a objetos mesmo, nada parecido com o ListGrid do SmartGWT que é totalmente orientado a Strings =Z

Tem mais alguns componentes também.
Espero que eles criem mais coisas em breve, gwt tem tudo pra desbancar muita gente grande ai.

Abraços.

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Bem, depende da pessoa, comigo normalmente é mais rapido programar na mão mesmo. Fora que eu pelo menos tenho (ou pareço ter) mais controle sobre o que faço.

Antigamente se perdia mais tempo codificando telas do que o processo central do software, só o tempo que se ganha em desenhar telas visualmente já economiza um grande tempo no desenvolvimento, mesmo fazendo visual o processo é cansativo, imagina codificando? usar drag and drop não é só mais eficiente como recomendado na maioria dos casos, se existir números comprovados que codificar telas é mais rápido do que desenhá-las gostaria de ver algo comprovado.

Heh, legal saber que existem outros sofrendo porque optaram pelo SmartGWT. :lol:
“Infelizmente” o showcase do SmartGWT e bem interessante. E com a falta de opcoes gratuitas…
Espero que em um futuro o time do GWT venha a adicionar novos componentes ao framework.

Sobre “desenhar” usando um WYSIWYG editor eu sou contra, essa e minha opniao hoje, nao precisa cortar os pulsos, ok?!
E parece que isso e um topico bem polemico:
http://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their

excelente noticia Rafael!

keller:

Heh, legal saber que existem outros sofrendo porque optaram pelo SmartGWT. :lol:
“Infelizmente” o showcase do SmartGWT e bem interessante. E com a falta de opcoes gratuitas…
Espero que em um futuro o time do GWT venha a adicionar novos componentes ao framework.

É verdade.
Constantemente digo que seria bem melhor se o smartgwt não existisse, daí teríamos que implementar do zero muitos componentes que mesmo que levando tempo seria melhor do que perder horas e dias com gambiarras tremendas pra ajustar a gambiarra do smartgwt (sim, o smartgwt é uma gambiarra).

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Bem, depende da pessoa, comigo normalmente é mais rapido programar na mão mesmo. Fora que eu pelo menos tenho (ou pareço ter) mais controle sobre o que faço.

Antigamente se perdia mais tempo codificando telas do que o processo central do software, só o tempo que se ganha em desenhar telas visualmente já economiza um grande tempo no desenvolvimento, mesmo fazendo visual o processo é cansativo, imagina codificando? usar drag and drop não é só mais eficiente como recomendado na maioria dos casos, se existir números comprovados que codificar telas é mais rápido do que desenhá-las gostaria de ver algo comprovado.

No caso do Swing dependendo do tipo de tela pode ser um parto sem uma ferramenta visual… imagina desenvolver uma tela que tem mais de uma centena de componentes de todo tipo :shock:

Att.

Adelar:

… imagina desenvolver uma tela que tem mais de uma centena de componentes de todo tipo :shock:
Att.

Daí sim eu acharia mais produtivo fazer visualmente do que ficar acertando todo esse layout na unha. Mas cada caso é um caso…

Eu curto pra caramba o Swing Designer, é o plugin oficial utilizado pela Borland (atual Embarcadero) no JBuilder.

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Bem, depende da pessoa, comigo normalmente é mais rapido programar na mão mesmo. Fora que eu pelo menos tenho (ou pareço ter) mais controle sobre o que faço.

Bom, no caso do swing estou de acordo com voce, ultimamente tenho tentado usar o editor do Netbeans, mas parece que o treco teima em nao funfar do jeito que quero, quando faço na mão via codigo a coisa flui melhor, pelo menos pra mim, e não tem dessa de demorar não, depois de algumas classes abstratas e alguns painels defaults fica bem rapido fazer novas telas.

E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?

Bem, depende da pessoa, comigo normalmente é mais rapido programar na mão mesmo. Fora que eu pelo menos tenho (ou pareço ter) mais controle sobre o que faço.

Antigamente se perdia mais tempo codificando telas do que o processo central do software, só o tempo que se ganha em desenhar telas visualmente já economiza um grande tempo no desenvolvimento, mesmo fazendo visual o processo é cansativo, imagina codificando? usar drag and drop não é só mais eficiente como recomendado na maioria dos casos, se existir números comprovados que codificar telas é mais rápido do que desenhá-las gostaria de ver algo comprovado.

Vou falar especificamente de Swing.

Não existe numeros, pq COMO JA DITO pelo Marky.Vasconcelos, vai de pessoa pra pessoa, sinceramente eu não estou me adaptando bem ao editor do netbeans, e tem a questão do controle sobre tudo como dito, no Delphi, sem usar ancora ou qualquer outra coisa, era apenas um Null Layout, podemos setar no swing, mas sera um… NULL LAYOUT. Ja usando os layouts java, to achando meio chatinho usar o editor, na mão eu me saia bem melhor, mesclando varios layouts e … acreditem, usando gridbag nos labels e texts.

É coisa de conhecer os layouts e desenhar num papel, qualquer tela fica facil depois de desenhada no papel.

E como eu ja disse no ultimo post, depois que tu faz os padroes de telas e panels, o resto é so herança e composição.

Aqui usamos poucos componentes do SmartGWT, decidimos passar um tempo criando os nossos componentes.
Porem vou te contar, os poucos componentes que usamos do SmartGWT da uma dor de cabeca! :?
Acredito que a ideia do SmartGWT seria de substituir “todos” os componentes GWT por isso a interoperabilidade entre os dois e gambi/workaround.

Eu concordo com voce nesse caso, porem estamos falando de GWT/Web nao Swing, certo?
Alem disso, nao desenvolvemos o mesmo “tipo de tela” em GWT/Web usamos um “approach” diferente.

Eu já penso que é melhor utilizar o GXT(e dar um testada no Vaadin, que me parece ser bom). Ele é pago, mas funciona bem, e se levar em conta o tempo que você levará desenvolvendo estes novos componentes e dando manutenção a eles, o preço do GXT não se torna caro. Alias, acho que para projeto de médio e grande porte, ou para desenvolvedores que irão utilizar o GXT em muitos projetos, vale a pena utilizar. E ele é compatível com os componentes do GWT, e ele é 100% escrito em Java(não é baseado em wrappers para componentes JS).

Mas falando em geral de todas as bibliotecas de componentes para GWT, vejo que a idéias de todas elas é substituir os componentes nativos do GWT. Eu pelo menos evito utilizar componentes nativos do GWT, quando utilizo SmartGWT, GXT ou quando utilizava o falecido GWT-EXT.

No caso do desenvolvimento web existem muitas ferramentas para a diferentes fases do desenvolvido… no meu caso não utilizo com tanto frequencia ferramentas de design tanto quando em desktop… no caso de web acho este tipo de ferramenta util, mas por falta de costume mesmo nao uso :roll:

fredferrao:

Bom, no caso do swing estou de acordo com voce, ultimamente tenho tentado usar o editor do Netbeans, mas parece que o treco teima em nao funfar do jeito que quero, quando faço na mão via codigo a coisa flui melhor, pelo menos pra mim, e não tem dessa de demorar não, depois de algumas classes abstratas e alguns painels defaults fica bem rapido fazer novas telas.

No caso do Netbeans o principal problema é que código gerado é muito amarrado ao gerador, e por bugar às vezes o gerador acaba atrapalhando do que ajudando. :?
Utilizo o plugin da Instantiations e acho muito bom… aguardo ancioso por novas “funções google”

Att.

fredferrao:

Não existe numeros, pq COMO JA DITO pelo Marky.Vasconcelos, vai de pessoa pra pessoa, sinceramente eu não estou me adaptando bem ao editor do netbeans, e tem a questão do controle sobre tudo como dito, no Delphi, sem usar ancora ou qualquer outra coisa, era apenas um Null Layout, podemos setar no swing, mas sera um… NULL LAYOUT. Ja usando os layouts java, to achando meio chatinho usar o editor, na mão eu me saia bem melhor, mesclando varios layouts e … acreditem, usando gridbag nos labels e texts.

É coisa de conhecer os layouts e desenhar num papel, qualquer tela fica facil depois de desenhada no papel.

E como eu ja disse no ultimo post, depois que tu faz os padroes de telas e panels, o resto é so herança e composição.

Exatamente, se voce conhece os LayoutManagers voce consegue fazer algo rapidamente e o resto é só herança e composição.
E no caso do LayoutManager, uso o MigLayout misturado com os do proprio Java.

Qualquer dia eu posto um exemplo que fiz em Swing e quanto tempo demorei.

Marky.Vasconcelos:

fredferrao:

knowledgebr:

Não existe numeros, pq COMO JA DITO pelo Marky.Vasconcelos, vai de pessoa pra pessoa, sinceramente eu não estou me adaptando bem ao editor do netbeans, e tem a questão do controle sobre tudo como dito, no Delphi, sem usar ancora ou qualquer outra coisa, era apenas um Null Layout, podemos setar no swing, mas sera um… NULL LAYOUT. Ja usando os layouts java, to achando meio chatinho usar o editor, na mão eu me saia bem melhor, mesclando varios layouts e … acreditem, usando gridbag nos labels e texts.

É coisa de conhecer os layouts e desenhar num papel, qualquer tela fica facil depois de desenhada no papel.

E como eu ja disse no ultimo post, depois que tu faz os padroes de telas e panels, o resto é so herança e composição.

Exatamente, se voce conhece os LayoutManagers voce consegue fazer algo rapidamente e o resto é só herança e composição.
E no caso do LayoutManager, uso o MigLayout misturado com os do proprio Java.

Qualquer dia eu posto um exemplo que fiz em Swing e quanto tempo demorei.

Concordo que depende muito dos LayoutManagers utilizados (o que prefiro é o MigLayout)… só que mesmo com esta ajuda quando a tela está em constantes modificações a coisa pode complicar.

Att.

Acho que é seria uma boa para quem gosta, mas pessoalmente estou com o Marky, desenhar telas utilizando esses recursos drag and drop faz uma “sujeira” danada no código, e além disso nem todas oferecem bom suporte a herança visual.
Para quem já possui experiência e possui telas padrão prontas, fica mais rápido fazer “na mão”.

Fazer na mão ou visual acho que vai de cada um mesmo. heheheh Só o tempo que um analista desenha no papel pra montar seu layout, eu costumo fazer visualmente. E se precisar alterar alguma coisa, também faço manualmente. A codificação deixo apenas pras regras de negócio mesmo.

Mas conheço sim, muita gente extremamente produtiva codificando na unha, até em Delphi e VB. Cada um trabalha como preferir, mas o engraçado é ver em fórums internacionais brigas homéricas a respeito de RAD e não RAD.

O GWT precisava mesmo era de uma grid, da mesma forma que no JavaFX também não tem. Fico imaginando a dificuldade de se implementar uma coisa que é tão usada pelos aplicativos hoje em dia…

Eu prefiro evitar essas bibliotecas como GXT, SmartGWT, etc. É tentador quando você compara o conjunto de widgets delas com os widgets padrão do GWT, mas ainda assim evito.

Principalmente aquelas que são apenas um wrapper para uma biblioteca em Javascript, pois assim eu perco todas as vantagens que o compilador Java/Javascript do GWT dá.

Outro problema é elas não se dão bem com widgets padrão do GWT, o que te deixa preso nelas.

E o GXT me parece que nem é compatível com o UiBinder, então é mais um fator contra o seu uso.

Sobre o UiBinder, o GWT Designer da Instantiations não o suporta (até onde eu sei). Segundo eles, o editor é um editor visual, não editor XML. Essa desculpa não faz o menor sentido pra mim, mas fazer o que… Só espero que agora a Google implemente suporte ao UiBinder no plugin, por que senão a coisa toda ficaria um tanto quanto incoerente.

Mas de qualquer forma, nada disso serve pra mim, eu uso Netbeans

mrrbigu:

Acho que é seria uma boa para quem gosta, mas pessoalmente estou com o Marky, desenhar telas utilizando esses recursos drag and drop faz uma “sujeira” danada no código, e além disso nem todas oferecem bom suporte a herança visual.
Para quem já possui experiência e possui telas padrão prontas, fica mais rápido fazer “na mão”.

Essa sujeira que o codigo gera vem de muito tempo atras, quando esses editores foram desenvolvidos, os editores desenvolveram, mas a compatibilidade com o antigo não foi quebrado.

Tome por base flex, a tela é montada usando uma linguagem de marcação, depois na hora de compilar essa tela, geralmente em xml e transformada em codigo, e misturada com o codigo de classe. O Visual Studio da microsoft faz algo parecido, mas ele usa herança, quando ele compila o projeto, ele compila a tela que esta em xml para classe, e esta herda da classe em questao.

O netbeans por exemplo, monta a tela de designe q nos vemos em tempo de projeto em xml, e ao mesmo tempo vai inserindo codigo java na classe, isso poderia ser evitado utilizando umas das tecnicas acima, evitando o lixo de codigo excessivo.

alanweb:

Essa sujeira que o codigo gera vem de muito tempo atras, quando esses editores foram desenvolvidos, os editores desenvolveram, mas a compatibilidade com o antigo não foi quebrado.

Tome por base flex, a tela é montada usando uma linguagem de marcação, depois na hora de compilar essa tela, geralmente em xml e transformada em codigo, e misturada com o codigo de classe. O Visual Studio da microsoft faz algo parecido, mas ele usa herança, quando ele compila o projeto, ele compila a tela que esta em xml para classe, e esta herda da classe em questao.

O netbeans por exemplo, monta a tela de designe q nos vemos em tempo de projeto em xml, e ao mesmo tempo vai inserindo codigo java na classe, isso poderia ser evitado utilizando umas das tecnicas acima, evitando o lixo de codigo excessivo.

O que o VS faz é “esconder” a sugeira, não sei se é a melhor abordagem. Por um lado, você vê a coisa mais limpa, mas por outro lado, você não vê e nem tem controle do código porco gerado por trás.

Mas com as máquinas cada vez mais poderosas, um código um pouco maior é um preço pequeno pela produtividade.

marcosalex:

O que o VS faz é “esconder” a sugeira, não sei se é a melhor abordagem. Por um lado, você vê a coisa mais limpa, mas por outro lado, você não vê e nem tem controle do código porco gerado por trás.

Mas com as máquinas cada vez mais poderosas, um código um pouco maior é um preço pequeno pela produtividade.

No final acaba dando no memo, pois vc pricisa fazer:meuTextbox.setValue("Digite aqui");Não importa se vc usa VS ou Netbeans, vc pode sempre fazer isso!