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

Iv · 15.10.2005, 16:41

2Crazy: извини, если какое либо из моих высказываний показалось тебе
мммм... некорректным.
Возможно я был несколько раздражен в тот момент.
Что касается меня, то я явный зоофил со склонностью к педерастии.
Но не наоборот.
И извини еще раз.

Цитата:

Я это понял как отказ от обсуждения примера

Да, я отказываюсь спорить по поводу твоего примера,
поскольку я СОГЛАСЕН с тобой.
Поскольку, как уже говорил ранее, мои утверждения не распространяются
на документы не имеющие иерархических связей.
Не более того.

Итак:
1. Я согласен с тобой, что многие XML объекты выгоднее распарсить в собственную структуру.
2. Я утверждаю, что те XML объекты, иерархические связи играют заметную роль
тащить в собственную структуру невыгодно в 99% случаев.

Я готов привести десятки примеров, причем живых, реально существующих.
Вот часто встречающиеся типы таких задач:
1. Древовидные меню.
2. Иерархические карты (город-район-улица-дом).
3. Описания структур организаций
и т.п.

спасибо.

Iv · 15.10.2005, 16:46

2KidsKilla: напиши плз на iv сабака design.ru, я тебе свою книжку пришлю,
если ты работаешь в той технологии, что я описал, то из книжки может чего еще
почерпнуть удастся, а мож и чем со мной поделишься из собственных находок.

спасибо.

Crazy · [+1 23.05.11]

Цитата:

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

2. Я утверждаю, что те XML объекты, иерархические связи играют заметную роль тащить в собственную структуру невыгодно в 99% случаев.

Даже в случае, когда на одну иерархичускую связь приходится десяток других связей, не подерживаемых DOM?

Iv · 15.10.2005, 17:26

возможно нет. от ситуации зависит.
но в общем, как правило, XML не помеха другим связям.

Crazy · [+1 23.05.11]

Ok. К вопросу "не помеха" мы еще вернемся. А сейчас перейдем к самой существенной части.

Мы оставляем данные в DOM-дереве для того, чтобы ими потом пользоваться, не так ли? Т.е. это означает, что в программе будет изрядное число место, где стоят обращения к данным этого дерева, используя DOM API и делая вполне фиксированные предположения о структуре этого дерева. Т.е. в программе есть ряд мест, код которых зависит от структуры конкретного типа XML-документа. И эти места де-факто "размазаны" по коду.

Я пока правильно излагаю?

KidsKilla · 15.10.2005, 17:50

совершенно не обязательно:
вариант с примером:
строим флешку в зависимости от хмл: attachMovie(node.nodeName, node.nodeName+"_"+depth, depth) bla-bla-bla...

Crazy · [+1 23.05.11]

В этом варианте DOM-дерево нам более не требуется, так?

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

Iv · 15.10.2005, 18:26

да, ты привел пример того, как не надо работать с XML.
собственно я обычно мой XML делаю "главным" в коде.
Обычно логика такова:
- узлы XML загоняю в подкласс с помощью org.dembicki.XMLE
- инициализирую построение сцены.

Создаваемые на основе данных объекты имеют некий
интерфейс общения с XML и, как правило, сами не знают
кто они такие и кто их соседи и т.п.
Но они четко знают кто их узел. В момент создания
они также регистрируются в своем узле и инициализируются.
Они не хранят данные о собственном состоянии.

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

Узлы же имеют свойства и методы для управления экземплярами.

Бонусы от этого разные и их много.
Например, навигация:
меню легко открыть на нужном пункте зная его id.
для этого в подклассе XML задается свойство "opened"
которое при вызове
any_node.opened = true
проверяет, открыт ли родитель, если закрыт, то
говорит родителю opened=true и так далее рекурсивно до
первого уже открытого узла.
соответственно, обратно спускаемся к нужному узлу
открывая ту и только ту цепочку, которая требуется.

если, например нужно узнать, какой итем в данный момент активен
то это реализуется тоже несложно:
при вызове opened=true в родительский узел записываем ссылку на
активный узел, примерно так:
this.parentNode.active_node = this

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

при всём при этом никаких переборов, поисков и обходов не производится.
никаких вещаний событий на тысячи элементов и т.п. всё строго и точно.

например эта технология работает на http://www.conclave.ru

Iv · 15.10.2005, 18:48

также очень здорово получаются админы, которые являются 2 в 1.
т.е. одна и та же флэшка является и админом и юзерским приложением.
отличие в том, что в случае админа я говорю через flashvars: admin=1.

В итоге человек, имеющий права админа прямо на HTML странице
вносит изменения в данные - например, двигает, добавляет/удаляет
города на карте.

в этом случае при драге экземпляр говорит узлу:
this.in_xml.attributes._x = this._x
this.in_xml.attributes._y = this._y

XML при этом сохраняется, не конвертится,
его данные не изменяются нигде, кроме как в нужном узле.

После чего админ жмет кнопку "сохранить" и XML улетает на сервак,
где записывается as is.

- это иллюстрация для опровержения:

Цитата:

Даже если нужно записать данные на сервер, то вариант "передать заново всю кучу данных, включая неизменившиеся части" является наихудшим.

скажем так: не всегда. далеко не всегда.

Crazy · [+1 23.05.11]

Цитата:

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

да, ты привел пример того, как не надо работать с XML.

Я понял это утверждение так:

1. Говоря о работе с XML ты никогда не имел в виду такой вариант и предаешь его анафеме как однозначно ламерский и непригодный к практическому использованию.

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

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

Чтобы не было недоразумений, я повторю текст:

Цитата:

Мы оставляем данные в DOM-дереве для того, чтобы ими потом пользоваться, не так ли? Т.е. это означает, что в программе будет изрядное число место, где стоят обращения к данным этого дерева, используя DOM API и делая вполне фиксированные предположения о структуре этого дерева. Т.е. в программе есть ряд мест, код которых зависит от структуры конкретного типа XML-документа. И эти места де-факто "размазаны" по коду.