Новый плагин называется SourceMate. Стоит денег. 30 дней можно пощупать бесплатно. Ставится через Help > Install New Software -> Search for new features to install -> Next -> New remote site -> указываем url: http://updates.elementriver.com/sourcemate/v1 устанавливаем, щупаем.

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

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

Robotlegs это MVCS фремворк реализующий паттерн MVC с добавлением еще одного элемента – Services, использующегося для реализации взаимодействия с «внешним миром», будь то Web-сервисы, файловая система, базы данных, взаимодействие с другими Flash-приложениями через Local Connection и т.п.

Внедрение зависимостей (Dependency Injection)

Современные фреймворки, базирующиеся на паттерне MVC теми или иными способами поддерживают реализацию принципа Inversion of Control (Ioc) или Dependency Injections (DI). Robotlegs также основан на этом принципе.

Для чего нужно использование паттерна Dependency Injection? ООП приложение состоит из классов. Классы могут получать доступ к другим классам имея ссылки на них. Они взаимодействуют друг с другом, используя эти ссылки. Смысл Dependency Injection – уйти от высокой связанности приложения, заменив описание взаимодействия между конкретными классами на интерфейсы. Т.е. класс X будет использовать не класс Y а реализациею его интерфейса I. В результате мы получаем низко связанное приложение, классы которого знают только о интерфейсах для работы с другими классами. Например в приложении для работы с почтой мы будем работать с интерфейсом IMailLoader, вызывая метод load(), а не с конкретной реализацией класса IMAPMailLoader. В этом случае IMAPMailLoader будет легко заменить на POPMailLoader,реализующий интерфейс IMailLoader или на любой другой класс реализующий нужный интерфейс.

В Robotlegs DI реализован с помощью SwiftSuspenders. Это легковесный DI фреймворк для реализации этого паттерна посредством метатегов [Inject].

Работая с Robotlegs с классом наследуемом от Context (о нем я расскажу ниже) мы имеем доступ к переменной injector. Это экземпляр класса, реализующего функционал фреймворка SwiftSuspenders. injector – это менеджер внедряющий нужный экземпляр класса в классы нашего приложения.

Возвращаясь к примеру с почтовым сервисом реализация DI с помощью Robotlegs выглядит следующим образом:

Для того чтобы фреймворк внедрил то что мы описали выше, в нашем классе достаточно будет написать:

В результате переменная mailLoader будет содержать экземпляр класса IMAPMailLoader.

Если же мы напишем:

В нашем классе мы можем задать name, для инстанцирования нужной нам реализации:

В результате переменная mailLoader будет содержать экземпляр класса POPMailLoader.

Создавая карты с помощью injector можно также внедрять конкретные экземпляры классов (mapValue), классы «одиночки» (mapSingleton) и пр. Подробнее об этом написано в документации Robotlegs.

Немножко разобравшись с реализацией DI в Robotlegs перейдем к реализации MVCS архитектуры.

Контекст

Сердцем фреймворка Robotlegs является класс Context, от которого собственно и наследуется наш главный класс приложения. В этом классе задаются основные связи между компонентами приложения.

Карты команд

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

Карты отображения

Так же как и PureMVC в Robotlegs для взаимодействия с view-компонентами используются посредники, называемые медиаторами. View-компоненты и их медиаторы сопоставляются с помощью mediatorMap.

Интересной особенностью медиаторов является их автоматическое инстанцирование только в случае добавления view-компонента, связанного с этим медиатором, в список отображения,что впрочем можно отключить во время задания правила для mediatorMap. Существует еще и viewMap, о котором в официальной документации не сказано ничего, но насколько я понял он используется для «внедрения» view-компонентов в классах приложения, т.е. является полным аналогом прямого использования injector.

Карты внедрения (иньекций)

Здесь описываем все классы или их экземпляры, которые необходимо «внедрять» в классы нашего приложения посредством использования метатега [Inject]. В частности здесь мы описываем наши классы с данными и сервисами необходимыми для реализации MVCS:

Все классы описанные с помощью commandMap и mediatorMap автоматически подготавливаются фреймворком для «внедрения» в классы приложения.
Таким образом в нашем главном классе приложения перед запуском мы конфигурируем все необходимые компоненты и взаимодействия.

События

Для системы событий Robotlegs использует «родные» события Flash-плеера. Для их распространения внутри фреймворка используется следующий синтаксис:

Чтобы слушать события используется следующий синтаксис:

Либо как уже было сказано выше во время конфигурации приложения можно указать на какое событие должна запускаться та или иная команда:

Распространять и слушать события могут далеко не все фигуранты фреймворка. Кратко рассмотрим «Актёров» Robotlegs (MVCS).

Модель и сервисы (M и S)

Я позволю себе объединить описание этих двух составных частей фреймворка в одном месте, так как оба этих компонента должны наследоваться от класса Actor. Для фреймворка не имеет значение модель это или сервисы, это просто «Актер», наделить их функционалом должен уже разработчик.

Для того чтобы иметь доступ к модели или классу сервиса из других классов фреймворка достаточно будет написать [Inject] перед объявлением переменной. Например если класс с данными называется ApplicationModel, то в классе, где необходимо будет его использовать, достаточно написать:

Перед этим, естественно, нужно не забыть его добавить в карту внедрения, как это было указано выше.

Наследники класса Actor могут посылать события приложению используя метод dispatch.

Отображение (V)

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

Медиатор должен наследоваться от класса Mediator. Элемент отображения связанный с медиатором доступен в переменной viewComponent. Медиатор имеет доступ к dispatch() и eventMap, а это значит что он может как распространять так и слушать события внутри приложения.

Для инициализации медиатора крайне не рекомендуется пользоваться конструктором. Для этого существует метод onRegister(), который необходимо переопределить и писать код инициализации в нем.

Для доступа к модели достаточно внедрить класс модели с помощью метатега [Inject] , так как это было описано выше.

Контроллер (С)

Функционал контроллера реализуется в Robotlegs посредством вызова команд. Класс команды должен наследоваться от класса Command. Команда создается только на время выполнения и после выполнения попадает в Garbage Collector. Команда появляется как результат возникновения события. Код, который должен выполнить команда должен быть помещен внутри переопределенного метода execute(). Сопоставления команд событиям происходит в commandMap Контекста приложения. Тот же самый commandMap доступен и внутри любой из комманд.

Доступ к модели организуется так же как и в классах отображения.

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

Команда может также посылать события приложению используя метод dispatch.

Кратко резюмируя хотелось бы сказать что реализация Robotlegs действительно очень интересная и заслуживает внимания. В чем то она похожа на PureMVC, об этом же говорит и автор Robotlegs. Однако в Robotlegs иначе организована система событий, не нужно писать switch/case в обработчиках событий, как это реализовано в PureMVC. Достаточно подписаться на нужное событие и назначить метод обработчик, так как мы это привыкли делать со стандартными событиями Flash. По другому организовано и взаимодействие между компонентами приложения. В отличии от PureMVC в Robotlegs для доступа к другим компонентам приложения уже не используются retrieveProxy, retrieveMediator и т.п., а используется метатег [Inject].

Flashbug
Данное расширение позволяет увидеть все “трейсы” на новой панели “Flash Console” плагина Firebug. Плагин имеет “Policy log”, позволяющий увидеть лог сообщений безопасности Flash-плеера. Для открытого в данный момент ресурса также можно увидеть сохраненные Shared objects. Flashbug  так же дает возможность увидеть отсылаемые данные AMF в панели Net (Сеть):

AMF в Firebug

Для своей работы требует debug версии Flash-плеера.
На сайте автора можно подробнее почитать о расширении. Но почему то кажется что активность автора спала и доработку своего детища он отложил в долгий ящик. Будем надеяться на лучшее. Тем не менее это достойная замена FlashTracer’у, которым я пользовался до этого.

FireFlash
Посредством FireFlash Console API позволяет отображать  объекты, массивы, XML и другие данные через Firebug console. Очень удобное и мощное средство для дебага и логинга. Позволяет группировать выдаваемые сообщения, есть механизмы запуска и остановки таймера для определения времени работы скрипта. На сайте автора расширения есть подробное описание API, примеры и видео помогающее понять как это работает.

Разрабатываю свои проекты я под Windows, поэтому для отлавливания бага, проявляющегося только под MacOS пришлось заимствовать макбук.

Выяснилось что Flash-приложение открытое в любом из браузеров подвисает во время потери фокуса самим браузером (переключение на другое приложение). Причина зависания – в момент потери фокуса приложением, содержащим Flash-контент, на Stage флэшки приходит событие MOUSE_MOVE, содержащее какие-то немыслимые координаты курсора (x:-100500,y:-100500). Соответственно подвешенный на это событие обработчик, занимающийся отрисовкой шлейфа мыши, входил в безумно длинный цикл и Flash-приложение подвисало.

Еще раз повторюсь это происходит только под MacOS, под Windows “ложного” срабатывания MOUSE_MOVE не происходит.

Будьте внимательны при обработке данного события.

Lee Brimelow в одном из своих постов о том как сделать Flex удобнее рассказал как минимум о трёх вариантах подключения сниппетов.

Eclipse Monkey
О том что это за зверь, и как использовать Eclipse Monkey для сниппетов в частности, было написано здесь. И даже существует русскоязычный проект на GoogleCode, в котором предлагается складывать скрипты для Eclipse Monkey.

На этом видео, кстати, можно посмотреть насколько эффектно и эффективно можно  кодить, используя Eclipse Monkey.

Все в Eclipse Monkey хорошо и возможности (выходящие далеко за рамки создания сниппетов)  и большое количество уже готовых скриптов для него. Не хорошо только то, что для того чтобы реализовать что-то новое под Eclipse Monkey нужно кодить. На что может не хватать ни времени, ни желания. Ну и еще один недостаток – он не работает в mxml редакторе.

Snip Tree View
Данная панелька присутствует в плагине CFEclipse.  И позволяет используя заданную горячую клавишу превращать определенную последовательность символов в нужный разработчику кусок кода.

Устанавливается плагин CFEclipse через Help > Software Updates >Findand install… с сайта http://www.cfeclipse.org/update . Для того чтобы воспользоваться панелькой нужно зайти  Window > Other Views… Затем найти Snap Tree View в ветке CFML.
Горячую клавишу можно назначить зайдя в Windows > Prefernces… А далее как показано на рисунке:

Недостатков было найдено достаточно много:

• для работы плагина обязательно должна быть видна панель плагина с кнопками,  коих очень много:   Частично проблема решается замещением всех этих кнопок одной вот этой путем копирования содержимого архива в папку plugins. Остальные кнопки нужно убрать ручками через Customize Perspective…;
• не работает в mxml редакторе;
• функционал очень сильно ограничен. Можно задать только текст вставляемый ДО и ПОСЛЕ курсора.

WST Snippets Panel
Позволяет создать сложные шаблоны кода на основе указания необходимых переменных в появляющемся диалоговом окне.

Установить можно весь пакет Web Standart Tools, в состав которого входит эта панелька, через Help > Software Updates >Findand install…, далее выбрать Web Tools Platform (WTP) Updates, затем через Europa Discovery Site найти и поставить пакет WST и все от чего он зависит.  А можно сделать проще – просто кинуть в папку plugins этот файлик.

После установки панель можно найти в Window > Other Views…, далее General > Snippets
Создавать шаблоны кода в этой панели несложно. На рисунке показан созданный мною шаблон кода для генерации геттеров и сеттеров:

Теперь для того чтобы вставить шаблон в код необходимо дважды кликнуть по необходимому шаблону в панели Snippets и в появившемся окне указать PROPERTY_NAME и PROPERTY_TYPE:

Недостатки тоже присутствуют:

• нету горячих клавиш. Вставлять шаблоны можно только с помощью клика мыши;
• при вставке шаблона не учитывает  первоначальные табы, поэтому после вставки код приходится двигать.

Компания Adobe выпустила тестовую версию компилятора alchemy, предназначенного для сборки программ, написанных на языках Си и Си++, в байткод AS3, пригодный для выполнения в виртуальной машине ActionScript Virtual Machine (AVM2). Результатом сборки является SWF или SWC файл, пригодный для выполнения в Flash Player 10 или Adobe AIR 1.5. Разработка базируется на использовании открытого компилятора LLVM (Low Level Virtual Machine).

Основная цель проекта alchemy – разработка на языке Си/Си++ универсальных библиотек функций, с реализацией требующих интенсивных вычислений операций, таких как кодирование аудио/видео, преобразование данных, парсинг XML, криптографические операции, симулирование физических процессов. При написании таких библиотек на языке Си/Си++ производительность, при выполнении в виртуальной машине AVM2 будет значительно выше, чем при их реализации на ActionScript 3.0, но все же в 2-10 раз медленнее чем при станратной компиляции в машинный код.

Для работы программ доступен POSIX совместимый API, а также специальная мультимедийная библиотека, предоставляющая интерфейс к функциям технологии Flash. Для прямого доступа к памяти из Си программ, был разработан специальный режим эмуляции, осуществляющий маппинг блоков памяти внутри VM, немного замедляющий работу программ. Исходные тексты новой системы планируется представить под одной из открытых лицензий. В настоящее время представлены только бинарные сборки alchemy для Linux, Mac OS X и Windows.

Принцип работы компилятора:

• При помощи LLVM, Си программа преобразуется в набор инструкций для абстрактной виртуальной машины;
• LLVM инструкции преобразуются в объектный код, специфичный для виртуальной машины, выполняющей ActionScript;
• ActionScript автоматически компилируется в байткод пригодный для запуска в Adobe Flash. Байткод в дальнейшем может быть преобразован в машинные инструкции при помощи JIT-компилятора из состава проекта Tamarin.

Первый раз технология была представлена в прошлом году на выставке MAX 2007, тогда специалисты из Adobe продемонстрировали выполнения игры Quake в окне браузера. Позднее для выполнения в виртуальной машине Flash удалось адаптировать интерпретаторы языков программирования Python, Lua, Ruby,Perl и эмулятор платформы Nintendo.

Здесь документация.

API здесь