Хорошее MVC

[crazyone]

Вот оно как, оказывается. Спасибо за пояснения.

ЗЫ Я кстати понял, почему мне древовидное ветвление в MVC тяжело дается. Пытаюсь думать кодом. А если нарисовать диаграмку, сразу так легко и понятно все становится.

[tofflife]

MVP/MMVC больше подуше.

Spicelib, parsley нам в помощь.

[fish_r]

Сообщение от Zebestov

В любом MVC ни при каком раскладе и ни на каком этапе выполнения приложения входной точкой не должен становиться view, для которого все же существует controller. У меня он тоже "тонкий", но входная точка на каждом этапе приложения — именно контроллер. Именно он всех инициирует, собирает докучи и запускает в нужном порядке. Если не поздно — подумай над реорганизацией.

Т.е. как концептуально это выглядит? Примерно так?

 
import flash.display.MovieClip;
import org.flashdevelop.utils.FlashViewer;
 
 
///Host
class Main extends MovieClip
{
	public function Main()
	{
		new Controller( this );
	}
}
 
 
///Controller
import flash.events.EventDispatcher;
 
class Controller extends EventDispatcher
{
	public function Controller(scene:Main, target:IEventDispatcher = null)
	{
		var model:Model = new Model();
		var view:Viewer = new Viewer(model);
		scene.addChild( view );
 
	}
}
 
///Model
class Model extends EventDispatcher
{
	public const READY_DATA:String = "ready data";
	public function Model()
	{
		...
	}
}
 
 
///View
import flash.display.Sprite;
 
class Viewer extends Sprite
{
	public function Viewer(model:Model)
	{
		model.addEventListener( Model.READY_DATA, init);
	}
 
	private function init():void
	{
		///start
	}
}

А кто представляет объект снаружи? Контроллер? Ну в данном случае, если напр. мейн захочет обратиться
к вьюеру.

Можно какой то мин. примерчик? Или пруф.

[Zebestov]

Сообщение от fish_r

Т.е. как концептуально это выглядит? Примерно так?

Примерно так.

Сообщение от fish_r

Ну в данном случае, если напр. мейн захочет обратиться к вьюеру.

Что он там забыл? Main создал контроллер и ушел на заслуженный отдых. Отец семейства теперь — твой главный контроллер. И он может всегда дотянуться до своей вьюхи. А потом приложение должно перейти в другую стадию. Тот же контроллер создаст новый контроллер, тот в свою очередь полностью возьмет на себя новый этап приложения, создаст новый view и будет с ним работать сам. По окончании просто приберет за собой и сообщит "папе", что все закончено. Главный контроллер будет с нетерпением ждать этого сообщения, чтобы решать, куда идем дальше.

В общих чертах.

[Psycho Tiger]

По сути, Main - контейнер для вьюшек и инициализатор контроллера.

[etc]

Controller в принципе не должен знать, что такое Main.
Константы имён событий надо объявлять в самих событиях.

[fish_r]

Сообщение от etc

Controller в принципе не должен знать, что такое Main.

Да, конечно. Это пример написанный наспех. Контроллер может воспринимать Main как просто DOC, но мне все равно не нравится - не должен объект сам себя куда-то добавлять.

Константы имён событий надо объявлять в самих событиях.

Имеется в виду так?

  [Event( name="some event" type="com.somepack.SomeClass" )]

Мне удобнее традиционным способом - видно перечень констант в панели Outline.

[etc]

Сообщение от fish_r

Да, конечно. Это пример написанный наспех. Контроллер может воспринимать Main как просто DOC, но мне все равно не нравится - не должен объект сам себя куда-то добавлять.

Кто куда кого добавляет? DOC, да, это логичнее.

Сообщение от fish_r

Имеется в виду так?

  [Event( name="some event" type="com.somepack.SomeClass" )]

Мне удобнее традиционным способом - видно перечень констант в панели Outline.

И [Event()] тоже, как раз в аутлайне и появится (это в FB во всяком случае). Тигра выше написал, что имелось ввиду.

[fish_r]

Сообщение от etc

Кто куда кого добавляет?

В примерном коде, у меня, где "точка входа - контроллер" возможны два варианта:
- контроллер получает ссылку на контейнер и добавляет туда вьюер,
- контроллер отдает ссылку на свой вьюер (другому контроллеру, или контейнеру).

Оба варианта мне не нравятся, потому, что контроллер должен иметь дело с сигналами объектов, а не с манипуляцией объектами.

Нет, имеется ввиду определение этих констант в наследнике Event.

И [Event()] тоже, как раз в аутлайне и появится (это в FB во всяком случае). Тигра выше написал, что имелось ввиду.

Создание объекта расширяющего Event, с определением перечня каст. набора событий -
в результате мы получаем возможность подписываться на события инициализируемые другим объектом, даже не находящимся в области видимости подписчика? Это имеется в виду?

[etc]

Сообщение от fish_r

В примерном коде, у меня, где "точка входа - контроллер" возможны два варианта:
- контроллер получает ссылку на контейнер и добавляет туда вьюер,
- контроллер отдает ссылку на свой вьюер (другому контроллеру, или контейнеру).

Оба варианта мне не нравятся, потому, что контроллер должен иметь дело с сигналами объектов, а не с манипуляцией объектами.

По мне так контроллер на то и контроллер, чтобы манипулировать.

Сообщение от fish_r

Создание объекта расширяющего Event, с определением перечня каст. набора событий -
в результате мы получаем возможность подписываться на события инициализируемые другим объектом, даже не находящимся в области видимости подписчика? Это имеется в виду?

Нет, имелась ввиду лишь первая часть про создание кастомного события. Остальная часть за гранью понимания.