Matisse++

Isso cheira a VB, mas tiraria muito trabalho de fazer bindings e comportamentos.

Vamos esperar que isso saia logo na release oficial.

Até!

tirando o fato de se criar todas as telas com um click, o esquema de databinding ficou igual do .NET hehe

mas mesmo assim ficou legal, fico feliz que o NetBeans finalmente está chegando a patamares “programáveis” que podem ser usados em produção, acho que o mesmo tem um grande futuro

E o eclipse que se cuide

Acho estranho, quando se trata de aplicações desktop, quando mais “facilidades” e recursos as IDE colocam, parece que o pessoal tende a valorizar menos ou procurar mais comparações disméritas (existe essa palavra?), parece quando usar X no linux era coisa de viado, porque maxo só pode fazer tudo no shell+vim.

Vejo todo esse tipo de “evolução” boa para todas as IDEs, pois nenhum vai querer ficar atrás dos recursos das outras, o que gera mais funcionalidades em todas IDEs.

Realmente Muito Legal, na minha opinão vai simplificar muita coisa com o NetBeans.

tks

Luiz Aguiar:

Acho estranho, quando se trata de aplicações desktop, quando mais “facilidades” e recursos as IDE colocam, parece que o pessoal tende a valorizar menos ou procurar mais comparações disméritas (existe essa palavra?), parece quando usar X no linux era coisa de viado, porque maxo só pode fazer tudo no shell+vim.

Vejo todo esse tipo de “evolução” boa para todas as IDEs, pois nenhum vai querer ficar atrás dos recursos das outras, o que gera mais funcionalidades em todas IDEs.

Esse tipo de critica me cheira inveja

Gostei bastante do que se propuseram a fazer, mas ainda não gosto da maneira na qual o Matisse trabalha, dificultando uma eventual mudança manual no código. O modelo de forms dele é um atraso ao invés de avanço, para mim.

Até!

Bom , ae eh uma opiniao pessoal mesmo… pois acredito que a forma com que ele trabalha (preservando o codigo de alteracoes) é que deixa ele rapido… veja a porcaria do VEP… que interpreta o codigo… lento que dá até pena de quem usa…

Faca uma tela complicada no Matisse e verá que ele é MUITO rapido… faca uma tela simples no VEP e vc vai chorar de raiva… até o WindowBuilder come poeira em velocidade/memoria para o matisse…

Quem usa Delphi ou VB está mais do que acostumado a mecher visualmente na tela… afinal… codigo de tela é sempre a mesma coisa… nao tem prq ficar “refatorando” milhares de vezes… isso são para apps MUITO especificas… e estas nao podem ser feitas NEM no VEP… ( eh o caso de um framework de telas dentro de um sistema por ex )

Mas para 90% das apps desktop… codigo de tela é massante e chato… trabalhar com layouts na mção então é o fim da picada…

do que?

Tudo isso é fruto da concorrência… e quanto mais houver rivalidade na parte gráfica mais ferramentas que facilitam o programador irão surgir…

Bom ou ruim? Com certeza vai depender de quem usa…

O leque de opções está aí… faça a escolha… use e seja feliz! :lol:

Mais uma vez o pessoal do Matisse inovando… Parabéns pra eles…

:idea:

Sem sombra de Dúvidas o Matisse está muito mais prático que o VEP.
Porém ainda acho o código do VEP muito mais legível.

Acho que a telas deveriam ser tratadas como Resources.
A JVM poderia muito bem ler um XML e criar a tela a partir dele, como o matisse faz. Dessa forma nós programadores ficariamos apenas com os modelos. Sem se preocupar com Layouts e tudo mais…

O que acho interessante é que os recursos apresentados aí estão presentes no Delphi desde a versão 1, pq então o delphi é tão mal visto?

do que?

Do netBeans estar transformando o desenvolvimento em algo mais simples e produtivo…

nao falei que VOCE esta com inveja…

acho que os “anti-netbeans” com comentarios deste tipo soh podem estar com inveja

Comentario quando fundamentado… adiciona… agora se só desdenhar… ae classifico normalmente de inveja…

Avante:

Sem sombra de Dúvidas o Matisse está muito mais prático que o VEP.
Porém ainda acho o código do VEP muito mais legível.

Acho que a telas deveriam ser tratadas como Resources.
A JVM poderia muito bem ler um XML e criar a tela a partir dele, como o matisse faz. Dessa forma nós programadores ficariamos apenas com os modelos. Sem se preocupar com Layouts e tudo mais…

O que acho interessante é que os recursos apresentados aí estão presentes no Delphi desde a versão 1, pq então o delphi é tão mal visto?

Bem 1º , Codigo de tela não precisa ser “super legivel e refatorado” , é um codigo de tela oras… vc mesmo disse… criar resources… é quase o que o matisse faz… vc nao deve se preocupar com o codigo que ele gera de tela… prq é besteira… ele simplesmente controla tudo isso para voce… que nem o delphi e seus .dfm… quantas pessoas vc jah viu alterando o DFM na mão constantemente ?

2º , delphi tem ALGO parecido com isso… a diferenca que o beans binding e o swing app framework conservao o modelo MVC… o delphi faz um modelo “bolognesa de codigo” tudo amarrado pronto para explodir…

Resultado ? o MESMO… manutenção ? quanta diferenca

É… o pessoal do netbeans tá pegando pesado mesmo. Bonito de ver!

Se o editor de código melhorar mesmo (e eu acredito que vai) eu passo a usar!

Imagino quanto tempo o pessoal do “tenho que setar o x,y do botão” deve demorar pra fazer um simples crud em swing.

E cá pra nós, já deu já esse argumento de não poder editar os “códigos de tela” então não presta, ta na hora de procurarem uns argumentos novos.

O matisse + GroupLayout inauguraram uma nova era em construções de interface gráficas.

A única coisa que me incomoda é que o matisse não faz tudo via o código da classe, como o WBuilder faz.

Chega ao absurdo de não reconhecer uma interface que foi feita no próprio matisse.

No matisse é assim: Crie e nunca mais modifique!

Exatamente, Acho que o código em Java pra criação de tela é totalmente dispensável. A utilização de resources poderia muito bem suprir tudo isso. Vejam bem, não me refiro a IDE´s a idéia é ter isso no Core. O Swing continuaria existindo, porém as IDE´s gerariam resources ao invés do código Java.

Humn… será mesmo? Acho que esse tipo de código está muito mais ligado ao programador do que a ferramenta/linguagem em si. E é possível SIM, ter um código muito bem feito em Delphi. Basta apenas o programador saber o que está fazendo.

[]´s

Aí você já entra na questão de conhecimento do programador. Ou você saberia me dizer como setar o ACLK do MSP430 ? Sem olhar no google.

Realmente esse argumento já deu o que tinha que dar. Aliás, eu acho que o código nem deveria existir já que as telas seriam baseadas em resources.
Programariamos apenas o modelo.

[]´s

“Todo mundo é ignorante, porém em assuntos diferentes! Só que alguns abusam.”

Nova era só se for pro Java né, porque no Delphi isso se chama pré-história.

Exatamente, Acho que o código em Java pra criação de tela é totalmente dispensável. A utilização de [B]resources[/B] poderia muito bem suprir tudo isso. Vejam bem, não me refiro a IDE´s a idéia é ter isso no Core. O Swing continuaria existindo, porém as IDE´s gerariam resources ao invés do código Java.[/quote]

MEU DEUS, UMA MENTE ABERTA NO FÓRUM!!! ALELUIA!!!

Humn… será mesmo? Acho que esse tipo de código está muito mais ligado ao programador do que a ferramenta/linguagem em si. E é possível SIM, ter um código muito bem feito em Delphi. Basta apenas o programador saber o que está fazendo.

[]´s

O “Binding” do Delphi vincula os data controls diretamente às bases de dados e não às classes de negócios, é uma idéia antiga minha fazer equivalentes dos DBControls para objetos, de repente nas versões atuais isso até já existe. Não só no Delphi mas como uma idéia geral eu acho genial, tomara que o Java Binding FUNCIONE…
[/quote]

onolox:

O matisse + GroupLayout inauguraram uma nova era em construções de interface gráficas.

A única coisa que me incomoda é que o matisse não faz tudo via o código da classe, como o WBuilder faz.

Chega ao absurdo de não reconhecer uma interface que foi feita no próprio matisse.

No matisse é assim: Crie e nunca mais modifique!

WindowBuilder é 300 vezes mais lento e come 13x mais memoria que o matisse… usamos por 6 meses aqui… simplesmente impraticavel.

Quanto a perder o .form… sim vc perdeu a tela no Matisse… MAS existe um modulo no NetBeans que faz engenharia reversa da tela e gera o .form… vide “FormGenerator”

1º Muito boa ideia… que tal vc fazer uma Implementacao de referencia… foi assim que Hibernate fez parte da JCP (JSR Enterprise JavaBeans 3).

2º Como nosso colega disse… o delphi liga diretamente a datasets… que nao sao nada mais que querys sql , nao vale isso eh codigo bolognesa… Beans Binding fazem bind em javaBeans… bem diferente de datasets (ou resultsets) Idenpendente do programador saber ou nao o que faz… usar dbcontrols é declarar seu app condenado a uma amarração sem fim… usar DbControls é coisa de APP MUITO pequeno… OU quando vc quer somente exibir os dados… tirando isso… eu usaria os controles comuns

Nova era só se for pro Java né, porque no Delphi isso se chama pré-história.

Nao sabia que o Delphi tinha gerenciador de layout. Desde qual versao isso surgiu?

]['s

Usar controles comuns é coisa de maluco, esse binding já devia existir há décadas, já que não há nada de mirabolante nisso…

Nao sei se essa resposta foi pra minha pergunta. Se foi o que fiquei curioso foi referente aos gerenciadores de layout e nao a parte de binding.

]['s

vcs estariam falando do SwingBean por exemplo?

Realmente, o WB e o giglo são muito mais lentos, mas fazem coisas que o Matisse não.

Interessane esse FormGenerator. Esse é o tipo de coisa que deveria ser melhor divulgado.

Mas o matisse se perde em certas situações, e nem é preciso perder o .form.

Pra mim só precisava aumentar a compatibilidade.

onolox:

Realmente, o WB e o giglo são muito mais lentos, mas fazem coisas que o Matisse não.

Interessane esse FormGenerator. Esse é o tipo de coisa que deveria ser melhor divulgado.

Mas o matisse se perde em certas situações, e nem é preciso perder o .form.

Pra mim só precisava aumentar a compatibilidade.

Tirando a interpretacao do codigo do form o que o WB faz que o Matisse nao faz ?

Quais situacoes que o matisse se perde ? Estamos usando em projetos bem complexos e ainda nao perdemos uma tela devido a essas “perdidas”… eu acho que vc esta confundindo com o VEP , esse sim se perde todo.

onolox:

Realmente, o WB e o giglo são muito mais lentos, mas fazem coisas que o Matisse não.

Interessane esse FormGenerator. Esse é o tipo de coisa que deveria ser melhor divulgado.

Mas o matisse se perde em certas situações, e nem é preciso perder o .form.

Pra mim só precisava aumentar a compatibilidade.

Tirando a interpretacao do codigo do form o que o WB faz que o Matisse nao faz ?

Quais situacoes que o matisse se perde ? Estamos usando em projetos bem complexos e ainda nao perdemos uma tela devido a essas “perdidas”… eu acho que vc esta confundindo com o VEP , esse sim se perde todo.

Mas o matisse se perde em certas situações, e nem é preciso perder o .form.

Pra mim só precisava aumentar a compatibilidade.

Não é só a turma do NetBeans que está fazendo bonito! O pessoal do Swing está fazendo um ótimo trabalho, em várias frentes.

Pelo que vi na apresentação, o NetBeans trabalhará de mãos dadas com Swing Apllication Framework. De acordo com o site deles:

The JSR-296 Swing Application Framework prototype implementation is a small set of Java classes that simplify building desktop applications. The prototype provides infrastructure that’s common to most desktop applications:

* Application lifecyle, notably GUI startup and shutdown.
* Support for managing and loading resources, like strings, formatted messages, images, colors, fonts, and other types common to desktop applications.
* Support for defining, managing, and binding Actions, including Actions that run asynchronously (in the "background").
* Persistent session state: support for automatically and selectively saving GUI state from one run of an application to the next.</blockquote>

O engraçado é que o Swing Application Framework rivaliza com a plataforma NetBeans.

Não vejo a hora de pôr as minhas mãos no novo NetBeans! 8)

Nao sei se essa resposta foi pra minha pergunta. Se foi o que fiquei curioso foi referente aos gerenciadores de layout e nao a parte de binding.

]['s

Não, que eu saiba não tem gerenciador de layout, mas nunca morri por causa disso, usava Anchors, além da orientação por grade…

não sou o maior fã do netbeans,
mas isso parece-me ser bem interessante…

Exato! São totalmente diferentes. Por isso não se deve usar um conceito/técnica de programação Java em Delphi e vice versa.
Volto a repetir, é totalmente possível fazer um código consiso e de fácil manutenção em Delphi, usando ou não DBControls. Basta saber fazer.

Humn… Afirmação perigosa essa hein. Dê uma lida sobre programação multi-camadas em delphi.

[]´s

Em 2007 voces discutindo sobre delphi?

Exato! São totalmente diferentes. Por isso não se deve usar um conceito/técnica de programação Java em Delphi e vice versa.
Volto a repetir, é totalmente possível fazer um código consiso e de fácil manutenção em Delphi, usando ou não DBControls. Basta saber fazer.

Humn… Afirmação perigosa essa hein. Dê uma lida sobre programação multi-camadas em delphi.

[]´s

Acho que voce que tem que olhar bem o que eh multi-camadas… camada de vizualizacao ligada diretamente a camada de persistencia ? hummm , nao tah faltando nada nao ?

Nostalgia eh uma coisa interessante… só a Borland e os Delpheiros roxos nao perceberam que o Delphi JAH foi um bom produto… apartir da versao 8… esta sempre atrazado em relacao aos concorrentes e sempre com uma qualidade muito inferior … vai pra .Net ? use VS , Delphi para .Net eh uma piada.

Nostalgia eh uma coisa interessante… só a Borland e os Delpheiros roxos nao perceberam que o Delphi JAH foi um bom produto… apartir da versao 8… esta sempre atrazado em relacao aos concorrentes e sempre com uma qualidade muito inferior … vai pra .Net ? use VS , Delphi para .Net eh uma piada.Foi percebendo isso que a Borland/Codegear está lançando até o final de março de 2007 o delphi 2007 FOR WIN32.

É se vc não colocar a camada do “meio” vai ficar faltando mesmo.

É já foi o tempo do Delphi mesmo… ainda bem hehehe. Só acho errado dizer que delphi é sinonimo de falta de flexibilidade, sistema de dificil manutenção, etc… Ou em Java(C,C#, Ruby, etc…) é impossível escrever um código espagueti ?
Se utilizar a plataforma .NET programe em C# que é uma linguagem que nasceu nessa plataforma, o resto é gambiarra. rs.
Ahh, só pra constar: uns dos criador do C# é o mesmo do Delphi.

[]´s

É já foi o tempo do Delphi mesmo… ainda bem hehehe. Só acho errado dizer que delphi é sinonimo de falta de flexibilidade, sistema de dificil manutenção, etc… Ou em Java(C,C#, Ruby, etc…) é impossível escrever um código espagueti ?
Se utilizar a plataforma .NET programe em C# que é uma linguagem que nasceu nessa plataforma, o resto é gambiarra. rs.
Ahh, só pra constar: uns dos criador do C# é o mesmo do Delphi.

[]´s

Eu fiquei decepcionado com a “flexibilidade do delphi”… essa porcaria nao tem NADA de novo… quer fazer um WebService ? vc esta com problemas… pois o suporte do Delphi 7 é arcaico… quer trocar de versao ? compre todos componentes novamente… quer criptografar alguma coisa ? Nada que existe de padrao no mercado vc consegue acesso facil com delphi

eu uso matisse já no myeclipse e acho bem legal, não gosto de swing porque além da interface ser lenta, é horrível, é feia, uma nojera

SWT ftw!!!11

[quote=Leozin]não gosto de swing porque além da interface ser lenta, é horrível, é feia, uma nojera[quote]
Olha, sinceramente, já passou o tempo em que falavam isso como argumento para não se usar swing, tente pesquisar melhor sobre aplataforma que verá que esta equivocado.

Não sei qual a moral pra se empurrar swing abaixo pro desenvolvedor. Sim, já ví interfaces bonitas feitas com swing, mas pela minha experiência com swing e swt, eu acabei ficando com swt. Sim, o Netbeans é produtivo pra fazer coisas em swing e requer menos gambiarras pra fazer funcionar, mas sei lá, gosto é gosto, experiências e dores vividas são de cada um, não é evangelismo, tanto é que nem faço questão de discutir isso com evangelista, o que eu citei anteriormente não passa de ponto de vista e, pelo contrário, uso cada um deles quando a situação lhe convêm entende?

Nada contra ninguém, mas vou seguir o seu conselho, vou pesquisar melhor sobre o assunto e ver o que já foi melhorado no swing e suas novas técnicas e componentes, lembro até que antes do java 6 sair o newsletter da sun me mostrou num e-mail uns esquemas de column sort em datatable e tal, só questão de análise (e tempo rsrs)

Mas o engraçado é que há 10 anos o Delphi tem um monte de coisas que só agora vêm aparecendo no Java, e ainda ficam falando “Wow, nossa!”. Wow, data binding, que fantástico! Conheço isso há 6 anos…

Mas o engraçado é que há 10 anos o Delphi tem um monte de coisas que só agora vêm aparecendo no Java, e ainda ficam falando “Wow, nossa!”. Wow, data binding, que fantástico! Conheço isso há 6 anos…

Sem contar que no .NET isso existe a um bom tempo

Não é atoa que o NetBeans ganhou o prêmio de IDE mais inovadora do ano. Vejam só quantas inovações ele trouxe no ano que passou, principalmente na parte de desenvolvimento de interface.

Eu prefiro muito mais o NetBeans do que o eclipse, apesar de conseguir fazer tudo que eu preciso nas duas IDEs.

Agora se alguém ai disse que não é possivel editar o código de uma interface gerado pelo NetBeans está redondamente enganado. Alguém que sabe utilizar a aba de propriedades dos componentes swing corretamente sabe do que estou falando. vc pode inserir código antes e depois da inicialização do componente. Além de outras vantagens que só quem tem experiência com o NetBeans sabe. Uma dica interessante é seguir todos os tutoriais que estão no site do NetBeans, e aguardem, em algum tempo os tutoriais estarão completamente revisados, sem aquela tradução gortesca que está hoje. Estamos trabalhando nas revisões.

Eu pessoalmente acredito que o java se tornou uma linguagem mais voltada para a web, a exemplo de jsp, servlets, jsf, e outros…

Coloquem na balança as inovações do java para web e as inovações para desktop, acho que web ganha. Mas agora talvez isso tende a se equilibrar. vamos esperar pra ver.

E olha que eu nem citei os mecanismos de persistencia como o hibernate e o Java Persistence.

Tambem não posso esquecer de EJB 3 e JAX-WS. :lol:

Leozin:

eu uso matisse já no myeclipse e acho bem legal, não gosto de swing porque além da interface ser lenta, é horrível, é feia, uma nojera

SWT ftw!!!11

Que ano que vc está ? 2000 ? 2001 ? A performance do swing melhorou MUITO e chega a ser tão rapido quanto SWT… SWT alem de algo fora do padrao é uma tentativa da IBM de empurrar algo por goela abaixo sem passar pela JCP…

Swing pode ter varias caras.;… inclusive bonitinhas como o Mac , ou feiinha como o linux…

Quer deixar acara do SWT ? coloque o Laf no Windows como CurrentPlataform…

Acho que sao necessarios mais argumentos que um “eh uma nojera”

Leozin:

Não sei qual a moral pra se empurrar swing abaixo pro desenvolvedor. Sim, já ví interfaces bonitas feitas com swing, mas pela minha experiência com swing e swt, eu acabei ficando com swt. Sim, o Netbeans é produtivo pra fazer coisas em swing e requer menos gambiarras pra fazer funcionar, mas sei lá, gosto é gosto, experiências e dores vividas são de cada um, não é evangelismo, tanto é que nem faço questão de discutir isso com evangelista, o que eu citei anteriormente não passa de ponto de vista e, pelo contrário, uso cada um deles quando a situação lhe convêm entende?

Nada contra ninguém, mas vou seguir o seu conselho, vou pesquisar melhor sobre o assunto e ver o que já foi melhorado no swing e suas novas técnicas e componentes, lembro até que antes do java 6 sair o newsletter da sun me mostrou num e-mail uns esquemas de column sort em datatable e tal, só questão de análise (e tempo rsrs)

Acho que voce nao viu nada:) Voce esta discutindo aparencia… aparencia se arruma com Laf… SWT alem de LENTO quando fora do do ambiente Windows… é fora do padrão e só vai ser encontrado em coisas que a IBM faz…

E sinceramente… de porcarias que a IBM doa para a comunidade estamos cheios…VEP, WTP… etc… etc…

Mas o engraçado é que há 10 anos o Delphi tem um monte de coisas que só agora vêm aparecendo no Java, e ainda ficam falando “Wow, nossa!”. Wow, data binding, que fantástico! Conheço isso há 6 anos…

Sim… existem a 6 anos ou mais… porem 1% dos “delpheiros” usao isso de forma que não vire um espaguete…

Já em java… isso bem mais dificil acontecer. O conceito é Outro…

Mas percebo que vc nao admite mesmo que delphi is dead

Mas o engraçado é que há 10 anos o Delphi tem um monte de coisas que só agora vêm aparecendo no Java, e ainda ficam falando “Wow, nossa!”. Wow, data binding, que fantástico! Conheço isso há 6 anos…

Sem contar que no .NET isso existe a um bom tempo :)

Eu vou ignorar a parte que vc esta botando .Net na frente de Delphi e Java em inovações… prq .NET eh nada mais que uma copia descarada.
Ninguem ali pensou… simplesmente refez o que já existia e colocou outro nome…

chun:

Eu vou ignorar a parte que vc esta botando .Net na frente de Delphi e Java em inovações… prq .NET eh nada mais que uma copia descarada.
Ninguem ali pensou… simplesmente refez o que já existia e colocou outro nome…

É impressionante o nível de conhecimento em tecnologia e inovação que você têm.

Por favor, evitem flame wars. Flame wars me deixam triste.

package god.world.utils;

import god.database.EvangelistDatabase;
import god.tools.DivineHammer;

public class DestroyEvangelist {
	public static void main(String[] args) {
		String evangelistName = args[0];
		if(EvangelistDatabase.find(evangelistName)==true) {
			DivineHammer hammer = new DivineHammer();
			hammer.obliterate(evangelistName);
			System.out.println("Evangelist destroyed successfully");
		}else {
			System.out.println("This guy is not an evangelist");
		}
	}
}

Após compilado:

>java DestroyEvangelist chun
>>Evangelist destroyed successfully

Zoeira. :lol:

Mas o engraçado é que há 10 anos o Delphi tem um monte de coisas que só agora vêm aparecendo no Java, e ainda ficam falando “Wow, nossa!”. Wow, data binding, que fantástico! Conheço isso há 6 anos…

Sim… existem a 6 anos ou mais… porem 1% dos “delpheiros” usao isso de forma que não vire um espaguete… :)

Então o seu raciocínio é que é melhor esperar 10 anos aparecer a feature x no Java do que programar direito no Delphi?

é tão fácil quanto, a diferença é que em Java as cagadas são mais chiques (e engraçadas). É só ver o tópico de códigos toscos ou o the daily WTF.

chun:

Mas percebo que vc nao admite mesmo que delphi is dead

Adminto sim, por que não? Delphi morreu porque é caro, mono-plataforma e proprietário, o que é uma pena.

juzepeleteiro:

chun:

Eu vou ignorar a parte que vc esta botando .Net na frente de Delphi e Java em inovações… prq .NET eh nada mais que uma copia descarada.
Ninguem ali pensou… simplesmente refez o que já existia e colocou outro nome…

É impressionante o nível de conhecimento em tecnologia e inovação que você têm.

Um comentario vazio deste, eu vou ignorar ok ? nao tem nada… nem opiniao… nem vizao… apenas critica sem nexo.

Nao… eu disse que nao existe nada de inovador… eu prefiro sim fazer a coisa da forma certa… Em delphi o IDE te leva a fazer essse tipo de cagada… eh vendido que usar dbedit em querys SQL é a coisa mais linda do mundo… que eh certo e deve ser feito… Em java nao existe essa venda , as coisas sao mais organizadas e isso eh indiscutivel…

Ae eh uma opiniao sua para mim cagada eh cagada em qualquer plataforma…

renato3110:

Adminto sim, por que não? Delphi morreu porque é caro, mono
-plataforma e proprietário, o que é uma pena.

Fora que a Borland eh conhecida por enfiar o pé na jaca sempre… nao eh a toa que jah foi vendida umas 4 vezes…

Mono plataforma ? Kylix ? eles ateh tentaram… mas infelizmente nao tem competencia para fazer algo deste tamanho…

Quanto caro eu concordo… pagar 1200 dolares por uma ferramenta semi-morta e menos produtiva que seus concorrentes ? Isso matou o JBuilder… 5 mil dolares para usar EJB ? eh pra rir mesmo…

Realmente estas novas features vão facilitar muito a vida de muitos desenvolvedores, principalmente os que estão vindo de Delphi (tipo eu… hehehe ) e VB.

Eu assino embaixo de tudo que o chun disse e ainda completo

DELPHI NÃO É JAVA!

Porque os desenvolvedores como nós devemos nos preocupar com interface e persistência?? Devemos focar na lógica do negócio, já que essas ferramentas tão ai por esse motivo.
:lol:

–
NetBeans a IDE mais inovadora do ano!

É se você usar DBControls ligados diretamente a camada de persistência realmente é errado.
Mas quem disse que não existe outra maneira de fazer isso?
Ligando os DBControls ao seu modelo?

Acho que o problema de usar IDE´s RAD como Delphi, Netbeans, Visual Studio etc é o fato de deixar o programador preguiçoso. Acaba fazendo as coisas sem saber o que realmente acontece. Esses dias peguei um cara programando JSF com o Visual Web Pack do netbeans e o cara nem fazia idéia do que era um Managed Bean.

Onde está o erro? na IDE ou no programador?

[]´s

Nunca vou usar uma ferramenta cujo código gerado por ela não posso alterar. Nunca.

Não confio em tecnologias que são complexas demais para serem usadas sem um editor visual. Se é necessário um punhado de wizards para conseguir trabalhar com o treco, eu passo.

Os DFMs (descrições de tela) do Delphi por exemplo, são bem simples de mexer…

LIPE:

Nunca vou usar uma ferramenta cujo código gerado por ela não posso alterar. Nunca.

Não confio em tecnologias que são complexas demais para serem usadas sem um editor visual. Se é necessário um punhado de wizards para conseguir trabalhar com o treco, eu passo.

Bom… ae nao eh questão de “ser complexo demais”… e sim questão de performance… ler um XML é MUITO mais rapido que interpretar o codigo linha a linha…

questão de opção… preferem gastar menos memoria… mas se vc quiser usar eclipse amanhã… nada impede… o codigo vai funcionar…

A questão é… Tela em 90% dos casos nao tem o que “refatorar” , é tela… usando matisse vc faz rapidinho outra… é besteira deixar de lado 500% a mais de produtividade só prq vc nao consegue alterar o codigo na munheca…

Fora que se vc usar as propriedades no painel do lado vc consegue mudar MUITA coisa… praticamente tudo… consegue inclusive adicionar codigos antes e depois de cada componente… acho que isso é mais do que suficiente…

Fora que conforme a evolucao das tecnologias o Matisse até que te ajuda… ex: se vc usar JDK 1.5 ele usa o GroupLayout com uma biblioteca externa… se vc usar JDK 1.6 ele converte para GroupLayout do proprio JDK… sem ter que ficar se acabando…

IDE é pra isso… ajudar

DFM’s sao simples me mecher por 2 motivos:

1º - 1% dos usuarios mechem nele
2º - São orientados a X:Y , ou seja… quando vc coloca um layout no meio a coisa complica bastante…

Avante:

Acho que o problema de usar IDE´s RAD como Delphi, Netbeans, Visual Studio etc é o fato de deixar o programador preguiçoso. Acaba fazendo as coisas sem saber o que realmente acontece. Esses dias peguei um cara programando JSF com o Visual Web Pack do netbeans e o cara nem fazia idéia do que era um Managed Bean.

Onde está o erro? na IDE ou no programador?
[]´s

E assim o mercado java vai ficar cheio de programadores, a IDE facilita o desenvolvimento, daqui a pouco vai ter nego fazendo CRUD completo com transações e segurança sem sequer saber o que é Hibernate

Na web é a mesma coisa, vai chegar uma hora que nego diz ser programador JSF por clicar na tabela do lado esquerdo do Netbeans (no Data Navigation), arrastar pra um table e dizer “sou programador web master fucking”

gg

DFM’s sao simples me mecher por 2 motivos:

1º - 1% dos usuarios mechem nele
2º - São orientados a X:Y , ou seja… quando vc coloca um layout no meio a coisa complica bastante…

Que linha de raciocínio esplêndida!!!

DFM’s sao simples me mecher por 2 motivos:

1º - 1% dos usuarios mechem nele
2º - São orientados a X:Y , ou seja… quando vc coloca um layout no meio a coisa complica bastante…

Que linha de raciocínio esplêndida!!!

Pena que nao posso dizer o mesmo

Pessoal,

Se é pra discutir, vamos discutir algo que seja mais produtivo… :lol:

Aos que falam mal de Delphi: teve seu tempo, foi uma excelente ferramenta (tanto a linguagem, que é totalmente orientada a objetos, quanto ao RAD). Simplesmente desmerecer algo que era bom, talvez antes de você começar a programar, é tolice…

Aos que defendem o Delphi: programei em Delphi desde a segunda versão e percebi o seu declínio desde a quinta (ou quarta) versão… não conseguiu acompanhar as mudanças (como um dia o Java também não vai conseguir…), perdeu o foco, e se f****. E um grande problema de ferramentas que facilitam muito a vida dos programadores é que a média dos desenvolvedores nestas ferramentas se tornam mediocres, são ótimos pra arrastar-e-soltar… no mundo java o cenário é bem melhor.

Programar é profissão, não religião… Ok, Delphi tá morto, mas ainda tem gente que ganha dinheiro com Cobol, Clipper… e aí?

Hoje programo 100% do meu tempo com Java e curto muito isso, todas as necessidades que tenho hoje, Java resolve de forma bem melhor que Delphi. Isso é verdade pra mim, pode não ser pra outros… e ponto.

Se é pra brigar, melhor que seja de Java e RoR

netBeans pare de ser burro, e seja mais funcional $%%¨@#!

imagina o tempo que economiza com isso…

pq ver problemas nisso??

Estranho, todo mundo usa hibernate porque é pratico, economiza tempo em não ter que ficar fazendo toda aquela parafernália via JDBC, e ninguém reclama.

Poderia ser mais claro na sua afirmação ?

Pratico = puxar 512 milhoes de plugins inuteis e mal feitos ?
Pratico = complicar coisas simples ?

Nao entendi…

Se isso virar uma guerra de IDEs, o tópico será trancado.

Deve ser por isso que programador java adora XML.

Alias, muito inteligente esse comentário.

Não sei se é um deboche, mas também acho que ler um XML embora lento ainda seja menos do que ler fontes Java

Como assim resources?
Não deveria existir código pra tela?..e assim nascerão vários programadores q não sabem nem o q é um gerenciador d layout…

Lich King:

Avante:

Realmente esse argumento já deu o que tinha que dar. Aliás, eu acho que o código nem deveria existir já que as telas seriam baseadas em resources.
Programariamos apenas o modelo.

Como assim resources?
Não deveria existir código pra tela?..e assim nascerão vários programadores q não sabem nem o q é um gerenciador d layout…

Resources nao quer dizer que nao vai existir codigo de tela… mas sim que nao vai ser CODIGO JAVA. eh uma outra forma de expressar o posicionamento de objetos em tela… Matisse jah faz isso… ele tem seu .form… porem gera codigo java para poder funcionar em qualquer IDE…

E quanto a nao saber sobre layouts… eu nao tenho uma opiniao bem formada… mas acho que para QUE ficar complicando a vida ? pra que ficar programando na mao uma coisa que PODE SIM ser automatizada e as vezes quase eliminada ? Programadores sao pagos para programar coisas mais importantes que perder 30 anos em cima de uma tela de cadastro… dificilmente telinha é o que importa em um sistema hoje em dia…

Lich King:

Avante:

Realmente esse argumento já deu o que tinha que dar. Aliás, eu acho que o código nem deveria existir já que as telas seriam baseadas em resources.
Programariamos apenas o modelo.

Como assim resources?
Não deveria existir código pra tela?..e assim nascerão vários programadores q não sabem nem o q é um gerenciador d layout…

O que é um gerenciador de layout?

Putz… acabei de desenvolver todos esses componentes de conexão com dados essa semana… hehehehe, parece piada… mas os JavaBeans dos caras parece que ficou show!!! Alguém já baixou essa versão pra testar?

[]'s

Ê tópico ruim, já passou da hora de trancar. Programador Delphi cada vez mais se parece com os Clipeiros de alguns anos atrás.

Uma aplicação Java tem que rodar em várias plataformas, e os componentes da tela (botões, labels, caixas de texto, radios, etc.) usam fontes diferentes, têm altura e largura diferentes, espaçamentos diferentes, etc. Como posicionar os componentes absolutamente, em grades, no estilo do Delphi e VB, nessa situação? Simplesmente não dá.

Para resolver esse tipo de problema é que existe o conceito de gerenciadores de layout (conceito que existe em outras plataformas, além do Java). Usando um layout manager, você dá “dicas” de como os componentes vão ser dispostos na tela e o gerenciador se encarrega de posicionar os componentes na tela, cuidando de dimensionar e espaçar os componentes de acordo com o que prega o Look&feel usado.

Funciona perfeito? Claro que não, é por isso que existem vários layouts disponíveis no Java, ao longo dos anos foram sendo criados layouts para atender às necessidades de criação de diferentes tipos de telas e à necessida de facilitar o trabalho do programador. E o suporte aos Look&feels sempre foi sofrível (a eterna discussão do “não nativo o suficiente”), com bugs, gerando inclusive Look & feels de terceiros, como o Winlaf e o Quaqua, dedicados a corrigir os pontos em que a implementação fornecida com a JRE implementa de forma incorreta os padrões esperados.

A última evolução é o GroupLayout, incluído no Java 6, que posiciona os componentes relativos uns aos outros, ao longo de eixos, que é mais intuitivo e natural para o programador, porque é muito semelhante a usar o sistema de grades do Delphi e do VB, mas mantendo o suporte a múltiplas plataformas.

Qual a diferença entre Windows e TCP/IP?

Ê tópico ruim, já passou da hora de trancar. Programador Delphi cada vez mais se parece com os Clipeiros de alguns anos atrás.

E isso é ruim?!

Alguma previsao de quando sera liberado o appFramework? (demo / release)

A menos que você esteja criando um sistema hiper-simples pra uma pequena locadora ou lojinha, data controls são um absurdo do ponto de vista da boa engenharia de software.

LIPE:

Nunca vou usar uma ferramenta cujo código gerado por ela não posso alterar. Nunca.

Não confio em tecnologias que são complexas demais para serem usadas sem um editor visual. Se é necessário um punhado de wizards para conseguir trabalhar com o treco, eu passo.

Completamente com o relator.

O beta do Netbeans 6.0 está previsto para o começo maio e o final para o meio de novembro, como pode ser visto em: http://www.netbeans.org/community/releases/roadmap.html

Até!

renato3110:

Qual a diferença entre Windows e TCP/IP?

.

Discordo. Não é porque você não sabe fazer (layout em Delphi) que não dá pra fazer. O Delphi tem compontes como o Panel (e outros), com funcionalidades similares ao GridBagLayout do Java. Tenho feito aplicações em Delphi para rodar no Linux, via Wine, onde o Look & Feel é respeitado, inclusive com qualquer fonte que o usuário escolher. Não tem a mesma precisão fina do Java, em termos de layout, mas pelo menos a aplicação não fica com cara de “alienígena” no desktop do usuário.

A maior desvantagem do Delphi é que ele “incentiva” o programador a tomar decisões ruins em termos de projeto. Usar controles data-aware, posicionar componentes usando coordenadas absolutas, alterar o Look & Feel diretamente na IDE são algumas dessas “facilidades” que acabam atrapalhando. Pode-se dizer, sem medo de errar, que a imensa maioria dos desenvolvedores Delphi são menos qualificados que a maioria dos desenvolvedores Java. As facilidades atraem os preguiçosos.

O maior problema do Delphi é a “opcionalidade” da Orientação a Objetos, menos rígida que no Java. Quase todos os recursos de OO presentes no Java estão presentes no Delphi, mas poucos os utilizam na sua plenitude. Nossa empresa desenvolveu um Framework de Persistência de Objetos, por exemplo, que é muito mais fácil de usar do que o Hibernate.

Utilizei Java por alguns anos (sou originário do C++) mas até então não havia uma ferramenta que permitisse atingir a produtividade que o Delphi dá - ainda mais quando a OO é usada em sua plenitude. O fato de não ser multi-plataforma é trivialmente resolvido com o Wine (que roda em Linux), pois as demais plataformas (não-Intel) são irrelevantes do ponto de vista das aplicações comerciais.

Existe ainda o Lazarus, que é um projeto Open-Source de uma IDE para o Free Pascal. Com o Lazarus é possível compilar o mesmo código em Windows, Linux e Mac. Mesmo que a Borland desista do Delphi, o Lazarus seguirá. Isso também ocorreu com o Clipper, através do Flagship - hoje há até o Visual xHarbour, uma IDE visual multi-plataforma (Windows, Linux e Mac). Todos gerando binários nativos em todas as plataformas.

O grande calcanhar-de-aquiles do Java sempre será a JVM.

Para empresas até é aceitável depender do wine, mas para usuários domésticos rodar uma aplicação “estrangeira” por meio de uma camada de compatibilidade é desconfortável.

No mais, concordo com o que você falou.

Enquanto a Microsoft dominar o desktop, o seu .NET e Delphi afins irão perdurar, é díficil ignorar algo que existe e está lá.