Shan’s Simple Examples: Setting properties of custom components
Someone in #cfflex on DALnet was asking about a custom component. They wanted to have a component that had two lists in it, where selections from the first list would filter the options in the second. They had a method written out that would do the comparison and filtering on the two lists, but they found that calling the method with the creationComplete event would return an error saying that one or the other property had no value.
The problem is that you never really know when or in which order properties will be set. The around this is to use getter and setter methods for your component’s properties:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | import mx.collections.ArrayCollection; private var _sourceData:ArrayCollection; private var _targetData:ArrayCollection; public function set sourceData(val:ArrayCollection):void { _sourceData = val; checkInit(); } [Bindable] public function get sourceData():ArrayCollection { return _sourceData; } public function set targetData(val:ArrayCollection):void { _targetData = val; checkInit(); } [Bindable] public function get targetData():ArrayCollection { return _targetData; } private function checkInit():void { if (_sourceData && _targetData) { // init this component here init(); } } private function init():void { ... } |
These getter and setter methods are called whenever external code tries to get or set the property value, including if your external value is set with a binding. If I call my theoretical component with the following MXML,
set sourceData()
and
set targetData()
are called whenever dataIn and dataOut get new values:
Both setter methods, after setting the passed value to private variables, call the checkInit() method. This method checks to make sure that _sourceData and _targetData are not null before calling the init() method.
Works great, Shan, thanks!
Comment by Jamie Jackson — April 20, 2009 @ 3:45 pm
A better place to check for this is in the commitProperties method. If you’d like to take advantage of Flex’s component lifecycle, your setter methods should call invalidateProperties. Then when you override commitProperties you’ll be ensured that any previous invalidateProperties calls will cause commitProperties to be run. Furthermore any changes which need to take place which affect the dimensions of the component should then take place in updateDisplayList, this is triggered through a call to invalidateDisplayList.
Ely Greenfield wrote a great presentation on the component lifecycle I recommend anyone doing component development to look it over.
http://www.onflex.org/ACDS/BuildingAFlexComponent.pdf
Comment by Tim — April 21, 2009 @ 11:57 am