|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Регистрация: Nov 2009
Адрес: СПб
Сообщений: 2,236
|
ок, логика знает эти инстанснэймы?
я просто никак не въеду, зачем что-то парсить что мешает напрямую обращаться? можно, конечно, обернуть этот объект из свц в некий ОбжектХолдер, чтобы в логике более цивильно выглядело Последний раз редактировалось mikhailk; 21.01.2011 в 11:58. |
|
|||||
Хороший вопрос... я тоже вчера хотел спросить, но как то постеснялся...
2КорДум: А вы, извиняюсь, партизан В общем ввиду того, что я так и не понял, в чем заключается вопрос, пофантазирую Делаем класс «парсер», который на входе получает указатель на экземпляр символа а так же указатель на логический блок. Внутри перебираем все дочерние элементы, и в зависимости от префикса имени(например выделенного знаком «_») вызываем различные функции в логическом блоке, передовая им элементы. Ну, условно, что-то типа:
__________________
Искренне Ваш, Джек. |
|
|||||
на самом деле вариант JackFromChaos альтернатива моему, вы берете инстанс, скармливаете его логической оболочке и все, у меня же некоторые классы уже в свцшке привязаны к логике:
А человек делает именно то что вы хотите, берет тупо графику и просто ее оборачивает, вот пример моей знакомой, она делает так же: 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е в процессе исполнения... Плюс подсказки во время написания кода. Не надо вспомнить как я называл тот или иной элемент...
__________________
Искренне Ваш, Джек. |
|
|||||
Регистрация: Mar 2010
Сообщений: 137
|
Что значит "распарсить"?
Парсинг - процесс разбора строки в определённом синтаксисе. При чём он здесь? Добавлено через 2 минуты Аааа... Понял. Имеется что-то вроде задания интерфейса в формате MXML, верно? |
|
|||||
JackFromChaos я немного запутался, вы за то что бы в свц был просто набор спрайтов и на них в проекте рантайм вешать логику (как в моем последнем примере), или же за то что бы в была графика отнаследованная от например спрайта с зашитой собственной логикой, а в основном коде просто добавлять им функционал для работы проекта?
|
|
|||||
А я ни за какой Но в этой ветке я примеров с наследованием графики от логики не писал...
Просто когда я делаю GUI, я руководствуюсь похожей на вашу схему. Т.е. есть клип(условно-окно). Я от него наследуюсь, и пишу внутри логику. Но ведь мы не только интерфейс делаем... В других случаях могут быть самые разные варианты... От моего последнего примера, до использования во Flash пользовательских классов, например для параметризующий клипов. Эти пользовательские классы могут быть и совершенно пустыми наследниками Sprite. Наличие информации у графического ассета, такого как тип, уже может добавить много удобства, например при использовании Flash в качестве редактора уровней какой нибудь игры. А может и с логикой быть... Добавлено через 5 минут По поводу GUI. К примеру в swc есть класс gAbout, внутри которого есть текст какой-то и кнопка... дальше я делаю уже в FD класс About extends gAbout, ну и, например, в конструкторе заношу в текстовое поле какой то текст, а на кнопку вешаю обработчик. При этом, если во Flash я дал кнопке имя _ok, а тексту, _text, то в конструкторе мне будет доступно: Такой подход к построению интерфейса мне кажется одним из самых удобных при разработке не слишком навороченных игр. Если же в игре или приложении ОЧЕНЬ много интерфеса, то тут, вероятно не обойтись без компонентов, ну или какого нибудь MXML, но последнее я не люблю(да и не знаю, если честно), поэтому предпочитаю компоненты для многократного использования(ну зачем нам иметь в проекте сотню копий одной и той же кнопки...). И тут уже по любому, какая то логика туда просится...
__________________
Искренне Ваш, Джек. |
|
|||||
Цитата:
Значит так, мой вопрос, для меня самого вроде бы очень понятный, вдруг оказался непонятным отчасти другим. Рассказываю, как у меня обстоит дело: клип представляет собой не что иное, как все элементы интерфейса плеера. Там так аккуратненько сложены все клипы: фон, стейты кнопок, слайдеров, скроллбаров, индикаторов. В общем виде напоминает текстурку для 3D-модели. У каждого элемента, конечно же, задан инстанс нейм, программе они известны (такой случай, когда я сам все делаю - рисую, формирую swc, пишу код). А теперь то, что я хочу сделать нормально: мне нужно распарсить этот клип (почему "распарсить", потому что подходит по смыслу это слово, как в xml-файле, мы его парсим, забирая значения узлов, атрибуты и прочее). Распарсить и отдать все стейты от одной кнопки конструктору кнопки, все стейты слайдера - конструктору слайдера и так далее по списку. Напоминаю, что все имена элементов мне известны. Я просто не могу придумать, как мне лучше сделать это все именно красиво, а не топорно наваливая логику вперемешку с парсингом и не дай Мук - в одном классе. И вот я тут расписал и еще хочется уточнить, что я хочу получить в итоге. А хочется мне структурированности. Вот я думаю, что сделаю класс парсинга, он пробежится по элементам, тут же скормит их нужным конструкторам классов, типа new BtnPlay(стейтКнопкиРаз, стейтКнопкиДва, стейтКнопкиТри). В самом конце диспатчим событие, мол, мы закончили распарсинг и все-все собрали, плеер готов. Что-то слушает это событие и по наступлению его стартует самая главня логика - "мозг" плеера. Рассуждения правильные?
__________________
тут я Последний раз редактировалось КорДум; 21.01.2011 в 15:38. |
|
|||||
Ну тут наверное как то так надо... по аналогии с 3d игрушками
Делаем какой нить AssetManager(ТextureManager в 3d), которому скрмливаем наш муви клип. Он все складывает в ассоциативный массив, ну типа имя:символ. А потом просто создаем наш плеер, при этом тот кто создает, имеет указатель на AssetManager(например синглтоном)... А уже кнопка Play при инициализации знает, что ей нужен bPlay, bPlayOver и т.д. И она просто запрашивает у AssetManager эти данные. Тут собственно композиция может быть любой, как вам удобно. Но общий принцип в том, что есть какой то унифицированный интерфейс который может по некоторому идентификатору отдавать некий графический ресурс. А конечный потребитель этого интерфейса знает идентификаторы необходимых ему ресурсов и может их получить.
__________________
Искренне Ваш, Джек. |
|
|||||
Вот! Вы поняли как надо
Это был мой первый вариант. Типа, метод парсинга, он отдает object в конце, мы ссылку на этот обджект передаем в классы формирования интерфейса. И этот способ был бы для меня нормальным, если бы nOobCrafter не посоветовал мне кое-что более интересное и приятное по структуре.
__________________
тут я |
Часовой пояс GMT +4, время: 20:41. |
|
« Предыдущая тема | Следующая тема » |
|
|