парсинг в класс
Имеется три класса, класс playerData получает на вход json объект
Код AS3:
Код AS3:
Код AS3:
Код AS3:
|
А зачем такие заморочки?
Можно все сделать гораздо проще, без всяких имен класса. Добавить просто им поле type, в который и прописывать тип данных, которые заранее хранить в константах. Например Код AS3:
Но если уж по какой-то не ясной причине нужно получить название класса, то есть же еще descrybeType() |
Хранить тип каждого объекта в json на сервере избыточно, к тому же постоянно нужно заботиться о совместимости(если вдруг изменится название типа). Про то что getDefinitionByName требует вкомпила, да, забыл) Ну а если все таки создавать на старте все объекты, и вызывать у них рекурсивно parse - это может привести к чему то-плохому? обычно не рекомендуется инициализировать переменные в месте объявления, но тут объекты простые, и создаются все одновременно.
UPD: я вижу только проблему в том, что даже если объект не пришел с сервера, он все равно будет висеть в переменной. В первом случае решается проверкой на null, а сейчас получается нужно в parse их нулить вручную |
Мил человек, объясни, что это за шляпу ты нам дал?
Это случаем не AS 2.0? Error::msg никогда такого не было в AS 3.0 Добавлено через 4 минуты И еще, по огрооомному секрету, так, что только между нами, и не кому больше не говори... Тащемта мысль проста. Никогда... Хм, не так!... Никогда, никогда, никогда. Так лучше. В общем, никогда не делай парсинг в модели. Аминь! |
Цитата:
Очень странное решение, мягко говоря. Хранение одного дополнительного поля в JSON - это совсем не избыточность, особенно при том, что это поле поможет сэкономить процессорное время на просчет данных и упростит код. Не нужны будут никакие hasOwnProperty, getDefinitionByName и и try / catch блоки |
Цитата:
|
Есть вариант создать отдельные "парсеры", которые сеттят все свойства в модель.
Но я бы бил за каждую строчку этого кода. По столу, конечно, а не по голове кодера. Добавлено через 57 секунд Цитата:
Я легко переношу модель в другой проект, переписываю лишь парсеры. |
dimarik,
В таком случае, есть конечно один нюанс - парсер должен знать обо всей структуре проекта, всех моделях. До какой степени парсер тогда должен уметь разбирать данные? Я у себя остановился на том, что некоторый парсер приводит поступившие данные до формата Object, не разбираясь в его структуре. Затем отдаёт его моделям, каждая из которых знает, какой именно кусок данных из этого Object конкретно её. Выходит, что с одной стороны чтение структуры данных зашито в модель, а с другой, формат передачи этой структуры независим. Что скажете, сенсей? |
Хех. Кэп говорит что парсер должен знать только об этой модели. Nothing else. Ну, каждый парсер должен знать о своих моделях )
|
Это сколько же их тогда будет в итоге, парсеров? Примерно столько же, сколько моделей, которым нужно обновляться из данных сервера?
У меня вырисовывается смутное представление из ещё одной огромной структуры из парсеров, большинство из которых выполняет работу в две строчки: "взять" <-> "переложить". пс. Вот примерчик наваял, чтоб было что то конкретное. Допустим, имеем такую структуру: Код:
{ |
Часовой пояс GMT +4, время: 12:52. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.