![]() |
Элегантно распарсить клип на элементы и отдать полученное
Здравствуйте все. Хочется элегантно решить ситуацию:
имеем swc с одним клипом, в нем куча мелких клипов-элементов. Целесообразно ли создавать отдельный класс со статическим (?) методом для парсинга этого клипа на составляющие? И как в таком случае отдавать полученное логике программы? Был вариант формировать Object, в логике парсить его. Но это двойная работа и, хоть, парсинг самого интерфейса будет сидеть красиво в отдельном не менее красивом классе, парсинг же конечно обджекта кажется каким-то нерациональным и портит всю элегантность. Хотелось бы узнать мнения знающих людей. |
я просто беру инстансы визуальных классов из свц, и скармливаю их некойоболочке, которая сверу накладывает логику.
Код AS3:
Код AS3:
|
Эм, то есть, мне нужно скормить этот клип "некой оболочке" (судя по всему, как раз тот самый класс-парсер), которая мне все распарсит и наложит сверху логику? Тогда это ведь нагромождение всего в одном классе получается (утрирую, но все же). Или же я не так понял?
|
ну его же еще можно разбить, вам же не обязательно в одном классе хранить всю логику элементов? нашли там клип для меню, скормили менюшной логике, а та в свою очередь разобрала все по кнупочкам.
Код AS3:
|
Не сосем понятна суть вопроса... Можно как то, пример что ли привести?
Добавлено через 6 минут Если речь идет о интерфейсе и MVC. То тут, мне кажется, лучше всего подходит вариант, когда мы наш вью наследуем от клипа, а затем уже непосредственно наследнике настраиваем связку с моделью и контроллером. Таким образом контроллер минимум знает о содержимом view... К примеру Код AS3:
|
nOobCrafter, вот теперь стала понятнее ваша мысль. Согласен, можно так. Тогда тот класс-парсер будет еще формировать корни логики.
JackFromChaos, нет, не MVC. Еще есть варианты? |
Все равно я не до конца понял суть проблемы.
Лично я, обычно, накладываю логику путем наследования от графического клипа, и далее через публичные переменные которые там есть для всех членов(без getChildByName). Так же иногда делаю всякие утилитные классы, ну например очень простой вариант: Код AS3:
Код AS3:
к P.S. Пример, естественно, синтетический, но очень похожий на реальный код... |
Нет, вы поняли неправильно ;)
Мне нужно всего лишь распарсить один клип из swc на составляющие и скормить его содержимое разным вещам. Как это сделать лучше моего варианта, мне уже посоветовал nOobCrafter. Но если есть и другие способы - я буду рад их выслушать тоже, авось будет что-то оптимальнее и эстетичнее :) |
А что значит "распарсить и скормить"?
Логика программы как потом с этими классами работает? Она знает их по именам? |
Какие классы? В swc только один класс, прилинкованный к одному клипу. В этом клипе тонна других клипов, которые мы хватаем через getChildByName.
|
ок, логика знает эти инстанснэймы?
я просто никак не въеду, зачем что-то парсить что мешает напрямую обращаться? можно, конечно, обернуть этот объект из свц в некий ОбжектХолдер, чтобы в логике более цивильно выглядело |
Цитата:
2КорДум: А вы, извиняюсь, партизан ;) В общем ввиду того, что я так и не понял, в чем заключается вопрос, пофантазирую;) Делаем класс «парсер», который на входе получает указатель на экземпляр символа а так же указатель на логический блок. Внутри перебираем все дочерние элементы, и в зависимости от префикса имени(например выделенного знаком «_») вызываем различные функции в логическом блоке, передовая им элементы. Ну, условно, что-то типа: Код AS3:
|
на самом деле вариант JackFromChaos альтернатива моему, вы берете инстанс, скармливаете его логической оболочке и все, у меня же некоторые классы уже в свцшке привязаны к логике:
Код AS3:
Код AS3:
|
2nOobCrafter:
Вариант наследования от графики и использования переменных мне нравится уже потому, что большую часть возможных нарушений в структуре графики можно выявить на момент компиляции, а не null referencе в процессе исполнения... Плюс подсказки во время написания кода. Не надо вспомнить как я называл тот или иной элемент... |
Что значит "распарсить"?
Парсинг - процесс разбора строки в определённом синтаксисе. При чём он здесь? Добавлено через 2 минуты Аааа... Понял. Имеется что-то вроде задания интерфейса в формате MXML, верно? |
JackFromChaos я немного запутался, вы за то что бы в свц был просто набор спрайтов и на них в проекте рантайм вешать логику (как в моем последнем примере), или же за то что бы в была графика отнаследованная от например спрайта с зашитой собственной логикой, а в основном коде просто добавлять им функционал для работы проекта?
|
А я ни за какой:) Но в этой ветке я примеров с наследованием графики от логики не писал...
Просто когда я делаю GUI, я руководствуюсь похожей на вашу схему. Т.е. есть клип(условно-окно). Я от него наследуюсь, и пишу внутри логику. Но ведь мы не только интерфейс делаем... В других случаях могут быть самые разные варианты... От моего последнего примера, до использования во Flash пользовательских классов, например для параметризующий клипов. Эти пользовательские классы могут быть и совершенно пустыми наследниками Sprite. Наличие информации у графического ассета, такого как тип, уже может добавить много удобства, например при использовании Flash в качестве редактора уровней какой нибудь игры. А может и с логикой быть... Добавлено через 5 минут По поводу GUI. К примеру в swc есть класс gAbout, внутри которого есть текст какой-то и кнопка... дальше я делаю уже в FD класс About extends gAbout, ну и, например, в конструкторе заношу в текстовое поле какой то текст, а на кнопку вешаю обработчик. При этом, если во Flash я дал кнопке имя _ok, а тексту, _text, то в конструкторе мне будет доступно: Код AS3:
Если же в игре или приложении ОЧЕНЬ много интерфеса, то тут, вероятно не обойтись без компонентов, ну или какого нибудь MXML, но последнее я не люблю(да и не знаю, если честно), поэтому предпочитаю компоненты для многократного использования(ну зачем нам иметь в проекте сотню копий одной и той же кнопки...). И тут уже по любому, какая то логика туда просится... |
Цитата:
Значит так, мой вопрос, для меня самого вроде бы очень понятный, вдруг оказался непонятным отчасти другим. Рассказываю, как у меня обстоит дело: клип представляет собой не что иное, как все элементы интерфейса плеера. Там так аккуратненько сложены все клипы: фон, стейты кнопок, слайдеров, скроллбаров, индикаторов. В общем виде напоминает текстурку для 3D-модели. У каждого элемента, конечно же, задан инстанс нейм, программе они известны (такой случай, когда я сам все делаю - рисую, формирую swc, пишу код). А теперь то, что я хочу сделать нормально: мне нужно распарсить этот клип (почему "распарсить", потому что подходит по смыслу это слово, как в xml-файле, мы его парсим, забирая значения узлов, атрибуты и прочее). Распарсить и отдать все стейты от одной кнопки конструктору кнопки, все стейты слайдера - конструктору слайдера и так далее по списку. Напоминаю, что все имена элементов мне известны. Я просто не могу придумать, как мне лучше сделать это все именно красиво, а не топорно наваливая логику вперемешку с парсингом и не дай Мук - в одном классе. И вот я тут расписал и еще хочется уточнить, что я хочу получить в итоге. А хочется мне структурированности. Вот я думаю, что сделаю класс парсинга, он пробежится по элементам, тут же скормит их нужным конструкторам классов, типа new BtnPlay(стейтКнопкиРаз, стейтКнопкиДва, стейтКнопкиТри). В самом конце диспатчим событие, мол, мы закончили распарсинг и все-все собрали, плеер готов. Что-то слушает это событие и по наступлению его стартует самая главня логика - "мозг" плеера. Рассуждения правильные? |
Ну тут наверное как то так надо... по аналогии с 3d игрушками:)
Делаем какой нить AssetManager(ТextureManager в 3d), которому скрмливаем наш муви клип. Он все складывает в ассоциативный массив, ну типа имя:символ. А потом просто создаем наш плеер, при этом тот кто создает, имеет указатель на AssetManager(например синглтоном)... А уже кнопка Play при инициализации знает, что ей нужен bPlay, bPlayOver и т.д. И она просто запрашивает у AssetManager эти данные. Тут собственно композиция может быть любой, как вам удобно. Но общий принцип в том, что есть какой то унифицированный интерфейс который может по некоторому идентификатору отдавать некий графический ресурс. А конечный потребитель этого интерфейса знает идентификаторы необходимых ему ресурсов и может их получить. |
Вот! Вы поняли как надо ;)
Это был мой первый вариант. Типа, метод парсинга, он отдает object в конце, мы ссылку на этот обджект передаем в классы формирования интерфейса. И этот способ был бы для меня нормальным, если бы nOobCrafter не посоветовал мне кое-что более интересное и приятное по структуре. |
если все известно, то зачем там все парсить? вот не пойму я этих манипуляций..бери да клепай где тебе нужно свои стейты и конструируй кнопки.
|
В общем здесь логичнее не схема Parse->Set->Init, а Parse, Init->Get. Таким образом снижается связность. Менеджер универсален. Он ни о ком ничего не знает. Только данные откуда то о символах получает...
Сам клиент этого дело тоже не особо заворачивается о том, в каком виде и как появляются ресурсы. Для него важно, что он может их получить через единую точку. Связность минимальная. И нет странного места, которое решает какому объекту какой ресурс нужен. Объект сам решает, какой ему нужен ресурс. Естественно, менеджер может быть универсальным, получать данные самым различным способом(swc, swf,png и т.д.), и при этом использоваться для разных окон, содержать в себе много разных композитов(наборов элементов) и т.д. |
Цитата:
А еще варианты? Может быть найдется еще лучше? ;) |
Цитата:
Лучше вариантов пока в голову не приходит, только хуже...:D |
JackFromChaos, во-во :D
На самом деле тема для меня очень интересная, уже очень давно думал, как это все лучше организовывать, как только не пробовал, чуть ли не статической ссылкой на клип с графикой. А раньше, когда не знал о способе с getChildByName, вообще каждому элементу присоединял свой класс, скармливал экземпляры этих классов. Как вспомню - бррр. Сейчас просто решил переписать старый плеер под новые знания, вот и задаюсь такими вопросами. |
Ну я не знаю, но в данном случае, даже неличие менеджера мне кажется не оправданно. Т.е. к примеру менеджер в 3d он ведь сделан прежде всего для того, что бы управлять ресурсами, оптимизировать загрузку, следить за тем, что бы ресурсы удалялись и т.д. Там это оправданно.
Но Flash другая платформа и задачу тут другая. Нет стоит, имхо, пытаться придумывать универсальные, красивые решения, но совершенно не оправданные с точки зрения данного применения. Это называется, забивать гвозди микроскопом, имхо. P.S. К примеру unity 3d, как я узнал недавно, не поддерживает интерфейс, свойства(т.е. getter/setter). Все переменные в классе должны быть публичными и т.д. Но на нем все равно пишут, так как он удобен чем то еще, это специфика платформы. Хотя получается там не применимы многие парадигмы ООП и паттерны.. P.P.S. "Что хорошо для русского, немцу смерть..." Добавлено через 2 минуты К слову, композитные текстуры в 3d графики придумали не от хорошей жизни, и не для того, что бы что-то "красиво реализовать"... |
А я менеджер и не планировал делать.
Мне нужно только правильно отдавать графику кусочкам логики и все. Мне кажется или вы все на MVC стараетесь переложить? ;) |
JackFromChaos,
это как так юнити3д не поддерживает свойства? Там полноценный си-шарп, который даже перегрузку операторов поддерживает. |
2ps_spectre:
А вот так:) На самом деле я деталей не знаю, это у меня жена на нем программирует. Но общая идея такова. Там действительно c#, но при разработке игр, программист должен наследоваться от стандартных компонентов unity, они попадают в редактор unity, и вот уже этот редактор как раз много чего не поддерживает. Такая вот архитектура. Там как бы даже компилятор кажется свой... Естественно, внешние библиотеки могут пользоваться всем спектром возможностей c#. Но факт остается фактом, основная разработка для Unity - это скорее сильно кастрированный c#. Вроде так... Хотя как я уже говорил, с Unity я не работал, и деталей не знаю... Добавлено через 3 минуты Цитата:
MVC я подсовывать не пытался... А еще мне кажется для небольших задач, вроде плеера, один класс из 300 строк, много лучше чем 10 из 50 строк... И потому что в результате строк меньше. Но прежде всего потому, что мы получаем самодостаточный модуль, который легко читается... А втыкнуть в какую то новую(или хорошо забытую старую) может быть куда сложнее.. И если для крупных задач без этого никак, то для мелких - самое то.... |
JackFromChaos, а-а-а, может и так, теперь учту. (з.ы. я сам только хелловорлд в юнити глянул и пока сам могу заблуждаться, все таки мы за флеш ))
сорри за оффтоп |
Ничего не понял. У нас есть файл, описывающий интерфейс, или нету?
|
Мое первое сообщение:
Цитата:
|
Цитата:
Но Action Script хорошо другим. Во первых это кросс платформа. Во вторых большая часть того, что для того же c# реализовывают всяческие движки, во Flash - часть стандартного фрэймворка. Ну и конечно мощный инструмент(может и не идеальный, но мощный:) ), в лице Flash IDE. Все это делает разработку на Flash весьма приятным делом... |
JackFromChaos, со всем соглашусь. )
з.ы. шарп тоже люблю (наверно любимый яп) ждем флеш3д , не долго ждать то уж. (Molehill) |
Цитата:
Добавлено через 2 минуты Пока остановлюсь на создании экзепляра класса клипа из swc, скармливание ссылки на него разным собирателям интерфейса и конечный диспатчинг события, мол, все собрали, можно приступать к дальнейшей реализации логики. |
| Часовой пояс GMT +4, время: 02:49. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.