Thanks, so it is a case of performance trade-off. Alas, I may not get sleep so easily, by now I'm trying to figure out the drag n drop mechanics within a Tree (calculateDropIndex, ah!)
Thanks for the reply --- In [email protected], "Alex Harui" <[EMAIL PROTECTED]> wrote: > > 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: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of benoit.kogut > Sent: Friday, September 21, 2007 3:32 PM > To: [email protected] > 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 [email protected] <mailto:flexcoders%40yahoogroups.com> > , "Alex Harui" <aharui@> 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: [email protected] <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of agggka > > Sent: Friday, September 21, 2007 2:31 AM > > To: [email protected] <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 ^_^ > > >
