The rich:suggestionBox control allows a user to type in a few characters and get a drop-down list of elements matching the string. So, for example, if the box was backed by a bean that could search through cities in California, and I typed in "san", I'd get a long list including "San Diego", "Santa Barbara", "San Francisco", etc. If I then continued typing, so the full string was "san d", the list would shrink down to "San Diego", "San Dimas", and probably a few others.
Our backing bean is pretty stupid now. It doesn't recognize that "san d" results are going to be a subset of "san" results, so rather than filtering what it already has, it runs a brand new query ... actually a web service call in my case. Also if the user erases some letters, that forces a new query too, which might be a duplicate of a query just run. Under the theory that good developers write good code, and great developers steal good code, I wonder if anyone has come up with a good framework for a backing bean that minimizes the number of queries it has to run. (I know a second-level cache would help here, but it wouldn't solve all the issues, and it's a bit harder to integrate with web service results than, say, with Hibernate.)
You can use a HashMap to cache typing results. Key on the suggestion string, then map it to the collection of matching rows. Then when a new suggestion string comes in, check it against the keyset. If the suggestion is an extension of the keyset - and not already in the cache - build a new collection including only those rows from the broader collection that still apply, then cache that. Add a bit of purging logic if it gets too resource-hungry. This is taking advantage of the fact that the same object can reside in more than one collection, so you don't need to clone or re-fetch objects for the more limited colection. And you won't have to "go back to the well" unless none of the cached jey/value pairs can be used.
Customer surveys are for companies who didn't pay proper attention to begin with.