Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > API приложений и сред

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 21.08.2013, 02:47
namespaces вне форума Посмотреть профиль Отправить личное сообщение для namespaces Найти все сообщения от namespaces
  № 11  
Ответить с цитированием
namespaces
 
Аватар для namespaces

Регистрация: Jan 2013
Сообщений: 126
Цитата:
Сообщение от alatar Посмотреть сообщение
Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.
Я так понял вы советуете регистрировать все медиаторы в команде, а не в одном главном медиаторе не?


Цитата:
Сообщение от PainKiller Посмотреть сообщение
Вот это вообще зря, теряется смысл использования фреймворка. Его минусы использования как раз в том и заключаются, что на каждый чих приходится создавать кучу классов (вьюху, медиатор, команду + возможно что то еще) - это не всегда оправдано.
А в самом классическом MVC, разве не создается для каждого объекта своя вьюха, контроллер, модель и т.д.?

Добавлено через 2 минуты
Может я действительно что то не дочитал, не понял до конца всю концепцию MVC.

Старый 21.08.2013, 11:05
PainKiller вне форума Посмотреть профиль Отправить личное сообщение для PainKiller Найти все сообщения от PainKiller
  № 12  
Ответить с цитированием
PainKiller
 
Аватар для PainKiller

блогер
Регистрация: Sep 2011
Адрес: Москва
Сообщений: 533
Записей в блоге: 4
Цитата:
А в самом классическом MVC, разве не создается для каждого объекта своя вьюха, контроллер, модель и т.д.?
везде по разному, модель и контроллер вряд ли создается для каждого объекта, да и в самой PureMVC это довольно произвольно - можно делать вьюху и прочее для каждой кнопки, а можно для каждого экрана/страницы/окна т.е. выбирать более крупные объекты

Старый 22.08.2013, 01:28
namespaces вне форума Посмотреть профиль Отправить личное сообщение для namespaces Найти все сообщения от namespaces
  № 13  
Ответить с цитированием
namespaces
 
Аватар для namespaces

Регистрация: Jan 2013
Сообщений: 126
Цитата:
Сообщение от PainKiller Посмотреть сообщение
везде по разному,
Представим так, есть 5 кнопок и все эти кнопки имеют свой слушатель клик, я их создаю и кидаю на сцену в отдельном классе. Потом создаю Медиатор для этого класса, регистрирую все 5 событий которые могут посылать кнопки и переключаюсь через switch выполняя команды.

Код AS3:
override public function handleNotification(note:INotification):void
		{
			switch (note.getName())
			{
				case AppFacade.OPEN_WINDOW: 
					viewComponent.addChild(window);
					Cookie.setCookie("OPEN_WINDOW", 10);
					break;
 
				case AppFacade.CLOSE_WINDOW: 
					viewComponent.removeChild(window);
					Cookie.setCookie("CLOSE_WINDOW", 11);
					break;
 
				case AppFacade.EFFECT_WINDOW: 
					Cookie.setCookie("EFFECT_WINDOW", 12);
					break;
 
				case AppFacade.TRANSITION_IN: 
					Cookie.setCookie("TRANSITION_IN", 13);
					break;
 
				case AppFacade.TRANSITION_OUT: 
					Cookie.setCookie("TRANSITION_OUT", 14);
					break;
 
			}
		}
Правильно делать так? Если управлять все эти спрайты через один Медиатор и обмениваться 20-30 сообщениями, по моему что то не так(
К тому же, при удалении спрайта из Медиатора, сам компонент все еще висит в памяти.
Если удалить таким образом
Код AS3:
viewComponent.removeChild(window);
Добавлено через 5 часов 9 минут
Ах да! По моему начинаю понимать что к чему.
На каждую вьюшку (компонент) создаю свой медиатор, то есть даже одна кнопочка сама по себе не может участвовать в фреймворке без посредника - медиатора. Это прежде всего полезно тем, что мы можем в будущем менять кнопки (классы) как хотим, без затрагивания всего кода и инициализация пройдет автоматически с заранее подготовленным медиатором.
И что самое интересное, штатные оповещения (dispatchEvent) используются только внутри вьюшек (компонентов) и нигде больше. Это придает гибкость приложению.
Все медиаторы, будто главный или последний, должны регистрироваться в команде.
Прокси могут только оповещать, отправлять события но не принимать. Полностью изолированный класс от всей системы.
В команду можно прописать сколько угодно прокси и медиаторов, зависимо от логики приложения, архитектуры.

В итоге я пришел к тому, что PureMVC действительно очень прост в изучении, логичен и очень гибкий инструмент. Прошло 5 дней и он как на ладони) Осталось только начать и творить по принципу Пюре.

Старый 29.10.2013, 20:29
Vasyaga вне форума Посмотреть профиль Отправить личное сообщение для Vasyaga Найти все сообщения от Vasyaga
  № 14  
Ответить с цитированием
Vasyaga

Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
Слегка касался PureMVC и видел некоторые примеры, где медиатор инициализируется при создании представления прямо в коде представления. Как я понимаю, это не есть здорово?

Старый 30.10.2013, 00:19
Котяра вне форума Посмотреть профиль Отправить личное сообщение для Котяра Посетить домашнюю страницу Котяра Найти все сообщения от Котяра
  № 15  
Ответить с цитированием
Котяра
буду краток
 
Аватар для Котяра

модератор форума
Регистрация: Sep 2003
Адрес: Ближайшее Замкадье
Сообщений: 3,110
Записей в блоге: 28
Отправить сообщение для Котяра с помощью ICQ Отправить сообщение для Котяра с помощью Skype™
PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?
__________________
Отряд Котовскага

Старый 30.10.2013, 01:00
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 16  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Цитата:
Сообщение от alatar
в любом случае, для каждого экземпляра вида, создается отдельный экземпляр соответствующего ему медиатора.
Абсолютно не согласен, ибо считаю что один медиатор вполне способен обслуживать несколько однотипных видов. И именно в этом для меня и есть преимущество наличия такого класса как медиатор. Иначе он бесполезная прослойка.

Цитата:
Сообщение от alatar
Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.
Опять же не согласен.
Есть к примеру медиатор попапов. То что зарегистрировалось в фасаде пусть там и висит, есть не просит.
(в угоду производительности конечно можно разные варианты применять, но регистрация/дерегистрация медиаторов, команд, прокси в пюре - часто тупой оверхед ненужный). А вот сами виды - да, можно прятать, дестроить, что угодно с ними делать. Но опять же. Без предыдущего утверждения - этот момент будет не всегда оправдан. Т.е. если медиатор == вью-обжект - тогда как бы придется регистрировать или убирать. Но ЗАЧЕМ????

//******************
Итого:
Команда - одна команда ОДНО действие с ОДНИМ уровнем абстракции, с ОДНИМ срезом логики. Пишет данные в прокси. Слушает нотификации кликов и прочей мути из медиаторов.
Прокси - один прокси умеет работать с НЕСКОЛЬКИМИ дата-обжектами. Через паблик методы принимает данные от команд. Шлет нотификации медиаторам.
Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам.

Медиаторы, прокси, команды - зарегистрировал один раз и пусть живут. Если есть необходимость их убирать из фасада - скорее всего архитектура косая. (Я не беру в учет супер круто написанный проект в котором везде вместо i++ - стоит ++i и прочая муть, и все-равно для оптимизации производителоьности вот прямо ппц как необходимо это сделать). Если не для производительности а по логике - нафиг такую логику.

Добавлено через 7 минут
И еще один момент меня колбасит ппц как.
То что вы юзаете пюре абсолютно не значит что ВСЁ должно быть наследниками классов пюре.
Регистрацию команд или медиаторов проще вынести в отдельный какой-то менеджер.
А дерево медиаторов это имхо просто опа неподдерживаемая.
__________________
Кто к нам с чем для чего - тот у нас того от того.


Последний раз редактировалось Dukobpa3; 30.10.2013 в 01:12.
Старый 30.10.2013, 07:08
Vasyaga вне форума Посмотреть профиль Отправить личное сообщение для Vasyaga Найти все сообщения от Vasyaga
  № 17  
Ответить с цитированием
Vasyaga

Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам.
Совершенно верно!
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Медиаторы, прокси, команды - зарегистрировал один раз и пусть живут. Если есть необходимость их убирать из фасада - скорее всего архитектура косая. (Я не беру в учет супер круто написанный проект в котором везде вместо i++ - стоит ++i и прочая муть, и все-равно для оптимизации производителоьности вот прямо ппц как необходимо это сделать). Если не для производительности а по логике - нафиг такую логику.
Прокси по логике PureMVC действительно регистрируются один раз и живут сколько нужно, чаще всего всю жизнь приложения, т.к. они являются частичным отражением модели. Команды там вообще существуют только во время их (команд) выполнения, потом экземпляр удаляется. А вот медиаторы, могут добавляться/удаляться произвольное количество раз. Пример: Мультидокументный редактор - на каждое представление (вид) документа - свой медиатор. Закрыл документ - уничтожилось представление и его медиатор.
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Добавлено через 7 минут
И еще один момент меня колбасит ппц как.
То что вы юзаете пюре абсолютно не значит что ВСЁ должно быть наследниками классов пюре.
Регистрацию команд или медиаторов проще вынести в отдельный какой-то менеджер.
Можно посылать нотификации и просто через синглтон фасада. Сам так делал. Не часто, но были случаи.
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
А дерево медиаторов это имхо просто опа неподдерживаемая.
Абсолютно не согласен. Пюре же дает механизм нотификаций, т.е. мы избавлены от привязки к стандартной модели событий и их баблингу: кто подписался на сообщение, тот его и будет обрабатывать. И совсем не обязательно элементом дерева медиаторов знать друг о друге: уничтожил вью, уничтожил медиатор. Или вы о чем-то другом?

Добавлено через 10 минут
Цитата:
Сообщение от Котяра Посмотреть сообщение
PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?
А если почитать тему про Хорошее MVC, то мнения многих людей там противоречат друг другу. Вью/контроллеры выделяются в отдельную группу, а модель содержит в себе и бизнес-логику, и получение и хранение данных, что как-бы намекает на разделение, подобное PureMVC. Плюс нотификации пюре решают проблему коммуникаций между частями приложения. Я, конечно, понимаю, что и у пюре есть свои проблемы, но он спокойно работает и позволяет разрешить некоторые неоднозначности классического MVC.

Старый 30.10.2013, 12:25
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 18  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три:
m -> v
v -> c
c -> c

Было бы более кошерное мвц, которое можно и с такой архитектурой фреймворка организовать, но всё-таки лучше если еще и технически как-то ограничено.
__________________
Кто к нам с чем для чего - тот у нас того от того.

Старый 30.10.2013, 13:37
alatar вне форума Посмотреть профиль Отправить личное сообщение для alatar Найти все сообщения от alatar
  № 19  
Ответить с цитированием
alatar
 
Аватар для alatar

блогер
Регистрация: Dec 2008
Адрес: Israel, Natanya
Сообщений: 4,740
Записей в блоге: 11
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Абсолютно не согласен, ибо считаю что один медиатор вполне способен обслуживать несколько однотипных видов. И именно в этом для меня и есть преимущество наличия такого класса как медиатор. Иначе он бесполезная прослойка.
Мне надо было как-то выделить "экземпляр"?

Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Опять же не согласен.
Есть к примеру медиатор попапов. То что зарегистрировалось в фасаде пусть там и висит, есть не просит.
(в угоду производительности конечно можно разные варианты применять, но регистрация/дерегистрация медиаторов, команд, прокси в пюре - часто тупой оверхед ненужный). А вот сами виды - да, можно прятать, дестроить, что угодно с ними делать. Но опять же. Без предыдущего утверждения - этот момент будет не всегда оправдан. Т.е. если медиатор == вью-обжект - тогда как бы придется регистрировать или убирать. Но ЗАЧЕМ????
Опять же, почему бы не дочитать предложение до конца и при чем тут регистрация/дерегистрация? Речь о ЭКЗЕМПЛЯРАХ.[/quote]

Добавлено через 2 минуты
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три...
Было бы лучше вообще без обсервера, в той реализации в которой он есть.
__________________
משיח לא בא
משיח גם לא מטלפן

Старый 30.10.2013, 14:15
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 20  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Цитата:
Мне надо было как-то выделить "экземпляр"?
Пюре весь на синглтонах. Вот как раз пересоздание екземпляров мне и не понравилось.
Вью-обжекты пусть создаются пересоздаются и умирают. А с медиаторами этого делать не обязательно. Хотя есть примеры, вон как с редактором мультиоконным, где это оправданно. В массе же своей - нет.

Цитата:
при чем тут регистрация/дерегистрация?
Екземпляр медиатора не зарегистрированный в фасаде - смысла не имеет. Именно это я и имел в виду. И даже если сам екземпляр медиатора не убивается, а только регистрируется/дерегистрируется - то суть та же. Для системы он умирает.
Поэтому для меня в этом контексте регистрация медиатора == его пересоздание. А будет это новый екземпляр или тот который где-то в пуле пролежал - не суть важно.
__________________
Кто к нам с чем для чего - тот у нас того от того.

Создать новую тему Ответ Часовой пояс GMT +4, время: 09:31.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 09:31.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2022, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.