mvcExpress (AS3 фрэймворка) презентация для FITC

[Deril_AS3]

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

Я бы не назвал подобное решение элегантным.

Как бы ты написать ето?

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

Это не идея — это ограничение. Чем оно обосновано?

Практикаи. Как я уже упоминал прежде, не имею примера когда нужно mediate view на абстрактном уровне. Mediator имеет очень простую работу - я не вижу причин делать его сложнее.

[alatar]

Как бы ты написать ето?

Так же как и написал в Robotlegs
class ViewA implements IView
class ViewB implements IView

...

,,,
public class BaseMediator extends Mediator
{
    [Inject]
    public var view:IView;
    ...
}
...

...

,,,
public class AMediator extends BaseMediator
{
    [Inject]
    public var model:AModel;
    ...
}
...

mediatorMap.mapView(ViewA , AMediator, IView);
mediatorMap.mapView(ViewB , BMediator, IView);

А "элегантное" решение я использовал для инжекта моделей. Т.к. логика работы с моделями одна и та же, а модели разные.

Добавлено через 1 минуту

Mediator имеет очень простую работу - я не вижу причин делать его сложнее.

А при чем тут усложнение медиатора? На его уровне ничего не меняется.

[Deril_AS3]

понял.

Спасибо за комментарий.

[Deril_AS3]

Я буду делать презентацию в Амстердаме : http://www.fitc.ca/events/speakers/s...eaker_id=13540

Спасибо за голосование!

Вы все еще можете купить Super Early Bird билеты

http://www.fitc.ca/events/tickets/?event=139

[maxkar]

Посмотрел примеры, которые были. Искал ответ на вопрос о том, как именно выполняется инъекция зависимостей в случае, если нужно несколько однотипных данных иметь. Так и не нашел.

Хотелось бы на примере следующий сценарий. Есть много-много однотипных объектов. Допустим, мы делаем редактор предметов для игры. Там в одном из окон выведен список предметов. С каждым предметом можно выполнить какие-то действия. Пусть это будет редактирование названия/характеристик inplace и удаление предмета.

Вопросы:
1. Как и кем создаются view и медиаторы для каждого из этих самых объектов?
2. Как производится инъекция нужного объекта в его view и mediator? Повторю, объектов с одним типом много.

TicTacToe мог бы быть подобным примером, если бы для каждой клетки был свой view. Требование "много однотипных view" - важное. Нужно уметь создавать view с использованием других view. Если ваш фреймворк этого не поддерживает, он не нужен. В этом случае проще взять ту библиотеку, с помощью которой делается такая композиция view.

В общем, какой-то минимальный пример кода хотелось бы. Не обязательно даже "много" действий. Пусть там будет список объектов. У объекта будет выводиться название и кнопка "удалить". Соответственно, "удалить" просто удаляет объект из списка. Основное требование - отображение одного объекта (название + кнопка удаления) выполнено в ввиде отдельного view и список объектов собирается с использованием этих view.

[alatar]

Всегда удивляют категоричные решения типа "не нужно". Вам лично существование этого фреймворка мешает?

Я вот, например, не вижу смысла в создании кучи медиаторов для мелких однотипных объектов. Описанная вами ситуация укладывается в концепцию компонента List. Там и куча однотипных view (item renderer) и редактирование (item editor).

[Deril_AS3]

Это можно сделать так:

В Command или ModuleCore классе:

		mediatorMap.map(SmallItemContainer, SmallItemContainerMediator);
		mediatorMap.map(SmallItem, SmallItemMediator);

package  {
import org.mvcexpress.mvc.Mediator;
public class SmallItemContainerMediator extends Mediator {
 
	[Inject]
	public var view:SmallItemContainer;
 
	override public function onRegister():void{
		for (var i:int = 0; i < 100; i++) {
			var smalItem:SmallItem = new SmallItem();
			smalItem.id = i;
			view.addChild(smalItem);
			mediatorMap.mediate(smalItem);
		}
	}
 
}
}

затем использовать идентификатор id в SmallItemMediator - для работы с SmallItem объектом.

но, как сказал alatar - это не практично.

лучше делать все это в SmallItemContainerMediator. Поместите объекты по идентификатору id в Vector или Dictionary, и работать с ними в SmallItemContainerMediator.

Извините что нет хорошей информации об этом на сайте, будет в будущем.
Я планирую видео курс обучения - но это большая работа.

[maxkar]

Я думал, что там будет что-то идеологически чистое, вроде отдельного модуля на дочерний view. А так - да, совсем непрактично.
1. В вашем решении в UI появилась совершенно ненужный там id. Ну не нужен он самому UI, а нужен только для связывания с медиатором. Причем в данном случае в UI он точно не нужен, вся логика, связанная с ID, прекрасно заканчивается на уровне медиатора и модели.
2. SmallItemMediator вынужден откуда-то получать айтем, с которым он работает. Видимо, из map'а/vector/dictionary на основе ID. Только вот не факт, что везде, где есть те объекты, есть нужный map. Да и не факт, что список объектов не будет локальным для какого-то медиатора и т.п. Вы же заставляете делать глобальное состояние. Это снижает возможность повторного использования.
3. Все делать в SmallItemContainerMediator непрактично. В SmallItemContainer может быть достаточно объемная логика по обработке той маленькой части. Поэтому уже исходя из этого нужна декомпозиция на отдельные панельки. Кроме того, отдельные панельки могут использоваться где-то еще.

Все это приводит к проблемам уже при небольших модификациях исходной задачи. Сначала мы редактировали предметы. Теперь мы будем делать еще и редактор магазина. Товары в магазине - это предметы (из редактора предметов) + цена + количество. Возможность редактировать не только товар, но и свойства предмета сразу из магазина - очень удобная. Почему бы здесь тоже не использовать тот же компонент отображения предмета, что и в исходном случае? Будет компонент отображения товара, внутри которого - компонент отображения предмета. Привязки к модели делаются нормально (модель предмета - часть модели товара). Вот можно ли использовать SmallItemMediator (и SmallItemView) и в первом случае (редактор предмета) и во втором (редактор предмета внутри редактора товара)? А мы потом еще где-нибудь сделаем панельку, где только какой-то один предмет выводится (чтобы не было списка объектов)... Так что явные прямые биндинги медиаторов к данным (или возможность идентифицировать данные и привязать медиатор к каким-то данным по ID) нужна.

Вообще, биндинг только по типам - не очень хорошая идея. Она накладывает массу ограничений на варианты использования. Посмотрите готовые dependency injection frameworks, там, скорее всего, практически везде есть возможность биндинга по имени. Это все потому, что может быть много объектов с одним типом, но различной "семантикой". Причем у меня, например, это достаточно типичная ситуация. Может быть несколько различных кэшей с одной и той же реализацией (но разными хранимыми объектами). Заводить несколько лишних классов только для того, чтобы обойти ограничения контейнера - перебор.

Я вот, например, не вижу смысла в создании кучи медиаторов для мелких однотипных объектов. Описанная вами ситуация укладывается в концепцию компонента List. Там и куча однотипных view (item renderer) и редактирование (item editor).

Ну да, укладывается при введении кучи дополнительных ограничений. Кнопочка "удалить предмет" должна присутствовать сразу в списке. Если это делать через renderer, у вас автоматически появится и какой-то контроллер для каждого объекта, созданного рендерером. А иначе нужно будет войти в "режим редактирования", чтобы у активного объекта появился правильный контроллер... Кстати, все равно всплывает контроллер для редактирования и как его биндить "естественно" в предлагаемом фреймворке - не очень понятно. Так что на реализацию List (пусть даже с рендерерами и едиторами) я бы с удовольствием посмотрел, там могут быть и другие проблемы. Использование же для большей части ручнуй композицию из вью/контроллеров автоматически приводит к тому, что все основные проблемы (которые пытается решать автор фреймворка) уже решены и фреймворк ничего не дает.

Всегда удивляют категоричные решения типа "не нужно". Вам лично существование этого фреймворка мешает?

Беспокоит. А вдруг мне потом достанется для поддержки что-нибудь с использованием этого фреймворка? Это при том, что фреймворк имеет огромные ограничения по сценариям применения. И мне потом придется мучаться, делая вещи совершенно неочевидными и сложными (по сравнению с наивной реализацией) способами. Или просто выпиливая фреймворк с уменьшением объема и увеличением понятности кода.

Есть и вторая, чуть менее практичная причина. А вдруг автор фреймворка задумается над описываемыми мною проблемами и общей идеей фреймворка. Потом проработает много-много возникающих из этих общих проблем вопросов. И затем создаст одну или несколько библиотек, прекрасно решающих некоторые задачи (без существенных ограничений, как в случае фреймворка). Может быть, я потом смогу где-то использовать эти библиотеки

[alatar]

Если это делать через renderer, у вас автоматически появится и какой-то контроллер для каждого объекта, созданного рендерером

Достаточно одного медиатора для списка и всплывающих событий от рендерера.

[Deril_AS3]

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

В вашем решении в UI появилась совершенно ненужный там id.

это нужно чтобы связать view с data...

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

SmallItemMediator вынужден откуда-то получать айтем

автоматически Inject, когда делаете mediate()

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

Вообще, биндинг только по типам - не очень хорошая идея.

Вы можете использовать:

		mediatorMap.mediateWith(new Sprite(), MyCustomSpriteMediator);

(спасибо alatar. Он уже сказал об этой проблеме.)


Спасибо за ваши комментарии. интересно узнать различные точки зрения.