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.

Reply via email to