--- In [email protected], Fotis Chatzinikos <fotis.chatzini...@...> wrote: > > Amy is right, > > the code was: > > override public function set data(value:Object):void > { > super.data = value; > } > > maybe its preferable to have : > > override public function set data(value:Object):void > { > if (value != null) > { > super.data = value; > } > } > > > What i usually do is check for null and then if not do any custom logic: > > override public function set data(value:Object):void > { > if (value != null) > { > super.data = value; > > //pseudo > if (value is supposed to be shown in red) > { > make the background red > } > else > { > //reset component to solve renderer re-use issues > reset color to Grey > } > } > }
This makes it impossible to set the data property to null. There might be some cases where you might actually want to do that (for instance if you wanted to have something that visually matched your renderers, but wasn't included in a List-based component. So you could potentially use a component that could be used as a renderer or not and reuse the data property to populate it. It seems to me that you're probably checking for null to account for the occasions when set data is called before createChildren(), which sometimes, but not always, coincides with null data. It seems like it's safer to either check for the child to be null or to call invalidateProperties() and put your logic in commitProperties, which always happens after createChildren. JMO; Amy
