JSON vs рукописный формат для конфигов - Философия программирования

JSON (pronounced like the name "Jason" -- jā'sən),
which stands for "JavaScript Object Notation",

В три слова JSON это текстовый формат — формат объектных литералов JavaScript.

Нечто типа этого:

{
  menu: 
  {
   id   : "file",
   value: "File:",
   menuitem: 
   [
      { caption: "New",   id: 17 },
      { caption: "Open",  id: 24 },
      { caption: "Close", id: 28 }
   ]
}

Позволяет описывать данные разных типов и структур. Характеризуется
большей компактностью чем XML и легкостью парсинга.

Активно используется в AJAX

Нативно подерживается JavaScript — парсинг это просто вызов метода eval("json text")
В настоящее время известны имплементации для следущих языков:

ActionScript.
C.
C#.
Cold Fusion.
E.
Java.
JavaScript.
ML.
Objective CAML.
Perl.
PHP
Python.
Rebol.
Ruby.
Squeak.

Ссылки и нотация здесь:

Мой tiscript (dll, free) естесвенно поддерживает JSON нативно:

чтение — obj = eval( string | stream )
и запись — (String | stream).printf("%V",obj)

Вот, рекомендую.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Так же из этим JSON. Я не знаю, кто завтра будет править мои конфиги — они вот они, на виду лежат. Так что — как бы ни был плох xml (привет to McSeem2

) — но что это такое, знают ваще все.

Ну и толку в том, что его знаю все? Вот кусок vcproj файла в хмл формате:

Name="Debug|Win32"
OutputDirectory="$(SolutionDir)\$(ConfigurationName)"
IntermediateDirectory="$(SolutionDir)\$(ConfigurationName)\$(ProjectName)"
ConfigurationType="4"

Теперь внимание вопрос. Какую циферку я должен поставить чтобы изменить тип проекта со static library на DLL?
И как вообще я увижу в конфиге, что это static library? И как мне здесь поможет знание или незнание хмл? Это я к тому говорю, что знание формата для правки конфигов это последнее дело. понять формат — это дело пяти секунд, а разбиратся что значат 1, 2, 3, 4, 5 гораздо больший гемор.

Здравствуйте, DarkGray, Вы писали:

K>>Спустись с неба не землю, откуда в ж-пе изумруды?

DG>Дык, зачем на основе неправильного использования технологии, хаять всю технологию.

Дык, что делать если технологию неудобно использовать правильно. Большинство хмл файлов идут без всякой схемы. Что же теперь на каждый чих и пук схему рисовать?

Приведу другой пример. В Опера-броузере нет ГУИ-кустомизатора меню. Так я открыл ихний menu.ini файл и без всякой схемы, без всякой доки и без всяких дополнительных тулзов, простым копи-пасте за пару минут сделал то, что мне нужно.

Кстати испоьзовать ХМЛ как формат конфигов — это как раз неправильное использование технологии. Т.к. хмл все-таки язык разметки. Когда он юзается по назначению например как в DocBook — это правильно. Но когда вот так:

<?xml version="1.0"?>
<view_preferences><DockViews><Design><Ctnrs><Ctnr><Opts>0,125,1124,844,255,3,0,1,0,0,0,0,0,0</Opts>
<Ctnr><Opts>0,125,1124,844,255,2,1,1,0,0,0,0,0,0</Opts><Ctnr>...

то это bullshit

Здравствуйте, c-smile, Вы писали:

CS>C точки зрения JS

CS>[1,2,3,]

CS>Это правильная запись (как и в C++ для enum или массивов)

Ага. Значит запятую в конце — можно. Это хорошо. Но встает вопрос — а нафига она тогда вообще нужна? По жизни? Разделитель? А пробел (tab/cr/lf) — чем не разделитель? А если нужно что-то с пробелами обозначить как один токен — заключай в кавычки и всех делов. В точности, как во всех командных процессорах. Но я чувствую, что здесь я переступаю некую невидимую грань и начинаю ассоциироваться с Обероном Губанычем... Так что, не надо отвечать на это сообщение.

Вообще, к формату "внешнеторчащих" частей софта требования совсем другие, нежели к внутренностям.
Если, скажем, для создания интерфейса я запросто могу перепробовать десятки библиотек, и остановиться на той, которая мне просто симпатичнее (и так и делаю, ты знаешь); то принимая для формата конфигов/скриптов/плагинов малораспространенный формат, я всегда рискую намного больше.

Пример из жизни: вот хочу я использовать твой TIScript для скриптинга. А кто мне гарантирует, что писатели моих скриптов будут familiar с его отличиями от ECMA? (или что он совместим с существующими библиотеками скриптов?)

Так же из этим JSON. Я не знаю, кто завтра будет править мои конфиги — они вот они, на виду лежат. Так что — как бы ни был плох xml (привет to McSeem2

) — но что это такое, знают ваще все.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, c-smile, Вы писали:

CS>>На самом деле JSON — правильный формат.

MS>Не возражаю. Это чисто придирки. С точки зрения написания руками — безусловный рулез по сравнению с XML. Но с точки зрения автоматического генерирования, эта самая запятая все портит. Генератор XML гораздо проще логически, чем генератор JSON. Именно из за этой самой единственной запятой. Точнее сказать, запрограммировать-то это не проблема, но если генерировать по некому шаблону — уже не фонтан. Синтаксис шаблонов сразу сильно усложняется. Межэлементный разделитель очень плохо вписывается в такую схему, хотя бы потому, что, скажем аттрибутов — три, а запятых надо всего две.

C точки зрения JS

[1,2,3,]

Это правильная запись (как и в C++ для enum или массивов)

Здравствуйте, c-smile, Вы писали:

CS>

CS>JSON (pronounced like the name "Jason" -- jā'sən),
CS>which stands for "JavaScript Object Notation",

А в чем смысл?
Ну, то есть.
* Для человеко-ориентированного конфига (в котором должно быть как можно меньше шума — чтобы легко править руками) — .ini вроде получше будет.
* Для машино-ориентированного (идеально логичного, расширяемого, и понятного большинству людей и библиотек) — как будто .xml рулит.

Где ниша для JSON?

ЗХ>Где ниша для JSON?

Для передачи данных с сервера на клиент.

Здравствуйте, DarkGray, Вы писали:

ЗХ>>Где ниша для JSON?

DG>Для передачи данных с сервера на клиент.

В том числе.

Вообще JSON меньше шумит и для конфигов более читабелен.

Наличие встроеных и компактных контейнеров в нотации тоже
помогает здорово:

[1,2,3] — vector
{ one:1; "two":2 } — map

Например вопрос: как в XML описать массив [1,2,3] ?
(если кто возьмется написать то не забудьте про описатели типов данных:
1,2,3 в JSON это int )

Здравствуйте, c-smile, Вы писали:

CS>Вообще JSON меньше шумит и для конфигов более читабелен.

Коллега, я же сознательно не спросил "а чем он лучше?"
Я спросил: где его ниша?

Впрочем, DarkGray мне уже ответил. Таки да, когда пришедшие с сервера данные можно просто eval'ить, а не разбирать какой-нито отдельной js-функцией — это очевидное преимущество.

Здравствуйте, c-smile, Вы писали:
CS>

CS>{
CS>  menu: 
CS>  {
CS>   id   : "file",
CS>   value: "File:",
CS>   menuitem: 
CS>   [
CS>      { caption: "New",   id: 17 },
CS>      { caption: "Open",  id: 24 },
CS>      { caption: "Close", id: 28 }
CS>   ]
CS>}
CS>

CS>Позволяет описывать данные разных типов и структур. Характеризуется
CS>большей компактностью чем XML и легкостью парсинга.

Ээээ. Ламерский вопрос — а запятая между аттрибутами обязательна? И для чего она вообще?
И еще — а для чего квадратные скобки и чем они отличаются от фигурных? Массивы?

Впрочем, если эти требования связаны с синтаксисом JS с его eval, то вопросы снимаются. Но с точки зрения некого абстрактного синтаксиса — остаются.

Здравствуйте, McSeem2, Вы писали:

MS>Ээээ. Ламерский вопрос — а запятая между аттрибутами обязательна? И для чего она вообще?
MS>И еще — а для чего квадратные скобки и чем они отличаются от фигурных? Массивы?

MS>Впрочем, если эти требования связаны с синтаксисом JS с его eval...,
Связаны.

MS>...то вопросы снимаются. Но с точки зрения некого абстрактного синтаксиса — остаются.

А как "некий абстрактный синтаксис" это в общем-то никому и не надо. Фенечка — именно в том, что будучи вполне декларативным описанием данных, этот формат остается валидным js

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, c-smile, Вы писали:
CS>>

CS>>{
CS>>  menu: 
CS>>  {
CS>>   id   : "file",
CS>>   value: "File:",
CS>>   menuitem: 
CS>>   [
CS>>      { caption: "New",   id: 17 },
CS>>      { caption: "Open",  id: 24 },
CS>>      { caption: "Close", id: 28 }
CS>>   ]
CS>>}
CS>>

CS>>Позволяет описывать данные разных типов и структур. Характеризуется
CS>>большей компактностью чем XML и легкостью парсинга.

MS>Ээээ. Ламерский вопрос — а запятая между аттрибутами обязательна? И для чего она вообще?
MS>И еще — а для чего квадратные скобки и чем они отличаются от фигурных? Массивы?

MS>Впрочем, если эти требования связаны с синтаксисом JS с его eval, то вопросы снимаются. Но с точки зрения некого абстрактного синтаксиса — остаются.

Запятая это часть синтаксиса JS.

На самом деле с точки зрения конфигов запятая тоже имеет место смыслить позволяя не ограничиваться только CRLF как разделитель значений:

{
  windowPos: [ 100, 100, 200, 200 ],
  windowState: "normal";
  recentDocuments: 
  [
    "file://c:/My Documents...",  
    "file://c:/My Documents...",
    "file://c:/My Documents..."
  ]
}

На самом деле JSON — правильный формат.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, c-smile, Вы писали:

CS>>Вообще JSON меньше шумит и для конфигов более читабелен.

ЗХ>Коллега, я же сознательно не спросил "а чем он лучше?"
ЗХ>Я спросил: где его ниша?

ЗХ>Впрочем, DarkGray мне уже ответил. Таки да, когда пришедшие с сервера данные можно просто eval'ить, а не разбирать какой-нито отдельной js-функцией — это очевидное преимущество.

И для С++ парсер JSON тоже проще чем XML.

Кстати упражнение читателю:

На основе С парсера JSON сделать json-cpp package.
http://oss.metaparadigm.com/json-c/

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Здравствуйте, c-smile, Вы писали:

CS>>>Вообще JSON меньше шумит и для конфигов более читабелен.

ЗХ>>Коллега, я же сознательно не спросил "а чем он лучше?"
ЗХ>>Я спросил: где его ниша?

ЗХ>>Впрочем, DarkGray мне уже ответил. Таки да, когда пришедшие с сервера данные можно просто eval'ить, а не разбирать какой-нито отдельной js-функцией — это очевидное преимущество.

CS>И для С++ парсер JSON тоже проще чем XML.

Гхмы. Проще, я верю.
Тем не менее, конфиги — это часть программы "открытая всем ветрам". Теоретически, их могут править руками, парсить другими библиотеками, поправлять испорченные; если же брать не просто формат конфигов, а некий вообще "формат обмена данными", то все эти факторы становятся еще важнее. Где-то, кому-то, в каком-то случае сказать "да у меня там xml-ка, глянешь, там все понятно в принципе" — на сегодня проще, чем сказать "да у меня там JSON, это такой формат конфигов, типа JavaScript, почитай по ссылке, и поправь".

Поэтому я и говорю

я не спрашиваю, чем он лучше.
Я спрашиваю, где его ниша.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>* Для человеко-ориентированного конфига (в котором должно быть как можно меньше шума — чтобы легко править руками) — .ini вроде получше будет.

Не всегда. Структурирован он плохо, не для всего хорошо. От xml в глазах рябит, если руками править.
Да и выглядит привычнее

ЗХ>Где ниша для JSON?

Я на пример только глянул — как раз надо менюшки в конфиги складывать. Сразу нишу нашел

. Даже парсер при желании можно из своего же готового хлама собрать. Что бы запятые "лишние" не мешались

Здравствуйте, c-smile, Вы писали:

CS>На самом деле JSON — правильный формат.

Не возражаю. Это чисто придирки. С точки зрения написания руками — безусловный рулез по сравнению с XML. Но с точки зрения автоматического генерирования, эта самая запятая все портит. Генератор XML гораздо проще логически, чем генератор JSON. Именно из за этой самой единственной запятой. Точнее сказать, запрограммировать-то это не проблема, но если генерировать по некому шаблону — уже не фонтан. Синтаксис шаблонов сразу сильно усложняется. Межэлементный разделитель очень плохо вписывается в такую схему, хотя бы потому, что, скажем аттрибутов — три, а запятых надо всего две.

Здравствуйте, c-smile, Вы писали:

CS>Активно используется в [url=http://en.wikipedia.org/wiki/AJAX
CS>]AJAX[/url]

Вот это использованли на одноим проекте — отличная штука, использует как раз эту нотацию.
В отличие от "традиционного" AJAX c XML и т.п. — это формат кроссплатформенный, т.е. в разных браузерах будет работать одинаково.

В общем — рулез

Здравствуйте, Зверёк Харьковский, Вы писали:

[поскипано]

Ничего из вышеизложенного XML не решает, стоит
например вместо ожидаемого <lisa>
юзеру написать <liza> и привет твоему конфигу.
Т.е. все эти DTD, XMLSchema никто не отменял.

Нападки на TIScript как на нестандартное нечто отметаем.
JSON он поддерживает на 100% и точка

Здравствуйте, c-smile, Вы писали:

CS>

CS>JSON (pronounced like the name "Jason" -- jā'sən),
CS>which stands for "JavaScript Object Notation",

Рулез, сенькс. Будем юзать. Жаль только, что готовых с++ библиотек нет. Хотя если писать свою с нуля, то разделитель-запятую я бы выкинул. Ну и = мне как-то больше чем : нравится. Корневые скобки вообщем-то тоже не нужны. Но это так мысли вслух, авось руки когда нибудть и дойдут сделать.

menu = 
{
  name  = "foo"
  items =
  [
     { caption = "bar" id = 108 }
     { caption = "xyz" id = 7   }
  ]
}

menu = // .. понеслась

K>Теперь внимание вопрос. Какую циферку я должен поставить чтобы изменить тип проекта со static library на DLL?

vcproj — это плохой пример, конфиг там как раз малочитаемый, т.к. в "коде" используеются магические числа.

K>И как вообще я увижу в конфиге, что это static library?

Открываешь схему, находишь нужную строчку, и понимаешь каким словом обозначается dll, а каким static

c-smile wrote:

> И для С++ парсер JSON тоже проще чем XML.
> Кстати упражнение читателю:
> На основе С парсера JSON сделать json-cpp package.
> http://oss.metaparadigm.com/json-c/

Я чего-то не понял: а где в этом парсере поддержка комментариев? То есть
чтобы можно было прочитать JSON-файл с комментариями, программно
его измениить и записать на диск, не трогая комментарии.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0 beta

Здравствуйте, DarkGray, Вы писали:

K>>И как вообще я увижу в конфиге, что это static library?

DG>Открываешь схему, находишь нужную строчку, и понимаешь каким словом обозначается dll, а каким static

Спустись с неба не землю, откуда в ж-пе изумруды?

<?xml version="1.0" encoding="windows-1251"?>
<VisualStudioProject
    ProjectType="Visual C++"
    Version="7.10"

Как говорится "Пишите нам и помните, что Microsoft компания всегда думает о том, как вас лучше сделать."

K>Спустись с неба не землю, откуда в ж-пе изумруды?

Дык, зачем на основе неправильного использования технологии, хаять всю технологию.

ps
Когда мы рисовали свой xml-формат для внутренних нужд, мы так же нарисовали и схему.
И когда потребовалось, чтобы секретарша его редактировала, ей был поставлен XmlSpy и схема
и ответ сразил наповал — О! Здесь же все просто! Здесь такие же строчечки как в Excel-е.
и действительно, она сразу смогла редактировать эти xml-формат, не смотря на то, что он имел сложную структуру.

Вот это правильное использование стандартных технологий на практике, а то, что Вы привели...

От:	c-smile	http://terrainformatica.com
Дата:	20.09.05 21:01
Оценка:	72 (9)

	От:	Kluev
	Дата:	21.09.05 07:50
	Оценка:	2 (2) +4

	От:	Kluev
	Дата:	21.09.05 11:54
	Оценка:	+5

От:	McSeem2	http://www.antigrain.com
Дата:	21.09.05 04:03
Оценка:

	От:	Зверёк Харьковский
	Дата:	21.09.05 00:41
	Оценка:	+2

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	20.09.05 22:24
Оценка:

От:	Aquary	https://wmspanel.com/
Дата:	21.09.05 01:01
Оценка: