forum.clarionlife.net

finsoftrz писал(а): 01 Декабрь 2020, 19:54 Посмотрел, понюхал. Супер, спасибо, но нет.

А вот скажите пожалуйста ответ на такой незамысловатый вопрос.
Есть некий обмен с девайсом, сервисом (тот же Veteis.API) в XML.
Причём там 40-50 вариантов типовых ответов (структур данных).
И Вы под каждую будите писать отдельный скрипт, который её парсит ?

Не совсем понимаю вопрос и что предлагается в виде его решения.
В ветисе передается много избыточных значений, которые не используются. Если пытаться все это реализовывать у себя, то будет сизифов труд. Я в этом случае предпочитаю иметь инструмент, позволяющий быстро реализовывать функционал, а дальше реагировать на запросы пользователей.

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

Я спросил потому, что для штатного XML парсера Clarion вполне можно сделать метод,
в который передаётся некий XML файл и очередь (в которой задана структура данных
и наименования тегов). Результат работы такого метода заполненная из XML очередь.
Чем-то похоже на штатный распарс JSON, тоже с оговорками, но в целом универсально.

Что-то опять не понимаю. Я так и делаю. Только в метод класса передается не имя файла и очередь, а наименование якорного узла и очередь. Имя файла передается при инициализации класса.

Наткнулся на статейку https://clarionmag.jira.com/wiki/spaces ... ing+Part+1, там есть о реализации clarion xml API, с использованием C++ либы expat https://libexpat.github.io/

What we sometimes forget is that Clarion itself ships with some extensive XML parsing capabilities. Years ago TopSpeed licensed the CenterPoint XML C++ class library (which is itself, reportedly, built on the open source Expat XML parser) and incorporated a wrapper for that library into the Clarion product line.

Игорь Столяров писал(а): 01 Декабрь 2020, 21:04 Конкретно Ветис.API приведён просто в качестве примера, вряд ли кому-то нужно
распарсивать (да и вообще разбираться) со всеми его структурами данных ...

Я спросил потому, что для штатного XML парсера Clarion вполне можно сделать метод,
в который передаётся некий XML файл и очередь (в которой задана структура данных
и наименования тегов). Результат работы такого метода заполненная из XML очередь.
Чем-то похоже на штатный распарс JSON, тоже с оговорками, но в целом универсально.

По идее - да, придумать некий декларативный язык, описывающий схему преобразования - какой параметр в какое поле очереди укладывается и какой тэг вызывает добавление записи к очереди. Дело хорошее...

В общем, как я понял, стандартный кларионовский парсер использует старую сишную библиотеку, написанную в 90-х, поэтому не поддерживает методы работы с xml, которые появились позже (в частности, xpath). А какие еще проблемы при его использовании? Почему-то, например, Парези и прочие вместо него стали разрабатывать альтернативные решения. Когда-то было обсуждение, я тогда не заострил внимание.

finsoftrz писал(а): 02 Декабрь 2020, 8:33 Почему-то, например, Парези и прочие

Я одно время достаточно живо переписывался с г-ном PARESI, т.к. его парсер имел кучу глюков при работе с русскими
текстами, а сам автор не имел представления о русском языке вообще и кириллице в частности.
Как он объяснял - главное для него скорость распарса. Он заострял внимание, что читает/записывает XML через DOS
драйвер (хотя я тогда ещё делал это через WinAPI в 2 раза быстрее). Ну и достаточно неплохой отладочный сервис,
который конечно намного превосходит Debug штатного парсера (хотя идея та же).

А через что читает штатный? Как я представляю, если сишная библиотека, то через win api. Почему у него через dos драйвер быстрее?
В iqxml, если не ошибаюсь, весь файл заливался в строку, а потом класс по ней лазил. Может, в стандартном какая-то более сложная структура в памяти создается, поэтому медленнее получается. Утечек памяти на больших файлах не наблюдается?

finsoftrz писал(а): 02 Декабрь 2020, 8:33 В общем, как я понял, стандартный кларионовский парсер использует старую сишную библиотеку, написанную в 90-х, поэтому не поддерживает методы работы с xml, которые появились позже (в частности, xpath). А какие еще проблемы при его использовании? Почему-то, например, Парези и прочие вместо него стали разрабатывать альтернативные решения. Когда-то было обсуждение, я тогда не заострил внимание.

Стандартный парсер появился только в CW6, а iqxml - раньше. А последняя версия Expat вышла два месяца назад...

Expat не поддерживает кодировку windows-1251 ( от слова совсем ), а Кларион - UTF-8 ( от того же слова ). Секции CDATA заменяют '<13,10>' на '<10>' . А в остальном, прекрасная маркиза ...

В принципе, шестнадцатеричным редактором можно поправить модуль clacpxml.dll ( например, поменять 'windows-1250' на 'windows-1251'), тогда windows-1251 начинает поддерживаться

Посмотрел свои архивы, первое найденное упоминание относится к 2006 году...

Кстати, да, только в С6. Меня смутило то, что в статье в кларионмаге упоминалось, что topspeed лицензировали сишную библиотеку. А последним продуктом topspeed был С5 в 1999 году. С55 и далее уже под лейбом SV.

Я в прошлый раз так и не добил тему чтения XML средствами Clarion.
Напомните пожалуйста. Как подобный (как часть внизу) XML читается?
В UTF-8 перекодировал.
Грузится, но ListXML.Node.getNodename() возвращает XXXXX вместо русских имен.

Вопрос наверное закрыт... Yufil как то писал ранее:

Yufil писал(а):Правда, есть ещё способ - шестнадцатеричным редактором поправить DLL (делал когда-то) тогда будет работать с кириллицей, но какие-то буквы в тегах не принимаются.