Every once in a while, we cheat to get some performance. It makes for inconsistencies and annoys people or trips them up. If there was a way in the language to enforce the order these properties get set I would've used it, then you wouldn't get burned as easily. However, we covered the rules for it in documentation since that's as good as we could do.
Performance outweighed consistency and extensibility in the framework thus far. So, your example won't work as expected, but that's because you're not using the component in the "documented and supported" way. Hope you don't lose too much sleep. ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of benoit.kogut Sent: Friday, September 21, 2007 3:32 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: ItemRenderer : listData and dataChange event I understood that, but I expected a bit more information. The listData property does not comply to its description, since it relies on another somewhat unrelated property (i'm streching a bit the matter, please don't flame), that could be seen as a severe inconsistency. An amazingly stupid example, since data and listData are not meant to be used that way At ALL : private function mungoClick():void { mungo.data = {a: null} mungo.listData = new BaseListData('energise !', '', null) // mungo.data = {a: null} } (...) <mx:TextInput text="{mungo.listData.label}" /> <mx:Button id="mungo" click="mungoClick()" /> Should that work ? the code seems correct, but the data binding doesn't work (unless the data property is set afterward). Does it matter ? maybe, at least enough to keep make awake late at night ;-) thanks ^_^ --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , "Alex Harui" <[EMAIL PROTECTED]> wrote: > > The setter does not have to call dispatchevent in this case because by > convention, the list classes set listData then set data which will fire > the dataChange. This is required since we have to set both in order for > the two properties to remain synced up. So you don't want or need to > dispatch the event in the listData setter. > > > > > > > > ________________________________ > > From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of agggka > Sent: Friday, September 21, 2007 2:31 AM > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > Subject: [flexcoders] ItemRenderer : listData and dataChange event > > > > hello there, > > Using the advices found on Alex Harui's blog, I wrote a simple > ItemRenderer. I stumble upon a weird (but documented) flex behavior, > the 'listData' property is describted as [Bindable(dataChange)] but > the property setter does not dispatch a dataChange event. > > I did check the IDropInListItemRenderer's documentation, I understand > that it's the common way item renderers work, but it's bugging me. > > So there are my questions : > > What would be the consequences if the dataChange event was dispatched > by both 'data' and 'listData' properties setters ? Would it introduce > unexpected behaviors ? or have a noticeable cost ? > > Why on hell the 'listData' property was made public if it imply that > it can't comply to its description (does not dispatch the event) ? > Could the item renderer mechanic change someday ? > > thanks ^_^ >
