Здравствуйте, Sinix, Вы писали:
S>Хипстеры, сэр. S>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
А аналоги XSD (для того же intellisense нужно вроде) и XSLT (хочу например html справку из XML .config файла делать) для json уже существуют? Или оно не надо?
Здравствуйте, andrey82, Вы писали:
A>А аналоги XSD (для того же intellisense нужно вроде) и XSLT (хочу например html справку из XML .config файла делать) для json уже существуют? Или оно не надо?
Тут как всегда: в студию автодополнение добавили (вплоть до имён и версий пакетов, если не забыл), проблемы остальных шерифа не колышут.
Чисто формально json-schema есть, но до xsd ей примерно как силуминовой отвёртке до мультитула. Аналогия удачная кстати, сценарии использования тоже отражает.
Здравствуйте, Sinix, Вы писали:
S>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения.
А в XML было ж всё. И комментарии эти, и трансформации, и валидация.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Вот что это за непотребство такое?
Ну имхо json это самый удобный вариант для конфигов. Категорически прост, древовиден, структуризован, типизирован и не так наворочен, как xml.
По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
Здравствуйте, Sheridan, Вы писали:
S>Ну имхо json это самый удобный вариант для конфигов.
Нет.
S>Категорически прост,
INI еще проще.
S>древовиден, структуризован,
Допустим.
S>типизирован
Wat?
S>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают
Запилы вида [{},[[{{}, [] читать еще сложнее.
И нет комментариев, Карл! Конфигурационный файл без возможности добавить в него комментарий -- это зло в чистом виде.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
S>>Если серьёзно, то большинство людей руками туда лезть будут не чаще, чем в нынешний xml. Какая разница?
Н>Как по мне, так язык разметки, в котором нет поддержки комментариев, даже не должен и рассматриваться в качестве кандидатуры на использование в конфигурационных файлах приложения.
Стандартный ответ json-фагов — можно добавить свойство "Comment"
Н>А в XML было ж всё. И комментарии эти, и трансформации, и валидация.
Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
Здравствуйте, Нахлобуч, Вы писали:
S>>Категорически прост, Н>INI еще проще.
Он не древовиден. Не типизирован.
S>>типизирован Н>Wat?
"строка", 1 — число
S>>По личному опыту: xml трудно читать, количество скобок превышает все мыслимые пределы, закрывающие теги только мешают Н>Запилы вида [{},[[{{}, [] читать еще сложнее.
Нифига. {} — хэш ключ-значение, [] — массив
Н>И нет комментариев, Карл! Конфигурационный файл без возможности добавить в него комментарий -- это зло в чистом виде.
Это зависит от того — решит ли разработчик использовать комментарии. Как минимум можно игнорировать ключи "comment".
Моя реализация читателя/писателя — умеет
Здравствуйте, Нахлобуч, Вы писали:
Н>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON?
хихи Всё ровно наоборот: со времён хэмэлеизации прошло достаточно много времени, чтобы понять: XML не стал "большим всемогутером", ибо тяжеловесен, избыточен, неудобен, да и не может "абстрактный формат" вдруг стать "всеми понимаемым". Тот же *.ini — ВСЕ программы могут без труда его прочесть, а смысл? Без семантики (и поддержки самой программой) ЛЮБОЙ формат бесполезен.
Но в чём прекрасен JSON, так это в удобстве — он читаемый, ЛЕГКО (де)сериализуемый, поддерживает все мыслимые структуры (включая циклические), ну и его современное распространение говорит само за себя! Я его юзаю практически с первых упоминаний в сети (почти лет 10) — крайне удобно, все конфиги именно в нём. Думаю, формат заслужил свою славу, обидно только, что M$ тратит столько времени на "осознание очевидного". Тот же *.sln писал какой-то имбецил с питоном головного мозга, при всём том, что даже *.csproj — XML! Неконсистентность от тех, кто учит нас жить.
Здравствуйте, Kolesiki, Вы писали:
K>Но в чём прекрасен JSON, так это в удобстве — он читаемый, ЛЕГКО (де)сериализуемый, поддерживает все мыслимые структуры (включая циклические), ну и его современное распространение говорит само за себя!
Ну так сценарии использования у них разные, чего смешивать-то?
Как показывает практика, на более-менее сложных структурах json откровенно сливает.
И по удобству редактирования, и по тулзам, и по объёму выигрыш редко превышает 20%, и отсутствие комментов/дат тоже радости не добавляет.
Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
Здравствуйте, Kolesiki, Вы писали:
K>Но в чём прекрасен JSON, так это в удобстве — он читаемый...
Мне приходилось сложные править XML'ки по 500 Kb весом, и их чтение не вызывало трудностей. Сложно себе представить такого же размера json, думаю, разобраться там будет нереально.
K> Я его юзаю практически с первых упоминаний в сети (почти лет 10) — крайне удобно, все конфиги именно в нём.
Всё зависит от размера и сложности конфигов. Шарповые проекты действительно сложными бывают, особенно когда нужна условная компиляция.
K>Тот же *.sln писал какой-то имбецил с питоном головного мозга...
О да, согласен.
K>Неконсистентность от тех, кто учит нас жить.
Кто нас только не учит жить
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Kolesiki, Вы писали: K>Здравствуйте, Нахлобуч, Вы писали: Н>>Какие такие инвалиды интеллектуального труда решили взять и заменить XML-конфигурацию на JSON? K>хихи :) Всё ровно наоборот: со времён хэмэлеизации прошло достаточно много времени, чтобы понять: XML не стал "большим всемогутером", ибо тяжеловесен, избыточен, неудобен, да и не может "абстрактный формат" вдруг стать "всеми понимаемым". Тот же *.ini — ВСЕ программы могут без труда его прочесть, а смысл? Без семантики (и поддержки самой программой) ЛЮБОЙ формат бесполезен.
Когда ругают XML, обычно не знают, заменой чему он является
Здравствуйте, sambl4, Вы писали:
S>Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
В чём проблема с DOM + XPath? Если объёмы громадные, то что JSON, что XML будут тупить одинаково — нужна DB в качестве "искабельного" кэша.
Здравствуйте, sambl4, Вы писали:
S>Но вот использовалось всё это по разному. В нашем приложении я переделывал XML сериализацию на Json, так всё стало гораздо лучше! Потому что XML был сделан вообще ужасно — он использовался только для потокового чтения и записи, но что-то найти в нём было абсолютно нереально.
Что "всё" и чем "лучше"? И как json облегчает задачу "что-то найти в нём"?
xml и json могут парситься потоково (sax), могут строиться во внутреннее представление (dom).
Ещё у xml есть XPath, к json тоже можно подобное прикрутить (даже готовые реализации есть).
XSLT — у json такого нет (ошибаюсь?), но можно на любом скриптовом языке накатать.
XSD — у json нет подобной валидации.
Также у xml есть атрибуты, что для простых структур сильно сокращает оверхед по разметке (напомню, речь шла о конфигах).
То, что xml не (так) удобен для JS-программистов, не умаляет его достоинств.
Ну а касательно легкости чтения — json всё же сложнее читать, особенно, если начать с середины — по закорючкам сложно выбраться на нужный уровень (привет, cdecl.org)!, а по открывающим и закрывающим тегам xml таки проще это сделать.
Здравствуйте, Sinix, Вы писали:
S>Как показывает практика, на более-менее сложных структурах json откровенно сливает.
Ты хотел сказать — xml.
Даже по твоим ссылкам видно: S>Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
В xml каша из тегов, в json чётко видно что к чему
Это называется мода. Был нормальный XML. Кучу инструментов для него придумали: простой декларативный DTD, мощнейшая XML Schema, какие-то Schematron-ы, XSLT и многое другое. Чуть ли не программы можно уже писать на этом XML-е. Но нет, он стал немоден, каждый уважающий себя студентик начал плеваться, как же так, в великом JavaScript-е ведь его неудобно использовать, какие-то XPath-ы надо учить, мне бы попроще чего, а давайте прямо этот жаваскрипт возьмём и запишем в файл. Лисперы тут икать начали.
Моё имхо — XML в текущий момент это шикарный инструмент. С прописанной грамотной XML Schema та же Intellij Idea позволяет писать этот XML практически как Java — на лету проверяет соответствие схеме, вываливает правильные автодополнения, ну ё-моё, чего ещё надо-то? А JSON — убожество, которое можно юзать только пока размер документа крошечный. А когда окунаешься в реальный мир и видишь там
}
}
}
]
}
}
]
}
то хочется немного старого доброго XML-я с закрывающими тегами.
