Просмотр полной версии : Оптимизация разбора ХМЛ
Меня уже давно мучает такой вопрос:
Как лучше поступать с ХМЛ данными, полученными флешкой - разбирать их и хранить в своей стуктуре/объекте типа дерева или еще чего-нибудь, или же каждый раз добираться до данных используя исходный ХМЛ?
Также интересует, что из этого быстрее, а что более грамотнее в реализации.
Парсинг xml данных - это и является преобразованием xml контента в объект(ы). Далее работа с xml данными сводится к работе с полученным объектом(объектами).
И только в случае обновления xml контента необходимо парсить его заново.
т.е. нет никакого смысла держать объект XML дальше
разобрали -> удалили ? верно?
а такой вариант - допустим таже менюха двух/трех уровневая, нету же смысла создвавать подпункты второго третьего уровня если мы не отображаем их т.е. нажали меню - собираем под меню, нам же нужны данные для его создания, и их лучше брать из своего объекта, или разбирать нужный кусок ХМЛ?
Да:
1. Разобрали
2. Удалили
3. Далее работаем с объектом
Та же песня и с меню.
это хорошо все сомненья прочь ! %))
разбор и перевод XML в объекты и работа с объектами
- признак неумения работать с XML.
в 99 процентах случаев нужно работать с XML.
объяснение просто:
XML объект это набор таких же объектов Object как и любой другой,
но у него есть стандартизированная структура и методы.
Перевод в объекты - удаление стандартизированной структуры и методов.
Не более того.
Абсурдно удалять то, что помогает работать с данными.
разбор и перевод XML в объекты и работа с объектами
- признак неумения работать с XML.
в 99 процентах случаев нужно работать с XML.
Такой пост - "признак неумения работать с XML."
ну давайте еще поспорим !!!!!!,
аргумент в пользу ХМЛ - унас все уже есть, зачем еще объекты !!!
аргумент в пользу Объектов - есть xml файл строк этак тыщ 5 или больше название тега занимает в среднем символов 6+пробелы+кавычки. вопрос: скоко лишней памяти мы тратим?
ну давайте еще агрументы в пользу первого способа и второго
В споре рождаеться истина!!!!
Соглашусь с Ивом. Работать с xml проще, чем хранить все в объекте.
ну давайте еще агрументы в пользу первого способа и второго
В споре рождаеться истина!!!!
В споре истина рождаеться очень редко.
Но так уж и быть приведу пару аргументов. Вернее короткий екскурс в основы.
Сериализация:
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-документ сам по себе нихрена полезного из себя не представляет и точно не обладает красотой снежынки. Ето всего навсего представление какогото обекта в форме, которая относительно удобна для сохранения (сериализация). Десериализовав обект из хмл мы получаем наш исходный обект и работаем с ним дальше. Ето же так просто явно и понятно. Интуитивно блин.
О чем здесь спорить?
Соглашусь с Ивом. Работать с xml проще, чем хранить все в объекте.
В чем проще???
Нахрена тогда вообще обекты других типов? Нахрена создаються классы, отношения между ними и иерархии? нахрена понапридумовано сотня паттернов?
Мой тебе совет - работай только с XML обектами и будет тебе щастье.
Мир
1. Кто у объекта сосед ближайший сосед?
2. Попробуй разом вывести всю структуру у объекта.
3. Если тебе надо сохранить иерархию на сервере, опять надо в xml перегонять.
1.Только ТИП обекта определяет данные, которые про етот обект надо знать. Обект НЕ ИМЕЕТ ПРАВА знать кто его ближайший сосед. Но в случае если он спроектирован чтоб ето знать - он ЕТО БУДЕТ ЗНАТЬ.
2. Тоже самое (кстати структуру любого обекта очень легко вывести е меня для етого класс есть с функцией Trace.traceObject().
3. Ну то перегони.
А вопрос как заставить вести себя обект так как он должен, если он блин в хмл?
Например у обекта был метод calculateSomething(). а другой обект служыл хранилищем для даных для етого с функциями хеширования, а третий слушал обращение к етому методу. Как ты ето в хмл воссоздаш?
А я просто поднимаю из хмл обекты и работаю дальше.
Такое впечатление, что ты говориш про хмл как просто про масив стрингов с древовидной структурой. Такое впечатление что ты считаеш, что обекты ето только даные.
1. Кто у объекта сосед ближайший сосед?
В общем случае вопрос лишен смысла. Иногда -- когда объект является членом коллекции -- об этом знает контейнер.
2. Попробуй разом вывести всю структуру у объекта.
В какой практической задаче может потребоваться вываливать юзеру структуру объекта в виде XML?
3. Если тебе надо сохранить иерархию на сервере, опять надо в xml перегонять.
1) Далеко не все загружаемые данные нужно потом записывать обратно на сервер.
2) Даже если нужно записать данные на сервер, то вариант "передать заново всю кучу данных, включая неизменившиеся части" является наихудшим.
узел XML как и любой другой объект можно загнать в подкласс.
это никак не влияет на всё остальное.
он может и вещать и слушать и иметь метод calculateSomething
или не иметь его, может хранить данные, иметь свойства и т.п.
всё это - как тебе захочется.
соответственно, вопрос перегонять ли XML в объекты сводится лишь к тому,
следует ли удалять... ну собственно я об этом уже писал выше.
Такое впечатление, что ты говориш про хмл как просто про масив стрингов с древовидной структурой.
А чем XML отличается "от массива стрингов с древовидной структурой"? :)
В общем случае вопрос лишен смысла- не слишком ли общий случай?
Чаще всего, а именно в 99% случаев моей практики работать приходится
со СТРУКТУРИРОВАННЫМИ данными,
где родительско-дочерние, братские взаимосвязи играют
не меньшую роль, чем сами данные.
И уж в этом случае вопрос ну никак не лишен смысла.
С оставшимся 1% согласен: можно перегонять в объекты. Но нужно ли?
когда объект является членом коллекции -- об этом знает контейнер - это тоже понравилось.
удаляем встроенные методы навигации по данным и создаем собственные.
В какой практической задаче может потребоваться вываливать юзеру структуру объекта в виде XML?- круто.
XML создан для разработчиков, для удобства и скорости их работы.
Впрочем как и языки программирования высокого уровня.
И сотня лишних килобайт портаченных на траффик и
100 миллисекунд потраченных на парсинг XML уже не играют никакой роли.
Разумеется XML не предназначен для непосредственного скармливания юзерам.
Не надо задавать такие вопросы как будто тут идиоты собрались.
п.п. 1 и 2 не играют ни малейшей роли.
Стандартизация и унификация подходов играют огромную роль в программировании.
Я совершенно без проблем разберусь в проекте,
в котором использованы стандарты типа XML.
Разбираться в зависимостях вручную созданных объектов - увольте.
- не слишком ли общий случай?
Диалоги в стиле "а вот может ли быть ситуация, когда выгодно работать непосредственно с XML" мне не инетересны. Ответ здесь очевиден: такие случаи быть могут.
Чаще всего, а именно в 99% случаев моей практики работать приходится
со СТРУКТУРИРОВАННЫМИ данными,
где родительско-дочерние, братские взаимосвязи играют
не меньшую роль, чем сами данные.
В моей практике как правило приходится работать со структурами данных, в которых связи "parent-child" и "next/prev sibling" являются в лучше случае недостаточными.
С оставшимся 1% согласен: можно перегонять в объекты. Но нужно ли?
Процентовка, очевидно, является частью лично твоего опыта. В универсальной применимости которого я очень сомневаюсь.
- это тоже понравилось.
удаляем встроенные методы навигации по данным и создаем собственные.
Для работы нужно иметь адекватным методы доступа. Адекватные, а не "встроенные". Простой пример: XML-документ содержит карту. Объекты -- дома. Доступ мне нужен по координатам X/Y. Чем мне поможет использование встроенных в DOM средств? Правильно, ничем.
В твоей практике такое не встречалось? Ничего страшного. Со временем начнешь писать более сложные программы.
И сотня лишних килобайт портаченных на траффик и
100 миллисекунд потраченных на парсинг XML уже не играют никакой роли.
Мсье хочет сказать, что никогда не работал с XML размером в мегабает и более? Ничего страшного, и это придет.
Разумеется XML не предназначен для непосредственного скармливания юзерам.
Прекрасно. А как предлагается его использовать?
Не надо задавать такие вопросы как будто тут идиоты собрались.
(Обрати внимание: не я иницииовал переход на личности. :)
Следующая цитата говорит о том, что если и не идиоты (верю), то уж явно не гуру.:)
п.п. 1 и 2 не играют ни малейшей роли.
Тем более, когда затем следует такая риторика:
Стандартизация и унификация подходов играют огромную роль в программировании.
Не хотел бы тебя огорчать, но унификация ради унификации есть идиотизм. Тем более, что в данном случае это совсем мимо.
Привязка к XML -- это и есть отказ от унификации. Я не хочу задумываться -- по возможности -- откуда загружены мои данные: из XML, CSV, из бинарного файла. Мне важна осмысленная объектная модель, отражающая суть задачи. Которую никто не имел в виду, проектируя DOM.
Я совершенно без проблем разберусь в проекте,
в котором использованы стандарты типа XML.
Обана. А какие еще "стандарты типа XML" ты знаешь? SGML? Что-то мне ничего больше не вспоминается.
Разбираться в зависимостях вручную созданных объектов - увольте.
Умение читать код -- основа профессионализма. Но в данном случае проблема не в этом. Проблема в том, что ты занимаешься самообманом.
XML дает синтаксис. Без семантики (некую убогую часть семантики даст DTD/XMLSchema). Разобраться в семантике -- то же самое, что разобраться в объектой модели. Здесь нет никаких отличий. За исключением того, что лишь в тривиальных случаях -- когда хватает штатных выразительных средств XML -- это будет так же просто. В остальных случаях разобраться с XML будет сложнее.
:) я в гуры не стремлюсь и, разумеется, каждый из нас говорит
с высоты собственного опыта работы во flash.
Например, в моей практике действительно не встречалось задач,
при которых я получал бы данные в XML, а доступ к ним
мне нужен был бы по координатам.
И с трудом себе представляю зачем нужно такие данные передавать в виде XML.
Ну это видать от недостатка практики: у нас в конторе
не найти такого программера, которому бы это пришло в голову.
И в этой ситуации вполне тебя понимаю и не виню:
мало ли с кем приходится работать.
унификация ради унификации - вот так и будем спорить?
сначала навешивать то, чего не говорил, а затем успешно опровергать?
Умение читать код -- основа профессионализма. - согласный я.
впрочем умение его писать не менее важно.
и не менее важно умение его писать читабельно.
Разговор становится беспредметным.
Просто опиши проект, в котором выгоднее получить данные в XML
загнать в объекты и кильнуть и у нас будет предмет для спора
или мы все тут же согласимся с тобой.
В моей практике как правило приходится работать со структурами данных, в которых связи "parent-child" и "next/prev sibling" являются в лучше случае недостаточными.
Пример можно?
А кто тебя заставляет их использовать?
Обожаю когда кидаются "умными" словами с высокоподнятой головой :)
К обоим: я привел пример. Читайте внимательно.
а можно ли уточнить для особо тупых?
к коим я начал себя причислять после твоего последнего ответа.
Простой пример: XML-документ содержит карту. Объекты -- дома. Доступ мне нужен по координатам X/Y.
Или нужно еще DTD?
сорри, как раз почему-то этот абзац пропустил.
очень понравилась фраза:В твоей практике такое не встречалось? Ничего страшного. Со временем начнешь писать более сложные программы. - я конечно постараюсь оправдать твои ожидания.
спасибо.
Итак, отличный пример: XML-документ содержит карту. Объекты -- дома. Доступ мне нужен по координатам X/Y. Чем мне поможет использование встроенных в DOM средств? Правильно, ничем. - в моей практике такое встречается частно. И утверждение, что ничем не поможет - весьма странно.
Из родителя я беру название улицы, а из родителя улицы я беру название района и т.п.
Если мне, например, это не нужно, то брать данные из XML или из
собственной структуры не так уж и важно. XML в таком случае не мешает - как минимум.
Но если завтра прибегает заказчик и говорит, что нужны названия
улиц к домам, то при наличии XML это делается несколькими строками.
В объектах же придется создавать иерархию....
Нужно дать пользователю подвигать дома?
я просто меняю атрибуты координат и шлю на сервак ВЕСЬ XML,
в котором данные изменились только в одном месте.
Трудозатраты на закидывание в базу - ноль без палочки.
Для пользователя и для базы это незаметно.
В крайнем случае, если XML большой,
я могу отличия от базового XML в базу прописать по ID узла.
Как поступать в таком случае с объектами - не очень понятно.
И главное: чем же мешает XML в твоем примере?
это были мои аргументы.
спасибо.
И я попробую уточнить условия:
1. Мы получаем данные в виде XML.
2. Это оптимальный вид для наших нужд, т.е. иерархические связи играют важную роль.
В противном случае к рассматриваемому вопросу это отношения не имеет.
3. После стандартного парсинга можно:
- оставить XML структуру как есть, навесив при необходимости классы на узлы.
- распарсить в набор объектов неких классов и XML убить.
Мое утверждение сводится к тому, что в подавляющем большинстве
случаев (моя практика дает порядка 99%) нет необходимости в
перегоне узлов в объекты и, более того, такой перегон вреден:
- лишние затраты ресурсов компа
- лишние трудозатраты
- снижение унификации и читабельности кода
собственно вот.
Ты хочешь уточнить мое условие или предлагаешь свое?
ни то ни другое.
вопрос был задан господином __i и собственно его мы обсуждаем.
соответственно:
1. прямо указано в вопросе
2. если иерархические связи не играют роли, то XML-ём это назвать
можно лишь условно и мои утверждения к таким случаям не относятся.
3. это варианты развития событий, не более того.
ни то ни другое.
вопрос был задан господином __i и собственно его мы обсуждаем.
Я это понял как отказ от обсуждения примера, о котором ты просил. Впрочем, еще остается г-н iNils.
2. если иерархические связи не играют роли, то XML-ём это назвать можно лишь условно и мои утверждения к таким случаям не относятся.
Это передергивание сразу по двум пунктам. Во-первых, XML есть вполне четко определенный термин. И попытки нечто назвать не-XML'ом только на том основании, что это не ложится в твою схему аргументации -- по меньшей мере смешно. Не называй. Твое право. Но к обсуждаемой теме это не имеет никакого отношения.
Во-вторых, я не вижу, где в этом треде идет речь о несущественности иерархических связей. Соответственно, мягко говоря, непонятно, с какой целью ты вставил эту фразу.
Кстати, со своей стороны предлагаю сторонникам точки зрения "работать непосредственно с DOM" привести пример, иллюстрирующий порочность записи данных в объекты с последующим отбрасыванием дерева.
Готов обсудить этот пример.
да, в таком случае мои утверждения не относятся к твоему примеру.
и просто обсуждать поставленный вопрос, не предполагая, что
иерархические связи в обсуждаемом XML играют важную роль,
то можно смело утверждать, например, что лучше всего
XML перегонять в массив, имея себе ввиду XML документ вида:
<data>1,2,3,4,5,6,7,8,9</data>
- в таком случае выбор XML не более чем случайность.
мне кажется, довольно очевидно, если не предполагать существование и
важность иерархических связей в XML то и говорить-то не о чем,
поскольку любой текстовый документ может быть загружен с помощью
объекта XML - и тут мы вообще теряем основу для обсуждения.
кстати, мои утверждения построены на заданном господином __i вопросе,
в котором говорилось о стуктуре/объекте типа дерева - разумеется деревом можно назвать и вот это:
<data>1,2,3,4,5,6,7,8,9</data>
- но я как-то не особо знаком с людьми, которые бы это назвали
структурой или деревом.
Возможно, ты первый такой среди тех, с кем я когда-либо общался.
И еще: это не передергивание.
Это пояснение того, как я понимаю вопрос.
разумеется деревом можно назвать и вот это:
<data>1,2,3,4,5,6,7,8,9</data>
Друг мой, тебе еще не надоело уводить разговор в оффтопик? Лично меня не интересует обсуждение "является ли деревом <data>1,2,3,4,5,6,7,8,9</data>". Думаю, автора треда этот схоластический вопрос тоже не слишком интересует.
Не надо этих разговоров в пользу бедных.
Итак, поскольку для моего примера решения так и не поступило (напоминаю, что я готов дать любые необходимые уточнения по условию задачи), то я по-прежнему готов рассмотреть пример оппонентов.
Кстати, со своей стороны предлагаю сторонникам точки зрения "работать непосредственно с DOM" привести пример, иллюстрирующий порочность записи данных в объекты с последующим отбрасыванием дерева.
Оппоненты, правда, пока ограничиваются мудрыми высказываниями типа "любой текстовый документ может быть загружен с помощью объекта XML". Трудно не процитировать г-на iNils'а, чудесным образом предвосхитившего этот поворот дискуссии: "Обожаю когда кидаются "умными" словами с высокоподнятой головой".
Если оппоненты иссякли по части дискуссии строго техничского характера, то я готов исполнить соло на тему "когда и почему нужно переводить из DOM в свою структуру". Просто дайте отмашку.
P.S. Кстати, дружок, не надо играть фразами типа "Возможно, ты первый такой среди тех, с кем я когда-либо общался". Я уже намекал тебе о неуместности перехода на личности. Я ведь не позволяю себе формально безукоризненных высказываний "Возможно, BitSky является тайным педерастом со склонностью к зоофилии". Воздержись и ты, please, от таких приемов ведения дискуссии.
Класно! Жаль, что я не смог участвовать в етом избиении младенцев.
Crazy, отдельное спасибо, что не перешел на личности, а все ответы даже на самые тупые вопросы аргументировал - я б так не смог.
На последок (я надеюсь) все-таки отвечу на адресованый мне топик.
А чем XML отличается "от массива стрингов с древовидной структурой"? :)
Тем, что хмл-документ сам себя описывает как обект. Тоесть кроме тупо-даных в нем сохраняется куча служебной информации, которая нужна для подальшей с ним работы. Но ты ведь сам ето знаеш не хуже моего ;).
А если ето не использовать - да ето будет тупое дерево строк.
KidsKilla
15.10.2005, 15:30
Можно ввязваться? =)
ответ на:
XML-документ содержит карту. Объекты -- дома. Доступ мне нужен по координатам X/Y. Чем мне поможет использование встроенных в DOM средств?
Предыстория:
Когдато на ruFlash прошла эта же тема. и обсуждения были даже жарче. именно тогда ив привёл пример, явно подходящий под эту ситуацию, странно что это же объяснение не проскользнуло здесь. не суть, будет время, найду то письмо, выложу.
Суть такова, что важен подход к задаче. Всё зависит от того как ты строишь основную схему:
Задача: создать карту с "горячими областями", домами, при наведении на которые выводится информация о них. (поправьте, если я не правильно понял условие)
а) карта создаётся вручную во флеше, в хмл у нас только данные о доме.
б) карта создаётся во флеше, но дома, инфо о них и т.п. создаются непосредственно в свфке в режиме админки. в хмл у нас та вся инфа, от координат домов, до описания по ним и т.п.
Решение:
а) при создании карты мы раздаём домам названия (фамилии владельцев). мув "дом" вложен в мув "улица", та в "город" и т.п. (древовидная структура)
это же дерево мы создаём в хмл, а потом, о чудо: 1 раз проходимся по карте, присваивая соответственные узлы хмл к мувикам, к примеру в виде параметра prop_xml. ноде можно дать параметр assigned_mc. далее, при наведении на мув у нас есть ссылка на нужную ноду: this.prop_xml, родителя(улица): this.prop_xml.parentNode, всех соседей по улице: this.prop_xml.parentNode.childNodes и т.п. можно и обратно, из ноды узнать соответственный мув.
б) отличается тем, что карта строится непосредственно из хмл.
п.с. в пользу хмл говорит и то, что серваку ты будешь хмл отдавать в том виде как он есть, не писать сериализатор\десериализатор, а вот непонятный объект ты просто так серваку не отдашь.
п.п.с. ждём-с примеры, когда нужно хмл выбросить, оставить рез-т парсера.
А итог то где? Кроме перекидыванием фраз на основе которых всем должно быть понятно, что тут бьются "монстры" ничего и нет. Простые смертные вас не поймут.
KidsKilla
15.10.2005, 15:47
А итог то где? Кроме перекидыванием фраз на основе которых всем должно быть понятно, что тут бьются "монстры" ничего и нет. Простые смертные вас не поймут.
тот месседж ива был написан столь же непонятно как и весь тред, но он поменял мой подход к программированию в целом. можебыть кому-то из нубов тоже поможет ;)
2Crazy: извини, если какое либо из моих высказываний показалось тебе
мммм... некорректным.
Возможно я был несколько раздражен в тот момент.
Что касается меня, то я явный зоофил со склонностью к педерастии.
Но не наоборот.
И извини еще раз.
Я это понял как отказ от обсуждения примера
Да, я отказываюсь спорить по поводу твоего примера,
поскольку я СОГЛАСЕН с тобой.
Поскольку, как уже говорил ранее, мои утверждения не распространяются
на документы не имеющие иерархических связей.
Не более того.
Итак:
1. Я согласен с тобой, что многие XML объекты выгоднее распарсить в собственную структуру.
2. Я утверждаю, что те XML объекты, иерархические связи играют заметную роль
тащить в собственную структуру невыгодно в 99% случаев.
Я готов привести десятки примеров, причем живых, реально существующих.
Вот часто встречающиеся типы таких задач:
1. Древовидные меню.
2. Иерархические карты (город-район-улица-дом).
3. Описания структур организаций
и т.п.
спасибо.
2KidsKilla: напиши плз на iv сабака design.ru, я тебе свою книжку пришлю,
если ты работаешь в той технологии, что я описал, то из книжки может чего еще
почерпнуть удастся, а мож и чем со мной поделишься из собственных находок. :)
спасибо.
2. Я утверждаю, что те XML объекты, иерархические связи играют заметную роль тащить в собственную структуру невыгодно в 99% случаев.
Даже в случае, когда на одну иерархичускую связь приходится десяток других связей, не подерживаемых DOM?
возможно нет. от ситуации зависит.
но в общем, как правило, XML не помеха другим связям.
Ok. К вопросу "не помеха" мы еще вернемся. А сейчас перейдем к самой существенной части.
Мы оставляем данные в DOM-дереве для того, чтобы ими потом пользоваться, не так ли? Т.е. это означает, что в программе будет изрядное число место, где стоят обращения к данным этого дерева, используя DOM API и делая вполне фиксированные предположения о структуре этого дерева. Т.е. в программе есть ряд мест, код которых зависит от структуры конкретного типа XML-документа. И эти места де-факто "размазаны" по коду.
Я пока правильно излагаю?
KidsKilla
15.10.2005, 17:50
совершенно не обязательно:
вариант с примером:
строим флешку в зависимости от хмл: attachMovie(node.nodeName, node.nodeName+"_"+depth, depth) bla-bla-bla...
В этом варианте DOM-дерево нам более не требуется, так?
Меня в даннй момент интересует именно случай, когда мы преднамеренно хотим сохранить дерево и длительное время брать из него данные.
да, ты привел пример того, как не надо работать с 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
также очень здорово получаются админы, которые являются 2 в 1.
т.е. одна и та же флэшка является и админом и юзерским приложением.
отличие в том, что в случае админа я говорю через flashvars: admin=1.
В итоге человек, имеющий права админа прямо на HTML странице
вносит изменения в данные - например, двигает, добавляет/удаляет
города на карте.
в этом случае при драге экземпляр говорит узлу:
this.in_xml.attributes._x = this._x
this.in_xml.attributes._y = this._y
XML при этом сохраняется, не конвертится,
его данные не изменяются нигде, кроме как в нужном узле.
После чего админ жмет кнопку "сохранить" и XML улетает на сервак,
где записывается as is.
- это иллюстрация для опровержения:Даже если нужно записать данные на сервер, то вариант "передать заново всю кучу данных, включая неизменившиеся части" является наихудшим.
скажем так: не всегда. далеко не всегда.
да, ты привел пример того, как не надо работать с XML.
Я понял это утверждение так:
1. Говоря о работе с XML ты никогда не имел в виду такой вариант и предаешь его анафеме как однозначно ламерский и непригодный к практическому использованию.
2. Когда ты говоришь, что "создаваемые на основе данных объекты имеют некий интерфейс общения с XML и, как правило, сами не знают кто они такие и кто их соседи и т.п. Но они четко знают кто их узел." ты описываешь ситуацию, как надо работать с XML. И которая не содержит проблем описанного мной сценария.
Поправь меня, если я понял тебя неверно. Если же все так и есть, то не мог бы ты обозначить, почему упомянутый мной сценарий считаешь непригодным к практическому использованию? Мне хотелось бы убедиться, что мы имеем в виду одни и те же недостатки.
Чтобы не было недоразумений, я повторю текст:
Мы оставляем данные в DOM-дереве для того, чтобы ими потом пользоваться, не так ли? Т.е. это означает, что в программе будет изрядное число место, где стоят обращения к данным этого дерева, используя DOM API и делая вполне фиксированные предположения о структуре этого дерева. Т.е. в программе есть ряд мест, код которых зависит от структуры конкретного типа XML-документа. И эти места де-факто "размазаны" по коду.
1. скажем так: такой подход имеет весьма и весьма существенные недостатки.
2. решает многие проблемы. стандартизирует подход.
ты сам же и обозначил проблемы:
- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.
в моем случае XML рекурсивно строит сцену исходя из собственной структуры.
как правило делается это одним методом, который живет в надклассе.
в развернутых случаях:
- получением XML списка соответствия классов
- получение собственно XML данных
- переход на первый узел
- получение ссылки на класс для построения экземпляра
(в зависимости от признаков узла, например имя узла, тип узла или
некий атрибут -- по ситуации)
- добавление экземпляра на сцену, возможно статическим методом класса,
передача экземпляру ссылки на узел.
-- в экземпляре: инициализация, сообщение узлу о себе
-- при необходимости вызов построения дочерних экземпляров на основе переданного узла
--- в экземпляре....
так рекурсивно строится вся сцена.
и еще добавлю: можно испоганить всё что угодно.
самые хорошие принципы при неправильном использовании совершенно бесполезны.
ты сам же и обозначил проблемы:
Для меня было важно получить подтверждение того, что ты находишь их существенными. Итак, описанный мной сценарий непригоден к использованию, поскольку:
- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.
Это единственные критерии, которые делают этот сценарий непригодным или ты полагаешь, что есть и другие, которые также стоит рассмотреть?
Являются ли они достаточными для того, чтобы решить, что сценарий, для которого они храктерны, если не худший, то по крайней мере не рекомендуемый к использованию без тщательного исследования последствий в каждом конкретном случае применения?
processor
16.10.2005, 01:46
Не читал, что тут написано ( может и не в тему буду ), но по топику:
- с XML обращение как с массивом , поэтому переводить в другие форматы смысла нет.
- небольшое количество переменных лучше пользовать LoadVars, большое кол-во - XML
- К любому NODE можно обращаться по ID , независимо на каком уровне он находиться.
KidsKilla
16.10.2005, 02:17
Не читал, что тут написано ( может и не в тему буду ), но по топику:
- с XML обращение как с массивом , поэтому переводить в другие форматы смысла нет.
- небольшое количество переменных лучше пользовать LoadVars, большое кол-во - XML
- К любому NODE можно обращаться по ID , независимо на каком уровне он находиться.
не в тему.
К любому NODE можно обращаться по ID , независимо на каком уровне он находиться.
swf сделаный под 8-ку это не поддерживает, по крайне мере в том виде, что использовалось раньше.
Не читал, что тут написано
Заметно.
processor
16.10.2005, 12:08
в 8рке поддерживаеться idMap или как массив xml[id1][id2][id3]
Создаваемые на основе данных объекты имеют некий
интерфейс общения с XML и, как правило, сами не знают
кто они такие и кто их соседи и т.п.
Но они четко знают кто их узел. В момент создания
они также регистрируются в своем узле и инициализируются.
Они не хранят данные о собственном состоянии.
Вообще то ето (если я тебя правильно понял) называется "Адаптер".
Тоесть во избежание
- обращения к данным используя фиксированные предположения о структуре
- места в коде зависящие от структуры и размазанность.
ты делаеш адаптер, который имеет свой интерфейс (который соответствует интерфейсу нужного обекта), и который непосредственно взаимодействует с хмл. Я правильно понял?
Ну тогда вся разница только в том, что
Они не хранят данные о собственном состоянии.
А даные хранятся в хмл.
Если поступать так, то нету ПРИНЦИПИАЛЬНОЙ разницы как работать. используя такой метод теряються все преимущества и недостатки хмл, которые описывались выше.
Единственый +: не нужно опять сериализовать для отправки на серевер.
Единственый -: ето медленее (при большых обемах данных ты поразишся насколько).
KidsKilla
16.10.2005, 20:34
Mokus, ты предлагаешь сперва загрузить хмл, перевести в нужный тебе вид, и потом начать раздачу слонов? т.е. после этого привязывать результат парсинга к инстансам, при чём попутно создавая свой собственный api?
поясню схему ива:
- мы работаем ИСКЛЮЧИТЕЛЬНО с хмл. все пересчёты завязаны на него,
- навигация по узлам стандартизована.
- вся перерисовка происходит только по окончании рассчётов (обязательное условие для игр, например)
- безбоязненно создаём-удаляем инстансы с сохранением свойств (увеличение производительности при минимальных трудозатратах)
всё это можно, конечно, проделать и с собственным объектом, но налицо 3 минуса:
1) сериализация
2) одноразовость парсеров. иначе ни о каких оптимизациях по сравнению с хмл речь не идёт
3) уникальность (одноразовость, а отсюда и сумбурность) API.
вот вам принципиальная разница.
минусы хмл не в медленности, а в зависимости от конкретной структуры (почти обязательно древовидная), да и то далеко не всегда. опять же всё зависит от подхода и реализации.
ОГО, как всех зацепило, извените что не принимал участия в дисскусии - небыло инета.
Прочитав все так и не смог сделать решить, что лучше.
Из выше сказаного я понял, что действовать нужно исходя из условий проекта:
1. Если ХМЛ документ используеться просто как данные для заполнения чего нить, то смысла нету их гнать в структуру.
2 Если ХМЛ служит как стартовые данные для какихто объектов которые будут ими манипулировать, создавать/иметь другие свойства то все же лучше их зафигачить в свою структуру? (пример: Тесты, В ХМЛ"е лежат вопросы, вопросы варианы ответов. каждый вопрос и каждый ответ имеет свой ID, Флешка обратно отсылает ХМЛ который содержит ID-вопроса ID - ответа на него. Так вот ХМЛ содержит данные заполнения для вопроса, а вопрос сам по себе должен иметь свойства как "был дан ответ на него","какой был дан ответ на него" эти своиства не приходят с ХМЛ, т.к. по умолчанию они раввны андефайнед %)) так если смысл тягать туда сюда данные из ХМЛ, когда мы можем заколбасить свою структура с нужными данными и свойствами и пользоваться ею)
Mokus, ты предлагаешь сперва загрузить хмл, перевести в нужный тебе вид, и потом начать раздачу слонов? т.е. после этого привязывать результат парсинга к инстансам, при чём попутно создавая свой собственный api?
Я вообще ничего не предлагал, +пару раз переспрашивал правильно ли я понял - наверно неправильно. Видно я просто переоценил немного елегантность Вашей схемы.
2) одноразовость парсеров. иначе ни о каких оптимизациях по сравнению с хмл речь не идёт
Как раз очень даже идет. Чесно говоря не понял, как такие заяления вообще можна делать.
3) уникальность (одноразовость, а отсюда и сумбурность) API.
А ето вообще супер-заявление!
А как Ты вообще работаеш с тучей обектов у которых разные API?
Как вообще у разных типов с разными предназначениями могут быть одинаковые API? Или я чето не понял, или Ты меня просто отправил в нокаут.
BitSky, мои вопросы вызвали какие-то проблемы или просто нет времени?
- выходные. я долько добрался до компа. ща впрягусь
Это единственные критерии, которые делают этот сценарий непригодным или ты полагаешь, что есть и другие, которые также стоит рассмотреть? - на этот вопрос и последующие ответить почти невозможно.
Нужна конкретика. Всё что я могу сейчас, похоже на алаверды, не более.
Ты говоришь: "есть такой-то подход с такими-то недостатками.
Как ты думаешь, какие недостатки у данного подхода?"
- и видишь мой ответ а-ля "алаверды".
Если мы хотим проанализировать ситуацию хоть сколь-нибудь детально,
мы можем сделать следующее:
Берем проект, например, древовидное меню.
Описываем логику построения, каждый своим способом.
Рассматриваем.
При необходимости, углубляемся дальше.
И еще:
Я хочу попросить г-на Mokus перейти на более деловой тон.
Меня огорчает, когда исключительно деловой вопрос
начинает обсуждаться в таком тоне.
Иногда постебаться можно, но когда кроме стеба нет ничего,
то, возможно, лучше эфир не засорять.
Спасибо.
Итак, если согласны, давайте описывать проект, сравнивать подходы.
Берем проект, например, древовидное меню.
Ну ето не совсем чесно - древовидное меню - родной для хмл обект. И даже Макромедиа в своем контроле Tree использовала хмл-структуру.
Давай возьмем чето поинтереснее.
Я хочу попросить г-на Mokus перейти на более деловой тон.
Меня огорчает, когда исключительно деловой вопрос
начинает обсуждаться в таком тоне.
Иногда постебаться можно, но когда кроме стеба нет ничего,
то, возможно, лучше эфир не засорять.
Жутко извиняюсь, просто на некоторые замечания сложно отвечать серйозно. Впредь постараюсь их полностю игнорировать.
давайте возмем проект предложенный мной %)))
ну я не предложил этот проект не потому, что я сам дятел и хочу чтоб за меня поработали. Я решил бы его таким способом:
1 получаю ХМЛ с тестами и разбираю его и добавляю данные в массив объектов cледующего вида
Object{
id : id voprosa берем из ХМЛ;
txt: text voprosa берем из ХМЛ;
ans : array of Object { txt - text voprosa берем из ХМЛ; id - id otveta берем из ХМЛ; choose: vibran li etot otvet}
answde : пользователь отвечал на этот вопрос.
}
2. Исходя из номера вопроса я рисую соответствующий вид в окне:
3. по окончанию теста я стряпаю ХМЛ следующего вида:
<vopros id=xxx>
<ans id=xxx/>
<ans id=xxx/>
...
</vopros>
я не против тестов.
впрочем и другие варианты готов рассмотреть.
Object{
id : id voprosa берем из ХМЛ;
txt: text voprosa берем из ХМЛ;
ans : array of Object { txt - text voprosa берем из ХМЛ; id - id otveta берем из ХМЛ; choose: vibran li etot otvet}
answde : пользователь отвечал на этот вопрос.
}
Потом проходит год и оказывается, что нужно делать опросник на N языках. И меняется структура XML. Вместо тэга <text> с текстом вопроса появлется N тэгов вида <text lang="en">Question</text>. Се ля ви.
В варианте с копированием данных в свою объектную структуру мы будем иметь четко локализованное изменение.
Потом проходит год и оказывается, что нужно делать опросник на N языках. И меняется структура XML. Вместо тэга <text> с текстом вопроса появлется N тэгов вида <text lang="en">Question</text>. Се ля ви.
я привел упрощенный вариант теста, в реалии там еще несколько штук полей , эт раз , во - вторых вся хмля генериться на сервере и шлется юзеру, т.е. вопрос об языках будет решаться тамже!!!!
изменения в XML будут выглядеть так:
было:
this.my_text = this.in_xml.firstChild.nodeValue
стало
this.my_text = this.in_xml.childNodes[_root.lang].nodeValue
и всё.
кстате что касаеться языка и проч это уже часности. кто мне помешает сделать так:
Object{
id : id voprosa берем из ХМЛ;
txt: object {ru: text; en:..... }
.......
}
поменять нужно будет немного кода и все
2BitSky
а как быть со свойствами которых нету в хмл?
как будем запоминать, что пользователь уже отвечал на этот вопрос?
изменения в XML будут выглядеть так:
было:
this.my_text = this.in_xml.firstChild.nodeValue
стало
this.my_text = this.in_xml.childNodes[_root.lang].nodeValue
Мы все еще говорим о варианте, в котором нет копирования данных в свою объектную структуру?
во - вторых вся хмля генериться на сервере и шлется юзеру, т.е. вопрос об языках будет решаться тамже!!!!
Агащасблин. :) Большая нагрузка. HTTP-акселератор и включенное кэширование. Пользователи благополучно получают один и тот же XML. :)
изменения в XML будут выглядеть так:
было:
this.my_text = this.in_xml.firstChild.nodeValue
стало
this.my_text = this.in_xml.childNodes[_root.lang].nodeValue
и всё.
и все?? и ты будеш перелопачивать весь код и везде, где надо получить текст вопроса будеш менять одну строчку? (заметь ето очень утрированый пример)
в случае с обектом ты один раз меняеш геттер.
я ответил по данному примеру.
более универсальный вариант:
стало:
this.my_text = this.in_xml._text
и также создаем геттер текста в подклассе XMLNode.
ну это не проблема - не даем кешировать, эт раз
во вторых ты думаешь, что выгоднее
слать ХМЛ в в 2-3-...n (где n количество языков) раз больше?
И ВАЩЕ не в этом вопрос, вопрос как лучше организовать хранение данных (хмл или своя структура !!!!)
и также создаем геттер текста в подклассе XMLNode.
Т.е. де-факто мы СОЗДАЕМ свою объектную структуру, но совмещает ее ЭКЗЕМПЛЯРЫ с экземплярами уже созданных парсером XMLNode.
Вся экономия в этом случае ограничена тем, что мы повторно используем данные и код связкй parent/child, next/prev sibling?
ну это не проблема - не даем кешировать
Это типа как контролера обмануть -- купить билет и не поехать?
выгоднее слать ХМЛ в в 2-3-...n (где n количество языков) раз больше?
Серверу, стоящему за HTTP-акселератором выгоднее послать 1 раз текст на N языках, чем 1000 раз одноязычные тексты.
И ВАЩЕ не в этом вопрос, вопрос как лучше организовать хранение данных (хмл или своя структура !!!!)
Ты сам отвлекся фразой про сервер. ;)
я ответил по данному примеру.
более универсальный вариант:
стало:
this.my_text = this.in_xml._text
и также создаем геттер текста в подклассе XMLNode.
Значит ты все-таки создаеш адаптер (а уважаемый KidsKilla почемуто пробовал меня в етом разубедить). Я уже про ето писал - поищи мои посты выше. И еще одно - в любом случае легче один раз написать (или взять чужой) классный парсер, чем каждый создавать новые адаптеры.
Серверу, стоящему за HTTP-акселератором выгоднее послать 1 раз текст на N языках, чем 1000 раз одноязычные тексты.
а пользователю? выгодней принять 100 к или 10 мб? че ты о себе заботишься %))
просто обидно ты меня отвлекаешь!!!
А из совсем выше сказаного стало ясно. Сам по себе класс XML хорош, но мал, как не тужся придется или ченить в него добавлять для более удобной работы или создавать совй объект для совсем удобной работы %)))
а пользователю? выгодней принять 100 к или 10 мб? че ты о себе заботишься %))
Во-первых, отношение в реальной жизни будет не 10 к 1, а 3-4 к 1. :)
Во-вторых, 11 сентября научило меня в первую очередь забоиться о себе (я про Национальную Веб Катастрофу).
просто обидно ты меня отвлекаешь!!!
А! Так это, выходит, моя реплика была: "во - вторых вся хмля генериться на сервере и шлется юзеру, т.е. вопрос об языках будет решаться тамже!!!!"
А из совсем выше сказаного стало ясно. Сам по себе класс XML хорош, но мал, как не тужся придется или ченить в него добавлять для более удобной работы или создавать совй объект для совсем удобной работы %)))
Правильно.
разумеется мы создаем классы экземпляров.
например, у меня лежит мувик с текст полем
- это тот объект, который отобразит один из ответов
он имеет собственный класс.
но этот класс не хранит никаких данных,
не имеет права ничего делать, кроме как обслуживать себя
и посылать своему узлу события.
к примеру:
мы ответили на вопрос, кликнув по нему.
экземпляр послал сообщение своему узлу
узел обработал сообщение:
сохранил в себе ответ, закрыл текущий вопрос,
передал управление следующему узлу.
тот открыл свой вопрос.
если мы заходтим вернуться на предыдущий вопрос,
то посылаем соответствующее сообщение активному узлу,
тот закрывает текущий вопрос, передает управление предыдущему узлу.
предыдуший узел открывает свой вопрос,
экземпляр, при инициализации получает сохраненные
в узле данные (выбранный ответ на вопрос)
и соответствующим образом себя отображает.
примерно так.
А из совсем выше сказаного стало ясно. Сам по себе класс XML хорош, но мал, как не тужся придется или ченить в него добавлять для более удобной работы или создавать совй объект для совсем удобной работы %)))
Ура Мы победили - иду пить пиво.
да, сам по себе класс XML не решает ничего.
я про то и говорю: нужно его расширять.
разумеется мы создаем в нем новые методы и свойства.
но при этом, те стандартные свойства и методы мы сохраняем и
активно используем. Этим достигаем преимуществ.
разумеется мы создаем классы экземпляров.
...причем количество классов будет таким же, как если бы мы делали параллельную объектную структуру.
Я поскипал описание сценария, поскольку хотел бы рассмотреть нечто более реалистичное.
Итак, у нас есть 100 вопросов. Чтобы была иерархия мы их сгруппируем в темы. По 10 штук в теме.
Пользователь участвует в опросе, который включает 30 вопросов. Вопросы выбираются случайным образом так, чтобы из каждой темы был выбран хотя бы один вопрос. И задаются пользователи, разумеется, не в том порядке, в котором они были в общем списке -- не забудем их перемешать.
В случае параллельной объектой структуры здесь все очевидно.
Как будет выглядеть в этом случае работа с XML?
к примеру:
мы ответили на вопрос, кликнув по нему.
экземпляр послал сообщение своему узлу
узел обработал сообщение:
сохранил в себе ответ, закрыл текущий вопрос,
передал управление следующему узлу.
тот открыл свой вопрос.
Повторюсь третий раз - ето Адаптер!!! (здесь у тебя правда еще и Обсервер и Нотифайер - но ето не важно).
Ответ на ето ищи выше (можеш по ключевому слову "Адаптер" ;) ).
собственно суть ответа и сводилась к тому, что:
узлы XML есть не что иное, как обычные объекты.
парсинг XML в другую объектную структуру - лишь удаление стандартных
связей между этими объектами (узлами), а при необходимости
- замена на собственные.
когда иерархические связи играют совсем малую роль - это не критично.
и я согласен с тем, что это можно перегнать в собственную объектную структуру,
другое дело, что часто в этом нет особой необходимости.
но вот когда иерархические связи важны, то замена навигации по XML
на собственную навигацию - не есть хорошо.
да, это адаптер. никто и не спорит.
вопрос лишь в том, где он живет.
Пользователь участвует в опросе, который включает 30 вопросов. Вопросы выбираются случайным образом так, чтобы из каждой темы был выбран хотя бы один вопрос. И задаются пользователи, разумеется, не в том порядке, в котором они были в общем списке -- не забудем их перемешать.
Эт ты канешно загнул %))
ну здесь есть тоже доля правды - нужно что пользователь в любое время мог перейти на любой вопрос 2BitSky ваши действия?
- передать управление нужному узлу.
ты его можешь найти по ID или как тебе больше нравится.
собственно и прелесть XML в этом случае в том, что не нужно
делать никаких специальных методов доступа, а использовать те, что есть у XML.
Вся экономия в этом случае ограничена тем, что мы повторно используем данные и код связкй parent/child, next/prev sibling?
- не сразу увидел этот пост.
ответ: да. но не только.
делать никаких специальных методов доступа, а использовать те, что есть у XML.
Правда? Если не сложно -- как мне "средствами XML" достучаться до этого вопроса по его коду:
<question>
<id>Foo2562</id>
... всякая прочая муть ...
</question>
А где я возьму его ID ?, в моем примере ID это ID которое храниться в базе!!!. те это не порядковый номер вопроса в данном тесте.
а пользователь решил что он хочет ответить на 13 вопрос после 33! как быть?
в моем примере ID это ID которое храниться в базе!!!
В моем -- тоже.
P.S. Не надо такой экзальтации...
ну.. я бы рекомендовал id загнать в атрибуты, это серьезно упростило бы задачу.
если ты не можешь повлиять на XML, то задача тоже не сложна:
в подклассе org.dembicki.XMLE есть событие onInitNode.
примерно так:
function onInitNode () {
if (this.nodeName.toLowerCase() == "id") {
var id_obj = this.rootNode.id_obj = (this.rootNode.id_obj || {})
id_obj[this.firstChild.nodeValue] = this.parentNode
}
}
и создаешь, например, свойство доступа:
function get _question_by_id (id) {
return this.rootNode.id_obj[id]
}
и в любом узле получаешь:
var node = _question_by_id[any_id]
задача тоже не сложна
Вопрос не в сложности. Просто фраза "не нужно
делать никаких специальных методов доступа, а использовать те, что есть у XML" не оказалась истинной.
разумеется, если XML не заточен под стандартные средства доступа,
например, нужен доступ по ID а он живет не в атрибутах,
то придется создавать собственные методы доступа.
отличие от объектной структуры в том, что в объектной структуре,
это нужно делать всегда.
при сохранении XML это нужно делать редко, чаще если XML
сделан не по уму.
В моем -- тоже.
P.S. Не надо такой экзальтации...
не увидел сообщения %(( поэтому мы сказали об одном и томже %))
я психовать начну.
почему ты так некрасиво себя ведешь?
"собственно и прелесть XML В ЭТОМ СЛУЧАЕ в том, что не нужно...."
зачем ты выдергиваешь часть фразы, переворачивая с ног на голову????
- фраза истинна, когда ID задан как ID а не как название узла.
отличие от объектной структуры в том, что в объектной структуре, это нужно делать всегда.
Определенно. Вот только неверно было бы думать, что для этого требуется каждый раз заново программировать нужный вид доступа. :)
Взамен же получается объект, который делает в точности то, что было нужно.
чаще если XML сделан не по уму.
Я переведу на русский: "во всех случаях, когда структура объектной модели не ограничена примитивными иерархическими связями" :)
я психовать начну.
Э... Если я посоветую пить настой травы валерианы -- это не будет сочтено неуместным вмешательством в права личности? :)
К обсуждению технических вопросов нужно относиться спокойно.
почему ты так некрасиво себя ведешь?
Если под "некрасиво себя вести" понимается "находить изъяны в твоих утверждениях", то ответ будет таков:
1. Ради достижения истины.
2. Для упрочения собственного понимания проблемы.
"собственно и прелесть XML В ЭТОМ СЛУЧАЕ в том, что не нужно...."
зачем ты выдергиваешь часть фразы, переворачивая с ног на голову????
Ты полагаешь, что я лишил фразу контекста? Ok. Я готов принести извинения, если ты укажешь, как влияет на ее понимание отрезанная мной часть.
- фраза истинна, когда ID задан как ID а не как название узла.
Вот видишь, ты начал вводить дополнительные ограничения. Это не плохо, это хорошо.
В ходе этого обсуждения мы продвинулись от постановки "так делать нужно всегда" к гораздо более ограниченной -- и горахдо более корректной -- формулировке: так нужно делать, если объектная модель имеет выраженную иерархическую структуру и объекты, к которым нужно получать быстрый прямой доступ, имеют уникальные строковые ключи, заданные в виде атрибутов узлов. (Кстати, поправь меня, если я ошибаюсь).
P.S. Излишняя эмоциональность в обсуждении обычно свидетельсвует о потребности доказать в ущерб потребности понять.
Да, ты поставил всё с ног да голову выдрав кусок из контекста:
1. Когда речь идет о ID узла, а в ДАННОМ случае подразумевалось
ровно то, что подразумевается в спецификации XML и что
ПО УМОЛЧАНИЮ подразумевается, когда речь идет об ID узла.
2. От частного правильного утверждения, перешел к общему неправильному.
Вложив собственный смысл в мое утверждение.
И как в прошлый раз после всего этого ты успешно опровергаешь....
то что сам же и напридумывал.
поэтому думаю, что ты находишь изъяны не в моих утверждениях,
а в собственных, придуманных тобою же.
Вот видишь, ты начал вводить дополнительные ограничения. - это не дополнительные ограничения.
Года я говорю, что узел можно найти по ID
то прости, 99.99% людей меня понимают так, как это прописано
в спецификации XML на W3C. Что вновь говорит о твоей уникальности.
Если мне понадобится сказать, что я советую найти узел
с именем ID, у которого дочерний текстовый узел содержит
уникальное значение, то я так и скажу.
так нужно делать, если объектная модель имеет выраженную иерархическую структуру - этого достаточно.
Да, ты поставил всё с ног да голову выдрав кусок из контекста:
1. Когда речь идет о ID узла, а в ДАННОМ случае подразумевалось
ровно то, что подразумевается в спецификации XML и что
ПО УМОЛЧАНИЮ подразумевается, когда речь идет об ID узла.
2. От частного правильного утверждения, перешел к общему неправильному.
Вложив собственный смысл в мое утверждение.
Вот полный текст твоего сообщения:
собственно и прелесть XML в этом случае в том, что не нужно
делать никаких специальных методов доступа, а использовать те, что есть у XML.
Боюсь, что тебя подводит память: здесь никогде не говорится об ID. По крайней мере, я этого не вижу.
- это не дополнительные ограничения.
Хм. А что это? Как ты предлагаешь назвать условие, соблюдение которого обязательно для того, чтобы твоя фраза была верна? Обязательным условием? Или как-то иначе?
Года я говорю, что узел можно найти по ID
то прости, 99.99% людей меня понимают так, как это прописано
в спецификации XML на W3C. Что вновь говорит о твоей уникальности.
Да, у меня определенно есть проблемы с уникальностью. Пятый раз перечитываю фразу -- и никак не вижу в ней упоминания ID. Помоги мне, please:
собственно и прелесть XML в этом случае в том, что не нужно
делать никаких специальных методов доступа, а использовать те, что есть у XML.
Как на счет извинений за необоснованные наезды в передергивании во время цитирования?
подразумевалось
ровно то, что подразумевается в спецификации XML
В спецификации ХМЛ нет ни слова про ID. Я повторюсь и скажу, что ХМЛ-документ описывает себя сам. ХМЛ специально придуман как максимально обобщенная модель.
и что ПО УМОЛЧАНИЮ подразумевается, когда речь идет об ID узла.
Кто определяет что подразумевается ПО УМОЛЧАНИЮ?
Вот полный текст твоего сообщения:
- не полный. сообщение состоит из двух постов и прямо ссылается на предыдущий.
Всем спасибо, до свидания.
- не полный. сообщение состоит из двух постов и прямо ссылается на предыдущий.
Оригинально. И в чем же был смысл преднамеренного разбиения на два поста? Я до сих пор думал, что человек помещает подряд два сообщения в том случае, если хочет, чтобы два его высказывания не были по-ошибке смешаны друг с другом.
А ты в каких целях это сделал?
Всем спасибо, до свидания.
Если вдруг появятся аргументы технического характера -- возвращайся. Только про извинения не забудь.
про извинения?
есть простой, опробованный способ выяснить, кто прав, кто виноват и кто должен извиняться.
Приглашаются сторонние люди и и решают кто прав, кто нет.
Смысл второго поста в том, что он уточняет предыдущий, за неимением возможности его изменить. Следуя за ним и прямо на него ссылаясь.
Смысл второго поста в том, что он уточняет предыдущий, за неимением возможности его изменить. Следуя за ним и прямо на него ссылаясь.
Там нет фразы "в уточнение предыдущего поста" или иного указания на то, что выделение во второй пост сделано по технической необходимости.
Соответственно, ты преднамеренно, либо случайно создал двусмысленные сообщение. После чего обвинил в преднамеренном искажении его смысла.
Я полагаю, что это требует извинений.
я не хочу объяснять очевидное.
если ты так ДЕЙСТВИТЕЛЬНО считаешь,
то я смею усомниться в твоих умственных способностях.
если ты хочешь извинений, то способ я тебе назвал.
если ты хочешь извинений, то способ я тебе назвал.
Извинения людей, все равно не умеющих отвечать за свои слова, мне без надобности. Я был заинтересован в их получении лишь до момента, когда осознал эту особенность.
K.A.T.A.F.A.L.K.E.R
17.10.2005, 20:03
Ну хоть кто-то кого-то в чем-то переубедил??? Да и вообще, народ, что вкуснее - варенье или колбаса? :rolleyes:
Я вначале говорил - "В споре истина рождается очень редко". Закончилось как всегда *****киданием за неименеем других аргументов. Хотя надеюсь, что господин __і получил исчерпывающий ответ.
KidsKilla
17.10.2005, 22:36
итог как всегда один:
в зависимости от ситуации и подхода и из конфетки может случиться *****, равно как и наоборот.
при грамотном подходе хмл не непонятный зверь, а друг и помошник...
Во-первых (и главное) - спасибо всем за все х/з сколько страниц на эту тему. Я пытался задать этот вопрос там, где ему место (в разделе XML), но там все ограничилось тремя жидкими постами...
Здесь я получил, что хотел.
Во-вторых. Инструменты предназначены для целевого использования (хотя, конечно, молотком можно измерить длину, а рулеткой забить гвоздь...). И с этой точки зрения Ив в самом начале и весьма конкретно обозначил свою позицию: XML выгодно использовать "напрямую", не перегоняя его в массивы или во что бы то ни было в случаях, когда древовидная структурированность данных играет решающую (или весомую) роль //не придирайтесь к словам с просьбами выразить эти эпитеты в процентах ))
Естественно, что для обработки XML-данных потребуются и иные инструменты помимо стандартных - это не говорит ни за, ни против сохранения данных в формате XML на "весь период использования" (где-то был такой довод от Crazy, на тему "что ж ты за другие инструменты хватаешься, работай стандартными XML-ными..."//мои извинения, если понял неверно, но, по-моему, смысл был такой...
В-третьих. Придирки к словам - не лучший способ ведения спора. А это у Crazy боевой прием (сужу по вещам, в которых понимаю хоть что-то - часть спора была мне недоступна, не эксперт). Судя по всему, Crazy - все-таки специалист, а из этого можно сделать вывод, что писаное Ивом он был в состоянии понять правильно, а не играть словами (чо в конце концов и кончилось практически руганью...)
Это не говоря уж о выражениях
В твоей практике такое не встречалось? Ничего страшного. Со временем начнешь писать более сложные программы.
и
Мсье хочет сказать, что никогда не работал с XML размером в мегабает и более? Ничего страшного, и это придет.
Ну ей-богу, как в песочнице...
И в-четвертых. Мои выводы (на моем этапе развития, конечно)
С "легкими" XML-никами (до 10-15 кБ, более - поэкспериментирую) однозначно буду работать, не перегоняя их "в другие форматы" (оговорюсь теперь сам: в случаях, когда древовидная структурированность данных играет решающую (или весомую) роль)
Как это в телевизоре...
"Пользуясь случаем, хочу передать привет..." - Иву спасибо за парсер, который я нарыл на Народе. Легкий, быстрый и красиво написаный (на мой "неэкспертный" взгляд)
есть практический опыт использования 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 выдает нечитабельную кашку.
удачи!
добавлю:
большинство удачных и часто используемых методов и свойств
стало частью класса org.dembicki.XMLE
в сети лежит соответственно.
при грамотном подходе хмл не непонятный зверь, а друг и помошник...
(Пишу сходу, без проверки. Так что заранее извиняюсь за возможные косякию)
В этом треде обсуждались де-факто три схемы работы с 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-тесты уже пройдены, остается де-факто тестирование пользовательского интерфейса и несколько интеграционных тестов.
Система готова.
Продолжение (не уместилось по объему) -- следующим сообщением.
Продолжение (не уместилось по объему) -- следующим сообщением.
Но жизнь системы не окончена. Рассмотрим несколько сценариев дальнейших событий:
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. Следствие предыдущего пункта и первого пунктов -- трудности при внесении изменений в реализацию.
Итак, с одной стороны -- сомнительная экономия от "повторного использования" родительско/дочерних связей (которые в действительности мы не используем), с другой -- разброд и шатания в коде.
Каждый выбирает сам. Дело добровольное.
1. Нет ни одной ссылки parent. Ввиду полного отсутствия необходимости.
2. Нет ни одной ссылки на соседний элемент. По той же причине.
3. Список всех дочерних элементов предоставляет только SelectedQuestions. - всё верно.
Чем менее значимы иерархические связи, тем меньше проблем при таком решении.
Тест "Семья и брак".
Все последующие вопросы зависят от предыдущих ответов.
Вложенность произвольная.
Количество вопросов произвольное.
По достижении дна ветки переходим на начало следующей ветки.
Произвольное количество откатов к предыдущему вопросу.
Подсветка "посещенных" ответов.
- В моем варианте реализации не изменится практически ничего
при переходе от теста описанного тобой к тесту описанному мной.
1. Объекты с замусоренным интерфейсом.... - нет ничего подобного.
Хм... даже интересно, с чего ты это взял?
Все роли строго расписаны. XML не отвечает за отображение вопроса,
а элемент понятия не имеет о том, каким будет следующий вопрос или
нечто в этом роде.
Обращений к parentNode нет в объекте и быть не может.
Объект знает только о своем узле и ни о чем более.
соответственно п.1, а так же 2 и 3, как построенные на нем - неверное предположение.
п.4 - не дублирование структуры документа а навигация по структуре,
поэтому так же - неверное предположение.
п.5 как основанный на 1 и 4 - также неверно.
Я бы предолжил не пытаться делать предположений о том, чего не знаешь,
а рассказать о том, о чем знаешь.
- В моем варианте реализации не изменится практически ничего при переходе от теста описанного тобой к тесту описанному мной.
Принципиальная разница в том, что я могу вместо расплывчатого и бесполезного "не изменится практически ничего" сразу сказать, что и как измениться в моем варианте.
Изменения коснутся:
XmlQuestionaryFactory. Добавлена обработка вложенных тэгов <question>.
Question. Добавляется список вложенных вопросов. Меняется код метода регистрации.
SelectedQuestions. Добавляется логика, управляющая выбором очередного вопроса и текущего количества доступных вопросов.
Кроме того, я сразу указал бы заказчику на странность в постановке задачи: при сохранении возможности вернуться и изменить ответ меняется состав вопросов, следующих за данным. И предложил бы набор решений этой проблемы. Но это уже совсем другая история...
Соответственно, я могу сразу написать unit-тесты для изменившегося кода и дать тестировщикам сведения, необходимые им для изменения плана тестирования.
Благодарю за хороший пример, иллюстрирующий преимущества рационального подхода к разработке ПО.
Я бы предолжил не пытаться делать предположений о том, чего не знаешь, а рассказать о том, о чем знаешь.
Я внимательно перечитал размещенные тобой сообщения, в которых ты немалое место уделяешь описанию технологии. С тем объемом подробностей и нюансов, которые ты счел уместным упомянуть. Я сделал из них именно такой вывод. Твое последнее сообщение его подтверждает.
Если ты писал все это вовсе не для того, чтобы это читали, после чего делали выводы и озвучивали предположения, то стоило экономнее отнестись к своему времени и нервам и просто ничего не писать. Или добавлять в конце "НА ОСНОВАНИИ ВЫШЕСКАЗАННОГО НЕЛЬЗЯ ДЕЛАТЬ ПРЕДПОЛОЖЕНИЯ". Не обязательно заглавными букавами.
Вполне может быть, что другие люди сделают из сказанного тобой другие выводы. Я свое мнение никому не навязываю и единственно правильным не считаю.
я могу .... сразу сказать- как будто я не могу сказать что изменится :)
изменится обработка событий в подклассе XML. и всё.
Кроме того, я сразу указал бы заказчику на странность ....- вопрос1 : вы изменяли мужу?
ответ 1: да
ответ 2: нет
- странно если в этом раскладе состав последующих вопросов не изменится,
а останется:
вопрос 2: сколько раз?
-- впрочем многие мужчины и женщины поступят так же :)
Я сделал из них именно такой вывод- мне кажется, что неправильный.
Возможно, причина в существенном недостатке информации
и полном отсутствии опыта использования данного метода.
Изложенное здесь мною это крохи...
Тебе не кажется что рановато делать такие утверждения?
НА ОСНОВАНИИ ВЫШЕСКАЗАННОГО НЕЛЬЗЯ ДЕЛАТЬ УТВЕРЖДЕНИЙ
от предположений до утверждений долгий и нелегкий путь...
Вполне может быть, что другие люди сделают из сказанного тобой другие выводы. - посмею сделать утверждение: каждый сделает собственные выводы.
Уфф, крэйзи, и не лень же... :)
- как будто я не могу сказать что изменится :)
Ты не сказал. А делать догадки о твоих возможностях мне неинтересно.
Уфф, крэйзи, и не лень же... :)
Надо же как-то развлекаться. :)
Спасибо за дискуссию
(Эта ваша штука мозги прочищает получше чем виски(с))
Вот почаще бы и в тех же дозах:)
(Билли заводи(с):)
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.