Связка FlashIDE + FD с компиляцией в FlashIDE

[fljot]

Любителям наследоваться от графики:

Представьте приложение аля quiz. Каждый вопрос "нарисован" дизайнером (всмысле созданы отдельные символы и всё красиво расставлено). Нужно чтобы это всё анимированно появлялось, затем каждая плашка с вопросом имеет своё внутреннее поведение (аля ToggleButton или сложный компонент как на последней картинке). Что, будете от каждого символа наследоваться?

[Psycho Tiger]

getChildByName как бы.

[fljot]

что с ним?

[Psycho Tiger]

Как бы даже с наследованием.
Наследуемся от контейнера со всей графикой и крутим-вертим.

[fljot]

От каждого вопрос-сет-контейнера наследоваться? Что с поведением каждого(ну почти) элемента в контейнере?

[ChuwY]

Я пришел к выводу, что лично мне очень даже неудобно разделять логику.
Так, чтобы часть была в swc, а часть в основном проекте в билдере, например.
Теперь вообще не создаю *.as файлов в flashIDE-проекте. Линковать можно благо в любой пакет и без создания файла. Классы соответственно получают имена в стиле CircleView, EnemyView, LevelView;
В основном проекте же все классы, которые будут работать с символами из библиотеки наследуются от, например, класса BaseControlLogic (его идею подрезал у коллеги) (сам класс наследуется, например, от EventDispatcher).
Он может выглядеть так:

package base {
	import flash.display.DisplayObjectContainer;
	import flash.display.Sprite;
	import flash.events.EventDispatcher;
	import flash.events.MouseEvent;
	import tools.CursorMgr;
 
	public class BaseControlLogic extends EventDispatcher {
		protected var _view : Sprite;
		protected var _owner : DisplayObjectContainer;
 
		public function BaseControlLogic(){
			super();
		}
 
		public function setView(view : Sprite) : void {
			if(view) {
				initView(view);
			} else {
				removeView();
			}
		}
 
		public function getView() : Sprite {
			return _view;
		}
 
		protected function initView(view : Sprite) : void {
			_view = view;
		}
 
		protected function removeView() : void {
			if(_owner) {
				_owner.removeChild(_view);
				_owner = null;
			}
			_view = null;
		}
 
		public function set owner(owner : DisplayObjectContainer) : void {
			_owner = owner;
			_owner.addChild(_view);
		}
 
		public function get visible() : Boolean {
			return _view ? _view.visible : false;
		}
 
		public function set visible(visible : Boolean) : void {
			if(_view) {
				_view.visible = visible;
			}
		}
	}
}

В потомках же переопределяем initView(); как нам надо.
Например так.

package levels{
	import dialogs.base.BaseControlLogic;
 
	import flash.display.DisplayObject;
 
	public class Level extends BaseControlLogic{
		private var _enemies : Vector.<Enemy>;
		public function Level(){
		}
 
		override protected function initView(view : Sprite) : void {
			super.initView(view);
			getEnemiesFromView(); // получаем всех врагов
			/*
			* делаем с ними, что надо
			*/
		}
 
		private function getEnemiesFromView():void{
			var child : DisplayObject;
			var enemy : Enemy;
			_enemies = new Vector.<Enemy>();      
 
			for(var : int = 0; i < _view.numChildren; i++){
				child = _view.getChildAt(i);
				if(child is EnemyView){
					enemy = new Enemy();
					enemy.setView(child);
					_enemies.push(enemy);
				}
			}
		}
  }
}

Естественно, Enemy наследуется от BaseControlLogic примерно таким же образом.

Мне кажется, что такой способ должен тебе подойти.
Ну или хотя бы натолкнуть на действия.
В общем использовать flashIDE как редактор уровней вполне себе можно.
И я уже такое делал. Правда тогда весь проект был во флеше, но это не имеет значения. Каждый клип уровня был слинкован со своим классом и передовался методу compileLevel(levelView):Level, который возвращал уже удобно подготовленный к обращению в коде уровень. Ну или не возвращал, если я в дизайне налажал и не поставил, например, ни одного респауна.


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


Так. Кажется, я прослоупочил ответ =)
И немного протупил =(

[КорДум]

От каждого вопрос-сет-контейнера наследоваться? Что с поведением каждого(ну почти) элемента в контейнере?

Как бы, в статье, где вы выложили данную ссылку, описан способ, как можно сделать лучше - gloomyBrain сказал. А вообще да, getChildByName тут, если так уж очень религия не позволяет сделать все программно.

[fljot]

Не вижу я там способа как сделать лучше, там все советуют расширяться от графики или добавлять композицией. А тем временем TanaTiX правильный вопрос задал, да и я тут пример с картинками привёл. Расширение от графики не позволит вам создать разные (визуально) объекты с одни внутренним поведением, для этого надо графику как раз экстендить от кодового класса — для этого есть поле base class (code behind получается). Причём для этого не надо перекомпилировать swc, достаточно указать правильный порядок classpath для mxmlc и ваш код будет вкомпилен вместо указанного во fla base class. Причем с fla-файлом сможет работать даже дизайнер, т.к. вкомпиливать можно (нужно!) классы-пустышки (просто BaseClass extends Sprite/MovieClip).

[gloomyBrain]

достаточно указать правильный порядок classpath для mxmlc

Получается, что нужно писать 2 класса - пустышку для Flash IDE + реальный для mxmlc. А где (как) правильно указать порядок? (И можно ли в FD?)

Ага - в в свойствах проекта =)

[fljot]

Пустышку пускай конечно jsfl генерирует (у fla-файла надо добавить classpath до реальной src папки, чтобы можно было указать на base class, а перед компиляцией swc автоматом создать все базовые классы-пустышки)