E4X + FDT warnings
Alex Davydov
сабжа и решает ли кто ее вообще?
Когда после загрузки XML-файлика, пытаемся эффективно его парсить, типа:
genderMale = _xml.genderLabel.@male;
genderFemale = _xml.genderLabel.@female;
Где, соответственно, _xml - распарсенный файлик с основным нодом;
genderLabel - нод с атрибутами male & female
И мы имеем кучу ж0лтых подчёркиваний с сообщениями "Could not resolve
variable (may be an XML element name) genderMale at line XXX"
Решений типа понижения строгости проверок не предлагать! :)
Ivan Dembicki
> Вот, собственно, к топику о FDT с подчёркиваниями.. Кто как решает проблему
> сабжа и решает ли кто ее вообще?
- я создаю класс, например DataFormat, в нем прописываю все имена
нодов и атрибутов в статических константах:
parsing static const GENDER:String = "gender";
parsing static const MALE:String = "male";
.....
Классы парсера наследую от этого класса и использую вот так:
var isMale:Boolean = node.getAttribute(parsing::GENDER) == parsing::MALE;
Alex Davydov
Первым делом я стал пробовать расширяться от кастомного класса, где описывал
(пытался описывать) ноды\аттрибуты с типами данных.
Только не вышло ничего. От XML\XMLList фиг расширишься, т.к. оне - final
А как у Вас выглядит этот DataFormat?
Спасибо!
Ruslan Shestopal
parsing static const
= а что это за такое ключевое слово parsing? Впервые вижу.
--
http://ruslanshestopal.com | - freelance flash developer and a DJ
Ivan Dembicki
> = а что это за такое ключевое слово parsing? Впервые вижу.
- это namespace
Alex Davydov
Ivan Dembicki
> А как у Вас выглядит этот DataFormat?
- не надо расширяться от XML
У меня модель данных строится по принципу того, что каждому имени узла
соответствует класс и все эти классы наследуются от одного, например
DataNode, который, в свою очередь наследуется от DataFormat, а тот уже
от EventDispatcher.
Парсинг данных происходит так:
в DataNode есть метод (т.е. он есть у всех Data классов), который
вначале берет нужные данные из своего узла XML и затем пробегает по
дочерним узлам:
const children : XMLList = node.children();
const length : uint = children.length();
for (var i : int = 0;i < length; i++) {
var childNode : XML = children[i];
var name : String = QName(childNode.name()).localName;
var NodeClass : Class = ModelsAccessor.getClassByName(name);
if (NodeClass) {
new NodeClass(childNode, this);
}
}
ModelsAccessor - это класс, в котором прописаны соответствия классов
именам узлов.
Вновь созданные экземпляры в свою очередь также инициализируют детей.
в new NodeClass(childNode, this); второй параметр - текущий объект, в
ребенке он записывается как parent и дети в свою очередь в parent
саморегистрируются.
Ivan Dembicki
Все методы, отвечающие за парсинг, живут в parsing неймспейсе - наружу
они не должны торчать.
Парсинг может происходить в несколько волн, но главная - первая волна.
На этой волне объект забирает данные из своего узла, регистрируется в
родителе и в других объектах выше по иерархии, если это необходимо.
Если есть горизонтальные связи, например, два узла из разных иерархий
должны знать друг о друге, то организуется вторая волна парсинга по
окончании первой.
К примеру, у меня есть XML описание иерархии классов некого проекта.
На первой волне парсинга все эти классы регистрируются в рутовом узле.
На второй волне, я устанавливаю связи наследования, вызовов и т.п.,
поскольку на первой волне объекты-описания классов еще не все созданы.
Всегда применяю одно важное правило: никогда не беру данные из
дочерних узлов иерархии, дети сами себя регают. Поскольку дети могут
быть, могут не быть и могут быть разными. В то время, как родитель
всегда есть и, как правило, тип его известен.
Бывают случаи, когда тип родителя или какого-то контейнера выше может
быть разным. В этом случае назначается интерфейс.
Пример:
есть узел, описывающий некий тип:
<type class="Object">
он может быть вложен в разные контейнеры, например описывающие тип
возвращаемых методом данных, суперкласс или еще что-нибудь, где
требуется описание типа. Также он может быть вложен на произвольной
глубине по отношению к тому, кого он описывает.
Чтобы он знал где ему регаться (помимо обязательного parent), я создаю
интерфейс ITypeHolder и всем, кто имеет type назначаю этот интерфейс.
При парсинге класс знает, что он должен зарегаться где-то наверху:
var holder:DataNode = parsing::parent;
while (holder) {
if (holder is ITypeHolder) {
(holder as ITypeHolder).registerType(this);
}
holder = holder.parsing::parent;
}
всё, теперь класс, который должен знать что-то там о неком типе, знает о нем.
При этом мы не рылись в детях в его поисках, не проверяли совпадение
имени и вообще его наличие.
Если строго придерживаться этого правила - дети регаются в родителях,
родитель только создает прямых потомков, то парсинг получается очень
шустрый и понятный. Не требует множества циклов прохода, поисков,
запросов и проверок наличия того или иного ребенка.
Alex Davydov
Одно могу сказать точно - кажется мне надо модернизировать свой
data-маппинг, используемый в проектах.
Спасибочки!
Valentin Simonov
конвертации XML в цепочку объектов
Alex Davydov
Ну-у-у.. У мене стоит скромная задача - сделать, чтоб ноды\аттрибы вылетали
на подсказке (CTRL+Space) и варнингов не было.
Задачи воссоздавать Xpath в принципе не стоит. Тем более, что все это уже
создается по умолчанию в плеере при загрузке\парсинге xml-файлика
Андрей Скорик
> конвертации XML в цепочку объектов
круто :)
только имхо не понятно для чего.. хотите объекты - юзайте JSON и
мапинг классов на серверной стороне на классы AS, чтобы получать от
сервера сразу готовый массив value objects и дальше их использовать со
всеми прелестями строгой типизации
а если уж работать с xml - то с ним и работать и не надо его ни во что
конвертировать)) а визуальные и другие компоненты писать так чтобы они
умели принимать коллекции данных любого вида (ну или максимально
возможного набора вариантов).
--
С уважением, Скорик Андрей. andrew...@gmail.com
Андрей Скорик
> всеми прелестями строгой типизации
имелся ввиду proxy
Daniil Tutubalin
имя, но совершенно разную структуру, в зависимости от того, где этот
нод расположен.
Пример (кривой и далёкий от реальности, но просто чтобы объянить, что
я имею в виду):
<request>
<credentials>
<user>dan</user>
<pass>1234</pass>
</credentials>
<user>
<name>Daniil</name>
<surname>Tutubalin</surname>
<balance>1000.0</balance>
</user>
</request>
В данном случае нод <user> внутри <credentials> и нод <user> внутри
<request> - это по сути омонимы.
Имеют совершенно разные структуры и должны преобразовываться в разные классы.
Ivan Dembicki
> Иван, а как вы решаете такую проблему, что ноды могут иметь одинаковое имя,
- даю больно в голову тому, кто сделал такой XML
Ну, а если серьезно, то при невозможности исправить XML, скорее всего
создал бы класс UserTypeDetector, который ну понятно из названия что
делал бы.
Ivan Dembicki
> только имхо не понятно для чего.. хотите объекты - юзайте JSON [...]
- есть 1000 и 1 довод за то, чтобы юзать в качестве транспорта XML, а
не что-то еще. Да, не везде годится XML, но в подаяющем большинстве
случаев противопоказаний нет. В обычной жизни это очень удобный,
читабельный и гибкий инструмент. Начитаня с того, что начинать
разрабатывать клиент можно задолго до серверной части и во всем
процессе разработки никак от них не зависеть. И так далее.
В итоге, рассматривать альтернативу XML я начну только после того, как
убежусь, что использовать XML в данном проекте крайне нежелательно.
> мапинг классов на серверной стороне на классы AS
- как будто это не потребует написания кода.
Вообще, вся логика развития двум принципам уже давно дает зеленый свет:
1) универсальность транспорта
2) перенос вычислений с сервака на клиент - удешевление обслуживания.
Если что-то я могу посчитать на клиенте, то я именно этим путем и пойду.
Нагружать сервак - подрывать свой бизнес. Хотя, если ты работаешь на
дядю, то да, вроде как нет смысла экономить чужие деньги :)
> а если уж работать с xml - то с ним и работать и не надо его ни во что
> конвертировать)) а визуальные и другие компоненты писать так чтобы они
> умели принимать коллекции данных любого вида (ну или максимально
> возможного набора вариантов).
- далеко не всем проектам подходит этот вариант. Я бы сказал, что это
простейший случай, когда XML используется в качестве описания
интерфейса. В случае, описываемом мною я должен осуществить довольно
объемный анализ документа, установить множество связей и на основании
этих данных построить вьюху того типа, который попросит пользователь.
Да, это тоже частный случай, но опыт
Андрей Скорик
думаю не меньше найдется и обратных :))
"JSON (JavaScript Object Notation) is a lightweight data-interchange
format. It is easy for humans to read and write. It is easy for
machines to parse and generate."
www.json.org, страница главная, строка первая.
еще плюс на мой взгляд - суть формата описывается 5-ю картинками и
несколькими абзацами текста.
еще +1 в копилку JSON - он компактнее
и наконец интуитивно :) JSON родился из ECMA-262, а xml туда подтянули через e4x
вот кстати статья :) в которой JSON - прямо называется обезжиренной
альтернативой XML (JSON: The Fat-Free Alternative to XML)
http://www.json.org/fatfree.html
> - как будто это не потребует написания кода.
а многое уже написано :) и для серверной части и для клиентской. и
написано добротно и может быть унифицированно использовано, остается
брать и пользоваться (кстати еще +1)
> Если что-то я могу посчитать на клиенте, то я именно этим путем и пойду.
Да, только давайте все же не забывать (счас скажу оскорбительную весчь
:) ), что пишем мы все-же "тонкий клиент". И второй момент - нагрузка
на сервер для владельца пусть может быть и затратна, но хоть как-то
управляема.. а на клиенте мы имеем дело с осредненным черным ящиком и
чем шире спектр устройств тем он меньше этот ящик :).
Не знаю лично моей пользовательской половинке - нравятся легкие и
быстрые приложения. А уж сколько там дядьки денег потратили на
организацию серверов - это их дело (отобьют если будет спросом
пользоваться, а если не будет - то и денег вложенных в написание
навороченного клиента не вернут)
Просто главное, что меня смущает - xml надо сначала собрать на сервере
(думаю это сравнимые, если не большие затраты, чем затраты на
сериализацию), и получается что мы его на клиенте разбираем обратно в
объекты.. мало того используя встроенный e4x так еще и написав
собственный парсер, еще и переделывая его при изменениях, еще и давая
в нос тем кто выдумывает не подходящюю структуру xml - когда для JSON
- берем as3corelib реализуем прокси - юзаем и в ус не дуем)
Так и чего ради эти пляски? Ради того чтобы загружаемые данные можно
было открыть браузером или блокнотиком и посмотреть?
> - далеко не всем проектам подходит этот вариант. Я бы сказал, что это простейший случай, когда XML используется в качестве описания
> интерфейса.
Конечно не всем, я имел ввиду (как иллюстрацию) data-driven элементы
по образу тех же флексовых.. тому же датагриду (или OLAPDataGrid -
который весьма такой не хилый анализ данных делает) можно скормить и
массив и xmllist и тд. он все это послушно обернет в в один из типов
коллекций имплементящих общий интерфейс ICollectionView и дальше будет
уже работать с данными единым образом (и фильтровать и сортировать и
применить какой-то дескриптор и тд.) вне зависимости от источника
данных (не ручаюсь что там это на 100% так, но в 99% того кода который
я видел это так). Сама концепция тут мне кажется удачной.