Форум Flasher.ru - Элегантно распарсить клип на элементы и отдать полученное

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

ок, логика знает эти инстанснэймы?
я просто никак не въеду, зачем что-то парсить
что мешает напрямую обращаться?

можно, конечно, обернуть этот объект из свц в некий ОбжектХолдер, чтобы в логике более цивильно выглядело

Цитата:

Сообщение от mikhailk (Сообщение 966490)

А что значит "распарсить и скормить"?

Хороший вопрос... я тоже вчера хотел спросить, но как то постеснялся...:)

2КорДум: А вы, извиняюсь, партизан ;)

В общем ввиду того, что я так и не понял, в чем заключается вопрос, пофантазирую;)

Делаем класс «парсер», который на входе получает указатель на экземпляр символа а так же указатель на логический блок.
Внутри перебираем все дочерние элементы, и в зависимости от префикса имени(например выделенного знаком «_») вызываем различные функции в логическом блоке, передовая им элементы.
Ну, условно, что-то типа:

Код AS3:

switch(prefix)

{

        case “unit”:logic.registerUnit(displayObject);break;

        case “enemy”:logic.registerEnemy(displayObject);break;

        case “bomp”:logic.registerBomb(displayObject);break;

        default:

                logic.registerStatic(displayObject);

}

на самом деле вариант JackFromChaos альтернатива моему, вы берете инстанс, скармливаете его логической оболочке и все, у меня же некоторые классы уже в свцшке привязаны к логике:

Код AS3:

= _target.getChildByName("money") as GUI_BaseItem;

А человек делает именно то что вы хотите, берет тупо графику и просто ее оборачивает, вот пример моей знакомой, она делает так же:

Код AS3:

                public function MainMenu (sprite: Sprite)

                {

                        _view = sprite;

                        _view.addChild(_menu);

                        _view.addEventListener(MainMenuEvent.CHANGE_STATE ,

                                                                function(e:Event):void {

                                                                        if(_state == IMAGE_STATE) _state = FACE_STATE;

                                                                        else _state = IMAGE_STATE;

                                                                }

                                                        );

 

                        new AdvancedButton(_menu['bt_plus'], 'bt_plus', MainMenuEvent.PLUS);

                        new AdvancedButton(_menu['bt_min'], 'bt_min', MainMenuEvent.MINUS);

                        new AdvancedButton(_menu['bt_load'], 'bt_load', MainMenuEvent.LOAD);

                        new AdvancedButton(_menu['bt_l'], 'bt_l', MainMenuEvent.ROTATE_L);

                        new AdvancedButton(_menu['bt_r'], 'bt_r', MainMenuEvent.ROTATE_R);

                        new AdvancedButton(_menu['result'], 'result', MainMenuEvent.GET_RESULT);

                        new FaceChBox(_menu['chbox_btn'], 'chbox_btn', MainMenuEvent.CHANGE_STATE);

 

                        gotoImageState();

                        unLock();

                        _state = START_STATE;

                }

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

2nOobCrafter:
Вариант наследования от графики и использования переменных мне нравится уже потому, что большую часть возможных нарушений в структуре графики можно выявить на момент компиляции, а не null referencе в процессе исполнения...

Плюс подсказки во время написания кода. Не надо вспомнить как я называл тот или иной элемент...

Что значит "распарсить"?

Парсинг - процесс разбора строки в определённом синтаксисе. При чём он здесь?

Добавлено через 2 минуты
Аааа... Понял. Имеется что-то вроде задания интерфейса в формате MXML, верно?

JackFromChaos я немного запутался, вы за то что бы в свц был просто набор спрайтов и на них в проекте рантайм вешать логику (как в моем последнем примере), или же за то что бы в была графика отнаследованная от например спрайта с зашитой собственной логикой, а в основном коде просто добавлять им функционал для работы проекта?

А я ни за какой:) Но в этой ветке я примеров с наследованием графики от логики не писал...
Просто когда я делаю GUI, я руководствуюсь похожей на вашу схему. Т.е. есть клип(условно-окно). Я от него наследуюсь, и пишу внутри логику. Но ведь мы не только интерфейс делаем...
В других случаях могут быть самые разные варианты... От моего последнего примера, до использования во Flash пользовательских классов, например для параметризующий клипов. Эти пользовательские классы могут быть и совершенно пустыми наследниками Sprite. Наличие информации у графического ассета, такого как тип, уже может добавить много удобства, например при использовании Flash в качестве редактора уровней какой нибудь игры. А может и с логикой быть...

Добавлено через 5 минут
По поводу GUI.
К примеру в swc есть класс gAbout, внутри которого есть текст какой-то и кнопка... дальше я делаю уже в FD класс About extends gAbout, ну и, например, в конструкторе заношу в текстовое поле какой то текст, а на кнопку вешаю обработчик.
При этом, если во Flash я дал кнопке имя _ok, а тексту, _text, то в конструкторе мне будет доступно:

Код AS3:

_text.txt="Я, любимый";

_ok.addEventListener(MouseEvent.MOUSE_CLICK, onClose);

Такой подход к построению интерфейса мне кажется одним из самых удобных при разработке не слишком навороченных игр.

Если же в игре или приложении ОЧЕНЬ много интерфеса, то тут, вероятно не обойтись без компонентов, ну или какого нибудь MXML, но последнее я не люблю(да и не знаю, если честно), поэтому предпочитаю компоненты для многократного использования(ну зачем нам иметь в проекте сотню копий одной и той же кнопки...). И тут уже по любому, какая то логика туда просится...

Цитата:

А вы, извиняюсь, партизан ;)

*выглядывает из-за кустов*

Значит так, мой вопрос, для меня самого вроде бы очень понятный, вдруг оказался непонятным отчасти другим. Рассказываю, как у меня обстоит дело:
клип представляет собой не что иное, как все элементы интерфейса плеера. Там так аккуратненько сложены все клипы: фон, стейты кнопок, слайдеров, скроллбаров, индикаторов. В общем виде напоминает текстурку для 3D-модели. У каждого элемента, конечно же, задан инстанс нейм, программе они известны (такой случай, когда я сам все делаю - рисую, формирую swc, пишу код).

А теперь то, что я хочу сделать нормально:
мне нужно распарсить этот клип (почему "распарсить", потому что подходит по смыслу это слово, как в xml-файле, мы его парсим, забирая значения узлов, атрибуты и прочее). Распарсить и отдать все стейты от одной кнопки конструктору кнопки, все стейты слайдера - конструктору слайдера и так далее по списку. Напоминаю, что все имена элементов мне известны. Я просто не могу придумать, как мне лучше сделать это все именно красиво, а не топорно наваливая логику вперемешку с парсингом и не дай Мук - в одном классе.

И вот я тут расписал и еще хочется уточнить, что я хочу получить в итоге. А хочется мне структурированности. Вот я думаю, что сделаю класс парсинга, он пробежится по элементам, тут же скормит их нужным конструкторам классов, типа new BtnPlay(стейтКнопкиРаз, стейтКнопкиДва, стейтКнопкиТри). В самом конце диспатчим событие, мол, мы закончили распарсинг и все-все собрали, плеер готов. Что-то слушает это событие и по наступлению его стартует самая главня логика - "мозг" плеера.

Рассуждения правильные?

Ну тут наверное как то так надо... по аналогии с 3d игрушками:)
Делаем какой нить AssetManager(ТextureManager в 3d), которому скрмливаем наш муви клип. Он все складывает в ассоциативный массив, ну типа имя:символ.
А потом просто создаем наш плеер, при этом тот кто создает, имеет указатель на AssetManager(например синглтоном)... А уже кнопка Play при инициализации знает, что ей нужен bPlay, bPlayOver и т.д. И она просто запрашивает у AssetManager эти данные. Тут собственно композиция может быть любой, как вам удобно. Но общий принцип в том, что есть какой то унифицированный интерфейс который может по некоторому идентификатору отдавать некий графический ресурс. А конечный потребитель этого интерфейса знает идентификаторы необходимых ему ресурсов и может их получить.

Вот! Вы поняли как надо ;)
Это был мой первый вариант. Типа, метод парсинга, он отдает object в конце, мы ссылку на этот обджект передаем в классы формирования интерфейса. И этот способ был бы для меня нормальным, если бы nOobCrafter не посоветовал мне кое-что более интересное и приятное по структуре.