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

[iNils]

Соглашусь с Ивом. Работать с xml проще, чем хранить все в объекте.

[Mokus]

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

ну давайте еще агрументы в пользу первого способа и второго

В споре рождаеться истина!!!!

В споре истина рождаеться очень редко.

Но так уж и быть приведу пару аргументов. Вернее короткий екскурс в основы.

Сериализация:
In computer science, serialization means to force one-at-a-time access for the purposes of concurrency control, or to encode a data structure as a sequence of bytes. The opposite operation, to extract a data structure from a series of bytes, is deserialization.

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

О чем здесь спорить?

[Mokus]

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

Соглашусь с Ивом. Работать с xml проще, чем хранить все в объекте.

В чем проще???

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

Мой тебе совет - работай только с XML обектами и будет тебе щастье.

Мир

[iNils]

1. Кто у объекта сосед ближайший сосед?
2. Попробуй разом вывести всю структуру у объекта.
3. Если тебе надо сохранить иерархию на сервере, опять надо в xml перегонять.

[Mokus]

1.Только ТИП обекта определяет данные, которые про етот обект надо знать. Обект НЕ ИМЕЕТ ПРАВА знать кто его ближайший сосед. Но в случае если он спроектирован чтоб ето знать - он ЕТО БУДЕТ ЗНАТЬ.
2. Тоже самое (кстати структуру любого обекта очень легко вывести е меня для етого класс есть с функцией Trace.traceObject().
3. Ну то перегони.

А вопрос как заставить вести себя обект так как он должен, если он блин в хмл?
Например у обекта был метод calculateSomething(). а другой обект служыл хранилищем для даных для етого с функциями хеширования, а третий слушал обращение к етому методу. Как ты ето в хмл воссоздаш?
А я просто поднимаю из хмл обекты и работаю дальше.

[Mokus]

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

[Crazy]

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

1. Кто у объекта сосед ближайший сосед?

В общем случае вопрос лишен смысла. Иногда -- когда объект является членом коллекции -- об этом знает контейнер.

2. Попробуй разом вывести всю структуру у объекта.

В какой практической задаче может потребоваться вываливать юзеру структуру объекта в виде XML?

3. Если тебе надо сохранить иерархию на сервере, опять надо в xml перегонять.

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

[Iv]

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

соответственно, вопрос перегонять ли XML в объекты сводится лишь к тому,
следует ли удалять... ну собственно я об этом уже писал выше.

[Crazy]

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

Такое впечатление, что ты говориш про хмл как просто про масив стрингов с древовидной структурой.

А чем XML отличается "от массива стрингов с древовидной структурой"?

[Iv]

В общем случае вопрос лишен смысла

- не слишком ли общий случай?
Чаще всего, а именно в 99% случаев моей практики работать приходится
со СТРУКТУРИРОВАННЫМИ данными,
где родительско-дочерние, братские взаимосвязи играют
не меньшую роль, чем сами данные.
И уж в этом случае вопрос ну никак не лишен смысла.

С оставшимся 1% согласен: можно перегонять в объекты. Но нужно ли?

когда объект является членом коллекции -- об этом знает контейнер

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

В какой практической задаче может потребоваться вываливать юзеру структуру объекта в виде XML?

- круто.
XML создан для разработчиков, для удобства и скорости их работы.
Впрочем как и языки программирования высокого уровня.
И сотня лишних килобайт портаченных на траффик и
100 миллисекунд потраченных на парсинг XML уже не играют никакой роли.
Разумеется XML не предназначен для непосредственного скармливания юзерам.
Не надо задавать такие вопросы как будто тут идиоты собрались.

п.п. 1 и 2 не играют ни малейшей роли.

Стандартизация и унификация подходов играют огромную роль в программировании.
Я совершенно без проблем разберусь в проекте,
в котором использованы стандарты типа XML.
Разбираться в зависимостях вручную созданных объектов - увольте.