Оптимизация разбора ХМЛ - Страница 13

KidsKilla · 17.10.2005, 22:36

итог как всегда один:
в зависимости от ситуации и подхода и из конфетки может случиться *****, равно как и наоборот.
при грамотном подходе хмл не непонятный зверь, а друг и помошник...

Mimohod · 18.10.2005, 01:40

Во-первых (и главное) - спасибо всем за все х/з сколько страниц на эту тему. Я пытался задать этот вопрос там, где ему место (в разделе XML), но там все ограничилось тремя жидкими постами...
Здесь я получил, что хотел.

Во-вторых. Инструменты предназначены для целевого использования (хотя, конечно, молотком можно измерить длину, а рулеткой забить гвоздь...). И с этой точки зрения Ив в самом начале и весьма конкретно обозначил свою позицию: XML выгодно использовать "напрямую", не перегоняя его в массивы или во что бы то ни было в случаях, когда древовидная структурированность данных играет решающую (или весомую) роль //не придирайтесь к словам с просьбами выразить эти эпитеты в процентах ))
Естественно, что для обработки XML-данных потребуются и иные инструменты помимо стандартных - это не говорит ни за, ни против сохранения данных в формате XML на "весь период использования" (где-то был такой довод от Crazy, на тему "что ж ты за другие инструменты хватаешься, работай стандартными XML-ными..."//мои извинения, если понял неверно, но, по-моему, смысл был такой...

В-третьих. Придирки к словам - не лучший способ ведения спора. А это у Crazy боевой прием (сужу по вещам, в которых понимаю хоть что-то - часть спора была мне недоступна, не эксперт). Судя по всему, Crazy - все-таки специалист, а из этого можно сделать вывод, что писаное Ивом он был в состоянии понять правильно, а не играть словами (чо в конце концов и кончилось практически руганью...)
Это не говоря уж о выражениях

Цитата:

В твоей практике такое не встречалось? Ничего страшного. Со временем начнешь писать более сложные программы.

и

Цитата:

Мсье хочет сказать, что никогда не работал с XML размером в мегабает и более? Ничего страшного, и это придет.

Ну ей-богу, как в песочнице...

И в-четвертых. Мои выводы (на моем этапе развития, конечно)
С "легкими" XML-никами (до 10-15 кБ, более - поэкспериментирую) однозначно буду работать, не перегоняя их "в другие форматы" (оговорюсь теперь сам: в случаях, когда древовидная структурированность данных играет решающую (или весомую) роль)

Как это в телевизоре...
"Пользуясь случаем, хочу передать привет..." - Иву спасибо за парсер, который я нарыл на Народе. Легкий, быстрый и красиво написаный (на мой "неэкспертный" взгляд)

Iv · 18.10.2005, 14:54

есть практический опыт использования XML более 6-8 мегабайт.
для удобства работы он разбивался на куски по 100-200 килобайт
(примерно столько занимает описание одного магазина)
также делался базовый XML, который задавал структуру и имел
ссылки на внешние XML-описания магазинов.
загрузка производилась в поточном режиме:
базовый XML после загрузки инициировал последовательную
загрузку дочерних узлов, и пока грузился,
например, пятый, он встраивал в себя 4й.

в итоге на клиенте собиралась структура, которую, если вытащить
в единый файл занимала бы более 6ти мегов.
Никаких тормозов при этом не наблюдалось.

Поскольку проект оффлайновый, после загрузки
приложение должно работать примерно 14 часов.
соответственно тестировалось на утечки памяти.
проблем не возникло.

полагаю, что 6мегов далеко не предел, поскольку
в отличие, например, от мувиклипов, XML не слушает
часто вещаемых событий типа onEnterFrame.
он просто лежит в памяти, не более того.

По поводу парсера на народе.
Собственно мною статьи писались чтобы самому понять что к чему.
Очень давно. Года 3-4 назад.

Вполне приемлемые инструменты работы с XML я выкладывал
на http://proto.layer51.com/l.aspx?p=19

в коротких проектах наиболее чаcто употребляю
nextNode и для тестовых целей tabbedString
потому как стандартный toString выдает нечитабельную кашку.

удачи!

Iv · 18.10.2005, 14:59

добавлю:
большинство удачных и часто используемых методов и свойств
стало частью класса org.dembicki.XMLE
в сети лежит соответственно.

Crazy · [+1 23.05.11]

Цитата:

Сообщение от KidsKilla

при грамотном подходе хмл не непонятный зверь, а друг и помошник...

(Пишу сходу, без проверки. Так что заранее извиняюсь за возможные косякию)

В этом треде обсуждались де-факто три схемы работы с XML:

1. Оставить все данные в оригинальном DOM-дереве и работать с ними.
2. Добавить в элементы оригинального DOM-дерева свои методы и данные.
3. Создать отдельную объектную структуру и передать в нее данные из DOM-дерева.

(Здесь стоит сразу уточнить, что в третьем пункте, если бы была техническая возможность, слово DOM не звучало бы вообще -- достаточно SAX).

Я не буду сравнивать эти три схемы ввиду порочности такого сравнения. Почему я считаю это сравнение порочным? Потому, что этот подход предполагает, что кто-то берем DOM-дерево и строит вокруг него приложение. Что, обычно, не соответствует действительности.

Нормальная разработка приложения следует вполне устоявшимся сценариям: сбор и фиксация требований, разработка архитектуры, дизайн классов и т.п.

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

Потому мы не будет извращаться и начнем по правилам. В качестве примера возьмем уже упоминавшийся опросник.

I. Сбор и фиксация требований.

Требуется создать опросник, обладающий следующими характеристиками:

1. Пользователю предоставляется выборка N вопросов из M доступных вопросов.
2. Вопросы разделяются на категории, причем при формировании предъявляемой пользователю выборки из каждой категории выбирается фиксированное количество случайно отобранных вопросов.
3. Предоставляемые пользователю вопросы перемешиваются.
4. Пользователь может пропустить вопрос, чтобы позднее вернуться к нему.

Обычно на этом этапе нет никаких требований к формату данных. Но я преднамеренно выберу худший для меня вариант: случай, когда создаваемая система интегрируется по данным с уже существующей.

5. Список вопрос загружается c сервера и представляет собой XML-документ. Список ответов пользователя отправляется на сервер также в виде XML-документа.

Для краткости я не буду приводить DTD и просто дам примеры документов.

5.1. Пример списка вопросов

Код:

<questions>
  <selection-rules>
    <select-questions section="Foo" count="2"/>
    <select-questions section="Bar" count="2"/>
  </selection-rules>
  <section id="Foo">
    <question id="Foo1">
      <text>Foo1 qestion text</text>
      <answers>
        <answer code="Answer1">
          <text>Answer 1 text</text>
        </answer>
        ...
        <answer code="AnswerN">
          <text>Answer N text</text>
        </answer>
      </answers>
    </question>
    ...
  </section>
</questions>

Здесь коды ответов уникальны в контексте вопроса.

5.2. Пример списка ответов.

Код:

<answers>
  <answer question="Foo1" code="Answer2"/>
  <answer question="Foo2"/> <!-- Без ответа -->
  ...
</answers>

II. Создание архитектуры

На этом этапе мы принимаем решение делать все на флэше. Даже если заказчик изначально хотел флэш, то только на этом этапе мы анализируем требования и говорим: да, это подойдет.

И начинаем проектировать разбиение на классы. Учитывая наши сценарии использования сразу выделяются следующие классы:

ExaminationVC. Отвечает за отображение текста вопросов и ответов, за навигацию по вопросам. Взаимодействует с SelectedQuestions.
SelectedQuestions. Представляет упорядоченный список отобранных вопросов, содержит элементы типа QuestionInstance.
QuestionInstance. Представляет вопрос, участвующий в опросе. Отвечает за отслуживание выбора пользователя. Делегирует Question запросы к тексту вопроса и списку ответов.
Question. Представляет вопрос. Содержит список объектов Answer.
Answer. Представляет ответ.
Section. Представляет секцию, содержащую список вопросов и хранит информацию о количестве вопросов секции, которые должны войти в опрос. Отвечает за случайный отбор требуемого количества вопросов.
Questionary. Представляет базу вопросов и содержит список секций.

На этом этапе мы сопоставляет свое разбиение со структурой XML-документов, чтобы убедиться, что мы можем получить все требуемые данные и что мы ничего не забыли. Обращаю внимание на то, что нет отдельного объекта, соответствующего <selection-rules>. Возникший для удобства составителей опросника, он не требуется на этапе исполнения.

QuestionaryFactory. Отвечает за создание экземпляра Questionary. Абстрактный класс.
XmlQuestionaryFactory. Реализация QuestionaryFactory для загрузки данных из XML.

ResultSerializer. Отвечает за сериализацию результата опроса. Абстрактный класс. Взаимодействует с SelectedQuestions.
XmlResultSerializer. Реализация ResultSerializer для сериализации результата в XML.

III. Дизайн классов.

На этом этапе мы детализируем интерфейс каждого класса. Например, мы фиксируем, что класс SelectedQuestion имеет следующие методы:

registerQuestion(QuestionInstance):void. Регистрация вопроса. Создает экземпяр QuestionInstance и добавляет в случайно выбранное место списка.
getCount():int. Возвращает количество элементов в списке.
getQuestionText(int):String. Возвращает текст вопроса с указанным индексом в списке.
getAnswerTexts(int):String. Возвращает массив строк с текстами ответов к вопросу с указанным индексом в списке.
setAnswerNo(int,int):void. Устанавливает номер выбранного пользователем ответа для вопросf с указанным индексом в списке.

Эти методы используются ExaminationVC. Еще несколько методов нужны для ResultSerializer:

getQuestionID(int):String. Возвращает ID вопроса с указанным индексом в списке.
getAnswerCode(int):String. Возвращает код выбранного ответа для вопроса с указанным индексом в списке.

Обращаю внимание: при выборе ответа мы оперируем порядковым номером, а при сериализации -- кодом.

Для XML-документа, который мы получаем на вход, характерна явно выраженная иерархическая структура. Казалось бы, интерфейс большинства объектов имеет ссылку на parent'а, ссылки на соседние элементы и список дочерних элементов. В действительности в интерфейсе наших объектов:

1. Нет ни одной ссылки parent. Ввиду полного отсутствия необходимости.
2. Нет ни одной ссылки на соседний элемент. По той же причине.
3. Список всех дочерних элементов предоставляет только SelectedQuestions.

Последнее утверждение кажется спорным. Действительно, а как же, к примеру, список секций опросника? Разве не нужно иметь к нему доступ, чтобы пройтись по всем секциям и добавить выбранные из них вопросы к списку?

Нет, не нужно. У Questionary мы имеем метод selectQuestionsFor(SelectedQuestions):void. Мы не спрашиваем "какие секции в тебе есть". Мы приказываем: "зарегистрируй свои вопросы".

Это один из главных принципов ООП: всегда, когда есть выбор, нужно не спрашивать, а инструктировать.

III. Реализация.

Для реализации мы выберем TDD (Test Driven Development). Поскольку XML у нас нигде не выходит за пределы XmlQuestionaryFactory/XmlResultSerializer, мы легко пишем unit-тесты, не заморачиваясь поднятием дерева.

Поскольку у нас четко выделена ответственность каждого класса и интерфейс не содержит лишних методов, мы всегда знаем, что нам тестировать. И может распределить разработку по нескольким программистам.

IV. Тестирование.

Поскольку unit-тесты уже пройдены, остается де-факто тестирование пользовательского интерфейса и несколько интеграционных тестов.

Система готова.

Продолжение (не уместилось по объему) -- следующим сообщением.

Crazy · [+1 23.05.11]

Цитата:

Сообщение от Crazy

Продолжение (не уместилось по объему) -- следующим сообщением.

Но жизнь системы не окончена. Рассмотрим несколько сценариев дальнейших событий:

1. Новый заказчик хочет заказать аналогичную систему. Но у него другой формат XML. Например, такой:

Код:

<questions>
  <author id="John@Doe.com">
    <question id="Foo1" category="Foo">
      Foo1 qestion text
      <answers>
        <answer code="Answer1">Answer 1 text</answer>
        ...
        <answer code="AnswerN">Answer N text</answer>
      </answers>
    </question>
    ...
  </author>
  ...
</questions>

Требования его дизнеса диктуют такое разбиение: вопросы делятся на блоки по авторам. Для каждого вопроса указывается его категория. Т.е. тэга, соответствующего категории, у нас нет вообще. Но есть тэг "автор".

Каковы будет изменения в нашей программе? В данной реализации мы правим класс XmlQuestionaryFactory. Мы всегда будем его править при изменениях в структуре XML.

Больше не меняется ни одной строки.

2. Заказчик желает усложнить систему, увеличив количество потенциальных ответов. Каждый ответ он будет штамповать именем группы. При формировании выборки вопросов отбирается один ответ из каждой группы. Фрагмент измененного XML:

Код:

<answer code="Answer1" group="a">
  <text>Answer 1 text</text>
</answer>
<answer code="Answer2" group="b">
  <text>Answer 2 text</text>
</answer>
<answer code="Answer3" group="b">
  <text>Answer 3 text</text>
</answer>

С правкой XmlQuestionaryFactory все понятно. Где еще будут изменения? Ответ очевиден, опять таки ввиду четкой модели классов:

Answer. Нужно добавить атрибут group.
QuestionInstance. Нужно добавить список отобранных ответов.
Question. Добавляем метод selectAnswersFor(QuestionInstance):void.

Обращаю внимание: мы не идем по маньячному пути "править как можно меньше классов". Мы правим в точности то, что править нужно -- думаем о будушем.

Что мы получим взамен, если будем строить систему вокруг DOM-дерева, т.е. вокруг конкретной структуры документа? Получим мы по крайней мере следующее:

1. Объекты с замусоренным интерфейсом. Если в вижу в коде обращение к Answer.parentNode -- это забывчивость программиста, гнусный хак или допустимый прием?
2. Следствие предыдущего пункта -- трудности в unit-тестировании. Усугубляющиеся усложнившейся процедрой подготовки тестовых данных.
3. Следствие предыдущего пункта -- повышение затрат на тестирование в целом.
4. Архитектура/дизайн системы, построенные не логическим анализом требований, а дублированием структуры документа, будут иметь больше нелогичностей и недоработок, которые аукнуться нам при поддержке и развитии.
5. Следствие предыдущего пункта и первого пунктов -- трудности при внесении изменений в реализацию.

Итак, с одной стороны -- сомнительная экономия от "повторного использования" родительско/дочерних связей (которые в действительности мы не используем), с другой -- разброд и шатания в коде.

Каждый выбирает сам. Дело добровольное.

Iv · 18.10.2005, 23:59

Цитата:

1. Нет ни одной ссылки parent. Ввиду полного отсутствия необходимости.
2. Нет ни одной ссылки на соседний элемент. По той же причине.
3. Список всех дочерних элементов предоставляет только SelectedQuestions.

- всё верно.
Чем менее значимы иерархические связи, тем меньше проблем при таком решении.

Тест "Семья и брак".
Все последующие вопросы зависят от предыдущих ответов.
Вложенность произвольная.
Количество вопросов произвольное.
По достижении дна ветки переходим на начало следующей ветки.
Произвольное количество откатов к предыдущему вопросу.
Подсветка "посещенных" ответов.

- В моем варианте реализации не изменится практически ничего
при переходе от теста описанного тобой к тесту описанному мной.

Цитата:

1. Объекты с замусоренным интерфейсом....

- нет ничего подобного.
Хм... даже интересно, с чего ты это взял?

Все роли строго расписаны. XML не отвечает за отображение вопроса,
а элемент понятия не имеет о том, каким будет следующий вопрос или
нечто в этом роде.
Обращений к parentNode нет в объекте и быть не может.
Объект знает только о своем узле и ни о чем более.
соответственно п.1, а так же 2 и 3, как построенные на нем - неверное предположение.

п.4 - не дублирование структуры документа а навигация по структуре,
поэтому так же - неверное предположение.

п.5 как основанный на 1 и 4 - также неверно.

Я бы предолжил не пытаться делать предположений о том, чего не знаешь,
а рассказать о том, о чем знаешь.

Crazy · [+1 23.05.11]

Цитата:

Сообщение от BitSky

- В моем варианте реализации не изменится практически ничего при переходе от теста описанного тобой к тесту описанному мной.

Принципиальная разница в том, что я могу вместо расплывчатого и бесполезного "не изменится практически ничего" сразу сказать, что и как измениться в моем варианте.

Изменения коснутся:

XmlQuestionaryFactory. Добавлена обработка вложенных тэгов <question>.
Question. Добавляется список вложенных вопросов. Меняется код метода регистрации.
SelectedQuestions. Добавляется логика, управляющая выбором очередного вопроса и текущего количества доступных вопросов.

Кроме того, я сразу указал бы заказчику на странность в постановке задачи: при сохранении возможности вернуться и изменить ответ меняется состав вопросов, следующих за данным. И предложил бы набор решений этой проблемы. Но это уже совсем другая история...

Соответственно, я могу сразу написать unit-тесты для изменившегося кода и дать тестировщикам сведения, необходимые им для изменения плана тестирования.

Благодарю за хороший пример, иллюстрирующий преимущества рационального подхода к разработке ПО.

Цитата:

Я бы предолжил не пытаться делать предположений о том, чего не знаешь, а рассказать о том, о чем знаешь.

Я внимательно перечитал размещенные тобой сообщения, в которых ты немалое место уделяешь описанию технологии. С тем объемом подробностей и нюансов, которые ты счел уместным упомянуть. Я сделал из них именно такой вывод. Твое последнее сообщение его подтверждает.

Если ты писал все это вовсе не для того, чтобы это читали, после чего делали выводы и озвучивали предположения, то стоило экономнее отнестись к своему времени и нервам и просто ничего не писать. Или добавлять в конце "НА ОСНОВАНИИ ВЫШЕСКАЗАННОГО НЕЛЬЗЯ ДЕЛАТЬ ПРЕДПОЛОЖЕНИЯ". Не обязательно заглавными букавами.

Вполне может быть, что другие люди сделают из сказанного тобой другие выводы. Я свое мнение никому не навязываю и единственно правильным не считаю.

Iv · 19.10.2005, 02:30

Цитата:

я могу .... сразу сказать

- как будто я не могу сказать что изменится

изменится обработка событий в подклассе XML. и всё.

Цитата:

Кроме того, я сразу указал бы заказчику на странность ....

- вопрос1 : вы изменяли мужу?
ответ 1: да
ответ 2: нет
- странно если в этом раскладе состав последующих вопросов не изменится,
а останется:
вопрос 2: сколько раз?
-- впрочем многие мужчины и женщины поступят так же

Цитата:

Я сделал из них именно такой вывод

- мне кажется, что неправильный.
Возможно, причина в существенном недостатке информации
и полном отсутствии опыта использования данного метода.
Изложенное здесь мною это крохи...
Тебе не кажется что рановато делать такие утверждения?

НА ОСНОВАНИИ ВЫШЕСКАЗАННОГО НЕЛЬЗЯ ДЕЛАТЬ УТВЕРЖДЕНИЙ

от предположений до утверждений долгий и нелегкий путь...

Цитата:

Вполне может быть, что другие люди сделают из сказанного тобой другие выводы.

- посмею сделать утверждение: каждый сделает собственные выводы.

nuran · 19.10.2005, 05:43

Уфф, крэйзи, и не лень же...