--- In [email protected], "Tracy Spratt" <tspr...@...> wrote: > > The core concepts are that item renderers need to update their visual UI > elements when the associated item changes, and need to update that item on > user interaction. > > > > You assign a dataProvider(StockInfo) to the List, which results in item > renderers being instantiated. Note, do not use an Array as a dataProvider, > use ArrayCollection. > > > > When the underlying item changes, the framework calls the renderer's set > data method(setter). When any pending changes are done, the framework calls > commitProperties.
Well, sort of. If a property of an object that's stored in an ArrayCollection changes, the ArrayCollection has no idea, and hence the List will not call setData(). You could potentially set up your itemRenderers to register/unregister for these events in the set data() override for your renderer. But that means your renderer can only ever be used to render this type of object. That's not necessarily a bad thing, but I try to keep my renderers barefoot and pregnant if you know what I mean. So my approach would be to have a manager that contains an ArrayCollection of StockInfo objects as one of its public properties. Bind the dataProvider on your HorizontalList to that public property. I'd probably limit that to read-only by just using a getter on it. Make sure your manager component takes care of all of the adding and deleting of StockInfos into the AC, so it can register for your change events on all items that are currently stored there and unregister for them once they're gone. Then when the manager gets the event, calls itemUpdated on whichever SockInfo changed, and the HorizontalList will update normally with no more special effort on your part. HTH; Amy
