Xml é um saco?

Muita gente prefere. O XML foi um pouco abusado. Por exemplo, o ANT usou o XML como uma espécie de linguagem de programação. Embora o XML seja bom para descrever dados, não é o ideal para definir processos. Por isso, muitos frameworks (como o Spring) e ferramentas (como o próprio ANT) estão adotando bindings não só em XML mas também em Groovy e Ruby.

Eu também acho que ficar configurando XML é um pé no saco. Pior que isso só ficar escrevendo teste unitário na mão para 500 classes… São coisas que me faz pensar se minha mãe não tinha razão quando falou que eu deveria ser médico… Sem tesão não há solução…

Por isso que nos meus projetos pessoais eu uso o Mentawai… Acho que tudo deveria ter configuração programática… Nossa vida seria um pouco mais prazerosa…

Como Vini disse acima, XML é bom para apresentação de dados e não para servir como linguagem de suporte, pois a sua tendência é ficar um código feio, entediante e demasiadamente abusivo.

Parafraseando o Urubatan: Poder configurar (com xml, anotações, etc) é bom. O Ruim é ter que configurar.

Uma coisa que o RoR abusa bastante é o Convention Over Configuration, se bem que outros frameworks java utilizam também, como o JUnit e o JBoss Seam.

peczenyj:

Parafraseando o Urubatan: Poder configurar (com xml, anotações, etc) é bom. O Ruim é ter que configurar.

Uma coisa que o RoR abusa bastante é o Convention Over Configuration, se bem que outros frameworks java utilizam também, como o JUnit e o JBoss Seam.

Mas existem algumas coisas que não dá para aplicar convention over configuration. Como você faz para IoC (qual instancia vai ser usada), auto-wiring (o que depende de que?), pool de conexões, filtros que serão aplicados, etc.

Pra essas coisas convention over configuration não vai fazer milagre e você terá que configurar usando alguma coisa, certo? Convention Over Configuration pode dar uma ajuda para definir os JSPs, mas para o resto não ajuda muito não.

Quer dizer, ajuda mas não faz milagre. Você terá sempre algo para configurar e quando isso acontecer você vai usar o que? Properties, XML, Annotations? Eu prefiro usar Java mesmo…

Que tal uma DSL Interna, como o próprio Rails faz? XML não foi feito para configuração mas Java também não.

Que tal uma DSL Interna, como o próprio Rails faz? XML não foi feito para configuração mas Java também não.

Interessante isso. Tem algum exemplo abstrato ou idéia de como seria feito isso para o Java?

Para MVC eu não sei, mas dá uma olhada no exemplo do Camel:

http://activemq.apache.org/camel/

E do JMock:

http://www.jmock.org/getting-started.html

Configurar arquivos xml o tempo todo é um chute no saco! Além do mais acho anti-produtivo.

Que tal uma DSL Interna, como o próprio Rails faz? XML não foi feito para configuração mas Java também não.

A questão é que XML não é uma linguagem de programação, mas sim uma linguagem de marcação (markup language) para documentos e/ou dados.

Como fazer um loop com XML? Como fazer um if com XML? Como fazer um método com XML?

Então temos que escolher uma linguagem de programação (ou uma DSL que nada mais é uma linguagem de programação para um domínio específico) e para tal temos muitas: Java, Perl, Ruby, Python, Groovy, BeanShell, etc.

Eu concordo que linguagens de script possuem mais a cara de configuração, por serem mais dinamicas, não exigirem compilação, etc. Por isso que eu gosto de configurar as minhas coisas com BeanShell também, que nada mais é do que o Java como uma linguagem de script…

Ter que aprender uma outra linguagem de programação para configurar, me parece overkill. Eu gosto do Mentawai pois ele me oferece também essa possibilidade, de usar diversas outras linguagens para a configuração além do bom e velho Java: http://www.mentaframework.org/configuration.jsp

Mas essa é a minha opinião pessoal, ok…

Eu acho que até entendi o que você quis dizer (que XML é ruim para fazer eeste tipod e coisa) mas dialetos XML permitem fazê-lo sem problemas. O problema não é que XML não é uma linguagem imperativa (que é o que você quis dizer como “linguagem deprogramação” -um termo muito mais abrangente) o problema é que ela não foi feita para ser escrita e lida por humanos.

Linguagens declarativas (como XML) são ótimas, mesmo quando temos linguagens imperativas. Pense em uma linguagem para fazer consultas num banco de dados que não seja declarativa e compare-a com uma deste tipo.

A parte do framework em questão eu dispenso mas o fato é que você já aprende outra linguagem. Estude sobre DSLs Internas (e seu uso no Rails como exemplo) e você vai ver que não tem que aprender linguagem nova’, pelo menos não como teria que aprender C# ou Ruby. O ponto é que você cria uma linguagem fazendo adaptações em outra. Olhe os exemplos que dei sobre DSLs em Java e vai ver que aprender uma DSL Interna traz boa parte dos benefícios de uma linguagem especializada sem pagar muito caro.

Mas realmente, se você não testa não possui muitas opções, eu já não recomendaria que um programa sem testes em java seja sequer desenvolvido quanto mais uma DSL Interna.

Legal esses artigos do seu blog! Mas você prefere que um framework desenvolva a sua própria DSL com sua sintaxe e tudo mais ou você acha melhor ele usar BeanShell mesmo, que é Java e todo mundo já está acostumado? DSL é legal sim, mas entre XML, Annotations ou properties eu fico com Java mesmo…

Concordo com você. Eu faço testes aqui pra tudo, até para os meus getters, setters, toString, etc. To partindo agora para testes funcionais com o Selenium!

ricardo_rico:

Legal esses artigos do seu blog! Mas você prefere que um framework desenvolva a sua própria DSL com sua sintaxe e tudo mais ou você acha melhor ele usar BeanShell mesmo, que é Java e todo mundo já está acostumado? DSL é legal sim, mas entre XML, Annotations ou properties eu fico com Java mesmo…

Uhm… Acho que você não entendeu o ponto sobre DSLs Internas, dá uma lidinha no link ou no Fowler que possivalmente vai ficar mais claro que você não teria que ‘aprender’ ‘outra’ ‘linguagem’ para utilizá-la. Você pode pensar de uma maneira bem simples: É Java, mas é Java adaptado para seu fim específico, a sintaxe é a mesma (tanto que compila) o que muda é o “estilo de programar”

(nota: na verdade é outra linguagem mas essa linguagem é basicamente Java com algumas características específicas do domínio, mas este tópico já é bem mais avançado)

ricardo_rico:

Concordo com você. Eu faço testes aqui pra tudo, até para os meus getters, setters, toString, etc. To partindo agora para testes funcionais com o Selenium!

Não sei se você foi irônico ou não, mas como dica: você não deveria testá-los, não diretamente. Quando se possui um teste unitário para uma classe o que você está testando é o comportamento da classe e não seus métodos individualmente.

Foi o que eu disse: Usando beanshell, temos a sintaxe do Java, os objetos do Java também, só que orientados para um fim específico que é configurar um framework. Se eu não me engano o Hibernate te permite configurar via código Java, pena que isso seja uma nota escondida na documentação e que poucas pessoas realmente a utilizem ou falem dela…

Não foi não Ricardo. Ser uma linguagem de script e ser uma DSL são coisas muito diferentes. BeanShell é uma GPL, uma linguagem de uso genérico. Uma DSL é diferente de uma GPL. Vou insistir novamente para que leia os links.

pcalcado:

ricardo_rico:

Concordo com você. Eu faço testes aqui pra tudo, até para os meus getters, setters, toString, etc. To partindo agora para testes funcionais com o Selenium!

Não sei se você foi irônico ou não, mas como dica: você não deveria testá-los, não diretamente. Quando se possui um teste unitário para uma classe o que você está testando é o comportamento da classe e não seus métodos individualmente.

Não fui irônico não, estava falando sério! Mas os testes unitários teoricamente não deveriam testar todos os métodos da classe, até os métodos private? Acho que testar demais não é o problema, o problema é testar de menos. Mas o que isso tem haver com XML!? Tenho como testar o meu xml? :lol: (Foi mal se estou fugindo do tópico em questão…) :oops:

ricardo_rico:

Não fui irônico não, estava falando sério! Mas os testes unitários teoricamente não deveriam testar todos os métodos da classe, até os métodos private? Acho que testar demais não é o problema, o problema é testar de menos.

Não foi uma crítica, foi uma sugestão.

O tópico é um pouco mais extenso mas pense na classe abaixo:

class Emprestimo{
 /* ... */
 public int getNumeroDeParcelas(){...}

 public void adicionaMaisUmaParcela(){...}

}

Eu não vou testar o método getNumeroDeParcelas() ou adicionaMaisUmaParcela() (nada me impede de fazer mas TDD não é exatamente sobre isso). O que eu quero testar é o comportamento da classe, neste caso o comportamento específico de adicionar uma parcela. QUal o meio de testar isso? Eu chamo adicionaMaisUmaParcela() e depois verifico o resultado em getNumeroDeParcelas(). Os métodos individualmente valem quase nada no teste, eles são apenas uma forma de oobtêr o comportamento desejado e verificar que este foi feito corretamente.

Entendi! Valeu! Mas isso não seria mais um teste funcional da classe em questão? Vc não está testando as funcionalidades dela? :roll: Qual seria a diferença então de teste unitário e teste funcional?