Рано или поздно любой flex-разработчик понимает, что нужно что-то сделать с собственным “винегретом” в коде, состоящим из mxml-разметки вперемешку с inline-кодом. А, собственно, что с ним не так? Если кратко, то:

• код трудночитаем, из-за постоянного перехода внутри одного файла от as3 кода к mxml разметке и обратно;
• сильная связанность (нет возможности легко заменить разметку или реализацию);
• низкая переиспользуемость кода (трудно перенести код/разметку в другой проект);
• отсутствует возможность разделить обязанности между разработчиком и дизайнером (кто-нибудь помнит/пользовался Flash Catalyst?, ах да: Development and sales ended on April 23, 2012);
• сильно разросшийся размер файла;
• и так далее.

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

<?xml version="1.0" encoding="utf-8"?>   
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"  
    xmlns:s="library://ns.adobe.com/flex/spark"  
    xmlns:mx="library://ns.adobe.com/flex/mx"  
    height="450">  

    <s:layout>  
        <s:VerticalLayout/>  
    </s:layout>  

    <fx:Script> <![CDATA[  
        import spark.events.IndexChangeEvent;  
        private function myChangedHandler(event:IndexChangeEvent):void  
        {  
            var selIndices:Vector.<int> = event.currentTarget.selectedIndices;  
            var selItems:Vector.<Object> = event.currentTarget.selectedItems;  
            var numItems:Number = selIndices.length;  
            selIndicesTA.text = "";  
            selItemsTA.text = "";  
            for (var i:Number = 0; i<numItems; i++)  
            {  
                selIndicesTA.text = selIndicesTA.text + selIndices[i] + "\n";  
                selItemsTA.text = selItemsTA.text + selItems[i] + "\n";  
            }  
        }  
    ]]>  
    </fx:Script>  
 
    <s:List allowMultipleSelection="true" change="myChangedHandler(event);">  
        <mx:ArrayCollection>  
            <fx:String>Flex</fx:String>  
            <fx:String>Flash Builder</fx:String>  
            <fx:String>Flash</fx:String>  
            <fx:String>Director</fx:String>  
            <fx:String>Dreamweaver</fx:String>  
            <fx:String>ColdFusion</fx:String>  
        </mx:ArrayCollection>  
    </s:List>  

    <s:Label text="Selected indices"/>  
    <s:TextArea id="selIndicesTA" height="75"/>  
    <s:Label text="Selected items"/>  
    <s:TextArea id="selItemsTA" height="75"/>
  
</s:Application>

Вместо того, чтобы пропагандировать “здоровое кодирование”, а также потому, что не смогла, как обычно, сразу сделать нормально. А, в конце концов, совсем открестилась от flex-а. Возможно, мы перекладываем с больной головы на здоровую, и во всем виновата прокрастинация разработчика. Но и она в основе своей вытекает, хоть и отчасти, из предыдущей проблемы. (Действительно ленивый программист сразу пишет рабочий, красивый и сопровождаемый код).

Не будем о грустном. Так как же можно отделить просо от гречки? Если хорошо поискать, то Adobe предлагает следующие варианты:

• использовать <fx:Script> блок. Собственно, от его использования мы и пытаемся избавиться;
• инлайн обработчики событий:

<s:Button label="Convert" 
click="celsius.text=String(Math.round((Number(fahrenheit.text)-32)/1.8 * 10)/10);"/>

• в отдельном as файле: <fx:Script source=”includes/Sample3Script.as”/>.

Много кода в инлайн обработчике не напишешь. Нельзя использовать операторы сравнения. Да и не похож этот вариант на разделение, скорее наоборот. Проходим мимо.

Описывание кода в отдельном as файле ни к чему, кроме головной боли, не ведет. Как минимум, код в пустом (безо всяких package, class и тд) файле выглядит странно, запутывает и приводит в уныние, наверное, все современные IDE. Кто-нибудь сейчас так пишет? Получается, название статьи расходится с её содержанием. Зачем она нужна непонятно (см. абзац “Почему так происходит”).

Вот мы все ругаем Adobe за Flex. Так ведь да, в один прекрасный момент она сама это поняла и переписала часть фреймворка, как надо. Ввела новый жизненный цикл компонентов и отделила логику/поведение компонентов от их внешнего вида и увеличила цифру у фреймворка аж до 4.00. Можно даже почитать, как правильно готовить такие компоненты. Переписать все компоненты сил не хватило, теперь этим занимается Apache Foundation.

Что же делать? И как быть? Наверное, многие уже поняли, к чему я клоню, и вспомнили о старом, добром CodeBehind-е.  Идея этого архитектурного паттерна проста: всю бизнес-логику пишем на чистом as3 (базовый класс), а расположение и внешний вид контролов, описываем, используя mxml-разметку. Все контролы, которые будут использоваться в коде, должны иметь id и быть описаны в базовом классе как публичные переменные с соответствующим типом. Звучит страшно, но на самом деле все просто. Рассмотрим пример:

// BaseControlPanel.as 
public class BaseControlPanel extends Group 
    { 
        public var stopButton : Button; 
        public var startButton: Button; 
        public function BaseControlPanel() 
        { 
            super(); 
        } 
 
 
        /** 
         * @inheritDoc 
         */ 
        override protected function createChildren():void 
        { 
            super.createChildren(); 
            stopButton.addEventListener(MouseEvent.CLICK, onStopButtonClicked); 
        } 
 
 
        /** 
         * Обработчик клика по кнопке старт 
         * @param e 
         */ 
        protected function onStartButtonClicked(e:MouseEvent):void 
        { 
            trace("Start"); 
        } 
 
 
        /** 
         * Обработчик клика по кнопке стоп 
         * @param e 
         */ 
        private function onStopButtonClicked(e:MouseEvent):void 
        { 
            trace("Stop"); 
        } 
    } 
 
// ControlPanelView.mxml 
<?xml version="1.0"?> 
<local:BaseControlPanel xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:local="*" xmlns:layouts="spark.layouts.*" 
                        xmlns:components="spark.components.*"> 
 
    <local:layout> 
        <layouts:HorizontalLayout paddingLeft="5" paddingTop="5"/> 
    </local:layout> 
 
    <!-- Кнопка запуска --> 
    <components:Button id="startButton" label="start" click="onStartButtonClicked(event)"/> 
 
    <!-- Кнопка остановки --> 
    <components:Button id="stopButton" label="stop"/> 
 
</local:BaseControlPanel>

В приведенном примере мы видим два варианта подписки на событие клика по кнопке. Стоп-кнопку мы подписываем на клик mxml файле. Для этого необходимо, чтобы обработчик события был виден, т.е. был либо protected либо public. Старт-кнопку мы подписываем в createChildren, сразу после того, как она создастся. Оба варианта приемлемы. Вариант с подпиской в разметке, как нам кажется, короче, но не так универсален. Если нам нужно будет создать еще один вариант разметки, нам придется еще раз подписывать кнопку на это событие, что избыточно и легко может привести к ошибке, если мы забудем это сделать. С другой стороны, если нам нужно подписаться на это событие не сразу, или подписать вообще другой компонент (который также может послать это событие), то сделать это без изменения as3 кода не получится. А так как именно эту проблему мы и решаем, то вариант с подпиской на событие в разметке в данном случае подходит лучше. Используем тот вариант, который решает нашу задачу лучше.

Таким образом, мы частично решили поставленные в начале статьи задачи, и даже получили некоторые другие преимущества:

• создание конструктора класса;
• возможность тестировать логику приложения отдельно от её представления;
• возможность наследоваться от базовой логики, без необходимости нести с собой mxml-мусор.

Но, как и у любого другого шаблона, у CodeBehind есть не только плюсы, но и минусы:

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

Другим вариантом реализации отделения логики от разметки является приём, называемый CodeFront (или code in front). Идея его (вы наверное и сами догадались) так же проста и кристальна, как и в случае с CodeBehind, и заключается в том, что сначала мы реализуем расположение компонентов, и только потом наполняем их жизнью (добавляем логику). Пример:

// BaseControlPanelView.mxml 
<?xml version="1.0"?> 
<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:local="*" xmlns:layouts="spark.layouts.*" 
         xmlns:components="spark.components.*" xmlns:s="library://ns.adobe.com/flex/spark"> 
    <!-- 
        /** 
         * Внешний вид панели управления 
         * Created 18.04.2014 
         * Version 1.0 
         * Copyright (c) 2014 
         * @author ChessMax (www.chessmax.ru) 
         */ 
    --> 
 
 
    <s:layout> 
        <layouts:HorizontalLayout paddingLeft="5" paddingTop="5"/> 
    </s:layout> 
 
 
    <!-- Кнопка запуска --> 
    <components:Button id="startButton" label="start"/> 
 
 
    <!-- Кнопка остановки --> 
    <components:Button id="stopButton" label="stop"/> 
 
 
</s:Group> 
// ControlPanel.as 
public class ControlPanel extends BaseControlPanelView 
    { 
        public function ControlPanel() 
        { 
            super(); 
        } 
 
 
        /** 
         * @inheritDoc 
         */ 
        override protected function createChildren():void 
        { 
            super.createChildren(); 
 
 
            startButton.addEventListener(MouseEvent.CLICK, onStartButtonClicked); 
            stopButton .addEventListener(MouseEvent.CLICK, onStopButtonClicked); 
        } 
 
 
        /** 
         * Обработчик клика по кнопке старт 
         * @param e 
         */ 
        protected function onStartButtonClicked(e:MouseEvent):void 
        { 
            trace("Start"); 
        } 
 
 
        /** 
         * Обработчик клика по кнопке стоп 
         * @param e 
         */ 
        private function onStopButtonClicked(e:MouseEvent):void 
        { 
            trace("Stop"); 
        } 
    }

Используя CodeFront, нам больше нет необходимости описывать все необходимые переменные в классе, чтобы использовать их в логике. Так как мы наследуемся от mxml-разметки, то компилятор делает это за нас. Но теперь мы лишены возможности назначить обработчик события inline-внутри mxml-разметки, так как описан он будет только в наследнике. Также нет возможности полностью заменить layout получившегося компонента, по понятным причинам. Да и перенести логику в другой проект без layout-а теперь не получится. Возможно, поэтому этот вариант гораздо менее популярен, чем CodeBehind.

Заключение.

CodeBehind/CodeFront - архитектурный прием, который позволяет относительно легко сделать код чистым и структуированным, что  легко дает возможность модифицировать его в будущем. Хотя поначалу довольно непросто привыкнуть писать код так, и это сильно раздражает. Даже кажется, что мы делаем слишком много дополнительной работы. Но, как говорится, стоит только начать, а уж когда втянетесь… Становится легче абстрагировать логику от разметки. Гораздо легче наследоваться от чистых AS3 классов, нежели от MXML классов с необходимостью изменять layout. Попробуйте один из перечисленных приемов в своем проекте. И обязательно оставляйте комментарии о своем положительном/отрицательном использовании перечисленных техник.

Почитать:

Code Behind
Code behind in Flex and WPF
Flex and WPF: A comparison – Part 2b
Code-Behind and Flex 2.0 (Partial Classes)
Building components by using code behind
Creating components and enforcing separation of concerns with Flex
Best Practice: Code Behind versus MXML Script Blocks versus View Helper

Для правильной работы со Spark компонентами и создания собственных компонентов, необходимо иметь понятие о том, как и по каким правилам они работают. Сегодня мы  рассмотрим базовые принципы, без знания которых невозможно эффективно использовать этот мощный фреймворк.

Итак, жизненный цикл каждого компонента во Flex фреймворке проходит следующие этапы:

• создание (construction);
• конфигурация (configuration);
• подключение/присоединение (attachment);
• инициализация (initialization);
• инвалидация (invalidation);
• взаимодействие (interaction);
• удаление (detachment);
• сборка мусора (garbage collection).

При наследовании компонентов разработчик может (должен) переопределять следующие методы:

• createChildren();
• commitProperties();
• measure();
• updateDisplayList().

Когда мы добавляем компонент с помощью mxml разметки

<local:MyComponent fontSize="12" width="100"/>

происходит следующее.

Сначала запускается этап создания, и инстанциируется экземпляр класса MyComponent. Затем происходит конфигурация, в течение которой компоненту выставляются свойства и стили, объявленные при добавлении компонента (применяются они позже). Пока внутри компонента не доступны свойства systemManager, stage, root и т.д. Но при этом могут вызываться get/set методы (конфигурация), поэтому при реализации необходимо правильно определять такие методы. Нельзя сразу применять изменения внутри метода, необходимо использовать валидацию.

private var _data:Object;
private var _dataChanged:Boolean;

private function set data(value:Object):void
{
    if (this._data !== value)
    {
        this._data = value;
        this._dataChanged = true;

        this.invalidateProperties();
    }
}

Теперь движемся дальше (до применений изменений мы дойдем чуть позже). Наступает этап подключения, в котором компонент добавляется на сцену, после чего происходит инициализация. Инициализацию рассмотрим подробнее.

Фазы инициализации:

• устанавливается значение свойства parent;
• событие «preinitialize»;
• создание дочерних компонентов createChildren() (для скинируемых компонентов это порождает вызов attachSkin(), про скины мы поговорим в следующий раз);
• событие «initialize», вызов метода инициализации initialize().

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

private var _okButton:Button;

override protected function createChildren():void
{
    if (this._okButton === null)
    {
        this._okButton = new Button();
        this._okButton.label = 'OK';
        this._okButton.addEventListener(MouseEvent.CLICK, this.okButton_clickHandler);
    }

    this.addChild(this._okButton);
    super.createChildren();
}

После того как компонент инициализирован, наступает этап инвалидации. Компоненты Flex фреймворка используют отложенную валидацию изменений. Аналогично как мы делали выше с полем data: изменения сохраняются и помечаются как измененные, а валидация происходи позже. Это позволяется сохранить высокую производительность, в том числе за счет того, что изменения применяются не по одному, а сразу все. Чтобы сообщить флексу о том, что требуется валидация, необходимо вызывать один из методов инвалидации:

• изменение свойств – invalidateProperties();
• изменение размеров – invalidateSize();
• изменение отображения – invalidateDisplayList().

Для применения изменения свойств будет вызван метод commitProperties(), именно его и надо переопределять в наследниках для применения изменения данных. Для определения необходимости обновления используются флаги (_dataChanged в примере с set data).

override function protected commitProperties():void
{
    super.commitProperties();

    if (this._dataChanged)
    {
        this._dataChanged = false;

        // Применение изменения поля this._data
    }
}

Отметим, что, так как валидация происходит после инициализации, то в методе commitProperties() уже доступны дочерние элементы, созданные в createChildren().

При валидации размеров будет вызван метод measure(), который устанавливает предпочтительные размеры (поля measuredWidth, measuredHeight, measuredMinWidth, measuredMinHeight). Замечу, что метод не будет вызван при установленных explicitWidth/explicitHeight (значения, присвоенные пользователем: <s:Label width="100"/>). Пример:

override protected function measure():void
{
    var i:uint;
    var count:uint;
    var w:Number;
    var h:Number;
    var child:UIComponent;

    w = 0;
    h = 0;
    count = this.numChildren;
    for (i = 0; i < count; ++i)
    {
        child = this.getChildAt(i) as UIComponent;
        if (child !== null)
        {
            w = Math.max(w, child.getExplicitOrMeasuredWidth());
            h += child.getExplicitOrMeasuredHeight();
        }
    }

    measuredWidth = w;
    measuredHeight = h;

    measuredMinWidth = w;
    measuredMinHeight = h;
}

Валидация размеров вызывает метод updateDisplayList(). При переоределении этого метода в наследниках здесь следует позиционировать и устанавливать размеры дочерних элементов. Также можно перерисовывать например фон. Актуальный размер компонента выставляется именно здесь. Вызов super.updateDisplayList() снова советую делать в конце переопределения.

По окончании инвалидации рассылается событие «creationComplete», после чего компонент находится в рабочем состоянии и доступен для взаимодействия с ним.

Когда компонент уже не нужен – он удаляется со сцены (методами удаления или выставлением флага visible=false). Если при этом больше не существует ссылки на объект или она слабая, то компонент будет удален из памяти сборщиком мусора. Обратите внимание, что ссылки на объект могут сохраняться при использовании обработчиков событий, биндига, сохранении в качестве ключей в словаре и т.д., поэтому не забывайте отписываться от событий, если больше не требуется его слушать.

Полезные ссылки

• Implementing the component http://livedocs.adobe.com/flex/3/html/help.html?content=ascomponents_advanced_3.html#210915
• About creating advanced components http://livedocs.adobe.com/flex/3/html/help.html?content=ascomponents_advanced_2.html
• About creating advanced Spark components http://help.adobe.com/en_US/flex/using/WS460ee381960520ad-2811830c121e9107ecb-7fff.html
• Презентация Павла Кожина «Жизненный цикл компонентов» http://www.slideshare.net/Constantiner/flex-component-lifecycle-overview
• Developing Flex 4 Components Book http://blog.flashgen.com/2010/12/07/developing-flex-components-book-2/

Квартал заканчивается. Погода радует непредсказуемостью, вечерами на горизонте светит яркая Венера, Луна и не  далёкий Юпитер... это как чудо, всегда считал что Венера появляется только рано утром перед восходом, она там была всегда, неужели сейчас нет. Вместо того чтоб открыть stellarium, добавлю задачу, "утром, до восхода попробовать отыскать её на горизонте". Для меня это событие не менее важное, чем остальные случившиеся в этом году : )

Аппаратно ускоренная графика - то, чего хотел последние лет так 5, прочно вошела в наши гаджеты всех размеров. И сейчас в разработке двух не игровых приложений, делаю ставку на наличие 3D-ускорителя у пользователя. В одном случае это приложения для Vk, там перекладываю работу с фотографиями на stage3D. Во втором это ios/android компас, простое бесплатное приложение, указывающие стороны по числу гуа и фен-шуй, тут на stage3D переносится часть интерфейса и сам компас. На устройствах без совместимого GPU оно не заработает, зато на остальных гладко/плавно/классно. Тема gui на stage3D, на мой взгляд - тема, пока не раскрытая. Хотел было использовать AlternativaGUI, но склонился к flash Ide компонентам, показалось кропотливо переправить тему на свой лад аля metro, т.е. без графики. Сегодня снова попробую выбрать между flex mxml и альтернативой. 

Попробовал Robolegs на Galaxy S в игровом приложении, тормозов не замечено. Сейчас всё пишу на них, реализация медиаторов очень понравилась. С февраля, вместе с друзьями создаём игровой проект, хотим к flashgamm успеть сделать просто круто. Не многим раньше альтернативы выложил сорсы на гитхаб, изначально рендер был на nd2d, сейчас их два, на альтернативе тоже. К слову очень понравилось как сделана альтернатива, сразу учат как делать правильно, сделать плохо - не просто , даже если были привычки - отучат. Привычки вообще это плохо.

Очередная попытка оседлать Realaxy AS Editor мне не удалась, сходу не завелись инжекты роболегсов. Тут наверное я чего-то не так настроил, показалось что RASE не гонялся ещё с кучей swc, вникать не стал, решил если научусь уверенно держаться в седле других JetBrains, то и тут буду успешен. Зато попробовал вникнуть в тему беты RASE 1.1 - компиляции AS3 кода в js-html5 , и тут не удалось, вроде не один я такой - кто хочет RASE, чтоб всё получилось и желает создателям вдохновений. 

Adobe в моих глазах делает сложно объяснимые вещи, понимать которые, возможно, лучше всего не умом. Вчерашнее заявление о поборах 9% с веб платформы... после того как они отключили поддержку веба на смартфонах и линуксах. Они или знают что webgl и js-html5 (которые есть/будут на мобилках), никогда не смогут догнать и стать конкурентами fp. Или всё плохо : )  А что если хорошо?  

Apache Flex вроде как обещается синтез js/fp , как я понял, существующие flex приложения заработают там где нет fp. Общем, что бы то не было, искать замену flash сегодня дело сомнительное, схоже как ставить flashbloсker в браузер - неразумно. Есть AdBlocker, который издавна, значительно лучше справлялся с задачей блокирования не только flash, а всей рекламы делая интернет чище. Несмотря на летящие камни, Adobe Flash продолжает "make love", и будет радовать классными штуками вроде http://www.incredibox.fr. 

Предполагаю, у adobe есть причины делать ещё пачку, вроде бы не нужных редакторов для HTML5 помимо Flash IDE, редакторы выполнены на AIR. Сейчас все силы развития Flash платформы перекинуты в AIR, повышение производительности и мобильные приложения, будущие flash это air. Nvidia ion - чипсет для процессоров intel atom, рекламировал себя так: "HD Videos on GPU-Accelerated Flash Player". Специально для fp на десктопе, Nvidia и ATI выпускают драйвера... а может и GPU. Теперь представим webkit скомпилированный под AIR )) и CUDA туда же. 

Так а что же если всё плохо? Отличный ответ на все случаи даёт Яков Файн в подкасте б.т. - "выучите то что знаете ещё лучше" будь то java, phyton, php, as или вышивание. Будьте  специалистом там, где вам нравится.  

В легендарных словах мастера Йоды, на мой взгляд не хватает одного слова, 

... Помни: сила рыцаря-джедая - это сила Вселенной. Но помни: гнев, страх, ненависть  – это всё ведет на тёмную сторону Силы. Как только ты сделаешь первый шаг по тёмному пути, ты уже не сможешь с него свернуть...

Выбор - личное дело каждого.

Пишет Адилет Абылов:

Недавно столкнулся с проблемой выбора архитектурного фреймворка для разработки под мобильные устройства на Adobe AIR. У меня довольно большой опыт использования Cairngorm, но терзают смутные сомнения в том, что Cairngorm - это хороший выбор для мобильных приложений, с учетом рекомендаций Adobe по экономии памяти и ресурсов процессора. Поиск в сети на эту тему не дал однозначного результата. Где-то читал, что Mate подходит для мобильных устройств, но Adobe рекомендует меньше использовать mxml, а Mate очень активно использует его. Возможно, мобильные приложения по определению не могут быть большими и сложными, поэтому использование фреймворком и не требуется.

Хотелось бы спросить мнения у более опытных коллег.

С уважением, Адилет Абылов

Спойлер. Это не просто. Это очень просто. - пишет Елена Геллер и продолжает:

На самом деле, Flash Builder – не единственный инструмент, с помощью которого можно комфортно изготавливать приложения для платформы Android. Это же самое могут и другие два популярных инструмента - FlashDevelop (далее по тексту - FD) и FDT. Учитываем, что  FlashDevelop бесплатен, а  FDT станет бесплатным, начиная с пятой версии (хотя и только в «упрощенном» варианте Free) – новость, особенно приятная для пользователей Mac и Linux.

В обоих инструментах главное — создать мобильный проект (Flex). В новом проекте у Вас уже готовы два mxml-файла — основной (в каталоге src) и первый вид (Home) в папке src/views. Ваши действия на самом деле аналогичны тем, которые требуются при работе в Flash Builder, ведь общую структуру и логику Flex 4.5 никто не отменял. 

Тестирование: F5 (FD), Run configurations (FDT).

Сертификат:  FDT — в папке проекта cert лежит образец сертификата, который для начала можно использовать.  FD – пользуемся .bat-файлом createCertificate.bat, который по умолчанию использует пароль fd.

Создаем .apk:  FDT — запускаем ant-скрипт (android_release_build.xml, либо, если необходимо, другой из папки ant), FD – запускаем соответствующий .bat-файл (подробнее можно прочитать в соответствующем readme-файле, также находящемся в проекте; отметим, что темплейты проекта для различных версий FD4 могут несколько отличаться, т. к. четвертая «ветка» популярного IDE хотя и рекомендуется для работы, но все еще не является релизом).

Собственно, все.

Читайте также предыдущую статью Елены - о разработке под iOS в среде OpenPlug.

Я помогаю Павлу изучать Flex и сегодня он попросил меня разобраться с одной странной ошибкой, которая возникла в его коде "непонятно откуда". Ошибка возникает во время выполнения и в сокращенном виде гласит такое:

VerifyError: Error #1019: Объект Getscopeobject 2 выходит за границы.

Официальная документация об этой и некоторых других ошибках ActionScript времени выполнения говорит, что они возникают в случае повреждения SWF-файла. Или в случаях сбоя работы компилятора, о чем надо сообщать в Adobe. То есть компилятор может создать неправильный файл, который не может быть корректно выполнен, но ошибки компиляции при этом мы не получим - только ошибку времени выполнения.

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

Получается, что ошибка -- где-то в исходном коде

Покопавшись немного, мы нашли проблему, из-за которой компилятор делал неправильный мед код. Павел предпринял попытку изобретения чего-то вроде геттера. Он смешал объявление переменной в классе с объявлением функции. Создал переменную типа Function и присвоил ей функцию. И это привело к созданию неправильного байткода.

Отбросив все несущественное, получим такой исходный код приложения, целиком воссоздающий данную проблему:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
			   xmlns:s="library://ns.adobe.com/flex/spark" 
			   xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600">
	
	<fx:Script>
		private var compilationDestroyer: Function = 
			function makeMyCompilerCrazy(): void
			{
			}			
	</fx:Script>
</s:Application>

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

читать далее

Евгений Потапенко таки оказался быстрее ребят из FDT и FlashDevelop и реализовал поддержку MXML в редакторе RASE (Realaxy ActionScript Editor) в разы быстрее, чем это сделали они. Вот скринкаст о том, как работать с MXML в редакторе RASE - Realaxy ActionScript Editor. Видео, как и редактор, пока в бете - так что пока без звука:

Выходит, что название редактора уже устарело, ведь вторая и третья буквы в аббревиатуре "RASE" обозначают "ActionScript" в названии "Realaxy ActionScript Editor". Теперь весь функционал редактора уже не помещается в его названии, так как MXML теперь тоже можно писать. Можно начинать думать над новым названием и новой аббревиатурой. Предлагаю название "Realaxy IDE" с аббревиатурой "RIDE!", что переводится как "Погнали!"

Лайк? Дизлайк? Предложите в комментариях свой вариант названия для этого редактора!

Сегодня разработчики UML редактора UML4AS выложили альфа версию в публичный доступ для скачивания.
Разработчики выделяют как основные особенности редактора:

• дружественный интерфейс разработчика/процесс разработки
• технология CodeSync для генерации кода, реверс-инжиниринг и устранение конфликтов
• поддержка ActionScript и MXML файлов
• поддержка рефакторинга
• поддержка командной работы

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

Я работал с веб-технологиями, начиная с ранних 90-х, и моей первой серверной технологией был язык PHP. Потом я работал с ColdFusion и Java, но всегда считал себя PHP-разработчиком. Когда пришел AJAX, я начал работать с фреймворками типа Prototype и script.aculo.us, и начал создавать собственные фреймворки.

В конце 2006 года я впервые попробовал разработку на Flex. Это было что-то вроде экспресс-курса, так как у меня было от 4 до 6 недель на создание демо-приложения для выходящей вскоре версии FDS (Flex Data Services, теперь называются LiveCycle Data Services). Хотя я был новичком во Flex и FDS, проект пошел хорошо, и я действительно насладился разработкой и процессом изучения.

Тем не менее, как бы приятно это ни было, это было нечто другое. Я имею в виду, что, когда я делал веб-приложения на ColdFusion или Java, я не ощущал большой разницы в сравнении с PHP; это было больше вопросом поиска правильных API и усвоения специфики языка. Позже, когда я начал работать с AJAX для DHTML, это тоже не так сильно отличалось. Большая часть сайта создавалась с помощью все тех же техник серверного языка, нужно было просто добавить специй тут и там (в данном случае – некоторых AJAX- виджетов).

Когда я сделал свой первый проект на Flex, о, мой мальчик, это было такое переключение! Четкое разделение между клиентом и сервером (бизнес-логика на стороне клиента в дополнение к бизнес-логике на стороне сервера), клиентская технология, которая компилировалась, а не интерпретировалась, два языка на клиенте, и все это требовало другой настройки ума, чем традиционная веб-разработка.

Это и есть моя причина для написания этой статьи. Я хочу поделиться с вами некоторыми из особенностей  Flex относительно PHP. Вместе с этим, я хочу представить Flex, сравнивая его с PHP там, где такое сравнение имеет смысл. Итак, эта статья предназначена для:

• PHP-разработчиков, которые хотят узнать о Flex и ActionScript 3 больше, чем может дать простое определение;
• PHP-разработчиков, которые уже сделали свои первые попытки кодирования Flex-приложений и хотят более широкого и глубокого понимания

Чего нет в этой статье? Мое намерение не в том, чтобы превратить вас во флексеров, и не в том, чтобы убедить вас в превосходстве Flex над X или Y. Я твердо верю, что существуют различные типы проектов, и что они могут и должны быть реализованы с помощью различных инструментов. Когда производительность, максимальная отдача от инвестиций и удобство являются главными приоритетами, то нет такой вещи, как универсальный инструмент.

В то же время, эта статья не является полной документацией к Flex или ActionScript3. Существуют десятки книг, охватывающих эту тему сотнями страниц. Есть тысячи статей о Flex. Моя цель – дать вам достаточно информации по наиболее важным темам и там, где это имеет смысл, связать концепции Flex с  аналогичными понятиями из PHP. Чтобы статья была полезной, я структурировал ее и постарался не вдаваться слишком глубоко в детали. В конце я даю краткое введение в Adobe AIR и ссылки на дополнительные ресурсы, если вам нужна подробная информация по этим вопросам.

Для большинства примеров я выбрал Flex 3, на то есть пара причин. Во-первых, во время написания этой статьи Flex 4 все еще не вышел. Во-вторых, Flex 4 в основном является эволюцией Flex 3, так что большая часть описываемых вещей может быть применена к Flex 4 с минимальными изменениями, если они вообще понадобятся. В некоторых случаях я укажу на эти отличия. Что касается PHP, то я использую версию PHP 5.3. Теперь посмотрим содержание, а затем – погрузимся в материал!

1. Что такое Flex?
   1. Flex: два языка и один фреймворк, чтобы связать их
   2. Почему вам нужно знать про Flex
   3. От тонкого клиента к умному и богатому клиенту
2. Введение в язык MXML
   1. Смешивание MXML  ActionScript 3
   2. CSS-стили
   3. Изменение MXML-кода во время выполнения
3. Введение в язык ActionScript 3
   1. Разделение выражений
   2. Типы данных, переменные, константы
   3. Функции и анонимные функции (замыкания)
   4. OOП: классы и интерфейсы
   5. Область видимости переменной
   6. Массивы
   7. Пространства имен
   8. Работа с XML
   9. Динамический ActionScript
4. Flex асинхронен
5. Связывание данных, метаданные и отражение
6. Где мои данные, давайте их сюда!
7. Аутентификация пользователя во Flex- и PHP-проектах
8. Работа над проектами Flex и PHP
   1. Flex SDK
   2. Flex Builder / Flash Builder
   3. Отладка Flex-приложений
9. Что такое Adobe AIR?
10. Что будет с Flash дальше??
11. Куда направиться после всего этого

Что такое Flex?

Простейший ответ: Flex – это просто еще один способ создания Flash-приложений. Flex-приложение компилируется в SWF-файл, который проигрывается в браузере с помощью Flash Player. Но зачем нужен еще один способ создания Flash-приложений? Традиционно Flash-приложения создавались в среде разработки Flash. Если вы посмотрите на нее, то вы заметите, что она ориентирована в основном на дизайнеров. Там есть сцена, временная шкала, инструменты рисования и т.д.

При разработке приложений важную роль играет производительность, вам нужны компоненты, вы хотите максимально упростить разработку, использовать код повторно, и, не в последнюю очередь, вы хотите современную IDE – интегрированную среду разработки.

Так что пересмотренный ответ может быть таким: Flex – это фреймворк с открытым исходным кодом, помогающий разработчикам быстро создавать насыщенные интернет-приложения (RIA, Rich Internet Applications), работающие внутри Flash Player. Фреймворк к сегодняшнему дню хорошо отточен в сравнении со своим первоначальным состоянием в 2006 году, когда вышел Flex 2, Flash Player 9 и ActionScript 3.

[к началу]

Читать всю статью "Flex для PHP-разработчиков"

читать далее

Так случилось, что фильтрация коллекций ни разу не беспокоила меня. А тут коллега задал вопрос, который послужил толчком к тому, что вы сейчас прочитаете. =)

Коллеге необходимо показать во view отфильтрованную ArrayCollection. Сама ArrayCollection находится в модели. Когда во view применяется фильтр, то данные модели очень сильно выглядят измененными. Что делать? Как быть?

Конечно, мы с вами знаем, что данные на самом деле не меняются. source коллекции так и остается исходным. Но не работать же в модели с source?

Конечно, не работать! И уж конечно, не делать копии коллекций! Тут спасибо Константинеру за наводку. =)

Можно использовать ListCollectionView в качестве обертки нашей исходной коллекции уже на уровне view. Тогда довольная модель работает с ArrayCollection, как и прежде, а view показывает, что захочет.

В качестве примера использую пример из доков Adobe для фильтрации коллекций.
Пример такой:

XML:

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

Что же мы делаем? Тут и далее использован беглый стиль программирования, потому что все-таки пример. =)
Добавляем обертку для коллекции:

Code:

После создания приложения создаем эту нашу обертку:

Code:

Фильтруем уже эту обертку, ее же показываем во втором выпадающем списке.
Добавляем новый выпадающий список для нашей родной коллекции.

Вот как выглядит код после изменений:

XML:

В результате получаем фильтрацию исключительно на уровне view. А модель живет своей счастливой и долгой жизнью. =)

Этот же подход можно использовать и при необходимости показывать одну и ту же коллекцию в разных контролах с разными фильтрами.

Вступление.

Этот пост начал свое существование 7 месяцев назад. Именно тогда я решил взять на вооружение Mate Flex Framework. Но злостный непрекращающийся дидлайн никак не давал мне закончить статью. Год выдался трудным и на работе и дома (в конце ноября у нас родился 3й ребятёнок). Сейчас, на праздниках (Всех с Новым Годом и Рождеством!) появилась свободная минутка, чтобы оглянуться назад.

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

Забегая вперед, хочу с удовольствием отметить, что освоение прошло успешно и пол-десятка проектов были запущены на каркасе Mate.

Теоретическое знакомство с Mate

Наконец-то у меня появилось время копнуть Mate.
И начну я с того, чтобы удостовериться в правильности выбора.

• Мне, как Flex-разработчику, Mate в первую очередь интересен тем, что это фреймворк, базирующийся на Flex.
• Очень хочется меньше кодить, но иметь при этом наглядный и прозрачный код.
• Понятная документация, обучение и примеры. Теперь посмотрим, какие фреймворки сравнивают и что о них думают:
  - Здесь - presentation сравниваются Cairngorm, Mate и PureMVC. Забавно, что количество доводов "против" для Mate меньше чем для остальных.
  - Довольно объемная статья: FrameworkQuest 2008, а точнее, заключительная часть исследования фреймворков. Почти во всех качествах, Mate выигрывает.
• Последним аргументом будет личный опыт. Приступим к тестовому проекту.

Для начала посмотрим видео: Mate Helloworld. Впечатления позитивные. Всё довольно очевидно и изящно. Здесь рассказывают про Mate на примере работы с простейшим сервисом при использовании AMFPHP. Мне это дело так понравилось, что я решил немедленно себе поставить эту штуку - но об этом позже.

А пока - продолжаем изучать Mate. Читаем про Mate на Go!Verla Flex Blog:

• 5 копеек о Mate Flex Framework - хвалебная речь.
• Пример использования Mate Flex Framework - очень глубокая статья, которая дает много полезного, даже не только о Mate.
• Презентации Constantiner-а: "Mate framework", "Краткое введение в Mate Flex framework". Презентации хороши, но являются лишь подручным материалом докладчика. Без самого докладчика многое понять сложно.
• "Строим приложение на Mate framework + Zend_AMF".

Вступление.

Этот пост начал свое существование 7 месяцев назад. Именно тогда я решил взять на вооружение Mate Flex Framework. Но злостный непрекращающийся дидлайн никак не давал мне закончить статью. Год выдался трудным и на работе и дома (в конце ноября у нас родился 3й ребятёнок). Сейчас, на праздниках (Всех с Новым Годом и Рождеством!) появилась свободная минутка, чтобы оглянуться назад.

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

Забегая вперед, хочу с удовольствием отметить, что освоение прошло успешно и пол-десятка проектов были запущены на каркасе Mate.

Теоретическое знакомство с Mate

Наконец-то у меня появилось время копнуть Mate.
И начну я с того, чтобы удостовериться в правильности выбора.

• Мне, как Flex-разработчику, Mate в первую очередь интересен тем, что это фреймворк, базирующийся на Flex.
• Очень хочется меньше кодить, но иметь при этом наглядный и прозрачный код.
• Понятная документация, обучение и примеры. Теперь посмотрим, какие фреймворки сравнивают и что о них думают:
  - Здесь - presentation сравниваются Cairngorm, Mate и PureMVC. Забавно, что количество доводов "против" для Mate меньше чем для остальных.
  - Довольно объемная статья: FrameworkQuest 2008, а точнее, заключительная часть исследования фреймворков. Почти во всех качествах, Mate выигрывает.
• Последним аргументом будет личный опыт. Приступим к тестовому проекту.

Для начала посмотрим видео: Mate Helloworld. Впечатления позитивные. Всё довольно очевидно и изящно. Здесь рассказывают про Mate на примере работы с простейшим сервисом при использовании AMFPHP. Мне это дело так понравилось, что я решил немедленно себе поставить эту штуку - но об этом позже.

А пока - продолжаем изучать Mate. Читаем про Mate на Go!Verla Flex Blog:

• 5 копеек о Mate Flex Framework - хвалебная речь.
• Пример использования Mate Flex Framework - очень глубокая статья, которая дает много полезного, даже не только о Mate.
• Презентации Constantiner-а: "Mate framework", "Краткое введение в Mate Flex framework". Презентации хороши, но являются лишь подручным материалом докладчика. Без самого докладчика многое понять сложно.
• "Строим приложение на Mate framework + Zend_AMF".

Столкнулся с проблемой запуска добавленных, не созданных в этом же билдере, mxml application файлов в проект.

решение описал в Flex Cookbook

Столкнулся с проблемой запуска добавленных, не созданных в этом же билдере, mxml application файлов в проект.

решение описал в Flex Cookbook

Во Львове мы имели пиковые по плотности флекс-доклады. Первый, "Практики большого флекс-проекта" от Андрея Табачина из EPAM Systems, занял 2,5 часа, как мы и рассчитывали. Вообще, эта конфа отличилась точностью: почти 100% явка регистрантов, пунктуальность всех участников и докладчиков. Было много, трудно и интересно. Во втором докладе, "Создание Spark-компонентов" от Андрея Процика из EPAM, стало ясно, как Code Behind мутировал во Flex 4: было наследование, а стала композиция MXML-класса скина и AS3 класса логики. Так что теперь к нему будет меньше претензий в духе "родитель обращается к свойствам ребенка, это же антипаттерн". Два этих основных доклада перемежались двумя "разгрузочными": "Управление рисками для разработчика" от Олега Керницкого (экспромт) и "Что я узнал от моей новой флекс-команды", который сделал я.

На афтепати в клубе "Культ" свершился сакральный контакт челябинских флексеров (1 чел) с флексерами из Ивано-Франковска (5 чел). Было точно установлено, что и уральские, и западно-украинские флексеры имеют дружелюбное человеческое обличье и темы для обсуждения. Всего я не слышал, но видел интерес. Люди из Ивано-Франковска показались мне еще немного более сдержанными, чем львовяне. Но если с ними заговорить, то за сдержаностью видна природная энергия. Карпаты...

По результатам Львовской встречи в тамбуре поезда "Львов-Киев" состоялся беспрецедентный, самый жаркий и длительный на моей памяти холивор на тему "Код бихайнд, нужен ли он". Для себя я понял, что точного определения код бихайнда не знает никто. Основная ошибка отрицающих код бихайнд в том, что они ищут в нем сакральный смысл (или Истину?), терпят естественную неудачу и потом обвиняют в ней кодбихайнд. В то время как всесь смысл кодбихайнда выражен в его названии, и видов его может быть множество. Незамороченные кодбихайндеры обычно довольны его предсказуемым поведением. И на этом все. Холивор длился часа 3. Традиционно похоливорили на тему "Синглтон, ты — Зло", осудили злоупотребление, неофитство, профанацию и деградацию образования программистов. Расходились спать довольные, впереди был Киев.

Такого флекса мы еще не докладывали, холивора такого — не холиворили. Спасибо тебе, Львов! И EPAM Systems — спасибо. Отдельное. Именно всего такого сурового и хотелось, и мы сделали это, йоу!

В Киеве, сойдя с поезда и позавтракав, мы отправились на конфу, где успели на завершение презентации разработчиков "Счастливого фермера". Затем Виталий Хить сделал доклад "Минимальные UI-компоненты" (как частное лицо) и сразу после него — "Как реально срубить бабла на социальных играх" (названия докладов привожу по мутирующей памяти, простите). И вот: снова Хить порубил нас на части живыми спичами с анализом факторов и рисков. Затем был доклад о поисках путей в лабиринтах от Владимира Кожаева. Потом Хитрый в очередной раз сразил нас мастерклассом, это была техника создания игры-платформера. Вот уж кто настоящий флэшер — так это Хитрый. Такого адекватного подхода к существующим инструментам хочется желать всем. Полный фэншуй. Удивительная харизма. Спасибо тебе, Денис.

Мы кулуарно обсудили PureMVC и немного Mate. В ходе обсуждения я понял, что часто задаваемый вопрос "где применять PureMVC" некорректен. Не "где", а "кому" применять PureMVC — вот что важнее! Почему: фреймворк PureMVC очень акцентирован идеологически. Его создатель — академик ООП, и это видно по самому фреймворку и документации к нему, даже по названию. Отсюда вывод: PureMVC рекомендуется адептам акдемического подхода. Поклонникам нордического, строгого и безжалостного к слабостям индивидуальных разработчиков ООП. Перфекционистам, которые хотят не только делать проект, но и превращать его в Памятник Программной Архитектуры для Восхищения и Поклонения ценителями и знатоками. Уверен, что лучшие результаты PureMVC даст именно в руках таких людей, которые способны его расширять конкретно для своего проекта, например, типизировав Оповещения. Избавившись от всего нетипизированного и соорудив Идеальный ООП- Аппарат для Этого Конкретного Проекта. Короче говоря: осмысленное превращение абстрактного PutreMVC в конкретное MyPureMVC даст адептам ООП лучший результат и наслаждение. Остальным даст головную боль. И больше тут не о чем спорить.

В этом идеологическая противоположность PureMVC с Mate: теплым, немного разболтанным таким фреймворчиком, в котором нетипизированность неустранима в принципе, и в том нет нужды. Это фреймворки, созданные противоположными человеческими психотипами, и это нужно учитывать при выборе. Нужно понимать, что когда в самом начале презентации Mate у Лоры Аргуэльо зависает презентуемое приложение, то она говорит "упс" и не вырезает єто из видео, так оно и идет в историю и на сайт Adobe. А ее напарник Нахуэль пишет прямо в конструкторе: "знаю, что здесь у меня полная лажа, но ничего лучше не смог родить, если знаете, пишите на почту". Легкость в отношении к жизни — это Mate.

Еще один вывод по фреймворкам: они даны нам, чтобы опробовать заложенные в них концепции и практики, увидеть недостатки, взять из них лучшее и потом решать, что делать дальше. Использовать или нет. Только практика, личные ошибки и анализ результатов дают настоящее понимание, меньше теорий — к делу!

В самом конце молодой отец, поздравляем! и изобретатель Олег Галабурда представил свои необычные разработки и творения, от мультибайтового упаковщика данных до караоке-системы. Темы были интересные, но чувствовалась подусталость: пятый доклад, несколько частей! На том и покончили с официальной частью. Мне показалось, что в Киеве было намного меньше людей, чем зарегистрировалось (56). Зря не пришли. Кстати, а во Львове секьюрити сегодня сообщило мне, что в воскресенье (25 числа) приходили какие-то люди на конфу во Львове. Странно, ведь везде было написано, что конфа — 25 октября. Кто были эти люди? Отпишитесь, пожалуйста.

На афтепати в Киеве мы видели Белую и она теперь пушиста. Также она набрала воды из Майдана, это такой фонтан в центре Киева. Также был частично развиртуализирован Makc3D, что вызвало живую реакцию сразу нескольких членов нашего движения. В частности, был развязан кармический вопрос экстрагирования звука в AS3 — Татьяна и Макс наконец увидели друг друга и тут же доразрулили ситуацию на красной салфетке. Мы много и часто фотографировали себя и тут же рассматривали фото, пораженные! Была минута, когда вспышки четырех камер создавали эффект стробоскопа.

В Киеве я понял, что люблю его просторы и стремительную ясность архитектурных линий. Вернувшись во Львов я вспомнил, как люблю его органическую природу, пятиугольные и треугольные комнаты, и артефакты в непрямых углах.

Организационные выводы, идеи по UAFPUG:

1. Во Львове будет еще больше Флекс-конференций.
2. Следующий, ноябрьский UAFPUG будет в г. Днепропетровск.
3. Появилась идея проведения зимнего ITSki в Карпатах: неделю живем в домике, делаем доклады, жжем камины, обсуждаем, катаемся на лыжах, получаем удовольствие. Точим лыжи!

Это не отчет, а мои впечатления по горячим следам. Дополняйте или поправляйте в комменатариях

Во Львове мы имели пиковые по плотности флекс-доклады. Первый, "Практики большого флекс-проекта" от Андрея Табачина из EPAM Systems, занял 2,5 часа, как мы и рассчитывали. Вообще, эта конфа отличилась точностью: почти 100% явка регистрантов, пунктуальность всех участников и докладчиков. Было много, трудно и интересно. Во втором докладе, "Создание Spark-компонентов" от Андрея Процика из EPAM, стало ясно, как Code Behind мутировал во Flex 4: было наследование, а стала композиция MXML-класса скина и AS3 класса логики. Так что теперь к нему будет меньше претензий в духе "родитель обращается к свойствам ребенка, это же антипаттерн". Два этих основных доклада перемежались двумя "разгрузочными": "Управление рисками для разработчика" от Олега Керницкого (экспромт) и "Что я узнал от моей новой флекс-команды", который сделал я.

На афтепати в клубе "Культ" свершился сакральный контакт челябинских флексеров (1 чел) с флексерами из Ивано-Франковска (5 чел). Было точно установлено, что и уральские, и западно-украинские флексеры имеют дружелюбное человеческое обличье и темы для обсуждения. Всего я не слышал, но видел интерес. Люди из Ивано-Франковска показались мне еще немного более сдержанными, чем львовяне. Но если с ними заговорить, то за сдержаностью видна природная энергия. Карпаты...

По результатам Львовской встречи в тамбуре поезда "Львов-Киев" состоялся беспрецедентный, самый жаркий и длительный на моей памяти холивор на тему "Код бихайнд, нужен ли он". Для себя я понял, что точного определения код бихайнда не знает никто. Основная ошибка отрицающих код бихайнд в том, что они ищут в нем сакральный смысл (или Истину?), терпят естественную неудачу и потом обвиняют в ней кодбихайнд. В то время как всесь смысл кодбихайнда выражен в его названии, и видов его может быть множество. Незамороченные кодбихайндеры обычно довольны его предсказуемым поведением. И на этом все. Холивор длился часа 3. Традиционно похоливорили на тему "Синглтон, ты — Зло", осудили злоупотребление, неофитство, профанацию и деградацию образования программистов. Расходились спать довольные, впереди был Киев.

Такого флекса мы еще не докладывали, холивора такого — не холиворили. Спасибо тебе, Львов! И EPAM Systems — спасибо. Отдельное. Именно всего такого сурового и хотелось, и мы сделали это, йоу!

В Киеве, сойдя с поезда и позавтракав, мы отправились на конфу, где успели на завершение презентации разработчиков "Счастливого фермера". Затем Виталий Хить сделал доклад "Минимальные UI-компоненты" (как частное лицо) и сразу после него — "Как реально срубить бабла на социальных играх" (названия докладов привожу по мутирующей памяти, простите). И вот: снова Хить порубил нас на части живыми спичами с анализом факторов и рисков. Затем был доклад о поисках путей в лабиринтах от Владимира Кожаева. Потом Хитрый в очередной раз сразил нас мастерклассом, это была техника создания игры-платформера. Вот уж кто настоящий флэшер — так это Хитрый. Такого адекватного подхода к существующим инструментам хочется желать всем. Полный фэншуй. Удивительная харизма. Спасибо тебе, Денис.

Мы кулуарно обсудили PureMVC и немного Mate. В ходе обсуждения я понял, что часто задаваемый вопрос "где применять PureMVC" некорректен. Не "где", а "кому" применять PureMVC — вот что важнее! Почему: фреймворк PureMVC очень акцентирован идеологически. Его создатель — академик ООП, и это видно по самому фреймворку и документации к нему, даже по названию. Отсюда вывод: PureMVC рекомендуется адептам акдемического подхода. Поклонникам нордического, строгого и безжалостного к слабостям индивидуальных разработчиков ООП. Перфекционистам, которые хотят не только делать проект, но и превращать его в Памятник Программной Архитектуры для Восхищения и Поклонения ценителями и знатоками. Уверен, что лучшие результаты PureMVC даст именно в руках таких людей, которые способны его расширять конкретно для своего проекта, например, типизировав Оповещения. Избавившись от всего нетипизированного и соорудив Идеальный ООП- Аппарат для Этого Конкретного Проекта. Короче говоря: осмысленное превращение абстрактного PutreMVC в конкретное MyPureMVC даст адептам ООП лучший результат и наслаждение. Остальным даст головную боль. И больше тут не о чем спорить.

В этом идеологическая противоположность PureMVC с Mate: теплым, немного разболтанным таким фреймворчиком, в котором нетипизированность неустранима в принципе, и в том нет нужды. Это фреймворки, созданные противоположными человеческими психотипами, и это нужно учитывать при выборе. Нужно понимать, что когда в самом начале презентации Mate у Лоры Аргуэльо зависает презентуемое приложение, то она говорит "упс" и не вырезает єто из видео, так оно и идет в историю и на сайт Adobe. А ее напарник Нахуэль пишет прямо в конструкторе: "знаю, что здесь у меня полная лажа, но ничего лучше не смог родить, если знаете, пишите на почту". Легкость в отношении к жизни — это Mate.

Еще один вывод по фреймворкам: они даны нам, чтобы опробовать заложенные в них концепции и практики, увидеть недостатки, взять из них лучшее и потом решать, что делать дальше. Использовать или нет. Только практика, личные ошибки и анализ результатов дают настоящее понимание, меньше теорий — к делу!

В самом конце молодой отец, поздравляем! и изобретатель Олег Галабурда представил свои необычные разработки и творения, от мультибайтового упаковщика данных до караоке-системы. Темы были интересные, но чувствовалась подусталость: пятый доклад, несколько частей! На том и покончили с официальной частью. Мне показалось, что в Киеве было намного меньше людей, чем зарегистрировалось (56). Зря не пришли. Кстати, а во Львове секьюрити сегодня сообщило мне, что в воскресенье (25 числа) приходили какие-то люди на конфу во Львове. Странно, ведь везде было написано, что конфа — 25 октября. Кто были эти люди? Отпишитесь, пожалуйста.

На афтепати в Киеве мы видели Белую и она теперь пушиста. Также она набрала воды из Майдана, это такой фонтан в центре Киева. Также был частично развиртуализирован Makc3D, что вызвало живую реакцию сразу нескольких членов нашего движения. В частности, был развязан кармический вопрос экстрагирования звука в AS3 — Татьяна и Макс наконец увидели друг друга и тут же доразрулили ситуацию на красной салфетке. Мы много и часто фотографировали себя и тут же рассматривали фото, пораженные! Была минута, когда вспышки четырех камер создавали эффект стробоскопа.

В Киеве я понял, что люблю его просторы и стремительную ясность архитектурных линий. Вернувшись во Львов я вспомнил, как люблю его органическую природу, пятиугольные и треугольные комнаты, и артефакты в непрямых углах.

Организационные выводы, идеи по UAFPUG:

1. Во Львове будет еще больше Флекс-конференций.
2. Следующий, ноябрьский UAFPUG будет в г. Днепропетровск.
3. Появилась идея проведения зимнего ITSki в Карпатах: неделю живем в домике, делаем доклады, жжем камины, обсуждаем, катаемся на лыжах, получаем удовольствие. Точим лыжи!

Это не отчет, а мои впечатления по горячим следам. Дополняйте или поправляйте в комменатариях

На днях пришла необходимость попробовать перенести библиотеки с flex sdk 3.2 на flex sdk 4.  Заодно повтыкать в Flash Builder 4 и различные радости которые нам принес Gumbo.

Все было хорошо и ничто не предвещало беды ). После создания проекта компилятор сразу начал ругаться. “Почему бы и нет” - подумал я, ведь различия в сдк большие. Начал выяснять почему.

Первым сюрпризом было то, что он ругался на mxml класс, который обращался к AS классу лежащему в том же пакете. “Едить колотить, какая та лажа” - подумал я. И волевым движением руки добавил в mxml импорт,  этого нужного класса.

Потом выяснилось, что такая же проблема еще с несколькими mxml.  Ругая индусов я добавил импорт и в остальные классы. Вылез следующий такой же проблемный AS класс. Вставка импорта не помогла — данный класс бы internal. Скрипя душей и наплевав на хорошие манеры сделал класс public. Вылез следующий баг, mxml наследованный от mxml. И тут полностью приплыли, если навигатор нормально видет класс, нормально входит в него, то компилятор ругается.

Начал выдумывать почему такое происходит. Вариантов у меня было три:

1. “Старый код”, В качестве базовых mxml классов используется mx:Canvas.
2. Проблемы с неймспейсами.
3. Я что то пропустил в этой жизни и изменился порядок создания библиотек.

Покапал в сторон “старых классов”, ничего! Нет никаких упоминаний о том что с ними, что-то нитак, поклацал галочки типа “Use Flex 3 compability”. Никаких результатов.

Поискал доки про изменения неймспейсов, плохого ничего не написано, никаких сложностей.

Библиотеки создаются стандартным образом, никаких шаманст ненужно.

Сделал тестовую библиотеку, неработает. Попробовал mxml без наследования, работает но меня это не спасает, использование классов в том же пакете без импорта не работает.

Поспрашивал у народа в чате UAFPUG. Никто ничего незнает. Дима попробывал несколько предложить несколько способов (пол мороженного лежит на полочке, ждет ).  Но они не повторяли мою проблему и не особо помогли. Затем Дима прислал пример с кукбук как создавать компоненты со своим неймспейсом. Повторил все операции описаные в статье, не работает! Ругается, что не может найти мой класс в моем неймспейсе. Почувствовал себя полным дебилом.

Одновременно со мной этой же проблемой занималась Татьяна Белоусова из команды Flexis. Она сказала, что если поставить опцию компилятора

то mxml классы генерятся и пачкой вываливаються в корень каталога generated, а имена пакетов пустые т.е. реально все mxml классы лежат в корневом пакете. после этого у меня осталось лишь 2 мысли, или я всетаки что то неправильно готовлю или это буг.

На bugs.adobe.com ничего похожего найти не смог (кошмар как сайт тормозит). Вернулся к варианту с неправильной готовкой.

Стянул проект с кукбука, запустил, все работает. Повторил снова все действия из кукбука, неработает. Проверил все настройки компилятора, неймспейсов — все совпадает, но не комплится. Копипастом перенес все в свой проект — неработает! К этому моменту я исчерпал практически весь запас ругательств. Попробовал убрать все описания кастомных неймспейсов, в настройке компилятора, библиотека с AS классом собралась. Добавил MXML — собралась, добавил наследника, естественно не собралась :).

Начал сравнивать вообще все галочки в примере и в моем проекте. Все одинакого. Перенес свои MXML в проект из кукбука, либа собралась, ни на что не ругалась, но и мои mxml не включила в проект. Полез в настройки библиотеки, пункт “Flex Library Build Path”, таб “Classes”, естетсвенно вновь появившиеся классы небыли включены в библиотеку, поставил галочки напротив них — либа нормально собралась, все классы сгенеренные из mxml разложились по нужным папочкам, package были розданы правильно. В этот момент, я почувствовал себя полным неудачником, ламером, человеком с погнутой кармой. Добавил еще несколько файлов, все отлично собирается и компилится. Затем еще пару, и тут мне надоело выставлять галочки напротив моих вновь созданых классов. И я подумал, какие клевые индусы, сделали такую офигенно-удобно-полезную переключалку “Include all classes from all sources path” (я еще в старых проектах не раз попадался когда вновь созданые классы не включались в либу) и я поспешил воспользоваться ей.

Всё. Всё перестало работать и вернулось на круги своя! Убрал галочку, все работает.
Убрал галочку протестил все мои нерабочие варианты, с наследованием mxml, с кастомными неймспейсами, с импортом. Всё работает.

Люди, вы понимаете, что это полная ЖОПА? Это полный маразм! Из-за левой, выставляемой по умолчанию, кажущейся мега удобной галочкой, которую не один здраво-ленивый человек не захочет просто так снимать (а если снимет, то только при важных обстоятельствах), я протрахался 2 дня! Я исчерпал все свои ругательства, заговоры, шаманства, волшебные слова и веру в людей. Если бы не пример. И если не случай(! просто неочевидное стечение обстоятельств), то я бы вообще ничего не собрал.

Не используйте пока эту опцию! Никогда, забудьте про нее или дождитесь релиза )

Когда давно я писала о вариантах передачи версии в приложение. Там упоминалось возможное использования для этого сonditional compilation, но тогда еще Flex 3 не вышел.

Сейчас уже давным давно вышел Flex 3 и даже 4 не за горами.

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

Передать константы в приложение можно, используя опцию компилятора compiler.define. Константы могут быть типов Boolean, String, Number или выражения, которые могут быть преобразованы в ActionScript в процессе компиляции. Далее эти константы доступны в приложении как глобальные.

Используя опцию define, необходимо для константы определить: namespace, имя и значение:

-define=namespace::variable_name,value

Пример:

-define=VERSION::description,'3.15.6'

Доступ из приложения доступен пока только из as-классов. В скором будущем, возможно будет работать и доступ из mxml-классов. Говорят, что в mxml-классах можно использовать только Boolean. Но зачем нам? Мы же код в mxml не пишем.
Пример доступа:

public static const VERSION_DESCR:String = VERSION::description;

Подробнее про использование conditional compilation в доках.

Bookmark this article at …

Наглядные официальные статьи по Code Behind во Flex уже есть, включая статьи о Code Behind на русском и украинском, рекомендующие этот подход новичкам во Flex. Напишем о нем еще раз, так как мы о нем толком еще не писали. Это упущение, ведь Code Behind относится к лучшим практикам!

"Code Behind" означает, что код находится за чем-то. А зачем это нужно?

Code Behind помогает стройно разделить код приложения по задачам. Код, в котором задается дизайн находится в одном классе, а код с собственно логикой работы — в другом, том самом, который "Behind".

Во Flex это выражается в том, что Actionscript находится за кодом MXML. Один из возможных (и хорошо работающих, проверенных подходов) к Code Behind реализуется с помощью т.н. Base-классов. Начнем с главного приложения проекта:

1. Для приложения создается базовый Actionscript-класс, в простейшем случае расширяющий родной флексовый класс Application:

package core
{
    public class ApplicationBase extends Application
    {
        ...
    }
}

2. Этот класс затем и используется как базовый в коде MXML-класса самого приложения:

<?xml version="1.0" encoding="utf-8"?>
<core:ApplicationBase ... >
     ...
</core:ApplicationBase>

Что мы получили: есть Actionscript-класс ApplicationBase, в котором мы контролируем MXML-приложение. То же самое мы делаем и для всех остальных MXML-компонентов нашего проекта: создаются AS-классы с именами, соответствующими шаблону ComponentNameBase, а MXML-компоненты используют эти классы как базовые — точно так же, как было показано выше для кода Application.

В таком подходе использование тэга Script в MXML-коде сводится к нулю и является, говоря упрощенно, уже плохой практикой.

Таким образом достигается четкое разделение вычислительной логики и дизайна приложения. Логика идет в Actionscript, дизайн — остается в MXML-коде.

Удивительно: для того, чтобы перехватить все события в интерфейсе Flex-приложения, нужно написать всего одну строку кода, и она весьма проста:

UIComponent.mx_internal::dispatchEventHook = myEventsHook;

Здесь myEventsHook — это метод вашего приложения, перехватывающий события. Он принимает два аргумента: само событие и объект, это событие породивший, так что в самом методе вы можете легко фильтровать информацию.

Еще удивительнее то, как мало об этой простой технике написано в сети. Гугл в основном находит применение к Cairngorm (снова это имя!), короткую запись на японском и занятный пост о задании поведения флекс-компонентов по умолчанию.

Обратите внимание, речь идет не обо всех событиях флекса, но именно о событиях визуальных компонентов, а точнее — всех компонентов, унаследованнх от класса UIComponent.

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

Например, посмотрим, что происходит при перемещении компонента Text из одной панели в другую:

# Move text field: 
	TextArea event: remove
Panel 1 event: childRemove
Panel 1 event: childrenChanged
Panel 2 event: childrenChanged
Panel 2 event: childAdd
	TextArea event: add
	TextArea event: htmlTextChanged
	TextArea event: textChanged
	TextArea event: valueCommit
	TextArea event: viewChanged
	TextArea event: viewChanged
Panel 1 event: widthChanged
Panel 1 event: heightChanged
Panel 1 event: resize
Panel 2 event: widthChanged
Panel 2 event: heightChanged
Panel 2 event: resize
Panel 1 event: xChanged
Panel 1 event: move
Panel 2 event: xChanged
Panel 2 event: yChanged
Panel 2 event: move
	TextArea event: updateComplete
Panel 1 event: updateComplete
Panel 2 event: updateComplete

Код, который выдает этот лог после нажатия кнопки "Move text":

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
				preinitialize="preinitializeHandler();"	>
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			
			private function preinitializeHandler():void
			{
				trace("Hooking UIComponent's event dispatcher"); 
				UIComponent.mx_internal::dispatchEventHook = myEventsHook;
			}
			
			private function myEventsHook(event:Event, uiComponent:Object):void
			{
				if(uiComponent.name == "firstPanel")
				{
					trace("Panel 1 event: " + event.type );
				}
				
				if(uiComponent.name == "secondPanel")
				{
					trace("Panel 2 event: " + event.type );
				}
				
				if(uiComponent.name == "textArea")
				{
					trace("\tTextArea event: " + event.type );
				}
			}
			
			private function moveText():void
			{
				trace('##################\n# Move text field: ');
				secondPanel.addChild(textArea);
			}
		]]>
	</mx:Script>
	<mx:Panel id="firstPanel" >
		<mx:TextArea id="textArea" text="Hello world"/>
	</mx:Panel>
	<mx:Panel id="secondPanel" />
	<mx:Button label="Move text" click="moveText();" />
</mx:Application>

Наглядно и просто! А сколько бы пришлось лазить по исходникам Flex SDK, чтобы получить эту элегантную картину

Данная техника помогает оптимизировать код. Например, если задать панелям и текстовому полю из вышеприведенного кода явные размеры (width, height), то событий будет почти в два раза меньше — отпадают всякие ресайзы, ведь размеры указаны явно, и у вас есть еще один повод сделать выводы.

Удивительно: для того, чтобы перехватить все события в интерфейсе Flex-приложения, нужно написать всего одну строку кода, и она весьма проста:

UIComponent.mx_internal::dispatchEventHook = myEventsHook;

Здесь myEventsHook — это метод вашего приложения, перехватывающий события. Он принимает два аргумента: само событие и объект, это событие породивший, так что в самом методе вы можете легко фильтровать информацию.

Еще удивительнее то, как мало об этой простой технике написано в сети. Гугл в основном находит применение к Cairngorm (снова это имя!), короткую запись на японском и занятный пост о задании поведения флекс-компонентов по умолчанию.

Обратите внимание, речь идет не обо всех событиях флекса, но именно о событиях визуальных компонентов, а точнее — всех компонентов, унаследованнх от класса UIComponent.

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

Например, посмотрим, что происходит при перемещении компонента Text из одной панели в другую:

# Move text field: 
	TextArea event: remove
Panel 1 event: childRemove
Panel 1 event: childrenChanged
Panel 2 event: childrenChanged
Panel 2 event: childAdd
	TextArea event: add
	TextArea event: htmlTextChanged
	TextArea event: textChanged
	TextArea event: valueCommit
	TextArea event: viewChanged
	TextArea event: viewChanged
Panel 1 event: widthChanged
Panel 1 event: heightChanged
Panel 1 event: resize
Panel 2 event: widthChanged
Panel 2 event: heightChanged
Panel 2 event: resize
Panel 1 event: xChanged
Panel 1 event: move
Panel 2 event: xChanged
Panel 2 event: yChanged
Panel 2 event: move
	TextArea event: updateComplete
Panel 1 event: updateComplete
Panel 2 event: updateComplete

Код, который выдает этот лог после нажатия кнопки "Move text":

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
				preinitialize="preinitializeHandler();"	>
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			
			private function preinitializeHandler():void
			{
				trace("Hooking UIComponent's event dispatcher"); 
				UIComponent.mx_internal::dispatchEventHook = myEventsHook;
			}
			
			private function myEventsHook(event:Event, uiComponent:Object):void
			{
				if(uiComponent.name == "firstPanel")
				{
					trace("Panel 1 event: " + event.type );
				}
				
				if(uiComponent.name == "secondPanel")
				{
					trace("Panel 2 event: " + event.type );
				}
				
				if(uiComponent.name == "textArea")
				{
					trace("\tTextArea event: " + event.type );
				}
			}
			
			private function moveText():void
			{
				trace('##################\n# Move text field: ');
				secondPanel.addChild(textArea);
			}
		]]>
	</mx:Script>
	<mx:Panel id="firstPanel" >
		<mx:TextArea id="textArea" text="Hello world"/>
	</mx:Panel>
	<mx:Panel id="secondPanel" />
	<mx:Button label="Move text" click="moveText();" />
</mx:Application>

Наглядно и просто! А сколько бы пришлось лазить по исходникам Flex SDK, чтобы получить эту элегантную картину

Данная техника помогает оптимизировать код. Например, если задать панелям и текстовому полю из вышеприведенного кода явные размеры (width, height), то событий будет почти в два раза меньше — отпадают всякие ресайзы, ведь размеры указаны явно, и у вас есть еще один повод сделать выводы.

Организация кода в пакеты

Словарь

Рефакторинг - Класическая книга описывающая практики рефакторинга - http://www.ozon.ru/context/detail/id/1308678/
DSL - Domain-specific language

Введение

Пакеты это механизм для организации кода и разрешения конфликта уникальности наименования классов. Это техническое определение, но по какому принципу создавать наименования? Какими критериями руководствоваться? И зачем вообще об этом задумываться?
К сожелению этот вопрос слабо освещен в классической литературе. В данной статье я хочу поделиться своим опытом и некоторыми исследованиями по данному вопросу. Первая часть статьи это моя попытка выделить общие принципы. В частности много идей я подчеркнул из презентации Juergen Hoeller, http://www.infoq.com/presentations/code-organization-large-project. Вторая часть статьи - описание вымышненного flex проекта и пошаговое развитие его структуры на основе свормулированных принципов и моего личного опыта.

Общие принципы

Можно сформулировать следующие архитектурные принципы:

Избегать циклических зависимостей;
Избегать дублирования;
Формировать модули;
Стремиться создавать слабо связанные модули;
Выбирать модули на основе логической, концептуальной организации (домена)

Далее о каждом их них более подробно:

Избегать циклических зависимостей между пакетами

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

Избегать дублирования

Часто альтернативой циклической зависимости является дублирование кода. Но такой код уже плохо пахнет. Дублирование заграмождает код и затрудняет его модификацию. Попробуйте переосмыслить местоположение нового кода и не прятать его глобоко в иерархии.

Формировать модули

Модуль это концептуальная сущность содержащая один или несколько дочерних пакетов. Модуль определяет границы для используемых в нем пакетов.

Стремиться создавать слабо связанные модули

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

Выбирать модули на основе логической, концептуальной организации (домена)

Часто модули разделяют на основе типов, например:

или на основе уровней:

Данная организация имеет право на существование, но она искуственна, то есть не следует из природы вещей. На мой взгляд, лучшим решением является разбиение на основе домена предметной области. Такое разделение ортогонально разбиению на основе типов или слоев, и развивается более естественно и имеет прозрачные границы.

Зачем об этом заботиться?

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

Пример и несколько практических советов

В последнее время я часто встречаю в flex приложении структуру пакетов следуещего вида:
vo
view
model
control
commands
business
events
Такое разделение на пакеты пришло к нам из фреймворка Cairngorm, где, видимо его приминение оправдано. Но оно встречается и в приложениях, где Cairngorm не используется. Как показывает моя практика, такое разделение плохо развивается при разростании приложения, пакеты получаются сильно связанны и их практически невозможно использовать повторно в другом приложении.
Я использую разбиение по логике или функциональности. Попробую привести пример.

Рассмотрим приложение AdminPanel

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

Начальная структура

rootpackage = com.agakhov.examples.adminpanel
rootpackage.ApplicationView.mxml // определяется размещение всех компонентов приложения
rootpackage.MainDataModel.as // модель данных всего приложения
rootpackage.MainEventMap.xml // сущность из фреймворка mate, её можно заменить обычным классом контроллера
rootpackage.AdminApplucationEvent.as // событие уровня приложения, например ApplicationStart
defaultpackage.Main.xml //создает и инициализирует основные компоненты)

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

Login

Допустим, что первая по приоритету задача это аутентифика

У армянского радио часто спрашивают, что всё-таки лучше: FB или FDT?

В чём-то их возможности пересекаются, например, оба предоставляют минимальные средства рефакторинга (переименование), оба имеют функцию поиска референсов на поле или метод и т.д.
Однако у каждого есть и свои особенности, которые отстутствуют у конкурента. Например, у FDT есть замечательная фича Quick fix, зато у FB есть профайлер, дизайнер форм, да и вообще он лучше работает с MXML.

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

UPD:iceX подсказал ссылку на более подробную статью.

читать далее

Непрошло и пол года как я подготовил исходники и написал пост о моем докладе на UAFPUG, который был 28 февраля, этого года.

Мой доклад назывался
“Eclipse Monkey — безграничный функционал Flex Builder’а.” как можно догадаться был посвещен прикручиванию Monkey скриптов к Flex Builder’у

В начале небольшая призентация:

По ходу призентации я приводил примеры использования скриптов. В правом углу некоторый слайдов есть метка E> это означает, что вместе со слайдом был пример кода. Примеры скриптов лежать в архиве у меня или в проекте monkey-for-flex на гугл коде. Примеры простые и не очень :).

Непростой пример посвещен использованию модели кода Flex Builder в Monkey Eclipse. Пример лежит в файле create-interface.js Данный пример генерит методы и свойства которые объявлены в выбраном интерфейсе, используя модель кода Flex Builder. Чтобы получить код нужно выделить в коде имя интерфейса и нажать Alt+m и в консоле будет выведен код. Остаеться его только скопипастить. Данный пример не является эталоном работы с моделью кода Flex Builder, это лишь иллюстрация возможностей Eclipse Monkey.

Еще я хочу обратить ваше внимание на библиотечки, которые я написал для более удобной работы.
Эти библиотеки лежат в папке com/the33cows/monkeylib

flexutil.js
Содержит методы для работы с текстовыми редакторами, как обычными так и MXML и CSS редакторов Flex Builder (Получение редактора, добавление текста, перемещение курсора). Библиотека не доделана, но с базовыми вещами справляеться нормально. Приветствуется добавление своих методов и/или советов, критики

templateUtils.js
Служит для работы с темплитами кода. В файл нужно прописать путь к каталогу где будут храниться файлы с темплитами

this.templateRoot = "< YourPathToTemplates >/templates/";

использование до безобразия простое

include("com/the33cows/monkeylib/templateUtils.js");
...
var tmpl = getTemplate("public-method.tpl"); // загрузили темплит из файла
tmpl = tmpl.replace(/{comments}/g, coments); // заменяем переменные на значения

переменная tmpl содержит строку с кодом, дальше с можно поступать как угодно.

Если есть каки-то вопросы, задавайте. Если есть какие-то пожелания, делитесь) Удачи.

Мы ищем молодого и талантливого Flash/Flex - разработчика, для участия в игровом проекте нашей компании (разработка клиентской части online игры), которого на первое время устроят 80000р. в месяц.

Мы хотим от кандидата:
- наличие опыта работы с Action Script 3.0;
- знание Flex Framework ( скиновать стандартные компоненты, создавать свои Flex-based компоненты, очень хорошо понимать как работает DataBinding, знать про коллекции, понимать как компилируется mxml в ActionScript, знать про Flex Managers, уметь разбираться в коде Framework`а);
- опыт групповой разработки online игр будет плюсом.

Мы предлагаем:
-возможности финансового и карьерного роста (так как проект новый);
-интересную работу;
-молодой и дружный коллектив, с которым можно выполнять интересные
задачи;
-оформление по ТК;
-уютный офис, располагающийся рядом с м. Тимирязевская, Рижская, или платформа Останкино.

Если Вы хотите присоединиться к нашей команде, пожалуйста, напишите мне письмо на адрес tpalitsina@bdirect.ru!

Несмотря на то, что ActionScript 3.0 является строго типизированным языком, в системе типов имеются некоторые “дыры” (обусловленные наличием типа Function и отсутствием дженериков (кроме Vector во Flash Player 10)), которые, с одной стороны, повышают гибкость языка, но с другой - делают код менее читаемым. В проектах, где число классов составляет несколько сотен и выше, это начинает составлять определенную проблему, особенно в случае командной разработки.

В случае массивов стандарт документирования имеется официально:

var myArray:Array/*of String*/;

Эта форма также поддерживается FlashDevelop (при ее использовании получаем автокомплит для элементов массива, что удобно). Кроме того, для mxml во Flex имеется метатег ArrayElementType, однако в чистых AS3 проектах без использования mxml он все равно не работает.

Однако массивами дело далеко не исчерпывается: для комфортной работы с кодом требуется информация о типах для Responder-ов, коллекций, в некоторых случаях  - информации о точном контракте у Function и т. п. В соответствии с этим при написании кода я проставляю дополнительные типы комментариев, характеризующих типы данных.

1) Коллекции, Dictionary

var features:ArrayCollection/*<String>*/;

var settings:Dictionary/*<String,XML>*/;

Для случая коллекций использование of выглядит неоправданным, так как массив и коллекция являются различными сущностями. Описание же в стиле дженериков Java выглядит очевидно, а также логично, в свете появления Vector с использующим угловые скобки синтаксисом.

2) тип Function

var mouseDownHandler:Function/*MouseEvent->void*/;

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

3) Уточнение типа

override public function doSomething(arg1:Object/*(MyType)*/,arg2:int):void{…}

В некоторых случаях приходится использовать в контракте функции более общий тип, несмотря на то, что в любом случае передаются объекты совершенно определенного типа. Такая ситуация часто возникает, например, когда производится override методов библиотеки, не подлежащей/не поддающейся изменению. В этом случае дополнительный комментарий позволит разработчику быстрее ориентироваться в коде.

4) Responder-ы

var sqlResponder:Responder/*<SQLResult->void,SQLError->void>*/;

Прямое следствие пунктов 1-2. Подобное описание responder-а позволяет избежать использования типа Object для обработки результатов выполнения асинхронных задач, что делает код более четким и читаемым.

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

Работа с mxml и css редактором отличается от работы с обычным редактором который нам предоставляет Eclipse Monkey. Чтобы получить доступ к любому редактору я использую такой метод

loadBundle("com.adobe.flexbuilder.editors.common");
/**
 * @return current text editor or null
 * @see org.eclipse.ui.editors.text.TextEditor
 */
this.getCurrentTextEditor = function()
{
	var editor = window.getActivePage().getActiveEditor();
	if (editor)
	{
		if (editor.getClass().getName() == "com.adobe.flexbuilder.editors.mxml.MXMLEditor"
			|| editor.getClass().getName() == "com.adobe.flexbuilder.editors.css.CSSEditor")
		{
			editor = editor.getCodeEditor();
		}
		/*
		//TODO add others editors that
		else if (){}

		*/
	}
	return editor;
}

Данный метод отдает ссылку на инстанс класса наследованого от org.eclipse.ui.editors.text.TextEditor, вернее даже на инстанс, который реализует
org.eclipse.ui.editors.ITextEditor

дальше работаем обычными для эклипса методами:

this.TextSelection = Packages.org.eclipse.jface.text.TextSelection;

this.insertToCursor = function(editor, text, moveCursor)
{
	if (editor)
	{
		var documentProvider = editor.getDocumentProvider();
		var doc = documentProvider.getDocument(editor.getEditorInput());
		var offset = editor.getSelectionProvider().getSelection().getOffset();

		doc.replace(offset, 0,  text);

		if (moveCursor)
		{
			var selection = new TextSelection(doc, offset+text.length, 0);
			editor.getSelectionProvider().setSelection(selection);
		}
	}
}

Метод вставляет текст в позицию курсора и если выставлен флаг, перемещает курсор в конец вставленного текста.

Вчера вышла новая EAP-сборка Intellij IDEA 9805 с поддержкой пространств имен в MXML-разметке Flex 4 Gumbo. Если кто не в курсе, эти пространства имен появились после отказа от префикса Fx в именах компонентов Gumbo.

Редактирование пространств имен, о которых будет известно среде разработки, производится в настройках проекта (комбинация Ctrl+Alt+Shift+S) на вкладке Flex Compiller Settings. Однако добавлять в этот список стандартные пространства имен (http://ns.adobe.com/mxml/2009, library://ns.adobe.com/flex/spark, library://ns.adobe.com/flex/halo, http://www.adobe.com/2006/mxml и http://ns.adobe.com/fxg/2008) совсем необязательно — они подхватываются средой «на лету» из файла flex-config.xml.

Хочется пожелать разработчиками также побыстрее справиться с изменившимся синтаксисом стилевых блоков CSS.

Примечание: если вы используете самостоятельную сборку Flex 4 SDK и у вас не компилируется SWF-файл приложения, то это означает, что вам необходимо удалить файл IDEA_INSTALL_DIR\plugins\flex\lib\idea-fcsh-fix.jar.

Вчера вышла новая EAP-сборка Intellij IDEA 9805 с поддержкой пространств имен в MXML-разметке Flex 4 Gumbo. Если кто не в курсе, эти пространства имен появились после отказа от префикса Fx в именах компонентов Gumbo.

Редактирование пространств имен, о которых будет известно среде разработки, производится в настройках проекта (комбинация Ctrl+Alt+Shift+S) на вкладке Flex Compiller Settings. Однако добавлять в этот список стандартные пространства имен (http://ns.adobe.com/mxml/2009, library://ns.adobe.com/flex/spark, library://ns.adobe.com/flex/halo, http://www.adobe.com/2006/mxml и http://ns.adobe.com/fxg/2008) совсем необязательно — они подхватываются средой «на лету» из файла flex-config.xml.

Хочется пожелать разработчиками также побыстрее справиться с изменившимся синтаксисом стилевых блоков CSS.

Примечание: если вы используете самостоятельную сборку Flex 4 SDK и у вас не компилируется SWF-файл приложения, то это означает, что вам необходимо удалить файл IDEA_INSTALL_DIR\plugins\flex\lib\idea-fcsh-fix.jar. Более подробно об этой ошибке читайте в JetBrains JIRA.

Вчера вышла новая EAP-сборка Intellij IDEA 9805 с поддержкой пространств имен в MXML-разметке Flex 4 Gumbo. Если кто не в курсе, эти пространства имен появились после отказа от префикса Fx в именах компонентов Gumbo.

Редактирование пространств имен, о которых будет известно среде разработки, производится в настройках проекта (комбинация Ctrl+Alt+Shift+S) на вкладке Flex Compiller Settings. Однако добавлять в этот список стандартные пространства имен (http://ns.adobe.com/mxml/2009, library://ns.adobe.com/flex/spark, library://ns.adobe.com/flex/halo, http://www.adobe.com/2006/mxml и http://ns.adobe.com/fxg/2008) совсем необязательно — они подхватываются средой «на лету» из файла flex-config.xml.

Хочется пожелать разработчиками также побыстрее справиться с изменившимся синтаксисом стилевых блоков CSS.

Примечание: если вы используете самостоятельную сборку Flex 4 SDK и у вас не компилируется SWF-файл приложения, то это означает, что вам необходимо удалить файл IDEA_INSTALL_DIR\plugins\flex\lib\idea-fcsh-fix.jar. Более подробно об этой ошибке читайте в JetBrains JIRA.

Вчера вышла новая EAP-сборка Intellij IDEA 9805 с поддержкой пространств имен в MXML-разметке Flex 4 Gumbo. Если кто не в курсе, эти пространства имен появились после отказа от префикса Fx в именах компонентов Gumbo.

Редактирование пространств имен, о которых будет известно среде разработки, производится в настройках проекта (комбинация Ctrl+Alt+Shift+S) на вкладке Flex Compiller Settings. Однако добавлять в этот список стандартные пространства имен (http://ns.adobe.com/mxml/2009, library://ns.adobe.com/flex/spark, library://ns.adobe.com/flex/halo, http://www.adobe.com/2006/mxml и http://ns.adobe.com/fxg/2008) совсем необязательно — они подхватываются средой «на лету» из файла flex-config.xml.

Хочется пожелать разработчиками также побыстрее справиться с изменившимся синтаксисом стилевых блоков CSS.

Примечание: если вы используете самостоятельную сборку Flex 4 SDK и у вас не компилируется SWF-файл приложения, то это означает, что вам необходимо удалить файл IDEA_INSTALL_DIR\plugins\flex\lib\idea-fcsh-fix.jar. Более подробно об этой ошибке читайте в JetBrains JIRA.

• позволяет легко и наглядно определять их свойства и обработчики событий
• автоматически делает переменные Bindable
• позволяет их связать с другими переменными и выражениями
• делает наглядным код

Но, на сколько я понял, не все классы можно представить в декларативном виде.

Например, класс flash.utils.Timer невозможно представить в виде MXML. Компилятор выдает ошибку "Неправильное количество аргументов". Всё от того, что конструктор этого класса содержит один обязательный параметр. Как его указать, и возможно ли это, увы, я не понял.

Но есть простое решение - использовать другой класс, хорошо подходящий по своему функционалу - mx.effects.Pause:

• позволяет легко и наглядно определять их свойства и обработчики событий
• автоматически делает переменные Bindable
• позволяет их связать с другими переменными и выражениями
• делает наглядным код

Но, на сколько я понял, не все классы можно представить в декларативном виде.

Например, класс flash.utils.Timer невозможно представить в виде MXML. Компилятор выдает ошибку "Неправильное количество аргументов". Всё от того, что конструктор этого класса содержит один обязательный параметр. Как его указать, и возможно ли это, увы, я не понял.

Но есть простое решение - использовать другой класс, хорошо подходящий по своему функционалу - mx.effects.Pause:

Основные положения

В настоящее время не существует способа документировать MXML-компоненты. (Кстати, в лайфдоках про это вот что сказано: Documenting MXML files). Компилятор asdoc не обрабатывает комментарии в MXML-файлах. Но число компонентов, разрабатываемых на базе MXML неуклонно растет, поэтому поддержка в asdoc файлов MXML очень бы помогла разработчикам при создании документации.

ASDoc комментарий

Для того, чтобы ASDoc-комментарий был обработан asdoc-компилятором, необходимо указать 3 тире после <!:
<!--- asdoc comment -->
Для сравнения - обычный комментарий начинается с 2-х тире.

Комментирование MXML-компонентов и компонента уровня класса

Комментарии для компонентов внутри MXML должны располагаться перед компонентами.
Комментарий компонента уровня класса должен располагаться перед корневым тегом MXML:

Комментарии перед тегами Script, Metadata будут игнорироваться. Перед тегами Definition, Library, Private и внутри их, комментарии так же будут игнорироваться.

Итог

В статье приводятся примеры использования ASDoc комментирования в различных его применениях. Рассматривать их подробно я не буду - всё достаточно прозрачно.

Вывод таков - MXML комментировать надо. И для этого уже существует прототип (если я правильно понял) стандарта, которого и следует придерживаться.

Основные положения

В настоящее время не существует способа документировать MXML-компоненты. (Кстати, в лайфдоках про это вот что сказано: Documenting MXML files). Компилятор asdoc не обрабатывает комментарии в MXML-файлах. Но число компонентов, разрабатываемых на базе MXML неуклонно растет, поэтому поддержка в asdoc файлов MXML очень бы помогла разработчикам при создании документации.

ASDoc комментарий

Для того, чтобы ASDoc-комментарий был обработан asdoc-компилятором, необходимо указать 3 тире после <!:
<!--- asdoc comment -->
Для сравнения - обычный комментарий начинается с 2-х тире.

Комментирование MXML-компонентов и компонента уровня класса

Комментарии для компонентов внутри MXML должны располагаться перед компонентами.
Комментарий компонента уровня класса должен располагаться перед корневым тегом MXML:

Комментарии перед тегами Script, Metadata будут игнорироваться. Перед тегами Definition, Library, Private и внутри их, комментарии так же будут игнорироваться.

Итог

В статье приводятся примеры использования ASDoc комментирования в различных его применениях. Рассматривать их подробно я не буду - всё достаточно прозрачно.

Вывод таков - MXML комментировать надо. И для этого уже существует прототип (если я правильно понял) стандарта, которого и следует придерживаться.

Для начала, несколько заметок:

• Перенос строки в строках MXML: символ &#xd; - мелочь, а приятно.
• Загрузка сложных Flash-приложений в SWFLoader должна производиться в выделенный домен приложения, т.к. могут быть конфликты классов:

• Если внешнее приложение подгружается в SWFLoader, есть вероятность, что в какой-то момент SWFLoader потеряет stage, что может пагубно отразиться на функциональности этого приложения. Если приложение где-то внутри обращается к stage и не обрабатывает его недоступность, то будут генерироваться ошибки. Побороть этот недостаток я не смог - только устранив все "не защищенные" stage из внешнего приложения.
• Внедрение шрифтов. Гораздо надежнее внедрять шрифт непосредственно из TTF файла. Внедрение из файла SWF, в котором, в свою очередь, внедрен необходимый шрифт лучше оставить для тяжелых случаев несовместимостей с Flex. Дело в том, что почему-то, внедренные в SWF разные стили (normal, bold) шрифта не корректно "извлекаются" Flex-ом. Он не дает назвать разные стили разными именами (как это можно сделать в первом случае), теряет одно из начертаний (жирный шрифт просто не выводится). Возможно, это из-за особенностей конкретных шрифтов, но первый метод срабатывает гораздо стабильнее.

• Внедрять клип из внешней SWF так, чтобы работали его фреймовые скрипты можно следующим образом:
  source="@Embed(source='assets/Index.swf')"
  При внедрении отдельного символа, его фреймовые скрипты и скрипты всех вложенных объектов теряются:
  source="@Embed(source='assets/Index.swf'#Index)"
  Игра с параметром mimeType не помогает.

На управлении внедренным контентом я бы хотел остановиться подробнее. Если у нас много однотипного материала для внедрения вышеописанным способом, то плодить SWF-файлы не удобно, плюс, внедряя каждый файл, мы не можем обобщать графику - она будет внедряться для каждого файла заново (не проверял, но догадываюсь).

Куда удобнее создать одну большую библиотеку и из нее внедрять символы. Но, к сожалению, их скрипты уже будут не доступны.
Но у нас есть в распоряжении метки фреймов и имена клипов. Совмещая возможности
MovieClip.currentLabels и MovieClip.addFrameScript можно получить контроль над внедренным клипом и заставлять его в нужный момент выполнять необходимые нам действия: останавливать клип на нужном фрейме, генерировать события и даже передавать данные в текстовые поля клипа.

Создаем компонент - наследник SWFLoader. После инстанцирования класса внедренного клипа (конец метода load(), можно так же добавить и в обработчик события загрузки), считываются все его метки и в их фреймы добавляются необходимые скрипты. Имя каждой метки имеет ключевую составляющую, которая и определяет тип действия добавляемого скрипта.
В нужный момент можно заставить клип остановиться, перейти на другую метку, генерировать событие (с идентификатором, так же зашитым в имя метки), просканировать клип и получить срез всех визуальных объектов, чтобы делать с ними всё что угодно. Главное - этот момент устанавливается прямо в таймлайне клипа, а не путем каких-либо расчетов количества фреймов или подобных методов.

Прекрасный момент - праздник еще не настал, а дидлайны уже позади! Отдыхать и набираться сил.

И конечно, наших прекрасных женщин поздравляю с праздником 8 марта!

Для начала, несколько заметок:

• Перенос строки в строках MXML: символ &#xd; - мелочь, а приятно.
• Загрузка сложных Flash-приложений в SWFLoader должна производиться в выделенный домен приложения, т.к. могут быть конфликты классов:

• Если внешнее приложение подгружается в SWFLoader, есть вероятность, что в какой-то момент SWFLoader потеряет stage, что может пагубно отразиться на функциональности этого приложения. Если приложение где-то внутри обращается к stage и не обрабатывает его недоступность, то будут генерироваться ошибки. Побороть этот недостаток я не смог - только устранив все "не защищенные" stage из внешнего приложения.
• Внедрение шрифтов. Гораздо надежнее внедрять шрифт непосредственно из TTF файла. Внедрение из файла SWF, в котором, в свою очередь, внедрен необходимый шрифт лучше оставить для тяжелых случаев несовместимостей с Flex. Дело в том, что почему-то, внедренные в SWF разные стили (normal, bold) шрифта не корректно "извлекаются" Flex-ом. Он не дает назвать разные стили разными именами (как это можно сделать в первом случае), теряет одно из начертаний (жирный шрифт просто не выводится). Возможно, это из-за особенностей конкретных шрифтов, но первый метод срабатывает гораздо стабильнее.

• Внедрять клип из внешней SWF так, чтобы работали его фреймовые скрипты можно следующим образом:
  source="@Embed(source='assets/Index.swf')"
  При внедрении отдельного символа, его фреймовые скрипты и скрипты всех вложенных объектов теряются:
  source="@Embed(source='assets/Index.swf'#Index)"
  Игра с параметром mimeType не помогает.

На управлении внедренным контентом я бы хотел остановиться подробнее. Если у нас много однотипного материала для внедрения вышеописанным способом, то плодить SWF-файлы не удобно, плюс, внедряя каждый файл, мы не можем обобщать графику - она будет внедряться для каждого файла заново (не проверял, но догадываюсь).

Куда удобнее создать одну большую библиотеку и из нее внедрять символы. Но, к сожалению, их скрипты уже будут не доступны.
Но у нас есть в распоряжении метки фреймов и имена клипов. Совмещая возможности
MovieClip.currentLabels и MovieClip.addFrameScript можно получить контроль над внедренным клипом и заставлять его в нужный момент выполнять необходимые нам действия: останавливать клип на нужном фрейме, генерировать события и даже передавать данные в текстовые поля клипа.

Создаем компонент - наследник SWFLoader. После инстанцирования класса внедренного клипа (конец метода load(), можно так же добавить и в обработчик события загрузки), считываются все его метки и в их фреймы добавляются необходимые скрипты. Имя каждой метки имеет ключевую составляющую, которая и определяет тип действия добавляемого скрипта.
В нужный момент можно заставить клип остановиться, перейти на другую метку, генерировать событие (с идентификатором, так же зашитым в имя метки), просканировать клип и получить срез всех визуальных объектов, чтобы делать с ними всё что угодно. Главное - этот момент устанавливается прямо в таймлайне клипа, а не путем каких-либо расчетов количества фреймов или подобных методов.

Прекрасный момент - праздник еще не настал, а дидлайны уже позади! Отдыхать и набираться сил.

И конечно, наших прекрасных женщин поздравляю с праздником 8 марта!

В моем опыте Flex-разработки наступает новая стадия взросления.

Ну, условно, у себя я уже могу выделить две стадии (не считая робкого потрагивания и любопытного пощупывания):

• Код представляет собой голый MXML, на котором и построено всё приложение. Крупные вспомогательные структуры классов и обильные инклюды. В решении относительно сложных задач (либо совсем простых) я полагался только на pure AS проекты и компоненты.
• Приложение делилось на компоненты (MXML компоненты), каждое окошко, каждый функционально законченный экран были компонентами. Обильное использование компонентов значительно упростило разработку приложений и внесло строгость и порядок, несмотря на довольно пространный список в Components -> Custom.
  Кроме того, такой подход значительно ускоряет разработку, уже засчет того, что визуальный редактор теперь не должен перерисовывать каждый раз всё приложение (а делает он это отнюдь не быстро).

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

Руки так и зачесались попробовать создать модуль в FB. Открываю проект, создаю New->MXML Module. Открывается новый файл mxml, в который я добавляю, к примеру, кнопку, и текстовое поле. Сохраняю. В окошке Components->Custom появился новый компонент, по имени модуля.
Проведем эксперемент. Перетащим его в окно основного приложения. Всё как с обычным компонентом. Компилирую. Замечательно: скомпилировалось два swf - один с именем приложения, другой - с именем модуля.
Для любопытства, копируем один только swf приложения и запускаем: видим кнопку и текстовое поле. Как я и предполагал, наш модуль включен в состав swf приложения как обычный компонент.
Запустим swf модуля. Сразу получаем ошибку "Не удалось найти класс mx.core::SpriteAsset." И не мудрено - модуль не содержит классов, включенных в основное приложение.
Но нам-то от модуля нужно что? Чтобы он не был включен в приложение, а подгружался в процессе работы приложения. Хотя, возможность использовать модуль как обычный MXML-компонент тоже надо отметить.

Ознакомимся вкратце с документацией: Creating Modular Applications. Здесь всё, на достаточно понятном языке, достаточно подробно разжевывается.

Итак. Нас интересовали загрузка модуля и ее мониторинг.
Пожалуйста, смотрим: Loading and unloading modules. За загрузку отвечает класс ModuleLoader. Любопытно, что это наследник VBox. Непонятно, почему именно VBox, а не, к примеру, HBox. Уж я-то вообще ожидал увидеть в этой роли SWFLoader. Ну да ладно. Убираем из кода приложения модуль и вставляем ModuleLoader. Кстати, он присутствует в палитре компонентов Layout.
Вписываем в свойство url имя файла модуля. И что особенно приятно, визуальный редактор сразу отобразил содержимое модуля. Вводим имя другого модуля - пожалста! Отображается другой модуль. Запускаем - всё замечательно отображается и работает.
Теперь по поводу мониторинга. Смотрим Using ModuleLoader events. ModuleLoader генерирует следующие события: setup, ready, loading, unload, progress, error, и urlChanged. Но позвольте! Если progress мы наблюдаем в этом списке, то почему нет open и complete? Что помешало вместо loading генерировать open, а вместо ready - complete?
При таком раскладе, если я использую ProgressBar в режиме mode="event", загрузка успешно мониторится, но ProgressBar не генерирует событие complete, что в некоторых случаях было бы полезно. Ну что ж, никто не мешает нам устранить этот недостаток, создав своего потомка ModuleLoader. Дело поправимое.

Есть еще один компонент, управляющий загрузкой модулей: ModuleManager. Этот класс, как нам обещают, предоставляет больше возможностей по управлению загрузкой модулей чем предыдущий. Но при этом, как утверждается, техника его использования является менее абстрактной чем работа с ModuleLoader.
Да, разработчики Flex не перестают меня удивлять. ModuleManager наследуется от Object и содержит всего два статических метода, что ввело меня в небольшой ступор. Однако, после изучения предложенных примеров, всё встало на свои места. Метод ModuleManager.getModule возвращает объект, удовлетворяющий интерфейсу IModuleInfo, уникальный для каждого управляемого модуля. Этот объект, в дальнейшем, можно использовать для загрузки модуля (метод load) и мониторинга событий загрузки, а затем, для инстанцирования модуля (через свойство factory).
Более подробное изучение этого класса, погружает нас в глубины Flex, что в мои планы пока совсем не входит. Вот уж, другими словами и не скажешь - все намного менее абстрактно. И больше подходит для решения специфических задач.

Ну-с, добро пожаловать в мир модульных приложений. Начинаем действовать!

В моем опыте Flex-разработки наступает новая стадия взросления.

Ну, условно, у себя я уже могу выделить две стадии (не считая робкого потрагивания и любопытного пощупывания):

• Код представляет собой голый MXML, на котором и построено всё приложение. Крупные вспомогательные структуры классов и обильные инклюды. В решении относительно сложных задач (либо совсем простых) я полагался только на pure AS проекты и компоненты.
• Приложение делилось на компоненты (MXML компоненты), каждое окошко, каждый функционально законченный экран были компонентами. Обильное использование компонентов значительно упростило разработку приложений и внесло строгость и порядок, несмотря на довольно пространный список в Components -> Custom.
  Кроме того, такой подход значительно ускоряет разработку, уже засчет того, что визуальный редактор теперь не должен перерисовывать каждый раз всё приложение (а делает он это отнюдь не быстро).

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

Руки так и зачесались попробовать создать модуль в FB. Открываю проект, создаю New->MXML Module. Открывается новый файл mxml, в который я добавляю, к примеру, кнопку, и текстовое поле. Сохраняю. В окошке Components->Custom появился новый компонент, по имени модуля.
Проведем эксперемент. Перетащим его в окно основного приложения. Всё как с обычным компонентом. Компилирую. Замечательно: скомпилировалось два swf - один с именем приложения, другой - с именем модуля.
Для любопытства, копируем один только swf приложения и запускаем: видим кнопку и текстовое поле. Как я и предполагал, наш модуль включен в состав swf приложения как обычный компонент.
Запустим swf модуля. Сразу получаем ошибку "Не удалось найти класс mx.core::SpriteAsset." И не мудрено - модуль не содержит классов, включенных в основное приложение.
Но нам-то от модуля нужно что? Чтобы он не был включен в приложение, а подгружался в процессе работы приложения. Хотя, возможность использовать модуль как обычный MXML-компонент тоже надо отметить.

Ознакомимся вкратце с документацией: Creating Modular Applications. Здесь всё, на достаточно понятном языке, достаточно подробно разжевывается.

Итак. Нас интересовали загрузка модуля и ее мониторинг.
Пожалуйста, смотрим: Loading and unloading modules. За загрузку отвечает класс ModuleLoader. Любопытно, что это наследник VBox. Непонятно, почему именно VBox, а не, к примеру, HBox. Уж я-то вообще ожидал увидеть в этой роли SWFLoader. Ну да ладно. Убираем из кода приложения модуль и вставляем ModuleLoader. Кстати, он присутствует в палитре компонентов Layout.
Вписываем в свойство url имя файла модуля. И что особенно приятно, визуальный редактор сразу отобразил содержимое модуля. Вводим имя другого модуля - пожалста! Отображается другой модуль. Запускаем - всё замечательно отображается и работает.
Теперь по поводу мониторинга. Смотрим Using ModuleLoader events. ModuleLoader генерирует следующие события: setup, ready, loading, unload, progress, error, и urlChanged. Но позвольте! Если progress мы наблюдаем в этом списке, то почему нет open и complete? Что помешало вместо loading генерировать open, а вместо ready - complete?
При таком раскладе, если я использую ProgressBar в режиме mode="event", загрузка успешно мониторится, но ProgressBar не генерирует событие complete, что в некоторых случаях было бы полезно. Ну что ж, никто не мешает нам устранить этот недостаток, создав своего потомка ModuleLoader. Дело поправимое.

Есть еще один компонент, управляющий загрузкой модулей: ModuleManager. Этот класс, как нам обещают, предоставляет больше возможностей по управлению загрузкой модулей чем предыдущий. Но при этом, как утверждается, техника его использования является менее абстрактной чем работа с ModuleLoader.
Да, разработчики Flex не перестают меня удивлять. ModuleManager наследуется от Object и содержит всего два статических метода, что ввело меня в небольшой ступор. Однако, после изучения предложенных примеров, всё встало на свои места. Метод ModuleManager.getModule возвращает объект, удовлетворяющий интерфейсу IModuleInfo, уникальный для каждого управляемого модуля. Этот объект, в дальнейшем, можно использовать для загрузки модуля (метод load) и мониторинга событий загрузки, а затем, для инстанцирования модуля (через свойство factory).
Более подробное изучение этого класса, погружает нас в глубины Flex, что в мои планы пока совсем не входит. Вот уж, другими словами и не скажешь - все намного менее абстрактно. И больше подходит для решения специфических задач.

Ну-с, добро пожаловать в мир модульных приложений. Начинаем действовать!

* * *

Впечатления. Работа с модулями не разочаровала: стабильно и надежно. Единственные проблемы, с которыми я столкнулся:

• Внедрение шрифта. CSS с внедрением TTF-шрифта определяется в главном приложении. Подгружаемые модули успешно используют эти шрифты. Но, возникла проблема с внедряемыми SWF, в которых используется другой шрифт. При вводе в динамические поля, ничего не отображалось. Тогда я внедрил этот шрифт в модуль. Шрифт стал отображаться. Но, что интересно, когда я собрал Release Build, шрифт опять перестал отображаться. Пришлось оставить Debug-версию модуля. Но это повлекло за собой следующую проблему.
• Если основное приложение собрано в Release Build, оно некорректно подгружает модуль, собранный в Debug Build. Я думаю, что вообще, по-отдельности модули лучше не обновлять. Я обратил внимание, что размер SWF-файла модуля даже при небольших изменениях, при перекомпиляции заметно меняется. Поэтому, следует, наверное, соблюдать осторожность при компиляции и обновлении модулей.

Олег Галабурда опубликовал во Flex Cookbook первый февральский пост который можно занести в актив UAFPUG в конкурсе "Кукбуклук".

На английском пост Олега называется так: Adding multiple sets of visual children to custom MXML components и в нем рассказывается, как с помощью состояний решить одну популярную проблему с добавлением многих дочерних компонентов к вашим собственным. Спасибо, Олег.

Напомню, что если вы публикуете пост во Flex CookBook, AIR Cookbook или Mobile Cookbook, то вы можете не ограничиваться вхождением в историю, но и получить возможность выиграть лицензию на Flex Builder 3 или Adobe CS4 Master Collection. Чтобы это стало возможным, я должен знать о вашей публикации и сообщать о ней Эду. А Эд выдаст нам серийный номер, который мы разыграем между опубликовавшими записи. Поэтому сообщайте мне на гуглопочту rostislav.siryk каждый раз, когда пишете в кукбук.

Олег Галабурда опубликовал во Flex Cookbook первый февральский пост который можно занести в актив UAFPUG в конкурсе "Кукбуклук".

На английском пост Олега называется так: Adding multiple sets of visual children to custom MXML components и в нем рассказывается, как с помощью состояний решить одну популярную проблему с добавлением многих дочерних компонентов к вашим собственным. Спасибо, Олег.

Напомню, что если вы публикуете пост во Flex CookBook, AIR Cookbook или Mobile Cookbook, то вы можете не ограничиваться вхождением в историю, но и получить возможность выиграть лицензию на Flex Builder 3 или Adobe CS4 (любой набор кроме Master Collection). Чтобы это стало возможным, я должен знать о вашей публикации и сообщать о ней Эду. А Эд выдаст нам серийный номер, который мы разыграем между опубликовавшими записи. Поэтому сообщайте мне на гуглопочту rostislav.siryk каждый раз, когда пишете в кукбук.

Ура!

свершилось чудо, появился бесплатный кодоформатер для as3|mxml в Flex Builder

http://www.riaspace.net/2009/01/ctrlshiftf-for-flex-builder/

В отличаи от ранее предлагаемого в поставке InterpriseIDE имеет настройки форматирования и работает лучше (ну или мне так показалось).

Спасибо Косте за ссылку

Ура!

свершилось чудо, появился бесплатный кодоформатер для as3|mxml в Flex Builder

http://www.riaspace.net/2009/01/ctrlshiftf-for-flex-builder/

В отличаи от ранее предлагаемого в поставке InterpriseIDE имеет настройки форматирования и работает лучше (ну или мне так показалось).

Спасибо Косте за ссылку

Время от времени кто-то спрашивает, с чего начать освоение FlashDevelop, замечательного IDE для разработки Flash / Flex приложений. Некоторые туториалы и информация по флэшдевелопу:

• Разработка AS3 / MXML приложений с помощью FlashDevelop.
• Можно ли компилировать целиком сложные проекты во FlashDevelop?
• Разработка Flex-based AIR (Apollo) приложений во FlashDevelop.
• Настройка ASDoc для FlashDevelop.
• Tutorial: AS3 in FlashDevelop (in English).
• FlashDevelop 3.0 Beta8, много плюшек.
• FlashDevelop 3.0 - настройка trace mode.
• Налаживаем компиляцию под Flash Player 10 из FlashDevelop IDE.
• Cравнение средств разработки RIA приложений используя Flash платформу.

Что-то здесь лишнее, а чего-то не хватает? Прошу высказываться и давать ссылки — облегчим правильным людям начало жизни с правильным редактором кода.

Обнаружил, что во Flex Builder работают шорткаты, позволяющие переключаться между открывающими и закрывающими скобками в коде:

Работают так, как и показано в картинке:

Ctrl+Shift+P — переключает между открывающей и закрывающей фигурными скобками при редактировании MXML- или AS3- кода.
Ctrl+B — переключает между открывающей и закрывающей фигурными или круглыми скобками при редактировании JavaScript-кода (при установленном JSEclipse, идет вместе с Flex Builder).
Ctrl+G — выделяет текст между открывающей и закрывающей скобками при редактировании JavaScript-кода (нужен JSEclipse).

Возможно, это для вас уже и не новость, но вот в Aptana IDE такого шортката нет (а там он еще нужнее при редактировании больших блоков JSON-кода).

Ссылка про теме: 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know.

??????????????????, ?????? ???? Flex Builder ???????????????? ????????????????, ?????????????????????? ?????????????????????????? ?????????? ???????????????????????? ?? ???????????????????????? ???????????????? ?? ????????:

???????????????? ??????, ?????? ?? ???????????????? ?? ????????????????:

Ctrl+Shift+P ??? ?????????????????????? ?????????? ?????????????????????? ?? ?????????????????????? ?????????????????? ???????????????? ?????? ???????????????????????????? MXML- ?????? AS3- ????????.
Ctrl+B ??? ?????????????????????? ?????????? ?????????????????????? ?? ?????????????????????? ?????????????????? ?????? ???????????????? ???????????????? ?????? ???????????????????????????? JavaScript-???????? (?????? ?????????????????????????? JSEclipse, ???????? ???????????? ?? Flex Builder).
Ctrl+G ??? ???????????????? ?????????? ?????????? ?????????????????????? ?? ?????????????????????? ???????????????? ?????? ???????????????????????????? JavaScript-???????? (?????????? JSEclipse).

????????????????, ?????? ?????? ?????? ?????? ?? ???? ??????????????, ???? ?????? ?? Aptana IDE ???????????? ???????????????? ?????? (?? ?????? ???? ?????? ???????????? ?????? ???????????????????????????? ?????????????? ???????????? JSON-????????).

???????????? ?????? ????????: 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know.

Нам пишет Елена Геллер (Дортмунд, Германия):

Вы когда-то сообщали о Flexclipse как о "минималистской" среде разработки. Flexclipse, похоже, пока не развивается. Существуют, однако, два других интересных опенсорсных проекта — axdt для Eclipse от Martin Schnabel (до этого, как я понимаю, создал ASDT) и FlexBean для Netbeans.

Оба проекта до времени находились в довольно сыром состоянии. Но вот недавно AXDT (с версии 0.0.6) и FlexBean (с сегодня) относительно юзабельны. Для больших проектов не вполне годятся, но для небольших поделок руками пользователей Линукса уже применяться могут. Как дебаггер "до кучи" вполне пойдет Arthropod; я его недавно оттестировала на Opensuse 11, запущенной в live-варианте с CD еще с бета-версией AIR — работает себе.

Насколько это актуально для отечественного разработчика, часто и густо пользующего "левый" софт (и, "имея то, что имеем", осуждать людей тут не за что), я не знаю. Это несколько актуальнее для западных линуксоидов. Да и вообще, для мелких самостоятельных разработчиков, не желающих проблем с законом, но начинающих практически с нуля (имею в виду материальную базу). Но по крайней мере, Flex-разработка под Линуксом медленно становится реальностью.

Ах да: плюсы и минусы. AXDT пользует опенсорсный Flex SDK, в настоящее время поставляется с версиями 3 и 4, но самостоятельно версию поменять нельзя. Cкажем, если завтра выйдет 3.3., то надо будет ждать следующей версии AXDT, которая авось это учтет. То есть может быть там можно что-то "подточить напильником", но я пока не знаю, где именно. А вот FlexBean можно без проблем переключать между любым количеством версий Flex SDK, но:

1. Для MXML пока что нет подсветки кода.
2. Проект по умолчанию создается с главным mxml-файлом, поэтому, если хочешь чисто AS-проект, надо сначала позволить создать этот главный файл (все остальное невозможно), а потом подправить свойства проекта.

Разумеется, об удобствах, предоставляемых FlashDevelop, пока можно только мечтать, но мы же пока что говорим о минималистском варианте. К тому же мне пока неясно, возможно ли подключать в обоих плагинах внешние библиотеки. Пока что я вижу только одну возможность: в той же папке, где лежит главный файл проекта (назовем его main.as), добавить конфигурационный файл, который в этом случае будет называться main-config.xml (тогда при компиляции он считается по умолчанию), и в нем внести все необходимые параметры, не забыв при этом цвет фона / ширину / высоту и пр.

Елена, спасибо за этот обзор!

?????? ?????????? ?????????? ???????????? (????????????????, ????????????????):

???? ??????????-???? ???????????????? ?? Flexclipse ?????? ?? "????????????????????????????" ?????????? ????????????????????. Flexclipse, ????????????, ???????? ???? ??????????????????????. ????????????????????, ????????????, ?????? ???????????? ???????????????????? ?????????????????????? ?????????????? ??? axdt ?????? Eclipse ???? Martin Schnabel (???? ??????????, ?????? ?? ??????????????, ???????????? ASDT) ?? FlexBean ?????? Netbeans.

?????? ?????????????? ???? ?????????????? ???????????????????? ?? ???????????????? ?????????? ??????????????????. ???? ?????? ?????????????? AXDT (?? ???????????? 0.0.6) ?? FlexBean (?? ??????????????) ???????????????????????? ??????????????????. ?????? ?????????????? ???????????????? ???? ???????????? ??????????????, ???? ?????? ?????????????????? ?????????????? ???????????? ?????????????????????????? ?????????????? ?????? ?????????????????????? ??????????. ?????? ???????????????? "???? ????????" ???????????? ???????????? Arthropod; ?? ?????? ?????????????? ?????????????????????????? ???? Opensuse 11, ???????????????????? ?? live-???????????????? ?? CD ?????? ?? ????????-?????????????? AIR ??? ???????????????? ????????.

?????????????????? ?????? ?????????????????? ?????? ???????????????????????????? ????????????????????????, ?????????? ?? ?????????? ?????????????????????? "??????????" ???????? (??, "???????? ????, ?????? ??????????", ???????????????? ?????????? ?????? ???? ???? ??????), ?? ???? ????????. ?????? ?????????????????? ???????????????????? ?????? ???????????????? ??????????????????????. ???? ?? ????????????, ?????? ???????????? ?????????????????????????????? ??????????????????????????, ???? ???????????????? ?????????????? ?? ??????????????, ???? ???????????????????? ?????????????????????? ?? ???????? (???????? ?? ???????? ???????????????????????? ????????). ???? ???? ?????????????? ????????, Flex-???????????????????? ?????? ???????????????? ???????????????? ???????????????????? ??????????????????????.

???? ????: ?????????? ?? ????????????. AXDT ???????????????? ?????????????????????? Flex SDK, ?? ?????????????????? ?????????? ???????????????????????? ?? ???????????????? 3 ?? 4, ???? ???????????????????????????? ???????????? ???????????????? ????????????. C??????????, ???????? ???????????? ???????????? 3.3., ???? ???????? ?????????? ?????????? ?????????????????? ???????????? AXDT, ?????????????? ?????????? ?????? ??????????. ???? ???????? ?????????? ???????? ?????? ?????????? ??????-???? "?????????????????? ??????????????????????", ???? ?? ???????? ???? ????????, ?????? ????????????. ?? ?????? FlexBean ?????????? ?????? ?????????????? ?????????????????????? ?????????? ?????????? ?????????????????????? ???????????? Flex SDK, ????:

1. ?????? MXML ???????? ?????? ?????? ?????????????????? ????????.
2. ???????????? ???? ?????????????????? ?????????????????? ?? ?????????????? mxml-????????????, ??????????????, ???????? ???????????? ?????????? AS-????????????, ???????? ?????????????? ?????????????????? ?????????????? ???????? ?????????????? ???????? (?????? ?????????????????? ????????????????????), ?? ?????????? ???????????????????? ???????????????? ??????????????.

????????????????????, ???? ??????????????????, ?????????????????????????????? FlashDevelop, ???????? ?????????? ???????????? ??????????????, ???? ???? ???? ???????? ?????? ?????????????? ?? ???????????????????????????? ????????????????. ?? ???????? ???? ?????? ???????? ????????????, ???????????????? ???? ???????????????????? ?? ?????????? ???????????????? ?????????????? ????????????????????. ???????? ?????? ?? ???????? ???????????? ???????? ??????????????????????: ?? ?????? ???? ??????????, ?????? ?????????? ?????????????? ???????? ?????????????? (?????????????? ?????? main.as), ???????????????? ???????????????????????????????? ????????, ?????????????? ?? ???????? ???????????? ?????????? ???????????????????? main-config.xml (?????????? ?????? ???????????????????? ???? ?????????????????? ???? ??????????????????), ?? ?? ?????? ???????????? ?????? ?????????????????????? ??????????????????, ???? ?????????? ?????? ???????? ???????? ???????? / ???????????? / ???????????? ?? ????.

??????????, ?????????????? ???? ???????? ??????????!

Передо мной стоит прозаичная задача - мини-редактор с использованием кривых Безье. Есть некая фигура, состоящая из кривых. Необходимо ее редактировать, путем изменении положения опорных точек.

Итак, прежде чем обратиться к таким авторитетным проектам как http://bezier.ru/, интересно было бы прогуляться по гуглу и посмотреть, что еще предлагают по этой теме.

Один из первых попавшихся - блог Paul Tondeur и его изыскания на эту тему: Drawing a cubic bezier curve using ActionScript3. Здесь можно ознакомиться с теоретической частью и изучить примерчик.

Дальше, получаем интересную статейку ссылкой с Drawlogic.com на labs.zeh.com.br: The search for the perfect bezier tweening syntax. Поиск решения создания пути перемещения при помощи кривых Безье. Особенно понравился пример с использованием Papervision3D - задается путь движения между фигурами.

Далее: Singularity представляет черезчур заумные классы с кучей примеров: Demos. Статья с описанием: AS 3 Parametric Curve Library.

Еще одна хорошая ссылочка: некий Cartogrammar представляет весьма доступный и очень простой в использовании класс CubicBezier.as. Здесь всего два статических метода, которые отрисовывают кривые разными способами. Кстати, очень даже заслуживает внимания. Пока ходил по ссылкам, натолкнулся на забавную демку как раз с использованием этого класса: AS3 Bezier blobs/metaballs

Интересный набор библиотек на Greensock: TweenLite, TweenMax, TweenFilterLite, TransformManager (AS3), TweenGroup. Не относится к кривым Безье (точнее их использует в некоторых случаях), но заставляет обратить на себя внимание.

Небольшое решение, которое может быть полезным: CurveToArray (AS3 class). На основании трех точек кривой Безье, выдает массив координат точек кривой.

Еще немного русскоязычного: Движение по кривой Безье.

А вот некий Flashgamer советует задвинуть "a couple good resources" и взяться все же за Degrafa. Ввиду "крупности" этого движка, оставим его на десерт.

Поглядим, таки, что нам предлагает наш http://bezier.ru/. Здесь множество документации на русском (что важно), обзорная демка и исходники. Скачать исходники можно при помощи SVN-клиента. - делаем СheckОut. Исходники по большей части представляют собой примеры использования, что конечно радует. В принципе писать тут нечего - сайт полон информации на русском, и если что, здесь же можно написать комментарий и получить ответ от хозяев. Надо просто попробовать.
Создаем проект AS3 в FD, кладем в него примеры, прописываем пути к библиотеке и компилируем. Ошибка: "Bezier.as(1488): col: 12 Error: Недопустимое присваивание переменной, которая определена как константа." Ну что ж делать, бывает. В строке "const limiter : Number = 20;" Меняем "const" на "var" и наслаждаемся демкой.
Кстати, исходный код просто перегружен ASDoc-комментариями (что, безусловно, является достоинством). Однако, ни на сайте, ни на Google Code я не смог найти ASDoc-документации Bezier. Странно...

Перейдем к Degrafa. Скачать ее можно на Google Code, но я, пожалуй, воспользуюсь SVN. Пришлось здорово повозиться, чтобы запустить примеры.
При использовании исходников, я вообще не смог избавиться от ошибок - что я не делал - везде вставала проблема некорректных namespace.
При использовании SWC, пример тоже выдавал кучу ошибок. Загвозка была в том, что в примерах указан namespace xmlns:degrafa="http://www.degrafa.com/2008", а нужно xmlns:degrafa="http://www.degrafa.com/2007".
Вывод по Degrafa - мощная и популярная система, но требует углубленного изучения.

Итак, вывод. Для себя я избрал три варианта:

1. CubicBezier.as.
2. Bezier.ru.
3. Degrafa.

CubicBezier - вполне работоспособный, примитивный движок позволяющий рисовать кривые Безье с различными параметрами. Его можно сразу использовать "как есть", либо с необходимыми модификациями, которые внести совсем не сложно. Предварительного изучения не требует, для моей задачи подходит "на ура".
Bezier - Требует предварительного изучения, зато предоставляет широкий набор возможностей для решения большинства практических задач, связанных с кривыми Безье.
Degrafa - Мощный комплекс, позволяющий создавать графику декларативно, при помощи MXML. Для того, чтобы приступить к решению задачи, придется изрядно почитать документацию, которая имеется в изобилии, в формате ASDoc. За изучение есть смысл взяться, т.к. проект весьма перспективный и популяризирующийся. Однако, как всегда, под конец года времени нет, поэтому придется отложить. Но не надолго - ощутив вкус прелестей Degrafa, уже не хочется от него отказываться.

Сегодня в сети появилась статья “Еще одно сравнение Adobe Flash и Silverlight 2″ , прочитав ее я понял главную ошибку авторов этих статей — каждый автор является специалистом только в одной области, или Flash|Flex или Silverlight. Поэтому страдают “конкурирующие платформы”. Как выход я вижу написание совместной статьи (но это дело долгих споров). Автор данной статья не избежал ошибок и показал всое поверхностное знание Flex/Flash технологии.

Я попытаюсь исправить его недочеты, для полноты картины )

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

Среда разработки и прочий инструментарий.

Для начала разберемся с инструментраем и возможностями:

FlashPlayer — это плагин который позволяет проигрывать swf файлы (байт код, который можно создавать где и как угодно, например умельцы рантайм генерят его и сразу же запускают в флешплеере).
Flash IDE/Flex Builder — это среда позволяющая создавать swf файлы.
Flex framework — это фреймворк позволяющий быстро и эффективно создавать RIA приложения. Flex Builder “заточен” для работы с Flex framework.

Использование Flash IDE как средство разработки крупных приложений, довольно опрометчивый шаг. Ее, в контекте разработы RIA лучше использовать как дополнительное средство.

Вообще не стоит говорить что вся разработка сводится к связку Flash IDE(графика)-Flex(код) — это просто частный случай варианта разработки.

а использовать только Flex сложно, поскольку ничего похожего на дизайн-вью в нем просто нет.

Ляп! пожалуйста, жмем на кнопку Design в MXML редакторе и видим дизайн вью. (единственно что он не работает в билдере под линукс). Может канечно этот дизайн вью и не такой навороченый как бленд, но он есть )

Язык программирования

ActionScript 3 являеться вариантом реализации ECMAScript-262, 4 версии http://en.wikipedia.org/wiki/ECMAScript , Я не буду искать подробности отличая от этого стандарта, они есть и это можно найти воспользовавшись гуглом ).

Язык не имеет …

Да язык часто ругают за его непродвинутость.

Язык не имеет встроенной событийной модели

но это вот ляп, событийная модель является главной фичей флешплеера 9 и выше.
– кстате автор нигде не учитывал возможности флешплеера 10 ) который уже вышел в релиз.

Отдельной строкой хочется сказать об отладчике.
Если во Flex Builder он еще куда ни шло, то во Flash им просто невозможно пользоваться – основным методом отладки до сих пор является trace.

При разработке крупных проектов боже вас упаси использовать и дебажить во Flash IDE! вы же не будете дебажить в Blend’e

Поддержка ОС и браузеров:
А что есть нормальная(официальная) поддержка Linux? Как мне поница Moonlight дорос пока только до версии 1. вобщем то до релиза далеко.
К том же плеер более стабилен в различных системах. (мне порой приходится перегружать барузер или запускать ИЕ чтобы посмотреть приложение на Silverlight, Маководы жалуются что не всегда получается поставить плагин)

Возможность упаковки в исполняемый файл:

Стоит учитывать что есть продукты сторонних производителей которые позволяют делать испольняемые файлвы из флеш/флекс приложений, причем под разные платформы (например Zinс)

Изображения:
JPEG, GIF, PNG — флеш с этим работает на лету. Вектор, у флеша это в крови. Кроме того, что можно импортировать ai,пдф файлы автор забыли о поддержке SVG графики. Причем уже есть библиотреки позволяющие использовать ее рантайм. (Например degrafa http://www.degrafa.com/2007/07/27/how-complex-can-you-get-with-degrafa-very/).
Также можно реализовать поддержку практичеки любого формата графики (ByteArray+Bitmap+Drawing API).
Про скорость отрисовки я бы вообще ничего не говорил, как не крути у флешплеера она больше.
А проблемы подготовки графики это уже проблемы кривых рук.

Видео:
flv это хорошее сжатие, но и возможность лайфстриминга, перемотки и других фич
из коментариев:
+ есть поддержка HD video
Флешплеер это тоже поддерживает.
+ теоретически, поддержку flv можно реализовать самому, используя MediaStreamSource (тут есть примеры http://code.msdn.microsoft.com/ManagedMediaHelpers)
нужна практика а не теория, хотя такой возможностью флеш не может покак порадовать.
Как не крути пока приоритет на стороне флеша

Шрифты:

Имеет три встроенных шрифта, поддерживается импорт символов из шрифтов ТТF, ограниченно поддерживаются шрифты, установленные в системе.

просто глупость.
Мы можем влючить любой шрифт в наше приложение, и он будет работать везде.
3 шрифта, тоже глупость, Просто по умолчанию флекс компоненты используют заданые шрифты, и нечего более.

Формально, не импортированные шрифты поддерживаются. Однако, с текстом, напечатанным таким шрифтом, почти ничего нельзя делать: ни поворачивать, ни масштабировать, ни использовать в качестве маски.

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

Сокеты:
незнаю что твориться в Silverlight, но в FlashPlayer к сожелению имеет некоторые ограничения

Работа с файлами:
Принципиальное преисущество было у Silverlight до выхода 10 версии флешплеера, теперь его нет ).

Хранение данных на клиенте:
хе хе пункту просто не зачет. никак не может влиять на оценку платформы.

Разметка:
Спорный вопрос. Я бы не ставил плюса ни одной из технологий.
Если говорить о скором будующем то будет революция Ключевое слово Flash Catalyst

«Программное» рисование:
Незнаю как обстоят дела в Silverlight, но во флеш им можно творить чудеса.

«Программная» анимация:

Flash/Flex: Основана на фрэймах.

Никто не мешает использовать верменные интервалы. т.е. больше возможностей ).
Я не спец в этой области и пусть те кто работают с FlashCS3|CS4 добавят свои коменты. ).

Собственные контролы:
Автор описал только один, довольно причудливый способ :).
Да. Визуально не всегда сразу можно посмотреть на внешний вид компонента.
Опять же для спора и нахождения истены в данном вопросе нужно сначало определиться с понятием “Собственный контрол”.

Кастомизация контролов
Я незнаю как работают стили в WPF, но

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

Полный бред. Для начала ознакомтесь с возможностями стилировния, затем полистайте примеры на той же Деграфе. Стили во флексе ограничиваются только фантазией, как только она закончилась, так и закончились стили )

Связывание данных

Да, во Flex не создается как таковой объект биндинга

Он то создаеться, но вот доступа мы к нему не имеем. Также есть возможность создать биндинг в коде BindingUtils

А двусторонний биндинг, единственный пока что козырь Silverlight, во Flex добавят в Gumbo.

В Flex 2|3 это также легко реализуется, как в коде так и с использованием MXML

Реализация MVC
Flex Framework и есть реалиация MVC просто она скрыта от глаз программистов. Поэтому они не разобравшись пугаються и пытаюстся насочинять своих фреймворков ).
А насочиняли их уже много Cairngorm/PureMVC/Mate/Guasax/Model-Glue… и так далее.

Вроде пока все, что пришло на ум.

Поэтому я бы не спешил делать такие опрометчивые выводы, незная не платформы, и незная текущего состояния вещей.
В скором вермени (2009 год) Adobe ух как пошатнет преимущества разработки под сильверлайт, И я бы не стал говорить, что “с точки зрения удобства для разработчика “серебренный свет” уже вне досегаемости”.

Единственными весомым преимуществами Silverlight является:
- большее количество “тяжолых” разработчиков, которые прошли огонь и воду в програмирование под C# и т.д. В отличаии от разработчиков Flex которые в большей части работали во Флеш
- политика отношения Microsoft к разработчикам, ее тактика “Мы везде и никто кроме нас)”. Обучение, бонусы и т.д.

ЗЫ
Неосвещенным остался вопрос производительности, но это тема для отдельного большого исследования.
Как показывает практика FlashPlayer быстрее в графике, как не крути, нельзя сказать что намного, но все же приятно

Сегодня в сети появилась статья “Еще одно сравнение Adobe Flash и Silverlight 2″ , прочитав ее я понял главную ошибку авторов этих статей — каждый автор является специалистом только в одной области, или Flash|Flex или Silverlight. Поэтому страдают “конкурирующие платформы”. Как выход я вижу написание совместной статьи (но это дело долгих споров). Автор данной статья не избежал ошибок и показал всое поверхностное знание Flex/Flash технологии.

Я попытаюсь исправить его недочеты, для полноты картины )

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

Среда разработки и прочий инструментарий.

Для начала разберемся с инструментраем и возможностями:

FlashPlayer — это плагин который позволяет проигрывать swf файлы (байт код, который можно создавать где и как угодно, например умельцы рантайм генерят его и сразу же запускают в флешплеере).
Flash IDE/Flex Builder — это среда позволяющая создавать swf файлы.
Flex framework — это фреймворк позволяющий быстро и эффективно создавать RIA приложения. Flex Builder “заточен” для работы с Flex framework.

Использование Flash IDE как средство разработки крупных приложений, довольно опрометчивый шаг. Ее, в контекте разработы RIA лучше использовать как дополнительное средство.

Вообще не стоит говорить что вся разработка сводится к связку Flash IDE(графика)-Flex(код) — это просто частный случай варианта разработки.

а использовать только Flex сложно, поскольку ничего похожего на дизайн-вью в нем просто нет.

Ляп! пожалуйста, жмем на кнопку Design в MXML редакторе и видим дизайн вью. (единственно что он не работает в билдере под линукс). Может канечно этот дизайн вью и не такой навороченый как бленд, но он есть )

Язык программирования

ActionScript 3 являеться вариантом реализации ECMAScript-262, 4 версии http://en.wikipedia.org/wiki/ECMAScript , Я не буду искать подробности отличая от этого стандарта, они есть и это можно найти воспользовавшись гуглом ).

Язык не имеет …

Да язык часто ругают за его непродвинутость.

Язык не имеет встроенной событийной модели

но это вот ляп, событийная модель является главной фичей флешплеера 9 и выше.
– кстате автор нигде не учитывал возможности флешплеера 10 ) который уже вышел в релиз.

Отдельной строкой хочется сказать об отладчике.
Если во Flex Builder он еще куда ни шло, то во Flash им просто невозможно пользоваться – основным методом отладки до сих пор является trace.

При разработке крупных проектов боже вас упаси использовать и дебажить во Flash IDE! вы же не будете дебажить в Blend’e

Поддержка ОС и браузеров:
А что есть нормальная(официальная) поддержка Linux? Как мне поница Moonlight дорос пока только до версии 1. вобщем то до релиза далеко.
К том же плеер более стабилен в различных системах. (мне порой приходится перегружать барузер или запускать ИЕ чтобы посмотреть приложение на Silverlight, Маководы жалуются что не всегда получается поставить плагин)

Возможность упаковки в исполняемый файл:

Стоит учитывать что есть продукты сторонних производителей которые позволяют делать испольняемые файлвы из флеш/флекс приложений, причем под разные платформы (например Zinс)

Изображения:
JPEG, GIF, PNG — флеш с этим работает на лету. Вектор, у флеша это в крови. Кроме того, что можно импортировать ai,пдф файлы автор забыли о поддержке SVG графики. Причем уже есть библиотреки позволяющие использовать ее рантайм. (Например degrafa http://www.degrafa.com/2007/07/27/how-complex-can-you-get-with-degrafa-very/).
Также можно реализовать поддержку практичеки любого формата графики (ByteArray+Bitmap+Drawing API).
Про скорость отрисовки я бы вообще ничего не говорил, как не крути у флешплеера она больше.
А проблемы подготовки графики это уже проблемы кривых рук.

Видео:
flv это хорошее сжатие, но и возможность лайфстриминга, перемотки и других фич
из коментариев:
+ есть поддержка HD video
Флешплеер это тоже поддерживает.
+ теоретически, поддержку flv можно реализовать самому, используя MediaStreamSource (тут есть примеры http://code.msdn.microsoft.com/ManagedMediaHelpers)
нужна практика а не теория, хотя такой возможностью флеш не может покак порадовать.
Как не крути пока приоритет на стороне флеша

Шрифты:

Имеет три встроенных шрифта, поддерживается импорт символов из шрифтов ТТF, ограниченно поддерживаются шрифты, установленные в системе.

просто глупость.
Мы можем влючить любой шрифт в наше приложение, и он будет работать везде.
3 шрифта, тоже глупость, Просто по умолчанию флекс компоненты используют заданые шрифты, и нечего более.

Формально, не импортированные шрифты поддерживаются. Однако, с текстом, напечатанным таким шрифтом, почти ничего нельзя делать: ни поворачивать, ни масштабировать, ни использовать в качестве маски.

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

Сокеты:
незнаю что твориться в Silverlight, но в FlashPlayer к сожелению имеет некоторые ограничения

Работа с файлами:
Принципиальное преисущество было у Silverlight до выхода 10 версии флешплеера, теперь его нет ).

Хранение данных на клиенте:
хе хе пункту просто не зачет. никак не может влиять на оценку платформы.

Разметка:
Спорный вопрос. Я бы не ставил плюса ни одной из технологий.
Если говорить о скором будующем то будет революция Ключевое слово Flash Catalyst

«Программное» рисование:
Незнаю как обстоят дела в Silverlight, но во флеш им можно творить чудеса.

«Программная» анимация:

Flash/Flex: Основана на фрэймах.

Никто не мешает использовать верменные интервалы. т.е. больше возможностей ).
Я не спец в этой области и пусть те кто работают с FlashCS3|CS4 добавят свои коменты. ).

Собственные контролы:
Автор описал только один, довольно причудливый способ :).
Да. Визуально не всегда сразу можно посмотреть на внешний вид компонента.
Опять же для спора и нахождения истены в данном вопросе нужно сначало определиться с понятием “Собственный контрол”.

Кастомизация контролов
Я незнаю как работают стили в WPF, но

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

Полный бред. Для начала ознакомтесь с возможностями стилировния, затем полистайте примеры на той же Деграфе. Стили во флексе ограничиваются только фантазией, как только она закончилась, так и закончились стили )

Связывание данных

Да, во Flex не создается как таковой объект биндинга

Он то создаеться, но вот доступа мы к нему не имеем. Также есть возможность создать биндинг в коде BindingUtils

А двусторонний биндинг, единственный пока что козырь Silverlight, во Flex добавят в Gumbo.

В Flex 2|3 это также легко реализуется, как в коде так и с использованием MXML

Реализация MVC
Flex Framework и есть реалиация MVC просто она скрыта от глаз программистов. Поэтому они не разобравшись пугаються и пытаюстся насочинять своих фреймворков ).
А насочиняли их уже много Cairngorm/PureMVC/Mate/Guasax/Model-Glue… и так далее.

Вроде пока все, что пришло на ум.

Поэтому я бы не спешил делать такие опрометчивые выводы, незная не платформы, и незная текущего состояния вещей.
В скором вермени (2009 год) Adobe ух как пошатнет преимущества разработки под сильверлайт, И я бы не стал говорить, что “с точки зрения удобства для разработчика “серебренный свет” уже вне досегаемости”.

Единственными весомым преимуществами Silverlight является:
- большее количество “тяжолых” разработчиков, которые прошли огонь и воду в програмирование под C# и т.д. В отличаии от разработчиков Flex которые в большей части работали во Флеш
- политика отношения Microsoft к разработчикам, ее тактика “Мы везде и никто кроме нас)”. Обучение, бонусы и т.д.

ЗЫ
Неосвещенным остался вопрос производительности, но это тема для отдельного большого исследования.
Как показывает практика FlashPlayer быстрее в графике, как не крути, нельзя сказать что намного, но все же приятно

Сегодня в сети появилась статья “Еще одно сравнение Adobe Flash и Silverlight 2″ , прочитав ее я понял главную ошибку авторов этих статей — каждый автор является специалистом только в одной области, или Flash|Flex или Silverlight. Поэтому страдают “конкурирующие платформы”. Как выход я вижу написание совместной статьи (но это дело долгих споров). Автор данной статья не избежал ошибок и показал всое поверхностное знание Flex/Flash технологии.

Я попытаюсь исправить его недочеты, для полноты картины )

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

Среда разработки и прочий инструментарий.

Для начала разберемся с инструментраем и возможностями:

FlashPlayer — это плагин который позволяет проигрывать swf файлы (байт код, который можно создавать где и как угодно, например умельцы рантайм генерят его и сразу же запускают в флешплеере).
Flash IDE/Flex Builder — это среда позволяющая создавать swf файлы.
Flex framework — это фреймворк позволяющий быстро и эффективно создавать RIA приложения. Flex Builder “заточен” для работы с Flex framework.

Использование Flash IDE как средство разработки крупных приложений, довольно опрометчивый шаг. Ее, в контекте разработы RIA лучше использовать как дополнительное средство.

Вообще не стоит говорить что вся разработка сводится к связку Flash IDE(графика)-Flex(код) — это просто частный случай варианта разработки.

а использовать только Flex сложно, поскольку ничего похожего на дизайн-вью в нем просто нет.

Ляп! пожалуйста, жмем на кнопку Design в MXML редакторе и видим дизайн вью. (единственно что он не работает в билдере под линукс). Может канечно этот дизайн вью и не такой навороченый как бленд, но он есть )

Язык программирования

ActionScript 3 являеться вариантом реализации ECMAScript-262, 4 версии http://en.wikipedia.org/wiki/ECMAScript , Я не буду искать подробности отличая от этого стандарта, они есть и это можно найти воспользовавшись гуглом ).

Язык не имеет …

Да язык часто ругают за его непродвинутость.

Язык не имеет встроенной событийной модели

но это вот ляп, событийная модель является главной фичей флешплеера 9 и выше.
– кстате автор нигде не учитывал возможности флешплеера 10 ) который уже вышел в релиз.

Отдельной строкой хочется сказать об отладчике.
Если во Flex Builder он еще куда ни шло, то во Flash им просто невозможно пользоваться – основным методом отладки до сих пор является trace.

При разработке крупных проектов боже вас упаси использовать и дебажить во Flash IDE! вы же не будете дебажить в Blend’e

Поддержка ОС и браузеров:
А что есть нормальная(официальная) поддержка Linux? Как мне поница Moonlight дорос пока только до версии 1. вобщем то до релиза далеко.
К том же плеер более стабилен в различных системах. (мне порой приходится перегружать барузер или запускать ИЕ чтобы посмотреть приложение на Silverlight, Маководы жалуются что не всегда получается поставить плагин)

Возможность упаковки в исполняемый файл:

Стоит учитывать что есть продукты сторонних производителей которые позволяют делать испольняемые файлвы из флеш/флекс приложений, причем под разные платформы (например Zinс)

Изображения:
JPEG, GIF, PNG — флеш с этим работает на лету. Вектор, у флеша это в крови. Кроме того, что можно импортировать ai,пдф файлы автор забыли о поддержке SVG графики. Причем уже есть библиотреки позволяющие использовать ее рантайм. (Например degrafa http://www.degrafa.com/2007/07/27/how-complex-can-you-get-with-degrafa-very/).
Также можно реализовать поддержку практичеки любого формата графики (ByteArray+Bitmap+Drawing API).
Про скорость отрисовки я бы вообще ничего не говорил, как не крути у флешплеера она больше.
А проблемы подготовки графики это уже проблемы кривых рук.

Видео:
flv это хорошее сжатие, но и возможность лайфстриминга, перемотки и других фич
из коментариев:
+ есть поддержка HD video
Флешплеер это тоже поддерживает.
+ теоретически, поддержку flv можно реализовать самому, используя MediaStreamSource (тут есть примеры http://code.msdn.microsoft.com/ManagedMediaHelpers)
нужна практика а не теория, хотя такой возможностью флеш не может покак порадовать.
Как не крути пока приоритет на стороне флеша

Шрифты:

Имеет три встроенных шрифта, поддерживается импорт символов из шрифтов ТТF, ограниченно поддерживаются шрифты, установленные в системе.

просто глупость.
Мы можем влючить любой шрифт в наше приложение, и он будет работать везде.
3 шрифта, тоже глупость, Просто по умолчанию флекс компоненты используют заданые шрифты, и нечего более.

Формально, не импортированные шрифты поддерживаются. Однако, с текстом, напечатанным таким шрифтом, почти ничего нельзя делать: ни поворачивать, ни масштабировать, ни использовать в качестве маски.

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

Сокеты:
незнаю что твориться в Silverlight, но в FlashPlayer к сожелению имеет некоторые ограничения

Работа с файлами:
Принципиальное преисущество было у Silverlight до выхода 10 версии флешплеера, теперь его нет ).

Хранение данных на клиенте:
хе хе пункту просто не зачет. никак не может влиять на оценку платформы.

Разметка:
Спорный вопрос. Я бы не ставил плюса ни одной из технологий.
Если говорить о скором будующем то будет революция Ключевое слово Flash Catalyst

«Программное» рисование:
Незнаю как обстоят дела в Silverlight, но во флеш им можно творить чудеса.

«Программная» анимация:

Flash/Flex: Основана на фрэймах.

Никто не мешает использовать верменные интервалы. т.е. больше возможностей ).
Я не спец в этой области и пусть те кто работают с FlashCS3|CS4 добавят свои коменты. ).

Собственные контролы:
Автор описал только один, довольно причудливый способ :).
Да. Визуально не всегда сразу можно посмотреть на внешний вид компонента.
Опять же для спора и нахождения истены в данном вопросе нужно сначало определиться с понятием “Собственный контрол”.

Кастомизация контролов
Я незнаю как работают стили в WPF, но

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

Полный бред. Для начала ознакомтесь с возможностями стилировния, затем полистайте примеры на той же Деграфе. Стили во флексе ограничиваются только фантазией, как только она закончилась, так и закончились стили )

Связывание данных

Да, во Flex не создается как таковой объект биндинга

Он то создаеться, но вот доступа мы к нему не имеем. Также есть возможность создать биндинг в коде BindingUtils

А двусторонний биндинг, единственный пока что козырь Silverlight, во Flex добавят в Gumbo.

В Flex 2|3 это также легко реализуется, как в коде так и с использованием MXML

Реализация MVC
Flex Framework и есть реалиация MVC просто она скрыта от глаз программистов. Поэтому они не разобравшись пугаються и пытаюстся насочинять своих фреймворков ).
А насочиняли их уже много Cairngorm/PureMVC/Mate/Guasax/Model-Glue… и так далее.

Вроде пока все, что пришло на ум.

Поэтому я бы не спешил делать такие опрометчивые выводы, незная не платформы, и незная текущего состояния вещей.
В скором вермени (2009 год) Adobe ух как пошатнет преимущества разработки под сильверлайт, И я бы не стал говорить, что “с точки зрения удобства для разработчика “серебренный свет” уже вне досегаемости”.

Единственными весомым преимуществами Silverlight является:
- большее количество “тяжолых” разработчиков, которые прошли огонь и воду в програмирование под C# и т.д. В отличаии от разработчиков Flex которые в большей части работали во Флеш
- политика отношения Microsoft к разработчикам, ее тактика “Мы везде и никто кроме нас)”. Обучение, бонусы и т.д.

ЗЫ
Неосвещенным остался вопрос производительности, но это тема для отдельного большого исследования.
Как показывает практика FlashPlayer быстрее в графике, как не крути, нельзя сказать что намного, но все же приятно

Вышел плагин к Visual Studio для создания Flex-приложений. Он называется Tofino Beta.

В этой бета-версии продукта уже есть отладчик с возможностью расставить точки останова как в AS3, так и в MXML, простая инсталляция (Flex SDK идет в составе плагина), поддержка SWC (в том числе в Object Browser'е). Правда, еще нет intellisense, но будет, а также будут добавлены средства интеграции Flex и .NET. Также в финальной версии производители обещают сохранить бесплатность продукта.

// узнал в .NET-блоге на habrahabr.ru от Павла Дмитриева

Как мы знаем, сегодня в США открывается Adobe MAX — ключевое событие, касаемое Flash-платформы и RIA-технологий от Adobe. Некоторым из русскоязычных читателей повезет, и они смогут попать на это событие (по крайней мере в декабре в Милане). Ну а остальным неудачникам (к коим я причисляю с полным правом и себя) останется лишь тихонько убить себя апстену.

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

• Thermo, инструмент для “бесшовного” взаимодействия разработчика и дизайнера, о котором мы уже писали, отменяется. Его не будет. Thermo умер Да здравствует Adobe Flash Catalyst!

  

  Говоря проще, инструмент сменил свое кодовое название на официальное. Публичная бета будет доступна в начале 2009-го года, но все посетители MAX’а получат ее раньше.

• Также посетители MAX’а получат билд Flex Builder 4, который может работать с Gumbo. В новой версии среды будут реализованы грандиозные фичи: генерация геттеров/сеттеров (уже есть с помощью Eclipse Monkey), генерация кода для событий (Илья Панин показывал на FlexCamp’е в Москве — опять Eclipse Monkey), новый Package Explorer и тултипы для ASDoc’ов, пользовательские шаблоны для MXML, ActionScript, и CSS. Шаблоны кода a la JDT там отсутствуют. Зато есть интеграция с Thermo Flash Catalyst. Также будет монитор сетевой активности для Flex-приложений и поддержка Flex Unit (вот это интересно!). Помимо всего обещают еще сильнее упростить создание CRUD для большого количества серверов и сервисов с помощью Client Data Management (CDM).
• Вышел Adobe AIR 1.5 для Mac и Windows. До конца года обещают для Linux. Он теперь использует новый, более производительный JavaScript-движок SquirrelFish. Среди новинок encrypted база данных для хранения приватной информации. Ну и то, чего мы ждали: поддержка новых возможностей Flash Player 10. AIR 1.5 доступен не только посетителям MAX’а, а всем. Причем уже сейчас.
• Предварительная версия Adobe Flash Player 10 для смартфонов, созданная в рамках Open Screen Project, также будет демонстрироваться на MAX’е.
• Adobe Flash Player 10 для 64-bit Linux.

Вся эта информация доступна в официальном пресс-релизе, посвященном MAX. Также можно прочитать новость в блоге InsideRIA.

Хочу еще также заметить, что если есть крупные конкуренты, то все новости обычно ходят парами. Мы это уже замечали при выходе Flash Player 10 на следующий день после выхода Silverlight 2. Сегодня тоже не преминули отметиться сотрудники Microsoft. Скотт Гатри написал в своем весьма авторитетном блоге пост, посвященный Silverlight 3 и не только.

Что хочется отметить?

• Silverlight 2 вышел месяц назад и победно шествует по планете. Он загружен уже более чем на 100 миллионов машин пользователей, в чем ему помогают программы Microsoft SMS и Microsoft Update, позволяющие системным администраторам легко устанавливать среду исполнения для большого количества пользователей в корпоративных сетях.

  Скотт Гатри таже отметил, что в результате всего этого хоть какая-нибудь версия Silverlight стоит уже на каждом четвертом компьютере во Вселенной. Как видим, большой прогресс за месяц.

• С удовлетворением хочется отметить, что ересь от Microsoft, в результате которой термин RIA там стал расшифровываться как Rich Interactive Applications (насыщенные интерактивные приложения), а не как полагается Rich Internet Application (насыщенные интернет-приложения), долго не продержалась (подробнее об этом можно прочитать у Роста). Скотт Гатри уже упоминает Rich Internet Applications. Что, в общем, радует. Бессмысленная путаница терминов на пользу не идет.
• Silverlight 3 будет существенно расширен по части предоставления пользователю медиа-возможностей (например, кодек H.264), по части графических возможностей (заявлено 3D и аппаратная акселерация графики), расширения в области связывания данных (data binding), а также новые контролы. Скотт говорит, что в рукаве у них много чего еще (лично я готов подозревать поддержку камеры и микрофона, а также работу с битмапами). Visual Studio планирует обзавестись графическим дизайнером для разработки Silverlight-приложений.

Такие вот новости. А что у вас интересного?

Bookmark this article at …

Hезнание английского не освобождает от ответственности

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

Обзор документации и книг по Adobe Flex:

Официальную документацию по Flex 3/Flex Builder 3 от производителя можно найти на сайте адоба. http://www.adobe.com/support/documentation/en/flex/ Данная ссылка содержит большой список полезной документации, сделаем ее краткий обзор:

Первых 4 ссылки содержит документы описывающие установку флекс билдера и описание его функциональности (для тех кто незнаком с Eclipse платформой или кто хочет обновить свои знания стоит почитать Using Adobe Flex Builder 3 http://livedocs.adobe.com/flex/3/using_fb_flex3.pdf )

Adobe Flex Language Reference — документация по ActionScript3 и Flex 3. Она также есть в хелпе, который поставляется вместе с Flex Builder 3.

Flex 3 Developer Guide — глобальный и полный мануал по флекс, о разработке флекс приложений. Полностью описаны возможности фреймворка. Примеры кода, работа с компонентами, общение с сервером. 1300+ страниц наполненных информацией.

Programming ActionScript 3.0 — мануал о программирование на ActionScript 3. Начиная от описания синтаксиса, заканчивая работой с принтером и видео. Советую ознакомиться вначале, если вы незнакомы с АС3.

Также там много полезных мануалов на все случаи программирования на флекс 3 (Скинование, создание собственных компонент, оптимизация приложений…) Документации выполнена очень качественно и ее очень много, для начала изучения и работы с Flex 3 ее должно хватить с головой!

В конце страницы есть ссылка на архив со всей документацией.

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

Книги о ActionScript 3 (я их не листал, а те что листал уже не помню и коментировать не буду):

• ActionScript 3.0 - Advanced Design Patterns (2006)
• ActionScript 3.0 - Bible (Wiley)
• ActionScript 3.0 - Design Patterns (OReilly.Jul.2007)
• ActionScript 3.0 - Essential (OReilly.Jun.2007)
• ActionScript 3.0 - Foundation Animation (FriendsofED.Apr.2007)
• ActionScript 3.0 - Foundation With Flash CS3 and Flex (FriendsofED)
• ActionScript 3.0 - Learning - A Beginners Guide (OReilly.Jan.2008)
• ActionScript 3.0 - Object.Oriented (FriendsofED.Jul.2007)
• ActionScript 3.0 - Programming
• ActionScript 3.0 - Using Components
• FriendsofED Foundation Flash CS3 Video
• OReilly.Learning.Flash.Media.Server.3.Mar.2008

Книги по программированию на Flex 2/3:

Learning Flex 3: Getting up to Speed with Rich Internet Applications
Веселая книжка по введению в разработку на Flex 3, обзор средств разработки, описание как их использовать, описание базовых вещей флекс-фреймворка, ничего сложного. Для новичка самое оно, чтобы получить представление о технологии и начать ее использовать.

Flex 3 - A Beginners Guide (McGraw.Hill.Mar.2008)
Первых 2 главы смело пропускаем (1. рассуждения на тему. 2. установка и настройка). Остальные можно смотреть через строчку. В книге дано краткое описание ActionScript3 и MXML. Очень кратко описаны возможности Flex 3 и Flex Builder 3. Книгу стоит почитать тем, кто только начинает свою работу с flex 3, больше ничего интересного в ней нет.

Flex 2 - Programming (OReilly)
Классика жанра. Немного теории о RIA, затем рассмотрены возможности ActionScript3 и Flex, много примеров кода и много картинок. То что она написана Flex 2 это не страшно. Я бы посоветовал ее как настольную книгу начинающего и продолжающего Flex-программиста.

The Essential Guide to Flex 2 with ActionScript 3.0 | The Essential Guide to Flex 3 (FriendsofED)
Что похожее на Flex 2 - Programming (OReilly), но как по мне хуже. Общий обзор возможностей Flex.

AdvancED Flex Application Development: Building Rich Media X
Вначале немного рассказывается о Flex и Веб 2.0, Чем флекс хорош для создания RIA. Затем авторы на примере создания социальной сети рассматривают возможности Flex. Книга интересна тем, что в ней по порядку рассматривается разработка большого проекта, от задумки, возможностей, выбора средств разработки до реализации как клиента, так и серверной части. Естественно, что клиента они делают на Flex, а в сервер строят на основе движка Drupal. Книгу стоит почитать для развития кругозора и понимания как создается RIA . Как справочник по Flex она сильно годится.

Flex 3 Cookbook: Code-Recipes, Tips, and Tricks for RIA Developers (OReilly.May.2008)
Список рецептов для Flex 3. Очень полезная книга, дает готовые решения большинства стандартных проблем, а также дает «отправные точки» для дальнейшего поиска. Советую держать ее под рукой.

Flex Solutions: Essential Techniques for Flex 2 and 3 Developers (FriendsofED)
Книга из разряда кукбуков, но если «Flex 3 – Cookbook» содержит советы о написании кода, то данная книга содержит еще советы и решения проблем связанных с настройками среды разработки. Все советы разложены по полочкам. Советую держать под рукой.

Foundation Flex for Developers (FriendsofED.Dec.2007)
Первая часть книги посвящена введению в флекс программирование. Вторая часть посвящена общению флекс приложений с сервером, используя ColdFusion, ASP.NET или PHP (как по мне довольно грустное описание так как все строиться на передаче ХМЛ, альтернативные способы, к сожалению, не рассмотрены). Третья часть посвящена работе LiveCycle Data Services (LCDS), ничего сказать не могу, опыта не имел и подробно не читал

Foundation Flex for Designers (FriendsofED.Jan.2008)
Книга о стилировании используя Flash, Photoshop, Illustrator и Fireworks и их интеграция с флекс. Использование дизайнер вью для создания приложения, форм, компонент. Ничего сказать немогу по поводу данной книги, мне не понравилась и нужна ли она дизайнерам ?

Данный список не является полным, книг по Flex 3 гораздо больше. При составлении я использовал только те книги копии которых я смог найти в сети (да простят меня их авторы)

Что же читать?

Читать нужно документацию от Адоба, она очень хорошая и охватывает практически все аспекты разработки РИА приложений используя Adobe Flex

В качестве старта для человека которому неведом мир Flex и ActionScript 3 советую начать изучение с прочтения книг:

Также полезно иметь под рукой Flex 3 Cookbook и Flex Solutions: Essential Techniques for Flex 2 and 3 Developers

После изучения этих книг, я думаю вы сможете уже сами продолжить свой путь в рядах флексеров! Удачи!

Жаркая дискуссия разгорелась в комментариях к скорому выходу книги "Adobe AIR" на русском. Я даже немного расстроился (совсем немного): многие, кого я считал экспертами в области, не понимают, в чем соль (Соль (СОЛЬ)) технологии Adobe AIR. А Nox Noctis здорово объясняет, что и зачем. Присовокуплю к его словамм свои нескромные соображения.

Попробую объяснить, чем же так важен Adobe AIR. Я опущу все технические моменты: локальные БД и безопасное хранилище данных, доступ к файловой системе и драг-дропы, встроенный браузер и даже кроссплатформенность. Объясню сначала очень коротко:

Главное в Adobe AIR — это легкость его использования. Теми, для кого он сделан. Это же — главное в Microsoft Silverlight. Раскрою мысль ниже:

Было: хотели, но не могли!

Стало: хотим и можем!

Но что это за статья? Мало букв. Даешь больше понятных букв на эту тему, и чтобы со смыслом.

Adobe AIR = Microsoft Silverlight = укрепление существующих границ

Еще раз: как было два мира и как осталось два мира, изменившись

Оба мира жили по своим законам и развивались. Более молодой мир веб-программирования развивался последние 5 лет особо интенсивно, и ему было легко это делать, так как было из чего развиваться. Из детских игрушек веб-приложения перешли в ранг маркетинговых орудий.

Они развились настолько, что по эффективности стали конкурировать с настольными приложениями. Поэтому традиционным программистам захотелось тоже так уметь, как флэшеры. Но прибегать к помощи флэшеров унизительно! Это все равно как признать в дизайнере человека разумного. Поэтому программистам очень нужна была платформа для создания веб-приложений без участия флэшеров. Теперь у них есть Microsoft Silverlight, и я уверен, что они будут с ним счастливы.

А почувствовашие вкус серьезных проектов веб-разработчики в свою очередь тоже оказались готовы к покорению новой среды — десктопа. Через заведомо знакомый Adobe AIR.

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

Adobe AIR в 2008 — это как Macromedia Flash в 1998

Microsoft Silverlight делает похожее: радикально расширяет область производства веб-приложений, упрощая это для тех, кто раньше этого не делал, но имеет опыт в традиционных языках.

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

И в Adobe AIR, и в Microsoft Silverlight есть большой и важный смысл — они позволяют двум разным мирам программирования расширяться, а программистам — делать больше интересных проектов для новых сред.

В комментарях к новости об очень скором выходе книги по Adobe AIR на русском языке появились две важные ссылки. Из них я узнал, что в январе 2009 года выйдут две книги по Flex на русском.

Книга 1: Программирование c использованием Adobe Flex

Книга 2: Learning Flex 3

Вторая книга еще не анонсирована в русскоязычных магазинах, но о ее выходе сообщает Михаил Антипин, который знает, о чем говорит. Она называется "Learning Flex 3. Getting up to Speed with Rich Internet Applications. Вот превью книги Learning Flex 3 (74 стр.)

Я, скорее всего, куплю и ту, и другую — для сравнения и не только. Полезными могут оказаться обе. Не стоит скидывать книгу по Flex 2 со счетов. Мой опыт флекс-разработки показывает, что самое важное в изучении Flex — это не код, а базовые принципы построения приложения, архитектура. И если в книге по Flex 2 архитектурные вопросы показаны лучше, чем в книге по Flex 3, то есть смысл в ее прочтении, поскольку архитектура Flex 2-приложения не отличается от арихитектуры приложения Flex 3. Короче говоря, будет хорошо, если эти книги окажутся достаточно разными.

Как мы уже писали ранее, 30 октября 2008-го года в Подмосковье состоится очередная встреча Русскоязычной Группы Пользователей Платформы Adobe Flash (Russian Adobe Flash Platform User Group, RAFPUG), которая пройдет в выездном формате. Для тех, кто еще ничего по данному вопросу не решил, предлагается небольшой FAQ.

Правильно ли я понимаю, что мероприятие это очень дорогое и платное?
Нет, вы понимаете неправильно. Мероприятие бесплатное.

Правильно ли я понимаю, что если я флэшер, то мне там попросту неинтересно?
И это неверно. Хоть мероприятие и называется FlexCamp, на нем будут доклады и по AIR, и многое другое. А также неформальное общение на любые интересные (и не очень) темы.

Правильно ли я понимаю, что если я не имею отношения к Flash-платформе, то мне лучше не приходить?
Ну а сам(а)-то ты как думаешь? Добро пожаловать в секту!

Правильно ли я понимаю, что добираться придется самостоятельно?
А вот это понято правильно! Едем до базы отдыха «Спутник» своим ходом.

Правильно ли я понимаю, что программа мероприятия еще неизвестна?
Все совсем не так. Программа известна, и она примерно такова:

1. 11:00 - 12:00
   Serge Jespers
   «Up close and personal with the AIR API’s»

   О чем:
   By showing code snippets and real life applications, you will learn about all the API’s available in AIR and how to use them.

2. 12:00 - 13:00
   Костантин Ковалёв aka Constantiner
   «Microsoft Silverlight и Adobe Flex: технологии для создания насыщенных интернет-приложений (RIA)»

   О чем:
   Доклад призван расширить кругозор Flex/Flash-разработчиков в области технологий для созданич насыщенных интернет-приложений (Rich Internet Applications, RIA). В нем будет дан обзор основных возможностей технологий Adobe Flex и Microsoft Silverlight в сравнительной форме, что дает лучшее представление. Будут рассмотрены краткая история технологий, особенности процесса разработки, доступный инструментарий, доставка приложений пользователю, а также сходство и различие в области API, взаимодействия с браузером, сетевого взаимодействия, медийных возможностей, программной модели, производительности, набора предоставляемых контролов и контейнеров. Более детально будут рассмотрены наиболее интересные “вкусности” (data binding, кастомизация приложений, работа с XML). Помимо этого будут показаны примеры взаимодействия Flash- и Silverlight-приложений, а также пример реализации приложения с использованием обоих технологий.

3. 13:00 - 13:30
   Dennis Khvostionov
   «Degrafa Framework»

   О чем:
   Short introduction to Degrafa - declarative graphics framework for Flex that allows for drawing graphics via MXML markup.

4. 13:30 - 14:30
   Товарищеский обед
5. 14:30 - 15:50
   Минигольф, теннис, медитация и прочие массовые удовольствия

6. 15:50 - 16:00
   Антон Волков
   «Видеотрансляция: привет из Перми»

   О чем:
   Новости Альтернативы 3D

7. 16:00 - 17:00
   Иван Дембицкий aka iv и Евгений Потапенко aka John
   «Плагинная архитектура Flash-приложения.»

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

8. 17:00 - 17:45
   Илья Панин
   «Eclipse Monkey - расширяем функционал Flex Builder»

   О чем:
   Eclipce Monkey – это плагин к Eclipse позволяющий писать рассширения к нему используя JavaScript (также Ruby, Python и Groove). В докладе рассказывается о применении Eclipse Monkey для рассширения и добавление функционала для Flex Builder.

9. 17:45 - 18:30
   Александр Гахов
   «Тестирование Flex UI, с помощью инструмента Flexmonkey»

   О чем:
   Доклад коснется таких тем как FlexUnitTests, Automation, на примере работы с инструментом тестирования Flexmonkey.

10. 18:30 - 19:30
    Товарищеский ужин

11. 19:30 - 20:00
    Артемий Малков
    «Круглый стол по Adobe Flex/Flash»

    О чем:
    Усыпляющее обсуждение технологий Flash platform плавно переходящее в …

12. 20:00 - …
    afterParty

Уже круто! Но ведь четверг — это рабочий день!
Не совсем так. Для тех, кто будет присутствовать на мероприятии, этот день рабочим не будет.

Ну вот я думал-думал и решил принять участие. Что мне для этого нужно?
Нужно поскорее послать регистрационную заявку на rafpug [dog] gmail.com. И как можно скорее! Подмосковье не резиновое! На всех мест не хватит!

Где я могу прочитать дополнительную информацию?
Тут.

Ну, вроде, пока информации достаточно.

Пару слов про мой доклад. Как было сказано, его цель — расширить кругозор Flex/Flash-разработчиков. На самом деле у этого доклада есть симметричный собрат, который призван расширить кругозор .NET-разработчиков. И будет он прочитан на следующий день, 31 октября на Silverlight Day в рамках встречи Питерской .NET User Group. Так что желающие могут сходить еще и туда Подробности в блоге Сергея Жихарева.

Так что увидимся

Bookmark this article at …

, если вы читаете цикл из пяти ясных статей "Рассудочное познание itemRenderer во Flex" в Adobe Flex Developer Center. Автор — Питер Энт из Adobe. Он последовательно излагает жизненно важные концепции и популярные ошибки в использовании рендереров. Познавая цикл рассудком, вы быстро поймете, почему оказался неэффективным метод панического клика, который, увы, многие применяют столь же упорно, сколь и безуспешно — снова и снова (сам не безгрешен, каюсь).

Станет ясно, что многие часы, проведенные в попытках заставить строку датагрида светиться зеленым, могли быть минутами пользы и удовольствия, потому что работать с рендерерами действительно легко, как только вы поймете главную мысль: не нужно пытаться управлять рендерером снаружи. Рендерер невозможно удержать в руках. Рендерера не существует, ясно? Только сам рендерер может управлять собой изнутри, основываясь на своих данных (или на данных родительского компонента).

Читайте Питера Энта. Понятнее чем он, на эту тему не писали. Итак, все пять частей:

1. Часть первая: встроенные рендереры.
2. Часть вторая: внешние рендереры.

   А где еще три части — спросит самый внимательный читатель? Ждите! Остальные части появятся в Adobe Developer Center совсем скоро. Не хотите ждать? Читайте прямо в блоге Питера Энта, они еще с марта и ждут очереди:

3. Часть 3: как законтачить с рендерером.
4. Часть 4: состояния, переходы и эффекты в рендерерах.
5. Часть 5: эффективные рендереры.

Усвоив это интеллектуальное наследие от Питера Энта, человека, ответившего на тысячи вопросов по Flex начиная с версии Flex 1 (он действительно работал в поддержке Flex, а теперь перешел в новый биг-бизнес-проект Genesis от Adobe), вы можете немного расстроиться: столько времени было потеряно зря в попытках брутфорс-атак на непокорные рендереры, когда достачно было силы мысли! Но вы не расстраивайтесь: ведь теперь-то вы все про них знаете и сможете ими управлять как только захотите.

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

Кстати, поскольку Питер Энт теперь за Флекс официально не отвечает, самое время прочесть его блог как в некотором смысле завершенный учебник по Flex.

"Resolved: (IDEADEV-14365) Flex 2 (ActionScript + MXML) support in IDEA" — такой статус теперь имеет заказанная еще Майклом Клишиным поддержка Flex-разработки в IntelliJ IDEA. 2 октября Дмитрий Жемеров написал, что поддержка Flex в IDEA реализована; багрепорты по конкретным моментам и запросы новой функциональности размещайте отдельно.

Как в IDEA выглядит Flex/JavaScript-дебаггер, можно увидеть на скриншотах и видео. Вот - официальный текст о поддержке редактирования Flex-кода. А вообще поддержке JavaScript и Flex в IDEA посвящена отдельная страница и немалая выдача в поиске.

FDT опасносте! Проверим?

Ниже в посте выражалось возмущение при упоминаниии о том, что многие мечтают работать в харьковской компании TeamDev. Открою завесу тайны: TeamDev участвует в создании IntelliJ IDEA от JetBrains и MyEclipse от Genuitec. JetBrains рекомендует продукты TeamDev. И сейчас TeamDev ищет Flex-разработчика в Харькове. Обратите внимание.

Пример приложения использующая исходники можно найти на сайте http://www.graviti.tv/blog/?p=46 (и http://www.graviti.tv/blog/?p=75 )

Но статья не о том как сделать кастомный хром, а неверном решении индийцев из адоб.

У кастомного хрома, как и у FlexChrome (showFlexChrome=”true”) есть проблемка, при максимайзе приложения оно выступает на 3 пиксела за экран во все стороны. При showFlexChrome=”true” как раз прячется скругление заголовка окна. Великолепный ход конем! :). При showFlexChrome=”true” это еще простительно, а вот когда у вас полностью свой кастом хром, то получается ужастно.

Как побороть это нормально я не нашел, пошел по простому выходу, вставил все приложение в отдельный компонент, а его сделал меньше текущего хрома ровно на 3 пх с каждой стороны)

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
			showFlexChrome="false"
			showStatusBar="false"
			showGripper="true"
			showTitleBar="false"
			width="700" height="500" frameRate="45"
			horizontalScrollPolicy="off" verticalScrollPolicy="off"
			xmlns:local="*"
			>
	<local:AIRApplicationContent 	width="{width-6}"
					height="{height-6}"
					x="{3}" y="{3}"
					filters="{[new DropShadowFilter(4,45,0,0.5)]}"
					/>
</mx:WindowedApplication>

В качестве бонуса получил использование тени от окна не сильно напрягаясь

Как обещал вчера, расскажу о новом (и похоже, пока единственном, зато каком!) плагине к Flex Builder. Плагин называется Enterprise IDE Plugin™. Разработчик: компания IDE Factory.

Enterprise IDE Plugin — это набор инструментов для архитекторов, разработчиков и менеджеров проектов, созданный для упрощения разработки приложений в среде Adobe Flex Builder 3. Плагин Enterprise IDE в данный момент выходит в публичный, ограниченный по времени beta-релиз.

Плагин Enterprise IDE не заменяет и не вытесняет Flex Builder, но скорее наращивает его мощность. С помощью инструментов повышения производительности и встроенной поддержки основных open-source фреймворков для Flex и ActionScript, Enterprise IDE превращает Flex Builder в исключительную среду разработки приложений enterprise-уровня. Он включает в себя новые инструменты для навигации по коду, генераторы проектов, классов и методов, средства автоформатирования, документирования и создания метрик кода, а также инструменты общего назначения для повышения продуктивности Flex-разработчиков и архитекторов.

Перечень инструментов и функций Enterprise IDE Plugin

Почти за каждой ссылкой находятся иллюстрации, подобные нижеследующей:

• Навигация по коду

• Перспектива Enterprise IDE. Открывается из меню. Обратите внимание на все пункты:
  
  
  
  
• Вид Flex Package Explorer.
• Вид Flex Hierarchy Explorer.
• Метрики кода: Flex Code Metrics Explorer.
• Зависимости кода: Flex Code Dependency Explorer.
• Вид Cairngorm Explorer.

• Генераторы кода

• Улучшенные мастера создания AS3, MXML, и Cairngorm-файлов. Переменные и функции можно задавать через интерфейс Мастера.
• Генераторы тестов FlexUnit и test suite (для проекта или класса).
• Создание AS3-кода по из UML-модели.
• Генераторы Cairngorm end-to-end-классов для REST, Web Service (WSDL) и Remoting (поддерживаются множественные версии Cairngorm).
• Генераторы геттеров и сеттеров для существующих AS3-переменных.
• Генераторы Java Value Object из Cairngorm VOs.
• Генераторы интерактивных приложений для тестирования Flex Cairngorm service и графического движка FlexUnit-тестов.

• Документирование кода

• Генерирование UML-модели по AS3-классам Flex-проекта.
• Создание ASDoc-документации одним кликом.

• Инструменты общего назначения

• Редактор и построитель e4x-выражений.
• Настраиваемое автоформатирование AS3 и MXML кода (для всего проекта или для одного исходного файла).
• Настройки в диалоге Eclipse Enterprise Preferences.
• Интегрированные TODO и FIXME задачи для AS3 и MXML.
• Встроенная в Eclipse Help справка.
• Flex RSS Feed Reader.

Планируемые улучшения в Enterprise IDE Plugin

• Поддержка фреймворка PureMVC.
• Инструмент Flex Code Coverage Explorer (что такое Code Coverage).
• Шаблоны кода.
• Поддержка фреймворка VisualFlexUnit.
• Поддержка фреймворка Prana.
• Формы редактирования файлов конфигурации Flex-проектов.
• Задачи Ant для сбора метрик проекта и форматирования кода.

Источник: трекер IDE Factory.

Ссылки по Enterprise IDE Plugin

• Как установить Enterprise IDE Plugin
• Руководство пользователя Enterprise IDE
• Матрица Enterprise IDE Features (со ссылками)
• Форум на сайте IDE Factory
• Багтрекер Mantis. Пишите отчеты и требуйте улучшений!

Установил, работает.

Как известно, технология Adobe AIR позволяет создавать полноценные десктопные приложения и поддерживает эту возможность соответствующими классами и методами. В частности, есть полный набор функций для управления системными окнами: их положением, порядком сортировки и т.д.

Например, для того, чтобы установить окно поверх остальных, используется метод orderToFront(). Однако я наткнулся то ли на баг, то ли на фичу этого метода: если другое окно получило фокус от мыши, то ваше окно поверх остальных не всплывет. Хотя при этом активизируется: фокус получит и будет призывно подмигивать в панели задач.

Затем я нашел и способ обхода этой неприятности, используя свойство окна alwaysInFront, и уйдя от использования orderToFront(). Сначала окно переводится в состояние "поверх всех" (alwaysInFront = true), затем активизируется, и, если было минимизировано, то восстанавливается; затем возвращается в состояние "не поверх всех" (alwaysInFront = false). Вот что получилось:

<?xml version="1.0" encoding="utf-8"?>

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

<mx:creationComplete>

    flash.utils.setTimeout(activateWindow, 2000);

    function activateWindow(): void

    {

        alwaysInFront = true;

        nativeWindow.activate();

        if(nativeWindow.displayState == NativeWindowDisplayState.MINIMIZED)

        {

    	    nativeWindow.restore();

        }

        alwaysInFront = false;

    }

</mx:creationComplete>

</mx:WindowedApplication>

Таким образом, все работает! Но меня гложут сомнения: а что если я просто не умею это готовить? Если знаете ответ — подскажите, можно ли обойтись без хака с alwaysInFront = true?

Предисловие

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

Введение

В данной статье я расскажу как собирать приложение которое использует flex modules.
Проект так же будет использовать библиотеки и уменьшать размер flex модулей. Для этого мы не будем включать в модуль код, который уже используется в основном приложении. Итак приступим.

Структура проекта

Данная структура соответствует принципу один maven модуль один артефакт. Следовательно flex модуль представлен ввиде отдельного maven модуля.

flexModulesProject/
flexModulesProject/pom.xml - основной pom, собирающий весь проект
//загрузчик модульного приложения.
flexModulesProject/flexClient/… - основное flex приложение
…
flexModulesProject/flexModuleRed/… - flex модуль
…
flexModulesProject/flex/pom.xml - корневой pom для flex приложение.
flexModulesProject/flexCoreLib/… - flex библиотека которая используется в проекте.

Разбор конфигурационных файлов проекта

на родительский pom проекта, pom библиотеки и корневой pom для flex проектов использование модуля ни как не повлияло. Более подробное описание их структуры можно посмотреть здесь.

pom для flexClient

XML:

Здесь существенна одна дирректива:

XML:

данная строчка создает в maven репозитории xml файл с перечнем всех классов, которые включаются в данный swf. Этот перечень будет использоваться при копмиляции flex модуля.

pom для flexModuleRed

XML:

следующий код:

Code:

исключает классы которые включены в flex-client.

здесь:

Code:

важно включение библиотеки со scope external.

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

Сборока проекта.

Для сборки проекта необходимо в корневой библиотеке проекта запустить команду mvn install

Развертывание проекта.

Строго говоря, в обязанности maven эта задача не входит. После того как проект будет собран, нужно поместить flexModuleRed.swf в одну папку с flexClient.swf.

Исходники

Исходники можно взять отсюда

Bookmark this article at …

Недавно Андрей Микитюк задал мне простой вопрос — как отменить биндинг переменной во Flex? Честно говоря, я не смог ему ответить, зато он сам нашел готовый ответ в блоге одного из индийских Flex-евангелистов Raghunath Rao Thricovil, или просто — Raghu.

Тем, кто еще не в курсе, напомню: связывание, или биндинг данных (data binding) — одна из мощных фишек Флекса. Фишка в том, что переменная a связывается с переменной b и после этого значение a будет изменяться каждый раз, когда изменится значение b — они связаны (binded). Один из простейших примеров — текст, вводимый в поле ввода, автоматически появляется в другом месте приложения при вводе / удалении каждого нового символа. При грамотном применении биндинг позволяет сэкономить кучу кода и времени. Для начинающих (и не только) есть пара коротких уроков по биндингу — очень рекомендую.

А как отменить связывание переменнных?

Вообще, у Raghu весьма полезный блог.

Вся флексовая блогосфера в страшном волнении: совсем скоро (счет на часы) станет доступен (уже доступен) билд Flex 4 SDK (кодовое название Gumbo), который можно назвать нереволюционным словом “революционный".

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

Пока билд еще в пути, я не смог посмотреть на него внимательно. Но доступна документация, которая даже при беглом осмотре дает хорошее представление о том, что изменения не косметические (как между Flex 2 и 3), а меняющие картину в целом и заставляющие нас заново учить Flex.

Информация о новых States была доступна уже давно. Скажу прямо, очень вкусно.

Теперь же нас ждут коренные изменения в скинизации. Насколько я смог разглядеть, это будет больше похоже на WPF/Silverlight API по части того, что ряд компонентов будут иметь свойство content, позволяющее устанавливать не только текст, как раньше (например, в качестве title компонента Panel), но вообще произвольный объект, который и будет использоваться в случае если объект графический, либо будет использоваться Label с применением к контенту toString (). Также мы можем применять различные лэйауты, что позволит, например, легко и просто сделать List расположенным по кругу. Все это будет доступно также на уровне скинов.

Также будет добавлен язык разметки FXG (ранее именуемый MXML-G) для описания графических примитивов (например, <Rect>, <Ellipse>, <Path>). Этот язык может использоваться как в отдельных FXG-файлах, так и напрямую в MXML-разметке в качестве отдельного пространства имен. Этот формат оптимизирован под Flash Player 10 и инструмент Thermo.

По части совместимости. Новые компоненты будут наследоваться от того же самого UIComponent, но это будет отдельная ветка, которая, к тому же, будет нацелена на Flash PLayer 10. Таким образом, в Gumbo-приложениях можно будет совмещать использование Halo-компонент и Gumbo-компонент.

Также нас ждет двунаправленная привязка данных (Two way data binding).

Вообще, данный релиз делает Flex-фрэймворк, что называется, гораздо более flexible. То есть достигается немыслимая гибкость в кастомизации компонент, что позволит использовать ее в соответствующем инструментарии (Thermo) и улучшить тем самым designer/developer workflow и свободу выражения дизайнерской мысли как таковой.

Так что ждем появления SDK (а пока я это писал SDK 4.0.0.2480 уже появился), а пока читаем дополнительную информацию:

• Страница Gumbo, на которой есть презентации продукта, краткое описание фич, описание архитектуры и доступные спецификации.
• Сообщение блога Flex Team.
• Сообщение блога Flex Doc Team.

Думаю, что в ближайшее время нас ждет множество интересных материалов по этому поводу! Следите за блогами!

Bookmark this article at …

Друзья, вот что нас ждет на каждом дне международной встречи URAFPUG:

Возможны уточнения, изменения и пожелания — желайте! Также будем смотреть, как все пойдет и соответственно адаптировать программу.

В следующем посте — куда идти и что делать сразу по приезду на URAFPUG.

А ты — зарегистрировался на URAFPUG?

Разберу как собрать простой проект с помощью Flex Mojos.

Начальные условия

установленная java jdk 5 или выше.
переменная окружения JAVA_HOME
установленный maven.

Стандартная для maven структура проекта

project-name/pom.xml………………. конфигурационный файл сборки проекта.
project-name/src
project-name/src/main/
project-name/src/main/flex…………. код flex приложения
project-name/src/test
project-name/src/test/flex…………. тесты flex приложения
project-name/src/main/flex/Main.mxml

Структура pom.xml

pom собирающий flex приложение:

XML: