we agree to disagree in that case. why lists based components. 1. automatic recycling 2. easier to tap into events and determine which item was clicked etc 3. itemrenderer factories
repeaters are useful and we use them, but its the correct tool for the time, and mostly the correct tool is some list based control, for us anyway. On Fri, Jan 30, 2009 at 6:09 AM, Tracy Spratt <tspr...@lariatinc.com> wrote: > "…repeater is rarely the sollution…" > > > > I disagree intensely. It depends entirely on the problem. Repeater should > not be used to replace a List-based control for a large number of items. > > > > But it should always be considered when you start using addChild() > statements driven by some data structure. > > > > And it can replace List for a limited number of items, or if you use a > paged navigation instead of scroll. > > > > Repeater has gotten an undeserved "bad rap" from folks using it improperly. > > > > Tracy Spratt > Lariat Services > > Flex development bandwidth available > ------------------------------ > > *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On > Behalf Of *Johannes Nel > *Sent:* Wednesday, January 28, 2009 5:05 AM > *To:* flexcoders@yahoogroups.com > *Subject:* Re: [flexcoders] itemRenderer data question (recycling) > > > > mmm, repeater is rarely the sollution IMO. remember that they render all > the items (when they do not recycle) and not only the visible parts like a > list. > > On Wed, Jan 28, 2009 at 11:23 AM, nwebb <neilw...@gmail.com> wrote: > > Ah right - wasn't aware that repeaters didn't recycle - thanks. > > > > On Fri, Jan 23, 2009 at 6:34 PM, Alex Harui <aha...@adobe.com> wrote: > > If there aren't going to me more than a few dozen funds you can use > repeater and avoid recycling. Otherwise, you'll have to live with recycling > and add other data like when it changed last so you can determine whether to > color it or not. > > > > *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On > Behalf Of *nwebb > *Sent:* Friday, January 23, 2009 12:54 AM > *To:* flexcoders@yahoogroups.com > *Subject:* Re: [flexcoders] itemRenderer data question (recycling) > > > > Yes sorry - I was scant with the details because I know people don't read > long posts. > > I'm just using a standard array for the dp rather than an ArrayCollection > and I am overwriting the array each time. Eventually I think that each > bundle may have completely different items (they are actually funds - this > is a financial app) , but in my test data I just have 4 funds. It was a > question out of curiosity more than anything else. I was trying to knock > something together quickly as this is just a prototype screen. > > ....at the moment (in the test data) I have the same 4 funds for each > bundle. From the UIDs I get, it looks like the renderers get recycled and > always in the same order - ie the renderer that was last used to display > item4 is then used to display item1 the next time around. If you knew your > List would never scroll, and you had the same four items, I wondered if > there was a way to turn off recycling, or at least get the renderer in > position1 to be in position1 again after a refresh. > > > n.b. Currently I send in the old percent & new percent, the override set > data and determine the state using those values, so the uissue is solved, > but curious to know if there is a way to get the same renderers being reused > in the same order for a scenario like i described. > > On Thu, Jan 22, 2009 at 6:43 PM, Alex Harui <aha...@adobe.com> wrote: > > That didn't quite make sense. What is the dataprovider for the % list? > Why would different bundles have data items with the same UID? Are you > resetting the dataProvider when someone selects a different bundle? > > > > If the dp for the % list is a set of fields computed from the selected > bundle, don't reset the dp and have those items in the dp dispatch change > events. That should keep recycling to a minimum. If that doesn't work, try > using a DataGrid with 1 column and headers turned off. It is possible that > List has a different recycling algorithm than DG > > > > *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On > Behalf Of *nwebb > *Sent:* Thursday, January 22, 2009 4:14 AM > *To:* flexcoders > *Subject:* [flexcoders] itemRenderer data question (recycling) > > > > Hi, > > > I have 2 List components on a page. > The one on the left displays the names of some "bundles" - e.g. "*Bundle > 1*" > The one on the right displays the items in the selected bundle, plus a > percentage value - e.g. "*item1 - 10%*" "*item2 - 55%*" "*item3 - > 61%*" > > The items are the same for all bundles, but their percentages may change as > the user selects different bundles. If that happens I want to highlight that > itemRenderer. (eg when the percentage changes, highlight renderer) > > > I looked at a similar example from Alex Harui - he compares a DataGrid's > listData.UID to the previous UID (stored as a property on the renderer). If > they match, he knows he has the same item and changes that value. > > I have implemented IDropInListItemRenderer (so I have access to the UID) > but the renderer-recycling of the List means that even when the UID's match, > the "oldPercent" value I stored doesn't actually match up to item being > displayed - in other words, the renderer which previously displayed "*item1 > - 10%*" may now be displaying "*item3 - 61%*" , so the percentage HAS > changed, but that's because it's displaying a different item! > > Is my only option to send both the new% and old% in via the dataprovider, > or is there another way to get around this issue? > > Cheers > > > > > > > > > -- > j:pn > \\no comment > > > -- j:pn \\no comment
