Комментарии 14
Достаточно понятно, надо будет посмотреть. Opportunities как демонстрация, или дальше из него что-нибудь получится?
Его действительно не хватало.
Модель MVC можно реализовать и самому без всех этих фреймворков, используя самые важные вещи для себя. Например, в проекте где я работаю, был использован фреймворк написаный по подобию CairnGorm, только заметно проще.
Но часто появляется проблема создания сложных UI компонентов, которые требуют заказчики и рисуют дизайнеры. И вот как раз на эту тему в интернете очень мало материала, да и никаких библиотек нет, а реализовывать в чистом виде использую за основу классы Flex выходит накладно
Но часто появляется проблема создания сложных UI компонентов, которые требуют заказчики и рисуют дизайнеры. И вот как раз на эту тему в интернете очень мало материала, да и никаких библиотек нет, а реализовывать в чистом виде использую за основу классы Flex выходит накладно
Конечно можно, и я написал некоторое количество проектов, без использования фреймворков. Но, суть использования Mate, как раз и заключается в крайней ненапряжности. Тоесть, вы пишите как всегда, но теперь 5% нюансов покрываете с помощью Mate.
Объясните подробнее, о проблеме с UI компонентами, может я попробую написать статью на эту тему. Есть некоторые приёмы построение шаблонных компонентов, которые могут покрывать гибкие требования заказчика.
Объясните подробнее, о проблеме с UI компонентами, может я попробую написать статью на эту тему. Есть некоторые приёмы построение шаблонных компонентов, которые могут покрывать гибкие требования заказчика.
Суть всех Flex-фреймворков, что я видел (в том числе и этот Mate) сводится к тому, чтобы автоматизировать процесс создания однотипных RIA: списки сущностей, формы для редактирования, отображение данных и так далее, естественно используя для этого богатые возможности Flex SDK и UI компонентов которые можно реализовать с помощью Flash.
Но заказчики (а скорее даже дизайнеры и специалисты по Usability) видя такой инструмент как Flex не ограничивают себя в фантазии и предлагают для реализации сложнейшие компоненты. Например у меня в приложении существуют Комбобоксы и Деревья совмещенные с радиобаттонами и чекбоксами: В дереве ветвь енаблится/дизаблится радиобаттоном, а листья отмечаются чекбоксами и все это, естественно, некоторым образом должно быть связано с моделью и изменять ее. Или скажем DataGrid совмещенный с деревом, в котором некоторые строки (rows) распахиваются как ветвь в дереве.
Конечно сами по себе эти компоненты реализовать возможно. Но когда дело доходит до того, чтобы попытаться связать такой компонент с самим шаблоном MVC, не нарушая парадигмы (скажем view не может изменять model, а только рассылать события и слушать (binding) модель) тут и начинаются проблемы
Но заказчики (а скорее даже дизайнеры и специалисты по Usability) видя такой инструмент как Flex не ограничивают себя в фантазии и предлагают для реализации сложнейшие компоненты. Например у меня в приложении существуют Комбобоксы и Деревья совмещенные с радиобаттонами и чекбоксами: В дереве ветвь енаблится/дизаблится радиобаттоном, а листья отмечаются чекбоксами и все это, естественно, некоторым образом должно быть связано с моделью и изменять ее. Или скажем DataGrid совмещенный с деревом, в котором некоторые строки (rows) распахиваются как ветвь в дереве.
Конечно сами по себе эти компоненты реализовать возможно. Но когда дело доходит до того, чтобы попытаться связать такой компонент с самим шаблоном MVC, не нарушая парадигмы (скажем view не может изменять model, а только рассылать события и слушать (binding) модель) тут и начинаются проблемы
Вы всё правильно описали. Но, следует разделять такие понятия как контрол и компонент.
У нас тоже используются такие нестандартные контролы, как, например, комбобокс совмещённый с деревом и чекбоксами. Это контрол — атомарный элемент UI, в нём не должно быть никаких попыток связи с моделью, только набор событий которые он диспатчит и публичные гетеры/сетеры, которые определяют данные, которые он обрабатывает.
Если же речь идёт о компонентне, который является композитом атомарных контролов, то здесь уже можно отойти от принципа контролов и добавлять код, которые увязывает логику его работы с моделью или чем либо.
Я ещё ввожу термин вью(представление), это особо обширный копмозит компонентов, который соответствует большой области на экране или всему экрану.
По идее, всё что мы создаём с помощью MXML это компоненты, так нам подсказывает и Flex Builder. А атомарные, полностью независимые ни от чего контролы, зачастую делают в чистом Action script наследуя UIComponent.
У нас тоже используются такие нестандартные контролы, как, например, комбобокс совмещённый с деревом и чекбоксами. Это контрол — атомарный элемент UI, в нём не должно быть никаких попыток связи с моделью, только набор событий которые он диспатчит и публичные гетеры/сетеры, которые определяют данные, которые он обрабатывает.
Если же речь идёт о компонентне, который является композитом атомарных контролов, то здесь уже можно отойти от принципа контролов и добавлять код, которые увязывает логику его работы с моделью или чем либо.
Я ещё ввожу термин вью(представление), это особо обширный копмозит компонентов, который соответствует большой области на экране или всему экрану.
По идее, всё что мы создаём с помощью MXML это компоненты, так нам подсказывает и Flex Builder. А атомарные, полностью независимые ни от чего контролы, зачастую делают в чистом Action script наследуя UIComponent.
использую PureMVC в проекте, где много _сложных_ составных компонентов. Полет нормальный. Mate что-то не впечатлил, имхо это для тех, кому сложно поделить в голове свой код на отдельные независимые mxml (и as3) компоненты и работать с ними/связывать их исключительно через mvc фреймворк.
Э, как же так, зачем тогда вообще фреймфорк, если не разделять код на независимые сущности?
Что-то вы излишне компроментируете Mate =)
Что-то вы излишне компроментируете Mate =)
я, наверное, не совсем понятно выразился. PureMVC хорош именно тем, что не использует никаких flex/mxml-специфичных фич. Это позволят четко провести грань между компонентами и их связями в _голове_ разработчика, что очень помогает в больших проектах. «Влезать в кабалу создания огромного количества классов» — во-первых, не огромного, а ровно один медиатор на один компонент, во-вторых, это не кабала, а очень приятный процесс — представьте себе, вы пишете логику программы вообще не обращая внимания на то, как в конце-концов будут реализованы компоненты, т.е. разделение полное, не даром он *pure* mvc. Это сложно объяснить словами, понимание приходит только в процессе разработки…
Скажите пожалуйста а разве правильно, что модель самостоятельно без участия
контроллера связывается с сервером ?!
public function saveOpportunity(): void
{
opportunity.lastUpdate = new Date();
new OpportunitiesMockService(onUpdateOpportunity).updateOpportunity(opportunity);
function onUpdateOpportunity(result: OpportunityVO): void
{
opportunity = result;
new Dispatcher().dispatchEvent(
new DataProviderEvent(DataProviderEvent.OPPORTUNITY_SAVED));
}
}
контроллера связывается с сервером ?!
public function saveOpportunity(): void
{
opportunity.lastUpdate = new Date();
new OpportunitiesMockService(onUpdateOpportunity).updateOpportunity(opportunity);
function onUpdateOpportunity(result: OpportunityVO): void
{
opportunity = result;
new Dispatcher().dispatchEvent(
new DataProviderEvent(DataProviderEvent.OPPORTUNITY_SAVED));
}
}
Ну, не вижу в этом никаких проблем. Контроллер должен поддерживает взаимодействие между моделями, сами же модели вполне могу загружать и сохранять данные из сервера.
Вообще, я сейчас исхожу уже из паттерна Model-View-ViewModel в Silverlight. Потому как два года работаю с ним, тогда, когда писалась статья я думал по другому.
Однозначно правильных решений нет, делайте так как вам удобно.
Вообще, я сейчас исхожу уже из паттерна Model-View-ViewModel в Silverlight. Потому как два года работаю с ним, тогда, когда писалась статья я думал по другому.
Однозначно правильных решений нет, делайте так как вам удобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример использования Mate Flex Framework