| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Общие вопросы > Работа с XML |
| Автор: Erfolg 23.9.2006, 10:11 | ||
| Подскажите, как реализовать следующую задачу, нужно открыть XML файл и из него вывести в memo нужную информацию структура файла:
Нужно что бы создавалась 3 колонки с unitTypeActual identificationCode serialNumber с XML не работал, даже не представляюс с помощью какого компонента это можно сделать |
| Автор: BUGOR 23.9.2006, 11:58 |
| Посмотри внизу на похожие ссылки... если там не найдёшь, то накидаю тебе программу на регулярках. |
| Автор: Erfolg 23.9.2006, 12:21 |
| ПРобую но ни чего не получается ((( Единственное получилось загрузить в TDGrid с помощью XML Mappera, но мне такой вариант не подходит т.к. у меня около 5 тысяч XML файлов и мне надо из них построить одну базу |
| Автор: DemoCode 23.9.2006, 12:38 |
Мы все здесь телепаты, поэтому можешь не говорить, что конкретно не получается, сами догадаемся. |
| Автор: Erfolg 23.9.2006, 12:50 | ||||
Действительно........ просто запарился (((( можешь накидать примерчек как с помощью XMLDocument можно вывести в мемо (в моем случае) все UNIT с атрибутами unitTypeActual и serialNumber Вот XML Файл
|
| Автор: BUGOR 23.9.2006, 15:05 | ||
Добавь на форму контрол ListView, установи компонент TregExpr(поищи по форуму):
Если unitTypeActual всегда 4 буквы, а serialNumber 12 символов, то работать будет... Можно было бы попроще сделать, без всяких StringReplace, но оказалось, что TregExpr не поддерживает опережающих проверок, которые в парсинге XML очень полезны. |
| Автор: drkot 24.9.2006, 13:55 | ||||
| BUGOR, вобще ничего страшного что для разбора xml существует специальный парсер. Война как говорится ...., главное маневры.
стакими ограничениями .... А потом ищи откуда в юзера глюки полезли.
Так и зачем тогда это нужно. Работа с XML на форуме расписана вдоль и поперек. Зачем велосипед с квадратными колесами изобретать? Erfolg, File->New->Other->XMLBuilder и будет счастье. |
| Автор: BUGOR 24.9.2006, 14:37 |
| drkot, читай внимательно топик, я же написал в своём первом сообщении: "Посмотри внизу на похожие ссылки... если там не найдёшь, то накидаю тебе программу на регулярках.", человек стукнул ко мне в icq и попросил накидать пример потому, что у него не получилось что-то с готовыми компонентами, что касается условий, то всё вполне рационально т.к. данные шаблонны если тебя не устраивают ограничения, то нужно просто поправить регулярное выражение и всё. Я не считаю нужным юзать огромные библиотеки и компоненты, когда задача стоит всего-лишь в том, чтобы вытащить некоторые данные из документа, целиком его парсить вовсе ненужно. Вообще можно решить это с помощью двух-трёх стандартных функций и решение не будет громоздким, просто оно будет менее элегантным, нежели при использовании TRegExpr. К тому же я не вижу смысла в этом споре, ты предложил своё решение проблемы - я своё, пусть человек выбирает, есть по меньшей мере две причины по которым я выбрал собственную реализацию(в данном случае): 1. Собственная реализации будет быстрее. 2. Программу не так раздует. |
| Автор: drkot 24.9.2006, 15:03 | ||
TRegExpr да это маленикая библиотека на 150 кил чистого кода + по скорости уступает стандартному парсеру раз в 10. Спецификация XML "нестрогая": тоесть есть огромное число допущений по синтаксису и форматированию документа (даже в одном документе одни и теже поля могут быть сформатированы по разному - разделены #10#13 например) и учесть все это в регулярках сложно и нецелесообразно. Из собственного опыта: в процессе конвертации из HTML(база) в XML(база) из примерно 2000 страниц не было автоматически разобрано порядка 150. Хотя эти страницы генерировались одним PHP скриптом, а регулярки предварительно хорошо оттестировались.
Если Вы считаете что реализация в виде классов и интерфейсов менее элегантна то позволю с Вами несогласится. PS: каждый вправе писать программу так как он это может и хочет, но нужно помнить, что используемые программистом методы и алгоритмы и меют свое предназначение и нежелательно использовать их для решения других задач непонимая при этом особенностей задач и методов. Если Вы незнаете или не владеете средствами работы с XML (тема так и звучит) то наверное стоит почитать или послушать что люди скажут, а не подставлять 5-е колесо к телеге. А потом такие "наученые" приходят на работу и валят перво еже задание, да и реализация получается такая, что вдрож кидает. Нихочу никого обидеть, но культура в программировании должно присутствовать иначе будет как в чизни. Если я неправ то готов выслушать критику в свою сторону (но конструктивную). Добавлено @ 15:08 Да и вдовесок. Я нисколько не посягаю на Ваши знания в области регулярных выражений и их(выражений) ценности в решении поисковых задач. |
| Автор: BUGOR 24.9.2006, 15:44 | ||||||||
В данном случае её использование не прибавляет к проекту и 20 кило, какой же прирост мы получим, если будет использовать метод предложенный вами? Я думаю это далеко не 20 Кб. Насчёт скорости, это слова с неба или Вы их можете подкрепить доказательствами? Или давайте сравнивать, или про скорость работы TRegExpr не упоминать.
Я сравнил релизацию с помощью стандартных функций(которая кстати наверняка быстрее, чем при использовании классов).
Ну так скажите, что-нибудь по делу лучше, не поленитесь, возьмите и сравните по скорости и размеру(а что ещё важно клиенту? Красота кода или реализации? Не думаю.) несколько реализаций и покажите нам всем, что лучше, к чему попусту учить меня культуре программирования? Я признаю, что с XML дело не имел, поэтому если Вы мне докажите, что преимущество готовых классов очевидны(в контексте именно этой задачи, а не в целом, потому что я всё это говорю относительно данной темы), то я соглашусь, что в данном случае лучше использовать их.
Я со своими задачами в этой области справляюсь, поэтому оставьте намёки при себе. |
| Автор: drkot 24.9.2006, 16:19 | ||||||||
Исходни весит 10-20кб в зависимости от сложности файла (полнофункциональная работа в XML базой), если только чтение то -20%, урезка по ненужным полям тоже пропорционально снижает; dcu примерно в 1-2 раза больше исходника (чем больше исходник тем относительно меньше dcu); вносимый в проект код 5-10кб. Беблиотека TRegExpr: 150кб исходник; 60кб dcu; размер кода в проекте не мерял.
Цифры косвенные. Мерялось время загрузки и формирования в оперативке некоторой структуры записей. Так при использовании TRegExpr процесс занимал порядка 40-45сек, на стандартном делфяшном (микрософтовском) парсере укладывались в 3 сек. (при использовании парсера из поставки Jedy процесс разбора XML файла 25Мб занимал 120сек.) Универсальный алгоритм не может работать быстрее специализированного.
В классах ипользуются теже стандартные функции, только классы сформированы специально под структуру файла, что позволяет работать с файлом как с обычной списком объектов.
А это не в Вашу сторону сказал. Это скорее просто сотрясание воздуха. Просто часто попадаются программисты коротые решают поставленные задачи такими методами, что слов нехватает остается только молчать. По поводу описания и разъяснений я подумаю о написании статьи. Если тема актуальна конечно. PS: я знаю далеко не все (точнее сказать пости ничего), но стараюся прежде чем задавать вопросы (или советовать) изучить проблему. Если чем обидел то приношу свои извенения. |
| Автор: BUGOR 24.9.2006, 16:41 | ||||||||
Интересно, неужели универсальны класс для разрбора xml весит так мало? Судя по структуре XML он должен вешать не меньше TRegExpr.
Зато я померил и говорю, что это 18 Кб)
ВОТ, именно поэтому-то я и предложил инвидиальную реализацию, просто не думал, что TRegExpr даст проигрышь(хотя опять же в данном случае не факт).
Но опять же универсальность будет тормозить весь этот процесс. |
| Автор: drkot 24.9.2006, 17:07 |
Здесь нет юниверсальности, структура классов и интерфейсы генерируются под конкретную структуру файла. Положа руку на сердце скажу: "В данной конкретной задаче победит pos + copy + delete." Конкретная ситуация, конкретное решение, максимум скорости (особенно если оптимизированные функции использовать). |