E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?[/quote]
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.[/quote]
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.[/quote]
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:
E porque não? é mais produtivo codificar linha por linha interfaces visuais no Java?[/quote]
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.[/quote]
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?[/quote]
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.[/quote]
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.[/quote]
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:
[quote=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.[/quote]
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”
[quote=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.[/quote]
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.
[quote=Marky.Vasconcelos][quote=fredferrao][quote=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.[/quote]
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.
[/quote]
[/quote]
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.
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
[quote=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”.[/quote]
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.
[quote=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.[/quote]
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.
[quote=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.[/quote]Não acho q o q o VS faça seja enconder a sujeira, senão o que a arvore de componentes do jsf e o uibinder do gwt fazem é e mesmissima coisa, gerar componentes apartir de um xml e injetar em um outro código(a pagina).
Eu uso o Netbeans, e gosto muito dele, mas o que ele faz com swing, isso sim é sujeira, e pior q nesse codigo gerado por ele vc não pode editar, pois ele não deixa, vc ve o codigo mas não pode editar.
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!
