cJSON: Формат полей для вложенных структур

[Игорь Столяров]

всегда можно найти работающий код. А в библиотеках на кларионе

Я Вам больше скажу, и на самом Clarion-е фиг что найдёшь ...
Вся жись - это бесконечный транслейт с каких-нибудь сей, скриптов, бейсиков, запросов и т.д.
Ловите момент и повышайте компетенции, пока автору не надоело отвечать на наши вопросы.

[finsoftrz]

Обобщаете.
У меня пока потребности в json не возникло. Возникнет, буду чесать репу. Сорри, без задних мыслей, я вот подумал, а не получится, как с iqxml? Мож проще для таких дел какой-нибудь pyton вместе со своим софтом подкладывать, где есть все модное и тьма народу работает. Как там бритая девочка в "Миллиарды" говорила, залог успеха в связке pyton и c++.

[Игорь Столяров]

У меня пока потребности в json не возникло

Ну, например, Вы уверенно работает с кассовым оборудованием, в т.ч. АТОЛ10.
А без JSON там все запросы к ФН выполнить нельзя, и весь новый функционал только на JSON ...

я вот подумал, а не получится, как с iqxml

Ничто не вечно. Технологии постоянно на ротации ...
Знаете сколько я потратил времени и сделал тестов, что бы объяснить Роберту Пареси,
что нельзя использовать в качестве служебного код русского символа "р" ? Ого-го !
А сейчас уже даже в совсем старых программах мы давно отказались от iQXml ... Эх !

[finsoftrz]

Перешли на штатный xml? А если завтра потребуется работа с пространством имен, снова все переписывать?

[Игорь Столяров]

Перешли на штатный xml?

Да, все задачи с помощью Юрия (всегда помним !) переписали на штатный XML.
И пардон, но весь Меркурий сделан на пространствах имён и прекрасно работает ...

[finsoftrz]

Ммм... Мы, конечно, отвлекаемся от темы, но в Меркурии никогда не требовалось использование пространства имен. Это в егаис есть, где наименование тегов не фиксированное. Наверно, Вы не поняли, речь про xpath.

Насчет pyton, оно не поддерживает обратную совместимость, актуальные версии не работают на вин7. По json такое впечатление, что пишут кто на что горазд, такой завершенной концепции, как в xml, нет. Мож тоже этот класс погонять...

[Игорь Столяров]

Наверно, Вы не поняли

Наверно. Я считал, что это префиксы перед именами тегов.
Всё. Завязали замыливать тему - здесь ещё много интересных дел намечатется ...

[Игорь Столяров]

Добрый день !

Я обещал пока не плодить пожелания, но проблемные места ведь можно обсудить ?
Мне вообще непонятен смысл экспорта в JSON указателей &= Null ... Простой пример.

Выгрузка списка сотрудников с фотографией и списком средств связи для каждого сотрудника.
Из 500 сотрудников фотки есть пока для 3-х, а контакты для 7-ми.

Но для каждой записи нужно выделять память под строку с фоткой и список, что бы потом это всё подтирать.
И если пустые строки можно убрать из строки выгрузки, то пустые массивы '"NameQueue": []' - нет.
А ведь можно просто не выделять память (не инициализировать указатель) на заведомо отсутствующие
реквизиты и просто не выводить в JSON указатели &= Null ... как-то всё очевидно тогда получается.

Т.е. для тегов указателей с опцией "IsQueue" / "IsStringRef" хочется иметь возможность указывать
дополнение {"IgnoreNull":true} - не выгружать тег если он не инициализирован (его значение = &Null).
Хотя какой смысл вообще в выгрузке тега указателя = &Null ? Ну или выгружать его хотя бы как "NameRef": null ...

Для тегов с опцией "IsQueue" / "Instance" опция {"IgnoreEmpty":true} - не выгружать тег с пустым массивом
если Records(Queue) = 0. Запрещает формирования строки в JSON с пустым массивом: '"NameQueue": []'

Прошу Вас рассмотреть возможность наличия в классе таких возможностей.

[Дед Пахом]

То есть Вы предлагаете добавить возможность не выгружать пустые массивы и объекты:
"array": []
"object": {}

Логично и последовательно. Я добавил 2 опции IgnoreEmptyArray и IgnoreEmptyObject.

[Дед Пахом]

Если вместо 2х правил оставить одно IgnoreEmptyObject (и для [], и для {}), могут ли возникнуть проблемы?

[Игорь Столяров]

Не успел спросить, где можно использовать совместно "IgnoreEmptyArray" и "IgnoreEmptyObject".
Никаких проблем - с одной опцией управления понятней смысл и логика скрытия пустого объекта.

[Дед Пахом]

Я думал о таком сценарии: {name:*, IgnoreEmptyObject: true} (все [] и {}). А я, допустим, хочу оставить в json пустые объекты {}. Тогда для них надо явно прописывать правило {name:<object>, IgnoreEmptyObject: false}, а их может быть много.

[Игорь Столяров]

А я, допустим, хочу оставить в json пустые объекты {}

Гипотетически, наверно, да. Но, в практическом применении:
- либо не нужны любые пустые объекты (и мы одной командой их убираем),
- либо вручную задаём для каждого объекта стратегию его экспорта.
Т.е. любая задача решается ...

[Игорь Столяров]

В текущем релизе "IgnoreEmptyArray" не работает для "name":"*"
Пример:

Код: Выделить всё

Root   &cJson
gPack  Group
GrField  Group
FieldS     Long(0)
FieldL     CString(21)
         end
GrList   Group
Doc1       &Queue
Doc2       &Queue
          end
       end
qDoc1  Queue.
qDoc2  Queue.
  Code
  Root &= json::CreateObject(gPack,,|
           '[{{"name":"*","EmptyString":"ignore","IgnoreZero":true,"IgnoreEmptyObject":true,"IgnoreEmptyArray":true},' & |
            '{{"name":"Doc1","instance":' & Instance(qDoc1,Thread()) & '},' & |
            '{{"name":"Doc2","instance":' & Instance(qDoc2,Thread()) & ',"IgnoreEmptyArray":true}]')
  If Not (Root &= Null)
     json::SaveFile('R:\Test.json',Root.ToUtf8())
     Root.Delete()
  end

Результат:

Код: Выделить всё

{
  "grlist": {
    "doc1": []
  }
}

[Дед Пахом]

Так правила для Doc1 главнее общих правил. Мы это обсуждали.