|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|
|||||
Регистрация: Aug 2009
Сообщений: 53
|
Вопрос по теории "livecycle createChildren".
Всем привет .
В некоторых источниках мне попадалась информация о том что создавать объекты надо в переопределеном методе "createChildren". Проблема состоит в том что если использовать "set" для определения объекта то сетер проходит раньше чем "createChildren" что преводит к ошибке. Вопрос такой в каких случаях определять объекты в методе "createComplite" а каких в методе "createChildren" ? Всем спасибо. |
|
|||||
Цитата:
Цитата:
|
|
|||||
Регистрация: Aug 2009
Сообщений: 53
|
Здравствуйте.
public function VideoPlayer() { super(); } public function set source(value:String):void { player.source = value; } protected override function childrenCreated():void { //TODO Auto-generated method stub super.childrenCreated(); player = new VideoDisplay() player.addEventListener(VideoEvent.READY,redyHandler); player.addEventListener(VideoEvent.COMPLETE,onComplete); this.addElement(player) } поетом я перекинул создание объекта player в конструктор. |
|
|||||
По-моему, у флекса такая иделогия
private var _source:String; private var sourceChanged:Boolean = false; public function set source(value:String):void { if (_source == value) return; _source = value; sourceChanged = true; invalidateProperties(); } override protected function createChildren():void { //TODO Auto-generated method stub super.createChildren(); if (!player) { player = new VideoDisplay(); player.addEventListener(VideoEvent.READY, player_readyHandler); player.addEventListener(VideoEvent.COMPLETE, player_completeHandler); this.addElement(player); } } override protected function commitProperties():void { super.commitProperties(); if (sourceChanged && player) { player.source = source; sourceChanged = false; } } |
|
|||||
Регистрация: Aug 2009
Сообщений: 53
|
а можно немножко по подробнее зачем запускать метод "invalidateProperties" .
|
|
|||||
Что бы был вызван commitProperties.
Добавлено через 1 минуту invalidateSize() – в следующем цикле будет вызван measure. //расчет минимальных размеров. invalidateProperties() – commitProperties. //применение/проверка свойств. invalidateDisplayList() – updateDisplayList. //отрисовка компонента и позиционирование его детей. Последний раз редактировалось alatar; 09.01.2011 в 13:39. |
|
|||||
Modus ponens
|
Вопрос с какого-то собеседования, нет? Меня тоже как-то спрашивали. И да, ожидаемый ответ -- что-то в духе как fljot описал. Но мне если чесно такая "непрозрачная" идеология не нравится. Т.е. как по мне имеет место попытка защиты от дурака предполагая, что человек использующий этот код обязательно дурак, что кроме всего прочего приводит к написанию лишнего кода. И, мое мнение, что если ошибка возможна, но легко устраняется пользователем, то ее нужно оставлять, и предоставлять пользователю возможность ее обработать, вместо того, чтобы городить кучу АПИ, которые мало того, что в 8 случаях из 10 будут лишними, так еще и в 1 случае из 10 будут вредными.
__________________
Hell is the possibility of sanity |
|
|||||
Чего в ней непрозрачного? Все фреймворки построения компонентов используют свой live cycle. Вполне логично, что программист должен ему следовать.
Цитата:
В этих случаях никто не заставляет использовать UIComponent в качестве базового для компонента. Вполне достаточно спрайта. |
|
|||||
Modus ponens
|
Как человек использовавший, пусть и не часто .NET фреймворк, могу с уверенностью заявить, что такого там нет. И вообще, если ошибиться десять раз, и один раз сделать правильно, то от этого ошибочное решение правильным не станет, так что, все или не все, это не аргумент. Есть логика и практика, логика говорит, что это не нужно и практика подтверждает, что это ни разу не пригодилось (мне лично) -- т.е. чистой воды балласт. Но, соглашусь, ни в этом, ни в каком другом случае UIComponent использовать не нужно ну или разве что чтобы процессор погреть, а то вдруг остынет и не заведется больше
__________________
Hell is the possibility of sanity |
Часовой пояс GMT +4, время: 20:52. |
|
« Предыдущая тема | Следующая тема » |
|
|