Случайно столкнулся с таким вариантом байндинга:
Вот к примеру, обычно мы делаем вот так:
<someComponent someAttribute="{someValue1+'_splitter_'+someValue2}"/>
А оказывается можно и так:
<someComponent someAttribute="{someValue1}_splitter_{someValue2}"/>
четверг, июня 04, 2009
Выбираем движок для просмотра Flash-панорам
Сегодня ищем движок для просмотра flash-панорам.
Для начала - немного теории панорам: Панорамная фотография, BASICS (здесь же можно найти и другую информацию про панорамное фото, софт, вьюверы).
По flash-вьюверам панорам, Гугл выдал следующих претендентов:
Для начала - немного теории панорам: Панорамная фотография, BASICS (здесь же можно найти и другую информацию про панорамное фото, софт, вьюверы).
По flash-вьюверам панорам, Гугл выдал следующих претендентов:
- Flash Panorama Player - платный, недорогой вьювер кубических панорам. Принцип прост - имя swf-файл вьювера должно соответствовать имени jpg-файлов, которые имеют соответствующие сторонам куба суффиксы.
- Ryubin's Flash Panorama Laboratory - Отличный движок, без исходников, но настраиваемый через XML.
- krpano - платный, недорогой вьювер с кучей дополнительных фич, типа эффект линз и тп.
- PanoSalado, Spincontrol - опенсорсный движок на базе PV3 и AIR-утилита для сборки виртуальных туров. Есть и исходники и документация.
среда, июня 03, 2009
Code-behind или mx:Script?
До некоторого времени, я выносил объемный AS-ккод из MXML-компонентов, используя тег <mx:Script/>:
Каких-либо логических недостатков такого метода я не наблюдал, однако столкнулся с постоянной глючностью автокомплита AS-редактора FlexBuilder. И вот, когда меня в конец это достало, решил взять на вооружение способ Code-behind.
Про Code-behind пишут следующее:
Code Behind
Building components by using code behind
Code-Behind in Flex 2
Code-behind gotcha in Flex Builder for AIR apps
Советы новичкам
В кратце, суть проста - наш MXML компонент ComponentName не базируется напрямую на основном компоненте, например, Canvas, а на компоненте-"прослойке" ComponentNameClass (также используется суффикс -Base). Код этого компонента размещается в ComponentNameClass.as. Его класс является потомком класса того самого основного компонента (Canvas) и содержит весь необходимый AS-код.
Все компоненты, которые имеются в ComponentName.mxml и к которым нужен доступ, должны быть объявлены в ComponentNameClass.as как public. Методы и обработчики событий - public или protected.
Вообще, конечно, это очень правильный подход. Только напрягает пара фактов - нужно возиться с объявлением класса и объявлять все компоненты, с которыми необходимо иметь дело в as-файле. Если, к примеру, я вдруг передумаю использовать в MXML вместо LinkButton (а он уже объявлен так в AS-компоненте) простой Button, получу ошибку - необходимо везде сделать замену. Выход - объявлять их дальних предков или вообще интерфейсы.
А вот интересно - есть ли средства автоматизации этого процесса? Что-то типа команды "Create Code-behind Class" или при создании MXML-компонента подобная галочка. Я не нашел...
<mx:Script source="includes/ComponentName.as"/>Каких-либо логических недостатков такого метода я не наблюдал, однако столкнулся с постоянной глючностью автокомплита AS-редактора FlexBuilder. И вот, когда меня в конец это достало, решил взять на вооружение способ Code-behind.
Про Code-behind пишут следующее:
Code Behind
Building components by using code behind
Code-Behind in Flex 2
Code-behind gotcha in Flex Builder for AIR apps
Советы новичкам
В кратце, суть проста - наш MXML компонент ComponentName не базируется напрямую на основном компоненте, например, Canvas, а на компоненте-"прослойке" ComponentNameClass (также используется суффикс -Base). Код этого компонента размещается в ComponentNameClass.as. Его класс является потомком класса того самого основного компонента (Canvas) и содержит весь необходимый AS-код.
Все компоненты, которые имеются в ComponentName.mxml и к которым нужен доступ, должны быть объявлены в ComponentNameClass.as как public. Методы и обработчики событий - public или protected.
Вообще, конечно, это очень правильный подход. Только напрягает пара фактов - нужно возиться с объявлением класса и объявлять все компоненты, с которыми необходимо иметь дело в as-файле. Если, к примеру, я вдруг передумаю использовать в MXML вместо LinkButton (а он уже объявлен так в AS-компоненте) простой Button, получу ошибку - необходимо везде сделать замену. Выход - объявлять их дальних предков или вообще интерфейсы.
А вот интересно - есть ли средства автоматизации этого процесса? Что-то типа команды "Create Code-behind Class" или при создании MXML-компонента подобная галочка. Я не нашел...
Подписаться на:
Сообщения (Atom)