Всякие разные штуки сомнительной полезности сделанные в свободное от работы время.
MXML без фреймворка!
Продолжая тему, сделал небольшую демку с использованием MXML компонентов построенных не на базе UIComponent. Ниже приведенный код реализует самые базовые возможности <mx:DataGrid/>. Конечно, он гораздо меньше чего может, зато скомпилированый в "дебаг" режиме весит всеро 13К, а в "релиз" режиме - так вообще, всего 6К. На подходе реализация самых жизненно необходимых компонентов - скрол-бара, прелоадера, собственно базового класса приложения, текстового веб-сервиса и AMF веб сервиса и, конечно, тестирование и оптимизация
В чем заключаются основные отличя от mx пакета:
- я стараюсь максимально избегать зависимостей между компонентами. Т.е. принцип, "что использовали, то и скомпилировали", увы, дословно этот принцип реализовать невозможно, но стремится к этому нужно.
- создавать как можно меньше дополнительных свойств и методов, везде, где это возможно использовать методы флешевых классов. Избегать не-флешевые классы в аргументах, возвращаемом типе методов, свойствах и т.п.
- не писать приватных методов или свойств. Обязательно должна быть возможность переписать метод суперкласса, или, как минимум его "отключить" не подвергая риску весь остальной функционал.
<?xml version="1.0" encoding="utf-8"?> <e4xu:Control xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:e4xu="http://e4xu.googlecode.com" width="800" height="600"> <e4xu:Input text="Test text" align="center" background="true" backgroundColor="0xAAAAAA" width="700" height="25" x="50" y="20" /> <e4xu:Table id="testTable" width="700" height="500" backgroundAlpha="1" x="50" y="50" > <e4xu:dataProvider> <mx:XML> <data> <node secondColumn="foo1" firstColumn="bar"/> <node secondColumn="foo2" firstColumn="bar"/> <node secondColumn="foo3" firstColumn="bar"/> <node secondColumn="foo4" firstColumn="bar"/> <node secondColumn="foo5" firstColumn="bar"/> <node secondColumn="foo6" firstColumn="bar"/> </data> </mx:XML> </e4xu:dataProvider> <e4xu:columns> <e4xu:Column id="firtsColumn" filter="@firstColumn" /> <e4xu:Column id="secondColumn" filter="@secondColumn" /> </e4xu:columns> </e4xu:Table> </e4xu:Control>
Всего комментариев 26
Комментарии
23.09.2011 19:16 | |
Приветствую!
Очень понравилась идея с MXML без фреймворка. А что должен уметь делать мой компонент, чтобы его можно было использовать в MXML (добавлять ему детей в том числе)? Здесь http://www.ryancampbell.com/2009/08/...le-and-source/ говорят, что нужно добавить и методы public function get children():Vector.<DisplayObject>{} public function set children( value:Vector.<DisplayObject> ):void{} и совсем запутался, не найдя такого метода в интерфейсе. |
24.09.2011 01:17 | |
Пусть, пожалуй, тут полежит раз речь зашла о конструкторах в mxml http://habrahabr.ru/blogs/Flash_Platform/128703/
|
24.09.2011 13:25 | |
Хе, так bsideup статью даже написал я не знал.
|
24.09.2011 18:25 | |
Хватит матерится!
|
08.10.2011 16:39 | |
Ох, я как-то это комментарий пропустил. С компилятором... вобщем там есть небольшая проблемка... это форк версии 3.2, или может чуть пожже, того, что в транке у Адоби было. Над ним практически исключительно bsideup работал. Потом мы на какое-то время забросили работу... потом, когда уже была 4.1 bsideup вроде пытался подстроиться под новые изменения, но я не уверен, что ему удалось, даже если удалось, то он их не коммитил.
Пустышки я проапдейтил под 4.1. Т.е. они должны работать с адобовскими сборками компилятора. Хотя, с 4.1.5 не пробовал. Если в репозитори есть примеры типа <foo bar="'some string'" .../> - то это скорее всего примеры работы с форкнутым компилятором (строки в одинарных кавычках). Если честно, то я жду бета версий нового обещанного компилятора, за существующий как-то не особо хочется браться, да и необходимости сейчас такой нет... Да, еще по поводу большого количества пустышек - как это ни смешно, некоторые даже не компилируются в результирующую флешку. Но кодогенерация заставляет их держать потому что очень топорно написана. Например, <Application> абсолютно безо всякого повода импортирует кучу классов из mx.* пакетов, которые далее нигде не используются, но чтобы компилятор не ругался, приходится их тоже добавлять... |
|
Обновил(-а) wvxvw 08.10.2011 в 16:43
|
20.12.2011 21:28 | |
https://github.com/bsideup/TrylogicFramework
и, да, советую глянуть =) давно уже использую MXML без Flex-а в своих проектах даже без модификации компилятора |
20.12.2011 21:42 | |
О. Прикольный фрэймворк. Сами велосипедируем подобное сейчас)
|
21.12.2011 01:59 | |
Сначала про Parsley. Скажем так, если то, что мы писали (пробовали) претендует на звание велика, то петрушка - это вертолет глубоководного плавания. Т.е. вещь не применимая вообще ни в какой ситуации. Написано, очевидно, либо в горячечном бреду, либо чтобы прославиться геростратовой славой, либо на зло (канадцам). Ни одна из предлагаемых фичь не имеет практического применения (их несколько ДИ - не единственное, что есть в петрушке, есть еще функции которые добавляют x-teen levels of indirection к describeType, XML и trace. Делая работу с ними жутко неудобной. Предназначено все это дело для северных областей Канады - где, как предполагается, фреймворк приобритет популярность, т.как его использование будет способствовать повышению комнатной темпереатуры за счет неустанной работы процессора.
На работе мы обязаны ее использовать. Это приводит к тому, что работу которую можно было сделать за день мы делаем по несколько недель, а юнит тесты не пишем в принципе, т.как best practices петрушки делают это технически не возможным. Говоря другими словами, нет ничего такого, что сделано с помощью петрушки, что нельзя было бы сделать за меньше времени, прилагая меньше усилий, врезультате получив более простой и надежный код. А если абстрагироваться от петрушки, то ДИ - это прямая дорога вашему коду в помойную яму. Принципы ДИ и модульности не совместимы. Код с использованием ДИ, по определению избыточный и одноразовый. Мы это прочувстовали на проекте который пишется уже несколько лет более чем десятком программистов. Модули, которые использовали, или используют один или более из нижеперечисленного не портируемы и не реюзабильны в принципе. Т.е. деньги и время потраченые впустую: PureMVC, SWIZ, Cairngorm, Parsley, Mate. О недостатках петрушки можно говорить еще долго, т.как наболевшая тема, но, я думаю, достаточно сказано Что до "без фреймоврка" - bsideup наверняка лучше опишет часть компилятора. Что до mxml части - не используется только "тяжелые" компоненты, такие как UIComponent и производные. Дело в том, что все, что связано с флексовым фрейморком было написано в худших традициях enterprise рынка. Т.е. монолитная глыба унылого, но все же оттестированого и худо-бедно работающего кода. Если слово enterprise не наполнено смыслом - речь о ситуации, когда приложение делается для очень ограниченного круга заказчиков, которым можно диктовать условия типа железа, операционной системы, даже можно потребовать от заказчика, чтобы сисадмина наняли определенного и платили за ежемесячные проверки работоспособности программы и т.п. Обычно это выливается в огромные системы написаные ad hoc, которые не возможно использовать частями, не возможно проапдейтить или использовать совместно с программами от других производителей. Используется: биндинг, т.как это зашито в компилятор на генетическом уровне. Используются метаданные, специфические для фреймворка. Используется возможность назначать стейты / подписываться на события декларативно. Откровенно говоря, глядя назад, мне кажется, что можно было лучше, иногда даже гораздо лучше... Но столкнувшись на практике с неимоверным количеством ограничений накладываемых декларативным стилем mxml я склоняюсь к мысли, что нужна либо очень серьезная переработка принципов, либо это в целом ущербное направление. Кроме того, на каком-то этапе, пришло разочарование от понимайия того, что никакими усилиями из SimpleButton, например, полноценную кнопку не выпилить. От битмапа нормальной интеракции с мышью не добится. На базе FTE минимально юзабильный фреймворк не построить. |
|
Обновил(-а) wvxvw 21.12.2011 в 02:01
|
21.12.2011 12:07 | |
Спасибо. Как я понял, петрушка и Ко очень плохие. TrylogicFramework чуть получше.
|
21.12.2011 15:20 | |
Сейчас пробуем прикрутить Spring - последний snapshot, благо, что разделили на отдельные либы с as3commons (хотя очень криво)
Но уже бесит, что EventBus не реализует IEventDispather. Чтобы перевести своих диспетчеров с на EventBus - вчера переколбашивал кучу кода, а если бы реализовывали - в одном-двух местах инжектировал бы нужные шины и всё ок. Как то кривенько получается пока. Я вообще не сторонник фрэймворков, но в текущем проекте, хотя бы настоял не использовать флекс (вес имеет значение). Авось и от спринга отобьюсь) |
|
Обновил(-а) Котяра 21.12.2011 в 15:59
|
27.12.2011 18:46 | |
Следует использовать SWC версию, т.к. в исходниках нет маппинга MXML компонент
|
Последние записи от wvxvw
- Dired - текстовый проводник по файловой системе (29.06.2013)
- Навигация по HTML с WASD (09.06.2012)
- JavaScript, все не так плохо (07.06.2012)
- Что такое tarball и чем его пакуют (11.04.2012)
- Критика Presentation Model (18.02.2012)