Оптимизация разбора ХМЛ

[Iv]

1. скажем так: такой подход имеет весьма и весьма существенные недостатки.
2. решает многие проблемы. стандартизирует подход.

ты сам же и обозначил проблемы:
- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.

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

в развернутых случаях:
- получением XML списка соответствия классов
- получение собственно XML данных
- переход на первый узел
- получение ссылки на класс для построения экземпляра
(в зависимости от признаков узла, например имя узла, тип узла или
некий атрибут -- по ситуации)
- добавление экземпляра на сцену, возможно статическим методом класса,
передача экземпляру ссылки на узел.
-- в экземпляре: инициализация, сообщение узлу о себе
-- при необходимости вызов построения дочерних экземпляров на основе переданного узла
--- в экземпляре....

так рекурсивно строится вся сцена.

[Iv]

и еще добавлю: можно испоганить всё что угодно.
самые хорошие принципы при неправильном использовании совершенно бесполезны.

[Crazy]

ты сам же и обозначил проблемы:

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

- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.

Это единственные критерии, которые делают этот сценарий непригодным или ты полагаешь, что есть и другие, которые также стоит рассмотреть?

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

[processor]

Не читал, что тут написано ( может и не в тему буду ), но по топику:

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

[KidsKilla]

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

Не читал, что тут написано ( может и не в тему буду ), но по топику:

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

не в тему.

[iNils]

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

К любому NODE можно обращаться по ID , независимо на каком уровне он находиться.

swf сделаный под 8-ку это не поддерживает, по крайне мере в том виде, что использовалось раньше.

[Crazy]

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

Не читал, что тут написано

Заметно.

[processor]

в 8рке поддерживаеться idMap или как массив xml[id1][id2][id3]

[Mokus]

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

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

Вообще то ето (если я тебя правильно понял) называется "Адаптер".
Тоесть во избежание

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

- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.

ты делаеш адаптер, который имеет свой интерфейс (который соответствует интерфейсу нужного обекта), и который непосредственно взаимодействует с хмл. Я правильно понял?

Ну тогда вся разница только в том, что

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

Они не хранят данные о собственном состоянии.

А даные хранятся в хмл.

Если поступать так, то нету ПРИНЦИПИАЛЬНОЙ разницы как работать. используя такой метод теряються все преимущества и недостатки хмл, которые описывались выше.

Единственый +: не нужно опять сериализовать для отправки на серевер.

Единственый -: ето медленее (при большых обемах данных ты поразишся насколько).

[KidsKilla]

Mokus, ты предлагаешь сперва загрузить хмл, перевести в нужный тебе вид, и потом начать раздачу слонов? т.е. после этого привязывать результат парсинга к инстансам, при чём попутно создавая свой собственный api?

поясню схему ива:
- мы работаем ИСКЛЮЧИТЕЛЬНО с хмл. все пересчёты завязаны на него,
- навигация по узлам стандартизована.
- вся перерисовка происходит только по окончании рассчётов (обязательное условие для игр, например)
- безбоязненно создаём-удаляем инстансы с сохранением свойств (увеличение производительности при минимальных трудозатратах)

всё это можно, конечно, проделать и с собственным объектом, но налицо 3 минуса:
1) сериализация
2) одноразовость парсеров. иначе ни о каких оптимизациях по сравнению с хмл речь не идёт
3) уникальность (одноразовость, а отсюда и сумбурность) API.

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