Dentro da nossa liberdade de expressão fica claro que podemos reinventar a roda e racionalizar qq necessidade para tal. Mas o quê vcs acham desse “framework”?
Meu primeiro contato com esse framework foi a duas semanas e confesso que, ainda pelo pouco que vi, fiquei muito intrigado qto a “real” necessidade disso. E fora do mundo AJAX?
O JSON não é um framework…
É uma forma de codificar objetos JavaScript (JavaScript Object Notation).
Só de você não ficar dependente de parsers XML (que funcionam diferente em diferentes navegadores) eu já acho que compensa…
Ah, e eu não acho que seja uma reinvenção da roda.
Eu fico intrigado mesmo é com a “necessidade” de usar XML.
Arquivos .ini são bem mais concisos na hora de fazer configurações. Já eram muito bem utilizados antes do XML, thankyouverymuch.
XML já é um dos formatos menos proprícios para representar dados, overhead dele é gigante. Preciso usar uma tag para falar 1?
O problema de ter uma linguagem universal dessas, é que ela acava sendo uma das piores opções para muitos casos, até um ponto onde “XML é como a violência, se ela não resolver, use mais dela.”
[quote=Bruno Laturner]Eu fico intrigado mesmo é com a “necessidade” de usar XML.
Arquivos .ini são bem mais concisos na hora de fazer configurações. Já eram muito bem utilizados antes do XML, thankyouverymuch.
XML já é um dos formatos menos proprícios para representar dados, overhead dele é gigante. Preciso usar uma tag para falar 1?
O problema de ter uma linguagem universal dessas, é que ela acava sendo uma das piores opções para muitos casos, até um ponto onde “XML é como a violência, se ela não resolver, use mais dela.”
[/quote]
Bem, alguns detalhes que talvez você não saiba.
O XML não foi inventando com o intúito de servir como arquivo de configuração. Já lí um artigo uma vez de uma pessoa fazendo uma enorme crítica a isso, e eu concordo até certo ponto. Arquivos .ini são do Windows certo? Então isso está fora de questão, pois aplicações Web não vão usar .ini ou um padrão fechado da Microsoft. Pode-se usar um arquivo properties, que tal? Igual o hibernate já usa. O problema é que você não consegue tanta representatividade em um arquivo properties (somente um par chave-valor).
Quanto a representação de dados (o que o XML deve fazer) eu não concordo com o que você disse. Mesmo essa overhead compensa a integração entre diversos sistemas.
Ai podem falar “mas o usado para armazenar configurações tbm representa uma certa classe de dados”. Eu concordo, mas mesmo assim foge do propósito de estruturar dados que podem ser intercambiados.
Esse preconceito com XML, eu acho, que é grande devido ao fato de quase todos os frameworks em Java utilizarem XML para serem configurados e isso realmente é um saco. Eu não creio que esse padrão seja abolido…
O JSON é utilizado dentro do contexto do Javascript como uma notação para representar objetos e que fique livre dos parsers XML.
[quote=davidbuzatto]
Bem, alguns detalhes que talvez você não saiba.
O XML não foi inventando com o intúito de servir como arquivo de configuração. Já lí um artigo uma vez de uma pessoa fazendo uma enorme crítica a isso, e eu concordo até certo ponto. Arquivos .ini são do Windows certo? Então isso está fora de questão, pois aplicações Web não vão usar .ini ou um padrão fechado da Microsoft. Pode-se usar um arquivo properties, que tal? Igual o hibernate já usa.[/quote]
Exatamente, não foi inventado para tal uso, mas é usado. Esse é o problema que estou falando. E sobre .ini, proprietário? Eles são um arquivo texto de propriedades. Estava me referindo ao esquema de organização interna, o mesmo de um arquivo de properties.
ASN.1 já era um formato padronizado usado para serialização de dados uma década antes do XML, agora tem também esse JSON, YAML.
Se XML fosse usado somente como descritor de documentos, ótimo, esse é o trabalho dele, agora para também fazer integração entre deus e o mundo, basta que dois ou mais sistemas sigam o mesmo esquema de validação e interpretação. Se é XML ou não, não é o ponto, dá pra fazer com qqr coisa.
Discordo apenas do final… o padrão XML está sendo minimizado com o uso de annotations. Numa rápida comparação, acho o Hibernate 3, bem melhor de usar que o 2, justamente pela substituição do XML por anotações. Acho que esse uso em larga escala de xml deve entrar em desuso, mas concordo que o padrão não será 100% abandonado, afinal ele se encaixa perfeitamente no uso de WebServices e também como arquivos de configuração mais genéricos (como web.xml, hibernate.cfg.xml, etc…).
JSON é apenas um formato de mensagem, assim como XML, binário, Plain Text, ou qualquer outra coisa que você quiser.
Pelo fato do JSON ser o formato dos objetos JavaScript, é uma grande vantagem utiliza-lo quando você precisa fazer uma comunicação Browser <-> Servidor, pois com um simples eval você transforma a mensagem JSON recebida do servidor num objeto para trabalhar.
Outro detalhe importante é o tráfego de rede. As mensagens JSON são bem menores que as mensagens XML e você pode tirar proveito disso de acordo com sua necessidade.
Com JSON você ganha integração mais facil nativamente com Javascript, além de tornar sua aplicação mais rápida pelo formato trazer um resultado menor do que xml, e usado com frameworks adequados como o prototype e o jquery sua produtividade vai lá em cima, não é toa que alguns players como o google adotam essa tecnologia.
O XML foi inventado a partir do complicadíssimo SGML com o intuito de estruturar os dados de forma mais simples. A especificação 1.0 saiu em fevereiro de 1998. De lá até hoje centenas de livros foram escritos, milhares de aplicações usam XML de diversas modos diferentes e este tópico me impressiona como ainda se pode discutir para que serve XML.
As tecnologias evoluem. Hoje há modos mais simples de fazer algumas coisas que se faziam com XML e o JSON é uma destas tentativas. Mas é preciso ter em mente que antes de existir XML, o que se usava era muito pior do que XML. As sigla CSV e INI são bons exemplos do que havia antes.
Em todas as linguagens que conheço há meios fáceis de tratar XML mas em quase nenhuma há meios padronizados de tratar arquivos .INI ou mesmo CSV de forma simples.
Eu só fico preocupado com o fato de: se uma coisa é padrão, deve ser usado indiscriminadamente. Se é padrão, utilize onde for interessante. Web Services? Interessante. Comunicação servidor - browser? JSON é melhor, mais fácil, mais rápido. Tem muitos padrões que já mudaram e viraram anti-patterns q há poucos anos eram indicados indiscriminadamente (Entity Beans?).
A propósito, de vez em quando é bom reinventar a roda. Faz a gente abrir a mente pra coisas novas…
Abraços!
