All streams
Search
Write a publication
Pull to refresh
9
0
grinka @grinka

User

Send message
Ну получается, что в общем случае мы берём XML и клеим тот же самый объект, который в JSON описывается одной конструкцией.
По ходу, накладные расходы при парсинге XML — гораздо больше. Но вот если использовать XPath, то XML получает явное преимущество. Разве не? :)
Ну да. Простота понимания пользователя :)
Вот лично мне понять XML проще, чем JSON. Чётко понятно, где элементы, где атрибуты, что во что вложено. Хотя вообще разница невелика.
Неправильная структура JSON, какую я привёл, запросто может получиться при, например, заполнении её из рекордсета. Пришло просто пустое значение — и может получиться такая фигня. Или просто значение переменной не определено (может, из Query String ожидалось, а не появилось).

В случае с XML конкретно такая ситуация пройдёт безболезненно и данные вернутся к Javascript, который может их обработать и решить, что делать с этим пустым блоком.

А вариант с незакрытым тегом в конце одинаково болезненный что для XML что для JSON. Всё равно что потерять — закрывающий тэг или последнюю фигурную/квадратную скобку. С той лишь разницей, что вместо XML вернётся строка, не являющаяся валидным представлением XML, а вместо JSON вывалится, очевидно, Exception.
А кто сказал, что НЕ должны?
Просто в данном случае вероятность получения проблем — выше. И всё.
Нда. Тут, похоже, я не совсем точно выразился: объект, который нельзя естественными средствами интерпретировать как ассоциативный массив.

То бишь в Javascript, например, любое свойство типа

object.prop1

может быть использовано как

object[«prop1»]

и перебрать все свойства объекта можно банальным циклом «for».

Попробуйте сделать то же самое в VB, C#, C++? Придётся повозиться.

Имхо, проблема тут как раз ввиду типизованности языков :)
Что-то Вы меня запутать пытаетесь. Что означает вообще
Json проще в понимании чем XML

?

Имхо, только то, что визуально и наглядно структура JSON более понятна, чем структура XML элемента. Вот как раз с этим я и не согласен.

А при чём тут синтаксис ответа — ума не приложу.
Для нетипизованных языков типа PHP — конечно. А вот если встретится объект, который нельзя интерпретировать как обычный ассоциативный массив? У меня, кстати, была именно такая ситуация, когда я столкнулся с такой проблемой. И обрастает банальный вроде бы конвертер разными проверочками, рефлекшнами и прочей фигнёй, которая требуется раз в сто лет :(
3. Json проще в понимании чем XML


Вот тут не соглашусь. Имхо, правильно сделанный XML выглядит более логичным. Но при этом, естественно, становится гораздо более «толстым» за счёт более сложного (читай «длинномерного») именования элементов -> объём передаваемых данных растёт.
А что, есть автоматические генераторы JSON из сколь угодно сложной структуры данных?
Да, понятно, что можно защититься. И телодвижения не слишком для этого сложные потребуются, но! — всё же потребуются. И обязательное приведение к строке.
И ещё немаловажная проблема — если попытаться получить такой JSON через jQuery, к примеру, ошибку отловить становится крайне сложно: функция обработки результата (success) вообще не будет вызвана.

PS: Конечно любому понятно, что отдавая данные, надо озаботиться тем, чтобы их можно было принять. И для этого что-то приходится проэскейпить, что-то проверить на пустоту, однако тут всё же есть некоторая более высокая вероятность ошибки :) Трудновылавливаемой.
2. И второй вопрос… какой вариант более чреват ошибками? Например, возвращение пустого значения:

JSON:
{
a: 12,
b:
}


то же в XML:
<a>12</a><b></b>


Первый код, как вы легко можете заметить, вызовет ошибку при обработке, второй же будет «проглочен» легко и непринуждённо. Значит, во избежание проблем, генерируемый для JSON код должен проверяться на пустые значения и как-то приводиться к «безопасному». То бишь — некоторые дополнительные телодвижения нужны.

1. Мне кажется тут экономить надо скорее на времени обработки. Что быстрее будет обработано на стороне клиента, JS-eval или XML парсинг?

Ну в GTalk-е ведь та же самая ерунда, это не недостаток конкретно данной «разработки»
Да, спасибо, пользователи QIP 2005 — тоже
Ну сказано ж, используют Open AIM для этого :)
Проверял с QIP: — в обе стороны русские буквы ходят нормально
Miranda: владелец Миранды всё видел по-русски, мне же приходили нечитаемые «буковки»
У меня сохранились контакты, но пропали все пункты меню.
Да пока вроде сыроват сервис… И, судя по «старине», неизвестно, будет ли развиваться.
Ну для некоторых это оказалось сюрпризом.
А ну как кто-то решит, что Google просто физически AOL-овские сервера уничтожил? :)
Хм. Это позволяет производить Sign in, Sign Out. А у нас проблема вроде была не в этом, а в полном отключении чата на странице? У меня вообще гаджета не было там.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity