LINUX.ORG.RU

hint: s-expressions

anonymous
()

>вы используете?

А, стоп. Использую я XML :)

yoghurt ★★★★★
()

Альтернатив XML'ю нет.

CARS ★★★★
()
Ответ на: комментарий от trex6

А запросы с клиент-сайда идут сразу к БД? Круто, два года такое хотел. Вот только как ограничивать доступ к БД в таком случае?

anonymous
()

Для чего? Для конфигов? Для передачи данных? Для их хранения?

baverman ★★★
()
Ответ на: комментарий от yoghurt

> Схема по крайней мере у джейсона есть

Посмотрел я пример схемы... ужоснах. DTD проще.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Удобно сделать сложные трансформации на сервер-сайде на нормальномя ЯП, а не на сраном PL/SQL или подобном. Тем более часто есть интеграции с большим количеством систем нужно много кода на сервере

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Я и не предлагал серебряную пулю. Нередко веб-приложение является всего лишь простеньким фронтендом к БД (кстати, я имел ввиду нечто вроде mongodb, которое сразу в json'е отдает данные).

anonymous
()

зависит от задачи, иногда альтернатив нет

а вообще - yaml

shty ★★★★★
()

А альтернатива чего именно?

А то области применения разные… Если разметка, то альтернатив нет. Если конфиги хранить, то JSON или ini вполне подойдут.

<вброс>А YAML — это вообще какое-то не читаемое говно!</вброс>

fat_angel ★★★★★
()
Ответ на: комментарий от rival

Поприятней xml'а будет.

Конечно, конечно… Вот пример из педивикии:

<event name="PRIVMSG">
 <method name="newUri" regex="^http://.*" />
 <method name="deleteUri" regex="^delete.*" />
 <method name="randomUri" regex="^random.*" /> 
</event>
event: PRIVMSG
methods:
  - name: newUri
    regexp: '^http://.*'
  - name: deleteUri
    regexp: '^delete.*'
  - name: randomUri
    regexp: '^random.*'

В случае XML отдельные блоки сразу вычленяются благодаря скобочкам, а вот как парсить твой ямль ХЗ.

fat_angel ★★★★★
()

sqlite || json
Питоновский модули иногда - как альтернатива json.

schizoid ★★★
()
Ответ на: комментарий от fat_angel

а вот как парсить твой ямль ХЗ.

Спроси у лисперов.

На самом деле это всего лишь вопрос привычки.

baverman ★★★
()

последний срач про xml занял ~30 страниц

Karapuz ★★★★★
()
Ответ на: комментарий от pitekantrop

>Написал на java для него неделю назад библиотечку парсер комбинаторов и генераторов.
в последнее время ЛОР становится все смешнее.

По сабжу:
лично я - ничего кроме xml для кроссплатформенной передачи данных не вижу. Некоторые мои знакомые используют JSON - им нравится. Я немного тоже попробовал, но отсутствие валидации и плохая читабельность перевысили более высокую скорость маршаллинга/демаршаллинга.

Ну а для конфигов где возможно - аннотациии, где невозможно - ну только XML.

На сегодня считаю XML одним из столпов языков хранения/передачи данных.

Уже одна автогенерация классов из xsd со всеми необходимыми аннотациями многого стоит.

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

> в последнее время ЛОР становится все смешнее

Что смешного?

плохая читабельность

У XML она лучше? Ты тролль что ли?

Уже одна автогенерация классов из xsd со всеми необходимыми аннотациями многого стоит.

Так говоришь, как будто что-то эдакое. Тулзы типа xjc пишутся за неделю.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

>У XML она лучше? Ты тролль что ли?
внезапно да. Мне намного прочще читать xml, чем JSON. Может, дело привычки, не знаю.

Так говоришь, как будто что-то эдакое. Тулзы типа xjc пишутся за неделю.

пока такая тулза одна и аналогов я не знаю даже в других языках.

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

> пока такая тулза одна и аналогов я не знаю даже в других языках

Для Java есть XMLBeans. Для Scala есть scalaxb. Это я ещё даже не гуглил.

pitekantrop ★★★
()
Ответ на: комментарий от JFreeM

Для С++ есть CodeSynthesis XSD. PyXSD для Python. Ещё за тебя погуглить?

Begemoth ★★★★★
()
Ответ на: комментарий от pitekantrop

>> плохая читабельность

У XML она лучше? Ты тролль что ли?

Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

tailgunner ★★★★★
()

А что плохо в XML? Парсится нормально, наверное под любой ЯП есть своя приблуда или встроенный функционал для обработки.

TGZ ★★★★
()
Ответ на: комментарий от tailgunner

> Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

XML более раздут, т.е. для передачи той же информации, как правило, требуется больше текста. Это, в общем случае, читабельности не способствует.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

>> Кстати, у XML с разумной схемой читаемость лучше, чем у любого JSON.

XML более раздут, т.е. для передачи той же информации, как правило, требуется больше текста.

Поэтому я и сказал «для разумной схемы». <elt attr1=foo attr2=bar/> как минимум не хуже {«elt»: { «attr1»: «foo», «attr2»: «bar» }}.

tailgunner ★★★★★
()
Ответ на: комментарий от Karapuz

> И для JSONа такие тулзы есть?

Пёс его знает. Мне пока не надо, т.к. Json-схемы я не использую. Но написать, думаю, не проблема.

У меня сейчас данные простые по структуре и большие по объёму. Так что использую сейчас парсер комбинаторы поверх потокового парсера и потоковый же генератор.

pitekantrop ★★★
()
Ответ на: комментарий от tailgunner

> Поэтому я и сказал «для разумной схемы». <elt attr1=foo attr2=bar/> как минимум не хуже {«elt»: { «attr1»: «foo», «attr2»: «bar» }}.

Это всё так чудненько выглядит, пока у тебя простые текстовые атрибуты. А давай attr1 будет составным, а attr2 - массивом.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

Это всё так чудненько выглядит, пока у тебя простые текстовые атрибуты.

Ну то есть как минимум иногда XML выглядит нормально.

А давай attr1 будет составным, а attr2 - массивом.

Давай.

<elt>
   <attr1 subattr1=foo subattr2=bar/>
   <attr2>0 1 2 3 4 5 6 7</attr2>
</elt>
{ "elt": { "attr1": { "subattr": "foo", "subattr2": "bar" },
           "attr2": [0 1 2 3 4 5 6 7]}}

Разница в читабельности уменьшилась, но она всё равно в пользу XML.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.