Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 110
json нечитабелен.
навороченные xml также не читабельны для человека, при выборе формата передачи данных стоит отталкиваться от того что это за данные и как они должны обрабатываться на сервере/клиенте.
XML тоже не для человека придуман.
Это язык для автоматизации обмена данными между машинами.
Это язык для автоматизации обмена данными между машинами.
зависит от привычки и форматирования. я уже привык читать json и мне он кажется проще, чем xml
Не читабелен для человека? или программы?
Как в общем и человеку, сидящему в браузере на любимом сайте!
Нечитабелен? Достаточно его правильно отформатировать, и его читабельность ничем не будет уступать XML. Для разных целей служат разные инструменты. Для передачи объектов — JSON.
чем же его правильно отформатировать?
для передачи данных — xml.
для передачи данных — xml.
{
method: 'mykewlmethod'
params: {
param1: [1,2,3,4,5,6,7,8,10],
param2: 2,
param3: 'param3'
},
async: true,
callback: mykewlfunc
}
vs
[?xml version=«1.0»?]
mykewlmethod
param1
1
2
3
…
10
param2
2
param3
param3
true
mykewlfunc
В этом случае, JSON, имхо, гораздо читабельней.
method: 'mykewlmethod'
params: {
param1: [1,2,3,4,5,6,7,8,10],
param2: 2,
param3: 'param3'
},
async: true,
callback: mykewlfunc
}
vs
[?xml version=«1.0»?]
mykewlmethod
param1
1
2
3
…
10
param2
2
param3
param3
true
mykewlfunc
В этом случае, JSON, имхо, гораздо читабельней.
ох, парсер-парсер…
{
method: 'mykewlmethod'
params: {
param1: [1,2,3,4,5,6,7,8,10],
param2: 2,
param3: 'param3'
},
async: true,
callback: mykewlfunc
}
vs
[?xml version=«1.0»?]
[methodcall]
[method]mykewlmethod[/method]
[params]
[param]
[name]param1[/name]
[value]
[array]
[data]1[/data]
...
[/data]
[/array]
[/value]
[/param]
[param]
[name]param2[/name]
[value]2[/value]
[/param]
[param]
[name]param3[/name]
[value]param3[/value]
[/param]
[/params]
[async]true[/async]
[callback]mykewlfunc[/callback]
[/methodcall]
img-fotki.yandex.ru/get/3313/sairi-na-tenshi.11/0_1f3d3_90308849_orig
Я думаю говорить о точных цифрах на сколько процентов выгоднее использовать JSON нельзя.
допустим можно было написать в XML ваш пример так:
И это уже 76 байт.
А чем пользоваться тут зависит от ситуации, например я своих проектах использую для генерации страниц комбинацию: XML + XSLT. А для обработки AJAX запросов форм → JSON.
допустим можно было написать в XML ваш пример так:
<x a="hello" b="hello" d="planet"><c><longstring>oops</longstring></c></x>
И это уже 76 байт.
А чем пользоваться тут зависит от ситуации, например я своих проектах использую для генерации страниц комбинацию: XML + XSLT. А для обработки AJAX запросов форм → JSON.
Ваш пример не верный, так как a,b,c находятся на одном уровне, а d,longstring являются дочерними по отношению к c
Да я ошибся, но вот так вроде бы верно:
Так даже 74 байта.
А почему бы не использовать атрибуты в XML, если уж нужна такая экономия.
<x a="hello" b="100"><c d="planet"><longstring>oops</longstring></c></x>
Так даже 74 байта.
А почему бы не использовать атрибуты в XML, если уж нужна такая экономия.
Опять не верно! Прочитайте структуру моего примера внимательнее.
Использовать атрибуты можно, но что будет если d узел будет иметь сложную вложенную иерархическую структуру, тогда он никак не уживется в XML документе как атрибут :(
Использовать атрибуты можно, но что будет если d узел будет иметь сложную вложенную иерархическую структуру, тогда он никак не уживется в XML документе как атрибут :(
Ну это Вы такой пример привели, а не я. И опираясь на свой пример — сделали вывод.
Ненужно конечно холиваров, достаточно только знать и применять там где это целесообразно.
Ненужно конечно холиваров, достаточно только знать и применять там где это целесообразно.
тогда вместо аттрибута будет элемент. какие проблемы?
а то и вообще
[x a=«hello» b=«hello» d=«planet»][c longstring=«oops»/][/x]
— 60 байт =)
[x a=«hello» b=«hello» d=«planet»][c longstring=«oops»/][/x]
— 60 байт =)
>в JSON мы экономим 24 байта трафика,
Офигетительная экономия. М.б. попробовать перейти на KOI-7?
>И для русского языка лучше в JSON использовать utf8
И для украинского тоже, а так же для иврита, китайского и суахили. Причем не только в json.
Офигетительная экономия. М.б. попробовать перейти на KOI-7?
>И для русского языка лучше в JSON использовать utf8
И для украинского тоже, а так же для иврита, китайского и суахили. Причем не только в json.
Да, 24 байта — это очень мало для экономии, но я привел процент экономии JSON по отношению XML, поэтому при гипотетическим соображениям на 1 млн. запросов мы экономим порядка 22.9 МБ трафика
Это экономия на спичках. Можно придумать свой собственный формат, передавать все в виде обычного массива — не хэша, вернуться к семибитной кодировке, но получится такой геморрой, что вся экономия выйдет боком. Вопрос только в удобстве, кто к чему привык, кто владелец данных, кто получатель. Т.е. выбор формата — не вопрос экономии на байтах. Во всяком случае для AJax сегодняшнего дня.
в JSON мы экономим 24 байта трафика,
Офигетительная экономия. М.б. попробовать перейти на KOI-7?
А попробуйте посмотреть на это как «экономия на 20%»?
С этой точки зрения выгоднее передавать бинарные данные и их преобразовывать во что-то более удобоваримое. Например XML для дальнейшей обработки XSLT но это такая задница, что лучше плюнуть на такую экономию и выбрать json, XML, HTML в зависимости от того, с чем дальше предполагаете работать.
Кстати. вы .NET интересуетесь, судя по профилю. Вот уж кто о трафике не заботится так это MS. Такая избыточно-чудовищная задница в их js-коде, что становится страшно. Любую страницу можно вдвое-втрое ужать. Но зато сложные приложения разрабатываются влет.
Кстати. вы .NET интересуетесь, судя по профилю. Вот уж кто о трафике не заботится так это MS. Такая избыточно-чудовищная задница в их js-коде, что становится страшно. Любую страницу можно вдвое-втрое ужать. Но зато сложные приложения разрабатываются влет.
О, это вообще больная тема. Пользоваться стандартными контролами лично мне оказалось настолько неудобно и код генерировался настолько чудовищный, что после первых трёх-четырёх попыток я оставил идею использования этих контролов в работе.
И вся универсальность стандартных MS контролов почему-то так и норовит приобрести приставку «псевдо».
Может быть за некоторые годы MS исправил ситуацию, но что-то не тянет тратить время на эксперименты :(
И вся универсальность стандартных MS контролов почему-то так и норовит приобрести приставку «псевдо».
Может быть за некоторые годы MS исправил ситуацию, но что-то не тянет тратить время на эксперименты :(
Экономия на трафике — это в большинстве случаев экономия на спичках. Ключевое преимущество JSON заключается в первой букве его названия:) Это просто гибкий и, что самое главное, родной способ описания всего и вся для JavaScript.
Кстати, если нужно сильно экономить траффик, то стоит посмотреть в сторону Action Messaging Format (AMF), правда, насколько я знаю, client-side его только во флэше реализован.
1. Мне кажется тут экономить надо скорее на времени обработки. Что быстрее будет обработано на стороне клиента, JS-eval или XML парсинг?
2. И второй вопрос… какой вариант более чреват ошибками? Например, возвращение пустого значения:
JSON:
то же в XML:
Первый код, как вы легко можете заметить, вызовет ошибку при обработке, второй же будет «проглочен» легко и непринуждённо. Значит, во избежание проблем, генерируемый для JSON код должен проверяться на пустые значения и как-то приводиться к «безопасному». То бишь — некоторые дополнительные телодвижения нужны.
JSON:
{
a: 12,
b:
}
то же в XML:
<a>12</a><b></b>
Первый код, как вы легко можете заметить, вызовет ошибку при обработке, второй же будет «проглочен» легко и непринуждённо. Значит, во избежание проблем, генерируемый для JSON код должен проверяться на пустые значения и как-то приводиться к «безопасному». То бишь — некоторые дополнительные телодвижения нужны.
Вариант в JSON, конечно же вызовет ошибку преобразования, поэтому не стоит отправлять клиенту заведомо ложные или ошибочные данные.
Говоря о телодвижениях, то Ваш пример может выглядеть по сравнению с XML таким:
{
a: 12,
b: ''
}
Говоря о телодвижениях, то Ваш пример может выглядеть по сравнению с XML таким:
{
a: 12,
b: ''
}
Да, понятно, что можно защититься. И телодвижения не слишком для этого сложные потребуются, но! — всё же потребуются. И обязательное приведение к строке.
И ещё немаловажная проблема — если попытаться получить такой JSON через jQuery, к примеру, ошибку отловить становится крайне сложно: функция обработки результата (success) вообще не будет вызвана.
PS: Конечно любому понятно, что отдавая данные, надо озаботиться тем, чтобы их можно было принять. И для этого что-то приходится проэскейпить, что-то проверить на пустоту, однако тут всё же есть некоторая более высокая вероятность ошибки :) Трудновылавливаемой.
И ещё немаловажная проблема — если попытаться получить такой JSON через jQuery, к примеру, ошибку отловить становится крайне сложно: функция обработки результата (success) вообще не будет вызвана.
PS: Конечно любому понятно, что отдавая данные, надо озаботиться тем, чтобы их можно было принять. И для этого что-то приходится проэскейпить, что-то проверить на пустоту, однако тут всё же есть некоторая более высокая вероятность ошибки :) Трудновылавливаемой.
> Да, понятно, что можно защититься.
Это не «можно защитится», а неверный пример. Если вы каким-то образом сгенерировали [b][/b], то вы таким же образом сгененируете b: ''. Генерация XML от генерации JSON на стороне сервера, имхо, ничем особо не отличается.
Это не «можно защитится», а неверный пример. Если вы каким-то образом сгенерировали [b][/b], то вы таким же образом сгененируете b: ''. Генерация XML от генерации JSON на стороне сервера, имхо, ничем особо не отличается.
Да ладно? :)
Имя атрибута — непусто :) А значение — запросто.
Хотя первое утверждение тоже не стопроцентно :(
Имя атрибута — непусто :) А значение — запросто.
Хотя первое утверждение тоже не стопроцентно :(
> Да ладно? :)
Стопудов (ц)
> Имя атрибута — непусто :) А значение — запросто.
Ну вы же как-то генерите имя атрибута, и как-то генерите его значение. Причем валидно. Что мешает сделать то же самое для JSON?
Стопудов (ц)
> Имя атрибута — непусто :) А значение — запросто.
Ну вы же как-то генерите имя атрибута, и как-то генерите его значение. Причем валидно. Что мешает сделать то же самое для JSON?
Для XML пустое значение атрибута — приемлемо. Для JSON — нет. Валидное значение для разных случаев уже разное.
Пустое и для JSON-а приемлемо, вопрос в том как оно оформлено. Что-то мне подсказывает, что в XML будет не примелемо такое:
[element attribute1= attribute2=«a»]
[element attribute1= attribute2=«a»]
1. В XML каждый атрибут априори обрамляется кавычками/апострофами?
2. Если использовать не атрибуты, а элементы, то будет всё валидно.
2. Если использовать не атрибуты, а элементы, то будет всё валидно.
> 1. В XML каждый атрибут априори обрамляется кавычками/апострофами?
Это вопрос?
> 2. Если использовать не атрибуты, а элементы, то будет всё валидно.
И что это меняет? Вы так и эдак всё равно будете генерить валидный XML. Так почему же вы допускаете генерацию невалидного JSON, но не допускаете генерацию невалидного XML?
Это вопрос?
> 2. Если использовать не атрибуты, а элементы, то будет всё валидно.
И что это меняет? Вы так и эдак всё равно будете генерить валидный XML. Так почему же вы допускаете генерацию невалидного JSON, но не допускаете генерацию невалидного XML?
Это риторический вопрос.
Я в любом случае не допускаю генерацию невалидного кода — что в XML, что в JSON. Лишь считаю, что в случае JSON вероятность получения невалидного кода чуть выше.
Я в любом случае не допускаю генерацию невалидного кода — что в XML, что в JSON. Лишь считаю, что в случае JSON вероятность получения невалидного кода чуть выше.
> Я в любом случае не допускаю генерацию невалидного кода — что в XML, что в JSON. Лишь считаю, что в случае JSON вероятность получения невалидного кода чуть выше.
Это из области религии. Вы ВЕРИТЕ, что это так. Хотя на самом деле это не так, XML и JSON по структуре (синтаксически) не так и далеки друг от друга, поэтому переделать генератор XML в генератор JSON-а не требует особых затрат. Поэтому, если вы религиозно боитесь невалидных JSON-ов на выходе, напишите сначала генератор XML-ей, а потом переделайте его в генератор JSON-ов :)
Это из области религии. Вы ВЕРИТЕ, что это так. Хотя на самом деле это не так, XML и JSON по структуре (синтаксически) не так и далеки друг от друга, поэтому переделать генератор XML в генератор JSON-а не требует особых затрат. Поэтому, если вы религиозно боитесь невалидных JSON-ов на выходе, напишите сначала генератор XML-ей, а потом переделайте его в генератор JSON-ов :)
> А значение — запросто
В твоем пример не валидный json, а не пустое значение. В случае пустого значения будет либо '', либо null
В твоем пример не валидный json, а не пустое значение. В случае пустого значения будет либо '', либо null
Зависит от серверного языка, да?
Кстати, если на уровне сервера ожидается числовое значение, а приходит пустое — то надо делать дополнительную проверку, чтобы в этом случае вывести '' или null, так как например милый ASP (не ASP.NET, а древняя версия) выводит это как просто пустую строку. Не Null, не "", а просто как пустую строку. И, как результат, может получиться невалидный json.
Кстати, если на уровне сервера ожидается числовое значение, а приходит пустое — то надо делать дополнительную проверку, чтобы в этом случае вывести '' или null, так как например милый ASP (не ASP.NET, а древняя версия) выводит это как просто пустую строку. Не Null, не "", а просто как пустую строку. И, как результат, может получиться невалидный json.
Неа, зависит от правильности реализации стандарта и логики приложения. Если ожидается числовое значение, то почему приходит пустое? С XML-же будут абсолютно теже самые проверки :) Чтобы закруглить этот спор, по сути ни о чем, повторюсь еще раз и JSON, и XML хороши оба, но случаи бывают разные и стоит использовать то, что подходит больше для данной ситуации.
Такая ошибка JSONa возможна только в том случае если вы сами руками писали структуру объекта, тут уже не json надо ругать, а себя.
А что, есть автоматические генераторы JSON из сколь угодно сложной структуры данных?
PHP: json_encode в ядре
Для других языков на сайте json поискать можно. Просто я пишу только на PHP и про другие языки ничего сказать не могу.
Идеология простая работы с json, собираем массив или объект данных и травим на него конвертер.
Какой структуры массив или объект, при правильно написанном конвертере, мне кажется все равно.
Для других языков на сайте json поискать можно. Просто я пишу только на PHP и про другие языки ничего сказать не могу.
Идеология простая работы с json, собираем массив или объект данных и травим на него конвертер.
Какой структуры массив или объект, при правильно написанном конвертере, мне кажется все равно.
Для нетипизованных языков типа PHP — конечно. А вот если встретится объект, который нельзя интерпретировать как обычный ассоциативный массив? У меня, кстати, была именно такая ситуация, когда я столкнулся с такой проблемой. И обрастает банальный вроде бы конвертер разными проверочками, рефлекшнами и прочей фигнёй, которая требуется раз в сто лет :(
То что PHP не типизированный, здесь врят ли какую то роль играет.
Честно говоря ниразу не сталкивался с объектом, который нельзя представить ввиде ассоциативного объекта.
Можно примерчик для моего общего развития?
Честно говоря ниразу не сталкивался с объектом, который нельзя представить ввиде ассоциативного объекта.
Можно примерчик для моего общего развития?
Нда. Тут, похоже, я не совсем точно выразился: объект, который нельзя естественными средствами интерпретировать как ассоциативный массив.
То бишь в Javascript, например, любое свойство типа
object.prop1
может быть использовано как
object[«prop1»]
и перебрать все свойства объекта можно банальным циклом «for».
Попробуйте сделать то же самое в VB, C#, C++? Придётся повозиться.
Имхо, проблема тут как раз ввиду типизованности языков :)
То бишь в Javascript, например, любое свойство типа
object.prop1
может быть использовано как
object[«prop1»]
и перебрать все свойства объекта можно банальным циклом «for».
Попробуйте сделать то же самое в VB, C#, C++? Придётся повозиться.
Имхо, проблема тут как раз ввиду типизованности языков :)
А чем проще работать в таком случае с XML? честно говоря не вижу никакой разницы.
Генераторы написаны для многих языков, зайдите на сайт там приведены готовые библиотеки.
Вам в случае работы при помощи генератор JSON не нужно писать руками, просто выберите объект и скажите фас. Разработчики уже об этом позаботились, и не придётся возиться.
Внизу я запутался и вас запутал, в данной ветки вы меня запутали…
А вообще просто попробуйте сделать что нибудь при помощи JSON, выбор сам сделается в пользу его.
Генераторы написаны для многих языков, зайдите на сайт там приведены готовые библиотеки.
Вам в случае работы при помощи генератор JSON не нужно писать руками, просто выберите объект и скажите фас. Разработчики уже об этом позаботились, и не придётся возиться.
Внизу я запутался и вас запутал, в данной ветки вы меня запутали…
А вообще просто попробуйте сделать что нибудь при помощи JSON, выбор сам сделается в пользу его.
А что, если мы генерим json ручками то не должны следовать стандарту? Есть стандарт, в котором описано как должен он выглядеть — по нему и пишем. Если не следуем — получаем море проблем. Все логично
А кто сказал, что НЕ должны?
Просто в данном случае вероятность получения проблем — выше. И всё.
Просто в данном случае вероятность получения проблем — выше. И всё.
Вы привели пример, с неправильной структурой JSON-а, и говорите — что вот, придет такая чтука и ниче работать не будет. А с чего она вообще должна работать?
Это тоже самое, что если вы генерите xml ручками и забудете, что надо одиночный тег закрывать вконце, а у вас будет парсер ругатся. И тоже будете говорить что-то вроде: Да, понятно, что можно защититься. И телодвижения не слишком для этого сложные потребуются, но! — всё же потребуются. И обязательное необходимо будет закрывать тег, если он одиночный?
Это тоже самое, что если вы генерите xml ручками и забудете, что надо одиночный тег закрывать вконце, а у вас будет парсер ругатся. И тоже будете говорить что-то вроде: Да, понятно, что можно защититься. И телодвижения не слишком для этого сложные потребуются, но! — всё же потребуются. И обязательное необходимо будет закрывать тег, если он одиночный?
Неправильная структура JSON, какую я привёл, запросто может получиться при, например, заполнении её из рекордсета. Пришло просто пустое значение — и может получиться такая фигня. Или просто значение переменной не определено (может, из Query String ожидалось, а не появилось).
В случае с XML конкретно такая ситуация пройдёт безболезненно и данные вернутся к Javascript, который может их обработать и решить, что делать с этим пустым блоком.
А вариант с незакрытым тегом в конце одинаково болезненный что для XML что для JSON. Всё равно что потерять — закрывающий тэг или последнюю фигурную/квадратную скобку. С той лишь разницей, что вместо XML вернётся строка, не являющаяся валидным представлением XML, а вместо JSON вывалится, очевидно, Exception.
В случае с XML конкретно такая ситуация пройдёт безболезненно и данные вернутся к Javascript, который может их обработать и решить, что делать с этим пустым блоком.
А вариант с незакрытым тегом в конце одинаково болезненный что для XML что для JSON. Всё равно что потерять — закрывающий тэг или последнюю фигурную/квадратную скобку. С той лишь разницей, что вместо XML вернётся строка, не являющаяся валидным представлением XML, а вместо JSON вывалится, очевидно, Exception.
Блин, это уже смешно. Что значит «запросто» и «может». Если у вас _запросто может получится_ невалидный json, то это исплючительно ваши проблемы. Не надо винить формать за то, что вы не смогли нормально написать сереализатор, или используете кривой сериализатор.
А вариант с невалидным xml-ем и json-ом одинаков — данных мы не получим. Если конечно вы после этот xml сами не парсите регулярками хитрыми, так, подстраховываясь.
А вариант с невалидным xml-ем и json-ом одинаков — данных мы не получим. Если конечно вы после этот xml сами не парсите регулярками хитрыми, так, подстраховываясь.
А вариант с невалидным xml-ем и json-ом одинаков — данных мы не получим. Если конечно вы после этот xml сами не парсите регулярками хитрыми, так, подстраховываясь.
При обращении за JSON или XML в Javascript обычно используются стандартные библиотечки Ajax. Так вот, как-то так сложилось, что в них обычненько есть встроенные средства парсинга JSON, а вот XML надоть парсить ручками. И если я пишу парсинг ручками, то ошибочку невалидного XML получу на этом этапе. А при «автоматическом» парсинге библиотечкой ошибку обработает библиотечка. Или не обработает и всё произойдёт «втихую».
Тогда надо посмотреть что обычно бывает, когда мы испольщуем эту библиотечку при неправильных данных. Ибо если библиотечка ничего нам не сообщает, то ну ее, эту библиотечку. Видимо поэтому большинство библиотечек, все таки нам сообщают о том, что случилось что-то такое, чего мы не ожидали, а что бы узнать как они нам это сообщают нада почитать мануальчек к библиотечке…
А кто-то писал, что это невозможно? Всего лишь «потребуются некоторые дополнительные телодвижения».
А вообще тот факт, что библиотечка самостоятельно обрабатывает исключения при невалидном ответе в JSON и вызывает определённую функцию — это скорее плюс, а не минус. Ибо исключительная ситуация — она как раз должна быть замечена. А здесь уже за нас озаботились тем, чтобы мы мимо неё не прошли!
> а вот XML надоть парсить ручками. И если я пишу парсинг ручками, то ошибочку невалидного XML получу на этом этапе. А при «автоматическом» парсинге библиотечкой ошибку обработает библиотечка.
Это всё в теории хорошо и красиво. А вы хоть раз сами пробовали руками парсить невалидный XML на JS?
Это всё в теории хорошо и красиво. А вы хоть раз сами пробовали руками парсить невалидный XML на JS?
Вы бы указали почему встал вопрос противостояния.
Экономия траффика — не всегда конкурентное приимущество.
Экономия траффика — не всегда конкурентное приимущество.
Никакого вопроса противостояния нет, просто на конкретном примере показываются определенные преимущества по экономии трафика.
В преимущества JSON надо записать то, что для обмена данными он подходит больше по причине быстродействия:
1. Скорость обработки: eval быстрее разбора xml
2. Объём данных JSON от сервера к клиенту меньше чем xml, значит время требуемое на доставку тоже меньше.
3. Json проще в понимании чем XML
В сухом остатке получаем что JSON делает приложения быстрее. А клиента который использует приложение более счастливым.
1. Скорость обработки: eval быстрее разбора xml
2. Объём данных JSON от сервера к клиенту меньше чем xml, значит время требуемое на доставку тоже меньше.
3. Json проще в понимании чем XML
В сухом остатке получаем что JSON делает приложения быстрее. А клиента который использует приложение более счастливым.
3. Json проще в понимании чем XML
Вот тут не соглашусь. Имхо, правильно сделанный XML выглядит более логичным. Но при этом, естественно, становится гораздо более «толстым» за счёт более сложного (читай «длинномерного») именования элементов -> объём передаваемых данных растёт.
Синтаксис json вообще разбирать не нужно потому что это просто нотация объекта JavaScript. Т.е. мы его уже знаем и разбираемся в нем.
Просто нам врят ли нужно постоянно просматривать что там приходит со стороны сервера, т.е. лицезреть синтаксис ответа сервера.
Если взять часный случай отладки в момент написания приложения:
console.log(eval(json));
В firebug видим всю структуру объекта полученного. Врятли это менее наглядно чем структура XML документа.
Просто нам врят ли нужно постоянно просматривать что там приходит со стороны сервера, т.е. лицезреть синтаксис ответа сервера.
Если взять часный случай отладки в момент написания приложения:
console.log(eval(json));
В firebug видим всю структуру объекта полученного. Врятли это менее наглядно чем структура XML документа.
Что-то Вы меня запутать пытаетесь. Что означает вообще
?
Имхо, только то, что визуально и наглядно структура JSON более понятна, чем структура XML элемента. Вот как раз с этим я и не согласен.
А при чём тут синтаксис ответа — ума не приложу.
Json проще в понимании чем XML
?
Имхо, только то, что визуально и наглядно структура JSON более понятна, чем структура XML элемента. Вот как раз с этим я и не согласен.
А при чём тут синтаксис ответа — ума не приложу.
Я бы еще добавил четвертый пункт, в котором упомянул бы что json — все таки нативная чтука для яваскрипта, и работать с ним гораздо проще. Нежели парсить xml, а из него все равно составлять js объекты или наборы каких-то данных, которые нам необходимы
Ну получается, что в общем случае мы берём XML и клеим тот же самый объект, который в JSON описывается одной конструкцией.
По ходу, накладные расходы при парсинге XML — гораздо больше. Но вот если использовать XPath, то XML получает явное преимущество. Разве не? :)
По ходу, накладные расходы при парсинге XML — гораздо больше. Но вот если использовать XPath, то XML получает явное преимущество. Разве не? :)
Смотря что за архитекрута у нас. К примеру мне xpath вообще не нужен. Я кидась данными и объектами между фронтендом и бэкендом. А использование xml-я для передачи данных можно рассматривать как нечто из ряда вон выходящее, к примеру если у меня будет будет какая-то хитрая древовидная структура, и мне надо будет с ней делать что-то немение хитрое.
А зачем для простых случаев усложнать себе жизнь — не могу даже и представить
А зачем для простых случаев усложнать себе жизнь — не могу даже и представить
Простите, а что вам мешает использовать аналог XPath для JSON? Выразительные средства и там и там одинаковы, имхо. Разве что, для таких манипуляций с JSON у вас есть стандартные прозрачные средства в виде самого JS :)
А можно с этого места поподробнее? Что за аналог XPath для JSON окромя банального перебора элементов/атрибутов и сравнивания с требуемой конструкцией? В XPath мне кажется достаточно удобно можно одной махонькой строчкой описать сразу все требуемые условия ко всем родительским элементам, которые меня интересуют. К сожалению, понятия не имею, как это реализовать в JSON. Покажите?
Давайте сравним. Напишите XPath, который вы хотите.
Ну вот навскидку прямо из кода
count( /Awards/Award/Category/Nominee[ position() = $winners-count ]/Attribute[ @is_nominee = '1' ] )
На стороне клиента?
Мы сейчас рассматриваем «аналог XPath для JSON». Вот пример выражения XPath, как Вы просили. Как при помощи JSON получить такой же результат, не прибегая к хардкоднутому перебору элементов? Я не могу придумать.
Почему не прибегать к хардкорному переборку элементов, кстати, если XPath это же делает всё равно? :)
А так да, на JSON будет перебор эл-тов. Но факт в том, что работать будет и будет работать верно. Поэтому всё что вы можете на XPath, будет и на JSON. Аргументом может являться только краткость кода.
А так да, на JSON будет перебор эл-тов. Но факт в том, что работать будет и будет работать верно. Поэтому всё что вы можете на XPath, будет и на JSON. Аргументом может являться только краткость кода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JSON vs. XML