Как стать автором
Обновить

Комментарии 14

Достаточно понятно, надо будет посмотреть. Opportunities как демонстрация, или дальше из него что-нибудь получится?
Да, это синтетический пример, но я его оформил по схеме большого типичного корпоративного приложения (списки сущностей и формы их редактирования). В частности у меня в рабочем проекте, такой же принцип организации представленя и данных.

Развитие примера не предусмотрено.
Его действительно не хватало.
Модель MVC можно реализовать и самому без всех этих фреймворков, используя самые важные вещи для себя. Например, в проекте где я работаю, был использован фреймворк написаный по подобию CairnGorm, только заметно проще.

Но часто появляется проблема создания сложных UI компонентов, которые требуют заказчики и рисуют дизайнеры. И вот как раз на эту тему в интернете очень мало материала, да и никаких библиотек нет, а реализовывать в чистом виде использую за основу классы Flex выходит накладно
Конечно можно, и я написал некоторое количество проектов, без использования фреймворков. Но, суть использования Mate, как раз и заключается в крайней ненапряжности. Тоесть, вы пишите как всегда, но теперь 5% нюансов покрываете с помощью Mate.

Объясните подробнее, о проблеме с UI компонентами, может я попробую написать статью на эту тему. Есть некоторые приёмы построение шаблонных компонентов, которые могут покрывать гибкие требования заказчика.
Суть всех Flex-фреймворков, что я видел (в том числе и этот Mate) сводится к тому, чтобы автоматизировать процесс создания однотипных RIA: списки сущностей, формы для редактирования, отображение данных и так далее, естественно используя для этого богатые возможности Flex SDK и UI компонентов которые можно реализовать с помощью Flash.

Но заказчики (а скорее даже дизайнеры и специалисты по Usability) видя такой инструмент как Flex не ограничивают себя в фантазии и предлагают для реализации сложнейшие компоненты. Например у меня в приложении существуют Комбобоксы и Деревья совмещенные с радиобаттонами и чекбоксами: В дереве ветвь енаблится/дизаблится радиобаттоном, а листья отмечаются чекбоксами и все это, естественно, некоторым образом должно быть связано с моделью и изменять ее. Или скажем DataGrid совмещенный с деревом, в котором некоторые строки (rows) распахиваются как ветвь в дереве.

Конечно сами по себе эти компоненты реализовать возможно. Но когда дело доходит до того, чтобы попытаться связать такой компонент с самим шаблоном MVC, не нарушая парадигмы (скажем view не может изменять model, а только рассылать события и слушать (binding) модель) тут и начинаются проблемы
Вы всё правильно описали. Но, следует разделять такие понятия как контрол и компонент.

У нас тоже используются такие нестандартные контролы, как, например, комбобокс совмещённый с деревом и чекбоксами. Это контрол — атомарный элемент UI, в нём не должно быть никаких попыток связи с моделью, только набор событий которые он диспатчит и публичные гетеры/сетеры, которые определяют данные, которые он обрабатывает.

Если же речь идёт о компонентне, который является композитом атомарных контролов, то здесь уже можно отойти от принципа контролов и добавлять код, которые увязывает логику его работы с моделью или чем либо.

Я ещё ввожу термин вью(представление), это особо обширный копмозит компонентов, который соответствует большой области на экране или всему экрану.

По идее, всё что мы создаём с помощью MXML это компоненты, так нам подсказывает и Flex Builder. А атомарные, полностью независимые ни от чего контролы, зачастую делают в чистом Action script наследуя UIComponent.
использую PureMVC в проекте, где много _сложных_ составных компонентов. Полет нормальный. Mate что-то не впечатлил, имхо это для тех, кому сложно поделить в голове свой код на отдельные независимые mxml (и as3) компоненты и работать с ними/связывать их исключительно через mvc фреймворк.
Э, как же так, зачем тогда вообще фреймфорк, если не разделять код на независимые сущности?

Что-то вы излишне компроментируете Mate =)
я, наверное, не совсем понятно выразился. PureMVC хорош именно тем, что не использует никаких flex/mxml-специфичных фич. Это позволят четко провести грань между компонентами и их связями в _голове_ разработчика, что очень помогает в больших проектах. «Влезать в кабалу создания огромного количества классов» — во-первых, не огромного, а ровно один медиатор на один компонент, во-вторых, это не кабала, а очень приятный процесс — представьте себе, вы пишете логику программы вообще не обращая внимания на то, как в конце-концов будут реализованы компоненты, т.е. разделение полное, не даром он *pure* mvc. Это сложно объяснить словами, понимание приходит только в процессе разработки…
Что-то в ваших словах есть конечно. Я, чесно говоря, не пробовал использовать PureMVC, всегда отталкивала указанная схема: на один компонент — один медиатор.

Пожалуй, действительно, слова тут не к месту, нужно ощущать и делать персональные выводы об удобстве.
НЛО прилетело и опубликовало эту надпись здесь
Скажите пожалуйста а разве правильно, что модель самостоятельно без участия
контроллера связывается с сервером ?!

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. Потому как два года работаю с ним, тогда, когда писалась статья я думал по другому.

Однозначно правильных решений нет, делайте так как вам удобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации