I have no control over the dataProvider at all. Performance is not an issue, because the data extraction only happens once, and it can be time-sliced it so the webapp does not appear to freeze. Passing through multiple event handlers, including EnterFrame would be perfectly acceptable.
> 3) Depth: Since you have no control over the renderers, you don't have any > way of knowing whether they're composed of containers within containers, etc. True. The routine needs to deal with that. > 4) Layout: Presumably, you want to have the text appear in the same order it > appears in the columns, and then within the individual renderers. There's no > guarantee that your iteration will go from top left to bottom right, so > you'll have to record where the text was found and then arrange it in some > way that tries to make sense (but may not, depending on what is going on in > the renderers). Yes, doing this right will be a lot of work. > 5) Random surprises from the renderer developers. If the renderer developer > makes a reference to its parent, owner, or something else like that and you > instantiate it in a way that doesn't involve a List of some sort, you may > wind up with Null Pointer Exceptions. They may come up with other stuff that > won't come up in your testing with reasonable renderers that you wrote, but > it will be your fault when they do something stupid and YOUR logic errors out. Yep, that is true. > In short, you have to work together with your other team members one way or > another to make this work. There are no other team members. This is a library routine. I want this to be as general as possible, and am prepared to do what it takes to make it work properly. > Why not just shortcut to the most performant method? Performance is not important, general utility is important. The library feature should just work, no excuses.