Re: Отправку СМС через VFP | |
---|---|
VeterVFP Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006 |
Да я только рад в таблицу-то сие загнать Добраться бы до этого прекрасного момента только Получается, что указанный выше XML (приходящий от оператора) не соответствует стандарту XML, раз его сходу XMLTOCURSOR() не берет? Как его ? Направьте на верный путь, комрады |
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Нет, это через MSXML2.DOMDocument Я не знаю в каком виде и через что ты получаешь "ответ оператора". Но в том же MSXML2.XMLHTTP объекте помимо .responseText есть и .responseBody где в бинарном виде будет содержимое ответа (без перекодировок), и даже .responseXML - где для XML ответов будет уже объект MSXML2.DOMDocument с загруженным в него и "разобранным" ответом. Твой "текст", если его сохранить в файл в utf8 кодировке и загрузить в парсер вполне себе адекватно разбирается и всё там видно.
XMLTOCURSOR() этот XML напрямую не скушает. Он не в том виде, в каком его ожидает данная функция. Она вообще очень, очень редко когда может скушать "произвольный внешний XML" - вот то что создал CURSORTOXML - другое дело ------------------ WBR, Igor |
Re: Отправку СМС через VFP | |
---|---|
VeterVFP Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006 |
Ессс похоже, то, что надо. Я как раз и получаю ответ через MSXML2.XMLHTTP.6.0! Можно ли в таком случае сразу обратиться через responseXML к узлам (без доп создания loXML = CreateObject("MSXML2.DOMDocument") или придется создавать? Вижу еще такой объект:
|
Re: Отправку СМС через VFP | |
---|---|
Crispy Сообщений: 18571 Дата регистрации: 16.05.2005 |
Дык а в чем проблема-то? Выше я ну разве только код на написал (пара команд), который все это и проделывает. Хотя возможно это уже как бы и не надо теперь. Но тем не менее. ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери) |
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Stream это ссылка на IStream интерфейс (он позволяет читать/писать/перемещаться по произвольному "нечто" аналогично как FREAD/FWRITE/FSEEK в фоксе позволяют читать/писать/перемещаться по открытому для низкоуровневого доступа файлу). Только я не думаю что из фокса это можно будет использовать. Уж точно не напрямую.
Загрузится ли у тебя XML в объект responseXML (да, тогда нет нужды ещё раз создавать MSXML2.DOMDocument и загружать в него данные) я не знаю - это зависит, насколько я знаю, от того какие заголовки в ответе присылает сервер. Если там будет ContentType="text/xml" или некоторые другие поддерживаемые этим парсером, то сам MSXML2.XMLHTTP создаст объект и загрузит в него ответ сервера. 2 Crispy опять плохое советуешь... Нельзя работать с XML как с тривиальным текстом. Это НЕ ПРОСТО текст. А писать свой парсер - да чтобы он хотя бы банально корректно разэкранировал < > & в "текстах", не говоря уж о всяких юникодных символах - это пустая трата времени. ------------------ WBR, Igor |
Re: Отправку СМС через VFP | |
---|---|
Crispy Сообщений: 18571 Дата регистрации: 16.05.2005 |
Дак ты ж САМ только что выше писал совершенно обратное! ;) В смысле, что случай-то оный "не для" как бы. По поводу же "пустой траты времени" - ну тут уж извини, но ты ж больше теоретик (опять таки по твоему признанию). А я практик. Мне главное, чтобы работало. А не чтобы соответствовало постановлениям партии и правительства программирования. И оно таки работает и проблем не имеет, уж не знаю, вопреки или не вопреки уставу партии. И мне как-то все равно, почему так. Если кому понадобится, найдут объяснение. Маркони вон тоже все теоретики убеждали, что КВ-связь через океан принципиально невозможна, что это противно самой теории, смеялись над самими попытками, а он молча увеличивал мощность передатчиков и установил таки стабильную связь через Атлантику. Теоретики несколько лет были в шоке и ходили плакаться друг к другу, жалуясь на него. Пока опять же практики не открыли озоновый слой. Так что, опять позволю себе процитировать из Гете: "Суха теория, мой друг, но вечно зеленеет жизни древо". По поводу же писания парсера - так пишется то всего один(!) раз, да и ничего сложного там нет, и кода совсем немного. А корячиться КАЖДЫЙ РАЗ для ВСЕХ нестандартных случаев с кодом преобразования данных под рекомендованный партией обработчик XML - на мой взгляд, это в гораздо большей степени пустая трата времени. ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери) |
Re: Отправку СМС через VFP | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Штатный виндовый "парсер" (который строит DOM XML-документа) на практике не годится. Он не может обработать 5-10 МБайтный документ, не хватает памяти, или еще чего. Попробуйте открыть большой XML при помощи IE, и все станет понятно. Можно использовать из обработчика "SAX", но тогда проще обойтись вообще без этого виндового парсера. Разобрать на тэги, декодировать - это и на фоксе просто. И об этом "недостатке" уже говорили 100 раз, и все равно - DOM, DOM... Только для учебных целей, построить DOM для маленького XML, типа, как могло бы быть хорошо, если бы это работало в боевых условиях.
|
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Наверное ты что-то не так понял. Я писал что для такого случая не обязательно парится с XMLAdapter и тем паче с "трансформацией" документа в вид пригодный для XMLTOCURSOR. А тривиально 3-мя строками кода вынуть нужные элементы. Напиши свой код и посмотрим сколько строк займёт он - ДАЖЕ без обработки экранированных символов, "разорванных" на несколько строк значений, CDATA и прочего безобразия, с которым справится штатный MSXML парсер. И не просто код засовывающий текст в курсор, где с ним ещё невесть что нужно делать, а именно конкретная задача - получить для приведенного XML значения узлов code, descr, account. У меня это занимает ровно 5 строк кода - а если веб-сервис корректно заголовки ответа прописывает, то ровно 3 строки будет. При том не какие-то мозговыворачивающие SUBSTR+AT+RAT+... выражения. В том то и соль что мой вариант будет гарантированно работать, а твой - ещё бабушка надвое сказала Смотря какой парсер. Даже в примитивном, невалидирующем, не поддерживающем DTD, XPath запросы, схемы, пространства имён и прочие аспекты из многостраничной спецификации XML-я парсере будет не одна сотня строк кода. Банально для корректной реализации разбора этого самого XML-я. Я вот, к примеру, не уверен что ты способен такой парсер написать за разумное время. Я и сам бы не взялся за такое задание на фоксе. И самое главное - зачем изобретать велосипед? Он будет работать быстрее штатного парсера? Нет. Он будет удобнее в использовании? Опять же нет. Так в чём тогда смысл тратить время на него? "Нестандартных" XML не бывает. Т.к. XML это стандарт. И парсер этот стандарт поддерживает в достаточном объёме. Г*но которое какие то идиоты прописали в файл и добавили расширение xml, естественно, XML-ем от этого не становится, и разобрать его ни штатный, ни твой парсер не сможет - без доработки "под это конкретное г*но". Благо сегодня таких клинических случаев практически не встречается - скорее встречается непонимание или неверное использование стандарта - но не явное его нарушение. Код же "преобразования данных" с использованием штатного парсера будет несложным и совершенно прозрачным. Да, в режиме DOM вполне может и такое произойти - но только будет ли у автора темы ТАКОЙ объём данных Не можно, а "нужно". Не проще ни разу. Если же не следовать стандарту "до буквы", то потом придётся плакаться что какие-то злые дядьки вместо пустого <data/> подложили такой же пустой <data></data>, или прописали какие-то "вредные неймспейсы" типа <ns1:data xmlns:ns1="https://www.fruitsandmeat.com/client"> и весь наш гениальнейший парсер полетел ко всем чертям В результате придёт для поддержки какой-то бедолага, который сломав мозг и осыпав проклятиями автора "нетленки", заменит это чудо на тот же самый штатный MSXML парсер - конечно, если вообще оставит реализацию на фоксе ------------------ WBR, Igor |
Re: Отправку СМС через VFP | |
---|---|
VeterVFP Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006 |
Попробовал - все норм получилось - значит данный провайдер вернул мне корректный ответ в
Ну в данном случае, думаю, вряд ли превысит. А если превысит - то будет вылет с ошибкой или "зависон" просто? Олег, это другой режим какой-то? Где почитать? Я так понял, сие нетривиальная задача, раз
|
Re: Отправку СМС через VFP | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Про SAX здесь же и почитать. Игорь где-то и пример приводил (но с IMPLEMENT-ами какими-то, с адскими )
forum.foxclub.ru forum.foxclub.ru Доб. Не про SAX ссылки оказались. У меня записано на них "почитать про SAX"... Вот первое попавшееся обсуждение: forum.foxclub.ru или вот еще forum.foxclub.ru ... Ниче не понятно, одни ссылки. Пример ИК не нашел... Вот! Тут "простенький пример" от Рома, наверное я про него вспомнил: forum.foxclub.ru В идее механизма SAX ничего сложного нет, это то же, что предлагает Crispy. SAX будет по очереди, в порядке текста XML, предлагать программе тэги, и их содержимое, а программа девает их, куда хочет Исправлено 3 раз(а). Последнее : of63, 27.03.17 18:18 |
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Да, он (механизм) простой - парсер просто берёт на себя все нюансы стандарта - разные кодировки, entities, cdata, распознавание атрибут/текстовый узел и т.п. Но реализации на нём основанные сложны (точнее они сложнЕЕ чем DOM-реализации) - т.к. уже от самой этой реализации потребуется "хранение состояние разбора" - грубо говоря, отслеживать в какой ветке "дерева документа" мы находимся в каждый момент времени. Ну совершенно нет. Он предлагает переформатировать слегка XML и надеяться что после APPEND FROM в каждой записи курсора окажется ровно по одному тегу. Как он затем собирается искать в этом курсоре нужные данные, лично для меня - загадка. По крайней мере ничего "тривиального" и "простого" на ум не приходит. Это нужна какая-то state-машина, или тот же SAX подход с "отслеживанием состояния". Смотреть что в одной записи, что в следующей и если "совпало" то брать данные из третьей записи, иначе пропускать записи по хитрому критерию а потом повторить поиск "с начала" Про атрибуты он либо забыл, либо забИл - т.к. его подход их не раскидает по отдельным записям (и потому такие узлы скорее всего не поместятся в 254 символа поля). Про многострояные текстовые значения тоже - он их не склеивает, и значит вынимающий код должен этим как-то озаботится... В общем геморроя я вижу более чем прилично, а пользы мало. P.S. именно поэтому я и предложил ему написать сей "простой код" - хотя-бы для этого примитивнейшего примера XML документа. Надеюсь до передёргиваний типа GO 5 он не дойдёт, т.к. тут уж всем очевидна будет г*нокодистость подхода Даже "тупой в лоб" STREXTRACT() и то не меньше буковок кода потребует, а он ну ОЧЕНЬ неуниверсальный, и для чуть более сложного документа уже совсем не покатит... ------------------ WBR, Igor Исправлено 1 раз(а). Последнее : Igor Korolyov, 27.03.17 18:45 |
Re: Отправку СМС через VFP | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Гемора прилично, но решаемо. В 2 тыс. строк уложилось Про 254 символа - это не суть. Суть... Вот есть некий предварительный парсер, выдает на выходе тэг (то, что в символах <>) или междутэговое содержимое (МТС). МТС после закрывающего тэга считаем мусором. МТС после открывающего - собственно значением тэга. Атрибуты выделяем как часть тэга, после символа пробел, вида атрибут="значение". Тэг и МТС XML-декодируем, и из кодировки тоже декодируем, если надо. Все это просто. Сложность в том, чтобы упростить программу пользователя, и подавать ей не просто тэг, а уже "тэг1.тэг2.тэг3..." т.е. уже собранный полный тэг, и затем по очереди по его атрибуту (как будто они есть МТС), и в конце само МТС. Я еще передаю счетчик тэгов. Это нужно, когда тэги неотличимы, идут пачками, чтобы внешняя прога и счетчиком не занималась...
>Смотреть что в одной записи, что в следующей и если "совпало" то брать данные из третьей записи, иначе пропускать записи по хитрому критерию а потом повторить поиск "с начала" Возвращаться на тэг выше программному автомату не требуется, потому-что... зачем возвращаться, если программа "помнит" предыдущие тэги, собирая их в составной тэг... Сами тэги распознаются банально: |
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Нет, и не проси. Даже читать подобное не стану
Уверен на все 100% что есть неучтённые моменты (кстати, про комментарии я вообще забыл - их тоже не так уж и просто отслеживать - закрывающий --> может быть где угодно "позднее" - а "внутри" полноценный фрагмент с "тегами, нардами и гуриями" - который необходимо пропустить "не разбирая"). И да, это УЖЕ весьма непросто - либо полноценный стек сооружать, либо какой-то "псевдо-стек" расщепляя постоянно "строку с точками" на части - при том что на самом деле учёт namespace-ов не позволяет использовать ни точку, ни слэш в качестве "разделителя уровней". Т.к. data и ns1:data где ns1 это префикс, к примеру, для "https://www.fruitsandmeat.com/client" - а потом внутри него будет ещё какой-нить data но с заданным "дефолтным" namespace-ом к примеру "https://www.bank-of-america.com/account" - и это два совершенно разных data... Да и реализация "простейших" для DOM парсера с поддержкой XPath вещей - например вынуть содержимое всех узлов data с атрибутом author="IK", или вынуть все узлы name независимо от уровня их вложенности - ну я не представляю как такое можно реализовать "элементарно" А без такого - придётся массу "ручного труда" применять - все те ужасные циклы, или вложенные циклы с не менее ужасными проверками... Т.е. я к тому что один лишь "разбор" это только часть работы - потом к результату разбора следует применять "запросы" - а запрос в XML иерархичен по сути, тогда как в курсоре он даже близко не такой... ------------------ WBR, Igor |
Re: Отправку СМС через VFP | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Возможно что-то и "забыл", раз не нарывался. Встречу - учту.
>полноценный стек Это что? Массив - разве не полноценный стек? Даже "строку расщеплять" в фоксе - одно удовольствие, типа ALINES, или GETWORDNUM, или AT/RAT >строку с точками Да, выбрал нехороший символ разделения тегов, но это легко поправимо, не правда ли? >реализация "простейших" для DOM парсера с поддержкой XPath вещей Чего нет, того нет, И БЫТЬ НЕ МОЖЕТ. Вся цель была уйти от DOM, но читать тэги последовательно, бесконечно, не ожидая конца самого первого тега, даже бросив чтение когда надоест, но получив нужные десяток-другой блоков внутренних данных. В процессе чтения, можно складывать каждый тэг+значение в курсор, потом SELECT-ами доставай какие хочешь "например вынуть содержимое всех узлов data с атрибутом author="IK", иерархия в таком курсоре не теряется. При небольшой фантазии можно сохранять, например, не тег целиком, а его составные части в отдельной колонке. Все это можно придумать, чтобы "упростить" SELECT-ы а'ля "XPath вещей", хотя мне не ни разу не было нужно, все извлекается уже из курсора, и извлекаются обычно не "все тэги которые", а количество блоков, сумма в рублях, всякие человеческие функции вобщем. Кстати, можно вобще наполнять принимаемыми тэгами не курсор, а обьект, с практически нужными свойствами-тэгами и значениями - тоже обьектами, с столь "необходимой" иерархией, получится подобие DOM-обьекта. Еще раз повторяю, SAX подход - для простых вещей, для больших файлов с перечислениями несложных обьектов. И без него просто никак не обойтись. Не знаю, почему ты не встречал XML-файлы >5 МБайт, даже 1.5 МБайта (1000 справок 2-НДФЛ) невозможно посмотреть, кроме как блокнотом! Столько мата пропустил от юзеров ) |
Re: Отправку СМС через VFP | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Оффа уже перенял лингвистические конструкции от IK.
|
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
Нет, массив это массив На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать, м.б. для каких-то целей и нечто типа peek(N) - т.е. "почти извлечение, но не убирая данные из стека" - вот тогда и получится абстракция "стек" пригодная для вышеописанных целей. Опять же - "расщеплять строку" это служебное действие для эмуляции поведения стека - push/pop в данном случае. Теряется, в том то и дело. Даже если полноценно сохранить иерархию (id/parent_id) то сам запрос получается сложным и неудобоваримым... Это ж могут понадобиться данные из разных записей - т.е. либо самообъединение, либо UDF пользовать. В общем в курсоре с иерархией работать неудобно. Благо нечасто это нужно. А если перенести всю эту логику "хитрого отбора" в код заполняющий курсор - это, конечно, решит проблему но моментально сделает код неуниверсальным. Боюсь что в этом случае ты получишь ровно ту же самую проблему - дичайшие тормоза и гигантское потребление памяти для многомегабайтных XML-ей. Тут и спора нет ------------------ WBR, Igor |
Re: Отправку СМС через VFP | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
>Нет, массив это массив На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать
Массив - это стек в чистом виде: push: - увеличить размер массива на 1 - в последний элемент положить значение pop: - вернуть значение из последнего элемента - уменьшить размер массива на 1 > [Иерархия при сохранении составного тэга] Теряется, в том то и дело. Не теряется. Но "сам запрос получается сложным и неудобоваримым", а кому сейчас легко? ) |
Re: Отправку СМС через VFP | |
---|---|
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002 |
А стек это таблица, а таблица это файл, а файл это видео, а видео это порно - так что массив это тоже порно Смотря в какую структуру курсора это помещать... Вообще в XML кроме "вложенности" есть ещё и "порядок" - т.е. надо либо нумеровать все такие записи-элементы, либо хранить ссылки на "предыдущий на данном уровне", "следующий на данном уровне" - хотя такого рода связи нужны тоже далеко не всегда. Ну атрибуты неясно как хранить - в одной записи с самим элементом - нереально такое структурировать (а без структурирования придётся извлекать из мемо-поля каждый раз - что не есть быстро). В отдельных записях - значит появляется ещё один тип связи - помимо вложенности и порядка В общем ты меня не убедишь что: 1) это будет быстрее. 2) это будет проще. Ну и да - это надо писать, писать и ещё раз писать. А имеющийся парсер - взял и сразу пользуйся. Хотя в SAX режиме тоже прилично писанины получится... ------------------ WBR, Igor |
© 2000-2024 Fox Club  |