XML Parsing?

[stweet]

Проще, а если там null т.е. сие атрибута вообще нет?
Т.е. компилятор вообще отругает вас если вы попытаетесь обратиться к несуществующему атрибуту.

[Wolsh]

Если там null то условие не выполнится, будет false.
Компилятор? Ему-то откуда знать, что будет в загруженном в рантайм XML-файле?

var xml:XML = 
<data>
	<tag atr="True"/>
</data>
trace(String(xml..@atr[0]).toLowerCase() == "true"); // true
trace(String(xml..@grab[0]).toLowerCase() == "true"); // false, @grab нет в xml

[Партизан]

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

Проще, а если там null т.е. сие атрибута вообще нет?

При String(xml.fakeNode.@fakeid) будет просто пустая строка. Вы же можете задать атрибут у несуществующего нода, который в свою очередь создастся (еще одна фишка XML за которую я его люблю использовать)

[stweet]

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

(еще одна фишка XML за которую я его люблю использовать)

"Object" ни чем не уступает "XML", а лучше, вообще использовать типизированные шаблоны. Сложно работать с объектами о свойствах которых знает только автор.

[wvxvw]

*тяжелый вздох* Нет такого "ХМЛ - отличная вещь" - любая задача подразумевает работу с какой-то структурой данных, можно использовать хеш-таблицу (Object) - тогда запись и чтение быстрые, но элементы нельзя сортировать, они должны быть уникальными, тяжело выделять памяти именно столько, сколько нужно. Можно использовать массивы - тогда чтение-запись-итерация - быстрые, а изменение занимает много памяти. Можно использовать список, дерево, стек и т.д. для каждой задачи как правило есть либо оптимальное либо оптимальные решения. ХМЛ - это формат передачи данных (очень хреновый, но в рамках этой дискусси можно не вдаваться в подробности) - то, что его можно использовать как какую-то разновидность дерева - по своему и хорошо и плохо, т.как для каких-то задачь можно обойтись и самим ХМЛем - там где скорость не критична, а для каких-то нужно обязательно создавать свои структуры данных - но не факт, что хеш-таблица или массив будут теми самыми оптимальными структурами! Нужно всегда исходить из требований алгоритма в котором они используются. Например, искать лучше в деревьях, сортировать - в массивах и т.д.

[Партизан]

wvxvw, разве я навязываю вам использование XML? Если у вас к нему такая непереносимость, есть куча других форматов. Хоть по почте перфокарты передавайте, кто против? Может и дыхание равномернее станет
Для меня же XML - отличная вещь для передачи и получения структурированных данных. Более того, для меня это очень удобный формат для определенных задач. Однако я не в коем случае никого не убеждаю отказаться от всего остального и тем более подстраивать решение задачи под формат передачи или получения данных. Мне всего лишь непонятно в этой теме зачем между задачей и решением вклинивать лишние решения, такие как перевод полученного XML в Object дабы получить несколько строк из этого XML. Логичного объяснения этому я не вижу. Wolsh достаточно четко подметил нелогичность этих действий в одном из предыдущих постов:

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

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

[stweet]

Тема запускалась очень давно и признаться я не совсем припоминаю цель данной задачи. На сколько сейчас я представляю решение, так это работать с структурой данных а не:
"Так, пришла xml, чё за xml, куда её сунуть, снова парсить?"
или:
"так, что за xml разобрались, а что в ней есть, опять парсить?"
так же:
"хм, там xml должна лежать, не помню, в ней или в другой та или иная переменная, так, опять парсить".
Вероятно именно этого я и хотел избежать, нашёл решения у "К.Мука" писать свои типы данных и шаблонизировать. На "JAVA", если я не ошибаюсь, есть тому достойный пример которым всем тычат, шаблон "UserData" исходи из данной структуры. т.е. активное использование типов, геттеров-сеттеров, в общем полиморфизм полнейший))) Но во всяком случае ты всегда в подсказках можешь узреть что это за объект и что в нём есть. Это моя точка зрения на обмен данными, сейчас я активно использую JSON с ним работать удобнее при загрузке и создания объектов типа "PublicStaticDataInfo".

[-De-]

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

[Партизан]

Сообщение от -De-

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

Ваш пример не дает ясности. Без кода я кроме xml ничего не вижу более, если чо...

[-De-]

Есть локализационный xml в том вот формате. У локализации есть собсно одна функция "вернуть строку по ключу". Ключ записан в атрибуте (и может содержать пробелы).
И вот поиск по атрибуту

locXML.string.(@id == key)

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