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

[Deril_AS3]

Здравствуйте.

предлагаю вашему вниманию мой фреймворк "MvcExpress": http://mvcexpress.org/.


MvcExpress облегчает программирование и работает быстрее чем PureMVC и RobotLegs, бесплатен(open source).

Презентация фреймворка состоится на FITC в Амстердаме 18-19 февраля 2013 года.
Охотно отвечу на все вопросы, как онлайн, и если кто приедет в Амстердаме, на FITC.

Проголосовать за презентацию можно здесь:
http://submit.fitc.ca/forums/139893-fitc-amsterdam-2013/suggestions/3264014-next-step-in-as3-framework-evolution

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

[incvizitor]

А в двух фразах можно объяснить, чем он лучше аналогов?

[Astraport]

В двух словах:
Simplest (http://mvcexpress.org/simplest/)
Fastest (http://mvcexpress.org/fastest/)
Хотя, конечно, желательно послушать автора.

[alatar]

Насчет первого я бы поспорил. Ничуть не проще Robotlegs. Частично по стилю похож на Robotlegs, частично на pureMVC. Команды регистрируются только по типу события, класс события никак не проверяется. Пока впечатления не однозначные.

Добавлено через 4 минуты
View нельзя ижектить в медиатор как интерфейс, только как класс.

[Deril_AS3]

В двух словах:
Simplest (http://mvcexpress.org/simplest/)
Fastest (http://mvcexpress.org/fastest/)
Хотя, конечно, желательно послушать автора.

Трудно сказать лучше .. :) спасибо Astraport.

хотя... шаг за шагом я добавляю новые функции, и я думаю, скоро мне придется изменить "Simplest" в "more features".


alatar также прав. Этат фрэймворк представляет собой смесь PureMVC и RobotLegs лучших функций. Именно поэтому в презентацие я буду говорить об "эволюции", а не "революция".

трудно улучшить RobotLegs простоту. Но я думаю, что я лучше назвал объектю и функций, и интерфейс чище, больше... "explicid".

Эта тема имет субъективный характер, но простота - одна из моих основных целей.


View нельзя ижектить в медиатор как интерфейс, только как класс.

Я думал над тем, но мне не удалось придумать хороший сценарий для этой функции.


можешь дать хороший пример?

[alatar]

можеш дать хороший пример?
Набор однотипных view, например графики, с одинаковым поведением и интерфейсом. Разница только в поставляемой модели. Базовый медиатор напрашивается один, разница будет только в имени модели, что решается наследованием медиатора.

Есть у меня один проект с таким функционалом. Киллер-фичей было бы создание правила инжекта модели в медиатор в зависимости от класса view. Т.к. модели тоже имеют один интерфейс.

Добавлено через 7 минут
В MvcExpress меня также смущает, что proxy передается только как объект. Нет ленивой инициализации.

Добавлено через 10 минут
Также хотелось бы, что бы CommandMap#execute возвращал созданную команду, для простой реализации AsyncCommand и цепочек команд.

[Deril_AS3]

Спасибо за пример! я подумаю над этом, сделаю модель.


В MvcExpress меня также смущает, что proxy передается только как объект. Нет ленивой инициализации.

будет! (v1.3.0). :) https://github.com/MindScriptAct/mvcExpress-framework/issues/23


... для простой реализации AsyncCommand и цепочек команд.

для async commands и цепочек у меня есть это решение:



package com.mindScriptAct.mapEditor.controler {
...

public class AsyncCommand extends Command {

public function execute(blank:Object):void {
var imageLoader:Loader = new Loader();
imageLoader.addEventListener(Event.COMPLETE, handleImmageLoad);
imageLoader.load(new URLRequest("example.jpg"));
}

private function handleImmageLoad(event:Event):void {
// think what to do next...
if (...) {
// execute next command if needed..
commandMap.execute(NextCommandInChain, params);
}
}

}
}



в mvcExpress невозможно получать Cammand i Mediator объекты, никоим образом.
Я хочу, чтоб именно так осталась.

Добавлено через 4 часа 43 минуты
Набор однотипных view, например графики, с одинаковым поведением и интерфейсом. Разница только в поставляемой модели. Базовый медиатор напрашивается один, разница будет только в имени модели, что решается наследованием медиатора.

Есть у меня один проект с таким функционалом. Киллер-фичей было бы создание правила инжекта модели в медиатор в зависимости от класса view. Т.к. модели тоже имеют один интерфейс.


Я понял ситуацию правильно?

http://mvcexpress.org/temp/InterfacedViewModel.jpg

[alatar]

Картинку лучше вставить в сообщение в расширенном режиме. На данный момент я ее не вижу. :(

Добавлено через 3 минуты
Я понял ситуацию правильно?
Похоже.

[Deril_AS3]

hm...

В этой конкретной ситуации, я бы делал так:




package temp {
import org.mvcexpress.mvc.Mediator;

public class BaseMediator extends Mediator {

protected var baseView:IBaseInterface;

override public function onRegister():void {
// mediate IBaseIterface specific stuff.
}

}
}



package temp {
import org.mvcexpress.mvc.Mediator;

public class A1Mediator extends BaseMediator{


private var _view:WiewA1;

[Inject]
public var proxyX:ProxyX;

[Inject]
public function set view(value:WiewA1):void {
baseView = value;
_view = value;
}

override public function onRegister():void{
super.onRegister();
// mediate ViewA1 specific stuff.
}

}
}


Элегантное решение, и все функции находятся в правильных классов.

и использовать так:


mediatorMap.map(ViewA1, A1Mediator);
mediatorMap.map(ViewA2Sub, A2Mediator);
mediatorMap.map(ViewBSub, BMediator);

...

var testView:ViewA1 = new ViewA1();
mediatorMap.mediate(testView);



Добавить view inject как интерфейс легко, но я не могу найти хороший практический пример где это необходимо(как функция, или просто для удобства).

Идея такова: каждый конкретный view должна иметь конкретный mediator.
Если view имеет суперклас - mediator может иметь также суперклас, если это нужно.

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

[alatar]

Я бы не назвал подобное решение элегантным.
Идея такова: каждый конкретный view должна иметь конкретный mediator.
Это не идея — это ограничение. Чем оно обосновано?

[Deril_AS3]

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

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


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

Практикаи. Как я уже упоминал прежде, не имею примера когда нужно 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/speaker.cfm?event=139&speaker_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]

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

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

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

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


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

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


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


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


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