Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   парсинг в класс (http://www.flasher.ru/forum/showthread.php?t=212500)

faraday 26.02.2016 21:46

парсинг в класс
 
Имеется три класса, класс playerData получает на вход json объект
Код AS3:

{name:'playerName', balance:{coins:5,gold:10}}

у класса dataModel есть метод parse, который обходит объект и добавляет свойства. в дебажной версии все работает на ура, парсит данные любой сложности. но в релизе не удается поймать имя класса. как альтернативу вижу создавать заранее new BalanceData() , а потом вызывать его метод parse. Но текущая версия нравится больше, есть еще какие-либо варианты?
Код AS3:

public class DataModel
{
                public function parse(model:Object) {
                        for (var key in model)
                        if (hasOwnProperty(key)) {
                        try {
                                this[key] = model[key];
                        } catch (e:Error) {
                                var className:String = parseError(e.msg);
                                var item:*= new (getDefinitionByName(className) as Class);
                                if (item is DataModel)
                                        item.parse(model[key]);
                                this[key] = item;       
                                }
                        }
                        return this;
                }
}

Код AS3:

public class PlayerData extends DataModel
{
var balance:BalanceData,
var name:String
}

Код AS3:

public class BalanceData extends DataModel
{
var coins:int
var gold:int
}


caseyryan 27.02.2016 14:03

А зачем такие заморочки?
Можно все сделать гораздо проще, без всяких имен класса. Добавить просто им поле type, в который и прописывать тип данных, которые заранее хранить в константах. Например
Код AS3:

switch (object.type) {
    case AllTypes.PLAYER_DATA:
        // обрабатываем данные пользователя
    break;
}

Просто не вижу смысла в такой конструкции, учитывая то, getDefinitionByName все равно требует, чтобы класс был заранее вкомпилен в swf.

Но если уж по какой-то не ясной причине нужно получить название класса, то есть же еще descrybeType()

faraday 27.02.2016 16:43

Хранить тип каждого объекта в json на сервере избыточно, к тому же постоянно нужно заботиться о совместимости(если вдруг изменится название типа). Про то что getDefinitionByName требует вкомпила, да, забыл) Ну а если все таки создавать на старте все объекты, и вызывать у них рекурсивно parse - это может привести к чему то-плохому? обычно не рекомендуется инициализировать переменные в месте объявления, но тут объекты простые, и создаются все одновременно.
UPD: я вижу только проблему в том, что даже если объект не пришел с сервера, он все равно будет висеть в переменной. В первом случае решается проверкой на null, а сейчас получается нужно в parse их нулить вручную

dimarik 27.02.2016 17:22

Мил человек, объясни, что это за шляпу ты нам дал?
Это случаем не AS 2.0?
Error::msg никогда такого не было в AS 3.0

Добавлено через 4 минуты
И еще, по огрооомному секрету, так, что только между нами, и не кому больше не говори... Тащемта мысль проста. Никогда... Хм, не так!... Никогда, никогда, никогда. Так лучше. В общем, никогда не делай парсинг в модели. Аминь!

caseyryan 27.02.2016 17:28

Цитата:

если вдруг изменится название типа
Как оно может "вдруг" измениться?
Очень странное решение, мягко говоря. Хранение одного дополнительного поля в JSON - это совсем не избыточность, особенно при том, что это поле поможет сэкономить процессорное время на просчет данных и упростит код. Не нужны будут никакие hasOwnProperty, getDefinitionByName и и try / catch блоки

КорДум 27.02.2016 17:38

Цитата:

В общем, никогда не делай парсинг в модели
А почему? Мне, человеку с некоторым опытом, не очень понятна сия мысль.

dimarik 27.02.2016 17:44

Есть вариант создать отдельные "парсеры", которые сеттят все свойства в модель.

Но я бы бил за каждую строчку этого кода. По столу, конечно, а не по голове кодера.

Добавлено через 57 секунд
Цитата:

Сообщение от КорДум (Сообщение 1192207)
А почему? Мне, человеку с некоторым опытом, не очень понятна сия мысль.

Формат данных не обязывает модель его поддерживать, например.

Я легко переношу модель в другой проект, переписываю лишь парсеры.

Tails 27.02.2016 18:03

dimarik,
В таком случае, есть конечно один нюанс - парсер должен знать обо всей структуре проекта, всех моделях. До какой степени парсер тогда должен уметь разбирать данные? Я у себя остановился на том, что некоторый парсер приводит поступившие данные до формата Object, не разбираясь в его структуре. Затем отдаёт его моделям, каждая из которых знает, какой именно кусок данных из этого Object конкретно её.

Выходит, что с одной стороны чтение структуры данных зашито в модель, а с другой, формат передачи этой структуры независим. Что скажете, сенсей?

dimarik 27.02.2016 18:26

Хех. Кэп говорит что парсер должен знать только об этой модели. Nothing else. Ну, каждый парсер должен знать о своих моделях )

Tails 27.02.2016 18:38

Это сколько же их тогда будет в итоге, парсеров? Примерно столько же, сколько моделей, которым нужно обновляться из данных сервера?
У меня вырисовывается смутное представление из ещё одной огромной структуры из парсеров, большинство из которых выполняет работу в две строчки: "взять" <-> "переложить".

пс. Вот примерчик наваял, чтоб было что то конкретное.
Допустим, имеем такую структуру:
Код:

{
    id:13,
    level:15,
    name:"Вася",
    skills:[
        {id:1, level:2}, {id:5, level:8}
    ]
}

И вот это у нас приходит с сервака в каком-то там формате. Допустим, парсер прочитал и получил именно такой Object. А дальше, тут надо 2 парсера? (Парсер игрока, вложенный парсер скилов игрока)


Часовой пояс GMT +4, время: 12:52.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.