<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-компонента подобная галочка. Я не нашел...
4 комментария:
В ту же тему
http://noubase.com/?p=139
p.s.: извини за рекламу :)
А не проще ли сделать разметку в MXML (скажем MyComponentBase), а потом занаследоваться в обычном классе MyComponent и всю логику писать там?
1. Вы считали, как это влияет на скорость компиляции, работы приложения и занимаемую память по сравнению с обычным способом написания кода?
2. Даже если влияет не очень существенно (типа 5% по каждому параметру), вопрос - нафига он вообще нужен, этот Code-behind?
@yelbota: А собственно, об этом и пишу. Или предлагаешь наоборот, наследоваться от MXML компонента? Или я что-то недопонял? Сорри :)
@Slon_vsapogah:
1. Я думаю это может сказаться только в случае, если такие компоненты используются как itemRenderer (при массовом производстве), да и то не факт.
2. Так в начале поста я по-своему это обосновал. Лично для меня это серьезная причина. Ну а вообще, как пишут - это пришло из .NET, если не ошибаюсь, и является хорошим правилом.
Отправить комментарий