Agree with Kevin though, hope too see a community developing Flex 2 components etc

cheers

I probably won’t support itemRenderer, although you’re more than welcome to add it. (Shouldn’t be too much work, since the list is built using a List control, which already knows about itemRenderer).

The main reasons are:

1) I wanted to create a control of moderate complexity to illustrate what it’s like to create a control. It doesn’t do everything that the framework controls do (so it’s much easier to read and understand), but it is complex enough that it gets into some meaty issues.

2) Auto-complete implies that the items are strings, or at least have a strong relationship to strings. This does not mean that I can’t imagine ways to use item renderers. However, it does mean that you’re somewhat less likely to need them in auto-complete controls than in, say, TileList, which is just a way of laying stuff out on the screen.

Of course, if enough people ask for it, or if you can help me think of some cool use cases, you might end up convincing me after all…

Will this component support itemRenderer as per normal Flex combox in the future?

so that the “dropdown list” can render more then just text?

cheers

Kevin: Glad this helps!

Steven: Interesting you mention this. I played around with this approach but decided to go with sorted lists instead, because they were easier for me to think about and seemed fast enough.

The data structure you describe in your article is a trie (sometimes pronounced “tree”, sometimes pronounced “try”). It is definitely the fastest data structure for doing prefix filtering, but takes the most space. There is a variant which is more space efficient called a Patricia Tree, which collapses nodes that only have one child. There are other popular variants, in which an array is sorted, and then a jump table is built for the first several characters that point to indices in the sorted array. Kind of a like a trie that points into an array.

Theoretically, a trie is a constant time lookup for fixed key lengths, whereas I am using a binary search, which is a log N process. However, the main performance issues arise not in the lookup, but the handling of the data after the lookup.

When no characters have been typed, the filtered result is the same as the original list of strings. In my code, these strings are copied into a separate array. That is obviously an order N operation. There is also a just-as-obvious solution to this, which is to make an empty prefix a special case and return the original array instead of a copy.

Finally, I deal with the sort order of the results by creating my list of candidates and then sorting them. This is an N log N operation. If you can help me speed this up, this would be the biggest bang.

In any event, if you can help me make this code faster, I’d be all for it!

In the meantime, it might be a good approach to incorporate into your component (which has a nicer UI to show the possible completions in a drop-down).

Hope to catch up with you again soon – Steven.