xml - не так и страшен :)

← →
12 © (2010-03-29 14:27) [0]

думал все выходные, как бы половчее написать обменник с филиалами

ADODataSet1.SaveToFile("wewewe.xml", pfXML);
ADODataSet2.LoadFromFile("wewewe.xml");

все :)
i love delphi!!

← →
Sergey13 © (2010-03-29 14:42) [1]

А в чем тут ловкость то? ИМХО самое сложное при репликации определить ЧТО отправлять и КАК интерпретировать присланное.
А формат - хоть голубиной почтой.

← →
12 © (2010-03-29 15:04) [2]

согласен. Но такая простота и скорость формирования, и в обе стороны к тому же - впечатлила

← →
test © (2010-03-29 15:12) [3]

12 © (29.03.10 15:04) [2]
Ты просто пока с ошибками не столкнулся.

← →
sniknik © (2010-03-29 15:58) [4]

проблемы не тогда когда пишешь/читаешь одним методом в любом формате (лучше использовать "родной", чтобы не преобразовывать), а тогда когда тебе в этом "универсальном" будет кто то другой данные предоставлять. тогда то то вся "универсальность" и "накроется".

а тут..., например замени pfXML на pfADTG и посмотри изменилась "ловчесть" обменника? а ведь уже не xml... + будет еще размер меньше.

а с другой стороны выгрузи также в xml из клиентского рекордсета, а загрузить попробуй в ado-шный... вот тебе и первая проблема, хотя xml, а толи еще будет когда пойдет обмен между разными участниками...
как говорится "плавали, знаем"...
и все бы ничего, все решается, но только для многих (особенно менеджеров) xml это как панацея, ибо "универсальный!"(произносится с придыханием, а после через паузу "а у вас, что не понимает?"), и хрен объяснишь, что структуру нужно обговаривать в любом случае, что сделанное самопальными парсерами мало кто поймет, что если в заголовке стоит win-1251 а внутри все в неизвестной науке кодировке то это проблема, что размер важен!, что может быть нестандартный указанием в заголовке интерфейса каким его требуется разбирать (тогда необходим еще и сом обьект от него) и т.д. все объяснения разбиваются об "он же универсальный" (универсальность понимают не в том, что на нем многое возможно, а в том что раз на нем значит все могут использовать...)

← →
Медвежонок Пятачок © (2010-03-29 16:05) [5]

что сделанное самопальными парсерами мало кто поймет

яя натурлих.
именно поэтому и XML

← →
Медвежонок Пятачок © (2010-03-29 16:08) [6]

И все таки он универсальный.
потому что:
1. на клиенте (винде) его разобрать можно всегда, ибо парсер есть в голой ОС
2. на SQL сервере его разобрать можно всегда (если в нем есть поддержка типа xml) (настоящие сервера ее имеют)
3. можно создавать herfvb как plain text и читать тоже.

4. куча еще причин по которым он универсальный.

← →
Palladin © (2010-03-29 16:11) [7]

а я вообще за json

← →
Медвежонок Пятачок © (2010-03-29 16:12) [8]

а могу я в оракле иметь таблицу с полем типа json?

фик. не могу. а надо.

← →
Медвежонок Пятачок © (2010-03-29 16:14) [9]

а могу я в голой vs2008 сделать linq запрос к документу json?
нет?
а пачиму?

← →
Медвежонок Пятачок © (2010-03-29 16:16) [10]

а могу я в голом браузере без плугинов открыть файл json в красивой древовидной форме?
нет?
а пачиму?

← →
Медвежонок Пятачок © (2010-03-29 16:18) [11]

а могу я сделать трансформ джейсон документу и получить на выходе rtf,html,txt или другой джейсон?

← →
sniknik © (2010-03-29 16:20) [12]

> яя натурлих.
> именно поэтому и XML
ответственность, и договоренность придерживаться одного формата/использовать только стандартный парсер совершенно не относятся к свойствам формата.

> а пачиму?
мелкософт не его "продвигает"

> а я вообще за json
а я за "родной" формат, т.е. обмен стараться делать на тех данных в которых работаешь, или с минимальными преобразованиями.

← →
sniknik © (2010-03-29 16:22) [13]

> а могу я сделать трансформ джейсон документу и получить на выходе rtf,html,txt или другой джейсон?
ну а кто ж знает твои способности? вообще парсеры/конвертеры подобные есть (для html использовал).

← →
Palladin © (2010-03-29 16:27) [14]

> а могу я в голом браузере без плугинов открыть файл json
> в красивой древовидной форме?

нет, но ты можешь сделать var o = eval(jsonString) и получить готовый объект js

> а могу я в голой vs2008 сделать linq запрос к документу
> json?нет?а пачиму?

если мс это не поддерживает, то нет, а зачем?

> а могу я в оракле иметь таблицу с полем типа json?

а зачем? строки чем не угодили?

> а могу я сделать трансформ джейсон документу и получить
> на выходе rtf,html,txt или другой джейсон?

можешь, но надо написать утилиту

НО, я абсолютно согласен с sniknik"ом, по поводу передачи толп данных в каком либо из описательных форматов, они, описательные форматы, не для того создавались, НО я за использования оных для: хранения опций, обменом небольших пакетов данных, запросов-ответов

просто json мне более симпатичен, приятен для глаза (а для чего еще были созданы описательные форматы как не для глаза)...

← →
Медвежонок Пятачок © (2010-03-29 16:37) [15]

а зачем? строки чем не угодили?

ну вот надо мне.
приходят данные из внешнего мира в виде xml.
я их складирую в поле типа xml.
на худой конец я их помещаю аз из в варчар.

и в обоих случаях я могу средствами родного sql выполнить запрос к этим данным.

← →
Медвежонок Пятачок © (2010-03-29 16:39) [16]

можешь, но надо написать утилиту

а для xml этого не требуется.
или почти не требуется.
точнее не требуется в том объеме в каком это потребуется для json.

в голой ос только что после установки это уже досупно.

зачем мне это надо?

а вот надо.
есть данные.
я к ним могу выполнять запросы.
могу их трансформировать в визуальное или печатное представления и так далее.

и все это с минимальнейшими затратами времени.

← →
Медвежонок Пятачок © (2010-03-29 16:46) [17]

просто json мне более симпатичен, приятен для глаза

Это вообще не аргумент.
Поясняю почему.

Представьте программиста прошлого века (тетеньку например предпенсионного возраста). Она всю жизнь имела дело с дибейсом, а о клиент-серверной технологии не слышала даже.

Тут к ней приходите вы и говорите, что намного круче юзать оракл/мсскл/fb/etc

Она вам говорит: а нука дайте глянуть внутрь ораклового формата. и нажимает ф3 в нортон командере на файле данных оракла.

Ее последующая реакция - это почти дословно ваш аргумент о более симпатичном джейсоне.

Но правда жизни-то в том, что те, кто понимает, тот не жмет ф3 на файле данных оракла.

← →
Palladin © (2010-03-29 17:28) [18]

> Но правда жизни-то в том

вот меня еще жизни неучили, иди поразбирай тонны логов запросов-ответов, да бы найти тот который процессинг отшил.... попросматривай трассировку ajax запросов-ответов веб-приложения... бабка и ф3 тут вообще ни причем...

← →
Palladin © (2010-03-29 17:34) [19]

еще раз повторяю, если бы дело все было в позиционно-независимом хранении, то для чего осмысленные названия тегов? почему бы не использовать бинарный формат ИД-значение? да потому что все для глаз, для того что бы было можно в текстовом редакторе править и просматривать

← →
Медвежонок Пятачок © (2010-03-29 17:42) [20]

Еще раз для тех кто жмет ф3.

Мне вообще по барабану как там внутри хмл представлены данные.
И по барабану текстовые они или бинарные.

По барабану, понимаешь?
Точно так же мне по барабану как устроен физически файл данных оракла.

У меня есть адекватные инструменты для работы с xml и я с ними работаю и инструментов этих - тысячи.

иди поразбирай тонны логов запросов-ответов

И в чем проблема?
Я лет десять как программирую в основном неинтеракитвное ПО, которое генерит логов не меньше чем у тебя.
И проблем не испытывал не разу.

← →
Медвежонок Пятачок © (2010-03-29 17:46) [21]

почему бы не использовать бинарный формат ИД-значение?

странный вопрос.

а почему например утф-8 не сделать бы бинарным?
не круто же.

← →
Медвежонок Пятачок © (2010-03-29 17:56) [22]

> а пачиму?
мелкософт не его "продвигает"

мелкософт не продвигает. замечательно.

А что насчет иных?

Могу я в других браузерах увидеть иерархию джейсона?
Могу я в других скл серверах оперировать типом данных джейсон?

Не могу. Точнее конечно могу, если нагенерю для этого тонны кастомного кода.

Вот и все. Больше ничего и не требуется доказывать.

← →
sniknik © (2010-03-29 18:09) [23]

> Я лет десять как программирую в основном неинтеракитвное ПО, которое генерит логов не меньше чем у тебя.
> И проблем не испытывал не разу.
сколько клиентов тебе присылает данные? не ты, записал/прочитал, а вот по твоему описанию "как надо", тебе присылают в "как хотим".

или мало, или очень везет. формат вообще тут дело десятое... проблемы вызывает не он, а миф о нем. что стоит только перевести на xml и все тебя станут понимать...

ну вот пойми к примеру, почитай "в удобном" виде, и скажи что мно отсюдя в базу сохранять? (я знаю, но ты тоже должен слету прочитать "универсальный", т.к. говориш проблем с ним не имеешь)
<?xml version="1.0" encoding="WINDOWS-1251"?><userinfo><extid>115543709</extid><fio>РљРѕС‰Р°РєРѕРІР° РќР°С‚Р°Р»СЊСЏ РќРёРєРѕР»Р°РµРІРЅР°</fio><doc>78 08662584</doc><phone>9201165114</phone><encdate>hQIOA39DGzuBhmYHEAf/SGoNabl4E0c1ZTyscGE0MrD0WaXWvr1a4+0yhTqqKaxjN2+VgRmim/L/aUesESu1sat3Cn4sl9ih6c8vN27LAhBEPI/O5TvoWKZbTAiYgqSddy4JgGKE1IJ0YBlJexhONiAPU+lj+OeiGN+DG6b77LiQv5CJmptXiuWdotaDHoUzX6gteNuNpTGKIKh3MNzHE1N8CxccBQVy9+yqJ1skpdfL850vYXODw+yRSQLG07fTD3zqR1O2+rjwbQ9Vjn5eSjPphBxGOrpFeRQc5rDspaVUiUV3LN5JO6IKg/5BT9SYHGbBIxoHBD/5tJHYBxaPRRqel7DgVZdKzvXP6EpmKggAgqyAt6mgNVURA1QWBOAKLlbOG7IDv91WPXQR54pleFOhqt8 zsn6C9NBTz+7r6seH8Y2GlRCEApN6kIxiEvuM1Eo6WgrMHt642Yg1ZuTEmAjXipZpMEaNjnXDEM6Vs7Ou59aSlTYPJ5 wj2Ak+G7u+9jutxGRzYokYGUoK0kfYVrOGuQ8qAZWBDztao1xpaQZmOClgmZtOwmCCrYc/PHSjmZgBsQzzL1TOAgSyQ5jSvkLPf0noxfdhAlGDFmjIVCBhCMa6IR5E7LpdYgea2NVZflmAGdBAGhA/CCzLmjioj4CiL7/xeUHR4fgM07VpfYN6wr6Mq2t7Mdqzk2Z7NSFVAqQ2VKeG0gFv/6rdeCdwCzRMLlzM4QsvCw84bbI88Turxg3x7hoh875BYFZLB+0BzMa3jPHboHjC=NJEm</encdate><srvtype>1</srvtype><resp_msg/><reg_dt/><templates><template><templid>mts</templid><paymsum>10000</paymsum><paymsubjtp>115</paymsubjtp><params><param code="307" num="1">9108780689</param></params><status>1</status></template><template><templid>default</templid><paymsum>10000</paymsum><paymsubjtp>111</paymsubjtp><params><param code="150" num="1">9204465164</param></params><status>1</status></template></templates></userinfo>

← →
sniknik © (2010-03-29 18:10) [24]

кстати то что там utf-8 догадаться не так уж и сложно, ты поле encdate расшифруй... что оно значит.

← →
Игорь Шевченко © (2010-03-29 18:15) [25]

sniknik © (29.03.10 18:09) [23]

Мне (точнее, заказчикам) дофига присылают. И что ?

> а миф о нем. что стоит только перевести на xml и все тебя
> станут понимать...

по крайней мере тебя смогут проверить до того, как понять

← →
Медвежонок Пятачок © (2010-03-29 18:21) [26]

<?xml version="1.0" encoding="WINDOWS-1251"?>

1с делает похожие дибейс файлы.
Данные в cp866, а в заголовке написано что анси.
И что дальше?
Скажем фу дибейсу?

← →
Медвежонок Пятачок © (2010-03-29 18:23) [27]

а миф о нем. что стоит только перевести на xml и все тебя станут понимать...

Ну а если все перевести на джейсон, то миф про всеобщее понимание сразу исчезнет? И все всех поймут?

← →
Кщд (2010-03-29 19:35) [28]

json, имхо, более читабелен
опять же, если надо прокачивать большие объемы(солидный объем именно одного сообщения, а не общий трафик, разумеется) - выигрывает - и существенно - по сравнению с XML

но XML - это и валидация(XSD) и интуитивно понятная навигация (XPATH) и преобразования (XSL/XSLT) и - черт возьми - запросы(XQuery)
кроме всего, готовые генераторы классов десериализации - надавил кнопочку и получил готовый класс по схеме
т.е. богатый функционал, масса готовых библиотек
XML давно и по праву стандарт обмена - де факто

> Мне (точнее, заказчикам) дофига присылают. И что ?
тогда скажи мне, что в encdate в примере. ты счас в том же положении/знаешь столько же, сколько я когда мне дали этот формат.
могу чуть чуть приоткрыть больше (чтобы вообще на равных)
это замена обмена который был, и очень хорошо себя чувствовал на dbf-е. замена произошла по "веяниям" всеобщей xml-изации, типа "мы должны использовать!".
и кстати если ты скажешь что там внутри старый dbf то будешь не далек от истины, но не все таки не прав. ну так, чем его заменили?

p.s. я бы не настаивал, но вы же говорите что все там так ясно и прозрачно, стоит только использовать...
а я говорю, что формат вообще не причем, все от сторон договаривающихся/исполняющих зависит.
т.что, доказывайте.

> 1с делает похожие дибейс файлы.
1c делает foxpro файлы, и все там у него правильно.

> И что дальше?
> Скажем фу дибейсу?
скажи фу своему проклевывающемуся ламеризму.

> Ну а если все перевести на джейсон, то миф про всеобщее понимание сразу исчезнет? И все всех поймут?
json никогда не рекламировали как универсальный формат для обмена данными, т.что да, миф исчезнет.
ну, а так как в силу той же рекламы менеджеры знают только про xml... то при любом другом формате они прибегут советоваться со специалистами, перестанут делать "умные" решения договариваясь о получении данных из базы вместо в файле бэкапа, в xml-е.

в общем со своей стороны вижу только плюсы если перейти, но только ты меня не слушал, не на json (json мне нравится, и он удобен когда работаешь с аяксом/в html/+(?), а когда у тебя dbf таблицы то почему ми и и не обмениваться?), а на "родной" формат/близкий к тому на чем работают, хотя бы с одной стороны.

> но XML - это и валидация(XSD)
попробуй "состыковаться" с MTC, формат приема платежей/точек. XSD там есть, и даже вполне себе приличные XSD. но думаешь проблем нет? это один из самых отвратительных форматов с каким сталкивался. (кто делал подтвердите/опровергните)

sniknik © (29.03.10 19:52) [29]

Не совсем понимаю, почему кривые руки ваших поставщиков данных должны как-то сопоставляться с языком ?

> тогда скажи мне, что в encdate в примере. ты счас в том
> же положении/знаешь столько же, сколько я когда мне дали
> этот формат.

Зачем мне чего-то говорить - посмотри в схему, там все написано

> 1с делает похожие дибейс файлы.
1c делает foxpro файлы, и все там у него правильно.

> И что дальше?
> Скажем фу дибейсу?
скажи фу своему проклевывающемуся ламеризму.

Экие мы категоричные.
Ну вот есть разработчик. Делфиец.
Договорились обмениваться дибейсом.
Приходит такой вот "правильный" фокспрошный дибейс.
Внутри у него не написано что он фокспрошный.
Бде в нем видит третий дибейс.
А кодировка раком.

> Не совсем понимаю, почему кривые руки ваших поставщиков данных должны как-то сопоставляться с языком ?
я то их как раз не сопоставляю, почитай тему сначала, я как раз говорил, что сам по себе xml ничего не значит.

> Зачем мне чего-то говорить - посмотри в схему, там все написано
схемы нет. по телефону ответ - бинари дата.
дальше?

хотя все одно не догадаешься, скажу так. там данные из того самого dbf, в текстовой табличке, символами псевдографики, и соответственно OEM (dos) кодировке, которая (чтобы не "ломалась", т.к. там символы вида & присутствуют "завернуты" в подобие base64 (а может в неудавшуюся попытку)). на вопрос зачем такие сложности, был ответ, почти по Пятачку - ну удобно же! (они ее "разворачивают", и как есть подсовывают в какой то печатаемый отчет).

мое удобство реальное.
и оно в том, что обработка может быть как клиентская, так и серверная.
а может вообще никакой обработки не быть а просто сохранение в первозданном виде.
и из этого первозданного вида я могу получить все что хочу (снова как на клиенте так и на сервере)

> что сам по себе xml ничего не значит.
> Договорились обмениваться дибейсом.
а вот договор, и его строгое соблюдение значит.

а xml не люблю только за то, что он позволяет договариваться ничего не понимающим, но возомнившем о себе менеджерам. которые из мифорекламы только и знают "универсальный, все поймут, и нам дайте в нем. неважно что нужно".

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

← →
Кщд (2010-03-29 20:28) [37]

> XSD там есть, и даже вполне себе приличные XSD. но думаешь
> проблем нет? это один из самых отвратительных форматов с
> каким сталкивался. (кто делал подтвердите/опровергните)

сопрягались с агрегаторами услуг - никаких проблем
да и XSD - для валидации, к "читабельности" данных отношения не имеет
по поводу encdate: разве json в этой ситуации чем-то лучше?

← →
Кщд (2010-03-29 20:32) [39]

>Кщд (29.03.10 20:28) [37]
>сопрягались с агрегаторами услуг - никаких проблем
поясню: агрегаторы - это те, кто реально проводит платежи из уличных CashIn-аппаратов: МТС, Билайн, НТВ+ и др.

выгрузи из клиентского, загрузи в адошный.

рисую один xsl и делаю один единственный вызов метода.
на выходе получаю адошный xml.

хотя мне это и не надо.
я исходный клиентский грузану на сервер аз-из и там его вставлю куда мне надо по строчечкам и полочкам

xml - не так и страшен :) Найти похожие ветки