FoxClub Forums > Visual Foxpro, Foxpro for DOS > Отправку СМС через VFP ::

• Войти

Страницы: 1 2 3

Re: Отправку СМС через VFP
VeterVFP Автор Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006	VeterVFP 24.03.17 11:44:21 Crispy Для чего - вначале считывал текст из файла(в FPD это только через цикл после FOPEN, в VFP намного проще) на предмет поиска и замены "><" на ">"+CHR(13)+"<". А затем через APPEND FROM добавлял полученный текст в создаваемую временную таблицу (в VFP опять же можно уже и курсор) с одним символьным полем длиной 254. Да я только рад в таблицу-то сие загнать Добраться бы до этого прекрасного момента только Получается, что указанный выше XML (приходящий от оператора) не соответствует стандарту XML, раз его сходу XMLTOCURSOR() не берет? Как его Igor Korolyov хотя-бы привести к виду поедаемому XMLTOCURSOR()-ом ? Направьте на верный путь, комрады

VeterVFP
Автор

Сообщений: 413
Откуда: Москва
Дата регистрации: 26.12.2006

VeterVFP

24.03.17 11:44:21

Crispy
Для чего - вначале считывал текст из файла(в FPD это только через цикл после FOPEN, в VFP намного проще) на предмет поиска и замены "><" на ">"+CHR(13)+"<".
А затем через APPEND FROM добавлял полученный текст в создаваемую временную таблицу (в VFP опять же можно уже и курсор) с одним символьным полем длиной 254.

Да я только рад в таблицу-то сие загнать

Добраться бы до этого прекрасного момента только

Получается, что указанный выше XML (приходящий от оператора) не соответствует стандарту XML, раз его сходу XMLTOCURSOR() не берет?
Как его

Igor Korolyov
хотя-бы привести к виду поедаемому XMLTOCURSOR()-ом

?
Направьте на верный путь, комрады [sm016]

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 24.03.17 12:56:58 VeterVFP Игорь, а вручную это через STREXTRACT? Нет, это через MSXML2.DOMDocument Я не знаю в каком виде и через что ты получаешь "ответ оператора". Но в том же MSXML2.XMLHTTP объекте помимо .responseText есть и .responseBody где в бинарном виде будет содержимое ответа (без перекодировок), и даже .responseXML - где для XML ответов будет уже объект MSXML2.DOMDocument с загруженным в него и "разобранным" ответом. Твой "текст", если его сохранить в файл в utf8 кодировке и загрузить в парсер вполне себе адекватно разбирается и всё там видно. loXML = CreateObject("MSXML2.DOMDocument") llResult = loXML.load("test.xml") ? loXML.selectSingleNode("/data/code").text ? loXML.selectSingleNode("/data/descr").text Равно как и приведенный "текст XML-я" вполне себе можно загрузить в этот объект - только уже через метод .loadxml(строка_с_xml) - тут кодировка указанная в строке <?xml... будет игнорироваться. Т.е. в XML УЖЕ должен быть "читаемый русский текст". XMLTOCURSOR() этот XML напрямую не скушает. Он не в том виде, в каком его ожидает данная функция. Она вообще очень, очень редко когда может скушать "произвольный внешний XML" - вот то что создал CURSORTOXML - другое дело ------------------ WBR, Igor

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

24.03.17 12:56:58

VeterVFP
Игорь, а вручную это через STREXTRACT?

Нет, это через MSXML2.DOMDocument

Я не знаю в каком виде и через что ты получаешь "ответ оператора". Но в том же MSXML2.XMLHTTP объекте помимо .responseText есть и .responseBody где в бинарном виде будет содержимое ответа (без перекодировок), и даже .responseXML - где для XML ответов будет уже объект MSXML2.DOMDocument с загруженным в него и "разобранным" ответом.
Твой "текст", если его сохранить в файл в utf8 кодировке и загрузить в парсер вполне себе адекватно разбирается и всё там видно.


loXML = CreateObject("MSXML2.DOMDocument") 
llResult = loXML.load("test.xml")
? loXML.selectSingleNode("/data/code").text
? loXML.selectSingleNode("/data/descr").text

Равно как и приведенный "текст XML-я" вполне себе можно загрузить в этот объект - только уже через метод .loadxml(строка_с_xml) - тут кодировка указанная в строке <?xml... будет игнорироваться. Т.е. в XML УЖЕ должен быть "читаемый русский текст".

XMLTOCURSOR() этот XML напрямую не скушает. Он не в том виде, в каком его ожидает данная функция. Она вообще очень, очень редко когда может скушать "произвольный внешний XML" - вот то что создал CURSORTOXML - другое дело

------------------
WBR, Igor

Re: Отправку СМС через VFP
VeterVFP Автор Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006	VeterVFP 24.03.17 14:01:34 Igor Korolyov Но в том же MSXML2.XMLHTTP объекте помимо .responseText есть и .responseBody где в бинарном виде будет содержимое ответа (без перекодировок), и даже .responseXML - где для XML ответов будет уже объект MSXML2.DOMDocument с загруженным в него и "разобранным" ответом. Твой "текст", если его сохранить в файл в utf8 кодировке и загрузить в парсер вполне себе адекватно разбирается и всё там видно. loXML = CreateObject("MSXML2.DOMDocument") llResult = loXML.load("test.xml") ? loXML.selectSingleNode("/data/code").text ? loXML.selectSingleNode("/data/descr").text Ессс похоже, то, что надо. Я как раз и получаю ответ через MSXML2.XMLHTTP.6.0! Можно ли в таком случае сразу обратиться через responseXML к узлам (без доп создания loXML = CreateObject("MSXML2.DOMDocument") или придется создавать? Вижу еще такой объект: oXMLHTTP.responseStream Но через дебагер не вижу свойств у него. Это чем то поможет для разбора?

Re: Отправку СМС через VFP

VeterVFP
Автор

Сообщений: 413
Откуда: Москва
Дата регистрации: 26.12.2006

VeterVFP

24.03.17 14:01:34

Igor Korolyov
Но в том же MSXML2.XMLHTTP объекте помимо .responseText есть и .responseBody где в бинарном виде будет содержимое ответа (без перекодировок), и даже .responseXML - где для XML ответов будет уже объект MSXML2.DOMDocument с загруженным в него и "разобранным" ответом.
Твой "текст", если его сохранить в файл в utf8 кодировке и загрузить в парсер вполне себе адекватно разбирается и всё там видно.

loXML = CreateObject("MSXML2.DOMDocument")
llResult = loXML.load("test.xml")
? loXML.selectSingleNode("/data/code").text
? loXML.selectSingleNode("/data/descr").text

Ессс

похоже, то, что надо.
Я как раз и получаю ответ через MSXML2.XMLHTTP.6.0!
Можно ли в таком случае сразу обратиться через responseXML к узлам (без доп создания loXML = CreateObject("MSXML2.DOMDocument") или придется создавать?
Вижу еще такой объект:


oXMLHTTP.responseStream

Но через дебагер не вижу свойств у него. Это чем то поможет для разбора?

Re: Отправку СМС через VFP
Crispy Сообщений: 18571 Дата регистрации: 16.05.2005	Crispy 24.03.17 14:19:14 VeterVFP а я только рад в таблицу-то сие загнать Добраться бы до этого прекрасного момента только Дык а в чем проблема-то? Выше я ну разве только код на написал (пара команд), который все это и проделывает. Хотя возможно это уже как бы и не надо теперь. Но тем не менее. ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери)

Re: Отправку СМС через VFP

Crispy

Сообщений: 18571
Дата регистрации: 16.05.2005

Crispy

24.03.17 14:19:14

VeterVFP
а я только рад в таблицу-то сие загнать Добраться бы до этого прекрасного момента только

Дык а в чем проблема-то?

Выше я ну разве только код на написал (пара команд), который все это и проделывает.

Хотя возможно это уже как бы и не надо теперь.

Но тем не менее.

------------------
В действительности все иначе, чем на самом деле.
(Антуан де Сент-Экзюпери)

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 24.03.17 16:24:48 Stream это ссылка на IStream интерфейс (он позволяет читать/писать/перемещаться по произвольному "нечто" аналогично как FREAD/FWRITE/FSEEK в фоксе позволяют читать/писать/перемещаться по открытому для низкоуровневого доступа файлу). Только я не думаю что из фокса это можно будет использовать. Уж точно не напрямую. Загрузится ли у тебя XML в объект responseXML (да, тогда нет нужды ещё раз создавать MSXML2.DOMDocument и загружать в него данные) я не знаю - это зависит, насколько я знаю, от того какие заголовки в ответе присылает сервер. Если там будет ContentType="text/xml" или некоторые другие поддерживаемые этим парсером, то сам MSXML2.XMLHTTP создаст объект и загрузит в него ответ сервера. 2 Crispy опять плохое советуешь... Нельзя работать с XML как с тривиальным текстом. Это НЕ ПРОСТО текст. А писать свой парсер - да чтобы он хотя бы банально корректно разэкранировал < > & в "текстах", не говоря уж о всяких юникодных символах - это пустая трата времени. ------------------ WBR, Igor

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

24.03.17 16:24:48

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	Crispy 27.03.17 08:24:56 Igor Korolyov опять плохое советуешь... Нельзя работать с XML как с тривиальным текстом. Это НЕ ПРОСТО текст. А писать свой парсер - да чтобы он хотя бы банально корректно разэкранировал < > & в "текстах", не говоря уж о всяких юникодных символах - это пустая трата времени. Дак ты ж САМ только что выше писал совершенно обратное! ;) В смысле, что случай-то оный "не для" как бы. По поводу же "пустой траты времени" - ну тут уж извини, но ты ж больше теоретик (опять таки по твоему признанию). А я практик. Мне главное, чтобы работало. А не чтобы соответствовало постановлениям партии и правительства программирования. И оно таки работает и проблем не имеет, уж не знаю, вопреки или не вопреки уставу партии. И мне как-то все равно, почему так. Если кому понадобится, найдут объяснение. Маркони вон тоже все теоретики убеждали, что КВ-связь через океан принципиально невозможна, что это противно самой теории, смеялись над самими попытками, а он молча увеличивал мощность передатчиков и установил таки стабильную связь через Атлантику. Теоретики несколько лет были в шоке и ходили плакаться друг к другу, жалуясь на него. Пока опять же практики не открыли озоновый слой. Так что, опять позволю себе процитировать из Гете: "Суха теория, мой друг, но вечно зеленеет жизни древо". По поводу же писания парсера - так пишется то всего один(!) раз, да и ничего сложного там нет, и кода совсем немного. А корячиться КАЖДЫЙ РАЗ для ВСЕХ нестандартных случаев с кодом преобразования данных под рекомендованный партией обработчик XML - на мой взгляд, это в гораздо большей степени пустая трата времени. ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери)

Re: Отправку СМС через VFP

Crispy

Сообщений: 18571
Дата регистрации: 16.05.2005

Crispy

27.03.17 08:24:56

Igor Korolyov
опять плохое советуешь... Нельзя работать с XML как с тривиальным текстом. Это НЕ ПРОСТО текст. А писать свой парсер - да чтобы он хотя бы банально корректно разэкранировал < > & в "текстах", не говоря уж о всяких юникодных символах - это пустая трата времени.

Дак ты ж САМ только что выше писал совершенно обратное! ;) В смысле, что случай-то оный "не для" как бы.

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

И оно таки работает и проблем не имеет, уж не знаю, вопреки или не вопреки уставу партии. И мне как-то все равно, почему так. Если кому понадобится, найдут объяснение.
Маркони вон тоже все теоретики убеждали, что КВ-связь через океан принципиально невозможна, что это противно самой теории, смеялись над самими попытками, а он молча увеличивал мощность передатчиков и установил таки стабильную связь через Атлантику. Теоретики несколько лет были в шоке и ходили плакаться друг к другу, жалуясь на него. Пока опять же практики не открыли озоновый слой.
Так что, опять позволю себе процитировать из Гете: "Суха теория, мой друг, но вечно зеленеет жизни древо". [sm128]

По поводу же писания парсера - так пишется то всего один(!) раз, да и ничего сложного там нет, и кода совсем немного. А корячиться КАЖДЫЙ РАЗ для ВСЕХ нестандартных случаев с кодом преобразования данных под рекомендованный партией обработчик XML - на мой взгляд, это в гораздо большей степени пустая трата времени.

------------------
В действительности все иначе, чем на самом деле.
(Антуан де Сент-Экзюпери)

Re: Отправку СМС через VFP
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 27.03.17 09:11:32 Штатный виндовый "парсер" (который строит DOM XML-документа) на практике не годится. Он не может обработать 5-10 МБайтный документ, не хватает памяти, или еще чего. Попробуйте открыть большой XML при помощи IE, и все станет понятно. Можно использовать из обработчика "SAX", но тогда проще обойтись вообще без этого виндового парсера. Разобрать на тэги, декодировать - это и на фоксе просто. И об этом "недостатке" уже говорили 100 раз, и все равно - DOM, DOM... Только для учебных целей, построить DOM для маленького XML, типа, как могло бы быть хорошо, если бы это работало в боевых условиях.

Re: Отправку СМС через VFP

of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

27.03.17 09:11:32

Штатный виндовый "парсер" (который строит DOM XML-документа) на практике не годится. Он не может обработать 5-10 МБайтный документ, не хватает памяти, или еще чего. Попробуйте открыть большой XML при помощи IE, и все станет понятно. Можно использовать из обработчика "SAX", но тогда проще обойтись вообще без этого виндового парсера. Разобрать на тэги, декодировать - это и на фоксе просто. И об этом "недостатке" уже говорили 100 раз, и все равно - DOM, DOM... Только для учебных целей, построить DOM для маленького XML, типа, как могло бы быть хорошо, если бы это работало в боевых условиях.

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 27.03.17 13:57:44 Crispy Дак ты ж САМ только что выше писал совершенно обратное! Наверное ты что-то не так понял. Я писал что для такого случая не обязательно парится с XMLAdapter и тем паче с "трансформацией" документа в вид пригодный для XMLTOCURSOR. А тривиально 3-мя строками кода вынуть нужные элементы. Напиши свой код и посмотрим сколько строк займёт он - ДАЖЕ без обработки экранированных символов, "разорванных" на несколько строк значений, CDATA и прочего безобразия, с которым справится штатный MSXML парсер. И не просто код засовывающий текст в курсор, где с ним ещё невесть что нужно делать, а именно конкретная задача - получить для приведенного XML значения узлов code, descr, account. У меня это занимает ровно 5 строк кода - а если веб-сервис корректно заголовки ответа прописывает, то ровно 3 строки будет. При том не какие-то мозговыворачивающие SUBSTR+AT+RAT+... выражения. Crispy А я практик. Мне главное, чтобы работало. В том то и соль что мой вариант будет гарантированно работать, а твой - ещё бабушка надвое сказала Crispy По поводу же писания парсера - так пишется то всего один(!) раз, да и ничего сложного там нет, и кода совсем немного. Смотря какой парсер. Даже в примитивном, невалидирующем, не поддерживающем DTD, XPath запросы, схемы, пространства имён и прочие аспекты из многостраничной спецификации XML-я парсере будет не одна сотня строк кода. Банально для корректной реализации разбора этого самого XML-я. Я вот, к примеру, не уверен что ты способен такой парсер написать за разумное время. Я и сам бы не взялся за такое задание на фоксе. И самое главное - зачем изобретать велосипед? Он будет работать быстрее штатного парсера? Нет. Он будет удобнее в использовании? Опять же нет. Так в чём тогда смысл тратить время на него? Crispy А корячиться КАЖДЫЙ РАЗ для ВСЕХ нестандартных случаев с кодом преобразования данных под рекомендованный партией обработчик XML - на мой взгляд, это в гораздо большей степени пустая трата времени. "Нестандартных" XML не бывает. Т.к. XML это стандарт. И парсер этот стандарт поддерживает в достаточном объёме. Гно которое какие то идиоты прописали в файл и добавили расширение xml, естественно, XML-ем от этого не становится, и разобрать его ни штатный, ни твой парсер не сможет - без доработки "под это конкретное гно". Благо сегодня таких клинических случаев практически не встречается - скорее встречается непонимание или неверное использование стандарта - но не явное его нарушение. Код же "преобразования данных" с использованием штатного парсера будет несложным и совершенно прозрачным. of63 Он не может обработать 5-10 МБайтный документ Да, в режиме DOM вполне может и такое произойти - но только будет ли у автора темы ТАКОЙ объём данных of63 Можно использовать из обработчика "SAX", но тогда проще обойтись вообще без этого виндового парсера. Разобрать на тэги, декодировать - это и на фоксе просто. Не можно, а "нужно". Не проще ни разу. Если же не следовать стандарту "до буквы", то потом придётся плакаться что какие-то злые дядьки вместо пустого <data/> подложили такой же пустой <data></data>, или прописали какие-то "вредные неймспейсы" типа <ns1:data xmlns:ns1="https://www.fruitsandmeat.com/client"> и весь наш гениальнейший парсер полетел ко всем чертям В результате придёт для поддержки какой-то бедолага, который сломав мозг и осыпав проклятиями автора "нетленки", заменит это чудо на тот же самый штатный MSXML парсер - конечно, если вообще оставит реализацию на фоксе ------------------ WBR, Igor

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

27.03.17 13:57:44

Crispy
Дак ты ж САМ только что выше писал совершенно обратное!

Наверное ты что-то не так понял.
Я писал что для такого случая не обязательно парится с XMLAdapter и тем паче с "трансформацией" документа в вид пригодный для XMLTOCURSOR. А тривиально 3-мя строками кода вынуть нужные элементы.
Напиши свой код и посмотрим сколько строк займёт он - ДАЖЕ без обработки экранированных символов, "разорванных" на несколько строк значений, CDATA и прочего безобразия, с которым справится штатный MSXML парсер.
И не просто код засовывающий текст в курсор, где с ним ещё невесть что нужно делать, а именно конкретная задача - получить для приведенного XML значения узлов code, descr, account. У меня это занимает ровно 5 строк кода - а если веб-сервис корректно заголовки ответа прописывает, то ровно 3 строки будет. При том не какие-то мозговыворачивающие SUBSTR+AT+RAT+... выражения.

Crispy
А я практик. Мне главное, чтобы работало.

В том то и соль что мой вариант будет гарантированно работать, а твой - ещё бабушка надвое сказала

Crispy
По поводу же писания парсера - так пишется то всего один(!) раз, да и ничего сложного там нет, и кода совсем немного.

Смотря какой парсер. Даже в примитивном, невалидирующем, не поддерживающем DTD, XPath запросы, схемы, пространства имён и прочие аспекты из многостраничной спецификации XML-я парсере будет не одна сотня строк кода. Банально для корректной реализации разбора этого самого XML-я.
Я вот, к примеру, не уверен что ты способен такой парсер написать за разумное время. Я и сам бы не взялся за такое задание на фоксе. И самое главное - зачем изобретать велосипед? Он будет работать быстрее штатного парсера? Нет. Он будет удобнее в использовании? Опять же нет. Так в чём тогда смысл тратить время на него?

Crispy
А корячиться КАЖДЫЙ РАЗ для ВСЕХ нестандартных случаев с кодом преобразования данных под рекомендованный партией обработчик XML - на мой взгляд, это в гораздо большей степени пустая трата времени.

"Нестандартных" XML не бывает. Т.к. XML это стандарт. И парсер этот стандарт поддерживает в достаточном объёме.
Г*но которое какие то идиоты прописали в файл и добавили расширение xml, естественно, XML-ем от этого не становится, и разобрать его ни штатный, ни твой парсер не сможет - без доработки "под это конкретное г*но". Благо сегодня таких клинических случаев практически не встречается - скорее встречается непонимание или неверное использование стандарта - но не явное его нарушение.
Код же "преобразования данных" с использованием штатного парсера будет несложным и совершенно прозрачным.

of63
Он не может обработать 5-10 МБайтный документ

Да, в режиме DOM вполне может и такое произойти - но только будет ли у автора темы ТАКОЙ объём данных

of63
Можно использовать из обработчика "SAX", но тогда проще обойтись вообще без этого виндового парсера. Разобрать на тэги, декодировать - это и на фоксе просто.

Не можно, а "нужно".
Не проще ни разу. Если же не следовать стандарту "до буквы", то потом придётся плакаться что какие-то злые дядьки вместо пустого <data/> подложили такой же пустой <data></data>, или прописали какие-то "вредные неймспейсы" типа <ns1:data xmlns:ns1="https://www.fruitsandmeat.com/client"> и весь наш гениальнейший парсер полетел ко всем чертям

В результате придёт для поддержки какой-то бедолага, который сломав мозг и осыпав проклятиями автора "нетленки", заменит это чудо на тот же самый штатный MSXML парсер - конечно, если вообще оставит реализацию на фоксе

------------------
WBR, Igor

Re: Отправку СМС через VFP
VeterVFP Автор Сообщений: 413 Откуда: Москва Дата регистрации: 26.12.2006	VeterVFP 27.03.17 14:33:31 Igor Korolyov Загрузится ли у тебя XML в объект responseXML (да, тогда нет нужды ещё раз создавать MSXML2.DOMDocument и загружать в него данные) я не знаю - это зависит, насколько я знаю, от того какие заголовки в ответе присылает сервер. Если там будет ContentType="text/xml" или некоторые другие поддерживаемые этим парсером, то сам MSXML2.XMLHTTP создаст объект и загрузит в него ответ сервера. Попробовал - все норм получилось - значит данный провайдер вернул мне корректный ответ в loXML= oXMLHTTP.responseXML Спасибо, Игорь! Igor Korolyov of63 Он не может обработать 5-10 МБайтный документ Да, в режиме DOM вполне может и такое произойти - но только будет ли у автора темы ТАКОЙ объём данных Ну в данном случае, думаю, вряд ли превысит. А если превысит - то будет вылет с ошибкой или "зависон" просто? of63 Можно использовать из обработчика "SAX" Олег, это другой режим какой-то? Где почитать? Я так понял, сие нетривиальная задача, раз of63 "тогда проще обойтись вообще без этого виндового парсера."

Re: Отправку СМС через VFP

VeterVFP
Автор

Сообщений: 413
Откуда: Москва
Дата регистрации: 26.12.2006

VeterVFP

27.03.17 14:33:31

Igor Korolyov
Загрузится ли у тебя XML в объект responseXML (да, тогда нет нужды ещё раз создавать MSXML2.DOMDocument и загружать в него данные) я не знаю - это зависит, насколько я знаю, от того какие заголовки в ответе присылает сервер. Если там будет ContentType="text/xml" или некоторые другие поддерживаемые этим парсером, то сам MSXML2.XMLHTTP создаст объект и загрузит в него ответ сервера.

Попробовал - все норм получилось - значит данный провайдер вернул мне корректный ответ в


loXML= oXMLHTTP.responseXML

Спасибо, Игорь!

Igor Korolyov
of63
Он не может обработать 5-10 МБайтный документ
Да, в режиме DOM вполне может и такое произойти - но только будет ли у автора темы ТАКОЙ объём данных

Ну в данном случае, думаю, вряд ли превысит. А если превысит - то будет вылет с ошибкой или "зависон" просто? :al:

of63
Можно использовать из обработчика "SAX"

Олег, это другой режим какой-то? Где почитать? Я так понял, сие нетривиальная задача, раз

of63
"тогда проще обойтись вообще без этого виндового парсера."

Re: Отправку СМС через VFP
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 27.03.17 14:49:17 Про 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

of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

27.03.17 14:49:17

Про 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	Igor Korolyov 27.03.17 18:41:09 of63 В идее механизма SAX ничего сложного нет Да, он (механизм) простой - парсер просто берёт на себя все нюансы стандарта - разные кодировки, entities, cdata, распознавание атрибут/текстовый узел и т.п. Но реализации на нём основанные сложны (точнее они сложнЕЕ чем DOM-реализации) - т.к. уже от самой этой реализации потребуется "хранение состояние разбора" - грубо говоря, отслеживать в какой ветке "дерева документа" мы находимся в каждый момент времени. of63 это то же, что предлагает Crispy Ну совершенно нет. Он предлагает переформатировать слегка XML и надеяться что после APPEND FROM в каждой записи курсора окажется ровно по одному тегу. Как он затем собирается искать в этом курсоре нужные данные, лично для меня - загадка. По крайней мере ничего "тривиального" и "простого" на ум не приходит. Это нужна какая-то state-машина, или тот же SAX подход с "отслеживанием состояния". Смотреть что в одной записи, что в следующей и если "совпало" то брать данные из третьей записи, иначе пропускать записи по хитрому критерию а потом повторить поиск "с начала" Про атрибуты он либо забыл, либо забИл - т.к. его подход их не раскидает по отдельным записям (и потому такие узлы скорее всего не поместятся в 254 символа поля). Про многострояные текстовые значения тоже - он их не склеивает, и значит вынимающий код должен этим как-то озаботится... В общем геморроя я вижу более чем прилично, а пользы мало. P.S. именно поэтому я и предложил ему написать сей "простой код" - хотя-бы для этого примитивнейшего примера XML документа. Надеюсь до передёргиваний типа GO 5 он не дойдёт, т.к. тут уж всем очевидна будет гнокодистость подхода Даже "тупой в лоб" STREXTRACT() и то не меньше буковок кода потребует, а он ну ОЧЕНЬ неуниверсальный, и для чуть более сложного документа уже совсем не покатит... ------------------ WBR, Igor Исправлено 1 раз(а). Последнее : Igor Korolyov, 27.03.17 18:45*

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

27.03.17 18:41:09

of63
В идее механизма SAX ничего сложного нет

Да, он (механизм) простой - парсер просто берёт на себя все нюансы стандарта - разные кодировки, entities, cdata, распознавание атрибут/текстовый узел и т.п.
Но реализации на нём основанные сложны (точнее они сложнЕЕ чем DOM-реализации) - т.к. уже от самой этой реализации потребуется "хранение состояние разбора" - грубо говоря, отслеживать в какой ветке "дерева документа" мы находимся в каждый момент времени.

of63
это то же, что предлагает Crispy

Ну совершенно нет. Он предлагает переформатировать слегка 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	of63 27.03.17 19:03:06 Гемора прилично, но решаемо. В 2 тыс. строк уложилось Про 254 символа - это не суть. Суть... Вот есть некий предварительный парсер, выдает на выходе тэг (то, что в символах <>) или междутэговое содержимое (МТС). МТС после закрывающего тэга считаем мусором. МТС после открывающего - собственно значением тэга. Атрибуты выделяем как часть тэга, после символа пробел, вида атрибут="значение". Тэг и МТС XML-декодируем, и из кодировки тоже декодируем, если надо. Все это просто. Сложность в том, чтобы упростить программу пользователя, и подавать ей не просто тэг, а уже "тэг1.тэг2.тэг3..." т.е. уже собранный полный тэг, и затем по очереди по его атрибуту (как будто они есть МТС), и в конце само МТС. Я еще передаю счетчик тэгов. Это нужно, когда тэги неотличимы, идут пачками, чтобы внешняя прога и счетчиком не занималась... >Смотреть что в одной записи, что в следующей и если "совпало" то брать данные из третьей записи, иначе пропускать записи по хитрому критерию а потом повторить поиск "с начала" Возвращаться на тэг выше программному автомату не требуется, потому-что... зачем возвращаться, если программа "помнит" предыдущие тэги, собирая их в составной тэг... Сами тэги распознаются банально: Часть текста скрыта Закрыть

Re: Отправку СМС через VFP

of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

27.03.17 19:03:06

Гемора прилично, но решаемо. В 2 тыс. строк уложилось

Про 254 символа - это не суть. Суть... Вот есть некий предварительный парсер, выдает на выходе тэг (то, что в символах <>) или междутэговое содержимое (МТС). МТС после закрывающего тэга считаем мусором. МТС после открывающего - собственно значением тэга. Атрибуты выделяем как часть тэга, после символа пробел, вида атрибут="значение". Тэг и МТС XML-декодируем, и из кодировки тоже декодируем, если надо. Все это просто. Сложность в том, чтобы упростить программу пользователя, и подавать ей не просто тэг, а уже "тэг1.тэг2.тэг3..." т.е. уже собранный полный тэг, и затем по очереди по его атрибуту (как будто они есть МТС), и в конце само МТС. Я еще передаю счетчик тэгов. Это нужно, когда тэги неотличимы, идут пачками, чтобы внешняя прога и счетчиком не занималась...

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

Сами тэги распознаются банально:

Часть текста скрыта

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 27.03.17 23:05:31 Нет, и не проси. Даже читать подобное не стану Уверен на все 100% что есть неучтённые моменты (кстати, про комментарии я вообще забыл - их тоже не так уж и просто отслеживать - закрывающий --> может быть где угодно "позднее" - а "внутри" полноценный фрагмент с "тегами, нардами и гуриями" - который необходимо пропустить "не разбирая"). И да, of63 программа "помнит" предыдущие тэги, собирая их в составной тэг это УЖЕ весьма непросто - либо полноценный стек сооружать, либо какой-то "псевдо-стек" расщепляя постоянно "строку с точками" на части - при том что на самом деле учёт 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

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

27.03.17 23:05:31

Нет, и не проси. Даже читать подобное не стану

Уверен на все 100% что есть неучтённые моменты (кстати, про комментарии я вообще забыл - их тоже не так уж и просто отслеживать - закрывающий --> может быть где угодно "позднее" - а "внутри" полноценный фрагмент с "тегами, нардами и гуриями" - который необходимо пропустить "не разбирая").
И да,

of63
программа "помнит" предыдущие тэги, собирая их в составной тэг

это УЖЕ весьма непросто - либо полноценный стек сооружать, либо какой-то "псевдо-стек" расщепляя постоянно "строку с точками" на части - при том что на самом деле учёт 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	of63 28.03.17 08:12:18 Возможно что-то и "забыл", раз не нарывался. Встречу - учту. >полноценный стек Это что? Массив - разве не полноценный стек? Даже "строку расщеплять" в фоксе - одно удовольствие, типа ALINES, или GETWORDNUM, или AT/RAT >строку с точками Да, выбрал нехороший символ разделения тегов, но это легко поправимо, не правда ли? >реализация "простейших" для DOM парсера с поддержкой XPath вещей Чего нет, того нет, И БЫТЬ НЕ МОЖЕТ. Вся цель была уйти от DOM, но читать тэги последовательно, бесконечно, не ожидая конца самого первого тега, даже бросив чтение когда надоест, но получив нужные десяток-другой блоков внутренних данных. В процессе чтения, можно складывать каждый тэг+значение в курсор, потом SELECT-ами доставай какие хочешь "например вынуть содержимое всех узлов data с атрибутом author="IK", иерархия в таком курсоре не теряется. При небольшой фантазии можно сохранять, например, не тег целиком, а его составные части в отдельной колонке. Все это можно придумать, чтобы "упростить" SELECT-ы а'ля "XPath вещей", хотя мне не ни разу не было нужно, все извлекается уже из курсора, и извлекаются обычно не "все тэги которые", а количество блоков, сумма в рублях, всякие человеческие функции вобщем. Кстати, можно вобще наполнять принимаемыми тэгами не курсор, а обьект, с практически нужными свойствами-тэгами и значениями - тоже обьектами, с столь "необходимой" иерархией, получится подобие DOM-обьекта. Еще раз повторяю, SAX подход - для простых вещей, для больших файлов с перечислениями несложных обьектов. И без него просто никак не обойтись. Не знаю, почему ты не встречал XML-файлы >5 МБайт, даже 1.5 МБайта (1000 справок 2-НДФЛ) невозможно посмотреть, кроме как блокнотом! Столько мата пропустил от юзеров )

Re: Отправку СМС через VFP

of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

28.03.17 08:12:18

Возможно что-то и "забыл", раз не нарывался. Встречу - учту.

>полноценный стек
Это что? Массив - разве не полноценный стек? Даже "строку расщеплять" в фоксе - одно удовольствие, типа 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	Simple777 28.03.17 08:22:50 Оффа уже перенял лингвистические конструкции от IK.

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 28.03.17 14:28:04 of63 >полноценный стек Это что? Массив - разве не полноценный стек? Нет, массив это массив На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать, м.б. для каких-то целей и нечто типа peek(N) - т.е. "почти извлечение, но не убирая данные из стека" - вот тогда и получится абстракция "стек" пригодная для вышеописанных целей. of63 Даже "строку расщеплять" в фоксе - одно удовольствие, типа ALINES, или GETWORDNUM, или AT/RAT Опять же - "расщеплять строку" это служебное действие для эмуляции поведения стека - push/pop в данном случае. of63 В процессе чтения, можно складывать каждый тэг+значение в курсор, потом SELECT-ами доставай какие хочешь "например вынуть содержимое всех узлов data с атрибутом author="IK", иерархия в таком курсоре не теряется. Теряется, в том то и дело. Даже если полноценно сохранить иерархию (id/parent_id) то сам запрос получается сложным и неудобоваримым... Это ж могут понадобиться данные из разных записей - т.е. либо самообъединение, либо UDF пользовать. В общем в курсоре с иерархией работать неудобно. Благо нечасто это нужно. А если перенести всю эту логику "хитрого отбора" в код заполняющий курсор - это, конечно, решит проблему но моментально сделает код неуниверсальным. of63 Кстати, можно вобще наполнять принимаемыми тэгами не курсор, а обьект, с практически нужными свойствами-тэгами и значениями - тоже обьектами, с столь "необходимой" иерархией, получится подобие DOM-обьекта. Боюсь что в этом случае ты получишь ровно ту же самую проблему - дичайшие тормоза и гигантское потребление памяти для многомегабайтных XML-ей. of63 SAX подход - для простых вещей, для больших файлов с перечислениями несложных обьектов. Тут и спора нет ------------------ WBR, Igor

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

28.03.17 14:28:04

of63
>полноценный стек
Это что? Массив - разве не полноценный стек?

Нет, массив это массив

На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать, м.б. для каких-то целей и нечто типа peek(N) - т.е. "почти извлечение, но не убирая данные из стека" - вот тогда и получится абстракция "стек" пригодная для вышеописанных целей.

of63
Даже "строку расщеплять" в фоксе - одно удовольствие, типа ALINES, или GETWORDNUM, или AT/RAT

Опять же - "расщеплять строку" это служебное действие для эмуляции поведения стека - push/pop в данном случае.

of63
В процессе чтения, можно складывать каждый тэг+значение в курсор, потом SELECT-ами доставай какие хочешь "например вынуть содержимое всех узлов data с атрибутом author="IK", иерархия в таком курсоре не теряется.

Теряется, в том то и дело. Даже если полноценно сохранить иерархию (id/parent_id) то сам запрос получается сложным и неудобоваримым... Это ж могут понадобиться данные из разных записей - т.е. либо самообъединение, либо UDF пользовать. В общем в курсоре с иерархией работать неудобно. Благо нечасто это нужно. А если перенести всю эту логику "хитрого отбора" в код заполняющий курсор - это, конечно, решит проблему но моментально сделает код неуниверсальным.

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

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

of63
SAX подход - для простых вещей, для больших файлов с перечислениями несложных обьектов.

Тут и спора нет

------------------
WBR, Igor

Re: Отправку СМС через VFP
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 29.03.17 08:44:09 >Нет, массив это массив На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать Массив - это стек в чистом виде: push: - увеличить размер массива на 1 - в последний элемент положить значение pop: - вернуть значение из последнего элемента - уменьшить размер массива на 1 > [Иерархия при сохранении составного тэга] Теряется, в том то и дело. Не теряется. Но "сам запрос получается сложным и неудобоваримым", а кому сейчас легко? )

Re: Отправку СМС через VFP

of63

Сообщений: 25256
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

29.03.17 08:44:09

>Нет, массив это массив На его основе стек ещё делать надо - указатель вершины хранить, методы push/pop сделать
Массив - это стек в чистом виде:
push:
- увеличить размер массива на 1
- в последний элемент положить значение
pop:
- вернуть значение из последнего элемента
- уменьшить размер массива на 1

> [Иерархия при сохранении составного тэга] Теряется, в том то и дело.
Не теряется. Но "сам запрос получается сложным и неудобоваримым", а кому сейчас легко? )

Re: Отправку СМС через VFP
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 29.03.17 14:52:30 of63 Массив - это стек в чистом виде: А стек это таблица, а таблица это файл, а файл это видео, а видео это порно - так что массив это тоже порно of63 Не теряется. Смотря в какую структуру курсора это помещать... Вообще в XML кроме "вложенности" есть ещё и "порядок" - т.е. надо либо нумеровать все такие записи-элементы, либо хранить ссылки на "предыдущий на данном уровне", "следующий на данном уровне" - хотя такого рода связи нужны тоже далеко не всегда. Ну атрибуты неясно как хранить - в одной записи с самим элементом - нереально такое структурировать (а без структурирования придётся извлекать из мемо-поля каждый раз - что не есть быстро). В отдельных записях - значит появляется ещё один тип связи - помимо вложенности и порядка В общем ты меня не убедишь что: 1) это будет быстрее. 2) это будет проще. Ну и да - это надо писать, писать и ещё раз писать. А имеющийся парсер - взял и сразу пользуйся. Хотя в SAX режиме тоже прилично писанины получится... ------------------ WBR, Igor

Re: Отправку СМС через VFP

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

29.03.17 14:52:30

of63
Массив - это стек в чистом виде:

А стек это таблица, а таблица это файл, а файл это видео, а видео это порно - так что массив это тоже порно

of63
Не теряется.

Смотря в какую структуру курсора это помещать...
Вообще в XML кроме "вложенности" есть ещё и "порядок" - т.е. надо либо нумеровать все такие записи-элементы, либо хранить ссылки на "предыдущий на данном уровне", "следующий на данном уровне" - хотя такого рода связи нужны тоже далеко не всегда.
Ну атрибуты неясно как хранить - в одной записи с самим элементом - нереально такое структурировать (а без структурирования придётся извлекать из мемо-поля каждый раз - что не есть быстро). В отдельных записях - значит появляется ещё один тип связи - помимо вложенности и порядка

В общем ты меня не убедишь что:
1) это будет быстрее.
2) это будет проще.

Ну и да - это надо писать, писать и ещё раз писать. А имеющийся парсер - взял и сразу пользуйся. Хотя в SAX режиме тоже прилично писанины получится...

------------------
WBR, Igor

Страницы: 1 2 3

:: Список Форумов•Список тем•Поиск•Войти

Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 28 (Гостей: 28)