Ну получается, что в общем случае мы берём XML и клеим тот же самый объект, который в JSON описывается одной конструкцией.
По ходу, накладные расходы при парсинге XML — гораздо больше. Но вот если использовать XPath, то XML получает явное преимущество. Разве не? :)
Ну да. Простота понимания пользователя :)
Вот лично мне понять XML проще, чем JSON. Чётко понятно, где элементы, где атрибуты, что во что вложено. Хотя вообще разница невелика.
Неправильная структура JSON, какую я привёл, запросто может получиться при, например, заполнении её из рекордсета. Пришло просто пустое значение — и может получиться такая фигня. Или просто значение переменной не определено (может, из Query String ожидалось, а не появилось).
В случае с XML конкретно такая ситуация пройдёт безболезненно и данные вернутся к Javascript, который может их обработать и решить, что делать с этим пустым блоком.
А вариант с незакрытым тегом в конце одинаково болезненный что для XML что для JSON. Всё равно что потерять — закрывающий тэг или последнюю фигурную/квадратную скобку. С той лишь разницей, что вместо XML вернётся строка, не являющаяся валидным представлением XML, а вместо JSON вывалится, очевидно, Exception.
Для нетипизованных языков типа PHP — конечно. А вот если встретится объект, который нельзя интерпретировать как обычный ассоциативный массив? У меня, кстати, была именно такая ситуация, когда я столкнулся с такой проблемой. И обрастает банальный вроде бы конвертер разными проверочками, рефлекшнами и прочей фигнёй, которая требуется раз в сто лет :(
Вот тут не соглашусь. Имхо, правильно сделанный XML выглядит более логичным. Но при этом, естественно, становится гораздо более «толстым» за счёт более сложного (читай «длинномерного») именования элементов -> объём передаваемых данных растёт.
Да, понятно, что можно защититься. И телодвижения не слишком для этого сложные потребуются, но! — всё же потребуются. И обязательное приведение к строке.
И ещё немаловажная проблема — если попытаться получить такой JSON через jQuery, к примеру, ошибку отловить становится крайне сложно: функция обработки результата (success) вообще не будет вызвана.
PS: Конечно любому понятно, что отдавая данные, надо озаботиться тем, чтобы их можно было принять. И для этого что-то приходится проэскейпить, что-то проверить на пустоту, однако тут всё же есть некоторая более высокая вероятность ошибки :) Трудновылавливаемой.
2. И второй вопрос… какой вариант более чреват ошибками? Например, возвращение пустого значения:
JSON:
{
a: 12,
b:
}
то же в XML:
<a>12</a><b></b>
Первый код, как вы легко можете заметить, вызовет ошибку при обработке, второй же будет «проглочен» легко и непринуждённо. Значит, во избежание проблем, генерируемый для JSON код должен проверяться на пустые значения и как-то приводиться к «безопасному». То бишь — некоторые дополнительные телодвижения нужны.
Хм. Это позволяет производить Sign in, Sign Out. А у нас проблема вроде была не в этом, а в полном отключении чата на странице? У меня вообще гаджета не было там.
По ходу, накладные расходы при парсинге XML — гораздо больше. Но вот если использовать XPath, то XML получает явное преимущество. Разве не? :)
Вот лично мне понять XML проще, чем JSON. Чётко понятно, где элементы, где атрибуты, что во что вложено. Хотя вообще разница невелика.
В случае с XML конкретно такая ситуация пройдёт безболезненно и данные вернутся к Javascript, который может их обработать и решить, что делать с этим пустым блоком.
А вариант с незакрытым тегом в конце одинаково болезненный что для XML что для JSON. Всё равно что потерять — закрывающий тэг или последнюю фигурную/квадратную скобку. С той лишь разницей, что вместо XML вернётся строка, не являющаяся валидным представлением XML, а вместо JSON вывалится, очевидно, Exception.
Просто в данном случае вероятность получения проблем — выше. И всё.
То бишь в Javascript, например, любое свойство типа
object.prop1
может быть использовано как
object[«prop1»]
и перебрать все свойства объекта можно банальным циклом «for».
Попробуйте сделать то же самое в VB, C#, C++? Придётся повозиться.
Имхо, проблема тут как раз ввиду типизованности языков :)
?
Имхо, только то, что визуально и наглядно структура JSON более понятна, чем структура XML элемента. Вот как раз с этим я и не согласен.
А при чём тут синтаксис ответа — ума не приложу.
Вот тут не соглашусь. Имхо, правильно сделанный XML выглядит более логичным. Но при этом, естественно, становится гораздо более «толстым» за счёт более сложного (читай «длинномерного») именования элементов -> объём передаваемых данных растёт.
И ещё немаловажная проблема — если попытаться получить такой JSON через jQuery, к примеру, ошибку отловить становится крайне сложно: функция обработки результата (success) вообще не будет вызвана.
PS: Конечно любому понятно, что отдавая данные, надо озаботиться тем, чтобы их можно было принять. И для этого что-то приходится проэскейпить, что-то проверить на пустоту, однако тут всё же есть некоторая более высокая вероятность ошибки :) Трудновылавливаемой.
JSON:
то же в XML:
Первый код, как вы легко можете заметить, вызовет ошибку при обработке, второй же будет «проглочен» легко и непринуждённо. Значит, во избежание проблем, генерируемый для JSON код должен проверяться на пустые значения и как-то приводиться к «безопасному». То бишь — некоторые дополнительные телодвижения нужны.
Miranda: владелец Миранды всё видел по-русски, мне же приходили нечитаемые «буковки»
А ну как кто-то решит, что Google просто физически AOL-овские сервера уничтожил? :)