В Silverlight все отлично, начиная от возможности писать код на всех языках из семьи .NET (ну, конечно же, самый популярный это красавец С#), заканчивая продуманной иерархией визуальных компонентов и возможности их полного видоизменения. Двусторонний биндинг, LINQ, нормальная поддержка ООП, Expression Blend как средство, прошу заметить, удобного «design mode» и т.п.

Есть и некоторые проблемные места, которые во Flex работают из коробки, например невозможность использовать свои курсоры, отсутствие чего-то на подобии PopUpManager, и нативного drag-n-drop. Но это все делается довольно быстро вручную.

В общем, я бы уже и смирился бы с мыслью, что Flex удел мучеников и желающих и далее подставлять костыли в индуский вонючий код, как был просто повержен беглым анализом новых фичей беты Flex 4!

Это был катарсис, оказывается в Adobe не все заснули в двухлетнюю спячку, оказывается они поняли, что раз Microsoft, возможно и своровали идею MXML, binding и вообще флекса как технологии (отмывши это все от толстого слоя ила из берегов Ганга), им ничего не мешает сделать то же самое. И вот, пожалуйста, новый фреймворк визуальных компонентов Spark, который один к одному копирует подход Template Design-а в архитектуре контролов Silverlight, это подробнее обсудим в следующих статьях. Вот тебе и пока-что хромающий Flash Catalyst, идеологическое подобие Expression Blend, вот тебе и новый язык векторной разметки на основе MXML — FXG!, точная копия набора примитивов из XAML (Rect, Ellipse, GradientFill и т.п.). Без которого немыслимо то самое разделение труда дизайнера и программиста.

Мало того, после просмотра исходного кода спарковских контролов, у меня возникло впечатление, что его писали уже люди, а не человеко-недели. Это же можно читать! Подозреваю, что Adobe всё-таки наняла нормальных архитекторов и программистов из штатов. Что конечно достойно глубокого поклона с моей стороны.

В общем, я несказанно счастлив, что теперь есть в чём разбиратся дальше. И что, возможно, вернусь в лоно флекса, как тот самый библейский блудный сын. Конечно же, как говорится, что-бы победить нужно узнать все слабости врага, чем, можно сказать, я сейчас и занимаюсь. Пожалуй в этом контексте и попробую написать несколько статей, не просто сравнивая Silverlight и Flex (слава Богу, сейчас это уже возможно), а рассматривая конкретные подходы в проектировании приложений, которые можно применять на обеих платформах. До встречи, друзья.

Краткий смысл паттерна в том, что мы ожидаем присваивание значений набору свойств компонента в течение одного кадра Flash Player-а, а последующюю логику обработки этих значений переносим на следующий кадр. Это может повысить производительность приложения, а так же навести порядок в обработке значений связанных между собой свойств компонента.

Полагаю, что инвалидация свойств компонентов во Flex практикуется потому, что большинство компонентов инстанциируется посредством MXML и порядок присваивания свойств спрогнозировать невозможно.

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

Я подготовил простой пример, который демонстрирует суть задачи.

Допустим у нас есть класс модели OpportunityDTO, экземпляры которого получаются от сервера и создаются AMF десериализатором Flash Player-а, который нам не подконтролен. В нём есть два свойства date, children, в момент присваивания значений которых, нам нужна дополнительная обработка. Эта обработка должна выполняться только тогда, когда оба свойства получили свои значения. Типичный случай для паттерна инвалидации свойств.

package com.tearaway_tea.model
{
	import flash.events.EventDispatcher;

	import mx.collections.ArrayCollection;

	import org.goverla.interfaces.IPropertiesInvalidable;
	import org.goverla.managers.PropertiesInvalidationManager;

	public class OpportunityDTO extends EventDispatcher implements IPropertiesInvalidable
	{
		public function get date() : Date
		{
			return _date;
		}

		public function set date(value : Date) : void
		{
			_date = value;
			_dateChanged = true;
			invalidateProperties();
		}

		public function get children() : ArrayCollection
		{
			return _children;
		}

		public function set children(value : ArrayCollection) : void
		{
			_children = value;
			_childrenChanged = true;
			invalidateProperties();
		}

		public function invalidateProperties() : void
		{
			PropertiesInvalidationManager.instance.invalidateProperties(this);
		}

		public function commitProperties() : void
		{
			if (_dateChanged && _childrenChanged)
			{
				_dateChanged = false;
				_childrenChanged = false;

				for each (var item : ItemDTO in children)
				{
					item.name += "/" + date.toString();
				}
			}
		}

		private var _date : Date;

		private var _dateChanged : Boolean;

		private var _children : ArrayCollection;

		private var _childrenChanged : Boolean;
	}
}

Для решения этой задачи я предлагаю использовать синглтон PropertiesInvalidationManager, который работает по образу и подобию флексовского LayoutManager-а.

package org.goverla.managers
{
	import mx.rpc.AsyncDispatcher;

	import org.goverla.interfaces.IPropertiesInvalidable;

	public class PropertiesInvalidationManager
	{
		public static function get instance() : PropertiesInvalidationManager
		{
			if (_instance == null)
			{
				_instance = new PropertiesInvalidationManager();
			}
			return _instance;
		}

		private static var _instance : PropertiesInvalidationManager;

		public function invalidateProperties(target : IPropertiesInvalidable) : void
		{
			if (_targets.indexOf(target) < 0)
			{
				_targets.push(target);

				if (_dispatcher == null)
				{
					_dispatcher =
						new AsyncDispatcher(commitProperties, [], 0);
				}
			}
		}

		public function commitProperties() : void
		{
			for each (var target : IPropertiesInvalidable in _targets)
			{
				target.commitProperties();
			}
			_targets = [];
			_dispatcher = null;
		}

		private var _targets : Array = [];

		private var _dispatcher : AsyncDispatcher;

	}
}

Суть очевидна. Менеджер получает ссылку на объект, который нуждается в инвалидации свойств, ставит его в очередь и на следующем кадре вызывает у него commitProperties(). Для откладывания выполнения используется флексовский AsyncDispatcher, который основан на Timer.

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

Но, несмотря на немногочисленную аудиторию, я с удовольствием посмотрел и послушал выступление создателя библиотеки Away3D, Александра Задорожного, как часть доклада «Трёхмерные вебсайты и вебсервисы: возможности, преимущества и перспективы». Он, довольно грустно поведал о разочаровании последней версией Flash Player 10 на предмет отсутствия ожидаемой полной поддержки 3D, а не только базового функционала. Сказал, что забросил своё детище, хотя и удивлён тем, что, проект Away3D так долго существует (связывает это с низкой функциональностю API Flash Player-а).

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

По уже сложившейся «традиции», после моего выступления Сергей Байдачный из Microsoft рассказал о Silverlight. На этот раз о новых фичах третьей беты. Вообще, мне очень интересна тема разработки на Silverlight (думаю, как и большинству сознательных флексеров). Flex до сих пор сложно назвать самым крутым средством для RIA, ввиду забивания со стороны Adobe на большинство вопросов программистского характера (рефакторинг, логичной и управляемой снаружи ООП моделью базовых компонентов, возможности языка Action Script). Так как Silverlight является наследником крутейших средств и методологий .NET-а, то он априори — крут, крут, крут.

Некоторые коллеги постоянно норовят разузнать все детали и нюансы использования Mate на практике и в связи с этим я решил описать пример типового архитектурного решения основанного на модели реального приложения. Он похож на примеры с сайта фреймворка, но расписан пошагово с конкретными рекомендациями на всех уровнях.

Итак, я подготовил проект opportunities (так сказать, подающий большие надежды) на Google Code с доступными исходниками. Для начала рассмотрим его он-лайн:

У нас есть список сущностей с возможностью редактирования каждой из них в отдельной форме, а также добавлять новые — проще не бывает. Следующее решение, как всегда покажется необоснованно сложным для подобного примера, но незабываем, что перед нами стоит задача ознакомления с Mate, а не написания примера в 25 строк экшен-скрипта.

Я использую, так называемую схему «двустороннего коммуницирования посредством модели и инжектинга», на сайте фреймворка есть отличная диаграма как этого так и других приёмов:

Рассмотрим каждый элемент диаграмы основываясь на классах моего примера. Пункт 3 исключаем, так как для доступа к серверу мы используем специальный класс сервиса OpportunitiesMockService наследуемый от ServiceBase (я уже описывал этот приём ранее).

Model

Я определил три класса модели. Самый элементарный, зависимый от представления, класс элемента списка OpportunityVO. Второй класс OpportunitiesDataProvider, является списком экземпляров OpportunityVO, он инкапсулирует в себе вызовы серверных методов и для удобства наследуется от ArrayCollection. Это даёт возможность использовать его провайдером данных для большинства списочных компонентов из Flex фреймворка.

Третий — OpportunityDataProvider, предназначен для работы с конкретным редактируемым OpportunityVO из списка. У него есть публичное свойство opportunity, а также методы для манипуляций с ним. Этот класс диспатчит события opportunityCreated и opportunitySaved типа DataProviderEvent, которые информируют о завершении обработки opportunity (так как эти действия зачастую связаны с вызовом серверных методов, мы неможем ожидать их синхронного выполнения в потоке вызова методов класса). Реализация класса очень простая, но в реальности, в него нужно помещать все трансформации, инициализации и прочие процедуры над элементом, которые не связаны с логикой работы представления, и вполне успешно могут быть отделены от него.

Так же есть вспомогательный класс OpportunityViewState, который используется для хранения информации о текущей видимой форме в представлении. Подобные классы приходится создавать для решения коммуникационных нюансов Mate, далее я их детально опишу.

View

Для представления также определены три класса, первый OpportunitiesListView для показа списка элементов. У него есть одно публичное свойство dataProvider, а также, он диспатчит два события createOpportunity и editOpportunity типа OpportunityEvent, которые говорят сами за себя.

Второй класс OpportunityEditView определяется свойством opportunity, в которое нужно присваивать непосредственно объект редактирования OpportunityVO, а также он диспатчит другие два события saveOpportunity и closeOpportunity также типа OpportunityEvent.

Третий — Index, является композицией предыдущих. В нём доступно свойство selectedIndex, которое определяет текущую видимую форму.

Это наше представление. Как видим, его классы наследуются от стандартных контейнеров Flex фрейворка, они не имеют зависимостей от провайдеров данных модели, являются пассивными и выглядят как довольно самодостаточные компоненты для повторного использования — то, что нам и нужно.

Mate Event Maps

Перейдём непосредственно к роли Mate в связывании модели и представления. Все декларации этого фреймворка описываются в так называемых «картах событий». Это MXML файлы, которые поддерживают биндинг и все остальные удобства Flex Builder-а. По мере увеличения проекта, эти карты довольно сильно разростаются, так что для разных групп коммуникаций я завожу отдельные файлы. В данном примере их четыре.

Одна из карт — DataInjectionMap, описывает связи между представлением и моделью, выполняется только один раз при запуске приложения. Это частичная реализация паттерна IoC (Inversion of Control), которая работает необычным образом: при необходимости, она создаёт только экземпляры классов модели и слушая события родительского Application, в момент создания представлений, выполняет описанные связывания. Типичная нотация с использованием тегов Injectors и PropertyInjector:

<Injectors
	target="{OpportunitiesListView}">
 	<PropertyInjector
		targetKey="dataProvider"
		source="{OpportunitiesDataProvider}" />
</Injectors>

Здесь мы задаем связь на основе биндинга между экземплярами классов OpportunitiesListView и OpportunitiesDataProvider посредством свойства dataProvider, данные которого в результате попадут в DataGrid.

Остальные: OpportunitiesEventMap, DataProviderEventMap, NavigationEventMap, непосредственно описывают действия, которые должны происходить при попадении в поле видимости Mate (Event Bus) каких-либо событий как из представления так и из классов модели. Например, нотация с использованием тегов EventHandlers, MethodInvoker и EventAnnouncer:

 <EventHandlers
	type="{OpportunityEvent.EDIT_OPPORTUNITY}">
 	<MethodInvoker
		generator="{OpportunityDataProvider}"
		method="editOpportunity"
		arguments="{[event.data]}"/>
 	<EventAnnouncer
		type="{NavigationEvent.NAVIGATE_EDIT_VIEW}"
		generator="{NavigationEvent}"/>
</EventHandlers>

Это выражение читается так: в тот момент когда представление продиспатчит событие editOpportunity (по-сути нажатие кнопки Edit), у экземпляра класса модели OpportunityDataProvider должна запуститься операция редактирования экземпляра класса OpportunityVO, которые доступен из события.

Так же, посылается специальное событие NavigationEvent, в результате которого представление должно переключиться в режим редактирования. Внутри класса OpportunityDataProvider, должен произойти вызов серверного метода для получение экземпляра OpportunityVO с последним состоянием элемента (но в моём примере, я упростил схему, и сохраняю в свойстве opportunity модели, тот же объект). Далее, так как мы указали связывание (injection) в DataInjectionMap между OpportunityEditView и OpportunityDataProvider по свойству opportunity, редактируемый элемент будет доступен в представлении.

В свойствах generator или source вышеописанных тегов, мы указываем класс модели, не экземпляр этого класса. Mate автоматически создаст экземпляр в нужный момент, причём, по-умолчанию, только один раз. Фреймворк имеет внутренний кеш для всевозможных экземпляров модели или событий, и ищет там необходимые объекты для повторного использования. Эта схема похожа на паттерн Singleton, но она гораздо практичнее, так как нет лишнего связывания между сущностями системы, которые неизбежны при использовании «одиночек» (кстати, довольно сильный недостаток прочих фреймворков типа Cairngorm или PureMVC).

И напоследок, рассмотрим специфику карты NavigationEventMap, в которой описаны ответные действия на события NavigationEvent. В общем-то, переключение режимов представления могло бы быть реализовано непосредственно в нём. Но, как показала практика, в больших проектах, визуально легче контролировать подход внешнего управления представлением. Например, если необходимо подключить deep-linking (поддержку изменения адресной строки броузера), мы введём ещё один тип событий BrowserNavigationEvent, которые будут использовать уже готовые списки действий в картах Mate. Итак, нотация:

<EventHandlers
	type="{NavigationEvent.NAVIGATE_EDIT_VIEW}">
 	<MethodInvoker
		generator="{OpportunityViewState}"
		method="setSelectedIndex"
		arguments="{[1]}" />
</EventHandlers>

При попадении в Mate события navigateEditView, вызывается метод у вспомогательного класса модели OpportunityViewState, который является проксирующим. Я не хотел бы вводить для этих целей этот класс, а бы присваивал значения в selectedIndex прямо в классе представления Index, но в свойство generator тега MethodInvoker (как и всех других тегов), нельзя указывать классы визуальных компонентов (то-есть можно, но это будет неправильно, так как фреймворк создаст экземпляр, недоступный никому). Суть в том, что, как я уже писал выше, Mate не создаёт экземпляры визуальных компонентов(и не пытается, это делает MXML), он слушает события всего приложения, и когда компонент попадёт в display list флеш плеера, фреймворк начинает с ним «сотрудничать» (зачастую для определения (injection) зависимостей). Получается, что есть внутренний кеш всех созданных классов самим фреймворком и отдельный список компонентов, которыми заведует сам флеш плеер и они не пересекаются между собой.

Вот и всё. Информацию о всех доступных тегах фреймворка можна найти в документации на сайте Mate. Надеюсь описание не получилось чересчур запутанным. С удовольствием отвечу на все адекватные вопросы по теме.

P.S. Кстати, на днях вышло обновление Mate до версии 0.8.7, в котором появилась возможность задавать связи (injection) между интерфейсами.

class ServiceBase
{
	public function ServiceBase(destination : String,
		resultHandler : Function = null, faultHandler : Function = null)
	{
		_resultHandler = resultHandler;
		_faultHandler = faultHandler;

		_remoteObject = new RemoteObject(destination);
	}

	protected function call(name : String, args : Array) : void
	{
		CursorManager.setBusyCursor();

		var operation : AbstractOperation = _remoteObject.getOperation(name);
		operation.addEventListener(ResultEvent.RESULT, onResult);
		operation.addEventListener(FaultEvent.FAULT, onFault);
		operation.send.apply(operation, args);
	}

	protected function onResult(event : ResultEvent) : void
	{
		CursorManager.removeBusyCursor();

		if (_resultHandler != null)
		{
			_resultHandler(event.result);
		}
	}

	protected function onFault(event : FaultEvent) : void
	{
		CursorManager.removeBusyCursor();

		if (_faultHandler != null)
		{
			_faultHandler(event.fault);
		}
	}

	private var _resultHandler : Function;

	private var _faultHandler : Function;

	private var _remoteObject : RemoteObject;
}

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

class GuestbookService extends ServiceBase
{
	public function GuestbookService(resultHandler : Function = null,
		faultHandler : Function = null)
	{
		super("GuestbookAction", resultHandler, faultHandler);
	}

	public function getGuestbookEntries() : void
	{
		call("getGuestbookEntries", arguments);
	}

	public function getEntryById(id : Number) : void
	{
		call("getEntryById", arguments);
	}

	public function updateEntry(id : Number, text : String) : void
	{
		call("updateEntry", arguments);
	}
}

Этот класс я называю сервисом по работе с гостевой книгой. В нём есть все те же методы, что и в серверном классе GuestbookAction (гейтвее или сервлете, в зависимости от платформы). В конструктор можно передать ссылки на функции, которые получат ответ от сервера или информацию о ошибке. Пример использования:

new GuestbookService().updateEntry(5, "Nice solution!");

или

new GuestbookService(onGetEntryById).getEntryById(6);

function onGetEntryById(result : GuestbookEntry) : void
{
	_list.addItem(result);
}

Основной принцип заключается в том, что мы не сохраняем ссылку на экземпляр класса GuestbookService, после того, как он отработает запрос — он нам не нужен. Этот факт можно использовать при множественном вызове серверного метода, каждный раз создавая новый экземпляр сервиса.

Мне этот подход нравится больше чем низкоуровневое конструирование запроса на основе RemoteObject своей прозрачностью и простотой. Так же, подобные наследники можно и следует генерировать автоматически на основе серверных классов. Тогда, вы получаете полный контроль над соответствием названий серверных методов, а так же их сигнатур. Компилятор просто не соберёт ваш проект, если вы не исправите ошибку.

Так же, подобное решение может вам помочь при юнит-тестировании, подменяя базовый класс чем-то вроде MockServiceBase.

На прошедших выходных я решил связаться с разработчиком плагина  Ернестом. Он оказался очень отзывчивым человеком. Мы обменялись с ним некоторым опытом разработки на Action Script и он пообещал доработать плагин и поправить панель настроек.

Сегодня утром, я обнаружил новую версию 0.6.8, которая практически идеальна. Всем рекомендую к использованию, что-бы ваш код был сексуален как никогда ранее.

А так же, не забывайте все претензии добавлять в баг-трекер проекта. Слава Богу, автор очень отзывчивый и оперативный.

Реализация itemRenderer-ов для грида

Никогда не ленитесь и создавайте все свои рендереры наследуя UIComponent или соответствующих контролов Label, CheckBox, TextInput. Никогда не используйте в рендерерах Box, Canvas — они безбожно тормозят.

Что такое mxml?

Что-бы понять суть, добавте параметр -keep-generated-actionscript компилятору флекса. После этого большинство вопросов как это работает, когда допустим биндинг и т.п. исчезнут сами собой.

Слушание событий

По возможности всегда подписывайтесь на события через mxml. Это плохой код:

private function onCreationComplete() : void {
	listView.addEventListener(RotatorsEvent.NEW_ROTATOR, baseEventsHandler);
	listView.addEventListener(RotatorsEvent.EDIT_ROTATOR, baseEventsHandler);
	listView.addEventListener(RotatorsEvent.DELETE_ROTATOR, baseEventsHandler);
	editView.addEventListener(RotatorsEvent.SAVE_ROTATOR, baseEventsHandler);
	editView.addEventListener(RotatorsEvent.CANCEL_ROTATOR, baseEventsHandler);
}

private function baseEventsHandler(event : RotatorsEvent) : void {
	switch (event.type) {
		case RotatorsEvent.NEW_ROTATOR : newRotatorAction(); break;
		case RotatorsEvent.EDIT_ROTATOR : editRotatorAction(); break;
		case RotatorsEvent.SAVE_ROTATOR : saveRotatorAction(event); break;
		case RotatorsEvent.DELETE_ROTATOR : deleteRotatorAction(); break;
		case RotatorsEvent.CANCEL_ROTATOR :
		default  : currentState = LIST_VIEW_STATE;
	}
}

Нужно писать так:

<view:RateCardListToolBar
	newRateCard="onNewRateCard(event)"
	loadRateCardSimpleItems="onLoadRateCardSimpleItems(event)"
	editRateCard="onEditRateCard(event)"/>

Жизненный цикл компонента

Обязательно найдите время для знакомства с очерёдностью и смыслом методов invalidateProperties(), commitProperties(), measure(), invalidateDisplayList(), updateDisplayList() и т.п. Не нужно пытаться что-либо рисовать в объекте graphics в конструкторе, для этого есть другое, более удачное место. Интересуйтесь!

Используйте code-behind

Зачастую использование тега <mx:Script /> допустимо только тогда, когда в нём будет не более одного-двух екранов кода. Если у вас огромный компонент обязательно выносите код в отдельный базовый класс:

Component.mxml:
<ComponentBase
	xmlns="*"
	xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Button
		label="button"
		click="onClick()" />
</ComponentBase>

ComponentBase.as:
package
{
	import mx.controls.Alert;

	public class ComponentBase
	{
		protected function onClick() : void
		{
			Alert.show("Я буду больше интересоваться внутренностями флекса",
				"Напоминание");
		}
	}
}

Event handlers

По-момему, нет ничего лучше чем называть методы хендлеров по такому конвеншену:

Для MouseEvent.CLICK — метод:

onClick(event : MouseEvent) : void

Для ListEvent.CHANGE для объекта с id=”customComponent” — метод:

onCustomComponentChange(event : ListEvent) : void

Избавляемся от противных предупреждений

Если у вас накопилось больше нуля предупреждений — срочной начинайте чистку. Вот, кстати, пример нелогичности Action Script, но тем не менее решаемый:

for each (var item : ItemType in items) {
	...code...
}

...code...

for each (var item : ItemType in items) {
	...code...
}

В таком коде вас ожидает Duplicate code definition warning. Исправить можно заменив последний цикл на такое:

for each (item in items) {
	...code...
}

Непреодолимый public

Все контролы в компоненте mxml имеют область видимости public, к сожалению так устроен мир. Это не значит что к ним можно свободно обращаться снаружи: customComponent.customButton.label = “very bad”, всегда нужно создавать соответствующие гетеры и сетеры: customComponent.buttonLabel = “very well”.

Binding

Во-первых, его нужно использовать. Подходы типа «Мы любим сами контролировать процесc присваивания данных» — пафос и лишняя головная боль. Пример максимально не эффективного кода:

if (!isExpand)
{
	activeDates.visible = false;
	hiatus.visible = false;
	startAirTime.visible = false;
	endAirTime.visible = false;
	daysAirTime.visible = false;
}
else
{
	activeDates.visible = true;
	hiatus.visible = true;
	startAirTime.visible = true;
	endAirTime.visible = true;
	daysAirTime.visible = true;
}

Нужно всего лишь пометь isExpand как [Bindable] и связать все контролы с ним в mxml.

Использование for each

Странно, но многие начинающие флексеры не знают о нём, что приводит к проблемам производительности. Нельзя:

for (var i : int = 0; i < result.length; i++)
{
	result[i].children = rateCard.rateCardsComparison;
}

Нужно:

for each(var item : DataType in result)
{
	item.children = rateCard.rateCardsComparison;
}

Изменение размера и позиции в updateDisplayList()

Глянем пример кода:

protected override  function updateDisplayList(unscaledWidth : Number,
	unscaledHeight : Number) : void
{
	super.updateDisplayList(unscaledWidth, unscaledHeight);

	if (horizontalScrollBar != null)
	{
		horizontalScrollBar.x = watchColumnEdge;
		horizontalScrollBar.width = width - watchColumnEdge;
	}
}

Так делать нельзя (диспачатся лишние события), нужно использовать методы move() и setActualSize().

Dynamic классы

Желательно отказаться от использования этого механизма. Только если нужно бысто заполнять коллекции или что-либо объектами типа {label : “Label”, handler : onSomething}.

Быстро рассмотрим типы приложений, что бы составить план обзора и поиска благоприятной почвы для старта разработки на Flex. По-видимому, все интересующие нас приложения уже можно разделить на вебтопные и десктопные. Веб-приложения могут быть обычными или RIA, и каждые из них могут иметь как front-end — собственно внешний сайт, так и back-end — админку. Не забудем так же и о том, что они могут быть как internet — для обычных обывателей сети, так и intranet — для корпоративных пользователей. С помощью механизма Adobe AIR, Flex стал доступен и на десктопе, но там его использование подчинено сходным требованиям как и в вебе.

Веб-приложения, которые не RIA

Flex практически никогда не нужен при разработке классических сайтов. Классическими я называю: домашние странички, сайты-визитки, новостные сервисы, форумы, блоги, порталы, социальные сети и т.п. Все, кто пытался реализовать их не на связке HTML+JS, в результате получал негибкую, тяжелую поделку, которая плохо индексируется, плохо рендерит текст, не поддерживает стандартную взаимосвязь с броузером и т.п.

Я участвовал в разработке подобного проекта в компании Sonopia. Мы разрабатывали социальную сеть на Flex, которую изначально, под впечатлением тезисов RIA, руководство хотело позиционировать как насыщеную медиа контентом и прочими ультра-штучками. В результате мы получили набор стандартных сервисов: Dashboard, Profile, Photos, Guestbook, которые выглядели как минимум нелепо. В гостевой книге пользователи не могли вставлять теги форматирования текста и ссылки на фотки или флеш виджеты. Перемещение по разделам нормально не синхронизировалось с кнопкой «Back» в броузере. Выполняя минимальный функционал приложение весило 1,5 Мб. В какой-то момент, все заметили что скорость разработки того, что должно быть не Flex, где-то в два раза дольше чем на HTML и большую часть проекта дописывали уже используя стандартные технологии. В результате нам добавилось проблем с синхронизацией обоих частей проекта. Затем команду Flex разработчиков расформировали, а чуть позже старт-ап провалился.

Ещё один пример — портал top4top.ru, пусть он и писался, предусмотрительно, на чистом Action Script, тем не менее это хрестоматийный пример неправильного позиционирования технологии (не говоря уже об общей идейной направленности).

Для персонального интереса, во время изучения Flex, я сделал на нём пару стандартных сайтов для группы Etwas Unders (есть описание) и для студии JMAK. Так как количество разделов и контента было не велико, то они выглядели сносно. Хотя многие посетители недоумевали, зачем там вообще Flex? Согласен — ни к чему. Единственный выигрыш — отсутствие проблем с версткой под основные броузеры (не отрицаю, что для кого-то это будет ключевой бонус).

Не так давно попалась ссылка на сайт http://xoalt.com/, интернет-каталог товаров. Подобные проекты, как и интернет магазины или просто справочники чего-либо вообще запрещено разрабатывать на Flex. Самый главный критерий таких проектов — это высокая доступность поисковым машинам, с чем Flex, как и все флеш-приложения традиционно слабы.

Разработка админок, которые в последнее время часто делают на Flex, так же под вопросом. Если нужна гибкая работа с текстом — будут проблемы, если же вывод табличных данных с необходимостью редактирования, то Flex с AdvancedDataGrid компонентом может помочь быстро справиться с заданием. Drag-n-drop возможен и на JS, но, не спорю, на Flex это можно сделать быстрее и проще.

RIA

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

«Нужно разработать большую кросс-браузерную веб-систему, по мониторингу/управлению/статистике определённых процессов определённого предприятия или продукта. В системе ожидается много иерархических или табличных данных которые нужно сортировать, групировать и редактировать. Нужно запрограммировать более десятка разнообразных форм ввода и изменения данных. Код должен реализовывать практики ООП и быть самодокументированным так как проект долгий и текучка кадров неизбежна.»

«Нам нужна on-line система по обработке видеосигналов с нескольких источников, а так же соотвествующий UI по базовому редактированию и сохранению контента на сервер.»

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

Flex – это наилучшее средство для разработки веб-приложений с большим количеством форм включая наборы нестандартных контролов ввода, с возможностью их скинования, включая все мультимедийные фичи флеш плеера, на основе легко сопровождаемого объектно-ориентированного программного кода.

Так как подобные критерии чаще всего удовлетворяют корпоративные системы, мы и не видим очень много популярных Flex приложений среди известных пользовательских интернет-сервисов. Разве что он-лайн фотошопы и видео-редакторы.

Сейчас, я как раз и занят разработкой подобной корпоративной системы по управлению рекламным контентом на телевидении. Вместо долгих описаний, я приведу пару UI-заготовок, которые должны быть реализованы в сжатые сроки:

Думаю, коментарии, почему в данном случае выбран именно Flex излишни. По-сути, вся данная статья — один большой коментарий вызванный данным проектом.

В заключении можно всё резюмировать банальными фразами. Ваша цель как программиста взвесить многие факторы будущего приложения и основываясь на них не выбрать (чаще всего) или выбрать Flex. Если же вас принимают на вакансию Flex программиста в проект, где его роль сомнительна или абсурдна, подумайте обстоятельно, что бы исскуственно не стать «слабым звеном» в глазах нахальных жавистов или гордых сишарпщиков — сотрудников по проекту (и такое на моём опыте бывало).

Поддавшись на восторженые отзывы риа-гуру я решил разобратся что и к чему. Не надейтесь, я не собирась тут расписывать по-русски о модели работы Mate, я опишу лишь несколькими предложениями: это действительно круто и я отвечаю за свои слова.

Я считаю, успех Mate связан с тем, что это не портированый фреймворк, а написаный именно под Flex. Он использует основные (возможно и не очень правильные) принципы и особенности Flex фреймворка, такие как:

• наследование всех классов от EventDispatcher, которое позволяет использовать bubbling-события, как основные носители сообщений между View, Model и прочими сущностями;
• довольно идентичную особенность биндинга, с помощью которой Mate наладило ненавязчивый IOC (Inversion of Controls);
• разметку mxml для описания деклараций связующих механизмов приложения в простой и понятной форме.

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

В общем, листая документацию сайта, можно получить первое впечатление не более чем за час. Просмотр исходного кода подтвердает подозрения, что авторы проекта — отличные профессионалы, которые обернули нюансы Flex в бонусы. Нужно пользоваться!

Программа доступна для ознакомительной установки. Наврядли удастся как-то использовать на практике, без соответствующего ПО для серверной стороны.

Некоторые детали

Интерфейс программы выполнен без дополнительного «скинования». Я не использовал никаких фреймворков. Поддерживается undo/redo для всех операций. Из интересных архитектурных моментов могу описать процесс декларации метаданных для передачи информации в редактор свойств выбранного элемента в дереве.

По-сути, каждый элемент дерева это наследник базового класса TreeNode, в котором объявлены специфические для его типа свойста, например:

public class PagesBaseNode extends TreeNode {

        [Bindable]
        [Serializable]
        [Editable(group="General", dependentGroup="Page", editor="CheckBoxEditor",
            label="page", bindable="true", index="5")]
        public function get page() : Boolean {
            return _page;
        }

        public function set page(value : Boolean) : void {
            _page = value;
        }

        [Serializable]
        [Editable(group="Page", editor="StringEditor", label="start template:", index="0")]
        public function get startTemplate() : String {
            return _startTemplate;
        }

        public function set startTemplate(value : String) : void {
            _startTemplate = value;
        }

        [Serializable]
        [Editable(group="Page", editor="CollectionEditor", label="aliases:",
            itemsEditor="TwoStringsEditor", itemsClass="PageAliasEntry",
            itemField1="alias", itemField2="target", index="1")]
        public function get pageAliases() : ArrayCollection {
            if (_pageAliases == null) {
                _pageAliases = new ArrayCollection();
            }
            return _pageAliases;
        }

        private var _page : Boolean;

        private var _startTemplate : String;

        private var _pageAliases : ArrayCollection;
    }

С помощью метаданных Serializable я указываю какое значение нужно сохранять в результирующем XML, блок Editable описывает тип редактора, подпись, позицию в наборе, а также, если свойство имеет списочный тип — класс элементов списка и названия полей в которые будут сохранятся значения.

Данное решение очень удобно тем, что при наличии более 10 типов элементов дерева в среднем с 5 уникальными свойствами в каждом из них, я избегаю разработки массы различных форм с разными наборами идентичных контролов для редактирования. При каждом выборе элемента дерева, редактор свойств, используя Repeater, генерирует набор из стандартных, предварительно запрограммированных редакторов: StringEditor, CheckboxEditor, CollectionEditor, TwoStringsEditor etc.

Cчитывание метаданных из объекта — дело техники, это не сложно.

Я подумывал о том, что-бы вычленить базовые классы TreeEditor, TreeArrow и TreeNode как отдельную open source библиотеку. А так же, можно добавить код по обработке метаданных элементов дерева и редактора свойств туда же. Если в коментариях отпишется хотя-бы один человек, кому бы это пригодилось — я это сделаю.

На разработку, в общей сложности и в одиночку, я потратил 6 месяцев. Первые четыре на программирование, вторые два на исправление ошибок. Заказчик очень доволен и не хочет останавливаться на достигнутом. Я, правда, не уверен буду ли я учавствовать в этом продолжении.