Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > e4xu

Всякие разные штуки сомнительной полезности сделанные в свободное от работы время.
Рейтинг: 5.00. Голосов: 2.

MXML без фреймворка!

Запись от wvxvw размещена 11.04.2009 в 00:27
Обновил(-а) wvxvw 11.04.2009 в 00:38

Продолжая тему, сделал небольшую демку с использованием MXML компонентов построенных не на базе UIComponent. Ниже приведенный код реализует самые базовые возможности <mx:DataGrid/>. Конечно, он гораздо меньше чего может, зато скомпилированый в "дебаг" режиме весит всеро 13К, а в "релиз" режиме - так вообще, всего 6К. На подходе реализация самых жизненно необходимых компонентов - скрол-бара, прелоадера, собственно базового класса приложения, текстового веб-сервиса и AMF веб сервиса и, конечно, тестирование и оптимизация
В чем заключаются основные отличя от mx пакета:
- я стараюсь максимально избегать зависимостей между компонентами. Т.е. принцип, "что использовали, то и скомпилировали", увы, дословно этот принцип реализовать невозможно, но стремится к этому нужно.
- создавать как можно меньше дополнительных свойств и методов, везде, где это возможно использовать методы флешевых классов. Избегать не-флешевые классы в аргументах, возвращаемом типе методов, свойствах и т.п.
- не писать приватных методов или свойств. Обязательно должна быть возможность переписать метод суперкласса, или, как минимум его "отключить" не подвергая риску весь остальной функционал.
Код AS3:
<?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>
исходники: http://code.google.com/p/e4xu/source...org/wvxvws/gui
Размещено в Frameworkless MXML
Комментарии 26 Отправить другу ссылку на эту запись
Всего комментариев 26

Комментарии

Старый 14.11.2009 13:11 tas вне форума
tas
привет) Смотрю мы занимаемся одной сущностью - быть может, скооперируемся?
Если интересно, пиши в аську - двесте94-восемьсот14-восемьсот28 =)

Тоже заинтересован в нано-связанностях, тоже есть своя реализация, только я сейчас занимаюсь логикой, а ты, как смотрю, занялся GUI =) имхо можно посотрудничать )
Старый 23.09.2011 19:16 Flashrunner вне форума
Flashrunner
Приветствую!
Очень понравилась идея с MXML без фреймворка. А что должен уметь делать мой компонент, чтобы его можно было использовать в MXML (добавлять ему детей в том числе)? Здесь http://www.ryancampbell.com/2009/08/...le-and-source/ говорят, что нужно добавить
Код AS3:
[DefaultProperty( "children" )]
и методы
Код AS3:
public function get children():Vector.<DisplayObject>{}
public function set children( value:Vector.<DisplayObject> ):void{}
У тебя я такого не нашел, но зато нашел реализацию mx.core.IMXMLObject. И еще вот такой вот код (DIV.as):
Код AS3:
if (c is IMXMLObject) (c as IMXMLObject).dispose();
и совсем запутался, не найдя такого метода в интерфейсе.
Старый 23.09.2011 20:44 Flashrunner вне форума
Flashrunner
Разобрался. Как я понял, метатег вовсе не обязательно указывать, можно так (нет возможности проверить):
Код:
<MyComponent>
<children>
<Sprite/><Sprite/>
</children>
</MyComponent>
И так можно задать любое свойство! Будем юзать
Старый 23.09.2011 23:13 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Ох, ок, сначала последнее Мы работали над проектом вместе, я и bsideup. На каком-то этапе bsideup решил добавить деструкторы (т.как у сгенеренного кода могла возникнуть такая необходимость), и, на самом деле, в кодогенерации уже существующей (но не выполняющейся) в MXMLC такая возможность существует... Но это мелочи, не обращайте на это внимания.

Что касается детей. Когда-то давно, во времена SDK 3.2 добавление детей для объектов типа DisplayObjectContainer генерировалось безо всяких дополнительных усилий. Т.е. было просто достаточно написать тег ребенка в теге родителя. После переделок, когда стало необходимо объявлять не-дисплей объекты в отдельном теге появилась так же необходимость добавлять детей с использованием [DefaultProperty] (она и раньше существовала, как возможность, и можно было делать через нее, но как-то не было необходимости).

Во времена все того же SDK 3.2 компоненту нужно было реализовывать интерфейс IMXMLObject потому что у него автоматически вызывался initialize() вместо конструктора. Сегодня такого требования нет, в принципе любой класс может быть использован в MXML, но у MXML самого по себе есть куча ограничений... Когда мы работали над проектом, у bsideup было много интересных идей по улучшению (добавить конструкторы с параметрами, убрать обязательный биндинг для констант и много чего еще), но в Adobe это как-то никого не заинтересовало Судя по всему, они готовят вообще какую-то грандиозную переделку, т.как по-существу никаких работ по модификации существующего кода нет, только багфиксы, да и те с большим опозданием...
Старый 24.09.2011 01:17 alatar вне форума
alatar
 
Аватар для alatar
Пусть, пожалуй, тут полежит раз речь зашла о конструкторах в mxml http://habrahabr.ru/blogs/Flash_Platform/128703/
Старый 24.09.2011 13:25 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Хе, так bsideup статью даже написал я не знал.
Старый 24.09.2011 18:25 Зубило вне форума
Зубило
Хватит матерится!
Старый 28.09.2011 19:37 Flashrunner вне форума
Flashrunner
wvxvw, спасибо за подробный ответ.

Обнаружил такую особенность.
Было приложение, у главного класса - тег
Код:
[Frame(factoryClass="Preloader")]
. Добавил к нему (к приложению) пару своих mxml-компонентов, скомпилировал - все норм. Размер 27кб - вполне соответствовал написанному коду. Стоило заюзать байндинг (просто добавил id одному компоненту) - размер увеличился до 176кб в релизе. Посмотрев сгенерированные классы, оказалось, что в swf внедрилась какая-то флексовая хрень, вроде стилей и скинов. Убрал метатег - стало все норм - 30кб с байндингом. Внутреннее устройство флекса знаю плохо и объяснить причину этого не могу. Рассказал просто, чтоб не наступали на эти же грабли )
Старый 29.09.2011 00:09 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Собственно для этого я перекомпилировал фреймворковские библиотеки. В компилятор зашито, безо всяких шаблонов и настроек, что когда используется биндинг, то нужно использовать классы из пакета mx.binding.* - какие-то из этих классов, сейчас уже не вспомню, создают зависимость ко всему остальному коду через использование IUIComponent интерфейса. Самое смешное, что это какой-то костыль связанный именно с UIComponent, и его было очень легко избежать. Ну а если вы и вовсе не собираетесь его использовать - то его лучше просто выкинуть. С "развитием" фреймворка таких мест набралось еще немного - нужно смотреть в сторону того, что и как заставляет создавать зависимости ко всяким *менеджер классам. Постараться минимизировать, а там, где не возможно минимизировать, заменить *менеджер классы пустышками, т.е. классами с такими же методами, но ничего не делающими. Собственно, в 4.5 у меня получилось это сделать, дальше я не старался апдейтить, да и смысла особо не вижу пока.
Старый 30.09.2011 16:33 Flashrunner вне форума
Flashrunner
На мой взгляд, пустышек не так уж и мало вы написали. Тем более надо не мало кода перекопать, чтобы их написать, поэтому, с вашего позволения, попробую ваш пакет с пустышками использовать
Вы также выложили сам компилятор, я так понимаю свой. Скажите, "привязаны" ли ваши пустышки к вашему компилятору или может заточены под ваш фреймворк?
Старый 08.10.2011 16:39 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Ох, я как-то это комментарий пропустил. С компилятором... вобщем там есть небольшая проблемка... это форк версии 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:25 tas вне форума
tas
даже не знал, что эта тема жива =)

я (bsideup) недавно как раз таки решил её вспомнить, и написал пару статей на хабр, советую к прочтению

Если нужна какая-то помощь от меня по компилятору - обращайтесь (лучше - в скайп: ih8fkdskype)
Старый 20.12.2011 21:28 tas вне форума
tas
https://github.com/bsideup/TrylogicFramework

и, да, советую глянуть =) давно уже использую MXML без Flex-а в своих проектах даже без модификации компилятора
Старый 20.12.2011 21:42 Котяра вне форума
Котяра
 
Аватар для Котяра
О. Прикольный фрэймворк. Сами велосипедируем подобное сейчас)
Старый 20.12.2011 23:45 dimarik вне форума
dimarik
 
Аватар для dimarik
Я не очень силен во Flex. Раскройте, пожалуйста, суть фразы "MXML без Flex-а". Как я понимаю, вы пишете код в mxml файлах и при этом не используете классы компонентов из т.н. Flex-framework (библиотеки визуальных и не только компонентов). В этом ли заключается основное достоинство вашего подхода?

Бегло просмотрев пару примеров из TrylogicFramework наткнулся на применение техники dependency injection. Вспомнил о parsley. У них вроде неплохая документация, все понятно. Ваш велосипед больше скоростей имеет? Может быть у него есть секретное оружие? Просветите, пожалуйста.
Старый 21.12.2011 01:59 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Сначала про 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 11:48 gloomyBrain вне форума
gloomyBrain
 
Аватар для gloomyBrain
Цитата:
Предназначено все это дело для северных областей Канады - где, как предполагается, фреймворк приобритет популярность, т.как его использование будет способствовать повышению комнатной темпереатуры за счет неустанной работы процессора.
Хаха, wvxvw +1 =)
Старый 21.12.2011 12:07 dimarik вне форума
dimarik
 
Аватар для dimarik
Спасибо. Как я понял, петрушка и Ко очень плохие. TrylogicFramework чуть получше.
Старый 21.12.2011 14:07 tas вне форума
tas
когда я писал TrylogicFramework, главная идея была сделать "для себя", а не "что б поддерживало кучу умных слов и шаблонов проектирования".

По поводу DI (и IoC, в частности):
Если взглянуть на мою реализацию, то она отличается от петрушкоподобных, я не идеалист Spring-а, я не копирую его. Я сделал так, как мне удобно было бы с ним работать.

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

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

Кстати! Петрушка - это коробочка с всякими реализациями паттернов. IoC, Persistence, MVC... блаблабла. Проблема в том, что он не структурирующий. В TrylogicFramework я взял идеи Cocoa Touch, iOS фреймворка, т.к. занимался iOS кодингом, и мне очень понравились их подходы. В TF почти не возникает вопросов "как сделать это". Для меня это важно, т.к. это позволяет проводить гибкую разработку ПО, когда все знают все части приложения, а не только техлид (привет Agile )))))


По поводу модульности:
Олег, не знаю, за что ты так DI, но лично мы наоборот, гораздо легче разбили на модули приложение именно с использованием IoC-а. I'm lovin it!
Старый 21.12.2011 14:28 tas вне форума
tas
Кстати, в branch-е веду разработку немного переработанной системы иерархии вида, т.к. текущая создаёт слишком много избыточного кода (интерфейсы, в частности)

вообще советую подписаться в гитхабе на этот FW, т.к. он живой, я веду разработку, и дальше будет только интересней )
Старый 21.12.2011 15:20 Котяра вне форума
Котяра
 
Аватар для Котяра
Сейчас пробуем прикрутить Spring - последний snapshot, благо, что разделили на отдельные либы с as3commons (хотя очень криво)
Но уже бесит, что EventBus не реализует IEventDispather. Чтобы перевести своих диспетчеров с на EventBus - вчера переколбашивал кучу кода, а если бы реализовывали - в одном-двух местах инжектировал бы нужные шины и всё ок.
Как то кривенько получается пока. Я вообще не сторонник фрэймворков, но в текущем проекте, хотя бы настоял не использовать флекс (вес имеет значение). Авось и от спринга отобьюсь)
Обновил(-а) Котяра 21.12.2011 в 15:59
Старый 21.12.2011 20:17 dimarik вне форума
dimarik
 
Аватар для dimarik
Цитата:
К сожалению, я не умею писать такие примеры, чтобы сразу показать всю соль моего решения, но лично для меня - это самый удобный фреймворк из существующих.
Просто пару предложений, описывающих суть двигла и его преимущества перед другими. Смогёте?
Старый 22.12.2011 16:56 tas вне форума
tas
Цитата:
Просто пару предложений, описывающих суть двигла и его преимущества перед другими. Смогёте?
ммм. Первое, что бросается в глаза - в отличии от многих других FW (которые в большинстве своём просто библиотеки), TF - структурирующий фреймворк, позволяющий сильно сократить количество *****кода. Переносимость кода в рамках как фреймворка в частности, так и флеш платформы в целом. На днях планировал показать возможности "встраивания" решений на TF в уже готовые системы на других движках, либо вообще без них.

Это было первое предложение ))) Второе - это отсутствие жесткой привязанности к реализации, что достигается благодаря сильному абстрагированию от реализации. К примеру, если Вы используете Flex, и хотите, чтобы View наследовался от UIContainer, а не просто Sprite - есть такая возможность, без внесения изменений в код самого фреймворка. Это очень актуально в эру возникновения Starling и прочих.

Я любитель сахара, который не нарушает читабельность кода, поэтому отличительными особенностями кода с применением моих технологий - это метатеги, это использование кастомных namespace-ов области видимости. Я люблю, чтобы код читался как книга, а не как его скомпиленный бинарный вариант (привет ruby )))

Хотите в IViewController-е управлять элементом IView? Объявляем паблик свойство с метатегом Outlet:
Код AS3:
[Outlet]
public var myLabel : TextField;
Причем, memory-safe

Хотите делегировать событие из IView без мороки с подписыванием и отписыванием при memory managment-е?
Код AS3:
[Event(name="addedToStage")]
public function onViewAddedToStage() : void
{
}
Хотите подписаться на какой-либо глобальный Action?

Код AS3:
[Action]
APPLICATION_STATE_CHANGED function onAppChangesState(newState : String, oldState : String) : void
{
    if(newState == "game")
    {
        actionDispatcher.dispatch(INIT_GAME, [GameType.PUZZLE]);
    }
}
на github-е есть ссылка на руководство, там не ASDoc, а именно мануалы по использованию, советую глянуть (да, я обещаю написать больше, и у меня большие планы на НГ выходные, ибо сейчас - работа)
Старый 27.12.2011 18:25 incvizitor вне форума
incvizitor
 
Аватар для incvizitor
А как это вообще работать должно?

Во флешь девелопе создал файл "e4xu_test.mxml", сделал его документ классом. В путях проекта указал каталог src папке в которой лежит папка org.

При компиляции выдает:
Цитата:
Error: Could not resolve <e4xu:Control> to a component implementation.
Старый 27.12.2011 18:46 tas вне форума
tas
Следует использовать SWC версию, т.к. в исходниках нет маппинга MXML компонент
Старый 29.12.2011 03:04 wvxvw вне форума
wvxvw
 
Аватар для wvxvw
Пространство имен определяется в файлах "манифестах" - XML файл в котором перечисляются все компоненты относящиеся к определенному пространству имен. Префикс (в данном случае e4xu) - вы задаете сами на уровне mxml файла (т.е вы можете назвать как хотите). URI пространства имен задется в параметрах компилятора (смотрите справку по -namespace), или, если у вас есть уже скомпилированная библиотека, то в ней он уже может быть задан (библиотеку же тоже кто-то компилировал ).
Но флексовый компилятор иногда делает исключения... и, например, произвольно переопределяет, либо не позволяет определить некоторые классы в своем пространстве имен. (Вы не сможете определить Number в своем пространстве имен - спасибо талантливым дизайнерам флекс фреймворка ).

Ошибка выше возникает в следующей ситуации:
Код:
<f:Sprite xmlns:f="flash.display.sprite.*"
  xmlns:e="http://www.example.com">
  <e:Component/>
</f:Sprite>
* В файле манифесте указаном в -namespace нет определения класса Component.
Например: в манифесте есть класс Compotnet
* В файле манифесте есть компонент, но его полное имя не указывает ни на какой класс известный компилятору.
Например, в манифесте указан класс my.compot.net.Component, в то время как в реальности класс называется my.component.Component.
* Ошибка в URI пространства имен, например, -namespace "http://exapple.com" my-manifest.xml.
 

 


Часовой пояс GMT +4, время: 21:04.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.