Comments 47
Странный велосипед, грозит быдлокодерством. Если приложение большое, то скорее всего есть модели на клиенте, никто не мешает сделать так new Person(jsonData) и внутри уже в черном ящике приводим данные к нужному виду, зачем усложнять общение с сервером?! Ведь эти данные мы не сможем использовать нигде больше — в них логика! Т.е. Public api такрй делать нельзя — а разделять паблик и не паблик не верно. Они разойдутся сильно со временем
В этой статье описаны две вещи. Во-первых, концепция. А во-вторых, возможные варианты использования. Никто не мешает использовать концепцию только там, где это действительно оправдано.
Скажем, те же даты…
Скажем, те же даты…
Возьмем те же даты, есть клиенты на ios, android, и браузер. Как нам этот формат поможет? Про то что это концепция — я написал, что смешивать логику с данными плохо. Но, как говорится не возбраняется, просто шаг в сторону плохой архитектуры. Но я согласен, в некоторых проектах это оправдано.
Даты — это не логика.
Дата нет, но конвертация формата даты из одного в другой вполне даже является.
Концепция заключается не в конвертации из одного формата в другой, а в отметке о необходимости такой конвертации.
Совершенно верно. В дополнение к сказанному ниже, хочу также заметить, что jsonex лишь вносит дополнительную ясность в сложных случаях. Если вы используете нестандартные типы данных, конечно же вам нужно описать их в документации API. Например, вы можете указать, что нотация
В случае необходимости использовать даты в JSON, вам пришлось бы делать приписку к каждому полю, содержащему дату, указывая, в каком она формате, либо делать где-то пометку, что все даты передаются в формате таком-то и надеяться, что все обратят на эту надпись внимание и никто ничего не напутает. Если даты – ваша единственная проблема, это еще куда не шло. При большем разнообразии типов запутаться еще проще.
Date() означает дату и имеет своим единственным аргументом дату в таком-то формате.В случае необходимости использовать даты в JSON, вам пришлось бы делать приписку к каждому полю, содержащему дату, указывая, в каком она формате, либо делать где-то пометку, что все даты передаются в формате таком-то и надеяться, что все обратят на эту надпись внимание и никто ничего не напутает. Если даты – ваша единственная проблема, это еще куда не шло. При большем разнообразии типов запутаться еще проще.
Плюс это грозит большим головняком при изменении требований, именно поэтому логику для вычислимых данных выносят в отдельные статичные утилитные методы-хэлперы, которые изрядно покрывают тестами.
Странный велосипед, грозит быдлокодерством
К сожалению, любой достаточно гибкий и мощный инструмент будет грозить быдлокодерством. В том числе и сам JS.
Если приложение большое, то скорее всего есть модели на клиенте, никто не мешает сделать так new Person(jsonData) и внутри уже в черном ящике приводим данные к нужному виду, зачем усложнять общение с сервером?!
Насчет черного ящика – верно, но для поддержки любых типов данных за пределами набора, предоставляемого JSON, придется либо держать схему с явно прописанными типами полей, либо городить странные конструкции. Именно этого хотелось бы избежать. Конечно, если схема уже есть – никаких проблем, используйте схему.
Что касается «усложнения» общения с сервером – если вам не нужны batch-запросы, вы не используете типов данных за пределами поддерживаемых в JSON или для всего уже есть схема, которая тщательно поддерживается, если вам не нужна возможность делать API доступным как по HTTP, так и по веб-сокетам, а то и по каким-то еще протоколам, то конечно, не надо ничего усложнять. Но если вам нужны какие-то из этих возможностей – jsonex дает их все разом, простым и согласованным способом. То, над реализацией чего вы могли бы ломать голову, становится уже решенной задачей.
Ведь эти данные мы не сможем использовать нигде больше — в них логика! Т.е. Public api такрй делать нельзя
Никто вас не заставляет засовывать логику в данные. В данных вида
Date('1991-01-01') не больше логики, чем в <date>1991-01-01</date> – нотации вызова можно считать своего рода тэгами, данные остаются данными. То, что парсер трактует Date() как вызов некой функции – всего лишь деталь реализации, позволяющая сделать парсер простым и расширяемым.Конечно же, с помощью jsonex можно делать публичный API. Главное, чтобы клиенты понимали тот набор «тэгов», которым вы оперируете. Но это верно для любого API – та часть данных, которую клиент не может интерпретировать, будет ему бесполезна. В jsonex вы можете отбрасывать все незнакомые нотации вызова, заменяя их на null или какую-то структуру общего назначения – для этого и нужен обработчик по умолчанию. Точно также, в XML вы игнорируете теги, которые вам не интересны.
В самих запросах к серверу, конечно, логика может присутствовать, также как она может присутствовать в SQL-запросах и любых более-менее сложных языках запросов. Это и прекрасно. Это позволяет конструировать гораздо более сложные запросы, когда они вам нужны. Но можно и запретить их использовать, если они вам без надобности.
Для рабочего проекта имхо куда более симпатичен Thrift.
Под него много библиотек, а под этот формат мне придется писать arc пост-обработку вручную для всех языков. Не JS единым живем.
Если статья была для привлечения внимания сообщество, тогда я за. Пока идеального формата обмена данными не реализовали, быть может ваш проект займет свою нишу. Как концепция он не интересен, а вот если он будет поддерживать кучу языков и иметь хорошую документацию — другой разговор.
Под него много библиотек, а под этот формат мне придется писать arc пост-обработку вручную для всех языков. Не JS единым живем.
Если статья была для привлечения внимания сообщество, тогда я за. Пока идеального формата обмена данными не реализовали, быть может ваш проект займет свою нишу. Как концепция он не интересен, а вот если он будет поддерживать кучу языков и иметь хорошую документацию — другой разговор.
Пока это в первую очередь концепция, к которой я сам отношусь осторожно. После того, как появится первый проект, активно использующий jsonex для клиент-серверного взаимодействия, появится новая статья, из которой будет понятно, оправдались ли радужные надежды и какие проблемы возникли при столкновении с реальностью.
Первоочередная цель этой статьи – поделиться идеей с теми, кто решает похожие задачи. Идея может оказаться полезной, а отзывы будут бесценными. В конце концов, при проектировании я думаю в первую очередь о своих собственных задачах и могу упустить что-то важное.
Как можно заметить по выбору хабов, jsonex ориентирован в первую очередь на веб-разработку и JS. Он выглядит очень естественно для JS-разработчиков, а в случае использования JS на стороне сервера, один и тот же код обработчиков можно использовать с обеих сторон.
Будет ли jsonex широко использоваться – вопрос истории. А документация будет )
Первоочередная цель этой статьи – поделиться идеей с теми, кто решает похожие задачи. Идея может оказаться полезной, а отзывы будут бесценными. В конце концов, при проектировании я думаю в первую очередь о своих собственных задачах и могу упустить что-то важное.
Как можно заметить по выбору хабов, jsonex ориентирован в первую очередь на веб-разработку и JS. Он выглядит очень естественно для JS-разработчиков, а в случае использования JS на стороне сервера, один и тот же код обработчиков можно использовать с обеих сторон.
Будет ли jsonex широко использоваться – вопрос истории. А документация будет )
Насчет черного ящика – верно, но для поддержки любых типов данных за пределами набора, предоставляемого JSON, придется либо держать схему с явно прописанными типами полейэто даже полезно. с JSON Schema уже во всю лисапедят то, что раньше делали с DTD и XML Schema. github.com/google/autoparse, github.com/cwacek/python-jsonschema-objects и т.п., — вплоть до билдеров форм на бутстрапе.
Я ничего не имею против схемы. Это важная и полезная практика, и jsonex вовсе не исключает ее использования, хотя и позволяет без нее обходиться, если по каким-то соображениям от нее отказались. Кроме того, при наличии схемы, он позволяет отделить валидацию от парсинга, что может быть полезно – каждый из процессов по отдельности проще в реализации и может использоваться независимо, ведь валидация бывает нужна не только для свежераспарсеных данных.
Мне кажется, что вы ничего не знаете про YAML
В отличие от YAML, очень развесистого формата с много-много-страничной спецификацией, jsonex является тривиальным расширением простейшего JSON, спецификация которого занимает одну страницу. При этом jsonex легко расширяем, имеет родственный JS синтаксис и позволяет конструировать сложные запросы к серверу в тех же терминах, что и обычные данные. Полагаю, это может оказаться полезным.
вероятно шутка в том, что yaml тоже начинался как тривиальное расширение простейшего перла. а потом понеслось… :)
Как-правило, в JSON многих не устраивает отсутствие комментариев и использования одинарных кавычек.
YAML же предоставляет такую возможность, не отказываясь от JSON-нотации!
Мало того, для работы с YAML уже написаны десятки библиотек под разные языки, при том что в каких-то языках он включен в стандартную библиотеку (например, Ruby).
YAML же предоставляет такую возможность, не отказываясь от JSON-нотации!
Мало того, для работы с YAML уже написаны десятки библиотек под разные языки, при том что в каких-то языках он включен в стандартную библиотеку (например, Ruby).
Более того, любой JSON-документ является валидным YAML-документом.
Почти, за одним маленьким исключением — в YAML нельзя использовать табуляцию.
В YAML можно использовать табуляцию. Табуляцию нельзя лишь использовать для значащих отступов. А если вы используете вариант формата со скобками, как в JSON, значащих отступов нет.
Смотрите, вот такой пример кода не пройдет валидацию (по крайней два парсера ругаются).
{
foo: 1
}
Как ни странно, такой пример кода не пройдёт валидацию и JSON-парсером, ибо ключ не закавычен =)
Надеюсь мне удалось донести, до вас свою мысль.
JSON есть правильное подмножество YAML. Если вы считаете это утверждение опровергнутым, то нет, не удалось. Если мысль была какая-то иная, то тоже не удалось, я не уловил её.
{
"foo": 1
}
Значит пока мало кто соблюдает спецификацию, т.к. этот пример не пройдет валидацию такими парсерами как js-yaml и pyyaml
ike@shair:/tmp> od -tc 000
0000000 { \n \t " a a a " : 1 1 1 \n } \n
0000020
ike@shair:/tmp> js-yaml 000
aaa: 111
ike@shair:/tmp>
ЧЯДНТ?
Не имею малейшего представления:
yaml-online-parser.appspot.com (pyyaml)
>> JS-YAML: deficient indentation at line 9, column 1:
>> foo: 1
>> ^
>> JS-YAML: deficient indentation at line 10, column 1:
>> }
>> ^
yaml-online-parser.appspot.com (pyyaml)
Output
ERROR:
while scanning for the next token
found character '\t' that cannot start any token
in "<unicode string>", line 2, column 1:
"foo": 1
^
Боюсь, что возможности, близкие к нотации вызова в jsonex – тэги YAML, все-таки выходят за пределы JSON-нотации и выглядят достаточно чужеродно на ее фоне. При этом нотация вызова гибче, чем тэги. Ну и любой валидный JSON-документ точно также является валидным jsonex-документом, как и YAML-документом. Насчет библиотек могу только порадоваться за YAML, но и он когда-то начинал на фоне их отсутствия.
«Тем не менее, некоторые вещи хотелось бы улучшить»
Есть, но не эти. Ничего концептуально нового — заточенный под нужды автора способ обмена данными.
Есть, но не эти. Ничего концептуально нового — заточенный под нужды автора способ обмена данными.
Разумеется, я думал в первую очередь о своих задачах и нуждах )
Но тем более интересно – что же хотелось бы улучшить вам?
Соглашусь, что ничего концептуально нового тут нет – «нотация вызова» широко используется в языках программирования. Но чтобы увидеть ее ценность применительно к формату данных, потребовалась долгая дорога.
Но тем более интересно – что же хотелось бы улучшить вам?
Соглашусь, что ничего концептуально нового тут нет – «нотация вызова» широко используется в языках программирования. Но чтобы увидеть ее ценность применительно к формату данных, потребовалась долгая дорога.
Такой велосипед на первый взгляд требует уйму времени на поддержку (баго фикс, въезжание новых разработчиков в особенности фреймворка).
Поэтому очень хочется понять, зачем он был сделан.
В начале поста брошены ну уж очень абстрактые фразы, из которых нельзя понять юз кейсы конечных пользователей. Из функциональности фреймворка тоже это понять нельзя, потому что, возможно, сделано не то и не так. Встречался с таким.
Ну например, такие вопросы:
— Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента. Почему Вы выбрали вариант сложнее?
— Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
— Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
Поэтому очень хочется понять, зачем он был сделан.
В начале поста брошены ну уж очень абстрактые фразы, из которых нельзя понять юз кейсы конечных пользователей. Из функциональности фреймворка тоже это понять нельзя, потому что, возможно, сделано не то и не так. Встречался с таким.
Ну например, такие вопросы:
— Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента. Почему Вы выбрали вариант сложнее?
— Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
— Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
Такой велосипед на первый взгляд требует уйму времени на поддержку (баго фикс, въезжание новых разработчиков в особенности фреймворка).
Это можно сказать о любом фреймворке.
Но возьмите, к примеру batch-запросы Facebook Graph API. Они устроены довольно сложно. С точки зрения клиента, jsonex даже проще, при том, что возможностей у него больше. На серверной стороне batch-запросы Facebook тоже устроены непросто, поверьте. Может, чуточку проще, чем движок arc, но не принципиально. При том, что arc опять же умеет больше.
При этом Facebook не претендует на универсальность подхода в своем batch API. Если вам понадобится использовать batch-запросы другой системы – придется начать с нуля. Если вы захотите реализовать batch-запросы у себя на серверной стороне – нет хорошего способа это сделать. Вы можете мимикрировать под Facebook (и подстраваться под все их изменения) или придумать свой подход – в любом случае решение будет достаточно уникальным.
При этом мы говорим только о batch-запросах, не затрагивая других тем. jsonex решает задачу batch-запросов, а также ряд других задач. При этом в качестве решения берется очень простое расширение всем знакомого JSON. Если ваша система «говорит на jsonex», в ней уже есть batch-запросы, кастомные типы данных и прочие плюшки. И вы можете общаться с любой системой, поддерживающей jsonex не внося изменений в подходы к построению запросов и обработке данных.
Далее по вашим вопросам.
Зачем нужны batch-запросы? В самом элементарном случае мы можем сделать RESTful api для каждого из запросов, параллельность выполнения чанков можем гарантировать на стороне клиента.
Во-первых, клиент (браузер) очень плохо гарантирует параллельность выполнения чанков. Число одновременных подключений к одному домену ограничено. SPDY или его аналог когда-нибудь решит эту проблему, но пока она есть.
Но даже если бы ее не было. Часто вам нужно получить одни данные, а затем на их основе получить другие. В этом случае запросы не параллелятся. Чтобы вытащить друзей ваших друзей, вам придется сделать два последовательных запроса. Либо добавить в API специальный вызов для вытаскивания друзей друзей (а также кучу других вызовов, вытаскивающих прочие комбинации зависимых данных, которые вам могут понадобиться). Альтернативное решение – batch-запросы с поддержкой зависимых вызовов. Как в том же Facebook Graph API, или как в jsonex.
Что за юз кейс для выполнения на клиенте произвольного кода? Почему бы не использовать некий eval валидного js-кода на стороне сервера хотя бы?
jsonex не позволяет выполнять произвльный код, ни на клиенте, ни на сервере. Только заранее определенные обработчики, смысл которых, равно как и возможные параметры, должен быть явно прописан в API. В случае jsonex ваши обработчики и есть API, включающее как возможные серверные вызовы, так и спецификацию нестандартных типов данных.
Я правильно понимаю, что схемы нет в проекте? Ну то есть если мы отправляем объект типа Person в одном запросе на сервер может прийти поле с именем dateOfBirth, а во втором birthDate? Если есть, то почему мы железно должны указывать тип данных например Date, а не определять его по схеме?
Если у вас есть схема данных с четко прописанными типами, конечно, вы можете ее использовать. Это не даст вам других возможностей jsonex, но с типами данных все будет хорошо )
И конечно же, отсутствие формального описания схемы данных вовсе не дает вам право отдавать дату рождения то как dateOfBirth, то как birthDate – в пределах серверного кода вы ведь так не делаете, не смотря на всю эту динамическую типизацию? Здесь ровно то же самое.
jsonex позволяет вам не иметь схемы данных. А если она есть – отделить валидацию согласно схеме данных от парсинга. В случае обработки JSON вам придется прямо во время валидации интерпретировать данные согласно схеме, чтобы ту же банальную дату, переданную в виде строки, превратить в объект даты и подставить в нужное место. Если вы этого не сделаете, вас будет ждать сюрприз в качестве строки в поле, в котором ожидается дата. Вам понадобится хитрый валидатор, который умеет не только проверять корректность данных, но и модифицировать их согласно схеме. По моему опыту, многие за неимением такого валидатора разбирают пришедшие данные вручную, независимо от наличия или отсутствия схемы.
jsonex отдаст вам готовые объекты. Хотите – валидируйте после, хотите – прямо в обрабочиках. Хотите – не валидируйте. Вся явная чушь все равно должна быть отсеяна обработчиками во имя принципов безопасности.
Это все здорово. Но я опять не увидел целесообразности этих решений.
Зачем писать Всеобъемлющий Супер Фреймворк, если можно решить каждый вопрос в отдельности, даже если писать все 'вручную' (те же отдельные вызовы апи)?
Ваш клиентский код будет генерить сотни-сотни вызовов апи в секунду? зачем заморачиваться об ограничениях браузера?
Почему бы не добавить этот самый запрос вытаскивания друзей друзей? Это очень просто и очень явно. Здесь я вижу немного кода на серверной стороне, обрабатывающей запрос. И не вижу супер-мега сложного кода фреймворка.
И даже при этом фреймворке ваши разработчики будут писать количество кода сравнимое с первым вариантом, но во втором варианте у Вас будет в системе присутствовать очень сложная система этого фреймворка.
Я не могу понять, а что плохого в том, что придется во время валидации интерпретировать данные согласно схеме? Давайте назовем этот процесс конвертацией из json в js-объект модели. И тут сразу все встает на свои места и может быть легко автоматизировано путем простой декларацией схемы. Сюрприза по Вашему примеру меня ждать не будет, потому что если данные не парсятся, то вылетит ошибка на этапе конвертации.
Вы извините, конечно. Но я вижу астронавта от архитектуры.
Зачем писать Всеобъемлющий Супер Фреймворк, если можно решить каждый вопрос в отдельности, даже если писать все 'вручную' (те же отдельные вызовы апи)?
Ваш клиентский код будет генерить сотни-сотни вызовов апи в секунду? зачем заморачиваться об ограничениях браузера?
Почему бы не добавить этот самый запрос вытаскивания друзей друзей? Это очень просто и очень явно. Здесь я вижу немного кода на серверной стороне, обрабатывающей запрос. И не вижу супер-мега сложного кода фреймворка.
И даже при этом фреймворке ваши разработчики будут писать количество кода сравнимое с первым вариантом, но во втором варианте у Вас будет в системе присутствовать очень сложная система этого фреймворка.
Я не могу понять, а что плохого в том, что придется во время валидации интерпретировать данные согласно схеме? Давайте назовем этот процесс конвертацией из json в js-объект модели. И тут сразу все встает на свои места и может быть легко автоматизировано путем простой декларацией схемы. Сюрприза по Вашему примеру меня ждать не будет, потому что если данные не парсятся, то вылетит ошибка на этапе конвертации.
Вы извините, конечно. Но я вижу астронавта от архитектуры.
Зачем писать Всеобъемлющий Супер Фреймворк, если можно решить каждый вопрос в отдельности, даже если писать все 'вручную' (те же отдельные вызовы апи)?
А зачем писать операционную систему? Ведь все можно сделать вручную!
Конечно можно. Если вам кажется, что ваши задачи лучше решаются в ручной реализации – используйте ручную реализацию. Задачи бывают разные, подход должен соответствовать задаче.
Ваш клиентский код будет генерить сотни-сотни вызовов апи в секунду? зачем заморачиваться об ограничениях браузера?
Вы не поверите, но достаточно всего нескольких затяжных вызовов и ваши запросы встанут в очередь. И это только для данных, а ведь вам и статику тянуть. Ну и главное-то не в решении чисто транспортных проблем, а в исключении проброса данных клиенту только ради того, чтобы тут же отправить их обратно на сервер в новом запросе.
Почему бы не добавить этот самый запрос вытаскивания друзей друзей? Это очень просто и очень явно.
И правда, зачем позволять композицию функций? Ведь всегда можно написать функцию, которая вызовет внутри себя одну, а затем другую.
И все будет неплохо, пока у вас пара-тройка таких агрегирующих запросов. В большой системе их будут десятки, каждый с кучей параметров, настраивающих поведение внутренних вызовов. А если система открытая, то и вовсе не угадать, какие комбинации понадобятся людям. Поэтому и существуют языки запросов, позволяющие нетривиальные конструкции, такие как SQL или тот же Facebook batch API.
Я не могу понять, а что плохого в том, что придется во время валидации интерпретировать данные согласно схеме? Давайте назовем этот процесс конвертацией из json в js-объект модели.
Вашему конвертеру нужно будет заранее знать о всех доступных форматах. Либо вам придется писать свой вариант конвертера для каждой новой системы, которая имеет свой взгляд на то, как выглядит сериализованая дата. Либо вы попытаетесь сделать его расширяемым и в какой-то мере повторите дизайн jsonex.
И даже при этом фреймворке ваши разработчики будут писать количество кода сравнимое с первым вариантом, но во втором варианте у Вас будет в системе присутствовать очень сложная система этого фреймворка.
Количество кода в языке, позволяющем композицию функций, железно будет меньше. При этом функции будут проще и пользоваться ими будет удобнее. Кроме того, мощность API будет расти гораздо быстрее с добавлением каждой новой функции, так как ее можно будет использовать в разных комбинациях с другими.
Что касается сложности фреймворка – движок arc предельно прост. В нем чуть более 300 строчек кода, разбитого на функции, большинство которых укладывается в десяток строк. В реализации от mayorovp кода еще меньше. Что именно вызывает у вас ощущение запредельной сложности?
Я уже не говорю о простоте использования. Если внутренности arc для вас слишком сложны (что на самом деле странно), вы можете просто пользоваться им. Он просто работает. Как работает ваш телефон или компьютер.
Вы извините, конечно. Но я вижу астронавта от архитектуры.
От вас это звучит как комплимент )
Вероятно, вам действительно не нужен jsonex. Честно говоря, всегда будет больше людей, которым он не нужен, чем тех, кому нужен. Но, если вы никогда не сталкивались с необходимостью batch запросов, вам не приходилось выставлять очередной чертов URL, по которому доступно то же самое, что по трем другим, но одним куском, вы никогда не ломали голову, как передать нестандартный тип данных, так чтобы он органично вписался в существующую систему, а не «давайте воткнем это грязным хаком, сейчас нет времени дорабатывать конвертер» – это еще не значит, что вселенная тривиальна и 64K хватит для всех. Это значит только то, что вы пока не сталкивались с более сложными ее проявлениями.
В моем случае, за те годы, что я работаю с веб, jsonex мог сэкономить как мне, так и окружающим огромное количество времени, которое можно было потратить на куда более интересные вещи, чем возня с транспортировкой данных «вручную».
Что-то в проекте arc как-то всего очень много. Если кому-нибудь нужен компактный инструмент для преобразования JSONEX в объекты и в обратную сторону, могу предложить библиотеку из одного файла. В ней нет ничего лишнего — совсем ничего, даже даты.
Зависимостей нет. Работает в «совместимом» формате, то есть с JSON, использует стандартные JSON.parse и stringify.
Зависимостей нет. Работает в «совместимом» формате, то есть с JSON, использует стандартные JSON.parse и stringify.
Спасибо! Добавил упоминание библиотеки в статью.
P.S. В arc много всего, потому что на данном этапе он пытается быть «академичным» – позволять играть с отдельными частями, сохраняя общую простоту. Например, он на полпути к использованию Stream-интерфейса, что должно дать возможность парсинга из потока. Он позволяет подключить альтернативный код очереди выполнения, содержит несколько базовых обработчиков, включая событийные get и set, добавлена пара других заделов на будущее. Сейчас это скорее научная лаборатория, чем рабочий завод.
P.S. В arc много всего, потому что на данном этапе он пытается быть «академичным» – позволять играть с отдельными частями, сохраняя общую простоту. Например, он на полпути к использованию Stream-интерфейса, что должно дать возможность парсинга из потока. Он позволяет подключить альтернативный код очереди выполнения, содержит несколько базовых обработчиков, включая событийные get и set, добавлена пара других заделов на будущее. Сейчас это скорее научная лаборатория, чем рабочий завод.
Абсолютно имеет место быть все, что в статье описано, как вариант декларативного запроса, не вижу причин почему его нельзя использовать, пять баллов.
Как только в формате данных появляется контекст, брюки превращаются из формата обмена в сигнальный протокол.
Нет никакой нужды для этого расширять JSON, просто оговорите ваш протокол до предела:
и JSON расширять не нужно, вся логика будет на сервере. А если же вас огорчают кавычки и комментарии, то вы что-то делаете не так, если вы хотите формат, удобный для глаз и рук, действительно уже есть YAML, где позабочено и о кавычках и о комментариях.
Единственной разумной новацией можно назвать ввод типов данных, типа даты, но нужно чётко понимать, что JSON родился из яваскрипта, и жертвование совместимостью с форматом сериализации объекта должно быть чем-то хорошо оправдано.
Нет никакой нужды для этого расширять JSON, просто оговорите ваш протокол до предела:
{"whatToDo": "doWhatIMean"}
и JSON расширять не нужно, вся логика будет на сервере. А если же вас огорчают кавычки и комментарии, то вы что-то делаете не так, если вы хотите формат, удобный для глаз и рук, действительно уже есть YAML, где позабочено и о кавычках и о комментариях.
Единственной разумной новацией можно назвать ввод типов данных, типа даты, но нужно чётко понимать, что JSON родился из яваскрипта, и жертвование совместимостью с форматом сериализации объекта должно быть чем-то хорошо оправдано.
Как только в формате данных появляется контекст, брюки превращаются из формата обмена в сигнальный протокол.Этот самый контекст находится далеко снаружи формата и является исключительно деталью реализации.
Нет никакой нужды для этого расширять JSON, просто оговорите ваш протокол до предела:У автора есть система кодирования, которая превращает его JSONEX в валидный JSON, в котором все именно так и оговорено.
{"whatToDo": "doWhatIMean"}
JSON родился из яваскрипта, и жертвование совместимостью с форматом сериализации объекта должно быть чем-то хорошо оправданоПредлагаемый автором JSONEX точно так же полностью совместим с яваскриптом, из которого он родился.
Я бы хотел повсеместное распространение YAML и edn.
А что вы думаете по поводу JSON5?
А чего тут думать? Надо все это включать в JSONEX :) Кстати, можно же форкнуть проект, и получить JSONEX-парсер после незначительных модификаций…
Выглядит разумно, нужно учесть эти фишки при дальнейшем развитии jsonex.
Кстати, если в вызов reviver добавить ссылку на родительский объект и гарантировать, что для массивов тоже передается key (индекс массива), то на базе JSON5 было бы очень просто делать парсинг jsonex в JSON5-представлении. Надо будет обсудить этот вопрос с авторами, может получится договориться и о более тесной интеграции.
Кстати, если в вызов reviver добавить ссылку на родительский объект и гарантировать, что для массивов тоже передается key (индекс массива), то на базе JSON5 было бы очень просто делать парсинг jsonex в JSON5-представлении. Надо будет обсудить этот вопрос с авторами, может получится договориться и о более тесной интеграции.
Sign up to leave a comment.
jsonex – упрощаем сложные клиент-серверные диалоги