--- In [email protected], "Alex Harui" <[EMAIL PROTECTED]> wrote: > > It depends... > > > > ...on the data object. Is it bindable? If so, does it really need to > be? > > > > Let's say you have a person Object { firstName: "Alex", lastName: > "Harui"}. Not bindable. It becomes the data property of the renderer > and you want to map components in your renderer to it. > > > > If you do: > > <mx:Label text="{data.firstName"} /> > > > > you will get warnings as the firstName property is not bindable. So the > important question is: Does it need to be bindable? Is the firstName > property of an object going to get modified in a way that won't refresh > the List? Usually not, but sometimes, some other part of the UI is > binding to list.selectedItem.firstName which will still work as it will > trigger on a change to selectedItem, but if you are editing items in the > list and changing the firstName, then selectedItem will not change and > other UI will not update. > > > > If it doesn't need to be bindable, then I'd just call > invalidateProperties and stuff the fields in commitProperties. The > speed difference will probably not be obvious, but it should be less > code and run slightly faster and you won't get warnings. If the data > object does need to bindable, then you might as well hook up with > binding if it is just a couple of bindings and the logic is simple. If > you already have a commitProperties method, I would probably not use > binding and map the data object fields in commitProperties because in > most cases, when the fields change in the person object, the entire data > property gets re-assigned due to the way most lists update their > renderers.
OK, thanks :-). That's the direction I was thinking.
